1001コメント302KB

Lisp Scheme Part27

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2009/07/27(月) 10:15:31

※ ここはCommon Lisp、SchemeをはじめとするLisp族全般のスレです ※

■過去スレ
　Part26: ttp://pc12.2ch.net/test/read.cgi/tech/1240567959/
　Part25: ttp://pc12.2ch.net/test/read.cgi/tech/1231856193/
　Part24: ttp://pc11.2ch.net/test/read.cgi/tech/1224939205/
　Part23: ttp://pc11.2ch.net/test/read.cgi/tech/1215875388/
　Part22: ttp://pc11.2ch.net/test/read.cgi/tech/1211381920/
　Part21: ttp://pc11.2ch.net/test/read.cgi/tech/1207300697/
　Part20: ttp://pc11.2ch.net/test/read.cgi/tech/1205021786/
　Part19: ttp://pc11.2ch.net/test/read.cgi/tech/1200237296/
　Part18: ttp://pc11.2ch.net/test/read.cgi/tech/1186922295/
　Part17: ttp://pc11.2ch.net/test/read.cgi/tech/1177065699/
　Part16: ttp://pc11.2ch.net/test/read.cgi/tech/1172404795/
　Part15: ttp://pc11.2ch.net/test/read.cgi/tech/1151025773/
　Part14: ttp://pc11.2ch.net/test/read.cgi/tech/1132275726/
　Part13: ttp://pc11.2ch.net/test/read.cgi/tech/1115901841/
　Part12: ttp://pc11.2ch.net/test/read.cgi/tech/1100229366/
　Part11: ttp://pc11.2ch.net/test/read.cgi/tech/1091456033/
　Part10: ttp://pc11.2ch.net/test/read.cgi/tech/1075630259/
　Part09: ttp://pc11.2ch.net/test/read.cgi/tech/1069594582/
　Part08: ttp://pc5.2ch.net/tech/kako/1058/10582/1058263391.html
　Part07: ttp://pc5.2ch.net/tech/kako/1042/10421/1042167213.html
　Part06: ttp://pc3.2ch.net/tech/kako/1031/10315/1031560687.html
　Part05: ttp://pc3.2ch.net/tech/kako/1023/10230/1023091882.html
　Part04: ttp://pc.2ch.net/tech/kako/1016/10162/1016211619.html
　Part03: ttp://pc.2ch.net/tech/kako/1008/10082/1008220265.html
　Part02: ttp://pc.2ch.net/tech/kako/1002/10025/1002584344.html
　Part01: ttp://piza2.2ch.net/tech/kako/987/987169286.html

■テンプレート置き場
　ttp://wiki.fdiary.net/lisp/ (id:guest pass:cl)

0669デフォルトの名無しさん

2009/09/02(水) 18:22:34

不覚にも（ｒｙ

0670デフォルトの名無しさん

2009/09/02(水) 18:45:49

おもしれーw

0671デフォルトの名無しさん

2009/09/02(水) 19:11:02

>>661
近日レビュー開始予定らしいから 11～12月くらいかね。
ttp://twitter.com/hisashim/status/3624762770

0672デフォルトの名無しさん

2009/09/02(水) 19:45:29

最後の一言までは平静だったのに、ちくしょう

0673デフォルトの名無しさん

2009/09/02(水) 20:56:17

もうややこしくなりそうなことはイヤ。

0674デフォルトの名無しさん

2009/09/02(水) 21:04:36

>>673

> '()

0675デフォルトの名無しさん

2009/09/03(木) 03:19:00

失言だったなぁ。まぁ許してくださいな。
考えを外に出していかないとうまく考えられないのよ。
そういう風に思ってます、で。

0676デフォルトの名無しさん

2009/09/03(木) 13:22:10

>>668
ばかー！

僕の珈琲返せ、あと鼻に抜けて痛いの！

0677デフォルトの名無しさん

2009/09/03(木) 20:33:03

何が面白いのか説明してほしい

0678デフォルトの名無しさん

2009/09/03(木) 20:35:49

おれ子供ができたら「らむだ」って名付けるんだ。

0679デフォルトの名無しさん

2009/09/03(木) 20:46:31

ちゃんと名前をつけてあげて

0680デフォルトの名無しさん

2009/09/03(木) 20:52:22

Y子萌え

0681デフォルトの名無しさん

2009/09/03(木) 21:20:06

R6RS Benchmarks
ttp://www.ccs.neu.edu/home/will/Larceny/benchmarks2009.html

ikarus 速いな

0682ひげぽん ◆Ngzcp/NZpA

2009/09/03(木) 21:47:44

>>681
コンパイラ組は、やはり速いですね。
Mosh はとりあえず遅いので次回リリースはさらなる高速化を目指します。
JIT 実装できるかな。

0683デフォルトの名無しさん

2009/09/03(木) 22:05:27

>>677
大きな流れがみえるでしょ。

0684デフォルトの名無しさん

2009/09/03(木) 23:48:51

>>682
次のリリースをじっと待ちますっ！

0685デフォルトの名無しさん

2009/09/04(金) 01:25:00

>>682
interpreter 部門では Mosh ってどうなの？
Ypsilon のベンチマーク結果を見ると Gauche と Ypsilon はかなり速いみたいだ
プロジェクトのページに比較が載ってると面白いかも

0686デフォルトの名無しさん

2009/09/04(金) 01:40:06

>>678
娘ができたら「にる」って名付けるんだ。

0687デフォルトの名無しさん

2009/09/04(金) 02:11:35

PLTはJITだったと思うけど速いなぁ

0688デフォルトの名無しさん

2009/09/04(金) 02:56:04

ガウチェとは俺のことかと Gauche 言い

0689デフォルトの名無しさん

2009/09/04(金) 04:03:51

schemeなんかそんなに速くしてなにが楽しいんだか
みんながCLに全力そそいでれば今ごろは・・

0690デフォルトの名無しさん

2009/09/04(金) 04:50:06

Cの次ぐらいに早くなってるはずだよな

0691デフォルトの名無しさん

2009/09/04(金) 05:52:08

CL厨涙目ｗ

0692デフォルトの名無しさん

2009/09/04(金) 07:41:29

Schemeだと一人でやれるからじゃね？
スピードの前に非互換なのをどうにかしたり、
ライブラリを整備したりして欲しい>scheme

0693デフォルトの名無しさん

2009/09/04(金) 08:27:54

もう委員会に認定なしに新規に処理系を作るのを禁止しちゃえよ
ユーザー数はそう少なくないのに個々の労力が分散されて本当に勿体ないと思うわ
CPANを持つPerlみたいに集中できれば、それなりにライブラリも整備されてくるのにね

0694デフォルトの名無しさん

2009/09/04(金) 08:37:20

srfiを充実させていくしかないんじゃね

0695デフォルトの名無しさん

2009/09/04(金) 08:59:49

わけのわからん個人製なんかより
MSとかGoogleあたりに作ってほしい

0696デフォルトの名無しさん

2009/09/04(金) 09:06:19

競争相手に労力の無駄遣いをさせるのも立派な戦略じゃないか
まあ、なんのために競争してるのかという意味ではおかしいかもしれない

0697デフォルトの名無しさん

2009/09/04(金) 09:36:18

>>686
中国人の知り合いに「てい」(T)さんってのがいる

0698デフォルトの名無しさん

2009/09/04(金) 11:23:31

てゐ

0699デフォルトの名無しさん

2009/09/04(金) 11:51:52

>>693
問題点は処理系が複数あることではなく、
それらに充分な互換性がないこと。
Perl だって Ruby だって処理系は複数ある。
Scheme でそれがうまくいってなかったのは、
規格内だけで出来ることが少なかったからだ。
そもそも R5RS ではモジュール化についての決まってなかった。
R6RS が出来たことでそれなりにポータブルなコードが書けるようになったし、
ライブラリを作ることもできるようになったわけだ。
とは言え、 R6RS 自体に批判的な見解も多いので、
これでリソースが集約されるってわけにもいかんだろうけどな。

0700デフォルトの名無しさん

2009/09/04(金) 12:01:08

以前は実装依存の部分や独自拡張が多かっただけだけど、
今はR6RS/ERR5RSと規格まで分離してしまったな。
相容れない部分、何とかうまく決着して欲しいものだ。

0701デフォルトの名無しさん

2009/09/04(金) 12:22:10

(lambda (kodomo)
(cond
((eq kodomo female) nil)
(else t)))

0702デフォルトの名無しさん

2009/09/04(金) 12:28:47

割と簡単に作れちゃうから
協力しないで自分で好き勝手に作っちゃうんだろうな

0703デフォルトの名無しさん

2009/09/04(金) 12:48:01

数多の方言がcommon lispへまとまっていく過程から
何も学んでないな、schemerたちは

0704デフォルトの名無しさん

2009/09/04(金) 13:11:44

Common Lispはずっと固まったままだな。
sequenceをCLOS的に書き直して欲しいが…

0705デフォルトの名無しさん

2009/09/04(金) 14:54:53

>>704
それは「枯れた」と言うんだ
あまりコネくり回すとperlのように悲惨な状態に陥るぞ

0706デフォルトの名無しさん

2009/09/04(金) 16:46:34

>>27

古い話で恐縮。べき集合が面白かったんで素朴集合論の勉強してる。
2^ℵ0　とか無限集合をSchemeで疑似的に扱えないものだろうか？
コンピューターの有限集合に慣れきっているんで選択公理のどこが
問題なのかピンとこない。コンピューターが実無限を扱えると面白い。

0707デフォルトの名無しさん

2009/09/04(金) 16:51:16

>>706
色々と直観に反する定理が出て来たりする。例えば、バナッハ・タルスキーのパラドックス：

一つの球体を粉々に砕いて、同じ大きさの球体二つを作ることができる

とか

0708デフォルトの名無しさん

2009/09/04(金) 17:06:25

>>706
証明系、数式処理系が扱ってる。> 無限

0709デフォルトの名無しさん

2009/09/04(金) 17:15:32

>>708

素のSchemeじゃ無理かな？
ℵ0+ℵ0=ℵ0 とか数式処理のようにパターンマッチングで
与えることはできると思うんだ。
どうしてそれでいいんだ？ってのをSchemeで実験数学みたいにやってみたいんだ。

0710デフォルトの名無しさん

2009/09/04(金) 17:23:04

>>706
論理式として閉じてる構造作れば良いんでない？
ただ実態を作る場合、それが本当に妥当かどうかは分からんが。
ハスケルで無かったっけ？そんなの。

数学ってあくまで実際のモデルを"参考"にして抽象的構造作ってるから、
その"参考"から創られる構造から演繹されたものを実際の世界(コンピュータだったらデータ)に還元しても、それが直感的に妥当だとは限らんよ？
>>707の例みたいになるし。混ぜるな危険。
まあ応用数学みたいにおいしいとこだけ啄むのも良いけど。

0711デフォルトの名無しさん

2009/09/04(金) 17:25:34

Exact Real Numberの非標準解析版作ればいい。

0712デフォルトの名無しさん

2009/09/04(金) 17:25:38

>>710

ありがとう。考えてみるよ。

0713デフォルトの名無しさん

2009/09/04(金) 17:59:13

>>706
「選択公理と数学」遊星社

0714デフォルトの名無しさん

2009/09/04(金) 18:01:29

>>713

それ志賀先生の３０講シリーズでも紹介さてた。
有名な本なんですね。

0715デフォルトの名無しさん

2009/09/04(金) 19:14:27

>>693
委員会の作る言語はクソという歴史的必然性があってだな、

ANSI C、Ada、Commo (ピー、ピー、ピー)

0716デフォルトの名無しさん

2009/09/04(金) 19:53:31

適度に分裂して適度に収束できた系が生き残るのだ
それが人為的か否かに関わらず

0717デフォルトの名無しさん

2009/09/04(金) 21:25:55

Haskellも委員会言語だな

0718デフォルトの名無しさん

2009/09/04(金) 21:44:04

ALGOL60も委員会言語だったような

0719デフォルトの名無しさん

2009/09/04(金) 21:51:11

どちらもたしかにクソ言語だな

0720デフォルトの名無しさん

2009/09/04(金) 21:53:57

Schemeって黒田さんも言っているようにALGOL系の
影響を受けてるんでしょ。

0721デフォルトの名無しさん

2009/09/04(金) 22:05:09

歴史が古いと委員会言語に移行してない？初期の C って参考にしたものがあるにせよ
個人が勝手に作った物だし。今はそうでない言語でも、そのうち ANSI ** なんてこと
になってしまうかもしれない。別に ANSI ではなく ISO でも。

委員会言語って、良い所もあるけど「専門家」に引っ掻き回されてグチャグチャにな
ったソフトウェアに近い印象がある（個人的には）。

0722デフォルトの名無しさん

2009/09/04(金) 22:09:01

Clojureってカッコがなくてキモイと思った。

(def fact
　(fn [n]
　　(cond
　　　(= n 1) 1
　　　:else (* n (fact (- n 1))))))

0723デフォルトの名無しさん

2009/09/04(金) 23:18:59

>>722
arcに似てるね。
defとかfnとか。

0724デフォルトの名無しさん

2009/09/04(金) 23:30:58

ClojureでＹコンビネーター

(def Y
　(fn [f]
　　((fn [proc]
　　　(f (fn [arg] ((proc proc) arg))))
　　(fn [proc]
　　　(f (fn [arg] ((proc proc) arg)))))))

(def fact0
　(fn [f]
　　(fn [n]
　　　(if (zero? n)
　　　　1
　　　　(* n (f (- n 1)))))))

((Y fact0) 5)

0725デフォルトの名無しさん

2009/09/04(金) 23:39:11

>>723
どことなく似てる。まだ詳しいことはわからないけど。

0726デフォルトの名無しさん

2009/09/04(金) 23:54:00

Clojureは末尾再帰の最適化がないから、Schemerはちょっと脳を切り替えないとね

0727デフォルトの名無しさん

2009/09/05(土) 00:04:23

ランタイムがJVMというのはどうなんだろう。
OracleはJavaをどう扱うんだろう。

Scala共々気になる。

0728デフォルトの名無しさん

2009/09/05(土) 00:06:39

>>726
そうかも。ただ、clj-processingとかでProce55ingを利用してグラフィックを扱えるんで重宝しそうな予感。
こういう実用的な話はテキストに載ってないけど。

0729デフォルトの名無しさん

2009/09/05(土) 01:44:35

>>707
関係ないんだけれど、関数型言語に（有用な）測度入れたりできる？

なんというか、測れるもの入れたほうがわかりやすくなりそうだし、
似ているけど、同値関係がないから違うものと判別されているものを
まとめられたら話が簡単にできると思うんだわ。

0730デフォルトの名無しさん

2009/09/05(土) 02:26:22

言語に測度ってなんだよ
S式上に定義された関数を積分とかするのか

0731デフォルトの名無しさん

2009/09/05(土) 02:43:28

>>730
離散な集合でも可測空間は作れるし、別にルベーグ積分に限っているわけじゃない。
たとえば、言語における語と関数を要素とする集合をΩとして、
文法規則な情報も入ったσ集合体が作れたら作って、相互にプログラム変換可能を
意味するような測度が入れられたらいいなぁと。
でも、現実的じゃないか。

0732デフォルトの名無しさん

2009/09/05(土) 03:26:02

測度というからには完全加法性を使いたいんだろ？
そんなもんが言語の何に対応するんだ。
仮にできたとしてゲーデル関数のへんてこな例が一つできるだけじゃないの。

0733デフォルトの名無しさん

2009/09/05(土) 04:14:44

>>700
ttp://www.scheme-reports.org/

興味があるならどうぞ。c.l.sとか色々な場所に流れてたから、
知ってるかもしれないけど。

0734デフォルトの名無しさん

2009/09/05(土) 04:29:28

ポールたんの Arc 言語を一見してみた感想：
「Common Lisp に Macro 書くだけで良くね？」

0735デフォルトの名無しさん

2009/09/05(土) 05:25:40

数学板か情報板行けばいいのに。その方が詳しい人にコメントもらえると思うよ。

0736デフォルトの名無しさん

2009/09/05(土) 05:51:07

>>732
何気にゲーデル関数が可測関数だと読めるようなことを。
それが狙い。へんてこな例じゃないものがあるかもしれないじゃないの。

0737デフォルトの名無しさん

2009/09/05(土) 05:53:17

大当たり。

0738デフォルトの名無しさん

2009/09/05(土) 06:12:44

>>735
実は、何気にこのスレが最高レベルだよ。

0739デフォルトの名無しさん

2009/09/05(土) 06:19:20

Lisp と Scheme を別々のスレに分ければ良かったものの、
一括りにしてしまった為、濃い人間の密度は高くなった。

0740デフォルトの名無しさん

2009/09/05(土) 09:43:01

>>715
言語仕様のコロコロ変わるオレオレ言語よりマシだと思うがのぅ。。

0741デフォルトの名無しさん

2009/09/05(土) 10:14:59

Common Lisp は専用スレあるよ

0742デフォルトの名無しさん

2009/09/05(土) 12:25:28

LOL買ったけど避けるべき言語は具体的に何かって書いてない～

0743デフォルトの名無しさん

2009/09/05(土) 12:28:53

Lisp以外の全てと言いかねない勢いだったような

0744デフォルトの名無しさん

2009/09/05(土) 12:42:35

まあ確かにLispより強力なマクロを持った言語って今のところないからな

0745デフォルトの名無しさん

2009/09/05(土) 13:43:57

>>740
Rubyの事ですか？

0746デフォルトの名無しさん

2009/09/05(土) 14:31:28

>>745
どう考えてもD

0747デフォルトの名無しさん

2009/09/05(土) 14:59:28

せっかくぼかしてあるものを具体化しようとする行為は野暮だな

0748デフォルトの名無しさん

2009/09/05(土) 15:26:41

python 2.* ディスんのかてめー

0749デフォルトの名無しさん

2009/09/05(土) 16:39:43

this？pythonってselfだろ

0750デフォルトの名無しさん

2009/09/05(土) 18:49:40

別にぼかしてないと思うが
「Lispのマクロシステムを持たない言語」と明言してるから
Lisp以外の全ての言語だよ

0751デフォルトの名無しさん

2009/09/05(土) 18:53:23

M4てどうなの？
よく知らないけど

0752デフォルトの名無しさん

2009/09/05(土) 19:01:20

Perl が学ぶべき言語なのがいまひとつ納得できないんだけど何を読むと悟りが開けるんだろう

0753デフォルトの名無しさん

2009/09/05(土) 19:11:47

CならK&Rという王道に従うならラクダ本ではないかと。

0754デフォルトの名無しさん

2009/09/05(土) 19:18:52

まぁ、Gaucheを使ってるならPerlとの差はCPANの恩恵なんじゃないか。
つまりライブラリーを漁ってみるべきかと。

0755デフォルトの名無しさん

2009/09/05(土) 21:28:30

>>752
あれは皮肉なんじゃない？ダグホイト性格悪い。
Haskellもケチョンケチョンだし、HOPの人たちもよく翻訳したよな。心広い。

0756デフォルトの名無しさん

2009/09/05(土) 21:40:17

Lispは速いとか言ってるけど結局、SBCLがshootoutで
別にいい成績じゃないからなあ
あそこで説得力がなくなった

0757デフォルトの名無しさん

2009/09/05(土) 21:42:43

SBCLが糞という事実が発覚しただけでは

0758デフォルトの名無しさん

2009/09/05(土) 21:46:37

おまえ、どんだけ心狭いんだよ…… >>755

0759デフォルトの名無しさん

2009/09/05(土) 21:48:06

>>757
SBCLといえば、Lispの一番使われてる環境だし、
作者のホイトもSBCLと親戚のCMUCL使ってるし

0760デフォルトの名無しさん

2009/09/05(土) 21:58:06

Perl の懐の深さはある意味で Lisp を越えてるよ。
構文のカスタマイズもかなり出来るし。
しかし、色々な形に派生しながらも Lisp が Lisp なのは結局のところ「S式」につきる。
Perl は何でもアリだけど、「これが Perl」って言えるような芯に欠けると思うんだよな。
Perl が Perl であるためにはテストが何パーセント通っただとかいった話になるだろうけど、
Lisp は Lisp らしければ Lisp だ。

0761デフォルトの名無しさん

2009/09/05(土) 22:03:58

なんでもありなのは、Lispの方だろ
Perlのカスタマイズなんて、Lispのマクロと比べたら屁みたいなもんじゃん

0762デフォルトの名無しさん

2009/09/05(土) 22:06:37

Lispの括弧なくすマクロあったよね

0763デフォルトの名無しさん

2009/09/05(土) 22:11:33

括弧なしオフサイドルール採用のLispってないの？

0764デフォルトの名無しさん

2009/09/05(土) 22:16:16

>>763
直接の答えではないけど、見つかりにくい理由なら

http://practical-scheme.net/wiliki/wiliki.cgi?Lisp%3AS%E5%BC%8F%E3%81%AE%E7%90%86%E7%94%B1

の「ならインデントでも良くね? 」が参考になる。

0765デフォルトの名無しさん

2009/09/05(土) 22:16:40

ttp://www.chino-js.com/tech/srfi/srfi-49/srfi-49.html

0766デフォルトの名無しさん

2009/09/05(土) 22:31:45

Common Lisp といえばGCL(以前のKCL)を思い浮かべる
私は古いのでしょうか？

0767デフォルトの名無しさん

2009/09/05(土) 22:43:12

お前のことなんかどうでもいい。自己紹介ならVIPでやれ。

0768デフォルトの名無しさん

2009/09/05(土) 22:44:02

>>764-765
いかにも厨っぽい質問に答えてくれてありがとう

>>765のS式とI式混在の記法は見やすくて良いけど、
構文木と記法の対応という安心感を失ってまで
導入するほどのものではないと初心者の自分でさえ思った

■ このスレッドは過去ログ倉庫に格納されています