Lisp Scheme Part23

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

□過去スレ□
Part22: ttp://pc11.2ch.net/test/read.cgi/tech/1211381920/
Part21: ttp://pc11.2ch.net/test/read.html/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://pc10.2ch.net/test/read.cgi/tech/1151025773/
Part14: ttp://pc8.2ch.net/test/read.cgi/tech/1132275726/
Part13: ttp://pc8.2ch.net/test/read.cgi/tech/1115901841/
Part12: ttp://pc8.2ch.net/test/read.cgi/tech/1100229366/
Part11: ttp://pc5.2ch.net/test/read.cgi/tech/1091456033/
Part10: ttp://pc5.2ch.net/test/read.cgi/tech/1075630259/
Part09: ttp://pc2.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

□参考リンク□

日本Lispユーザ会 (日本語)
ttp://jp.franz.com/jlug/index.html
ここにかなりの情報があります。削るとAllegro Common Lispのページへ。

プログラミング言語Scheme (日本語)
ttp://www.sci.u-toyama.ac.jp/~iwao/Scheme/scheme.html
Schemeの人はまずここを見ましょう。

Schemeへの道 (日本語)
ttp://www.stdio.h.kyoto-u.ac.jp/~hioki/gairon-enshuu/SchemeNotes/scheme.html
Schemeの入門サイト。

Practical Scheme (日本語)
ttp://practical-scheme.net/index-j.html
Scheme処理系「Gauche」の作者である川合史朗氏のサイト。
「普通のやつらの上を行け」など、興味深い文書を沢山翻訳されてます。

LispUser.net (日本語)
ttp://lispuser.net/
Lisp関連の有用な情報がまとめられています。Common Lispの話題が中心。

□仕様関係□

CLtL2: Common Lisp the Language 2nd edition (英語)
ttp://www-2.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html

CLHS: Common Lisp Hyper Spec (英語)
ttp://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/FrontMatter/Chapter-Index.html

R5RS: Revised(5) Report on the Algorithmic Language Scheme (英語)
ttp://swiss.csail.mit.edu/~jaffer/r5rs_toc.html

R5RS: Revised(5) Report on the Algorithmic Language Scheme (日本語)
ttp://www.sci.u-toyama.ac.jp/~iwao/Scheme/r5rsj/html/r5rsj.html

ERR5RS: A proposal for an Extended R5RS Scheme (英語)
ttp://scheme-punks.cyber-rush.org/wiki/index.php?title=ERR5RS:Charter

R6RS: Revised(6) Report on the Algorithmic Language Scheme (英語)
ttp://www.r6rs.org/final/html/r6rs/r6rs.html

□Wikipedia関連□

ttp://ja.wikipedia.org/wiki/LISP
ttp://ja.wikipedia.org/wiki/Common_Lisp
ttp://ja.wikipedia.org/wiki/Scheme

□継続関連□

なんでも継続 (日本語)
ttp://practical-scheme.net/docs/cont-j.html

Schemeへの道:継続 (日本語)
ttp://www.stdio.h.kyoto-u.ac.jp/~hioki/gairon-enshuu/SchemeNotes/continuation.html

継続の使い方 (日本語)
ttp://www.geocities.co.jp/SiliconValley-PaloAlto/7043/index.html#continuation

継続の使用法 (日本語)
ttp://www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/block.html

Kahua: 継続ベースのアプリケーションサーバー
ttp://www.kahua.org/

□書籍関連(1)□

Structure and Interpretation of Computer Programs (英語)
ttp://mitpress.mit.edu/sicp/
通称「SICP」として知られる『計算機プログラムの構造と解釈』の原書です。
全文がオンラインで読めます。

SICP Web Site for the Japanese Edition (日本語)
ttp://sicp.ipl.t.u-tokyo.ac.jp/
SICP日本語版のサポートサイトです。正誤表等。

How to Design Programs (英語)
ttp://www.htdp.org/2003-09-26/Book/
Schemeを使った優れたプログラミング入門書。全文がオンラインで読めます。

The Little Schemer (英語)
ttp://www.ccs.neu.edu/home/matthias/BTLS/
The Seasoned Schemer (英語)
ttp://www.ccs.neu.edu/home/matthias/BTSS/
Schemeの教科書として定評のある「Schemerシリーズ」のサポートページです。

The Scheme Programming Language (英語)
ttp://www.scheme.com/tspl3/
Scheme入門書。全文がダウンロードできます。

『プログラミングGauche』 (日本語)
ttp://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?&ISBN=978-4-87311-348-7
ttp://karetta.jp/book/gauche-hacks (立ち読み版)
ttp://karetta.jp/book-cover/programming-gauche (サポートページ)
Scheme処理系言語Gaucheの初の解説書！

『入門Scheme』 (日本語)
ttp://www4.ocn.ne.jp/~inukai/scheme_primer_j.html
幻となったScheme入門書。全文がダウンロードできます。

Practical Common Lisp (英語)
ttp://www.gigamonkeys.com/book/
ttp://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06721-1
S式の羅列で現実的な問題をどう解くのか、そのギャップに悩まされてる人に。
全文がオンラインで読めます。日本語版が『実践Common Lisp』として出版予定。

『On Lisp』 (日本語)
ttp://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06637-5
ttp://user.ecc.u-tokyo.ac.jp/~tt076524/onlispjhtml/ (日本語訳HTML版)
ttp://www.paulgraham.com/onlisp.html (英語原文がダウンロード可)
LispハッカーPaul Grahamが、Lispの力の源泉であるマクロプログラミングを解説。

□その他(1)□

John McCarthy's Home Page (英語): Lispの生みの親、ジョン・マッカーシーのサイトです。
ttp://www-formal.stanford.edu/jmc/

Association of Lisp Users (英語): 米国のLispユーザ会です。
ttp://www.alu.org/alu/home

CLiki (英語): Common Lisp関連のリソースが集積されています。
ttp://www.cliki.net/index

CMU Common Lisp Repository (英語): 新旧様々なプログラムが置いてあります。
ftp://ftp.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/0.html

The Common Lisp Cookbook (英語): いわゆるCookbookです。
ttp://cl-cookbook.sourceforge.net/

The EncyCMUCLopedia (英語): CMUCL関連文書。CMUCLユーザーでなくとも有益なはず。
ttp://www.isr.ist.utl.pt/library/docs/encycmuclopedia/doc/

Common-Lisp.net (英語): 多くのプロジェクトがホスティングされています。
ttp://common-lisp.net/

よろずや (日本語): Lisp関連の実用的な情報が色々。
ttp://www.geocities.co.jp/SiliconValley-SanJose/7474/

どう転んでもLisp (日本語): 竹内郁雄氏による発表のスライドです。
ttp://jp.franz.com/base/seminar/2005-11-18/SeminarNov2005-Takeuchi.files/v3_document.htm

Lispとは何か (日本語): 中村正三郎氏による発表のスライドです。
ttp://www.asahi-net.or.jp/%7Eki4s-nkmr/lisp20061121/lisp.html

□その他(2)□

独習Scheme三週間 (日本語): Schemeの教科書。
ttp://www.sampou.org/scheme/t-y-scheme/t-y-scheme-Z-H-1.html

Bibliography of Scheme-related Research (英語): Scheme関連の論文リンク集。
ttp://library.readscheme.org/

Scheme Hash (英語): S式でXMLを使えるようにするSXML等。
ttp://okmij.org/ftp/Scheme/index.html

Scheme-users.jp (日本語): Schemeユーザのためのハブサイトです。
ttp://scheme-users.jp/

(Scheme) (Lisp) (日本語): 各種Scheme処理系をCygwin上でビルドする方法など。
ttp://www.geocities.co.jp/SiliconValley-PaloAlto/7043/

SLIB (英語): Scheme用のライブラリとして有名なSLIBのサイトです。
ttp://swiss.csail.mit.edu/~jaffer/SLIB

Scheme Requests for Implementation (英語): いわゆる「SRFI」のサイトです。
ttp://srfi.schemers.org/

Meadow memo: 2ちゃんねるログ: dat落ちした過去スレの一部が見られます。
ttp://www.bookshelf.jp/2ch/index.html

□その他(3)□

初心者が集うIRC（布教してくれる先生も大募集です）。
irc.scenecritique.com
port 6667
チャンネル　#Lisp_Scheme

Schemeのテストコード書いたり、簡単な実行したりコードさらしたりするにはここへカモン。
ttp://codepad.org/
コードを書いて実行した時のURLを記録しておけば、実行結果も一緒にさらす事が出来て幸せです。

□実装(1)□

awklisp: Awkで書かれたわずか500行のLispインタプリタ。
ttp://www.accesscom.com/~darius/

CAMPUS LIsP Lemon version: Cでわずか1000行。
ttp://www-masu.ist.osaka-u.ac.jp/~kakugawa/hacks/clisp/

SECDR-Scheme: SECD machine modelに基づく実装。
ttp://lily.fan.gr.jp/~kmd/adhoc/view.rhtml?n=SECDR-Scheme_woyomu

LispMe: Palm上で動くScheme処理系。これもSECD virtual machine。
ttp://www.lispme.de/lispme/

Minischeme: 1ファイルに凝縮されたScheme処理系。
ttp://tinyscheme.sourceforge.net/minischeme.tar.gz

TinyScheme: Minischemeを色々弄ったもの。
ttp://tinyscheme.sourceforge.net/

Schemix: Linuxのkernelへのパッチで/dev/として扱えるTinyScheme。
ttp://www.abstractnonsense.com/schemix/

Bit: Minischemeよりも小さい（？）バイトコード変換系。
ttp://www.iro.umontreal.ca/~dube/

KI-Scheme, AM-Scheme, etc...
ttp://www.nifty.com/download/dos/prog/lisp/

□実装(2)□

Gauche: マルチバイト文字に対応したR5RS準拠のScheme処理系。川合史朗氏作。
ttp://practical-scheme.net/gauche/index-j.html

PLT Scheme: DrScheme、MzSchemeなどのR5RS準拠および独自拡張のScheme処理系。
ttp://www.plt-scheme.org/

Scheme48: R5RS準拠のSchemeバイトコードインタプリタ。
ttp://www.s48.org/

Gambit-C: R5RS準拠のScheme処理系。
ttp://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Main_Page

Chicken: R5RS準拠のScheme処理系。スタンドアロン実行ファイルが簡単に作成可能。
ttp://www.call-with-current-continuation.org/

Stalin: 激烈な最適化を施すScheme処理系。人間の書くCコードより速いという噂。
ttp://cobweb.ecn.purdue.edu/~qobi/software.html

Bigloo: CLR用のコードを吐けるようになったらしい。
ttp://www-sop.inria.fr/mimosa/fp/Bigloo/

guile: R5RS準拠のGNU公式拡張用言語。もちろんSLIBも使えます。
ttp://www.gnu.org/software/guile/guile.html

Chez Scheme: R6RS準拠の商用Scheme処理系。インタプリタはフリー。
ttp://www.scheme.com/

Ypsilon Scheme System: R6RS準拠のScheme処理系。
ttp://www.littlewingpinball.net/mediawiki-ja/index.php/Ypsilon_Scheme_System

□実装(3)□

Steel Bank Common Lisp: 代表的なCommon Lisp処理系。
ttp://www.sbcl.org/

CMUCL: Common Lisp処理系。
ttp://www.cons.org/cmucl/

GNU CLISP: Common Lisp処理系。
ttp://www.clisp.org/

Embeddable Common Lisp: Common Lisp処理系。
ttp://ecls.sourceforge.net/

Allegro Common Lisp: 代表的な商用Common Lisp処理系。
ttp://www.franz.com/

LispWorks: 商用Common Lisp処理系。
ttp://www.lispworks.com/

Corman Common Lisp: 商用Common Lisp処理系。
ttp://www.cormanlisp.com/

Arc: ポール・グレアム氏が開発中の新しいLisp。
ttp://arclanguage.org/

□イベント関連□

GaucheNight (2008-03-08)
ttp://practical-scheme.net/wiliki/wiliki.cgi?gauche.night
「SchemeとGaucheとλとS式を愛するすべての人に贈るマクロな一夜」
出演：川合史朗、伊藤篤、山下伸夫、笹田耕一、ひげぽん、zick、
　　　黒田寿男、えんどうやすゆき、ほか

GaucheNight (2007-05-09)
ttp://practical-scheme.net/wiliki/wiliki.cgi?GaucheNight%3a2007
出演：川合史朗、黒田寿男、まつもとゆきひろ(Skype中継)、小飼弾、
　　　伊東勝利、久井亨、小黒直樹、ほか

黒田寿男氏関係 (黒板の人)
ttp://pc10.2ch.net/test/read.cgi/tech/1151025773/901-909
ttp://www.bookshelf.jp/2ch/tech/1151025773.html#901

Schemeのマクロに関する黒田氏の所感
ttp://cl-www.msi.co.jp/solutions/knowledge/lisp-world/articles/scheme

それに対する川合史朗氏の応答
ttp://practical-scheme.net/wiliki/wiliki.cgi?Scheme%3a%e3%83%9e%e3%82%af%e3%83%ad%3aCommonLisp%e3%81%a8%e3%81%ae%e6%af%94%e8%bc%83

それに対する黒田氏の再反論
ttp://cl-www.msi.co.jp/solutions/knowledge/lisp-world/articles/gauche-night

それに対する川合氏の応答
ttp://practical-scheme.net/wiliki/wiliki.cgi?Scheme%3a%e3%83%9e%e3%82%af%e3%83%ad%3aCommonLisp%e3%81%a8%e3%81%ae%e6%af%94%e8%bc%83%3a%e6%84%8f%e5%91%b3%e8%ab%96

その他、黒田氏によるLisp関連のエッセイがこちらで読めます。
ttp://cl-www.msi.co.jp/solutions/knowledge/lisp-world/

□2ch上にあるLISP関係のスレ□

(make-thread :name common-lisp :part 5)
http://pc11.2ch.net/test/read.cgi/tech/1215834213/

【ＣＧＩ】実用比較Lisp vs C/C++【ＧＵＩ】
ttp://pc11.2ch.net/test/read.cgi/tech/1150501484/

【魔法】リリカル☆Lisp【言語】
ttp://pc11.2ch.net/test/read.cgi/tech/1183396621/

Emacs Lisp 3
ttp://pc11.2ch.net/test/read.cgi/tech/1191875993/

【ﾔﾊﾟｰﾘ】XMLをS式に置換えていくスレ【LISP最強】
ttp://pc11.2ch.net/test/read.cgi/tech/1140006937/

【SICP】計算機プログラムの構造と解釈 Part2
ttp://pc11.2ch.net/test/read.cgi/tech/1203096230/

【普通のやつらの】 Arc Language 0 【上を行け】
ttp://pc11.2ch.net/test/read.cgi/tech/1202098949/

Lisp@UNIX版
ttp://pc11.2ch.net/test/read.cgi/unix/1019926525/

Lisperこそ真のプログラマーよ！！
http://pc11.2ch.net/test/read.cgi/prog/1175791979/

LISPってさ〜
http://science6.2ch.net/test/read.cgi/sim/1015169050/

テンプレ終り？乙〜

981 ：デフォルトの名無しさん ：sage ：2008/07/12(土) 18:26:53
　　(p)http://wiki.fdiary.net/lisp/ にこのスレのテンプレをまとめておきました。
　　このスレの最初のものをコピーしたばかりなので、最新版にアップデート
　　しなきゃいけない所の訂正をお願いします。
　　（たとえば、テンプレには話題のイプシロンについてはかかれていない。）

　　また、ID:guest PASSWORD:cl です。インストールログなどの公開場所
　　としてもご利用ください。

>>1 押忍・・じゃなくて・・乙！

>>1 乙
テンプレすごいなー

>>1 乙
Scheme実装に追加でMosh。
ttp://code.google.com/p/mosh-scheme/

あとShiroさんが面白かったって書いてた奴
ttp://clojure.org/

>>19
http://wiki.fdiary.net/lisp/?%A5%C6%A5%F3%A5%D7%A5%EC+%28Lisp+Scheme%A5%B9%A5%EC%29

テンプレ改訂しました。実装のところは言語ごとに分けてみた。

(乙　(>> 1))

□その他(4)□

Somewhere Over the Rainbow
http://jp.youtube.com/watch?v=2A2Jt4WOxN8

r6rs日本語訳のpdf版ってねーの？

>>23
お前が作ればあるぞ

まだ半分もできてないけど現状報告。
http://kissho.xii.jp/1/src/1jyou41912.pdf.html
WiLiKiにあがってたのをベースに組版中。
TeXに明るくないので原文のマークアップをそのまま適用する方向でやってる。

WiLiKiにあがってる訳ってたしかleque氏がやってたんだよね？
ほとんどコピペの組版作業でもけっこうめんどいのに、訳とかすごすぎるとオモタ。

翻訳版を作るのは理解するより難しいからね。
理解したことを日本語の文章で書く必要があるから。

しばらくSchemeから離れてたんだけど
Ypsilon という処理系が公開されてたんだね。
試してみたらかなり高速。
> (import (time))

> (time (tak 12 6 0))


;; 1.279202 real 1.279208 user 0.0 sys
12
>
Gaucheと並ぶ優良国産処理系の予感。

GC が脱 Boehm なんだっけ？

テンプレwikiからのお知らせ(common lispスレと同じ
文章になってます。FAQは共通でいいでしょ?）

よくありそうな質問をwikiでまとめておこうと思うので
よくありそうな質問と（回答ができそうな人は回答を）
書いてくれませんか?質問と回答のフォーマットは
一応決めてあります。

http://wiki.fdiary.net/lisp/?FAQ (id:guest pass:cl)

Schemeプログラミングはdomain specificな性能をもつコンパイラを書くところから始まる・・・

>>28

詳しいことはわからないけどＧＣはそういう方針
なんだって。

ピンボールゲーム用ってのには驚いた。
ビル・バッジ、わ〜、懐かしい名前。月刊アスキー
で読んだっけ。処理系を作った人はずっとこれを
追いかけているらしい。夢のある人だね。羨ましい。

>>31
OpenGLだってDSL持ってんじゃん。(そこをLLVM by Apple)
グラフィック系はちょっと凝ったことしたくなって、そこがメインだったりするから、
お仕着せのAPIだけじゃ困るわけ。

GCとかネイティブスレッドとかはライブラリのラッパを書くより大変なのだ

common lispスレなくなった？
ここと統合？

5つ下に何かあるようだが

>>34
へんな名前にしたらしい
アンチのしわざ？
http://pc11.2ch.net/test/read.cgi/tech/1215834213/

Schemeにcartesian-product-for-eachというものはないでしょうか?

(cartesian-product '((a b c) (0 1)))
⇒ ((a 0) (a 1) (b 0) (b 1) (c 0) (c 1))
http://practical-scheme.net/gauche/man/gauche-refj_158.html#IDX3119

メモリ上にこのリストを作らずに、各要素に対してprocを適用するものがほしいのですが。

gaucheにあるじゃん。
そのまんまの名前で。

>>28
ドキュメント化されてないけど、あったんですね。
自分で書いてしまいました。
cartesian-productよりも簡単でした。

(define (cartesian-product-for-each proc los)
(let loop ((r '())
(los los))
(if (null? los)
(proc r)
(for-each (lambda(x)(loop (cons x r) (cdr los))) (car los))
)))

ど素人ですまないんだけど
timeを行うとreference to undefined identifier: time
となるんだけど
どうすれば使えますか？

ど素人は判ったから、まず自分の境遇について語ってくれないか？

version209でLanguage: Standard (R5RS).です。

plt schemeです

42,43ですけど言語の選択のところのPLTのところを選択すると
使えました
なぜですか？

timeは標準(RSR5)にはないからです。

version209って古いの使ってるね。Planetで使えないの多いのに。バージョンアップしたほうが幸せになれるとおもうよ。

新しくしてもR5RSにtimeはないですけどね、念のため。

>>47
せめてR6RSについて書けよｗ

Lispっぽいawkってないのかな？さくっと正規表現をワンライナーで書けるやつ知ってたら教えて。

>>49
Gaucheで正規表現書いたことないのか？

Lispっぽいシェルを作ればワンライナーいらないっぽいな

scshってのがあるから使えば?

Eshellでいいじゃん

どのScheme処理系でもDSLを作れるはずなのに、おかしいな

r6rsの日本語訳を読んでたら、
「bodyの中に挿入される」ってフレーズに遭遇した。
なんかやらしい。（＞＜）

つ S式

コミュニケーション

つ M式

つ ネジ式

つ 相武紗季の始球式

つ 正岡子規

つ 両儀式

なにこの流れ

よくわからんが「やらしいもの」の列挙であろう。

>>56 S式もやらしいぞ
>>57 S式コミュニケーションというラノベがあるのだ
>>58 S式がやらしいと言うのならM式も忘れちゃいけねぇ
>>59-62 以降は単なる「しき」繋がり
>>63 ようやく突っ込みが入る
>>64 ちょっとピントのズレた解説
>>65 解説(解答編)

全レスしてる奴久々に見た。きもい・・・

いろんな芸風の人が来ますね

どうでもいいが「ねじ式」（ひらがな）だ

どうでもいいことは書かなくていいよ。

部外者の愚問ですが、Webプログラミングをする場合、Ｇａｕｃｈｅは、Ruby、Pythonなんかに比べてどんなメリットがありますか？

>>70
別に無いよ。

>>70
KahuaはGaucheを使ったフレームワークだけれど、継続を積極的に使っているところがおもしろい。
だけどメリットとして説明するのは難しいな。
ちゃんと理解すれば記述は簡潔になるんだけど、そもそも理解しにくいってのもあるからどっちもどっちって気もする。
まぁ、結局は好みとかもあるから使ってみなきゃ判断出来ねぇよ。

ロジックを記述するときに関数型は（比較的に）記述量が少なくて済むことぐらい。
あと、思い入れを満たしてくれるところｗ

納品用はPython, 自分用はGauche ... ああ、夢のない話をしてしまった orz

（A)BNF(投資家じゃない方の)からS式にマップは原理上可能ですが
そのS式とコードを食わせると構文木を作ってくれる
ような関数もschemeでは楽に書けるんでしょうか？
これができたらコンパイラのフロントエンド部分を作り放題なんですが

それが（いわゆる）コンパイラコンパイラって奴ですな

>>75
SLLGEN

>>71-74
Schemeに元々慣れていれば、って感じですね。
レスありがとうございました。

>>76
コンパイラコンパイラとかでぐぐったら凄い数の実例がありました
すごいですね

>>75
こんなライブラリもあるんですか
また読ませていただきます

>>75
Gauche の SVN Trunk に入ってる parser.peg モジュールが使えるんでね？

>>80
ドキュメントが無いよ…

分子構造をリストで表せないでしょうか？
例えば、C2H6Oだとエタノール、ジメチルエーテル。
炭素原子から手が４つ出ているのをリストで表現するには
どうしたらいいのかと．．．

>>82
CMLで書いてssax:xml->sxmlするんだ。

>>82
隣接リストでいいんじゃね？
>>83
CMLって使ってる人見たことないんだけど

>>84
ありがとうございました。隣接リストで考えてみます。

あわせて行列による分子の表現、行列演算による化学反応の表現が
できたら面白いと思いました。やってみます。

>>82
つXymTeX

http://oku.edu.mie-u.ac.jp/~okumura/texwiki/?XyMTeX
http://www.klavis.info/xym.html
http://homepage3.nifty.com/xymtex/fujitas/rd/chosho.html

Gaucheでzlibを使うにはどうしたらいいんでしょう？
http://practical-scheme.net/wiliki/wiliki2.cgi?Gauche%3AZlib
にある
Gauche-zlib-0.1.2.tgz
はリンク切れで入手できません
うーん

（^A^）ｶﾞｳﾁｮ

srfiにzipうんたらって関数なかったっけ？
それで

>>85
ずっと昔は化合物を扱うLispで書かれたシステムもあったらしい。
今だとPythonの方が主流？かな。
でもがんばれ。

>>86
それLaTeXだし方向性が違うと思うぞ

>>90
TeXだからASCII文字シリアライズwith構造の参考になるでしょ。
しかも変換できるようにしておけば、
XymTeXで分子構造図画像も作れるし。

schemeについての質問です。
二分木を作成、描写せよという問題で作成まではできたのですが、描写とはどうすればいいのでしょう？
初心者な質問ですいません。

設問した奴に聞けよｗ

>>87
あぷろだにUpっといてやったぞ。
http://www.toel.sytes.net/~toel/cgi-bin/upload/stored/up3794.xxx

>>87
Windows 版でよければ Gauchebox に入ってるぞ

>>94
>>95
ありがとうございます
win, linux両方で使用するのでどちらも利用します。

http://wiki.fdiary.net/lisp/ ですが、一応情報を集めるサイトにしてあります。
どんどんページを追加してやってください。
comp.lang.lisp,comp.lang.schemeまで含めようとしたけど、matzlispのhikiの
プラグインがatomに対応していないためにやめました。これらはmiscに
入れておきました。

gauche-firebird がリンク切れかサイト死亡で見れないんですが、
firebird 用のDBDどこかにありませんか？

40過ぎのわしでも子供の頃（高校生くらい）に Lisp に憧れたんだから、
今の子ならそんなの普通だと思ってたが・・・

おっちゃん誤爆してるで

まあ少年がLisp触ってるぐらいでオヤジども喜びすぎと
雑誌の記事がLispかBasicだけという時代に若者だった俺は思う

９０過ぎのワシも高校のころにLispに憧れたぞ。

>>102
ジジイ、いくつのとき高校行ったんだよ？

>>102
McCarthyより年上じゃねえかw

>>103
ここまでの年齢だと逆に、
中学までしか出てなくて、定年してから学業やりたくて高校行くみたいなエピソードが
想像しやすいかもしれんｗ

ラムダ計算論ができたころに高校生だったんですね、わかります。

日本では戦前にLispが発見されたという噂を聞いて駆けつけました。

lispの起源は韓国ニダ

日本で最初のLisperって誰？
HLISPの後藤英一先生？

そのあたりだろうな。あと故・中西正和先生とか。

竹内先生は意外と遅い組？

和田先生も忘れちゃいけないよね。

あと、その世代だと井田先生かな。

思えばその世代のLisperはどれも役立たずだったな

つまんない煽り乙

今の世代のLisperはどれも>>114よりは役に立ってるかな。

注目ワード“高階プログラミング”って何だ？
ttp://ascii.jp/elem/000/000/157/157495/

萩谷先生の関数プログラミングっていう本は
高卒レベル数学力(偏差値60切る位)でプログラミング初心者では読めませんか？
Yコンビネータなどの高度な話題にもふれてますか？

>>118
良い本です。だいじょうぶですよ。

途中、フィボナッチ数列の行列表現、固有値
とかでてきますけど本筋とは関係ないので
とりあえず無視してＯＫです。
Ｙコンビネーターはとりあげてないですね。

序文で萩谷先生は高校生に読んでもらいたい
と書いてます。

Yコンビネーターについて触れてる、高校生にも読める本って
そういえば無いような気がする。あったっけ？

プログラミング初心者が読んで何かを作れるようになりたいんだったら向いてないかも。

>>120
Little Schemer

あれYコンビネータまで行くのか

Yコンビネータって本を読むほどの物でもない気がするけど
λ記法でわかりにくければS式で書き下せばいい

なんでYコンビネータだけが特別扱いされてるんだろ？

再帰系のコンビネータの中でってこと?
そりゃ一番シンプルだし。

>>126
つか、やたら Y が目につくようになったのはいつ頃から？

今朝くらいから

>>128
それはテトラポッドやろ。

>>119
ありがとうございます。
＞ 途中、フィボナッチ数列の行列表現、固有値
程度なら理解できると思います。

都内で初心者向け勉強会を模索しようとしております。

以下想定です。
こうしたらいいとかありましたらどんどん提示して頂けたら幸いです。

・大学生のLisper/Schemerを先生として呼ぶ
・上記のため会費をとります。
・場所は以下を想定。（1h：1400〜2300円くらい＋各自１ドリンク）
ttp://www.ginza-renoir.co.jp/miyama/
・スキルがバラバラになるため基本的に自習を想定
（同スキルの人と課題本を決めてチーム学習する等は自由です）
・参加条件としてキーボードがサクサク打てる程度。処理系を入れるノートパソコン等。
・開発環境構築から指導の予定


参加者希望予定者がいらっしゃいましたら、
lischemep at gmail.com
まで下記を記入して送ってください。

使用希望の
・希望日（参加頻度：必ず参加、月１希望、仕事のため不定等）
・希望参加費
・ＯＳとバージョン
・エディタ
・処理系
（↑処理系は希望なければおまかせと書いてください）

また先生やってみたいという方は、下記を記入して送ってください。
・希望日（開催頻度も）
・希望報酬額（時給換算、月ＸＸ円等）
・対応できるＯＳ・処理系・エディタ

先生のレベルを決めないで、
希望参加費を申告制にすると、
収集つかないんじゃないかな。

>>132

なるほど。
勇み足過ぎたかもしれません。

まず、参加希望者から
・自分のレベル
・どんな課題がしたいか

を送ってもらうように訂正します。
lischemep at gmail.com

最初の課題は開発環境構築じゃなくて処理系を選ぶこと。

>>131
お、面白そうだな。
確認だけど◆/uyHCgG7qAは先生じゃなくまとめ役ってこと？
「先生」の技量に全てが依存している気がする。
大学生でLisperを名乗れる奴ってどのくらいいるんだろう。

131です
135さん

私は先生はとても無理です。

先生は学生でなくてもいいのですが
そうすると高額なセミナーになってしまう気がして。

社会人のSchemer/Lisperなら薄謝もらってもおそらく割に合わないでしょうし。

>>136
スキモノならボランティアでやってくれるんじゃないの？
もっと安くあげる方法はあると思う。
http://www.javaopen.org/jfriends/howto/

自習じゃ駄目な理由は？

ここで聞けば良いのでは？
http://www.lingr.com/room/bpYrj7DtJnN

Lisp/Schemeは人気が低いわりに実装がやたら複雑だから人手が足りない。
移植したりライブラリを増やしたりできない。
勉強会やるとしたら言語仕様だけでなく実装についてやるべきだけど、
複雑な実装が乱立しているから難しい。

もちろん単純なScheme処理系もあるが、それは人気がなさすぎる。
たとえ言語が人気でも処理系が不人気なら意味がない。
複雑さの許容度は人気に比例するのだと思う。

複雑なものもいずれ必要にはなる。
でも今は必要ないんだよ。今一番必要なのは、人気と釣り合いのとれた単純な実装。
そのためならマクロを犠牲にしてもいい。
それに気づいた人はS式から離れていく。嫌いになった訳ではないがな。

>>140
で?っていう

>>140
自分の低能ぶりを直視できない人間だということを婉曲に表現した自己紹介ですね

>>140
言い訳をいろいろ考える才能はありそうですねｗ

地元の大学でSchemeの授業があれば聴講したいの
だけど、残念ながら無し。
東京近辺に住んでいたら東工大の講義を聴講したい。

>>144
むかしなら、大学の授業の潜り込みは簡単だったんだけどね。
今は、わからない。
東工大もセキュリティは厳しくなってるからね。

>>140
釣られるけど、マクロの無いLispなんてLispじゃないだろ
そもそもCommonLispもSchemeもちゃんと仕様のある「まとも」な言語なんだけど。

Lisp 1.5 は Lisp じゃないなｗ

処理系のソースコードを気軽にいじれるならマクロなしでもいけるかも
Lisp1.5はそうだったかも

>>145
国立大は社会人受入れに寛容
なようなので正規に聴講生の
手続きをとって試験も受けて
単位もとりたいです。
でも、地方の大学でSchemeを
使った講義があるところは
限られてるみたいです。

マッカーシー博士の最初の論文
にあったLispで記述されたLisp
で仕組みがよくわかりましたよ。
故中西先生もこの論文だったか
ユーザーマニュアルだけを手がかりに
最初のLisp処理系を書いたと読んだけど。

マクロは無いくせにｗ、コンパイラは含んでいるというのは凄いと思う＞LISP 1.5

他言語処理系に対するアドバンテージは
マクロだけだもんね

>>149
どうしてもね。その傾向はあるかもね。人工知能の分野もlispよりC++のほうが勢いがあったり
するらしいから、教える人が少なくなるんだろうね。筑波、東工ふくめて旧帝大あたりだったら
一つくらい授業がありそうだけど。それ以外の地方は確かに期待できないかもしれないね。

プログラムの筋はschemeをやる方が断然よくなるんだけどな。これは抽象化がうまくなるから
だろうと思う。高階関数を扱える言語をしっかりやってるかやってないかでセンスはずいぶん変
わるね。

>>152
んなこたあないｗ

Lispのアドヴァンテージはいくつか
考えられますが、一番はＳ式のもつ
プログラムとデータの同一性だと
思います。強力はマクロもその
特性のひとつでは？

>>137
いいリンク紹介ありがとうございます。
やっぱり安く上げる方法考えた方がいいんですかね。
私自身はお金は無頓着なので。場所ももう少し探してみます。
課題本はあったほうがいいんでしょうか。
「この本やりたい」とかありましたら教えてください。


>>138
>>139
自習だとつまらないことでつまづいて長い時間考えることがあるからです。
ネット上で聞くということも出来ますが、
その場合状況説明のやりとりに時間がかかります。
私はもう結構な年なので、お金を払ってでも学習速度を上げたいと思ってます。

（意地悪い言い方で申し訳ないけど）自分の家庭教師が欲しい、ってことなのかな？
もしそうなら「自分と同じレベル募集」とか、はっきり言っちゃったほうが良いかも。ｗ

俺も先生は大学生とか限らないほうが良いと思う。

> その場合状況説明のやりとりに時間がかかります。

これを要領よくやる訓練も必要かと

>>151
マクロ機能は自分で好みのを書けってことだったんじゃないかな？
当時のマクロの実装は簡単だったしね。

>>149
私立だって簡単に聴講生になれるぞ。
金がかかるだけで。

>>159
最初の頃はFSUBR + EVALで一々手で書いた。
パターンが出来上がったのでdefmacroになった。

>>156
> 自習だとつまらないことでつまづいて長い時間考えることがあるからです。

本当はそれが大切なんだけどね。
より深く理解するし、それが出来る人が継続もできる。
壁に負ける人はいつも負け続ける。

それが大切だとしても若いうちだけだろ。
年取ってるなら金払ってでも学習速度を上げたいって言うのはわかる。

生涯学習だな。カルチャー教室でやらないかな？ｗ

>>157
家庭教師。つまるところそうなのかもしれません。
Lisp/Schemeにとっつきにくさがあると思ってて
同じ状況の人がいるだろうと思ってたのですがあまりいないみたいですし。。。

状況としてはThe Little Schemerの半ばで頓挫している状況です。
他にもプログラミングGaucheやANSI Common Lispなどをつまみ食いしてますが
途中で分からなくなってます。

色々当たっているうちに少しずつ分かったりしますが
時間がかかりすぎている気がしています。
このままだと数年かけて一冊片付くペースになってしまいそうです。


>>162
三十代になるとさすがに焦ります。

> 三十代になるとさすがに焦ります。
俺は164がなんでLisp/Schemeをやってみようと思ったのかが気になるな。
知的興味が理由なら年齢で焦ることはないだろうし。
近い将来に仕事で使う必要があるのなら焦る気持ちもわかる。
学習する動機によっておすすめの方法も違ってくると思うんだが。どう？

書いてあるじゃん
挫折しそうだから
くじけそうだから
もう後がなさそうだから

俺なんて、40近くになってScheme始めたぞ。
独学でSICPをしこしこ解いてるよ。

同時に数学の勉強も始めたんだが、こっちがきつい。
数学基礎論のやさしい教科書はないかな。

目的がいまいちはっきりしない質問者はやがて身の上話を始める法則

>>167
> 同時に数学の勉強も始めたんだが、こっちがきつい。
> 数学基礎論のやさしい教科書はないかな。

数学基礎論の質問スレッド その4
http://science6.2ch.net/test/read.cgi/math/1207899938/

おおかた数理論理学か集合論の教科書を薦められると思うが
計算機科学との関連で何かもくろみがあるならこっちへ
http://science6.2ch.net/informatics/

「数学」が何を指してるか知らんが、
基礎論は数学を勉強する支えにはならないぞ普通は。

集合論とか論理とかを学ぶなら基礎論には手を出していない
普通の教科書のほうが良い。

>>168
ありがとうございます。覗いてみます。

>>169
そうなんですか？
集合論とか論理学から、計算機科学方面へ進めていきたいと思っていたのですが。
私の「基礎論」という言葉の使い方がおかしいのでしょうか？
集合論や論理学そのものを学んだほうが良いということでしょうか？

>>146
仕様があればまともな言語なのぉ〜？

「まともな言語」の集合を定義してください

>>170
今、数学で「基礎論」といったら、逆数学とかあのへんのことを指すんじゃないかな。
少なくとも専門分野を「基礎論」と自己規定してる数学者は、だいたいそのあたりの
分野を研究してることが多い。(Harvey Friedman, Stephen Simpson, 田中一之氏, etc)
「基礎論」という分野が勃興してきた19世紀末と現在とでは、言葉のニュアンス
がかなり違ってきているので、注意が必要かと。

167氏はあるいはもっとルーズに、「基礎論」という言葉を「数理論理学」とほぼ同義で
使ってるのかもしれないが。

まあいずれにしろ、数理論理学は（少なくとも初歩の段階では）メインストリームの数学とは
直接関係しないことが多いね。幾何的モデル理論みたいに、数論への応用があったりする
分野もあることはあるけど、そういうのは非常に専門的な話題になってしまう。
（169氏が言ってる「数学を勉強する支えにはならない」というのはおそらくそういうニュアンスなのだろう。）

でも理論計算機科学に興味があるのなら、数理論理学は必須だから、（167氏言うところの）
「基礎論のやさしい教科書」を勉強するのは意味のあることだと思うよ。

とりあえずはこのあたりをご参考に。
ttp://www.kurims.kyoto-u.ac.jp/~hassei/reading_list.html#LOGIC

計算機工学者のための計算機数学のとっかかりということなら、
島内さんの「数学の基礎」はどうかと思ったが、
http://www.amazon.co.jp/数学の基礎-島内-剛一/dp/4535601062
絶版で中古市場では高い！ヤフオクでも元より値が上がってる！

竹内外史とかのは基礎論だよな？

と板違いか。

>>165
はじめのきっかけは、「普通のやつらの上を行け」を学生時代に読んでです。

知的興味もありますが、将来的には仕事で使いたいと思っています。
また、なるべくLisp/Schemeを広めていきたいと思っています。
それで初学者向けの勉強会が出来ないかと思いました。

目標としては、AllegroServeを使えるようになること、
On Lispを理解できるようになることです。

>>176
まだ、shemeやcommon lispに馴れていないならば、SICPよりもう少し簡単なもの
からお勧めするよ。
schemerなら、gauche本でもいいし、common lisperならAnsi Common Lispや岩波
の本でもいいし。

>>176
ポールグレアムって結局SchemeにもCLにも否定的じゃないか？

>>178
どちらかといえばSchemeにもCLにも肯定的だと思うよ。
（Lisp族以外の言語に比べれば）

PG
javaには否定的というのははっきりしてるし、C系に苛立ちを持ってるような記述も
みかけたことはあるかな。

CとPerlは人気の言語として色々条件を満たしているみたいな話があったような

40年も前から存在するのに
lispが全く存在感無い事について
想像力を働かせてみた方がいいと思うね

>>182
どれだけの世界を見て生きてきたか知らんが、
あなたのちっぽけな経験で感じた存在感なんて
なんだというのだ
ふしあなか？

>>183
頑張ってそれか？
「viaweb以外のインストールベースの例を教えてください」
って聞かれたらどうするの？
はいやりなおし！

「実用性なんて飾りです。偉い人にはそれがわからんのですよ。」
くらい言わないと。

>「viaweb以外のインストールベースの例を教えてください」

なんか薄っぺらいなぁ。

>>170
皆言ってるように「数学基礎論」そのものに首を突っ込む必要はない。
集合というのはただのモノで、ただのモノについての議論を深めていくと
濃度がどうとか数学基礎論の方へ行く。

そっちではなくて数学の基礎と言うか数学村の言葉使いに慣れておく必要がある。
つまり集合と言うただのモノに必要な性格付けをして数学的な実質のある体系を
作っていく手順を自分なりに一度は体験しておく必要がある。

入り易いのは数の構成で、島内氏のとか岩波新書に「数の体系」とかいろいろある。
そんなことは分かってるというのであれば不要だが、単に実数も複素数も知ってるというのではだめ。

次にやっておくべきは代数かな。計算機科学との相性も良いし、暗号等での応用もあって本もたくさんある。

あとは必要と興味に応じてやっていけば良い。ひとつ注目したいのは圏(カテゴリー)論。
ひと昔前はGAN(GENERAL ABSTRACT NONSENSE)とか揶揄されたが様変わりで、
Haskellで圏論と言う言葉を知る人も増えたらしい。

昔の本だと「数学基礎論」となっていても
真偽関数から始めて命題論理・モデル理論・述語論理・帰納的関数・・・と続き
最後にちょこっと公理的集合論が出てくる、というような感じで
>>170のやりたそうなことに内容的にはちょうどよかったんじゃないかと思うが
今はもっと効率的にやる方法もあるだろう

>> 173, 187, 188
ご教示、ありがとうございます。

そもそもの動機なのですが、ただいま「論理と計算のしくみ」を読んでいまして、
ちょっと展開が速すぎて着いていけないので、もうすこし詳しく、さらに言えば
演習もあるような書籍は無いかと思ったしだいです。
証明の仕方に慣れていないせいか、結論はともかく過程に納得ができなくて。

とりあえず、「論理学をつくる」を入手しましたので、これをみっちりやってみます。

圏論も視野には入っています。ちょっと遠そうですが。

一番初めの目的はプログラミングや設計に役立てるためだったのですが、
いつのまにか、数学を学ぶこと自体が楽しくなってきてしまいました。
脱線して、計算機科学と関係ない方向に行ってしまいそうです。

>>184
はいさようなら！

177さん

助言ありがとうございます。

やっぱりLispかSchemeどっちを学ぶか決めた方がいいのでしょうか。今は両方手をつけてます。

それと最近翻訳された実践Common Lispは初学者向けですか？

>>191
そこは自分で考える部分だよ。

言語の取得って基本的に同時に複数をやるのはあまりよいとは思えないですね。
ゴールがなにか？を考えたら使用する言語は決まってくると思うけど。
LLな活動ならgauche で充分だけど、重い計算をさせるならcommon lispのほうが
当然向いてるし。

>>192
同時にやるのが〜といったのは
(defun foo (arg1 arg2) ....)
(define (foo arg1 arg2) ....)
と微妙な違いの1例だけど、この違いがなれないうちは混乱に結びつくからだよ。
(defun foo (arg1 arg2)
....
(cond
[(= a b) ...]
....))

みたいになっちゃいけないし。

>>193
それはcommon schemeだ。

>>191
『プログラミングGauche』で「途中で分からなくなって」るんだったら、
『実践CL』も同じ結果になる可能性が高いんじゃないかと。

とりあえず「AllegroServeを使えるようになる」という目標があるのなら、
CL一本に絞って、もっと懇切丁寧な初学者向け教科書で勉強してみるのが
一番じゃないでしょうか。

Peter Norvigもたしか「まったくの初心者にはこれが一番いい」と言ってたと
思いますが、TouretzkyのGentle Introductionが非常に丁寧でいいと思います。
こちらから全文が無料でダウンロードできます。

ttp://www.cs.cmu.edu/~dst/LispBook/index.html

「リスト遊び」とかどうだろう。Emacsが動けばすぐ試せるし。

「プログラミングGauche」は全部理解する必要はないだろう。
特に第3部は必要な箇所だけ読めば良い。

皆様、色々と助言ありがとうございます。

>>195さん、
よさそうですね。後で印刷して通勤の合間に読んでみます。

>>196
Emacs Lispの本も持ってます。そちらにも手を付けてみます。

>>197
それを聞いて少し安心しました。

AllegroServeを使えるようになるにしろ、On Lispを読めるようになるにしろ、
実践Common Lispは良いテキストだと思うけどなあ。

漏れは、リスト遊びや、Elispの勉強は、上二つの目的には直接関係してこないと思う。

>>199
禿同。実践本がマスターできたら、あとは自分で調べながら何でもやれるよ。
マクロもCLOSも書いてある本は他にないと思う。実践本のFOO言語の下りは
本当に素晴しい。

ちなみにAllegroServeは使うだけなら全然難しくないよ。
S式でややこしいListの構築の練習に良いかもね。
リスト遊びは名著だけど、泥臭くなさすぎる。

教えてください.R5RSに記述されている手続き/シンタックスはすべて
syntax, library syntax, procedure, library procedure, optional procedureのいずれかに
分類されていますが,define, define-syntax, syntax-rulesに関しては上の分類別の記述がありません.
どのように考えれば良いでしょうか.すべて定義に必要なものですから基本的なものだとは思うのですが
単純にsyntaxの部類に属するとしてよいのでしょうか.

define、define-syntaxは式ではないのでsyntaxではない
syntax-rulesは式ではないのでsyntaxではない

たぶん

CLで言う所の特別式は値のある式だけど
R5RSではたとえば
(define x (define y 100))
などは許されない

値のない式もあるから203の例は不適当だったか

>>201
define, define-syntax, syntax-rulesは確かに書いてないねえ。
でも、こいつらはどう考えても手続きじゃないから分類するならsyntaxなんじゃないの？

CLみたいに特別式、関数、マクロに単純に分類できないからねぇ
beginの扱いも微妙だし

svnから引っ張ってきた最新版のgaucheをVCでコンパイルすると
実行時にしょっぱなのScm_Initでこけます。

どうもvminsn.cの SCM_VM_LOCAL_ENV_CALL ラベルに来たとき
vm->val0に値が設定されていないことが原因っぽいのですが、
これの解決策分かる方いませんか？

スレチなら、適切な場所に誘導してもらえると嬉しいです。

>>207
> スレチなら、適切な場所に誘導してもらえると嬉しいです。
http://www.lingr.com/room/gauche

>>201
自分はsyntaxだと理解してきました。

ちなみにR6RSではsyntaxと明記です。

>>208
ありがとうございます。

http://natu.txt-nifty.com/natsutan/2008/08/lisp_186c.html

センスのないネタやね。この手の奴にlispを語ってほしくないな。sicpを
やってた奴みたいだが。

どうでもいいものを、ここに張る奴もどうかしてる。

>>みなさま
いろいろお教えいただきましてありがとうございます
>>209 さんのご意見に従い
割り切ってsyntaxに入れてしまったのが簡単で良いかなと思っています
しかしこれらをあえてsyntaxから外してあるということは
R5RSはそれだけ厳密に定義されているということなんでしょうか

R5RSは結構いい加減w
それ系のMLでも解釈について議論になってる。

もちろん仕様がないような言語とは比較になりませんが。

どういう言語でも↓こういうことがあるもんなんです。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html
そういうレベルの意味において「いい加減」

静的型と仕様は頭の中にあればいいよ

お前は頭の中で済むほど頭がいいのか？

お前は頭の中で済むと思い込むほど頭がわるい人は多い。

worse is betterを思い出した
頭のいい奴は複雑なものを作るから困る

日本語は難しくてかなわん
S式で説明してくれ

(define (難しい? 言語) (eq? 言語 '日本語))
(if (難しい? '日本語) 'S式でおｋ)

>>220
コラコラｗ

>>220
#<undef>

ところでSchemeの仕様にむやみと未定義が多いのは何でなの？
なにかに決めりゃいいじゃん、nil でもいいからさぁ。
とりあえず決めた方が実用的になると思うんだけど。

>>223
決めちゃったらもう変えれないだろ。
議論が尽くされてないところは決めるべきじゃないし、
実用のために不格好になるのは CommonLisp だけで十分。

common lispが不恰好とな？

少し認める

>>223
決めちゃうことが（例えば性能的な）制約になる実装があり得るから

rubyとか酷いよね

gauche上の話なのですが、

(definc-syntax member
　(syntax-rules () ((_ name) (name :init-value 0))))

(define-class <test> ()
　(member X))

こうすると、どうも(member X)の展開が上手くいかないようなのです。
これを上手く展開させる方法はありますか？

>>229
本質的にマクロをわかってない。
あくまでもそういう書き方で展開させたいなら結構めんどいことになるよ。

評価される場所でないと、マクロは展開されない。
define-class ごと再定義するのが良いだろう。

>>230-231
ありがとうございます。
他のやり方を考えてみます。

writeとかdisplayが真値を返さない可能性があるので
and-let*とかで処理をつなぐ時にいちいち
(begin (write obj) #t)とか書くのは不恰好な気がする。
せめて#<undef>は#fにはなりえない、くらいの制約は欲しい

（とはいえ、未規定の値を返す手続きが#fを（返す｜返しうる）処理系は見たことないけど）

* が前置されていたら次の式は #t を返したものとして扱う、てな
自分用and-letを定義したらどうよ。

意味的に and じゃないとこで andなんちゃら を使っているのだから仕方ない

letをネストしたくないのと、いちいち継続を捕捉して脱出したくないだけだろ
戻り値が未定義だというのは問題の本質ではないな

朝起きたらLISPになっていますように

つまり括弧を書きたくないだけだね。
フロントエンドでも作れば？

HaskellのMaybeモナドっぽく使いたいわけですよ
いろいろマクロを書いて試してます

>>238
括弧を書きたくないのではなくて
beginで値を捨てるのが好きじゃないんです

未規定値は#fかもしれないし真値かもしれないというのも気持ちが悪いです
もしかしたら(eq? (write obj1) (write obj2)) -> #fかもしれませんし

個人的には、未規定値は使ったとたんにエラーになる処理系が好ましいな

0個の多値を返せばいいじゃない

and-let*の中で返り値が未規定な手続きを使ったり、
未規定値を比較する、といった発想が理解できない

他コンピュータとの通信プログラムなどで
画面出力するというのが主ですね
クライアントプログラムなどでREPLの介入が出来ない場合
デバッグのための出力を埋め込んだりもします

未規定値の比較は実際には行いませんよ
ただ真理値も同一性も規定されていないから
どうなるかはわからないといいたかっただけです

なぬ？ (begin (write "hoge") #t) が恰好悪いですと？
そんな時こそマクロ〜

>>244
プログラミング向いてないのでは？

(define (tree-count elem tree)
(let f ((rest tree) (count 0))
(cond
((null? rest) count)
((list? (car rest)) (f (append (car rest) (cdr rest)) count))
(else (if (eq? elem (car rest))
(f (cdr rest) (+ 1 count))
(f (cdr rest) count))))))
(= 6 (tree-count '<> '(A B C <> (A <> (X <>)) <> (<> <>))) ; => #t
こういうのでも末尾再帰になってるんでしょうか？

fの呼出しは末尾呼出しになってますね

>>239
ほんとにMaybeモナドみたいにしたいなら、そのように書くしか無いと思うよ
(有効な値は全部Justでくるむとか、逆に「有効な返り値と決してeq?にならない
値」を失敗を表すのに使うとか)。and-let*で#fを特別扱いしてるのは
「大抵の場合うまくいく」っていう一種の妥協で、>>239のアプリは
その「大抵の場合」から外れているってことだと思う。

絶版になったと思ってたディヴィグ翻訳本
いつの間にかまた売られるようになってますね
3版ではなさそうですが

little schemerの継続の所が凄くわかり辛い(関数名からして意味不)
今の段階ではこういうのもあるって知っておく程度で詳細は他の本でカバーしろって事かな？

頑張れ、ここで派を食いしばれってこと。
ドリルみたいなもんだから、逃避したら身には付かない。

何の発見もない精神論だな

結局shiroさんの記事とwikipediaとprogramming language schemeを参考にしましたけどね

ドリルでルンルンクルルンルン

>>251
具体的にどのページのどれが分からないか書かないとまともなレスは来ないよ常考。

継続渡しのネタはP.137-147ですね
あとP.160ー173のYコンビネータのネタもややこしいですね
初見では10章よりも難しく思えましたまる

P.137の multirember&co の定義で２つコレクター出てくる。
ひとつは

(lambda (newlat seen)
(col newlat
(cons (car lat) seen)))

もうひとつは

(lambda (newlat seen)
(col (cons (car lat) newlat)
seen))

実は２つとも無名関数で再帰をしている。このコレクターが再帰のたびに別な関数になっていることをちゃんと理解できてるかな?
これが分かるならP.140までは理解できているはず。つまりTenth Commandmentはコレクターを作れってことだよね。実行してみるとこうなる。

http://codepad.org/efWZQKk8

８章のテーマは確かに継続渡しなんだけど、無名関数で再帰することを上手にやるのがコレクターってこと。
９章のネタではさらに再帰のさせ方を工夫してやるとＹコンビネータを作れるというお話。

P.137からP.140が理解できればコレクターとＹコンビネータを両方とも理解できます。頑張れ。

Ｙコンビネータは memoization に役立つんだけど、それとコレクターは瓜二つで８章・９章のもとネタになっています。

＞再帰のたびに別な関数になっていることをちゃんと

無名関数で新しい関数が作れることをマクロ内でやれるようになると、プログラムの記述量を物凄く減らすことができる。
SchemeなどのLisp系言語の特徴はプログラムの記述量が少ないこと。これを支えているのが８章・９章の考え方。
ここを理解できると「Lisp脳」の人たちの考え方に近づくことが出来ます。

Tenth Commandment・・・Lisp脳で問題を考え直せ
　　　　　　　　　　　　　　　　　　　　　　↓
　　　　　　　　　　　　　　　　　・コレクターを使ってみる
　　　　　　　　　　　　　　　　　・Ｙコンビネータを使ってみる
　　　　　　　　　　　　　　　　　・マクロを使ってみる。

そういえばSchemerシリーズにはマクロの説明が無いね。Reasoned Schemerでは使ってるけど。

再帰というか自己参照ね。
それが無限の入れ子になったのが再帰。

＞それが無限の入れ子になったのが再帰。

有限じゃないと処理が終了しない常考。

弱参照も張らずにメモ化とな

chapter8,9を理解できるのがいまのところの目標であることはわかりますた。
sicp読んでみたけど1.11の反復版の答え見て「なんだこれは」と実力不足は実感しましたし。

Yコンビネータのところは
http://www.ece.uc.edu/~franco/C511/html/Scheme/ycomb.htmlとか
http://dangermouse.brynmawr.edu/cs245/ycomb_jim.htmlみながら読み返してます。

collectorについては
8章のmultirember&coは書き出したりしながら雰囲気は掴めたんだけど、最後のeven-only*&coの
一番ネストが浅いcondのelseのコレクターをどうするの？って言うところ(P.146の上から4段目)で
ボブロスばりに答えの(lambda (al ap as)...)ってのが出てくるのが、面喰らいました。

でこれはhttp://practical-scheme.net/docs/cont-j.htmlの末尾再帰と継続って項で説明されてるような考え方を使って
ようやく「なるほど」って思える程度の理解に辿りついた次第であります。

マクロはTeach yourself scheme in fixnum days、Programming Language Schemeのマクロの項
あとOn Lispとpractice schemeのpractical-scheme.netのScheme:OnLispの項を参考にしてます。

elispを一年ぐらい触ってて()に抵抗が無いぐらいは馴染んでるつもりですが、それでもここまで詰まるとは…
やっぱり生のLispってものは怒ろしいものですね。

あとmultirember&coの"&"の読み方がわかったのも収穫です、ありがとう皆

弱参照（weak reference）の話を始めたらソフト参照もしなきゃならない。
ここではコレクターやＹコンビネータの話をしてるのに。
メモ化（memoization）ですら話が遠くなるからあとにしてくれ。

そんな我が儘言われても・・・

multirember&co では lambda + collector は２つ使う。
multiinsertLR&co では lambda + collector は３つ使う。コレクターを１つ余計に使うだけ。

evens-only*&coでは lambda + collector は３つ使う。これは multiinsertLR&co と同じ。

multirember&co では a-friend の引数は２つ。
evens-only*&coでは the-last-friend の引数は３つ。コレクターの引数を１つ余計に使うだけ。

＞一番ネストが浅いcondのelseのコレクターをどうするの？って言うところ(P.146の上から4段目)で
＞ボブロスばりに答えの(lambda (al ap as)...)ってのが出てくるのが、面喰らいました。

そこで詰まるのはプログラミングの概念が原因じゃなくてP.145の３段目が頭に入ってなかっただけでしょ。
分かってるみたいだし気にしないで大丈夫。

>>267
オマエ、弱参照が話したいだけだろ。ぼくちゃん知ってるよーみたく。ガキだねｗ

ここはおまえが演説する場所ではない

>>270
オマエが弱参照を教えてやれば？
他の香具師は優しく>>257に教えてるぞ。
なんでけんか腰になるかね？

>>269 みたいなこと言ってるガキには喧嘩腰が適切

>>266
「あとにしてくれ」とか書いてる時点で「おまえの演説」だろ。
ここは私物ではない。

負け犬が暴れているようにしか見えないんだがｗ

雑音気にしないで演説続けろ

メモリリークの話はHaskellスレでもやってたね。メモ化じゃなくて遅延評価だけど。

LLFuture 動画リスト
http://www.nicovideo.jp/mylist/8224180

evens-only* (P.144)
http://codepad.org/Ys9BY5CQ

((9 1 2 8) 3 10 ((9 9) 7 6) 2)
↓
((2 8) 10 (() 6) 2)


evens-only*&co (P.145-146)
http://codepad.org/9gVuGqhM

((9 1 2 8) 3 10 ((9 9) 7 6) 2)
↓
(38 1920 (2 8) 10 (() 6) 2)

リストの中にリストがある場合の処理がちょっと面倒でした。

>>276
SRFI-45で言及されている問題？
と思ったらHaskellは素朴なグラフ簡約と等価なはずだから違う話かな？

multiinsertLR (P.141)
http://codepad.org/KCHE46Ro


multiinsertLR&co (P.141-144)
http://codepad.org/Gx9BpnQx

LとRの値を順番に辿ってみるとどのようになっているのか理解しやすいです。
この例は(col newlat 2 2)

Little Schemer Ch.8　>>258, >>278, 280

multirember&co (P.137)
http://codepad.org/efWZQKk8

multiinsertLR (P.141)
http://codepad.org/KCHE46Ro

multiinsertLR&co (P.141-144)
http://codepad.org/Gx9BpnQx

evens-only* (P.144)
http://codepad.org/Ys9BY5CQ

evens-only*&co (P.145-146)
http://codepad.org/9gVuGqhM

guile て日本語通る？

guileは日本語コードはUTF-8を認識しないけど
Latin-1の範囲の文字をサポートしてるから
マルチバイト文字をユニバイトにばらしたものを使えば
大概は事足ります
文字コードは16進表記ではなく8進表記が使われます

guile> (string->list "こんにちは")
(#\343 #\201 #\223 #\343 #\202 #\223 #\343 #\201 #\253 #\343 #\201 #\241 #\343 #\201 #\257)

@Part19
483 ：デフォルトの名無しさん：2008/02/07(木) 12:51:51
    guileはutf-8で日本語は使えないのでしょうか？
484 ：デフォルトの名無しさん：2008/02/07(木) 20:44:33
    >>483
    > guileはutf-8で日本語は使えないのでしょうか？
    guile> (let ((s "日本語表示テストです．"))
    (string? s))
    #t
    guile>
485 ：デフォルトの名無しさん：2008/02/07(木) 20:51:57
    日本語が使えるが何を意味してるかによる
486 ：デフォルトの名無しさん：2008/02/07(木) 21:12:09
    まあ、日本語なんてこっちじゃ乞食でも気違いでも使ってるからね
487 ：デフォルトの名無しさん：2008/02/07(木) 22:59:39
    gosh> (define (日本語が使えますか?) #t)
    日本語が使えますか?
    gosh> (日本語が使えますか?)
    #t
488 ：デフォルトの名無しさん：2008/02/07(木) 23:27:38
    日本語schemeｷﾀｺﾚ
489 ：デフォルトの名無しさん：2008/02/08(金) 00:20:27
    全角カッコのあつかいはどうなるのでしょうか
490 ：デフォルトの名無しさん：2008/02/08(金) 01:27:27
    全角なんてありませんよｗ

497 ：デフォルトの名無しさん：2008/02/08(金) 10:33:35
    guileでUTF-8で
    guile> (define hoge "ほげほげ")
    guile> hoge
    "?\x81??\x81\x92?\x81??\x81\x92"
    guile> (string-length hoge)
    12
    となってしまうけど、4にはならないの?
498 ：デフォルトの名無しさん：2008/02/08(金) 15:26:02
    >>497
    guileではcharacterは8bitだったはず
    (integer->char 256)はエラー
    バイナリデータと文字が混在するファイルを扱う場合は
    こっちのほうが割り切って使えるからいい
499 ：デフォルトの名無しさん：2008/02/08(金) 16:31:45
    ちょうどいいからお前らにUTF-8の文字数を数える
    プログラムでも書いてもらおうかな。
    【問題】上のGuileのような文字列のバイト列を
    UTF-8とみなし、その文字数を返す関数を書け。

昔のイライザ、ドクターを思い出してしまったよ。
ttp://talk.oyasuminasite.com/

眠れぬ夜は話し相手に。

Little Schemerの８章・９章はLispらしい考え方が出来ないと難しく感じる。
８章のテーマは自己参照と継続渡し（コレクター）
９章のテーマは再帰とＹコンビネータ
他の言語（例えばRubyとかJavaみたいな手続き型言語）ではあまりお目にかからないから、
一読して直ぐに理解できない人の方が多い。

まぁ上のアレを継続渡しといわれても例が悪すぎると思うが

>>288
凄くお詳しそうなので継続渡しの素晴らしい例を教えてください。ちょうど悩んでました。

>>289
素晴らしいかどうかじゃなくて、
一読して直ぐに理解できるかどうかの話だけど。

「継続」に2個以上の引数を渡すとか、わかりにくいかなと思っただけ。
既に多値を理解していることを前提にしているのかな？

＞既に多値を理解していることを前提にしているのかな？

してないでしょ常考。Little読んでる人達だから。

『多値』
http://practical-scheme.net/wiliki/wiliki.cgi?Scheme%3A%E5%A4%9A%E5%80%A4

>>287
＞ Little Schemerの８章・９章はLispらしい考え方が出来ないと難しく感じる。
ではどうしたらLispらしい考え方が出来るようになりますか？

>>292
写経

>>292
Little Schemerを読む。

何その循環依存

>>295
(define (写経) (Read-Little-Schemer))
(define (Read-Little-Schemer) (写経))

すごいや！Schemeならタダの無限ループだよ！＞＜

循環再帰を乗り越えてこそ、Lispらしい考え方が出来るようになれるということでは？ｗ

>>298
(define (写経 理解度)(if (= 100 理解度 ) '終了　(Read-Little-Schemer (+ 理解度 1))))
(define (Read-Little-Schemer 理解度) (写経 理解度))
(Read-Little-Schemer 0)

(define (写経 理解度)
(if (= 100 理解度 ) '終了　(Read-Little-Schemer (+ 理解度 1))))

(define (Read-Little-Schemer 理解度)
(写経 理解度)
(display 理解度)
(newline))

(Read-Little-Schemer 0)

これを継続（コレクター）で書いてみてください。

さすがおまいらw

こんな感じでしょうか？

(define (写経 理解度)
(if (= 100 (car 理解度))
(display 理解度)　
(Read-Little-Schemer (cons (+ (car 理解度) 1) 理解度) 写経)))

(define (Read-Little-Schemer 理解度 col)
(col 理解度))

(Read-Little-Schemer '(0) 写経)

復習
((lambda (f)
(lambda (g)
(f (lambda (x) ((g g) x))
(lambda (x) ((g g) x)))))
(lambda (写経)
(lambda (理解度)
(if (< 理解度 100)
(写経 (read-little-schemer 理解度))
'終了))))

Yコンビネータを使うならこんな感じ。
read-little-schemerも括り出した方がイイけど。

(((lambda (f )
((lambda (x )
(f (lambda (y) ((x x) y))))
(lambda (x )
(f (lambda (y) ((x x) y))))))
(lambda (写経)
(lambda (read-little-schemer)
(lambda (理解度)
(if (< 理解度 100)
(写経 (read-little-schemer 理解度))
'終了)))))
0)

まだやってんのかｗ

>>303-304
両方とも
#<procedure>
が返ってくる。

(loop
(read 'hyper-spec)
(disassemble (compile nil (write-great-code)))
(read 'ia32-instruction-set))

>>302-304
こういうことをやりたかったのかな？

(((lambda (f)
((lambda (x)
(f (lambda (y) ((x x) y))))
(lambda (x )
(f (lambda (y) ((x x) y))))))
(lambda (!)
(lambda (n)
(if (= 100 (car n))
(begin
(display n)
(newline)
(display "終了"))
(! (cons (+ (car n) 1) n))))))
'(0))

>>303-304
Yコンビネータを分離した書き方。

(define Y
(lambda (f)
((lambda (x)
(f (lambda (y) ((x x) y))))
(lambda (x )
(f (lambda (y) ((x x) y)))))))

(define (写経 Read-Little-Schemer)
(lambda (理解度)
(if (= 100 (car 理解度))
(begin (display 理解度) (newline) (display "終了"))
(Read-Little-Schemer (cons (+ (car n) 1) 理解度)))))

((Y 写経) '(0))

>>281でコレクターをcolと書いてるのでそれに似せて書くなら、Yコンビネータは

(define Y
(lambda (col)
((lambda (x)
(col (lambda (y) ((x x) y))))
(lambda (x )
(col (lambda (y) ((x x) y)))))))

と書けます。
ちょうど>>301の写経というのがコレクター関数みたいになってると考えると分かり易いと思います。

もうひとつ階乗計算。

(define Y
(lambda (col)
((lambda (x)
(col (lambda (y) ((x x) y))))
(lambda (x )
(col (lambda (y) ((x x) y)))))))

(define (Fact my-fact)
(lambda (n)
(if (= n 0)
1
(* n (my-fact (- n 1))))))

((Y Fact) 10)

>>310とあわせて考えるとLittle Schemerの９章も理解し易いでしょう。

Little Schemerの９章はこんな関数です。

(define Y
(lambda (col)
((lambda (x)
(col (lambda (y) ((x x) y))))
(lambda (x )
(col (lambda (y) ((x x) y)))))))

(define (mk-length length)
(lambda (l)
(cond
((null? l) 0)
(else (+ 1 (length (cdr l)))))))

((Y mk-length) '(Little Schemer Seasoned Schemer Reasoned Schemer))

mk-lengthがコレクター関数みたいになっていて、Ｙコンビネータを括り出す説明を丁寧に行っています。
そして、コレクター関数というのがやりたいことの大事な部分を抽出したものになっているのも理解できるでしょう。

最後に>>281の multirember&co を３引数のＹコンビネータを使って書き直しておきます。
http://codepad.org/JS40NwIb

(define Y3
(lambda (M)
((lambda (future)
(M (lambda (arg1 arg2 arg3)
((future future) arg1 arg2 arg3))))
(lambda (future)
(M (lambda (arg1 arg2 arg3)
((future future) arg1 arg2 arg3)))))))

自分でやってみてください。うまく出来たでしょうか?

Little Schemer Ch.8　>>281のＹコンビネータ（Y〜Y5）

multirember&co (P.137) ・・・ Y3
http://codepad.org/JS40NwIb

multiinsertLR (P.141) ・・・ Y4
http://codepad.org/x4lUHXtg

multiinsertLR&co (P.141-144) ・・・ Y5
http://codepad.org/8vB4xkrZ

evens-only* (P.144) ・・・ Y
http://codepad.org/0uccVIHy

evens-only*&co (P.145-146) ・・・ Y2
http://codepad.org/KbHy4nk9

これを全部見ればＹコンビネータに慣れてしまってもう難しく無いと思えるかもしれません。

defineはトップレベルや本体の開始においてのみ有効らしいですが、何でですか。

(if #t
　　(begin
　　　(define x 1)
　　　x))
こんな式を有効にすると何か文法的にまずくなるんですか。

スコープが不明瞭になるのでは？

そういうのはletを使って欲しいからじゃないか？

>>315
コンパイルする処理系で効率落ちるからじゃね?

>>315
beginがスコープを作らないのは、複数のdefineを生成するマクロを書くのにbeginを使うため。
たとえば、

(let (...)
　(multi-define-generating-macro)
　body ...)

これが

(let (...)
　(begin (define foo ...) (define bar ...) ...)
　body ...)

こんなふうに展開された時、beginの中だけでスコープが完結したら困る。

beginはRnRSで明確に規定されていないし、実際に処理系に依存した解釈がされている。
このスレではGaucheと異なるDrSchemeの処理が異端扱いされたことがあった。
TOPレベルでのbeginの処理についてだったかな。

begin中の継続の扱いについてでしたね

>>315ですが、これはbeginの話なんですか？
(if #t (define x 1))
これをDrSchemeで評価すると、
define: not allowed in an expression context
となるのですが、なんでdefineがexpression contextで許されないかが知りたいのですが。

スコープが不明瞭になるのでは？

>>323
もうちょっと詳しくお願いします。

defineした x はどの範囲で有効？

トップレベルで有効、ということにすればいいと思うんですが。

関数内では使えない、トップレベル専用の例外として導入したいということ？

はい。

静的スコープを旨とする Scheme では、動的にスコープが変わる（たとえトップレベルでも
宣言されているかどうか、という事実が変わる）のは好まれないのじゃないかなあ。
(define x デフォルト値)
(if なんちゃら (set! x ほげほげ))
みたいなんじゃ駄目？

>>329
>動的にスコープが変わるのは好まれないのじゃないかなあ。
そうかもしれません。

> 〜みたいなんじゃ駄目？
普通はそうすると思うのですが、疑問に思ったので質問してみました。

Gauche原理主義のヤラセでした。ｗｗｗ

　 　 　　　　　　　　　　　　　　　　　　　　 　 _, ,_
　　　　　　　　　　　　　　　　　　　　ｗ　　（ ・ω・ ）
　　　　　　　　　　　　　　　　　　　　(~)､ /　　　i　 ）
　　　　　　　　　　　　　　　　　　　　 ＼ `　|＿/　/|
　　　　　　　　　　　　　　　　　　　　　 `ー_（　__ノ　|
　　　　　　　　　　　　　　　　　　　　　　 （　 `（　 ､ﾉ
Gauche原理主義のヤラセでした。ｗｗｗ_ﾉ`i__ﾉ

「DrSchemeはR6RSに対応していました、なぜです？」
　　　　　　　　　「やむをえんだろう、TOPレベルで継続が出来ない処理系が、何になるか」
　　　「荒らすことはありませんでしたな、総帥・・・・。」
　　　　　,! 　 ﾚ'~`'ｰ-!!　　 〉-'" ,.r'"　　 ﾞi,　　　　　　　 ﾞ,:.:.:| 　-t:r:.、――- ､..:::::::::::
.　 　 　 ,!　　　`''ｰ､, ,! ﾞi, / ﾞi,-'"　　　　　ﾞi,　 　 　 　 ,r'ﾞ`i,:.|　 　 `"ー‐'''"~:.:.:::::::l:.:.:.
　　　　 ,!　　　　　　 ﾞヽ. ﾞi　/　　　　__　　 ﾞi,　　　　　i　'ヽ.i:.l　　,;;''"￣￣:.:.::/:::::::|:.:.:.
　　　　,!　　　 _,..,_　　　ヽﾚ'　　,,､r'＿ ヽ.　 ﾞi,　　　　 |　/ゝl:.l,　":.:.:.:.:.:.:.:.:.:.:::::::::::::|:.:.:.
　　 　 !　 　,ri-､-‐､ッ_､ｰ-r'' <,"ゞ'ノ'' |.:.ヽ. ﾞi,　 ,r=,､i,　i,ヽ,ﾞi'i　:.:.:.:.:.:.:.:.:.:.:.:::::::::::::|:.:.:.
　　　 ,!　 ,r':.:|i,　 ￣　　_,r--､,　￣ﾞ`　,|:.:.:.:.|ヽ.〉''ゝ=ﾉﾞi,　ヽ.)i,!　.:.:.:.:.:.:.:.:..:.:.:.::::::::::|:.:.:.
　　　,! 　/:.:.:.:i ﾞi、　 ,r'"　l　 　 `ヽ､_/::l:.:.:.:.:|,:' 　 ,.:' .　 ﾞi,　 λ　.:.:.:.:.:.:.:.:.:.:.:.:.:.::::::!;:;:,､
　　　!. /;;l.:.:.:.:.i　 `" 　 　 ｌ　　 　 　 :::,!:.:.:.:./'t._,.:'l　 　　　`‐'|',　 .:.:.:.:..:.:.:.:.:.:.:.:.:.:.:.::':':'
　 　 !/;;;;;;l:.:.:.:.:ﾞi,　　　　　 l　　　　　 ::,!:.:.,:''t.／;;;;|　　　　　　| :':,　.:.:.:.:.:.:.:.:,,＿＿＿__
　　 〈;;;;;;;;;;ﾞ:,:.:.:.:.:ﾞi,　　　　 ,!　　　　 .:/,.,:'　,:':;;;;;;;;;,!　　　　　　| :.:.':､ .:.:.:.:.:.:.:.:.:.￣￣￣
　　　ﾞi,;;;;;;;;;;;;':,:.:.:.:.i'i, 　 　 t　　　　,/:'!,''-');;;;;;;;;;/　 　　.　　　|　:.:.:.ヽ. .:.:.:.:.:.:.:.:.:.:;;;;;;:.:.:
　　　　ﾞi,;;;;;;;;;;;;ﾞヽｲ　ﾞ:,　　 ',　　 ,r',:'　　,:';;;;;;;;;ノ 　 　 　 　.　 |　.:.:.:.:.:ﾞ:､ .:.:..:..:.:.:.:.:.:.:.:.:.:
　　　　　ヽ､;;;;;;;;;;;|　　 ヽ、　_,,ノ,ri､､_,,:';;;;;;／　　　　　 　 　r.'!　 .:.:.:.:.;;::ﾞ:､:.:.:.:.:.:.:.:.:.:.:.:.
　　　　　　　　　　　　　　　　　　　　　　　　　　　　「ふっ・・・冗談はよせ」
　　　　「兄上も意外とあまい様で・・・・。」

codepadっていつまでみれるんでしたっけ。
しばらくPCでネット出来なくて、、

>>334
心配やったら魚拓とっとけ

>>315
自前の処理系では通るよ。
そのdefineはトップレベル束縛。
常識的に考えてbeginにスコープはない。(begin != (let () ...))

R5RSに
beginはlambdaから導出されるよ
でも定義は書けないよ
しかもトップレベルのbeginは導出式じゃないよ
なんて書かないで
(CLで言う所の)特別式ってことにすればいいのに

僕の肛門もbeginを導出しそうです＞＜

>>337
特殊形式を少なくするってのも、
Schemeの初期の設計方針の一つだったからねえ。
意外とトップレベルの意味はややこしくてR6RSへって流れじゃないですかね。

実装の都合を無視してデザインの正しさを追求する
Lisperはいつだってそうだ

>>340
え？

car とか cdr とか

>>339
導出できる物はマクロでもいいけど
定義込みのbeginはトップレベルでなくても導出できない
必須だけど導出できない物はプリミティヴで用意しなくてはいけない
beginは必須（マクロ展開後に必要だったりするから）
なのにR5RSまでではbeginがあまりに宙ぶらりん
R6RSはまだよく読んでないけど

>>320-321
前スレでの話
http://pc11.2ch.net/test/read.cgi/tech/1211381920/327
＞723 名前：デフォルトの名無しさん 投稿日：2008/06/18(水) 23:37:58
＞Scheme初心者の俺が通りますよ
＞質問なんだけど、トップレベルってなんか特別なの？
＞
＞(define cc #f)
＞
＞;A
＞(display (call/cc (lambda (c) (set! cc c) (cc 'hoge))))
＞(display 'fuga)
＞(cc 'moga)
＞
＞;B
＞(begin
＞(display (call/cc (lambda (c) (set! cc c) (cc 'hoge))))
＞(display 'fuga)
＞(cc 'moga)
＞)
＞
＞トップレベルでこーやったとき、Aが無限ループにならないのにBが無限ループになるのが理解できないの...

当時は「Lisperさん」が暴れてて話が途切れてしまったと思う。

リンク間違えたｗ
×　http://pc11.2ch.net/test/read.cgi/tech/1211381920/327
○　http://pc11.2ch.net/test/read.cgi/tech/1211381920/723

＞当時は「Lisperさん」が暴れてて話が途切れてしまったと思う。

Common Lispスレからわざわざ来て「SchemeはLispではない」という人いるね。
推薦図書スレで他の言語厨に同じことやって切れられたんだったね。

>>341
たぶん、MITとUCBの考え方の違いを言いたいんだろう。

>>336
素朴な実装の処理系なら普通は通ると思うけど、
少なくともR5RSを目指している処理系では本当は通っちゃだめなんじゃ？

>>348
自分は336じゃないしRnRSでは通っちゃいけないと思うけど
(define x #f)
(define (foo) (set! x hoge) ...)
みたいなダサい書き方はどうにかならないか、とも思う
CLだと簡単な
(let ((x piyo))
  (defun foo () xにアクセスしたり変更したりするコード)
  (defun bar () xにアクセスしたり変更したりするコード))
みたいなことがどうしてできないのか、せっかくのレキシカルクロージャなのに、とも

>>349
古いSchemeでは出来たんですよ。

((lambda () (define x 1)))
を評価すると定義の後にexpressionがないといって怒られますが、
なぜ定義だけで終わったらだめなんでしょうか。
意味がないからでしょうか。

>>347
理解した。

(lambda () )
⇒lambda: bad syntax in: (lambda ())

((lambda () ))
⇒lambda: bad syntax in: (lambda ())

((lambda () (define x 1)))
⇒begin (possibly implicit): no expression after a sequence of internal definitions in: ((define x 1))

((lambda () (begin (define x 1))))
⇒begin (possibly implicit): no expression after a sequence of internal definitions in: ((define x 1))

((lambda () (begin (define x 1) x)))
⇒1

((lambda () (begin x)))
⇒reference to undefined identifier: x

((lambda () (begin 1)))
⇒1

((lambda () (begin )))
⇒begin (possibly implicit): bad syntax (empty form) in: (begin)

>>347
＞MITとUCB

R6RSを推進してる連中はもっと考え方が違うけどな。

>>315, >>322, >>351
なんか質問しっぱなしだね。分かったのかまだ疑問が残ってるのか・・・
defineじゃなくトップレベルのbeginの話だってのはおｋ？

beginを特別扱いするのやめろよ
区別するのはdefineの方だろ

>>349
普通はxを外に出さずにこうするだろ?

(define foo nil)
(define bar nil)
(let ((x piyo))
  (set! foo (lambda () ...))
  (set! bar (lambda () ...)))

マクロでくるんで簡単そうに見せるのもなんとかなりそうな気はする。

>>356
＞beginを特別扱いするのやめろよ

理由は？

(define foo)で値未定義だけど、
symbol/variableは存在することにしてくれたら、
意味のある値を設定する前に参照するバグを、
実行時に補足できるのにな。

>>356
トップレベルのbegin特別扱いがないと、
マクロ等でちょっと厄介。例えば>>357。

>>357
(define foo nil)
⇒reference to undefined identifier: nil

こんなん出ましたｗ

(define-syntax display-line
(syntax-rules ()
((_ a)
(begin
(display a)
(newline)))))

(define-syntax foo!
(syntax-rules ()
((_ a) (set! a "foo"))))

(define-syntax bar!
(syntax-rules ()
((_ a) (set! a "bar"))))

(let ((x 'piyo2))
(display-line x)
(foo! x)
(display-line x)
(bar! x)
(display-line x))

(let ((x 'piyo))
(define-syntax foo!
(syntax-rules ()
((_ a) (set! a "foo"))))

(define-syntax bar!
(syntax-rules ()
((_ a) (set! a "bar"))))
(display-line x)
(foo! x)
(display-line x)
(bar! x)
(display-line x))

define-syntaxはトップレベルでしか使えない

>>363
使えますが何か？

>>356, >>357, >>363

>>364
define-syntaxは*R5RS処理系では*トップレベルでしか使えない、でよろしいか？

>>355
>>315,>>322は>>330で一応納得しました。
>>351はこの２つとはまた別のことだと思うのですが？

351はinternal-defineを変換するとletrecと等価だから、
bodyがないということで怒られるんだよ。
最近のやつって細かいことにうるさいけど、
肝心のプログラムは作ってるのか？

とはいうものの
空理空論にとりつかれる奴はプログラム作ってるか作ってないかに関係ない
まあ共通点は理屈をしっかり勉強してない奴だな

>>368
納得しました。
> 肝心のプログラムは作ってるのか？
インタプリタを書いているんです。
質問した式は、素朴に実装した処理系なら普通通ると思いますし、
通ってもそんなに問題にならない気がするのに、DrSchemeでは通らないので疑問に思って質問しました。
確かに細かいことかもしれませんが、だからこそ気になるものじゃないですか？
なぜこんなものまで検出するように実装してあるのかと。

規格として許されていないものはちゃんとエラーになってくれたほうが良いという
考え方もあるのだ。

黒板の人の不思議:

曰く、

「今日紹介する Allegro eli (Emacs Lisp Interface) はわたしに取って最も大きな理由の1つになります。」

Emacs LispってANSIスタンダードだっけ?

「implementation が言語の semantics を決めるような言語 (perl, ruby, python, etc) は、まじめな開発には使うべきではない。」

implementationが言語のsemanticsを決めているEmacs Lispで書かれた拡張はOK?
それともエディタ類はimplementation が言語の semantics を決めるような言語を使ってても良い?
良く分かんないや。

この論法からすると、Allegroで書かれたエディタ以外ではCLのプログラムさえ書いちゃいけない希ガス

(CL -> Scheme) -> (C -> CL)
0が偽をあらわさない。
これは実用面から見ると相当マヌケな仕様でジョークのネタくらいにしかなりません。

> Scheme はその仕様に iteration を持ちません。
call/ccでループすればいいのでは？

> single name space に固執するのは、単に funcall を使いたくないだけ、というひどく 下世話な理由 のみによるのではないかとわたしには思えてなりません。
> そのわりには apply に拒否反応を示さないという自己矛盾に気がついている Schemer というのは少ないように見えます。
(foo x y z) = (funcall #'foo x y z)じゃなくて
(foo x y z) = (funcall foo x y z)ならfuncallがあってもいい。
Schemeのapplyは(foo x y z)を(apply #'foo '(x y z))なんて書かない。

(apply #'foo '(x y z)) -> (apply #'foo (list x y z))

>>372
ギャグのつもりで言った/書いたのに真面目にとられて大弱り
いまさらギャグでしたとも言えないし

なにか懐しい光景だな…最近Schemeはじめた人？

>> 372
プロダクトとして残るものを何で作るかとそれを作り上げるために使う道具との
区別もできないのか。一生バイナリエディタでマシンコード直接入力でもやってろ。

なにこの今更マジレスの嵐ｗ

春だなぁ。

冬だろ。

やれやれ

まあ黒板の人は言うだけ番長ってことで…

＿＿＿＿＿＿＿＿＿＿＿＿＿（
|　　　　　　　　　　　　　　　　　　　＼
| 　／／　 ／￣￣　＼　ズン　　　　＼乂八　　　　へ
|／／|　　(([]匚●二］))　∧　ズン　　　｜　＼　　｜　|　　　　　　 　　＼｜｜｜／
|ゝ|￣￣|７ (((((曰)))))／　　ヽ＞　　　　　|　　　）　　|　｜＼　　　　　＼　が 　 G　／
|　＿＿＿＿　　　　　|＝＿　　）　　　　　丿　ι（　　｜｜　　|　　　　―　き　　a　 ―
|　|ＩＩ ＩＩ ＩＩ ＩＩ ＩＩ|（〇　／◆く丿ヽ/　　　　　/　　　　 ）　｜　|　　|　　　 　―　た　　u　―
|（）⌒|￣＼／＿／へ　／　　　　　　　　|　ι　　 （　丿　　　|　 　　　 ―　ぁ　　c　―
|人（ξ厂１、巛《丿ー′　　　　　　　　　|　　ι 　　（　　 /／　　　　　―　！　　h　―
|　　　　Ｌ「　＼　　　　　　|　　　　　　　　｜　　　　　　＼/　イ　　　　　／　　　　e　＼
| 　 　／|| ＼◎　　　||　||＼　　　　　　　　|　　　　　　　　　丿人　　　　／｜｜｜＼
|　　/　||　||　　|￣| 　||　||　|　　　　　　　　＼　　　　　　　　　　　）　　　　　　　
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣　＼　　　　　　　　ん
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣＼　　/　＿＿＿＿
　　　　　　　　　　　　　　　　　　　　　　　／￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　　　　／

＿＿＿＿＿＿＿＿＿＿　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
――――――――――――――――――――　―――――――――――――　　　　
＿＿＿＿　　　　＿＿　　　　ぶちっ！！！ ＿　　　＿ ＼卩／―へ＿＿　＿＿＿＿＿＿＿
　／||　　⌒ゝ―（ ）ＩＩＩＩＩＩつミ　￣￣￣￣￣―――　＼/|　▽▽　　　＿＿　＼――――――
　|／＼］二（ ）ＩＩＩＩＩつミ　￣￣￣￣￣￣―――　／／／＼ []　　　　|　　＼　」―――――
＿＼　 ＼　　　　＿＿＿＿＿―――――　 ／／／―― ＼　　　　|_――Ｕ――　　　――
　　Ｌ＼　 ＼　＼ーヽ　　＿＿＿＿＿＿―　/￣し　――― ロ|ｖ|ロ　〕――――――＿＿＿
　　　　 ＼／　〉/＿◎く||　　　　　　　　　 〜巛〈っ　　　　　／　凵　　＼
＿＿＿ ＼／＼　　＾（　　＼＿＿＿＿＿　　　〜　＿＿／　　／　＼ 　＼＿＿＿＿＿＿＿＿＿
￣￣　　　＼＿く||_　　＼＿/＞､　￣￣―――――　/￣/◎＿＿＿＼ 　＼　＿＿＿＿＿＿＿
＿＿＿＿＿ ξ◎（　　　Ｌ二二ｌ＿＿＿＿＿＿＿　　|／ 丿＿＿＿＿　＼　＼＿＿＿＿＿＿＿
―――――　（ξ　　＼＿　―――――＿＿＿＿　/　//＿＿＿＿＿＿　＼ ＼―――――　-
＿＿＿＿＿＿＼＿/＼ヽ＼＿＿――――――　　ｌ二＞￣￣￣￣―――
　　　　　　　　　　　　＼￣　ノ　　　　　　　　　　　／二/ニ|
￣￣￣￣￣￣￣￣　　￣　　￣￣￣￣　_￣￣￣￣￣￣￣　￣￣￣￣￣￣￣　￣￣￣￣￣

　　　　　　　　　　　　7７　　　　＿＿
　　　　　　　　　　＝＜##　　／　／￣￣￣
　　　　　　＿＿＿//＿|＿/＿_/
　　　＿ヽ〓＼　_/γ⌒ヽ　　　＿＿＿＿
／／　　／／ヨコ.人_￣ﾉ　_／／∋.ヽ￣￣ヽ
＼＼＿_＼＼ヨコ＿／￣￣＼＼∋ﾉﾉ＿＿ﾉ
　￣　　　　￣　　　　　　　　　　￣￣￣￣
「高速で接近する機影があります」
「ザコか？」
「ありえません。通常のザコの３倍のスピードです。」
「ｶﾞ、ｶﾞｳﾁｪだ、、赤い彗星のｶﾞｳﾁｪだ、逃げろ！」

　　＼　　.　　　　　.　　　　　　　　　　　　　　　　　/　　　　　　／
ズ.　　＼　　　　　　　　　　　　　　　　　　　　　.　/　　　　　／
　　ゴ　　＼　　　　　　　　　　　　　　　　　　　　/　　　　／
　　　　ォ　　＼　　　　　　　　　|　　　　　　　　/　　　／
　　　　　　ォ　　　　　　　　　　｜　　　　　
　　　　　　＿＿＿__、　　／￣‖￣＼　　　　　　　　∧
...　　/　　　　　　//　_(((′　　‖　　　...)))＿＿　　/　∧
　　/　　　　　　//　　(((　||＼＿＿／||　)))　　　／⌒⌒⌒　＼
　/＿＿＿＿//　　　(((＼＼　●　／／)))　　　し
｜/――――　　　　　(((((((（￣￣）)))))))　　　　し　　　　　　　）
｜|Γ　　‖　/_＿＿.　.　　＼――／　　　＿＿＿し　　　　　ノ
｜|｜　　‖ｌ　　　　　　ｌ　　　[Е∃]/　　ｌ　　　　　　|_　Ｖ　ノ
｜|｜＿...　ｌ＿_　　　　ｌ　.　　　　　　　　　ｌ　　　　＿_ｌ　　/
｜|　　＼ 　＼..　　　　＼￣＼　　／￣／　　　　／　　/
　　　　　
　　　　／　　　　/　　　　　　　　　　　　　　　　ゴ　＼　　　
　　／　　　　　/　　　　　　　　　　　　　　　　　　　ォ　＼　　
／　　　　　　//　　　　　　　　　　　　　　　　　　　　　ォ　＼

「見せてもらおうか、連邦のR6RSの性能とやらを」

＿＿＿＿＿＿＿＿＿
|　＿＿＿＿＿＿＿　｜　「プログラミングしてる最中に、どうやってバグに
|　|　　　　　　.　　　｜｜　　　　　　　　気を付けろって言うんですか？」
|　|　　/　ノノ人..ヽ　|　|　　『大丈夫、あなたなら出来るわ』
|　|／　　б　б　＼|　|
|　|＼...　人ー人　／|　|　　「・・・おだてないでください、、。」
|　|__.＿＿＿＿＿＿|　|　　『カタパルトへ！』
|＿＿＿＿＿＿□□□|

　　　　　　　　　　　　　　　　　　入
／￣ ＼　　　　　　　　　　　　∧）＼
|　：　あ |　　　　　　　　　　　ノ　| |　　＼　　　　　　　　／￣＼
|　：　　 |　　　　　　　 　／| |　　| |　　）人　　　　　　　|　お　　|　　　　　　　　　　　　　
| セ　あ |　　　　　　　/　 | |　　|丿　ノ　　）　　　　　　|　高　　|
| イ　ん |　　　　　　／　丿　　丿　　　　　丿丿 　　　 |　 く　　|
| ラ　た |　　　　/ι　￣￣＼　))　　∠二 丿 　　　　 | 　と　　|
| と　 ：　|　　／|　　:（￣￣ﾟ￣厂　「く　ﾟ丿:　　　　　 　|　ま　　|
| か　：　|　　　|　　　入＿＿ノ　　　| ー　　ｌ⌒Ｉ 　　　 |　 り　　|
| い　　　＞　｜ι　〃∵　　　　　　|　∵ｌ⌒Ｉ　|ヽ 　　|　 や　｜　
| っ　　　|￣￣￣λ　∵　　　　　　　|　 　|　｜｜| 　＜　 が　｜
| た　　　|　　　 /　|　　　　　　　　〜~　　｜ ｜｜|　　|　　っ　｜
| よ　　　|　　　/　　|　　　　-―――′　/　 /　| | 　　|　 て　｜
| な　　　|　　/　　　|＼　　　　　　　´　／　 / 　/｜　　＼＿／
＼＿__／　 /丶　　　|　丶_　　　　　／　　　/　/　/　
　　　　　 Ｖ　　　ヽ　　| 　　　　　　ｌ′　　　′´　　〉
　　　　　　　　　　　　　|　　　　　　|　　　　　　　／

おいたはいけませんよ？

amd64環境だとmoshがsegvる

　　　　　　　＼..＼.／..／
　　　　　　￣￣＼|／￣￣
　｜　／￣￣＼　　／￣￣＼　｜
.　|　　＼＿＿／　　＼＿＿／　.｜
.｜＿＿＿＿＿／＼＿＿＿＿＿.|
｜　|　　　　　　　　ゝ　　　　　　|　.｜
|.　　|　　　　　＿_＿＿_　　　　｜　　|
|...　人　　　　　　⌒　　　　　　ノ　　　|

「このタイミングでの継続は古今例がない。」

///////////：。/ォ//////。、//*//θ/////////.////////////////
////////////ォ。//*/炎//.//．。//////τ///゜。//*/.//。，////*/
///////。：/ォ//　　　ヽ//σ/*///////ζ//゜///。、//.゜////////ォ/
/////.///ボ　∠＝＿　　ヽ　))))/／＼摩擦＼　/、。////，//・。、/ォ//
///炎＿＿＿‖|　●　|[]　))))/γ　⌒　ヽ　＼,////.：/．///////ォ////
///|　|￣￣　/[Εヨ]))))))＿＿（　　　　　》≫、////.///：；/:///ォ/////
///|　|／　//　/￣..　　..Γ　　人＿＿＿ノ＼。/.・：/./：/////ォ///*//
/..　|／￣/　/⌒|　|⌒‖　ζ熱�＝_　　＼＼/、。*//////ォ///.////
///／　／.＼＼｜｜　＼/(((((ノ炎/　γ⌒　◆ヽ///*///ゴ/////////
/／⌒　））//(((((（￣￣（(((((((ノ　///..（　○　ヽヽ////////)))////。
/　○／///ォ/｜‖｜　｜‖｜＼＼＼///＼　//////爆＼＼)))//、//
三／////ォ///　｜‖｜　｜‖｜＼＼＼＼　/////◆―◎　)))))　。//
///////ォ/////｜＿‖Ｌ＿Ｌ‖｜＼＼＼／/////；/◆◆￣し))))//
//////ォ/////////　＼　　　＼　　　　　　＼/./：)))///＼　　　　　　＼/
/////ォ/////////////＼　　　＼＿＿＿＿＼))))//////＼/￣/＼＿ゝ
////ゴ////////////////((＼◆　◎＿/////////////.　/　../／　／/

「少佐ぁ！トップレベルで継続できません!!!!助けてくださいぃ！！！
　　　shiro少佐ァァァァァッ！！shiroうわぁぁぁっぁぁっぁっぁぁっぁあーーーっ！」

面白いと思ってやってるんだろうか

　　　‖　　 　　　　 ‖
　　　‖　　　＿　　 ‖
　　　|│─￣|　|￣│ |_
　　　|│　　│　|　　|　|　＼
　　 /|│＿　|　|＿　|　| 　　＼
　　|　|　　　│　|　　　│ 　　│
　　|　──/　　＼─＾ 　　　　|
　　|　　＜ ＼ 　/￣￣＞　　│
　　|　─＿＿∨＿＿─ヽ　　＼　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　│| ＜二＞ 　＜二＞＼　　ヽ　　　　＜　「すまないクラウン、、、、ザコにはトップレベルで
　　// |＿＿_/￣ヽ＿＿／|　　　　＼　　　|　　継続をする能力は、、ない。だが、貴様の死はムダ
　／　ヾヽ　　 └　　　　　/（‖　　　　|　 　|　　ではないぞ。R6RSを道ずれにしたのだからな。
　＼＿＿|＼ 　￣￣　 ／（　|＿─￣　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　ヽ|＼＿＿／ |丿　　　　　　　　　

(define (面白い? AA) (eq? AA 'ガンダム))
(if (面白い? 'ガンダム) '継続でおｋ)

荒れてるなぁ
372さんの黒田さんネタに373-374でジョークネタで便乗したのがいけなかったんだろうか
だとしたらごめんなさい

キチガイに謝る必要はなかろうｗ

道ずれ
道づれ
道連れ

R6RSを道ずれにした、というのは、つまり、R6RSがSchemeの進むべき道を逸れた『道からずれた』ものになった、と云うことだったんだよ！！！

by 黒田 寿男、(株)数理システム

>>397
そう思ってるなら刺激するなＹＯ！
一般的に逝って、脈絡もなく出る罵倒(として使っている)単語は、
その人のコンプレックスを表している。

>>401
忙しければ自然とスルーをするけど、時間が余ってれば持て余すからな。結局
そうゆうことだとおもうよ。

さてネタを振るか…。
common lispではslime@emacsがあるけど、schemeではなにをつかってるの？
みんな！

>>402
slime使ってるけど何か?

なんかグローバルなシンボルを探索して見つからないところでエラー出すコードのあたりで
無効なポインタ参照して落ちてる
$ cat foo.scm
$ mosh -l foo.scm
と空のファイルを食わしてもそうなる
どうなってるんだmosh…
amd64 linux環境なのがいけないのだろうけど、x86 linuxでコンパイルしたmoshは普通に使えるし、
gaucheやpltscheme、chicken、stalinは普通にコンパイル実行できるし

ソース読まないことには何とも言えないだろ
分かることと言えばC++で書かれているとかその程度

>>404
ポインタの扱いがまずい。
64bit CPUが存在しなかった時代のコードにそういうのがいっぱいある。

moshは…

x86_64やG5でもintは32bitなんでしょうか？
64bit環境でプログラミングした事ないからよくわかりませんが
（128bit環境ならありますが）

自分の使ってるコンパイラのマニュアル読め

64bit環境持ってないもんで

環境持ってなくてもマニュアルくらい読めるんじゃね？

LP64とILP64で検索

>>409
つエミュ

http://shibuya.lisp-users.org/wiki/index.php?TechTalk_1%2FLT%E7%99%BA%E8%A1%A8%E8%80%85%E5%8B%9F%E9%9B%86

らしいよ。

SECDマシンって面白いですね！
Forthの楽しさとS式の美しさを併せ持ったって感じで。
Schemeで実装するのは簡単なのでCでチャレンジしてます。
当面の目標はシンボルと空リストとペアだけで純Lispならぬ純Schemeです。
とりあえずコピーGCだけ形にしました。
最初はペア書換なし＋参照カウントで行こうと思ったのですが
再帰の効率が悪いのと後々遅延評価を取り入れたいと考えたのでGCに変更しました。

Schemeの実装って、Schemeだけしか考えないならいいけどCで書かれた
関数を呼べるようにしようとか思うと継続との絡みを考えないわけには
いかないよね。どう解決してるの?

>>415
http://practical-scheme.net/docs/stack-j.html

難しく考えすぎ。
CのスタックとSchemeのスタックは全く別のものだと思えば簡単。
それで困ることはほとんどない。

古い話だけどちょっと教えて。前スレで、

＞ttp://pc11.2ch.net/test/read.cgi/tech/1211381920/588
＞>>265のambをlet-syntaxするマクロを書いたら、`...' が衝突した
＞http://codepad.org/FhFcRNhU
＞こうですか？わかりません！
＞http://codepad.org/DOhmrD4x
＞
＞ttp://pc11.2ch.net/test/read.cgi/tech/1211381920/589
＞http://codepad.org/DsQGNTC2
＞
＞ttp://pc11.2ch.net/test/read.cgi/tech/1211381920/590
＞PLTの拡張かと思ったがR6RSに書いてあった。

って話があった。
そのヒントに使ってケント.デヴィグ著「プログラミング言語Scheme」p.170を書き換えると
http://codepad.org/yvwb6wvY
こんな風にdoを書くことができた。
そんで思い出したが、Reasoned Schemerのパターンマッチの話でも... ...の置き換えがキモイって言ってたね。
で、調べてみたらココ
http://practical-scheme.net/wiliki/wiliki.cgi?sasagawa%3A%E6%95%B0%E5%BC%8F%E5%87%A6%E7%90%86
でも同じことやってた。でも"step"なんてやってる。
hygienic macroで(... ...)はこう使うのっておかしいのかな？

>>417
SchemeとCを相互に呼べるようにしようと思うと
Schemeから呼んだCの中でScheme呼べるようにしたいし
その中で捕捉した継続が外側のSchemeから見えてしまう可能性あるじゃない。

>>418
"step"を使った例はR5RSやR6RSのｻﾝﾌﾟﾙだね。
ttp://practical-scheme.net/wiliki/wiliki.cgi?R6RS%3A%E7%BF%BB%E8%A8%B3%3AStandard%20Libraries%3A5%20Control%20structures

>>418
Part.21の319-330でそんな話があった。
... ...の置き換えじゃなくて、...が0個でもマッチするとかいう話。

LispMeの説明にSECDマシンが出てくるよ。chap6を見てみて。

http://www.yuasa.kuis.kyoto-u.ac.jp/~nobu/study/palm/chap1.html
http://www.yuasa.kuis.kyoto-u.ac.jp/~nobu/study/palm/chap2.html
http://www.yuasa.kuis.kyoto-u.ac.jp/~nobu/study/palm/chap3.html
http://www.yuasa.kuis.kyoto-u.ac.jp/~nobu/study/palm/chap4.html
http://www.yuasa.kuis.kyoto-u.ac.jp/~nobu/study/palm/chap5.html
http://www.yuasa.kuis.kyoto-u.ac.jp/~nobu/study/palm/chap6.html
http://www.yuasa.kuis.kyoto-u.ac.jp/~nobu/study/palm/chap7.html
http://www.yuasa.kuis.kyoto-u.ac.jp/~nobu/study/palm/chap8.html

と思ったら、>>418の貼ってる
http://codepad.org/DsQGNTC2
にpush!とpop!があるのか。Gaucheにもあるし、解決。

>>419
極端な話、SchemeからCを呼ぶときは別のスレッドを走らせることにすると
Cの関数を挟む形で継続を捕捉することがなくなる。
・古いスレッドは新しいスレッドが終了するまで待機
・新しいスレッドの継続に古いスレッドの情報は含まれない
・新しいスレッドで古いスレッドの継続を呼ぶと古いスレッドが2個あるような状態になる
という感じで自然に辻褄が合う。

スレッドを使わなくても、難しいこと何も考えないで実装すればこれと同じ振る舞いになるはず。
Cの関数はRnRSの範囲外だから、どんな振る舞いだろうと問題ないと思う。

SECDマシンと云えば……

http://www.blue.sky.or.jp/grass/doc_ja.html
こんなのが。

教えてください。このforは動くのに、
(define-syntax for
(syntax-rules ()
((_ (var start stop) body ...)
(do ((var start (add1 var)))
((> var stop))
body ...))))

こっちのforは動きません。
(define-syntax for
(syntax-rules ()
((_ (var start stop) body ...)
((do ((var start (add1 var))
(limit stop))
((> var limit))
body ...)))))

どうしてでしょうか？
これは動きます。
(do ((var 1 (add1 var))
(limit 10))
((> var limit))
(display var)
(newline))

(for (i 1 5)
(display i))

doの返り値をthunkとしてapplyしてるのは意図的？

(define-syntax for
__(syntax-rules ()
_____((_ (var start stop) body ...)
______(do ((var start (add1 var))
____________(limit stop))
___________((> var limit))
________body ...))))

>>428-429
あ、恥ずかしいｗ
もちろん非意図的です。
ありがとうございます。

(define-syntax for
__(syntax-rules ()
____((_ (var start stop) body ...)
_____(let ((continue #f)
___________(var start)
___________(limit stop))
_______(call-with-current-continuation
________(lambda (x)
__________(set! continue x)))
_______(unless (> var limit)
_________body ...
_________(set! var (+ var 1))
_________(continue))))))

こんな風に書かないと黒田さんに怒られるかも
これならtail recursionじゃなくてiteration
（もちろんジョーク）

gensym使った方がlimitに置き換えるより安全化？

(define-syntax for
(syntax-rules ()
((_ (var start stop) body ...)
(let ((gstop (gensym)))
(do ((var start (add1 var))
(gstop stop))
((> var gstop))
body ...)))))

doはマクロだからそれだとgensymの返り値は束縛に使われないし
syntax-rulesではgensymを使わなくても変数キャプチャは起こらない
マクロテンプレートの展開より先に評価するトリックはない（はず）
あれば保健的じゃなくなるし

syntax-caseの時にはgensym使うのかな?
syntax-caseでも心配ないの?

syntax-caseでも心配ないです

syntax-caseもそうなんだ。CLより安全だね。
stepに対応したバージョンを考えたｗ

(define-syntax for
(syntax-rules ()
((_ (var start stop) body ...)
(do ((var start (add1 var))
(limit stop))
((> var limit))
body ...))
((_ (var start stop step) body ...)
(do ((var start (+ step var))
(limit stop))
((> var limit))
body ...))))

(for (i 2 10 2)
(display i)
(newline))

>>435
リードマクロ

(define-syntax for
__(syntax-rules (= to step)
____((_ var = start to stop step i body ...)
_____(do ((var start (+ var i))
___________(limit stop))
__________((> var limit))
_______body ...))
____((_ var = start to stop body ...)
_____(do ((var start (+ var 1))
___________(limit stop))
__________((> var limit))
_______body ...))))

(for i = 0 to 10 (print i))
(for i = 0 to 10 step 3 (print i))

(define-syntax for
__(syntax-rules (= to step)
____((_ var = start to stop step i body ...)
_____(do ((var start (+ var i))
___________(limit stop))
__________((> var limit))
_______body ...))
____((_ var = start to stop body ...)
_____(for var = start to stop step 1 body ...))))
このほうがいいか

注意
(let ((to #f))
(for i = 0 to 10 (print i)))
は動きません（マクロ使用内リテラル識別子toの束縛がマクロ定義中の束縛と違うから）
もちろんtoが=でもstepでも同じ事です

>>440
それいいね。

http://www.yomiuri.co.jp/atmoney/news/20080919-OYT1T00011.htm

なんかはてな人力検索でschemeネタまじえた質問が騒ぎになってるね
http://q.hatena.ne.jp/1221708568

>>444
なんていうか、微妙にコミュニケーションスキルの足りない困った人の宴に
Schemeが巻き込まれて可哀相、みたいに思った。

でも、そんなに不正解者が多いのか、そのQ1・・・ちょっと驚き。

>>445
これ正しい選択肢ないよね。Schemeに関数無いし。

>>444
釣り針大き杉ｗｗｗ

＞Schemeは多くのレンタルサーバに標準でインストールされている

これってプログラミング全然関係ないしwww

痛すぎて笑えん

>>445
驚くんじゃなくて、
はてなで答えたくてうずうずしている人たちのレベルが、
そういうものなんだという理解をすべき。

ってなんかそこのコメントみたいなレスになっちゃったw

>>450
いや、まともな奴はQ1を読んで「馬鹿だコイツ」と判断してポイだろw

http://q.hatena.ne.jp/1221584268
ここのQ1も選択肢が^^;

>>444
nishioがschemerだと思われてしまってるところに、怖いです。pythonの人でしょう?

他の質問も眺めてみたが…
話題にしない方がいいのでは。
逆上して荒されそうな。

>>452
完全にギャグだな

>>454
schemerへの風当たりを強くしてくれたからね。

せめてお友だちや先生に聞けよなってことで

質問内容はともかく、回答はボットかプログラミング自体知らないポイントゲッターが
適当に答えてるとしか思えないな。
参考→ ttp://d.hatena.ne.jp/tilfin/20080522/1211510834

履歴見たらshiroさん色んな所で回答しまくってるな。好きなのかな。
それにしてもピアノうますぎ吹いた

講師が宿題丸投げしてどうするでFA

はてななら職場に電凸する奴がでないから安心？

practical-scheme.net落ちてますね

これは本気じゃなくてソーカルみたいに狙ってやったんじゃないのか？

理由は？

はてなアンケートの回答者は本文すらロクに読んでない奴ばかりっていうことを示すためだろ。

http://d.hatena.ne.jp/nishiohirokazu/20080917/1221667941
http://d.hatena.ne.jp/nishiohirokazu/20080918/1221708888
釣られてる連中必死だなｗ

仮に狙ってやったんだとしても
システム的にああなるのは明らかなことで
すでに他の人も指摘してる

つまらん遊びはSchemeと関係ないところでやってくれ

(define (ネタ? はてな) (eq? はてな 'Scheme))
(if (ネタ? 'Scheme) 'その釣り針で吊れますか？)

はてなにだけは関わらないほうがいいんだということがよくわかった

srfi-98

おめ

>>467
はてな出身者がScheme処理系で売り出し中なわけだが。

おまけに、shibuya.lispの母体だw

ひげぽんをいぢめちゃだめだよ

>>471
はてな村が母体なの？こりゃ駄目だな

何が起こったのか理解できないんだが、一体何が起こったんだ？
結構、致命的？

馬鹿が馬鹿にされて逆切れした。

schemeももうおしまいなのかな。

『はてなアンケートの回答者はロクに問題文読んでない』仮説
↓
学生に教えるのに良い言語は？
Coq>Haskellとかいう有り得ない結果
↓
追試だ！
↓

『第一問に答えられない人は答えないで！』
→Scheme は多くのサーバに設置されてるらしい
↓
仮説立証
→問題文読まない子逆ギレ

shiroさんのフォローが涙を誘う
アラン・ケイと飯食ったって話はwilikiに詳しく書いてくれるかな。
ちょっと期待。

shiroさんのまとめが力強すぎてあとのことはどうでもよくなった

「初学者に勧めるのに一番適している言語」の候補と、
「実用規模のコードを書いたことがある言語」
がそもそもPythonとSchemeしかかぶっていない件について。

つまりまずは無駄な物を教えろという事ですかwww？

教育用と実用つうのは相反するものです。

基礎をちゃんと固めておけば、どんな言語でもそれなりに対応出来るように
なると思うですよ。

じゃあその基礎ってなんなの？
ていう話がもっとでればおもしろかったのにねえ

まあBefungeとかはネタだと流石にわかるがCoqとかはネタかマジかの判別にちょっと困るなwww

MITもscheme捨てたのか…。pythonでどうやって構文木いじるんだ？
pythonは書くのも読むのも好きなほうだけど、なんだか悲しいよ。

今回、誰も得をしないな。ただただ悲しくなっただけだった。

基礎はわからないけれど、本質と言うべきものの一面としては、
言語の進化・成長だろう。言語は時代とともに書き換えられて、
より現状に適した形態へと変化する、かね。カッコ良く言えば。

変化を拒んでいたら、取り残されるのは当然だよ。悲しいが。
いい加減転換の時期なんだ。
このままきれいなschemeに固執するのか、それともpythonの
生産性に匹敵するようなschemeにしてゆくのか。

綺麗なままライブラリを蓄積していけるようにするんだよ。

ライブラリの大部分はC/C++かJavaか.NETに丸投げするだけ。
綺麗なインターフェイスが先行し実装がそれに従うというのは大嘘だな。

数学では無駄なものはとことん拒絶される。schemeってそんな感じだよな。
pythonみたいに「バッテリーも付いてて生産性高いよ!」なんてのは
Schemeじゃ無理だ。

http://www.kahua.org/download/kahua/2008Fall/WayToGaucheOnRails.pdf
> 慣れればRubyより生産性が高い
だってよ。

>>444
> これだからScheme使いは非常識だって言われるんだよ。Lispなんてマイナー言語使うやついるわけねぇだろ。
じっくり読むとじわじわ面白味がわかってくるな、この一行ｗ

うちの隣あたりに脳内がshiroさんみたいな美人女子大生が住んでたら楽しそうだな・・・。

http://codepad.org/aPduLgln

ねぇねぇ、>>440あたりの見ながらマクロ練習してんだけど、
defineとdefine-syantaxってどう使い分けるのか教えて。
実行速度とか違うもの?どっちが早いの?
インライン展開みたいな使い方ならマクロのほうが速いよね？
処理系によって逆転する程度の速度差なら気にしなくて良い？

そのレベルなら速度よりも
まず機能面を重視して学ぶべき。

機能面って具体的にいうとどんなこと？

>>494じゃないけど横レスするなら
「より汎用性の高いパターン」はマクロ化して、特殊用途なら関数にまとめるってこと。
汎用性の高いパターンあたりの話を機能面と言ってる希ｶﾞｽ。
外してる？

>>493
関数であろうとマクロであろうとどのような実装になるかは処理系ごとに違う。
速度に関してはどちらを選ぶべきかは実測しないとわからん。

言語としての一般的な作法としては可能である限りは関数として、
つまり define で定義する方が良いとされてる。

評価のタイミングをコントロールしたいとかいった、
関数では出来ないことが必要になったらマクロを使うのが普通。

『汎用性の高いパターンをdefine で定義していって、
どうしても関数で出来ないことが出てきたらdefine-syntaxする。』
という判断基準を決めたと仮定してみる。

例えば、forの例で出てくる「body ...」や「step」といった可変長なことを
パターンマッチするのはdefine-syntaxでＯＫ。
aprintもdefine-syntaxでＯＫ。

でも四捨五入やkeisanは関数で良い。『汎用性の高いパターン』だけど関数で出来ない訳じゃない。
という理解で良いんでしょうか？

『汎用性の高いパターン』だけど関数で出来ない訳じゃない場合でも、
マクロ化してインライン展開みたいな使い方で高速化出来るならマクロ化する。

というのも判断基準に加えておけば良いのかな？

>>498
「引数評価」のキーワードが出てこないから失格です。

こうして誰かがてきとーに作り上げたLisp/Schemeのイメージが
バタフライ効果で大御所クラスの人間の脳まで汚染してゆく。

これがバブルか・・・

カオスでしょ

>>501-502
マクロ練習してる香具師が最初から完璧に理解できてたらオマエ等自殺するしかないもんなｗ

>>498
関数とマクロは本質的に違うものだ。 汎用的であるかどうかは全然関係ない。
なんでそこで「汎用性」を持ち出すのかまず説明しないと何を知りたいのか曖昧だぞ。

>>504
「汎用的」って言葉を使ったのは「繰り返し良く使う共通パターンを抽出したもの」って意味で使いました。
で、そのパターンが「引数評価」の順番によって影響されるか考えてみる。
>>500
「引数評価」の順番はコンパイル時だから、マクロはその前だった。
もし、評価された関数の結果を使うようになってたらマクロ化は出来ない。
そういうときはその結果を除いた別のパターンを見つける。
それで、>>498-499みたいなことを考えるけど、最後まで妙な高速化は考えない。
早い時点で変な最適化をするのは一般的には悪影響を与えることが多いから。
こんな順番で考えるのかな?

引数評価の順序よりも、するかしないかが重要。

ifをfunctionとして実装したときに起りうる問題は？(from sicp)

てことは「defineとdefine-syantaxってどう使い分けるのか」という最初の質問の答えは、
>>506
「引数評価をするかしないか」で使い分けるということか。
>>494が言ってた
＞まず機能面を重視して学ぶべき。
というのも「引数評価をするかしないか」という話？

BASICもIFステートメントがあるから遅延評価の機能を持ってると言えるのだろうか……？

などという考察を大真面目にしているブログを見つけて吹いた

>>507
lambdaさえあれば没問題

>>509 まぁそうやって成長してゆくものだ

>>507
Exercise 1.6.にAlyssaがnew-ifを使ってsquare-rootを計算したら何が起こるか説明せよとあった。
Special Formの話。

http://codepad.org/OHXrT4yy
やってみると無限ループ。
特殊形式でないと、then部、else部ともに評価を終えた
後で、分岐を評価しようとするので、自分を呼び出す再
帰が使われている場合、無限ループになってしまうから。

じゃあ、特殊形式が必要なときにdefine-syntaxが必要になる？

condの引数（笑）を思い浮かべてみろ
評価するってレベルじゃねーぞ

>>512のつづき
http://codepad.org/3KaPqn6k
最初の例ではthen部かelse部が必ず無限ループになったが、
define-syntaxを使うことで回避できる。

停止しないのは作用的順序で評価を行っているから。
引数のsqrt-iterを次々と展開している。
関数の呼び出しは引数の評価が先に行われるが、
マクロの場合は先頭から展開されるため、このような形の再帰呼び出しはマクロではできない。
もっとも、new-if関数だって遅延評価で使えるようにできるが>>509が言うように、
IFステートメントがあるから遅延評価の機能を持ってると逆に考えてはいけない。

評価順序は、MLやSchemeのような作用順序の言語と、
Haskellなどの正規順序で評価する言語では異なる。
new-if関数のような問題は作用順序の言語で起こる。

condの引数（笑）は遅延したぐらいではどうしようもないぞ

ifが特別式じゃなければいけない理由と
condがマクロじゃなければいけない理由は違うでしょ

>>512のelse部が必ず無限ループになるのはこの式で
(define (sqrt-iter guess x)
(new-if (good-enough? guess x)
guess
(sqrt-iter (improve guess x)
x)))
sqrt-iterが次々と開かれるためにおこる。condは関係ない。
だからnew-if関数が遅延評価であっても同じく次々と開かれるので無限ループ。
>>515の遅延評価の機能を持ってると考えてはいけないのはそういう意味。
new-if関数は遅延評価で使えるようにできるわけではない。

これは、sqrt-iterをマクロにしても同じ。
http://codepad.org/yt4cs2s9

new-if関数が>>514の時に無限ループにならないのは「if and only if」の条件になっている。
my-ifの場合のシンボルは特殊形式と同じ働きになる。
>>494の言っていた機能面とはまさにこのこと。

Scheme は括弧の中身を全て評価して括弧の外に値を返す関数と、それ以外の働きをする特殊形式 からなっています。
特殊形式には今見た if のほかに lambda, define, quote, set! などがあります。

関数では、先頭要素が手続きだからそれ以外の要素を先に評価し、それから先頭の手続きに引数を適用します。
平たく言えばSchemeでのマクロとは、特殊形式を定義することに他なりません。
マクロは呼び出し時の形式がsyntax-rulesの形にひっかかったとき、本体が適用される仕組みですから、
sqrt-iterが次々と開かれるためにおこる無限ループを避けることが出来ます。
Common Lispでは特殊形式とマクロという区別があります（した？）が Schemeでは両方構文として扱われます。

関数適用では call by value に従ってあらかじめ全部の引数を評価するが、
そうしないで特殊な処理をするのがシンタックス形式である。
特殊手続きじゃないnew-ifは、trueの時の式もfalseの時の式も両方簡約して
から評価しようとするため、sqrt-iterを再帰的に処理して引数を評価ようとする。
そのため無限ループに落ちいってしまう。
my-ifマクロではこのような簡約は起こらず、マクロ展開が行われてお仕舞である。

関数の評価順序についてはSICPのEX 1.5の問題から始まっている。
(define (p) (p))

(define (test x y)
(if (= x 0)
0
y))

(test 0 (p))

最後の式を実行した時どうなるか？

正規順序で評価する（Haskellなどの言語の）場合、非演算子の(p)を
必要になるまで「完全に展開し、簡約しよう」とはしない。その為に、
展開が行われないで無限ループにならないですむ。必要になったら述語を
最初に評価し、その結果if文の0だけ評価することを決める。(p)は無視される。

ところがこれをSchemeで実行すると、非演算子の0と(p)を「評価して作用させ」
ようとする。よってif文の(p)が次々と展開されで無限ループになる。
マクロを作成する時にはEx1.6とEx1.7のエラーには気をつけるべき。

(define-syntax p
(syntax-rules ()
((p) p)))

今度のはマクロでこうは書けない。マクロに出来ない例？

正規順序で評価する（Haskellなどの言語の）場合、チャーチ・ロッサーの定理により
「正規形が存在すれば必ず正規形（β簡約可能項を持たない項）に到達する」
という正規化戦略が保証されている。
従って、簡略戦略は，作用順序のSchemeでは停止性について責任を持たねばならぬが、
正規順序の言語では停止性が保証されているのである。
この話はこのスレでよく挙げられる "To Mock A Mockingbird" にも出てくる
ラムダ計算の話である。

Schemeは作用順序の言語だから、関数であれマクロであれ停止性については
責任を持たねばならない。ただし、関数は完全展開するがマクロはマクロ展開
までしか展開しない違いがある。
「defineとdefine-syantaxってどう使い分けるのか」という最初の質問に対する
ひとつの答えは、この違いが決定的に重要ならマクロにするべきということ。
そうでない限りは関数のままでおいた方が良い。最適化が効くことが多いから。
他の理由は、アナフォリックマクロやマクロ生成マクロなどが挙げられる。

>正規形（β簡約可能項を持たない項）に到達する
んでもって、その式が閉式でアリティ０だったら
その式はカノニカルな式、というわけですね？

ていうか、ただ単に４章よくわかってないことに気づいたから、
ちゃんと読んで質問しようと思ってただけなんだけどね。

それに、実のところ、回りが思っているほど大したことには
なっていないと思うよ。

pythonと連携できるlispさがしてたら
http://www.call-with-current-continuation.org/
こんなのみつけた
これってマイナーな言語なの？
他で使ってたプログラムの流用はできない？

テンプレにはいてったのか
すまそ

common lispからschmeに乗り換えようと思った理由ってなんでしょうか？

継続とtail jumpが楽しい。

末尾呼出しの最適化、継続、単一名前空間といった言語特性も大きいけど
本当のところは「言語規格準拠で、様々なCPU、様々なOSで動くポータブルな処理系がCLになかった」から
もしかしたらLisperとしてよちよち歩きの頃にポータブルなCL処理系があったらSchemerになることもなかったかもしれない
Lisperとしての自我が芽生える前にCLにフられて（というか自爆）、目の前にいたSchemeに惚れて以来一筋

あとCISCよりもRISCスキーだったから
よりシンプルな物が好きだったという傾向も影響してるかも
R3000が好きだし

>>444を読んでScheme（LISP）に興味を持ちました。
まずは無料で手に入るSICPを読もうと思います。

普段はVBA、Java、趣味でRubyです。

maximaに相当するものがschemeにあるなら乗り換えるのだけどなあ

用途次第でどっちも使えばいいんじゃないの?
俺はそうしてるが。

どうしてもCommon Lispでないとだめな用途って何だろう。
コンパイラかな?

>>539
どうしてもSchemeでないとだめな用途って何だろう。
こくばんかな?

>>537
作ってみない？
数学の勉強にもなるし。
といいつつ、わたしゃ途中で挫折している。
数式処理は簡単化がめんどい。

思いつき

http://codepad.org/zctEhM1Y
http://docs.plt-scheme.org/reference/nest.html

>>542
compact-number-listの逆関数ｷﾎﾞﾝﾇ

マクロ生成マクロ
http://codepad.org/PYA73S1q

>>543
色々いじっていたらこんなになった
(lambda (xs)
(define (foo x y z)
(if (= x y) (cons x z) (foo x (- y 1) (cons y z))))
(let fold
([f (lambda (x z) (if (pair? x) (foo (car x) (cdr x) z) (cons x z)))]
[z '()]
[xs (reverse xs)])
(if (null? xs) z (fold f (f (car xs) z) (cdr xs)))))

アナフォリックマクロ
http://codepad.org/JcuniUhD

>>545
�d。このＳ式は便利かも。
http://codepad.org/Xye6JwUI

>>537
数式処理ならJacalは? http://people.csail.mit.edu/jaffer/JACAL

>>548
installしてみた
今年の３月に出たソフトなのか
wxmaximaみたいなGUIないのかな
maximaのto_lisp();
でlisps層に降りて作業できるけど、それに相当するのみつけられなかった

>>549

自己レスです
maximaに相当する機能が一通りあるようです

maximaのto_lisp();
=
jacalのqed;

(to-maxima)
=
(math)

>>549
いや、Jacal自体はMS-DOSでも走ってたくらい古いソフト (当時から全てSchemeで書かれてた)。
だからあんまり機能は豊富じゃないと思う。枯れてるとは思うけど。

Jacalってscmですよね
scmはかなり軽いから常用したいんだけど
ビルド周りが泥臭くて
ちゃんとビルドできてるんだかどうだかわからなくて不安。
OSのパッケージ版でさえ不備があるくらい。
Bignum周りも微妙だし有理数もない。
Guileがscmくらい軽いといいんだけど。

下地貞夫著「数式処理」
を見ながら作成してる人もいるね。
http://practical-scheme.net/wiliki/wiliki.cgi?sasagawa%3A%E6%95%B0%E5%BC%8F%E5%87%A6%E7%90%86
http://practical-scheme.net/wiliki/wiliki.cgi?sasagawa%3Acomplex

common-lisp で .so か .dll 作って c から呼びたいんだけど、
商用の処理系じゃないと無理?

つ【ECL】
ttp://ecls.sourceforge.net/

百年の言語がFFIでC++を呼んだりすると思うか？

って誰かが言ってたが、
新しい技術を恐れるなとか言いつつ
古いものを使い続けることに恐怖を感じているのだとしたら、間抜けだ

誤爆乙

>>556
百年で思い出したが、なんとか2056年まで生きたい。
Lisp生誕百年だ。どうなっているのか?
実装レベルで考えると今ちょうど50年だね。

きっと3000年問題で困ってそう

950年も先の事で困りますかね？

50年後はマイノリティリポートみたいに
なんかオブジェクトを手で動かして作るんだよ
言語なんてなくなってる

パッチとか送るの大変そうだなｗ

量子コンピューターでも現れない限り、
０，１とは付き合わざるを得ないし、
アセンブラも消えないはず。
高級言語ＣＰＵが一般的になったら変わるのかな。

人間がプログラムを組むのではなくて
プログラムを組むプログラム　を組むプログラム　を組むプログラム…　を組むプログラム　を人間が組む
になる
人間側インタフェースは完全に自然言語ベースになっていくでしょう

無理だな
数式は自然言語だというオチならあり得るが

時は西暦2045年・・・
ソフトウェア会社社長「プログラムを組むプログラムが完成したので
おまえらプログラマは全員解雇な。既に競合他社は人間を全員クビにして
高い生産性、少ないバグ、人件費削減を達成してるんだ」

1000万行のプログラムを数KBのテキスト（自然言語？）に圧縮できるとか
全ての定理を少数の公理から導けるとか

情報理論っておもしろいなｗ

メタプログラマとかメタメタプログラマとか出てくるのかな
Lispは姿を変えて残ってるだろうね、本質が数学なものは長生きするよ

>>566
最終的にはすべての仕事をプログラムが行うようになる。
でも、バグがないプログラムを作ることはできないので、そのプログラムを
メンテする人が最後の職業となる。
その人はアーキテクトと呼ばれるバグを取り除くだけの簡単なお仕事です。

少なくとも俺が生きてる間は実現せんだろうな

人間とコンピュータがくっついてしまって、どこからどこまでが人間で
どこからがコンピュータなのか、きっと区別がつかなくなってると思う。
したがってプログラミングなんぞ存在しないと言えば存在しないし、
有ると言えば有るとも言える状態になっているだろう。

西暦2500年くらいには…

>>571
はいはいサイバーパンクサイバーパンク

>>555
ありがとうございます。ライセンスがよくわからなかったのですが、
コンパイル後の実行ファイルもGPLになるんでしょうか?

ECLはLGPLだし、作ったものは自分の好きなライセンスでいいんじゃない？
libecl は LGPL って点に気をつければ、かなり自由だと思われ。

>>574
thx. スタティックリンクしなければ好きなライセンスで大丈夫なんですね。

>>554
cffi

>>556
c++呼びたいなら

Verrazano
http://common-lisp.net/project/fetter/

>>576
> >>554
> cffi
cffiでどうやってdllを作るのか詳しく

ここにgccでsoを作ってLispで使う方法が書いてある。
http://lispuser.net/memo/lisp/2006-04-16-04-32.html
http://lispuser.net/memo/lisp/2006-04-19-05-00.html

でも>>554の求めてるのはdllを作ってCで使いたいから逆か・・・

ちゃんと書き込む前に良く嫁

なあ、ここの住人ならWinnyレベルのソフトなんて朝飯前で作れちゃうんだろ？

まぁ、「技術的に難しくて作れない！」って奴がいたらアホだな。

作れないよ。
もしくは、作れても作る気は全くないので作れないのと同じと思ってくれたまえ。

ゴキブリを素手で掴むレベル。

>>583
云い得て妙な。

金子氏がスゲーと言えるのは技術力よりかはアイディアだな
いくら元ネタにFreenetがあったとはいえ、
当時Winnyを着想するのは・・・・・・やはり天才と言わざるを得ない

windowsというプラットフォームならではの発想
linuxとかでああいうソフトは無理

うーんプラットフォーム依存なのかな〜

>>577
普通にＣから呼ぶdll作れば
clからも同じ名前で呼べたはず
ただしextern "C"でcにしないとだめ

maximaからJcalへの移行を検討してみたけど
maximaのplot機能を置き換えることができなさそう

lisp:(cffi::hoge)

ができないのもちょっと気になる

>>588
だから質問文良く読めよ。

CL"で"dll作るって書いてあるだろ。お前の目は節穴か。そうか。

>>590
逆向きなのね。

>>590
まぁ質問文はよく読むべきだが、単なる見間違いのレベルで熱源反応出さんでも。

すまん、気付く云い過ぎた。

いや、上の方でも同じ事指摘されてるのに同じ間違いをしてるから、ついカッとなってやった。今は反省している。

仕事上でもよくあることです。

CLerはexeは作れないという思考停止状態だからな
exeも作れんのにdllなんて作れるわけがない

何と脊髄反射の多いスレ

ループを末尾再帰でシンプルに記述した！なんて思ってしまう人間がいる。
実はその試みは問題を複雑にしただけだ。まずそこに気付いて欲しい。
相互末尾再帰はgotoよりも始末が悪く、デバッグすらままならない。
デバッグするには、全てを普通の再帰に戻す。これでやっと理解できる
レベルに落としこめる。脳は日常的にスタック構造に慣れているからだ。
では末尾再帰にも慣れればよいのでは？という反論がありそうだが、
そんな概念が日常に出てくる事があるだろうか。
残念ながら思いつかない。

パフォーマンス的に見ても、自分で必要な箇所でループや
スタックを明示的に使った方が速いのは明らかだ。

schemeは構文を少なくする代わりに、意味を重複して持たせている。
例えばクロージャと関数の同一視、これに継続も含めると、
自分で作った関数がどのように使われる事があるか、全く予測が付かない。
これではバグの予防すら困難だ。
意味が重複する事で、自分の意思が込められない。
構文を少なくまとめるよりも、構文1つの意味を単純にするべきではないだろうか。
構文だけ見てdoの繰り返しが末尾再帰だと気付く人間が、
一体どれだけいるだろうか。
わざわざ末尾再帰だと規定する必要もどこにあるだろう。
コードにプログラマの意思を込められなければ、
それは良い言語とは言えないのではないか。

持論の開陳は御自分のサイトでお願いします^^

開発者への負担が大きい言語は大抵その辺りのジレンマで破綻するよな

自分はSchemerなんですけど、ここ数日Emacs Lispのプログラムを書いてます。
597-598さんとは逆にループでプログラムを書くのに苦労してます。
末尾再帰最大の利点は参照透明性を保ちつつ変化する値を扱える点だと思います。
継続の特別扱い（末尾文脈でなくても継続を破棄すること）は自分もおかしいとおもいますけど。
Wilikiでも前に話題になってた「なぜcall/ccが副作用をもたらすのか」の原因にもなってると思います。

ちょっと間違い。
参照透明性＋値の変化はふつうの再帰でも扱えますね。
定数空間でそれを行えるのが末尾再帰の利点ですね。

？？？

おれは逆にfor文を書くのが苦痛で仕方ないんだが。
>>598 のような感性があることは認める。だがそれをむやみに一般化しないでくれるか。
世の中には少数ながら、再帰とTCOの方が自然に考えられる変な種類の人間がいるのだ。

forが駄目ならloop, iterate, seriesマクロを移植して使えばいいじゃない

マチルダさん＜あなたはLisperかもしれない
Lisperはニュータイプなんだろうか？オールドタイプなんだろうか？

TCOの意味がしばらくわかりませんでした。

末尾再帰でループすると多重代入みたいになる。
代入の順序が前後するのが嫌なときは使える。

forが嫌いだとjavaやCがつらいだろうな〜…

JavascriptのforEachは好き

Pythonのforは好きですね

forは好きだけど、なぜかlisp系で使おうという気にならない。
と言うわけでお前らloopを使おう。

それはよくない、それはよくないよマチルダさん！

loopってマクロでしょ？中身何でできてるの？

>>613
括弧とスペシャルフォーム

loopマクロはCっぽい手続型DSLをS式に変換する500行未満で書ける小規模のコンパイラだよ
schemeで実装した原始lispと大体同じ作り
DSLをパーズして一つのS式に畳み込んでゲロるだけ

その調子で全部Cっぽい手続型DSLにしてしまうのはどうだろう

loopは超一流のギャグだ
あれを実装しようとすると心の底からイラつく

iterateの方が簡単かもな

>>615
500行未満って小規模なのか？loopとformatは実装しろと言われたら泣くｗ

でもひげぽんの問題も、loopでの回答が一番美しいな。
ttp://d.hatena.ne.jp/higepon/20080925/1222326246

Yow! Loop macrosでググれ。
Comp.Lang.schemeの記事が見つかる。
それをコピペすれば解決。

>>620
�d。loopを使ってみた。そのページのは長いので改造した。
lisp系なのにreturnとか笑えるｗ
http://codepad.org/QeJlUSpa

lisp系の良い所は末尾再帰でもループでも使える自由度にあるわけで、
ループじゃなきゃ駄目とか末尾再帰じゃなきゃ駄目と言ってるのは
使う側の問題であって処理系の評価には全く関係ない。
そんなことも理解できないで文句言ってる奴は腕が無さ杉。
どの言語を使っても大した仕事は出来ないだろうね。

returnは書かなくていいがcontinueを律儀に書くのが末尾再帰

繰り返しマクロ（このスレで出てきたもの）

>>418 do
http://codepad.org/yvwb6wvY

>>436-441 for
http://codepad.org/pHIilEjT

>>621 loop
http://codepad.org/QeJlUSpa

※　iterate, seriesマクロも募集

唐突ですみませんが．．．

Schemeで会計ソフトって作れますか？

話ぶったぎってすまないけど質問
いまだにScheme脳になりきらない俺なんだが

int line[100][100]; // なんか適当な値が入ってる

------------------
int out[100];
int i, j;

(for i = 0; i < 100; i++){
out[i] = 0;
for(j = 0; j < 100; j++){
if(i != j){
out[i] += line[i][j]
}
}
}

return out;


上記みたいなイメージの処理で2次元配列ぐりぐり回してなんか処理したいけど(= i j)のときは処理しないよみたいなことがしたいときってどうやって書けばいいと思う？
outをリストにしてlineをリストのリストにしてそれぞれiotaで添え字作ってzipでまとめてぐだぐだぐだーな処理を書いてみて流石に頭が悪すぎるだろうと思ったけどいい考えも浮かばなかった
誰かかっこいいネタくれ

話ぶったぎってすまないけど

と思ったら書くな

話ぶったぎってすまないけど

特に書き込むことなかった

if (i == j) continue;

ところでCで書くんですか？Schemeで書くんですか？

Schemeで書いてもらえると非常に嬉しい
Common Lispとかだとちょっと嬉しい

最初に行列の対角成分を0で上書きするね俺なら

vector使って二重doでグリグリやるってのは？
doを使うとSchemeらしくないけど。

＞いまだにScheme脳になりきらない

＞lineをリストのリストにして

むしろ重症だと思うぞ。

>>626
(= i j)のときは処理しない、ってのが既に手続き的じゃないかな。
関数的には、このときはこの値、そのときはその値、って感じじゃない？

>>631, 634
あーそうかも

>>632
doとか使うとなんか負けたような気がするじゃないか

do は単なる末尾再帰

こんなループにまじになっちゃってdoするの？

>>625 本格的な複式簿記ソフトGnuCashは機能の多くがguileで書かれてるよ。

名前が嫌な感じ

>>626
そういうのならsrfi-42使うかな。

(do-ec (: i 100) (: j 100)
(unless (= i j) (inc! (vector-ref out i) (array-ref line i j))))

Scheme脳っていったって何でもかんでも明示的な再帰で書くわけじゃないっさ。
再帰はあくまで基本のビルディングブロック。定型的な処理にはより大きな出来合いのブロックを使う。

>>638
ありがとう。
行列簿記のシステムをSchemeで書こうと思って。

２重ループで外側ループの変数を内側ループの処理にまざようとすると
めんどくさくなった記憶がある
std::for_each

schemeは政治で仕様が変わる可能性あるけど
common lispは過去の遺産の関係で簡単には変わらないっていう解釈は間違い？

>>643はアホ

プログラミング言語に政治って何のことだよ。勢力か？

R6RSが気に入らないのだろ。Schemeの後継者争い。
LispやSchemeのブランドにこだわるのは処理系の開発が滞るのが怖いからかな。

しょせん黒板に書いて思考実験するための言語で
保守すべき実物が何もないから、一寸先は闇。

規格の権威としてはISOが最高でしょうけど
ANSIとIEEEってどっちが上ですか？
(もちろん言語としてはANSI CL > R5RS Scheme > IEEE Scheme、ANSI CL > ISLISPであり
規格の権威の上下が言語の上下を決める訳ではない事は承知しています）

上って何だよｗｗ

人気

>>648はアホ

ANSIとIEEEって分野が違うでしょ。
重なる部分が多いのは分かるけど。

上も下も無いだろ〜
どっちもよりより上位の規格としてISO持ってるんだから。

あちゃー書き方がまずかったか。
私がアホなのもSchemeが実験言語なのも否定しませんが
ISOには及ばないもののIEEEで規格化されているSchemeが643-647(特に647)みたいな扱いはないでしょ、て意味です
括弧つき注釈をつけたのは
「それくらいググれカス」
「ISOが最高ならISLISP >>> (越えられない壁）>> ANSI CL, IEEE Schemeかよ」
って書かれないようにと思ったのですが、まずかったですね。

便利に使えりゃなんでもいいじゃん

俺はとりあえず末尾再帰がきちんと動いてればschemeと見なすよ
継続なんてオナニーだろアホか

>>643
R5RS->R6RSという流れは必然なのではないかと思う。
Schemeは小さな言語でも、自分を自分自身で表現することで、
インクリメンタルに自己拡張させることができるという
meta-circularの理論を実証するため生み出された可能性がある。
（継続の概念もその過程で発見された？）
Scheme開発の歴史は知らないので、誤っているかもしれないけれど、
その一面は間違いなく存在したはず。

その観点に立った場合、Schemeはいつか小さな仕様の自分自身を用いて
大きな仕様の自分を記述しないと、意味が無い。
それが、R5RS->R6RSという流れなんじゃないだろうか。
逆に言えば、R5RSのScheme世界が十分成熟したとみなされたんだろう。

>>655
末尾再帰の最適化＝継続の最適化

知らないことを認識できてるなら調べりゃいいのに

>>658
アイアイサー

>>656 色々違うなあ。
自己記述とインクリメンタルな拡張の概念はLispにほぼ最初から備わってた。
継続の発明もSchemeよりずっと前。LandinのJ-operatorが1965年くらいかな? そのへんまで遡れる。

そんじゃSchemeは何をしたかってことだけど、直接の動機はHewittのActorモデルのうまい記述を
考えているうちに、手続き呼び出しとメッセージパッシングがともに継続渡し+gotoで統一的に
表現できることに気づいたって話かなあ。けれど実装面では、静的スコープで性能を出せることを
示したって功績の方が大きいかもね。

>>660
>自己記述とインクリメンタルな拡張の概念はLispにほぼ最初から備わってた。
万能関数？とかいう機能のことですか。

うーん。とにかく、歴史は一度調べておく必要がありますね。

必要はないけど、出鱈目書かないでください。

>>656を読むと、
「ではないかと思う。 」「可能性がある。 」「発見された？」 「誤っているかもしれない」
「その観点に立った場合、」「という流れなんじゃないだろうか。 」「とみなされたんだろう。 」
終始、自分の推測と、そこから派生するものと、疑問しか書いていない。
つまり、これは事実についての文章ではなく、彼の認識についての文章なわけで、
デタラメかどうかは「Schemeに関する事実と彼の記述内容」ではなく「彼の考えと彼の記述内容」に
違いがあるかどうかで決まる。
（本当はそう思っていない事実を、「〜と思う」という言い方で書いたら、それは「事実でありデタラメ」だ）

多分>>656は、本当にそう思っていることを書いたのであって、デタラメを書いたのではないと思うよ。

結果的に有用な情報がポストされればいいんじゃね?
>>661
自己記述についてはeval[e;p]の実装がLispインタプリタの始まりであったことを
考えれば、最初からLispはそうだったってことになる。自己記述が容易だったために
インクリメンタルな拡張が可能だったっていうのはMcCarthyの"The History of Lisp" で
触れられてたと思う。
Lispの歴史の中でのSchemeの位置づけについてはSteele&Gabrielの"The Evolution of Lisp"
がわかりやすい。
R5RSとR6RSについては、まあいろいろな人のいろいろな思惑があるんで一口には言えないなあ。

「最初から」っていうとアレだけど、
元はリスト処理ライブラリでしょ、FORTRANの。
詳しくは"The History of Lisp"で。

＞Lispの歴史の中でのSchemeの位置づけについて

Gerry Sussman and I wanted to understand Carl Hewitt’s ideas, which seemed to have intellectual power, but we couldn’t get past the complexity and the notation to see “what was really going on.”
So we decided to implement a “toy” actors language.
We hoped that it could capture the essence of the ideas while remaining simple enough to understand.
It might even turn into something useful.

--- Guy Steele "The History of Scheme"

A Sequence of AI Languages at MIT

LISP (McCarthy et al., 1958)
METEOR (Bobrow, 1964)
CONVERT (Guzman, 1969)
PLANNER (Hewitt, 1969)
MUDDLE (Sussman, Hewitt, et al., 1970)
MICROPLANNER (Sussman et al., 1971)
CONNIVER (Sussman et al., 1972)
PLASMA (Hewitt et al., 1973) <== >>666のヒューイットのアイデアはこれで説明していた
SCHEMER (Sussman and Steele, 1975)

We decided to start with a small Lisp interpreter and then graft on exactly two more constructs: a way to make actors and a way to send messages.
Gerry had been studying and teaching Algol 60, so we decided to use the full funarg solution so that our toy language would have lexical scope.
Our intuition was that this would also keep track of actor’s acquaintances correctly.
(Also inspired by Algol 60, the first toy interpreter was call-by-name rather than call-by-value! I will gloss over that distinction here.)

An Astonishing Conclusion

Actor constructors and lambda expressions in our toy language are operationally equivalent.
Does it follow that actors are “merely” functions in a tail-recursive, lexically scoped language?
They are the same mechanism.
Any difference is not inherent, but depends only on what you put in their bodies.
If your primitive operators are functions, you will tend to write programs in a functional style.
If your primitive operators are actors, you will tend to write programs in an actor style.

A New Language Is Born

After some discussion, Carl Hewitt agreed with our conclusions (with two minor exceptions).
In a way, this ended the “language competition.” <== これは大事！
Our great new AI language “Schemer” turned out to be a small dialect of Lisp with some nice properties.
Oh, yes: the name?
File names in that OS were limited to 6 characters.
“SCHEME”

in Lisp

(DEFINE FACTORIAL (N)
　(COND
　　((ZEROP N) 1)
　　(T (TIMES N (FACTORIAL (DIFFERENCE N 1)))))

(FACTORIAL 5) ⇒ 120

in PLASMA

(define
　[factorial ≡
　　(≡≡> (message: [=n] (reply-to: =c))
　　　(rules n
　　　　(≡> 1 (c <== (message: 1)))
　　　　(else (factorial <==
　　　　　　　　　(message: (n . 1)
　　　　　　　　　　(reply-to:
　　　　　　　　　　　(≡≡> (message: =y)
　　　　　　　　　　　　(c <== (message: (y * n))))))))))])

in SCHEMER

(define factorial
　(alpha (n c)
　　(= n 0
　　　(alpha () (c 1))
　　　(alpha ()
　　　　(- n 1
　　　　　(alpha (z)
　　　　　　(factorial z
　　　　　　　(alpha (y)
　　　　　　　　(* n y c)))))))))

Now evaluating the message send

(factorial 5 fred)

results in sending a message containing 120 to the actor named fred.
Oh, joy!

in SCHEME

(define-syntax zerop
(syntax-rules ()
((_ x) (= 0 x))))

(define-syntax times
(syntax-rules ()
((_ x y) (* x y))))

(define-syntax difference
(syntax-rules ()
((_ x y) (- x y))))

(define (FACTORIAL N)
　(cond
　　((zerop N) 1)
　　(else (times N (FACTORIAL (difference N 1))))))

(FACTORIAL 5)

>>663
よくぞ見破りましたというか、すごい明確化の能力ですね。

上記書き込みの理解をとりあえず試みてみます。

>>675
そこでdefine-syntaxを使うのは恥ずかしい

>>673 in SCHEME
http://codepad.org/JOzaBBNR

このように今でもACTORモデルは使えます。

>>677
理解出来ないなら書き込むな

>>675は「in SCHEME」というより「in SCHEMER」だから
あらかじめdefine-syntaxで定義されてる処理系で走らせる意味があるんだよ。

>>676-677
おまえホント、痛い奴だな。

そういう同一人物認定も、相当に痛いと思うけどなぁ。

話ぶったぎってすまないけど

喧嘩はよそでやってくれ

そうだぞ。夫婦喧嘩は犬も喰わない。

Lispだけに、カッコ悪いよな。

こういうどうでもいい流れになるのがLispのLispたる所以

でもそこが好きーむ

Schemeはもともと、Actor（オブジェクト？）指向プログラミング言語として
設計されたのですね。
安直に言うと、SICP２章〜３章のdispatchが出てくるコードがScheme
メインストリームということでOKですか？

>>668
違います。

PLANNER　A Language for Proving Theorems
by Carl Hewitt (1967)
ttp://dspace.mit.edu/bitstream/1721.1/6144/2/AIM-137.pdf

MICRO-PLANNER REFERENCE MANUAL
by Gerald Jay Sussman and Terry Winograd (1970)
ttp://dspace.mit.edu/bitstream/1721.1/5833/2/AIM-203.pdf

Gerald Jay Sussman と Terry Winograd によるPlanner のサブセット
Micro-Planner は、当時主流であった論理的アプローチとは異なる手法を提案しました。
論理的アプローチ派の Robert Kowalski は Alain Colmerauer と共同で
Micro-Planner によく似た Prolog を開発しました。
不幸なことにMicro-Plannerはバックトラッキングの扱いにくさを証明しましたが、
制御構造に関する議論を活性化しました。
このころ、Peter Landin は J (Jump) 演算子を使って非常に強力な制御構造
を導入しました。

Drew McDermott と Gerald Sussman は、Landin のコンセプトを
「Hairy Control Structure」と呼びさらに発展させ、Conniver 言語に実装し
ました。

THE CONNIVER REFERENCE MANUAL
by Drew V. McDermott and Gerald Jay Sussman (1972)
ttp://dspace.mit.edu/bitstream/1721.1/6204/2/AIM-259a.pdf

Scheme　An Interpreter for Extended Lambda Calculus
by Gerald Jay Sussman and Guy Lewis Steele Jr. （1975）
http://dspace.mit.edu/bitstream/1721.1/5794/2/AIM-349.pdf

MITのAIラボで作る言語は CONNIVER とか PLANNER とか 「考えるもの」系の
名前をつける伝統だったので、Schemeの名前は、「Conniverよりもっと
スニーキー(卑劣)なPlanner」という意味のSchemerとなるはずだった。

>>670で言ってる“language competition”には>>667,>>689,>>690の各言語が登場します。
そしてそれら全てを包含した最終言語がSchemeなので、>>688の意見は的外れです。

>>689
どう違うんでしょうか?簡単でいいので教えていただけると嬉しいのですが。

>>691
了解しました。

ていうか、本増えすぎですよ・・・。

>>691
> >>670で言ってる“language competition”には>>667,>>689,>>690の各言語が登場します。
> そしてそれら全てを包含した最終言語がSchemeなので、>>688の意見は的外れです。
>>670には
SCHEMER (Sussman and Steele, 1975)
が入っているのですが、本当にこれも包含されるのですか？
もしかして、SchemerとSchemeは別物ということでしょうか？

>>670には×
>>667には○

>>664が言ってるように>>695-696は自分で調べろ。乞食か？

＞Lispの歴史の中でのSchemeの位置づけについてはSteele&Gabrielの"The Evolution of Lisp"
＞がわかりやすい。
http://www010.upp.so-net.ne.jp/okshirai/HOPL2-Uncut-j.txt

PLASMA(PLANNER-73)
http://dspace.mit.edu/bitstream/handle/1721.1/41116/AI_WP_081.pdf?sequence=4

>>697
リョーカイ

すみません、ちょっと教えてください。

(define (hit clist)
(let iter ((progress (look-forward-symbol clist)) (w '()))
; (display progress)(display w)(newline)
(cond ((not progress) w)
((not (car progress)) #f))
(else (iter (look-forward-symbol progress)
(append w (hit2 progress))))))

look-forward-symbolとhit2の実装はあまり関係ないと思うので省きます。
名前付きletでループさせているのですが、
else節のiterが第一引数#fで呼び出された場合に
condの最初の節で抜けて欲しいのにelse節を再び評価してしまいます。
condって節を順に評価していくとR5RSに書いてあるのでその通りにしたつもりなのですが、
何か間違ってますでしょうか。

>>699
#fの後の括弧が一つ多い

あ！仰る通りですw
直したらうまくいきました。
ありがとうございました。

995:朝鮮社会民主党(アラバマ州) 2008/10/05(日) 15:29:29 .85 ID:UoemBcGT
このスレのまとめ：
習得するべき言語：C, C++, C#
習得するべきスクリプト：perl, python, ruby
やめておくべき言語：Haskell, Lisp

Gauche以外の方言がもっと評価されてもいいと思うのだが
日本語が使えなさそうなのは門前払いなのかな
C#やRubyは日本語に関しては安心だよな

gaucheでヒアドキュメントって使えるんでしょうか？

(define foo #hHEREDOC
aaaaa
bbbbbbbbb
cccc
HEREDOC)

みたいなことやりたいです

さらにヒアドキュメントの中でS式をevalしてその結果を埋め込みとかできればなお嬉しいです
(define foo
#hHEREDOC
abcde
#hSEXP (integer->string 1)
fooHEREDOC)

>>704
非公式なパッチならあるので、これを使えば出来なくはない。
http://practical-scheme.net/wiliki/wiliki.cgi?Rui%3a%E3%83%92%E3%82%A2%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88
2年前のバージョンに対するパッチなので、今の版に適用するならちょっと手を加えないといけないかも

>>704 使えない。wilikiかMLで以前議論があったような気がする。
文字列リテラル内でダブルクオートやバックスラッシュをエスケープするのが面倒ってこと?

>>705
便利なケースが無いとは言わんが、そんな小汚い方法はSchemeにそぐわない。
マクロでやればいいことだし。

へえ、マクロでねえ。

ヒアドキュメントより木構造テキストを使った方がいいんじゃないの？
http://practical-scheme.net/gauche/man/gauche-refj_157.html#SEC433
文字列補間でもいいけど。
http://practical-scheme.net/gauche/man/gauche-refj_48.html#SEC80

>>710 に同意。
#`"foo
bar" とか普通に改行も含められるんだから、十分じゃないか？

SICP日本語版を読んでいます。
質問です。

(+ 1 2) の様な書き方を「逆ポーランド記法」と読んでも良いのでしょうか？

>>712
ttp://ja.wikipedia.org/wiki/%E9%80%86%E3%83%9D%E3%83%BC%E3%83%A9%E3%83%B3%E3%83%89%E8%A8%98%E6%B3%95

ポーランド記法というのですね。失礼しました。

Gauche 0.8.14 記念age

(　ﾟ∀ﾟ)o彡°がうちぇ！がうちぇ！

http://codepad.org/YyhxEFko
こんな風にalphaを導入すれば>>673-674のように
(factorial 5 fred)
でアクター指向プログラミング出来るから>>678よりSchemerに近くできるね。
アクターがメソッドを持つようにすればオブジェクト指向と同じ。
alpahaの式でその部分が鮮明になる。
CLOSはこんな風に考えられたのかな?

アクターモデルのような非同期型のオブジェクトモデルも
注目されるようになって来てはいるが、実用には程遠いかなぁ。
Erlangぐらいか？

> 実用には程遠い

んなことないだろ。バカでも携わる方面にまで降りてきてないだけで。

トリクルダウンｗ

ありゃ、cygwin上のGauche-0.8.14でGauche-gl-0.4.4が動かねぇ
0.8.13なら動くのに
cygwinどっか壊したかな？

>>718
> アクターモデルのような非同期型のオブジェクトモデルも

アクターモデルはオブジェクトモデルじゃないよ。
非同期メッセージングモデル。

> Erlangぐらいか？

Erlangも違う。
非同期オブジェクトモデルなのはABCLなどほんのごく一部です。

>>721
リビルドしたか？
0.8.13と0.8.14はVMの仕様が変わってるぞ。

gaucheスレを作ったらここからどれだけコメントがなくなるんだ老化?

gaucheで勉強中の者です。
defineとdefine-methodはどう使いわけるのがいいのでしょうか。
define-methodだけで十分且つ安全とは言えませんか？

メソッドじゃないものをdefineすることもある
たとえば (define pi 3.14)

とりあえず(define define '())してみると良いんじゃないかな

C++でいちいちvirtualと書くのが面倒だと言うのと同じことだな。

>>725
Gauche のオブジェクトシステムは CLOS を元にしているけれど、
Scheme とは相性の悪い点もある。

概念的に Scheme の関数は本質的に全て無名関数であって、
それが変数を束縛しているということになってるのに、
CLOS は名前で区別する体裁になってるのがイマイチと言われている。

その他、速度の点でも常に妥当な型を探してディスパッチなんてやってらんない。
このへんは最適化もほとんど出来ないらしい。
でも、もしその速度低下が許容可能で、
define-method を常に使うことが開発効率を大幅に上昇させるなら、
あなたがそうすることを処理系は妨げない。

CLOSとかアホかと。
シンボル拡張して(obj.foo.bar)でいいじゃん。
でもfooが関数だとすると((obj.foo).bar)なのか？
これでいいのか？って議論にかならずなるよね。
無いものを作るのは難しいですなｗ

そんなのLispじゃない＞(obj.foo.bar)

>>731
いや obj.foo.bar は lisp 的に一つのシンボルじゃね?

>>732
(obj . (foo . bar))なら許す

アクセッサは関数じゃないと。

schme用に書いたコードをcommon lispに変換するのって
適当なマクロ導入するだけでできますか？

そのマクロが真に適当ならば。

その昔taoというオブジェクトシステムがあって
こいつのメソッド適用はオブジェクトを前置する記法だったと聞いた

竹内先生のTAO?

TAOは確かSmaltalk風のメッセージパッシングスタイルのオブジェクトシステムで、
[object message arg1 arg2 arg3]と書く。
先頭がフラグが立った特殊なコンスセルになっていて、
それでこのS式がメッセージセンド式であることを識別していたはず。