【入門】Common Lisp その11【質問よろず】
■ このスレッドは過去ログ倉庫に格納されています
Lisp Schemeスレでは恥ずかしくて聞けないようなことを質問したり、
Lisp Schemeスレの話題は高度すぎて気後れする人が話しあったり。
それ以外でもCommon Lispについての話題なら歓迎します。
ま、ゆっくりやりましょう。
「いいものの本質は、いかなる時代においても変わらない」byパワーズ
■前スレ
【入門】Common Lisp その10【質問よろず】
http://peace.2ch.net/test/read.cgi/tech/1361341876/
■Wiki
http://wiki.fdiary.net/lisp/ (id:guest pass:cl)
http://cl.cddddr.org/
http://tips.lisp-users.org/common-lisp/ CommonLispは無くなっても困らないけどs式使う言語が否定される訳じゃ無いからなー
GUIとかI/Oもちっと近代的に再定義できないもんかの>>CommonLisp なんでClojureはdoted pairなくしたんやろ
Symolic expressionはlinked cellが実体やないのか？
おかげでcar,cdrもないらしいやないか
それでもリスプの仲間かい！
レイプの間違いやないか？
エロいのうClojure consセルを次のように定義できるんやな
(define (cons car* cdr*)
(lambda (bool)
(if bool car* cdr*)))
で、かー、くだーや
(define (car cons-cell)
(cons-cell #t))
(define (cdr cons-cell)
(cons-cell #f))
わし、勉強したで
どや！ >>8
Clojureはcons cellのあり方を変えてもLisp族であれると明確にしたんじゃないの？
実際Lispのdot pairってClojureでvector で2値持つのと何所が違うの？ lispworks欲しい
実際emacs slime sbclとどれくらい違うんだろ >>14
GUI使わないならLispWorksもEmacs+Slimeですよ。
ちなみにGUIつかうならフランツ買うべき > GUI使わないならLispWorksもEmacs+Slimeですよ。
GUI使うよ
> ちなみにGUIつかうならフランツ買うべき
なんで？ >>16
とりあえずGUIで日本語使わないならLispWorksでも大丈夫だけど、GUI使うときに付属のエディタが多バイト文字対応してない>>LispWorks
Franzはそのあたり問題ないのとGUIのユーティリティーが凄い良くできてる。
でもお金無いのでFranzは評価版だけしか使ってないけどな!
エディタさえなんとかなるならLispWorks好きなんだけどな! lispworks6からUTF-8で表示で崩れもなく表示もできるし入力もできるよ．
common graphicsよりcapiの方が評判良いと思うけど．
lispworks7からjvmと連携するらしいよ． やっぱり日本語がネックか
とりあえずfreeのacl使ってみる >>18
マジか！
マジならアップグレードするか
#という事を続けてAllegro購入とかわらんくらい突っ込んでるのがなっとくいかねー >>18
jvm連携するくらいならClojreのIDEになってほしい orz Schemeに比べてCommon Lispの利点て何？ ベタベタな手続き型プログラミングがいとも簡単にできるところじゃね？ 偽と空リストが分かれてないとかnilのcar,cdrはnilとかそういうところは地味だけど
マクロ定義とかでリスト操作するときに便利 あとバリバリに最適化してC並の性能に出来るところも気持ちいい Common LispがLisp-2であることは、俺にとっては実用上便利だが、
そうは思わない人たちもたくさんいるだろう。 let over lambdaではちょくちょくageてた common lispって柔軟だけどかゆい所に手が届かない所が多いね
大抵はalexandriaとかkmrclとかcl-ppcreとかsplit-sequenceとか使えばなんとかなるけど
ライブラリが散らばるのが気になる
alexandriaとかkmrclをベースに自分だけが使う一つの巨大なライブラリを作って足りない部分を追加していく方がいいのかな 名前空間みたいに、分けられる概念は分けるのが正義。Scheme はたぶん間違っている。
その意味では CL も副作用を分けなかったのは失敗だった。 プログラム書いるとオレオレマクロとかオレオレ関数ができてくると思うんだけど、みんなこれどこに置いてるの sbclでコンパイルに数秒かかってて
(incf v)
(incf v)
...
をn回繰り返す式を
を(incf v n)にしたらコンパイルが一瞬で終わるようになった
最適化すごい 最初は今書いてるプログラムソースと同じディレクトリに置いて間を見計らって
~/.sbcl/の中に置いて起動時にloadするようにしてる >>34
1． オレオレだと思っていてもalexandriaの中を探すと大抵のものはある．それを使う．
2． なければ，オレオレライブラリでもasdfで読めるようにしておく．quickproject使えば手間もかからん．
初期化ファイルで読み込ませるのはbad practice． ローカルプロジェクトはasdの設定とか面倒そうでやってなかったけど
quickproject使えば自動で生成されるんだな
前より楽になったしもっと早めに調べておけばよかった >>37
やっぱそんな感じなんですかね
一つのore-xandriaにいろいろ詰め込んでquicklispのlocal-projectに置いてるだけだったので、整理しようかなと思ってたんですが
参考になりました (defun fn1 (str)
(print str))
どなたか教えて下さい。
上の様な関数fn1を最適化、型宣言をして下の様な、
(defun fn2 (str)
(declare (optimize (speed 3)(debug 0)(safety 0)))
(declare (string str))
(the string (print str)))
関数fn2になりました。
マクロを使って下のfn3の様にしたいのですが
可能でしょうか。教えて下さい。
(defun fn3 (str)
(high-speed)
(var-string str)
(the-print str)) declareをhigh-speedやvar-stringマクロで表すのは無理
コードウォークするか別のアプローチを取るしかない 書き込んだ後で思い出したけどリードマクロならdeclareに展開しても大丈夫だった (defmacro defun-opt (name args &body body)
(let ((vars (mapcar #'cadr args)))
`(defun ,name ,vars
(declare (optimize (speed 3) (debug 0) (safety 0)))
(declare ,@args)
,@body)))
(defun-opt fn ((string str))
(the string (print str)))
こんなんじゃだめなの？かなりてきとーに書いたけど >>40
CommonLispだから最適化しなくちゃならないとかマクロ使わなくちゃならないというのはむしろ間違い。
書く手間を減らしたいということなら、変数に最適化設定を入れて#.するってことが多いかな。
quicklispで公開されてるライブラリ入手してdeclareでgrepして読んでみると良いよ。
(defvar *normal-optimize* (optimize (speed 1) (debug 3) (safety 3)))
(defvar *full-optimize* (optimize (speed 3) (debug 0) (safety 0)))
(defun fn2 (str)
(declare #.*full-optimize*)
(declare (string str))
(print str)
str) 型宣言とか最適化宣言って最初からつけといた方がいい？
後からつけるのは面倒そうだけど最初からつけるのも面倒だし >>45
コンパイラにチューニングの肝を教える為のシステムだろう？
とりあえず動くコード書いてって言うREPL大好きな人なら後からだし、設計から最適化を含む人なら最初から入れるだけじゃないの？
あんまり難しく考えるとはげちゃうぞ 最初から入れる方向で設計する方が
あとあと抜本的大改造しなくてすみそうな > あとあと抜本的大改造しなくてすみそうな
やっぱり最初から宣言書いといた方が楽かな
はげるのは困るし っていうか
人に聞いて決めるようじゃだめじゃないか？
自分で判断、どう判断しようか、その方針で作っていくうちにその良し悪しを知るのも勉強 40です。
みなさま、ありがとうございます。
特に41さま、42さま、43さま、44さま、
具体例を示していただいて、大変勉強になりました。
また45からの「最初か後か」の議論。
参考にいたします。
ちなみに私は、正解を探る技量が自身に無いと考えていて
ひと通り書いて速度が気になれば「後から」改変する
方法でやっています。
これだと、とりあえず必要な目先の事だけに集中できて
コードのスッキリ感が保てると思うので。 cl-ppcreってparse-stringして正規表現をS式にしたあと
それを使って文字列比較のクロージャを作ってるように見えるんだけど
dfaのコードが見当たらない
文字列比較のクロージャを使うやり方では有限状態機械はいらないのかな clojureとcommon lispとschemeのどれを学んだら良いか悩んでいます。
common lispが気になっているのですが、
モダンLispといわれるclojureの方がJVM言語ということもあって現実的に利用が容易な気もしていますし、
schemeはシンプルということで学びやすいのかなとも思います。
主観でも良いのでおすすめや優位性を教えていただけないでしょうか。よろしくお願いします。 >>53
ここはcommon lispのスレなのでおすすめは決まっているようなものですがclojureです。
ユーザーが親切。 Schemeがシンプルっていうのは正しいけど誤解でもある。
コミュニティで合意できた部分だけが仕様としてまとまったので仕様だけを見るなら綺麗で単純だけど、
決着がついてない論争は膨大にあって、処理系ごとに方針の違いが大きかったりする。
きちんと理解しようとすると、思ったよりは容易でない。
でも、まあ、 Common Lisp よりは楽かな。
Clojure は JVM が先にあって Lisp 的な外観をくっつけたものなので、
言語としての構造は Lisp 的テイストよりも Java 的テイストに寄ってると思う。
いろいろと Lisp っぽくないので Lisp についての理解を深めたいなら
あまり向いてないかもしれない。
現実路線というのはその通りだと思う。
Common Lisp は良くも悪くも Lisp 代表って感じ。 >>53
使って学ぶならClojureがおすすめ
入門書は孔雀が表紙の本がGaucheの人が訳してて読みやすいし分かりやすい
ここCLスレだけど >>53
お勧めは、common lisp
schemeはlisp矯正ギブスみたいなところがあって、他言語やってた人にはいい気がするけど、
何かアプリを作ろうとすると、ライブラリがなくて面倒だったり、処理系依存が増えたりする。
clojureはjavaのライブラリを呼び出せるので、手軽にアプリが作りやすい。まそのおかげで、GUIアプリを作るのがやり易い。
その一方で、JVMの縛りを受ける。
armのlinuxで使おうとしたら、armのJVMがあんまりよくないのか、やたらと重かった。
なんだかんだで、common lispはいいバランスだと思う。
あとlisp族初めてなら、emacsとか入力支援のある環境を使った方がいいよ。 >>53
お勧めはClojure、ちくせうCLスレなのに！！！！
Webアプリとかは特に
CommonLispでお気楽極楽する事もできるけど、準備が大変。(GUIやるにはFFIで根性入れるかお高い処理系買うとか)
Clojureはこの点をJVMに依存することで過去の資産を使えるのが利点。
Schemeは僕は好きじゃ無いので説明に困るからお勧めしない。
なお、WebアプリをCommonLispで作るとmade with alien technologyを実感できてコレがたまらん abclとかいうjvm上で動くcommon lisp処理系もあるよ Clojure人気すぎワロタ
お前らが考えるCommon LISPの実用に足りないこと、
これさえあれば実用できるのになー（ﾁﾗｯﾁﾗｯ
って思うことって何？ コルーチンを実現するためにcl-contでpythonのyieldと同じ機能付けたら
マクロ展開後の式が大きすぎるみたいなこと言われたとき >>53
大人気のclojureに水を指すようだが、あれは first-class continuationsをサポートしていない。初めてリスプ系の勉強するのにはやめておいたほうがいい。初めてのLisp系の勉強には俺はSchemeを勧める。
テキストはThe Little Schemerを勧める。理由は
1. collector（ continuation ）もやるし
2. Y-combinatorもつくるし
3. Scheme上でScheme Interpreterもつくるからだ。
ただ、あくまでS式（Symbolic expression）を扱うので、例えばリストが内部的にどういうデータ構造なのか？は別書でやることになる。
car-cdr部を持つ単位（cons Cell）を次のようにclosureとして表現して見せてるくらいだ。
(define cons
(lambda (u v)
(lambda (t)
(if t u v))))
(define car (lambda (cell) (cell #t)))
(define cdr (lambda (cell) (cell #f)))
;applications
(define a
(cons 1 2))
(car a) -〉 1
(cdr a ) -〉 2
実用アプリをは基礎を学んでからCLででもClojureででも書けばいいんでないかい。 おれの個人的意見。
>>53
scheme は scheme を実装して勉強する言語、と言っていいと思う。実装に興味があるならお勧めできる。特に gauche あたりの実装は素晴らしく綺麗で、面白い。
Common Lisp は何かを作るためのパワフルな道具。使えるようになって損はない。力を付ければ、低レベル層から高レベル層まで扱えるのが強み。ただやや古臭いところも。
Clojure は Lisp の皮を被ったちょっと違う何か、かもしれない。モダーンですごく考えられているし、どんどん進歩していて楽しい。コミュニティも活発。
まあ一つをやったら他のことはできない、なんてことはない。どれも面白いから、どんどん手を出すといいと思う。 >>53
>>62の補足
The Little Schemerでは徹底して再帰的定義でやる。なのでwhileとかでの非再帰的定期は出てこない。非再帰的的定義など（きっと）頭の良いチンパンジーでさえできるようなものはいちいち扱わない！
また、fibonacci数を求めるなどを再帰的に定義すると非再帰的定義に比べてとても処理速が遅くなることがあるが、末尾再帰の書き方も出てくるので
非再帰定義に同等の速度を再帰的定義では発揮するやり方も学べる。
具体的にはcollecterを使った再帰的定義で末尾再帰が実現される例が出てくる。
この辺りもこのテキストを勧める理由た。ただし！意外に難しいかもしれない。最近、書き込みがあったがこのテキストがわからん、あきらめたと。
どうにもチンプンカンプンなら関連しそうな概念や例についめネットなどで予備調査しながらやるといいと思う。教えてくれる人がいればそれが一番だけどね。
「何？、継続がわからん？
あのな、いいか、女とセックスしたい時にな、女を脱がしてからセックスするだろ？まず脱がしてからセックスすることを継続だ。
それにつきる。」 >>53
Schemeはいい言語だけど、何かをやろうとするとちょっとめんどいことが多いかな
完全な主観で言えばCommon Lispが好きだけど、
何かやりたいことがあってそれを実現したいのならClojureが一番楽だとは思う Libraries,??not framework の哲学とか http://eed3si9n.com/node/141 とかが性に合うならClojureでもいいかも
あとは括弧が(Scheme/CLに比べると)少なかったり lisp方言としてはarcが好きだけど処理系がなあ アクセス禁止にされてしまいレスが遅くなって申し訳ありません。
実はland of lispとプログラミングClojureはとりあえず読んだことはあります。(内容は正直曖昧に理解しているところもありますが。)
みなさんのお話を聞いたうえで、今特定の仕事に追われているわけでもないですし、common lispを勉強していこうと思います。
何かをするために言語を学びたいというのももちろんありますが, それ以上にlispという概念についての理解を深めたかったことと, いわゆる`lisper`への憧れから, もっとも満足できそうなのはcommon lispかなと判断しました。
皆さんご意見いただき有難うございました。 最近思うんだけど、Lispの利点で重要だけどあまり宣伝されてないのはrepl。
書いたコードを即時に動かして結果やデータを見つつ、徐々に大きくしていくスタイルは脳汁どばどば出る。
LispマシンやCLIM系のインスペクタやデバッガも、このスタイルのためにあるように思える。 リスプの概念をスマートに認識できるのはスキームだけどな
ま、いいけど
バイバイ >>71
REPL が重要なのは同意。でも、REPL はもっと進化していいと思う。SLIME でもまだ不満だ。
例えばだけど、プロファイリング結果をグラフでREPLとは別のウィンドウに表示し続けるとか。アレグロにはあったけどCLOSのクラス階層を表示してくれるとか。 >>74
LightTableってエディタでclojureいぢると少し近い感じになるかも
CLだとやっぱりFranzとか欲しくなる
小売りで買えないから学習用の奴しか触ったこと無いけどたしかに脳汁が出そう 昔の Lisp の開発環境って使ったことは無いんだけど、スクリーンショットだとか動画とか見ると、
今でいう JavaScript を Chrome の開発環境で使ってるみたいな感じで、かなりリッチなんだな。
slime なんてめじゃないぞ。 どうして退化してしまったのか…。 >>74
現状ライブラリとして広く共有されてるかは別としてそれなら簡単に作れると思うけどね
クラスブラウザなら素朴なのがslimeにもあるよ(require 'slime-xref-browser) M-x slime-browse-classes これもCLOS入門で試しに作ることが多い
replが重要なんじゃなくて対話性が重要ってことなんじゃないのかな
そして他の言語にかなりキャッチアップされてるから，いまとなっては大した特長でもない slime-browse-classes初めて知った
クラスの継承関係を表示するだけでも便利だけどスロットとか出ないの？ >>80
シンボルの上でC-c C-d dすれば良いんじゃねｗ
いずれにせよ柔軟性や透明性など、自由度が段違いですのでカスタマイズするのも自作するのも簡単だろう >>81
その方法なんで気付かなかったんだろ
ありがとう slimeでさえ使い込なせてないのにそれより多機能な>>71があっても豚に真珠だな
早く豚から海豚くらいになりたい うぉー、LightTable かっけー！サンクス！
いろいろいじってみる。
>>78
すまん、おれの説明が悪かった。
クラスブラウザは単なる例で、もっとLispの特徴を活かした開発支援のアイディアはあると思っているんだよ。
それがあることで生産性がぐっと上がるような。
具体例が出せないが、多分一つの方向は、コードから得られる統計的データを生かすものだと思う。 みんな そんなにreplとクラスブラウザが好きなら
Smalltalkにしちゃいなよ Smalltalkと同程度に、インタラクティブに、イテレーティブに、アジャイルに、GUIを含めて開発できるということだな Smalltalk はもう何年も前に死んでるじゃないか clojureから流れてきたものだけど、CLer的にはloopってどういうものだと認識されてる？
同じlispではあるけど、CommonLispは関数型であろうとしてるように感じないんだよね
効率のためなのかわかりやすさのためなのか、ローカルでさえあれば再代入まみれの副作用まみれっていうように感じる
loopも結局使い方によっては関数型の繰り返しっぽいっちゃぽいんだけど、どう使うにしろlispっぽくはないよね？
そのへんどう思われてるのか気になる。気軽に使っていいものなの？ CommonLispはマルチパラダイム言語であって、別に関数型であろうとしているわけではない
Lispは歴史的な理由で関数型と勘違いされているが、手続的にもかけるし関数的にも書けるしOO的にも書ける
状態が増えると保守性もろもろが落ちるのは真なので、そこらへん意識しつつ、適材適所で書けばいい >>90>>91
マルチパラダイムってのは確かに書いてあったけど、利用者側はなるべく関数型っぽく書こうとするべきなのかなと思っていた
Scalaとかだとマルチパラダイムだけどなるべく関数型でかくことが推奨されてるイメージがある
なんでも関数型っぽく書くのではなく、わかりやすく書きやすく目的にあったように書きましょうというのがCLの正しいスタイルなのかな？
つまり状況に適していると判断できればloopをつかうことをためらう正当な理由はないってことか。
性能もdo系統や末尾再帰と比べて申し分ないようだし 出来るだけ関数型で書くかはコーディングスタイルの話じゃないの 概ねそんな感じでいいと思うけど、結局はどんな書き方も許されているので利用者が適宜判断する以外ないってだけかなあ
CommonLispとしての正しいスタイルというものはたぶんない Lisp族は利用者が対象に最適と考える記述を書きやすくしている
他の言語は言語作成者が最適と考える記述を書きやすくしている mapcarは知ってるけど他のmap系は知らないので
hyperspecを眺めていたら疑問に思ったので質問します。
結果を返さないし反映もされないmapcは
どんな有用性があるのでしょうか。
おそらく私の無知なのでしょうが
mapcの存在する意味、使いどころが解りません。
どなたか説明出来ませんか。 >>96
97のとおり副作用目的で使う
用途としてはdolistと同じだがmapcはそれより昔からある
他の言語でいうとRubyのmapとeach、Schemeのmapとfor-eachのような関係
dolistがあるので存在意義が薄れた (dolist (obj lst) (f obj))
の場合は
(mapc #'f lst)
に出来て簡潔 CL はマルチパラダイムなのは認めるけど、最近のパラダイムを取り込めてなくないか？
誰か haskell の型システムを完璧にCLに取り込むべきだ。(liskell は死んだっぽいし) ■ このスレッドは過去ログ倉庫に格納されています
