Common Lisp, Scheme Part 14
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/11/18(金) 10:02:06Part1: http://piza2.2ch.net/tech/kako/987/987169286.html
Part2: http://pc.2ch.net/tech/kako/1002/10025/1002584344.html
Part3: http://pc.2ch.net/tech/kako/1008/10082/1008220265.html
Part4: http://pc.2ch.net/tech/kako/1016/10162/1016211619.html
Part5: http://pc3.2ch.net/tech/kako/1023/10230/1023091882.html
Part6: http://pc3.2ch.net/tech/kako/1031/10315/1031560687.html
Part7: http://pc5.2ch.net/tech/kako/1042/10421/1042167213.html
Part8: http://pc5.2ch.net/tech/kako/1058/10582/1058263391.html
Part9: http://pc2.2ch.net/test/read.cgi/tech/1069594582/
Part10: http://pc5.2ch.net/test/read.cgi/tech/1075630259/
Part11: http://pc5.2ch.net/test/read.cgi/tech/1091456033/
Part12: http://pc8.2ch.net/test/read.cgi/tech/1100229366/
Part13: http://pc8.2ch.net/test/read.cgi/tech/1115901841/
0002デフォルトの名無しさん
2005/11/18(金) 10:03:26日本Lispユーザ会(日本語)
http://jp.franz.com/jlug/index.html
ここにかなりの情報があります。
http://jp.franz.com/
削るとAllegro Common Lispのページへ
プログラミング言語Scheme(日本語)
ttp://www.sci.toyama-u.ac.jp/~iwao/Scheme/scheme.html
Schemeの人はまずここを見ましょう。
Lisper への道(日本語)
ttp://www.geocities.co.jp/SiliconValley-Oakland/1680/rakup.html
判りやすいLISP入門サイト。
Schemeへの道(日本語)
ttp://www.stdio.h.kyoto-u.ac.jp/~hioki/gairon-enshuu/SchemeNotes/scheme.html
ここはschemeの入門サイト。
0003デフォルトの名無しさん
2005/11/18(金) 10:04:13http://buri.sfc.keio.ac.jp/lisp/menu.html
Practical Scheme(日本語)
ttp://www.shiro.dreamhost.com/scheme/index-j.html
「普通のやつらの上を行け」など、興味深い文書を沢山翻訳されてます。
(Gaucheという完成度の高いscheme処理系作者さんのページでもあります。)
Scheme Hash(英語)
http://okmij.org/ftp/Scheme/index.html
S式でXMLを使える様にするSXMLなど
John McCarthy's Home Page
http://www-formal.stanford.edu/jmc/
LISPの生みの親、Ｊ・マッカーシーのページだそうです。
Association of Lisp Users
http://www.alu.org/alu/home
米国のLispユーザ会
0004デフォルトの名無しさん
2005/11/18(金) 10:04:59SICP(英語)
http://mitpress.mit.edu/sicp/full-text/book/book.html
「計算機プログラムの構造と解釈」の原書です。
全てオンラインで読めます。
計算機プログラムの構造と解釈 第二版 (snip) に関連するホームページ
http://www.ipl.t.u-tokyo.ac.jp/sicp/
SICPの回答集
http://www.melt.kyutech.ac.jp/~gogogo/sicp_ex/
http://pluto.aurorasd.co.jp/~mkama/sicp/
http://www.ipl.t.u-tokyo.ac.jp/sicp/solution.root.html
http://www.sampou.org/scheme/sicp/answer/
0005デフォルトの名無しさん
2005/11/18(金) 10:05:49Schemeで書かれた正規表現ライブラリ
ttp://www.cs.rice.edu/~dorai/pregexp/pregexp.html
幻の「入門Scheme」
ttp://www4.ocn.ne.jp/~inukai/scheme_primer_j.html
オンラインで読める
各種scheme処理系をcygwin上からビルドする方法など。
ttp://www.geocities.co.jp/SiliconValley-PaloAlto/7043/
Bit - Implantation compacte de Scheme
http://www.iro.umontreal.ca/~dube/
mini-schemeよりも小さい(?)bytecode変換系
Lisp 言語処理系: CAMPUS LIsP, Lemon version
http://aten.aial.hiroshima-u.ac.jp/~kakugawa/clisp/index-ja.shtml
Cコードによるわずか1000行の実装
Cliki
http://www.cliki.net/index
CommonLispのプログラムがたくさん紹介されているのでここを当たるべし。
0006デフォルトの名無しさん
2005/11/18(金) 10:06:37http://www.isr.ist.utl.pt/library/docs/encycmuclopedia/doc/
cmucl以外でも有益なはず
CMUのLisp Repository
ftp://ftp.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/0.html
新旧様々なプログラムが置いてある
Tiny CLOS Tutorial
http://home.adelphi.edu/~sbloch/class/272/tclos/tutorial.shtml
Schemix
http://www.abstractnonsense.com/schemix/
Linuxのkernelへのパッチで、/dev/として扱えるTinyScheme
Bibliography of Scheme-related Research
http://library.readscheme.org/
Scheme関連の論文リンク集
0007デフォルトの名無しさん
2005/11/18(金) 10:15:34awkで書かれたわずか500行のLispインタプリタ
awklispを読めばLispが理解できる
ttp://www.accesscom.com/~darius/
Emacs Lisp 2
http://pc2.2ch.net/test/read.cgi/tech/1068467385/
* Hotdog Scheme http://rover.cs.nwu.edu/~scheme/
MS が金出してたみたい
* Bigloo http://www-sop.inria.fr/mimosa/fp/Bigloo/
CLR 用のコードを吐けるようになったらしい
継続
なんでも継続
ttp://www.shiro.dreamhost.com/scheme/docs/cont-j.html
Schemeへの道:継続
http://www.stdio.h.kyoto-u.ac.jp/~hioki/gairon-enshuu/SchemeNotes/continuation.html
継続の使い方
http://www.geocities.co.jp/SiliconValley-PaloAlto/7043/index.html#continuation
継続の使用法
http://www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/block.html
CPS(継続渡しスタイル)の説明
http://www.csl.sony.co.jp/person/masui/Forum/data/20011215023622/
Kahua: 継続ベースのアプリケーションサーバー
ttp://www.kahua.org/
0008デフォルトの名無しさん
2005/11/18(金) 10:18:06CLtL2: Common Lisp the Language 2nd edition
http://www-2.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html
CLHS: Common Lisp Hyper Spec
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/FrontMatter/Chapter-Index.html
R5RS: Revised(5) Scheme(ja)
http://www.sci.toyama-u.ac.jp/~iwao/Scheme/r5rsj/html/r5rsj.html
便利な情報リソース）
The Common Lisp Cookbook: いわゆる Cookbook
http://cl-cookbook.sourceforge.net/
小さい実装）
SECDR-Scheme: SECD machine model に基づく実装
ttp://lily.fan.gr.jp/~kmd/adhoc/view.rhtml?n=SECDR-Scheme_woyomu
Minischeme: 1 ファイルに凝縮された Scheme 処理系
http://tinyscheme.sourceforge.net/minischeme.tar.gz
TinyScheme: Minischeme を色々弄ったもの
http://tinyscheme.sourceforge.net/
KI-Scheme, AM-Scheme, etc...
http://www.nifty.com/download/dos/prog/lisp/
LispMe: Palm 上で動く Scheme 処理系. これも SECD virtual machine.
http://www.lispme.de/lispme/
0009デフォルトの名無しさん
2005/11/18(金) 10:20:35http://ruku.qp.tc/dat2ch/0403/01/1069594582.html
独習 Scheme 三週間
http://www.sampou.org/scheme/t-y-scheme/t-y-scheme-Z-H-1.html
Schemeの教科書
よろずや
http://www.geocities.co.jp/SiliconValley-SanJose/7474/
lispの実用的な情報が色々。
Common-Lisp.net: 多くのプロジェクトがホスティングされてる
ttp://common-lisp.net/
Bill Clementson's Blog: Lisp関連の話題が中心のBlog
ttp://home.comcast.net/~bc19191/blog/
Practical Common Lisp: S式の羅列で現実的な問題をどう解くのかそのギャップに悩まされてる人に
ttp://www.gigamonkeys.com/book/
0010デフォルトの名無しさん
2005/11/18(金) 14:16:17どうでもいいけどなんでスレタイ"Common" Lisp, Schemeなの？
Lisp Schemeじゃだめなの？
ちょっと前までLisp Schemeだったよね。
Common付けないといけない理由でもできた？
あと>>7の
>CPS(継続渡しスタイル)の説明
>http://www.csl.sony.co.jp/person/masui/Forum/data/20011215023622/
が404になってた。
0011デフォルトの名無しさん
2005/11/18(金) 14:24:25Emacs Lisp とか xyzzy はスレ違いだと明示するためかな。
0012デフォルトの名無しさん
2005/11/18(金) 15:16:52そのページの内容はWilikiに転載されてます。
http://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Scheme%3aCPS
0013デフォルトの名無しさん
2005/11/18(金) 15:50:52そういうのはスレが立つ前、900 過ぎで言わないと。
前スレの 980 が言ってるように、981 過ぎたらスレが落ちる前に次スレを
立てるのが先決。それまでにテンプレ議論ができてないと前スレそのままに
なってもしょうがない。
0014デフォルトの名無しさん
2005/11/18(金) 23:00:330015デフォルトの名無しさん
2005/11/18(金) 23:31:22つまんない理由で
キャンセルしちゃった
残念
0016デフォルトの名無しさん
2005/11/19(土) 21:33:580017デフォルトの名無しさん
2005/11/19(土) 21:51:06結局どういう話だったの？
フランツのセミナー行った人詳報頼む。
0018デフォルトの名無しさん
2005/11/19(土) 22:33:110019デフォルトの名無しさん
2005/11/19(土) 22:34:09現在査読中。
発売は来年。値段は\4000-を超えないようにしたい。
0020デフォルトの名無しさん
2005/11/20(日) 02:39:30マクロ文字でシンボルに意味を持たせるという手もあるみたい。
http://lambda.s55.xrea.com/20040325.html
つか、このサイト Google から消えてるな？
0021デフォルトの名無しさん
2005/11/20(日) 11:46:50してくれるとよかったんだけど。XMLパーサとかjLinkerとかドキュメント読めば
書いてある内容をわざわざ改めて聴かされてもこちらとしては嬉しくないんだが。
あと両日とも会場が窮屈なのはどうにかならないのかなぁ。変な姿勢でスライド眺めてたら
首が痛くなっちゃったよ。
遠方からこのセミナーの為に自費で上京してくる学生さんとかが現れたのはあれかな、
Lispが年寄りの懐古趣味ではなくなりつつあるっていうことなのかな。
0022デフォルトの名無しさん
2005/11/20(日) 13:43:28懐古趣味だけどな。
0023デフォルトの名無しさん
2005/11/20(日) 15:02:06いってきたものです。昨年度同様資料は掲載予定とのこと。
** SemanticWeb
迷って新宿御苑一周して遅刻して逃した。翌日ネタにしてたくらいなので何かしゃべったはずだが、このため不明。
誰か知ってたら補完よろしく。
** Lisp とゲーム
子供向けゲーム開発プラットフォームを作った話。以降の OpenGL+SWIG とあわせて15分の
セッションなので超簡単に終わる。ものとしてはSqueakとかでデモってる子供から使える
ビジュアルプログラミング環境とかと似たようなもんなのかな。ベースエンジンは25KLOC,
40class 程の規模。Agent Cubes とかいう名前でオープンソース化予定。
このプラットフォームの一環としてOpenGL/GLUTや外部のフリーの物理演算ライブラリをACLから
使えるようにして、ゲーム記述のためのDSLを作った。SWIGがACLに対応したのでC/C++ライブラリを
簡単に組み込めるようになったとのこと。
libusbのSWIG化してるときにLisp/Scheme対応もやっとこうかと思ったんだけど、その時はどの実装向けにしたら
いいかよくわからんかったので、Lisp界はACLとGCLで大体カバーできて、できはACL>>>>GCLらしいとわかったのが収穫。
** On Lisp 翻訳
高校の時Lispに関心を持って、PaulGrahamのCL本の続刊OnLispが未訳なことを知って勉強をかねて翻訳に着手。
二年後2chでの協力などにより完成。CL本と違い、Macroの徹底応用本で、現在LispHackerな人の突っ込みを受けつつ
大幅改善＋出版準備中。値段は<4000円予定。ちなみに、実は本人はあんまりLispでは書いてないらしい。
内容紹介の中ではMacroとMultimethodについて解説してた。Multimethodはトップレベルのレシーバが構成上ない
だけと思ってたので、レシーバを消滅させることで匿名のアドホックなクラスに対してメソッド定義できると
いうのはなるほどと思った（あまりに初心者ですまん。自分はLisp歴0年なんで）。
続く…（技術的に見てLisperな人にとっては既知の話が多かったと思う）
0024デフォルトの名無しさん
2005/11/25(金) 03:11:00例えば+をマクロと関数に分けて作って、
(+ 1 2 3 ...) という直接使用のときはマクロとして可能な限り簡約してしまい、
((if test + -) 1 2 3 ...) みたいなときは関数を選択、という風に使い分けたいのですが、
こういう文脈によって切り分ける事はできるでしょうか？
CommonLisp、Schemeどっちでもいいです。
（CommonLispのシンボルが変数と関数別スロットにあるように、）
マクロと関数が別スロットにあるような処理系ならできそうな気がしますが、
実際のところそういった処理系はあるでしょうか。
0025デフォルトの名無しさん
2005/11/25(金) 04:21:45つ http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_3-2-2-1.html
0026デフォルトの名無しさん
2005/11/25(金) 21:40:11ありがとうございます。
えーと、つまりそのリンクの説明によると、関数とマクロは切り分けられる
ということらしいのですが、
シンボルに対応するマクロ定義用スロットというのがどこか別に存在する、
という解釈で合ってますでしょうか？
第一引数を評価するときにmacroexpandフックが呼び出されるということは
そのフックの中でマクロシンボルの管理をしているということでしょうか。
0027デフォルトの名無しさん
2005/11/25(金) 22:17:32この特殊フォームの機能を成立させるには、正確にシンボルを置き換えるために
bodyで生成されるかもしれないフレームの変数について全て知っていないと
いけないはずで、そのためにはマクロで書かれた未知の構文に対応するために、
bodyのシーケンスに対してmacroexpandしていかなくてはいけない、
延いてはその処理系の変数生成フォームのパターンを全て把握している必要がある、
ということだと思うのですが、
やはりそういう複雑なことをやっているのでしょうか？
0028デフォルトの名無しさん
2005/11/26(土) 02:55:59LISP Scheme hierarchy図
http://dreamsongs.com/NewFiles/Hopl2Slides.pdf
0029デフォルトの名無しさん
2005/11/26(土) 03:27:08なかなか面白いね。
0030デフォルトの名無しさん
2005/11/26(土) 03:55:52つまりはシンボルマクロの名前がシャドウイングされたときの話？
逐次展開して行くってのはまあそれでいいし、
シャドウイングが発生するような式の中では
ちゃんと展開しないようにしなきゃいけないのも確かだけれど。
でもマクロ展開しちゃったら出てくるのはアトムか、
式だったら特殊形式か関数適用かなわけで、
しかもシャドウイングするような特殊形式の数なんて高が知れている気がするけれど。
少なくとも macrolet と比べてとりわけ複雑だとは思えないなあ。
0031デフォルトの名無しさん
2005/11/26(土) 06:54:37一般的に「関数とマクロは切り分けられる」って話じゃなくて、>>24 で
言ってたように「直接適用する時だけマクロみたいな処理をしたい」という
まさにその要求を実現するために、compiler-macroっていう特殊なマクロが
CLでは規格化されてるってこと。だからANSI準拠なCL処理系だったら 24 の
やりたいことはできるよ。
実装上はシンボルにfunctionスロットとcompiler-macroスロットを持っとく
のが素直だろうけど、そうではない実装だってあり得る。
0032デフォルトの名無しさん
2005/11/26(土) 08:10:24凄い調べようだな…
0033デフォルトの名無しさん
2005/11/26(土) 08:57:14ありがとうございます。
マクロとシンボルの関係について謎だったのですが、これで理解できた気がします。
マクロはシンボルの値として必ずしも参照できなくても良いみたいですね。
0034デフォルトの名無しさん
2005/11/26(土) 09:45:32話の筋としてはマクロは first class object じゃない、
つまり言語に於いて値となり得る対象ではないので
値として参照できちゃいけないといった方がいい。
マクロ定義・展開関数を、なにかタグをつけるとかして
関数スロットに突っ込んでおくような実装もあるだろうけれど、
というか xyzzy がそんな感じなんだけれど、
それが何かマクロ型とでもいうべき値として意味を持っているわけじゃない。
0035デフォルトの名無しさん
2005/11/26(土) 16:16:37Lispでは、ボトムアップスタイルでコードが
書ける、とよく言われておりますが、
イメージ的には関数を個別に書いてゆき
後でそれを統合し易いといったような
意味なのでしょうか？
0036デフォルトの名無しさん
2005/11/26(土) 17:17:31設計の時間を殆ど要しない。
ネックは実行速度のみ と 開発&コーディングスタイルの違いだけである。
頭悪いとできないかもしれんね。
0037デフォルトの名無しさん
2005/11/26(土) 17:22:20とりあえずプログラム数千行も書けばわかるよ。
素養のない人に説明するのは難しい。
0038デフォルトの名無しさん
2005/11/26(土) 18:22:530039デフォルトの名無しさん
2005/11/26(土) 22:17:490040デフォルトの名無しさん
2005/11/27(日) 02:19:07プロジェクトを回すだけのLisperを揃えるのが困難とか開発したプロダクトを
投げて保守させるのが困難とか、環境とか政治的な要因の方がネックだな。
0041デフォルトの名無しさん
2005/11/27(日) 02:30:36一度やってみたいなぁ。いつもLisperは俺一人か、良くてあと一人くらいだよ。orz
0042デフォルトの名無しさん
2005/11/27(日) 06:30:58> Lisperが揃ったプロジェクト！
> 一度やってみたいなぁ。いつもLisperは俺一人か、良くてあと一人くらいだよ。orz
履歴書と、職務経歴書もって、苫米地英人博士のコグニティリサーチラボ行ってみれば？
苫米地博士はCommonLisp大好きで、Lispハッカー募集してるから。
0043デフォルトの名無しさん
2005/11/27(日) 10:44:16一時期会社が傾いて、新規の技術者募集は今はやってないんでない？
0044デフォルトの名無しさん
2005/11/27(日) 11:44:570045デフォルトの名無しさん
2005/11/27(日) 13:53:59>投げて保守させるのが困難とか、環境とか政治的な要因の方がネックだな。
誰でも使える言語で一人で開発してる自分には無縁だな。
さらに、EVALに近い機能を使ってカリー化とかしてるし。
何の言語使おうが、生産性を1/10に下げて誰でも使えるようにするか、
そうでないかの違いな気がする。
0046デフォルトの名無しさん
2005/11/27(日) 13:58:48> >プロジェクトを回すだけのLisperを揃えるのが困難とか開発したプロダクトを
> >投げて保守させるのが困難とか、環境とか政治的な要因の方がネックだな。
>
> 誰でも使える言語で一人で開発してる自分には無縁だな。
> さらに、EVALに近い機能を使ってカリー化とかしてるし。
>
> 何の言語使おうが、生産性を1/10に下げて誰でも使えるようにするか、
> そうでないかの違いな気がする。
そこでMatz Lispですよ！(Rubyのことなので検索しないように）
誰でも使えるかどうかは…
0047デフォルトの名無しさん
2005/11/27(日) 14:00:27パフォーマンスが……
0048デフォルトの名無しさん
2005/11/27(日) 14:05:440049デフォルトの名無しさん
2005/11/27(日) 14:34:47言語なんか適材適所で使い分けるもんだと思っていたよ。
0050デフォルトの名無しさん
2005/11/27(日) 16:15:470051デフォルトの名無しさん
2005/11/27(日) 18:03:07RubyやJavaScriptはLisp方言だと思ってる。
0052デフォルトの名無しさん
2005/11/27(日) 18:10:41その言い回しはパラダイム論争になるわえ。
0053デフォルトの名無しさん
2005/11/27(日) 18:23:18プログラムを（文字列ではなく）リストとして扱えなくちゃLispとは呼べないだろ。
RubyやJavaScriptでできるんだっけ？
0054デフォルトの名無しさん
2005/11/27(日) 18:34:060055デフォルトの名無しさん
2005/11/27(日) 21:37:44んなことない。プログラムが S 式なのは Lisp のある方言群の特徴でしかない。
dynamic typing で call by reference な言語は全部 Lisp。
0056デフォルトの名無しさん
2005/11/27(日) 22:40:03リスト処理できなくてもLispなのか。おまえの友達は少ないだろうな。ｗ
0057デフォルトの名無しさん
2005/11/27(日) 22:55:51私は>>55に賛成。
プログラムがオブジェクト(ラムダ)であることに意義があると考える。
その形がリストであることにこだわるのは意味的に重要でない。
0058デフォルトの名無しさん
2005/11/27(日) 23:00:16>>55 >>57 の言うような言語はスレ違い。どっか他でやってくれや。
0059デフォルトの名無しさん
2005/11/27(日) 23:00:490060デフォルトの名無しさん
2005/11/27(日) 23:01:310061デフォルトの名無しさん
2005/11/27(日) 23:22:300062デフォルトの名無しさん
2005/11/28(月) 00:15:140063デフォルトの名無しさん
2005/11/28(月) 00:34:090064デフォルトの名無しさん
2005/11/28(月) 02:27:43「プログラムをリストとして扱えること」は関係無いだろ
0065デフォルトの名無しさん
2005/11/28(月) 03:34:04実際CommonLISPは組み込みの特殊フォームが25程度で、
後は全て関数かマクロによるリスト処理で成り立ってる。
ただしリストじゃないとLISPのマクロのようなものが書けない、
ということではない、ということかな？
ほんとはシーケンスのような抽象化をしたいとこなんだけど、
たまたまリスト操作と「見なす」表現が理解に都合良かったということ。
中身が実はベクタだったりするLISPも実際あるだろう。
初心者や表層だけ見て判断する馬鹿には最初は単なる「リスト処理言語」としての
側面しか見えないかもしれないが、その側面はまさに初心者や馬鹿でも
わかるように設置した受け皿なので、それでかまわないのだろう。
0066デフォルトの名無しさん
2005/11/28(月) 03:43:030067デフォルトの名無しさん
2005/11/28(月) 04:04:36そう。無関係。
だけどそれら両方を備えている言語以外は一般にはLispとは呼ばない。
DylanやJavaScriptは「Lispと似た特徴を備えている」がLispではないでしょ？
0068デフォルトの名無しさん
2005/11/28(月) 20:09:32あくまでこれはイメージですが、
(hoge ムッチャ複雑な処理の中に
(poge まぁ複雑な処理の中に(moge 単純な処理))
(jo まぁ複雑な処理の中に(jojo 単純な処理)))
このようなLispのプログラムにおける
ボトムアップ開発とは
１．まず単純なmoge,jojoを作り
２．次にまぁ複雑なpoge,joを作り
３．最後にムッチャ複雑なhogeを完成させる。
ってことですよね？
カプセル化無しのスッポンポン。
確かに全体の透明性は高い、が一目では
何をやってるのかさっぱり分からんって
ことはないのでしょうか？
ことで…
0069デフォルトの名無しさん
2005/11/28(月) 20:37:23全然Lisp知らないでしょ。おはなしにならないよ。
0070デフォルトの名無しさん
2005/11/28(月) 20:43:50>>35じゃないですが。
それって、他の言語でも普通にできますよね？Lispとどう関係あるのかいまいちわからないです。
0071デフォルトの名無しさん
2005/11/28(月) 22:51:20>>70
他の言語でも出来るけど、mainとか何とか書かなきゃ実行もできない。
面倒っしょ？対話的環境最高。
そもそも単純な処理から複雑な処理を作るって何か違和感…
単純な処理の組み合わせにするんじゃね？
0072デフォルトの名無しさん
2005/11/28(月) 23:06:50Lispに戻ってくればわかる。
0073デフォルトの名無しさん
2005/11/28(月) 23:15:54シーケンスとか言っても
(map (lambda (x) (* 2 x)) (cons 3 (make-array 10 1)))
=> (3 . [2 2 2 2 2 2 2 2 2 2])
とかできないんじゃ意味ないし。
リストこそが抽象である。
0074デフォルトの名無しさん
2005/11/28(月) 23:56:11それは思考停止というものだよ。
確かにリストの形に抽象化されたスタイルは素晴らしいものだが、
逆に言えばそれはリストでしかないということだ。
0075デフォルトの名無しさん
2005/11/29(火) 00:03:53万能と抽象は違うと思うが。
(vector 1 (vector 1 (vector 1)))
これはまさしくリストの構造だ。
0076デフォルトの名無しさん
2005/11/29(火) 00:08:30オブジェクト指向的な言い方をすれば、先にクラスを設計しなくても、必要に
応じてメソッドをぽちぽち作っていけば、気が付いたらクラス（的なもの）が
出来ているって感じだな。
0077デフォルトの名無しさん
2005/11/29(火) 05:20:47インスタンスベースのオブジェクト指向言語に対して
それではあんましメリット無いような…
javascriptとかrubyとかでも出来るんじゃないの？
もっとlispらしい話を！
というとデータ構造と制御構造がリストと渾然一体なことと
マクロとかマクロとかマクロとかしかないのかな…
＃個人的にはそれで十分というかそれこそが全てなんですけど
短くてわかりやすい例を示したいといつも思っているんだけど
なんか表現力がたらんくていつも挫折。orz
0078デフォルトの名無しさん
2005/11/29(火) 06:21:30car cdr consとかでやってると、データの並び順が変わったとき、car cdrとかやってる部分は全部書き換えになっちゃうんじゃない？その辺がlispって面倒そうなイメージなんですが、どうやって回避するんですか？
>>71
なるほど。mainを書かないでいいのは楽チンでいいですね。コンパイルとかも、関数単位でできるみたいですし。只、lispだけじゃないですが、うっかり既にある関数を上書きしてしまいそうなのが恐いイメージがあります。
0079デフォルトの名無しさん
2005/11/29(火) 06:42:31ラッパ書けばいいんじゃない？
あるいはハッシュとかdefstractとかdefclassとか。
0080デフォルトの名無しさん
2005/11/29(火) 07:13:14言ってみれば構文木を first class object として扱えるところかなあ。
他の言語の eval だと大抵受け取るのがパース前の文字列なんで、
それを使ってごにょごにょしようとした場合構文木をいじるんじゃなくて
文字列・ソースコードをいじることになるのが面倒くさい。
マクロも同じで、文字列→文字列変換だと、無いよりはいいかもしれないけれど、
lisp のマクロと比べてあんまり魅力的ではない。
まあ、そこはどうにか構文木を直に触れるようになったとしても、
構文木オブジェクト周りで内部表現と外部表現が齟齬をきたす可能性が高い気がする。
つまりソースコードを read して print したら何が表示されるか、
という話で、lisp であるなら元の S 式が表示されるわけだけれど。
そこで表示されるのは構文木の外部表現なのか、元のソースコードなのか。
或いは構文木を write して read したらどうなるのか。
そこで read/write Invariance は保障するのは S 式を採用しないと結構面倒そう。
個人的には read と eval が分かれていて、
read/write Invariance が保障されるなら別にリストじゃなくてもいいかなあとは思う。
ただ、せっかく手軽に切ったり貼ったりできるのにリストじゃなくする理由もあんまりない気がする。
リストって言うか cons,car,cdr で弄れる対象と言った方がいいか。
内部的に対になったメモリ領域じゃなくて匿名関数でもいいけれど、
そりゃ効率が悪い、という話でしかない。
措いてしかし、構文木の内部表現がベクタで、なおかつそれをいじることを前提とした言語であったら、
ベクタを弄り回すライブラリが充実していることだろうから、あまり問題にならないかもしれない。
scheme の syntax-rules みたいなパターンマッチベースのマクロだったら
それなりに他の言語でも上手くいく可能性はあるかもなあと思わなくもないけれど。
少なくとも symbol 型のデータ型は必要になるんじゃないかなあ。
識別子が first class object じゃないと困るって言うか。
0081デフォルトの名無しさん
2005/11/29(火) 07:14:350082デフォルトの名無しさん
2005/11/29(火) 09:38:08本当に複雑な問題っていうのは、まず (hoge ムッチャ複雑な処理)
の中身をどうすべきか、っていうのが事前にわからない。
問題の本質自体が見えていない。そこが出発点。
とりあえず手元には生のデータがある。その生のデータをいじくりながら、
まず問題を記述するための単語にあたるパターンを見つけ出す。もちろん
最初はそれが正しいかどうかはわからないが、仮説を立てて、生データを
単語にまとめるルーチンを書いてみる。それがmogeやjojo。
その単語を色々組み立てて、問題を記述できる句が構成できないどうかを
調べてみる。句できたらそれを色々組み合わせて文ができないか調べてみる。
その途中で、最初のパターン化が間違ってたことがわかり、下に戻る
こともある。ときには、多少間違っていてもそれを使って無理矢理全体を
組んで様子を見てみると、どこがおかしいかわかる場合もある。そうやって
粘土をこねたりLegoを組み立てるみたいに作っていくと、最後に
「(hoge ムッチャ複雑な処理の中に
(poge まぁ複雑な処理の中に(moge 単純な処理))
(jo まぁ複雑な処理の中に(jojo 単純な処理)))」
と書けば問題がきちんと記述できることがわかる。これがわかれば後は簡単だ。
君の言うように、どんな言語にだって落とせる。もっともこれが分かった時点で
Lispの場合は既に動くプログラムが手元にあるわけだが。
まあ、大抵はこのあとリファクタリングして整理してゆくがね。
君は、答えが分かった後どうするかって話をしている。難しいのはその前だ。
0083デフォルトの名無しさん
2005/11/29(火) 10:30:030084デフォルトの名無しさん
2005/11/29(火) 21:03:03懇切丁寧なる解説＜−深謝。
いよいよLispらしいことを伺いますが、
))) このカッコのネストは人間にとって、どこまでの
深さが理解出来る限度なのでしょうか？
ワインバーグがPL/Iの例ですがプログラマに
とって基本は三段まで、五段以上は理解不能と
書いています。
ところがLispの場合,setqで関数内部を隠蔽するのを
良しとしない気風？もあってか))))))六段〜七段！
なんて普通に見かけますよね？
（まぁインデント無しで読むのはチト苦しいが…）
Lisperの素質ってネストにどれだけ耐えられるか？
もっと言えば、頭がよじれそうな複雑なネスト構造に
「被虐的な快感！」を覚えるかどうか、
これがポイントでは？
0085デフォルトの名無しさん
2005/11/29(火) 21:11:56> もっと言えば、頭がよじれそうな複雑なネスト構造に
> 「被虐的な快感！」を覚えるかどうか、
> これがポイントでは？
実際に読むのには全く使っていない。
書き方に作法があるので支援環境で組まれたソースを読むのは
pythonと同じスタックしかいらない。（基本はぶら下げで全部表現）
0086デフォルトの名無しさん
2005/11/29(火) 21:14:51並みよりは深いネストに耐えなきゃなんないが、
画面の幅を超えるほどの深さになることはまれ。
要するに問題の深さを抑えられるかどうかがポイント。
つまり、効率的に分割できる能力のこと。
0087デフォルトの名無しさん
2005/11/29(火) 21:40:03Webに転がっているコードを良く見るとわかるが、
開き括弧'('がネストしているケースはそれほどないはずだ。
Lisperがコードを読むときはリスト先頭の名前と
インデントの仕方で判断してると思ってよい。
名前で始まらないリストが現れる場合は何かの構文の中か、
インライン関数の呼び出しぐらいしかない。
Lisperでも
((lambda (a b c) body) x y z)
より
(let ((a x)(b y)(c z)) body)
の様に名前が先頭にある方が読みやすいと考えている。
また、Lispはコードがデータであるが故、
専用エディタが無くてもコードをreadしてpretty printすることで
適切にインデントされたコードを得ることができ、
そのインデント具合から間違いがわかったりする。
0088デフォルトの名無しさん
2005/11/29(火) 21:46:16開き括弧とその直後とインデントで、全体の「かたち」は9割くらい把握できません？
0089デフォルトの名無しさん
2005/11/29(火) 21:47:59[
[
[
[
0090デフォルトの名無しさん
2005/11/30(水) 00:02:42S式単位での編集に慣れたら括弧がない言語の編集がめんどくさくてかなわん。
0091デフォルトの名無しさん
2005/11/30(水) 00:13:34カッコは(特に閉じカッコは)見えなくなるよ。
意識の上ではまさに>>89のような感じ。
009291
2005/11/30(水) 00:42:191関数が長すぎるのもリファクタリング不足って気がする。
高階関数とマクロでいくらでも短くできるはず。
0093デフォルトの名無しさん
2005/11/30(水) 00:42:59Emacs様をちゃんと使いこなしてますか。
0094デフォルトの名無しさん
2005/11/30(水) 00:54:19. . . only try to realize the truth.
Neo: What truth?
Spoon Boy: There is no list.
Neo: There is no list?
Spoon Boy: Then you'll see that it is not the list that bends; it is
only yourself.
0095デフォルトの名無しさん
2005/11/30(水) 01:40:39dabbrevに慣れたせいで別のエディタやIDE(Javaとか使うとき)が使えません。
0096デフォルトの名無しさん
2005/11/30(水) 17:02:47一定だそうです。WEBの発展とプログラマの
増加を考えれば相対的には減少傾向にあります。
しかしながら、少なくとも、このLisp言語には
逆風のなかでも、「しつこく」Lisperは存在する
訳です。この「極」東、日本にさえ…
何故か？
やはり(((())))の魅力にはまるのではないで
しょうか？
それ以外にもう、他の言語に対して差異化するもの
は何もない、と言い切って過言ではないからです。
ネストによる複雑さは初心者にとって確かにLispへの
障壁かもしれませんが、逆に言えばLispに残された
唯一の魅力なんです。
異様な(((())))が気にならない、これこそ既に
Lispにはまっている証ではないでしょうか？
スタック構造って本来、人間の記憶機能に最も近い。
(何とか（何とか（何とか 最後に）））
この（カッコを越えるたびに頭脳負荷がかかりますよね？
各々の機能を理解してスタックに積みこんで行く訳ですから。
解放されるのは）））の後でしかない。
これを楽だって言っちゃ駄目なんです。
この頭脳負荷そのものが快感なんだって言わなければ。
0097デフォルトの名無しさん
2005/11/30(水) 17:19:280098デフォルトの名無しさん
2005/11/30(水) 17:27:02ところで、
LispWorksって結構評判良さげ？
Personal Editionを使用された
経験のある方ぁ！
道誉？
0099デフォルトの名無しさん
2005/11/30(水) 21:50:37> 一定だそうです。
> WEBの発展とプログラマの
> 増加を考えれば相対的には減少傾向にあります。
> しかしながら、少なくとも、このLisp言語には
> 逆風のなかでも、「しつこく」Lisperは存在する
> 訳です。この「極」東、日本にさえ…
> 何故か？
> やはり(((())))の魅力にはまるのではないで
> しょうか？
> ************************************************************
> それ以外にもう、他の言語に対して差異化するもの
> は何もない、と言い切って過言ではないからです。
> ************************************************************
0100デフォルトの名無しさん
2005/11/30(水) 21:51:25> ネストによる複雑さは初心者にとって確かにLispへの
> 障壁かもしれませんが、逆に言えばLispに残された
> 唯一の魅力なんです。
> ************************************************************
> 異様な(((())))が気にならない、これこそ既に
> Lispにはまっている証ではないでしょうか？
> ************************************************************
> スタック構造って本来、人間の記憶機能に最も近い。
> ************************************************************
> (何とか（何とか（何とか 最後に）））
> この（カッコを越えるたびに頭脳負荷がかかりますよね？
> 各々の機能を理解してスタックに積みこんで行く訳ですから。
> 解放されるのは）））の後でしかない。
> これを楽だって言っちゃ駄目なんです。
> この頭脳負荷そのものが快感なんだって言わなければ。
0101デフォルトの名無しさん
2005/11/30(水) 22:11:37書いてしばらくして気付いた。
関数でいいのにマクロがいっぱい...。
■ このスレッドは過去ログ倉庫に格納されています