Lython: Python用common lispフロントエンド 14
ストーリー by Oliver
括弧の森の蛇 部門より
括弧の森の蛇 部門より
moriwaka 曰く、 "Pythonによるcommon lispフロントエンドlythonが開発されている。Lythonはcommon lisp風の記述を読み込み、直接Pythonバイトコードを出力して実行する。まだ初期のコンセプトリリースで、マクロやcar/cdr関数のような(lispとして)基本的な要素も十分ではないが、Pythonモジュールを読み込んで実行するサンプルなどを見ると、lispとPythonの利点をあわせもつ強力な処理系への期待が膨らむ。"
car/cdr (スコア:1)
Re:car/cdr (スコア:0)
contents-of-the-decrement-part-of-the-register
・・・なんか違う気もする。
＃Common Lispにはfirst/restってのがあるな。
Re:car/cdr (スコア:2, 参考になる)
以前 Common Lisp を使う職場に派遣されてた頃、 最初に car/cdr を使って書いてたら軽～く失笑されたので、 それ以降 first/rest しか使いませんでした。
あれは『時代遅れ』みたいなニュアンスの失笑だったかなぁ。
;;; cadddr なんてのよりは fourth の方がはるかに解りやすいですしね。
Re:car/cdr (スコア:0)
けっ。トーシローが。。。
Re:car/cdr (スコア:0)
理由の説明できない素人でない限り。
Re:car/cdr (スコア:1, 興味深い)
cadddr = car o cdr o cdr o cdr (o は関数合成)
だからLisperな人にはcaddrの方が分かりやすいんでしょう。
Re:car/cdr (スコア:2, 参考になる)
cons cell に対して car と cdr が何をやってるかを知らず、 単純に『cadddr ≡ fourth だから四つ目の要素を取ってくる』って短絡しちゃうと、 cdr 部がリストでない dot pair が出てくるとはまっちゃうかも。 中で何をやってるかが明示されてる cadddr の方が、 その点では確かに解りやすいですね。
まぁあたしゃ native Lisper ではありませんので、 しろーとったらしろーとなんですけど―― こんな阿呆コード [srad.jp] は書くゎ、 困った時は progn 頼みだゎで。
;;; いちおー数年間は Lisp（だけじゃないけど）でご飯食べてたので、
;;; プロではないとも言えないのですが。
Re:car/cdr (スコア:0)
なんてたって、本当のプロはもうみんな老眼ですから。
強力な処理系 (スコア:1)
でも、短いプログラムなら、自由なパラダイムで、簡単に書けるのも便利ですよね。
特に、関数型と手続き型の利点が、うまくマッチしてれば、とても簡単にプログラムが書けるようになるのかも。。。
野次馬的疑問 (スコア:1)
Re:野次馬的疑問 (スコア:1)
で。Pythonってダイナミックスコープを持っていないんじゃないでしょうか。完全にCommonLisp準拠にするためにはCommonLispインタプリタを書く羽目になると思います。
ただ簡単なマクロが実装されているようなのでsetfっぽいことは案外簡単にできるんじゃないでしょうか。
# まあ無理してPythonでLispしないでも本物のLispがあるんだし…。
Re:野次馬的疑問 (スコア:2, 興味深い)
そういう話ではなくて、Pythonの便利機能やらライブラリやらを
使いたいLisperにちょっと浮気する選択肢があたえられるのが
うれしいのではないのかな？
wild wild computing
Re:野次馬的疑問 2 (スコア:0)
Lispで実装したPython処理系って
どっちが現実的？
Lisper にとっては Python というと (スコア:1, 参考になる)
こっち [cons.org]のほうでは?