Common Lisp, Scheme Part 14
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/11/18(金) 10:02:06Part1: http://piza2.2ch.net/tech/kako/987/987169286.html
Part2: http://pc.2ch.net/tech/kako/1002/10025/1002584344.html
Part3: http://pc.2ch.net/tech/kako/1008/10082/1008220265.html
Part4: http://pc.2ch.net/tech/kako/1016/10162/1016211619.html
Part5: http://pc3.2ch.net/tech/kako/1023/10230/1023091882.html
Part6: http://pc3.2ch.net/tech/kako/1031/10315/1031560687.html
Part7: http://pc5.2ch.net/tech/kako/1042/10421/1042167213.html
Part8: http://pc5.2ch.net/tech/kako/1058/10582/1058263391.html
Part9: http://pc2.2ch.net/test/read.cgi/tech/1069594582/
Part10: http://pc5.2ch.net/test/read.cgi/tech/1075630259/
Part11: http://pc5.2ch.net/test/read.cgi/tech/1091456033/
Part12: http://pc8.2ch.net/test/read.cgi/tech/1100229366/
Part13: http://pc8.2ch.net/test/read.cgi/tech/1115901841/
0153114
2005/12/04(日) 16:25:53俺もそれしか無い気がしたが、Common Lisperの間でそういうスタイルが
一般的だとかいう話は聞いたことがないので。
あと、一番俺にとって重要なのはタイプするのが面倒だとかいうくだらないこと。
>>151
マクロがあるからLispに興味あるんだが、
ありふれたことをするのにも、例えば、大抵の問題を扱うのに
メッセージ伝達モデルのほうがタイプ量減るからといって、
マイ言語の世界に突入しなきゃならんのはどうかと。
共通プロトコルが安定してないとJavaみたいな大規模なライブラリなんて
作れないでしょ。
総称関数で書かれたライブラリと
メッセージ伝達モデルのオブジェクトシステムで書かれたライブラリが
平気で混在してるのがある意味、理想的な状況にも思えるけど、どうかな？
そんなのおぞましいって思うかな？
0154152
2005/12/04(日) 16:46:45パッケージ内で偶然バッティングするケースもあると思うけど、
「同じパッケージ内でも気にしたくない」ってのは、ちょっと
どうかと思うけど。気にしろよ、とか思う。
ってか、プログラマが｢気にできる｣範囲に分割するのがパッケージの
役割なんだから、｢気にしたくない｣なら、さらに分割すべき
だけど、その制限が｢仕様として」どうか、ときかれれば、まぁ、
ちょっと恣意的な制限ではあると思う。
0155149
2005/12/04(日) 19:08:31だから>>149で「メソッド名はクラス名をプレフィックスするなりして一意に」という
のはあくまで「極端な話」だってばさ。基本的には>>152氏も言っているように
同じ名称のメソッドは対象となるクラスが異なっても同じ機能を持つはずであって
同じパターンで引数を取るはずであるというのが設計思想の根底にあると思う。
あとは昔のbit別冊に載ってた記憶があるが効率の問題もあるかもしれん。
0156デフォルトの名無しさん
2005/12/04(日) 21:44:51メッセージという特定のクラス系統に特定の意味を持つものにgenericな
名前をつけてしまうのがオブジェクト・セントリックな世界から頭を
切り替えられない人の敗因。
C++やJavaのメソッドの名前というのはあくまである対象固有の操作に
つける名前であるから、その一面を切り取って命名しているに過ぎない
(または名前がもつ意味の一面しかその操作が表していないとも言える)。
だから対象となる系統が変われば同じ名前の操作でも引数の数から何から
変わるということがおこりえる。それはメリットでもあれば統一した意味論で
全てのクラスを語れないというデメリットでもある。
generic functionは例えばC++のコンテナでpush_backというメンバ関数の
形式と意味論が共通に約束されているとか(イテレータの++や*演算子もそうだ)、
Ruby方面でいうduck typingに近い。
だから特定のクラス系統にのみ意味を持つものなら、それ相応に特定的な動詞が
思い付かないならそれを示すプレフィクスを付けるのが一番安全。
でなきゃパッケージで区切る。
あくまでbruteにメッセージ形式を持ち込みたいなら、メッセージと対応する処理を
定義するマクロを作って、あとはメッセージをsendする関数を作ってしまうのが
いいんじゃないか。
全体で合意できるのはレシーバとなる第一引数の存在くらいしかないのだろうから。
個人的にはC++にも(最近ではJava方面も?)Generic Programmingという概念は
入っているだろうに、なぜそっちからLispにくる人はそれを理解の一助とせず
無視するのかが理解に苦しむところ。
0157デフォルトの名無しさん
2005/12/04(日) 21:48:46> 入っているだろうに、なぜそっちからLispにくる人はそれを理解の一助とせず
> 無視するのかが理解に苦しむところ。
自分もC++やJavaからLispに入ってきた人なのだった。
なぜ114のような文句垂れる人は、にしておこう。
0158デフォルトの名無しさん
2005/12/04(日) 23:46:20>だから特定のクラス系統にのみ意味を持つものなら、それ相応に特定的な動詞が
>思い付かないならそれを示すプレフィクスを付けるのが一番安全。
それじゃCに逆戻りなんだよね……名前空間の便利さを知ると、とてもじゃないけど
やってらんない。関連性の高い関数とオブジェクトはセットで管理したいですな。
LISPでも名前空間の実装無いの？
0159デフォルトの名無しさん
2005/12/05(月) 00:15:11その引用部分の直後に書いてあるけど、パッケージ。
0160デフォルトの名無しさん
2005/12/05(月) 00:18:03だから、そのためのパッケージだべさ。
0161デフォルトの名無しさん
2005/12/05(月) 00:26:14(defun hoge (&rest args) ...)
で受けて手動ディスパッチすりゃいいんじゃねーの?
処理系によっては defmethod するより typecase で分岐の方が速かったりするし。
0162デフォルトの名無しさん
2005/12/05(月) 01:03:32で、それを実装してみればいいじゃないか。
0163158
2005/12/05(月) 01:40:41なるほど。
パッケージの名前解決ってどんな感じ？（C++みたいに）引数の型の定義に近い
メソッドを検索して持ってくるの？それともやっぱりパッケージ名で修飾しないとダメ？
0164デフォルトの名無しさん
2005/12/05(月) 02:30:38>入っているだろうに、なぜそっちからLispにくる人はそれを理解の一助とせず
>無視するのかが理解に苦しむところ。
そんなの簡単。そっちも理解できないから。
そして自分の頭に既にある図面(しかも半端な)にあてはめることでしかものを理解できない・しようとしないわけさ。
0165デフォルトの名無しさん
2005/12/05(月) 02:37:52あるんだが、BOOSTとか見ると何であんな複雑怪奇なことをしてGeneric Programmingに
取り組んでいるのか理解に苦しむ。素直にLisp/Scheme使えばいいのに・・・
アレは理解できない・というよりしたくない。エラーメッセージもわけわからんし、
修正→コンパイル→デバッグのサイクルに費やす時間が異常に長いしで不毛なことこの上なし。
0166デフォルトの名無しさん
2005/12/05(月) 03:40:22確かに boost の lambda は笑った。すべてをコンパイル時にやろうという
C++ の執念は凄いが、実用性は？だよね。
0167デフォルトの名無しさん
2005/12/05(月) 10:04:030168デフォルトの名無しさん
2005/12/05(月) 11:55:300169デフォルトの名無しさん
2005/12/05(月) 16:38:190170デフォルトの名無しさん
2005/12/05(月) 17:40:020171114
2005/12/05(月) 21:41:42>>だから特定のクラス系統にのみ意味を持つものなら、それ相応に特定的な動詞が
>>思い付かないならそれを示すプレフィクスを付けるのが一番安全。
>>でなきゃパッケージで区切る。
だから、そうするしかないねえ、という話をすぐ上でしている。
そして、俺はそれすら 面倒 だという下らない話をしてるんだよ。
タイプ量が増えるからな。
CLOSのモデルに合わせてプログラムを書けないなんて話は
俺の最初の書き込み以降、誰一人していない。
逆にgeneric functionも必要/有用だと認める意見が多かった気がするがな。
ただ、多重ディスパッチを必要としないプログラムを書いてる限り、それは
タイプ量と考慮すべきことを増やすだけで、それが他のOO言語に慣れた人間には
納得のいくトレードオフに思えないことは結構多いんじゃないか？
そもそも、Gaucheに無い制限を持つCLOSの話題から始まったことも忘れるなよ。
RubyやPythonから今のオブジェクトシステムを除いて、
CLOSだけを加えたらどうなるか考えてみろよ。
俺の普段の仕事には多重ディスパッチなんかより、
Rubyみたいな属性アクセスの抽象化と実際のアクセスを
少ないタイプ量で(マイ言語の世界も構築せずに)できる機能のほうが全然重要だったりする。
っつーか、たまにそういう要求に出会ったら、それこそ
自分でディスパッチの仕組みを作ったっていいんじゃないかと思ったりもする。
そういう場合、対象の集合が持つ性質は多分、かなり予期・コントロールできると想像する。
つまり、その集合、その問題に特化したディスパッチシステムを作るのは容易な可能性が高い。
だけど、無引数のget-hogeを定義したあとで、なんらかのキーを引数に要求する
get-hogeを継承関係にすらない異クラスに追加したくならないか、
なんて予期できないんだよ。
0172114
2005/12/05(月) 21:42:56統計的情報(?)を聞けた時点で、ほとんど満足なわけだが、156みたいなアホがいるから
反論したくなる。
メッセージ伝達モデルを欲しがる人間をあからさまに馬鹿にする態度が気に食わない。
CLOSなんて唯のライブラリでLispの本質じゃないのにさ。
Paul Grahamのエッセイを読んでみろよ。
クロージャ詰め込んだハッシュなんて、まんまメッセージのレシーバじゃないか。
0173デフォルトの名無しさん
2005/12/05(月) 21:46:02ごめんね。暇になったら必ず読むよ。
0174デフォルトの名無しさん
2005/12/05(月) 22:51:00あんまり重要じゃないところに突っ込むけどさ、Paul Grahamも、
Common Lispが、"タイプ量"的にまずいってことは認めてるし、
まぁ、欠点は欠点として認めるとして、
タイプ量をケチるなら、それなりのエディタを使うとか、
そもそもCommonLispは使わないとか、そういう方向になるんじゃ
ないのかな？
タイプ量からCLOS批判するのは少し納得がいかない希ガス。
0175デフォルトの名無しさん
2005/12/05(月) 23:55:51dispatch だけだったら CLOS なしでも大差ないだろ。
それとも optimize とかが何か違うのか。
0176デフォルトの名無しさん
2005/12/05(月) 23:59:47>>114、>>116 あたりの自分の態度を見直したほうがいいよ…。
同じ Gauche 使ってる身としては、Common な人々は心が広いなーと思た。
残念だろうけど、どっちかというとアホなのは 156 じゃなくて 114 だと思うよ…
0177デフォルトの名無しさん
2005/12/06(火) 00:28:03http://www.functionalobjects.com/resources/beyond-java.phtml
0178デフォルトの名無しさん
2005/12/06(火) 01:17:37自分のやり方が実現できないと文句言ってるだけの人だったね。
Haskellは変数を破壊的に変更できないから使い物にならん、というのと同レベル。
ついでにいうとgeneric functionのlambda listが合同なのはgeneric function
っつーくらいだから本来当たり前の話で、
Tiny CLOSでlambda listが違っても使えるってのの方が単なる余録。
0179158
2005/12/06(火) 02:26:00いくらパッケージで分割できるつうても、自動的に名前解決してくれないんだったら
プリフィックスと同じで不便なことには変わりないなぁ。
というか、おまいら名前空間・generic programming・メッセージングその他もろもろを
ごっちゃにしとらんか？傍目からは疑似問題起こしとるような気がしてならんが……
0180デフォルトの名無しさん
2005/12/06(火) 03:02:09156を理解せずにかろうじて食いつけるところだけ食いついてみた
という感じだけど、元々理解できてないから完全に見当外れ。
だからコメントもつかない、つまり相手にされてない。
0181デフォルトの名無しさん
2005/12/06(火) 05:35:510182デフォルトの名無しさん
2005/12/06(火) 05:59:260183デフォルトの名無しさん
2005/12/06(火) 06:48:14ttp://user.ecc.u-tokyo.ac.jp/~t50473/onlispjhtml/packages.html
検索くらいしる。
・Lispの型は値に、C++の型は変数名にくっついている
・CLOSのgenricは実行時、C++のgenericはコンパイル時にメソッドが選ばれる
・CLOSのmethodはオブジェクトに属さない
この辺ちゃんと理解してる？
0184デフォルトの名無しさん
2005/12/06(火) 08:14:38レシーバを規定する method は鎖で繋がれたペットみたいなイメージ。
0185デフォルトの名無しさん
2005/12/06(火) 20:26:20使ってたのを思い出して、ググってみたら今でもあるんですね。
ttp://www.yuasa.kuis.kyoto-u.ac.jp/~komiya/tus_intro.html
UNIX版を落として使ってみたら、ﾃﾗﾅﾂｶｽ
ちょっと遅いけど、いろんなプラットフォームで動くし、
エディタついてるし、お勉強用には良いかも。
tusとかmtusとか、cmtusとかstusとか作れるみたいだけど
違いはなんだろ？
0186デフォルトの名無しさん
2005/12/08(木) 10:57:59しれないという話。
http://www.rubyist.net/~matz/20051205.html#p02
0187デフォルトの名無しさん
2005/12/08(木) 11:13:420188デフォルトの名無しさん
2005/12/08(木) 11:14:31Lisperから見ると、良い点の大半を捨てたように見えるんだけどな。
0189デフォルトの名無しさん
2005/12/08(木) 11:38:16かけ離れすぎてて無理があると思う。
Lispにない利点もあり、Lisperにも(どの言語にもあるような機能の範囲では)
ストレス少ないので、
more acceptable (かつ、いくつかの面ではmore comfortable) than Lisp
ではあると思う。
関数型的な利用にはあんまり向かないよね。
思考の枠組みとしてはLispより狭いけど、まあそれで十分なことも多い。
0190デフォルトの名無しさん
2005/12/08(木) 23:24:14…と思ったけどmatz氏が良い指摘をしてるね。
一般人(悪い意味じゃないよ)ってのは抽象化になれてないんだろうな。
0191デフォルトの名無しさん
2005/12/09(金) 06:10:21アルゴリズムの抽象化なんかは関数型言語をやったりLispを使い慣れたりしないと、
あまり理解できないか、少しわかっても難しく感じるだけで
有り難みやかっこよさを感じるところまでいかないと思う。
せいぜい高階関数いいね、止まりじゃないかな。
0192デフォルトの名無しさん
2005/12/09(金) 06:14:09先の見えない世界が延々と続いているような恐ろしいものを想像してる人が
たまにいるが、それは違うと思う。
0193デフォルトの名無しさん
2005/12/09(金) 06:53:070194デフォルトの名無しさん
2005/12/09(金) 10:11:000195デフォルトの名無しさん
2005/12/09(金) 10:25:020196デフォルトの名無しさん
2005/12/09(金) 23:04:24Lisperにとっても誰にとっても抽象的なものってのは
難しいものだと思う。
だけど、一旦分かると格好良い！とか美しい！
と思うのがLisperや数学好きな奴だな。
0197デフォルトの名無しさん
2005/12/09(金) 23:23:30少なくて楽なんだよね。Perlなんて一見楽そうだけど、覚えておかなきゃいけないこと、
注意しなくちゃいけないことが不規則に多すぎて神経衰弱しちゃう。
0198デフォルトの名無しさん
2005/12/10(土) 00:45:140199デフォルトの名無しさん
2005/12/10(土) 14:11:550200デフォルトの名無しさん
2005/12/11(日) 06:03:27…
以下、何事もなかったよーにLispの話題ドゾー↓
0201デフォルトの名無しさん
2005/12/11(日) 14:59:41(foo)
r)
を楽に書けるマクロってあったりする？
0202デフォルトの名無しさん
2005/12/11(日) 15:05:220203デフォルトの名無しさん
2005/12/11(日) 15:12:450204デフォルトの名無しさん
2005/12/11(日) 15:22:330205デフォルトの名無しさん
2005/12/11(日) 19:39:50現状が素晴らしく思えてきます。
0206デフォルトの名無しさん
2005/12/12(月) 03:11:35SBCL on Windows
進展があったみたい
0207デフォルトの名無しさん
2005/12/13(火) 00:33:56で、どうやって動かすんだい？
C:\sbcl-win32-0.9.6-binaries>sbcl
fatal error encountered in SBCL pid 4032:
can't find core file
coreファイルあるのに読んでくれないや。
と思ったら
環境変数SBCL_HOMEを設定したら動いたよ
set SBCL_HOME=C:\sbcl-win32-0.9.6-binaries\
C:\sbcl-win32-0.9.6-binaries>sbcl
This is SBCL 0.9.6, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>;.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
os_map: 3, 0x1000, 01000000, 0x1000.
os_map: 3, 0x2000, 05000000, 0x1000.
os_map: 3, 0x3000, 09000000, 0x17ce000.
Your Kitten of Death awaits!
*
これでいいのかい？
0208デフォルトの名無しさん
2005/12/13(火) 01:00:27sbcl --core sbcl.coreで逝けたよ
すげー
ちょー速い
こりゃネイティブコンパイルだね
Windowsでこんだけ速いのってフリーじゃなくね？
0209デフォルトの名無しさん
2005/12/13(火) 23:33:33以前（ずっと昔）このスレで速さ比べが載ってて
CLISPのコンパイル後より
Petie Chez Scheme のVMが速いとあったが
SBCL ON Windows には足元にも及ばないぞ。
シェル上で動いてる、って事はVMじゃないのか？
0210デフォルトの名無しさん
2005/12/14(水) 01:01:40JITじゃね？ と、いいかげんなことを言ってみるテスト。
0211デフォルトの名無しさん
2005/12/14(水) 01:14:490212デフォルトの名無しさん
2005/12/14(水) 05:47:04http://www.sbcl.org/manual/Compiler-only-Implementation.html
0213デフォルトの名無しさん
2005/12/14(水) 06:37:06今までは実行せずに「リスト遊び」と「SICP」を読んでただけ。
で、「コマンドライン引数に指定されたファイルを印字する」スクリプト
書いてみた。(関数名変かもしれんが気にしないでくれ)
(define ret_data (lambda (fname)
(port->string-list (open-input-file fname))))
(define print_forlist
(lambda (x)
(if (not (null? x))
(and
(print (car x))
(print_forlist (cdr x))
))))
(define main
(lambda (env)
(if (not (null? (cdr env)))
(and
(print_forlist (ret_data (car (cdr env))))
(main (cdr env))
))))
gauche使いな偉い人達はどういう風に書くの?
0214デフォルトの名無しさん
2005/12/14(水) 07:00:41(for-each (lambda (f)
(call-with-input-file f
(lambda (p)
(display (port->string p)))))
(cdr args))
0)
かな？
0215デフォルトの名無しさん
2005/12/14(水) 07:02:51(define (print-file f) (print (file->string f)))
(define (main args) (for-each print-file args))
0216213
2005/12/14(水) 07:15:55す すげー
displayとかfile.utilとか気になりまくりだ
さっそく調べてみよう。ありがとう。
0217215
2005/12/14(水) 08:09:52これは
(define (main args) (for-each print-file (cdr args)))
か。すまそ。
0218デフォルトの名無しさん
2005/12/14(水) 08:28:560219デフォルトの名無しさん
2005/12/14(水) 09:23:29(define (main args)
(for-each (cut file-filter copy-port :input <>)
(cdr args))
0)
0220デフォルトの名無しさん
2005/12/14(水) 14:46:080221デフォルトの名無しさん
2005/12/14(水) 16:48:560222デフォルトの名無しさん
2005/12/14(水) 17:30:090223デフォルトの名無しさん
2005/12/14(水) 18:10:46こんなの決まってたんだね。
ttp://members.at.infoseek.co.jp/zzyyb/srfi/ja/srfi-22/srfi-22.html
#!は先頭行以外では別の意味に使っていいのかな。
0224デフォルトの名無しさん
2005/12/16(金) 01:09:16叩き台をGaucheに含めると書いてあったと思うのですが、該当するコードが含まれて
いるのはどのリリースですか？CVS HEADも覗いているのですが見当たらないので
ご存知の方いましたら教えて下さい。
0225デフォルトの名無しさん
2005/12/16(金) 01:15:59Gauche-devel-jp ML あたりで聞くほうが良いと思う。
0226デフォルトの名無しさん
2005/12/22(木) 08:27:26これが 300 系統で最初の正式リリースってことになるのかな。
win 版だと msvcr71.dll が必要になるそうなので注意。
http://download.plt-scheme.org/drscheme/
0227& ◆Q5hc3/kNG.
2005/12/23(金) 07:41:44DrScheme(PLT)のエディタで書いて、
Petite Chez で動かすのが一番かな?
･･･OSがWindowsですから。
0228デフォルトの名無しさん
2005/12/23(金) 08:32:57(define a '(1 + 2))
として、
((car (cdr a)) 1 2)
として、3 が出力されるようにしたいのですが、(quote +) を
primitive の＋に変換する方法はありますか？
little schemer のソースでは、全部 cond でスイッチケースしてた
んだけど・・・
0229デフォルトの名無しさん
2005/12/23(金) 08:49:540231デフォルトの名無しさん
2005/12/23(金) 20:07:33実用面ではどんな風に応用されてるのかさぱーりわからん
0232デフォルトの名無しさん
2005/12/23(金) 20:29:380233デフォルトの名無しさん
2005/12/23(金) 21:42:59たまには意味あるんじゃないか？
名前空間を汚さずにラムダ式だけで計算できるから
実例は知らないけど…
0234デフォルトの名無しさん
2005/12/23(金) 22:51:17for-eachとかcall-with-*とかに再帰的な手続きを渡せたりとか。
0235デフォルトの名無しさん
2005/12/24(土) 04:58:280236デフォルトの名無しさん
2005/12/24(土) 12:45:41コンパイラ作る時に使うとか
0237デフォルトの名無しさん
2005/12/25(日) 02:45:47ちょｗｗｗｗｗ LISPｗｗｗｗｗ
0238デフォルトの名無しさん
2005/12/25(日) 03:19:10何を表現してるのかさっぱりわからんｗｗｗｗｗ
0239デフォルトの名無しさん
2005/12/25(日) 12:52:44ここの2.6に書いてある、ダイナミックヒープ中の一時的なビットベクタを使う
とはどういう意味なんでしょうか。
どこがマークされたか保存しておいて、スイープの時に照し合わせるんでしょうか?
だとしたら滅茶苦茶時間かかると思うんですけど。
リストにネイティブなポインタを使うと下位2ビットしか使えないんですが
そこをGCのフラグに使うのが一般的なんでしょうか?
それともポインタの代わりに配列のインデックスを使った方がいいんでしょうか?
これのやり方がいまいち良く分かりません。
0240デフォルトの名無しさん
2005/12/25(日) 13:12:05dirtyになるから、incremental gcとかが面倒にならんかな。
まあ、write barrierの実装方法にもよるし、ケースバイケースだね。
0241デフォルトの名無しさん
2005/12/25(日) 21:45:08とりあえずBASICは前科者
あとFORTRANは怒らせないほうがいい
0242デフォルトの名無しさん
2005/12/25(日) 22:11:06src/store.c読め。
markBitという変数がビットベクタ。
わざわざLispMeのソース持ってきて調べちゃったじゃないか。
ちなみにセルはインデックスになっていた。
これのメリットはフラグビットが多く取れる事、永続化する際に
アドレス変換しなくて良い(そのままfwrite/fread可)といった点。
0243デフォルトの名無しさん
2005/12/25(日) 23:22:53読まずに質問してすいません。
マークビットにインデックスで直接アクセスするので、余計な時間はかからないんですね。
フラグビットが多く取れることやダンプが簡単なことはとっても魅力的なんですけど
メモリの無駄が多いことと、いっぱいになったときに reallocするのが重そうなので
なんだかためらってしまいます。
reallocしない方法も考えられますが、生きてるセルの間が大きくなったりしたら
困る気がします。
0244デフォルトの名無しさん
2005/12/25(日) 23:30:150245デフォルトの名無しさん
2005/12/25(日) 23:43:29それは Palmの場合ですよね。
LispMeではヒープのサイズは固定ですが、一般にはヒープサイズを可変にした方が
いいと思ったので。
言葉足らずですいません。
0246デフォルトの名無しさん
2005/12/30(金) 06:23:00http://www.kohgakusha.co.jp/books/detail/4-7775-1180-4
0247デフォルトの名無しさん
2005/12/30(金) 13:45:12あってない）人の入門向けってとこかな。高校生くらいには丁度いいのかも。
まぁ、せっかくここまで揃えた Lisp 本コレクションが欠けるのも悔しいので
買ってしまうんだけどね…。
0248デフォルトの名無しさん
2005/12/30(金) 18:50:02「計算機科学の方面では『λ算法』とかいうものがあると聞きますが、
詳しいことは筆者もよく知りません」
という記述はどうかと思いました。
0249デフォルトの名無しさん
2005/12/30(金) 18:57:45計算モデルを知らなくても使えるからいいじゃん。
無意味にしったかぶりするよりは好印象。
0250デフォルトの名無しさん
2005/12/30(金) 22:46:190251デフォルトの名無しさん
2005/12/31(土) 01:51:57あそこパソ通時代のノリそのままの半可通本が多いわけだし
0252デフォルトの名無しさん
2005/12/31(土) 09:59:50■ このスレッドは過去ログ倉庫に格納されています