CommonLisp Scheme Part12

>>912
へぇ〜。つか、そういう面白いことは放送前に教えてくれよ。

もまいら
Common Lisp Hyper Specが更新されてましたよ。

http://www.lispworks.com/documentation/HyperSpec/index.html

>>912
（　ﾟдﾟ）ﾅﾆｰ!?

>>913同様に、そういう事は早く言えよ。

しばらく前からwilikiに書いてあったよ

ドラマの件はさ〜っぱり忘れてた。誰かビデオでも撮ってないかな。

Common Lisp HyperSpecは変更点がよくわかんないけどダウンロードしとこ。
関係ないけどLispWorks 4.4のPersonal Editionまだ来ないね。
ILC2005行けばEnterprise Editionの評価版貰えるかも知れないけどウェブサイト
見る限りじゃちゃんと準備が進んでいるのかあやしげな悪寒。業務で行くのは無理か。

文字コードをeuc-jpからutf-8に変換するライブラリで
lispの方言(librep)でも使えるものってありませんか？

そういう事にLISP使うのは間違ってる気がする
本来そういった文字セットとかを超越した所にS式は存在するべきなんだよ

>>919
青いな

Scheme初心者です。FAQだったらごめんなさい。
syntax-rulesで作成したマクロは通常define-syntaxで
シンボルにバインドしているようですが、なぜdefineでは
いけないのでしょうか？試してないけどそれもアリ？
ひょっとしてマクロとそれ以外のオブジェクトとで
異なるScopeを持たせたいってことでしょうか？

921です。
試してみましたが、やはりdefineではエラーになります。
defineを使ってマクロをシンボルにバインドするような実装も
可能だと思うのですが。
そうした場合、どういう不都合がありますか？

>>922
define はあくまで変数を定義してそれに値を与える（たまたま値がラムダ式であれば
関数を定義したことになる）だけです。マクロは文法上、変数ではないので define で
定義するのは一貫性を欠くことになります。また define-syntax はトップレベルでしか
使えないなど、制約事項も異なります。

>>922
あと、コンパイルと実行が別々になっている場合、マクロはコンパイル時に
展開するのが普通だから、マクロ定義と通常の束縛とが区別できる形に
なってないと困る、ってのもある。

お前等逝けよ。 >ALL
逝けってば。
早く逝けっつってんの。

最近LISPでない言語でプログラム書いたら、
LISPの偉大さ心に染みた。

処理系実装して解るLispの(_|_)さ。

どういうところがどうだと言いたいのかさっぱりわからん。

>>927
(_|_)
↑この顔文字?の意味がわからん。

ウルトラ・・・かな

>>923,924
921です。ありがとうございます。
コンパイラの場合、話はわかりやすいですね。
インタプリタの場合はどうでしょうか？
(実装依存、という話ではなく、どのようにあるべきか、です)
たとえば
(define-syntax some-operation (syntax-rules ...) ;;マクロ
(define some-operation (lambda ...) ;;手続き
とした場合、
(some-operation ...)
という呼び出しは、やはりマクロ定義のほうを優先するのが順当なのでしょうか。
ただし、呼び出し時の字面は全く同じだと仮定します。

あるべき姿としては、コンパイルしてもインタプリタで実行しても
同じように実行できるのがいちばんいいんじゃないの。もっともこれは
Lispが随分苦労してきた問題で、いまだにすっきりした解決は無いと
思うけど。（comp.lang.schemeあたりで、マクロと分割コンパイルの
話題を探すと色々出てくると思う）

マクロと手続き、両方定義したらどうなるかっていう話は、綺麗な仕様は
無いような気がする。ナイーブに上から実行してくインタプリタなら
後から出てきた方が上書きしちゃうだろうけど、例えば別ファイルで
some-operationにset!されたらどうなるかとか。921は何かアイディアがあるのか？

>>932
>921は何かアイディアがあるのか？
何もありません。ただ、R5RSをみても、define-syntaxの説明があまりにも
簡略でdefineとの関係がよくわからなかったのでおたずねしました。
Scheme勉強中なのでできるだけ実装系に依存しない理想的な挙動をイメージ
しておきたかったのですが、
[1]コンパイラなら話は簡単(924のように)
[2]インタプリタでもコンパイラと同じ挙動が期待される(932のように)
[3]ナイーブに上から実行してくインタプリタなら後から出てきた方が上書き(932のように)
ということですね。
931に挙げた例だと[2]と[3]とは矛盾することになりますが、
[2]は人間様にとって実装によらず常に同じ結果を返すようにするように期待したもので、
本来の「自然な」Schemeの振る舞いは[3]のほうである、と理解しました。

しかし、もし[3]の立場をとるとすると、define-syntaxとdefineとは同じscopeを
共有することになり、define-syntaxの存在意義がよくわかりません。
>>923さんは「マクロは文法上、変数ではない」と書かれましたが、
マクロを変数に「バインドする」ことならやってもよいのでは？(初心者です)
define-syntaxでなければできないことって、何かありますか？
具体的な例をいただければ理解できると思います。

初心者です・・・

人間様にはR5RS schemeのdefine-syntaxは理解できません・・・

初心者です・・・

初心者です・・・

具体的な例をいただけないと理解できんとです・・・

初心者です・・・

921です。自省
コンパイラの存在なしで話をしようとしていたのが誤りだったのかも。
結局Schemeといえども単なる言語処理系であって、形而上学的な理想像を
追い求めてはいけない、ということでしょうか。

>>936
私も初心者だけど、defineとdefine-syntaxは概念として全然違うものだと思うので、
なんでそんなにしつこく同一視できると思うのかよくわからない。
ただ、うまく説明できるほどには習熟してないのでもどかしい。

あえて説明を試みるならdefineは実行環境が持っている保存領域になんかいれるもので、
define-syntaxはコンパイラ(インタプリタ)に覚えさせる指示ってカンジ？
Cでいうならステートメントや式とコンパイラディレクティブの差みたいなもの。
変なこと言ってたらスマソ。

>>933
変数値として「マクロ」を認めてしまうと、当然実行時の動的な値に従うべきということに
なるので、実際問題としてコンパイラを作るのが非常に難しくなってしまうよね。

文法上「マクロ」は通常の Scheme の実行環境の「外側」にあると考えられるわけ。
マクロ展開時の「実行時環境」を考えたくないので、手続き的な方法ではなく宣言的な
方法での定義を強制させているのだろうね。

でも、個人的には危険が危ないがなんでもできる Common Lisp 風のマクロのほうが
好きだったりするのだが。ｗ

921です。
>>937
>Cでいうならステートメントや式とコンパイラディレクティブの差みたいなもの。
>>938
>文法上「マクロ」は通常の Scheme の実行環境の「外側」にあると考えられるわけ。
なるほどね。
個人的には、SchemeのマクロはCのプリプロセッサ的なものと理解しました。
かなり納得。

921です。939の続き。
となると、やはり933の[3]的な考えは正しくなく、どのような場合でも、
まずマクロ展開が行われてから、通常の評価が行われる、ということになりますね。
ふむふむ、納得。
間違っていたらご指摘ください。

>>940
むしろ、仮に [3] のような処理系であっても結果がなるべく同じになるように考えて
define と define-syntax を分離していると考えることもできる（ような気がする）。

>>929
未定義

jythonのようにjavaソースやclassファイルに落とせるlispの処理系って
何かありますか？
javaでは面倒な処理をLispで書けが生産性があがる気がするのですが。

>>943
最近のは試してないけど kawa はいかが？
http://www.gnu.org/software/kawa/

単発ＱＡは荒しのサイン

>>921
schemeでシンボルといったら'nameで表されるようなオブジェクト、または
それらの型を言う場合が多い。あなたが言っているものは名前とか識別子と
呼ぶのが適当だ。もし混同していたのなら、これを機に復習してくれ。

識別子には種類が二つあって、それは(defineやlambda式で導入される)変数名
と(define-syntaxやlet-syntaxで導入される)構文キーワード名だ。
これらは同じ名前空間で管理される(別の言い方では同じスコープ規則に
従う)が、扱いは別。
(932が言っているのは、ソースファイルとかモジュールというような概念が
定義されてないschemeにおいて、それらをどう扱うかという話。)

>>933
[1], [2], [3]はなんというか視点がずれてる。
コンパイラ、インタープリタ問わず処理系は (some-operation ...) を処理
するときには二つのsome-operationのバインドのうちどちらかしか見えない
ので、その式を処理する方法は常に一つしか存在しない。
つまり、some-operationを変数名だとみなしたら手続き呼び出しだし、
構文キーワード名だとみなしたらマクロ展開だ。

そういった訳で、940でのあなたの理解は大まかには正しいということに
なる。マクロ展開が先に行なわれるというよりは、マクロ呼び出しだったら
展開するしか処理方法がないということね。

ちなみに通常は、トップレベルで二重に定義された名前は後から定義した方
が以前の定義を(概念的に)上書きするので、 (some-operation ...) は
マクロ呼び出しとして処理することになる(この辺はschemeの仕様書で探して
みたが明確な記述はなかった)。

いい加減ﾃﾝﾌﾟﾚに入れても良い様な気がするが…

>>943
ttp://home.comcast.net/~bc19191/blog/040627.html

訂正。
> (some-operation ...) はマクロ呼び出しとして処理することになる
...は手続き呼び出しとして...

読み返してみると日本語ムチャクチャだな...

>>947
gj

jil.faslが存在しない〜〜〜なんだよ・・・

JiL? 6のトライアル版でも使ってんの？

>951
faslは見つけたんだが、require出来ん。
Trialでは無理なのかな？
これでjavaコード全部書いてやろうと思ってたんだが。

トライアル版持ってないから力になれない。Franz Inc.に直接問い合わせてみれば?

921です

>>946
>もし混同していたのなら、これを機に復習してくれ。
なるほど。ご指摘ありがとうございます。

>some-operationを変数名だとみなしたら手続き呼び出しだし、
> 構文キーワード名だとみなしたらマクロ展開だ。
結局、手続きとマクロ展開とはつくられたときから全く別の
ものであり、参照のためにそれぞれ変数名や構文キーワードに
関係づける際に、それぞれdefineとdefine-syntaxを使う、と
理解しました。
ただし、
>「これらは同じ名前空間で管理される(別の言い方では同じ
>スコープ規則に従う)
わけですね。

そうすると、マクロと手続きとは並列的な関係にあるオブジェクトであって、
>>946さんは婉曲に
>そういった訳で、940でのあなたの理解は大まかには正しいということに
>なる。
なんて書いてくださいましたが、私が>>939-940で納得していた
「Cプリプロセッサ的解釈」はちょっと違いますね。

compiler(およびそれと整合的なシステム)は、実行時に
マクロ展開を選択的に優先して実行するようなシステムだと
思えばいい、ということで、今度こそ納得できた気がします。

921です。補足
ちなみにcompilerそのものの場合には
コンパイル時にマクロ展開するので、
最後のくだりの中で
>実行時に
が不要であることはわかってます。

>>954-955
キミの理解はあってると思うけど、
キミの文章は色々不要な事を言い出しちゃってて、
コミュニケーションに難がある、と思う。

このような文章を書くあなたは学生さんだと思うが。
テストの回答で、余計な事書くと減点されるって知ってるよね？
今の君のコミュニケーションは、正にそれ。くどい。

くどい＝回りくどい

あるいは、

正解わからずに、解答欄に三つも四つも解を書いて、
数撃ちゃ当たるだろう、という傲慢な態度が見え隠れしている。

921です
>>956-957
勉強します。

>>954
それでOKかと。

923とその背景を説明してる924はよく出来てると思うので、迷ったら読み
返すといいかもしれない。

>>959
Vielen Dank!

CPSにコンパイルする処理系ないですか
もつろんSchemeでさ

rhizome/pi "完全なCPSによる実装である"らしい。