【入門】Common Lisp その６【質問よろず】
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2009/02/18(水) 00:22:16初心者のQ&A
本スレでは恥ずかしくて聞けない人のQ&A
本スレは高度すぎて割り込めない人のQ&A
linuxでなくてwindowsでやりたいんですが・・・Q&A
lispを使用してC#やJAVAの代替にするための方法（おまけ）
ま、ゆっくりたりましょう。
「いいものの本質は、いかなる時代においても変わらない」byパワーズ
(list
(url http://pc8.2ch.net/test/read.cgi/tech/1101386936/l50 :part 1)
(url http://pc11.2ch.net/test/read.so/tech/1140012484/l50 :part 2)
(url http://pc11.2ch.net/test/read.so/tech/1181479267/l50 :part 3)
(url http://pc11.2ch.net/test/read.cgi/tech/1201402366/l50 :part 4)
(url http://pc11.2ch.net/test/read.cgi/tech/1215834213/l50 :part 5))
□テンプレート置き場□
ttp://wiki.fdiary.net/lisp/ (id:guest pass:cl)
0002デフォルトの名無しさん
2009/02/18(水) 00:23:10(SBCL: http://sbcl.sourceforge.net/
:プラットフォーム UNIX, Linux, Mac, Windows(移植中)
:開発 活発
:日本語 使える（UCS4, UTF8, EUC)
:特徴 一番お勧めのコンパイラ。)
(CLISP: http://clisp.cons.org/
:プラットフォーム UNIX, Linux, Mac, Windows
:開発 そこそこ活発
:日本語 使える
:特徴 バーチャルマシン。遅いがフットプリントが小さい。)
(CMUCL: http://www.cons.org/cmucl/
:プラットフォーム UNIX, Linux, Mac
:開発 そこそこ活発
:日本語 使えない（回避法有り）
:特徴 高速コンパイラ。SBCL の元になった。)
(Clozure CL: http://openmcl.clozure.com/index.html
:プラットフォーム PPC-Linux, Mac, x86_64-Linux と x86_64-FreeBSD に移植中
:開発 そこそこ活発
:日本語 使えない (pre ver 1.1なら多少扱える。)
:特徴 元々商用のコンパイラ。ネイティブスレッドが使える。))
0003デフォルトの名無しさん
2009/02/18(水) 00:23:42(Allegro: http://jp.franz.com/index.html
:プラットフォーム Windows ,Mac OS X , Freeを含む各種UNIX
:開発 ほとんど本陣
:日本語 使える(内部UTF16,外部 プラットフォーム毎)
:特徴 お高いがもっとも頼れる。申し込みが必要だがFree Express Editionあり )
(LispWorkss: http://www.lispworks.com/downloads/index.html
:プラットフォーム Windows ,Mac OS X
:開発 半年にいっぺんくらいアップデート
:日本語 使えるみたい(完全に対応しているかはちとわかりかねまする)
:特徴 IDEベースです、フリー版はconsセルの上限が来るとダイアログ
がでてしまいます、SDLとかで遊ぶとすぐに引っかかります ))
((その他)
(ABCL: http://armedbear-j.sourceforge.net/
:特徴 JavaVM 上で動く。JavaVM のバイトコードを生成。)
(GCL: http://www.gnu.org/software/gcl/
:特徴 日本発 Kyoto Common Lisp の直系。)
(ECL: http://ecls.sourceforge.net/
:特徴 Lisp->C コンパイラ。組み込み可能らしい。こちらもKCLの系譜))
0004デフォルトの名無しさん
2009/02/18(水) 00:24:37http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/cltl/cltl2.html
http://lispdoc.com/
http://clqr.berlios.de/index.html
日本語のチュートリアル
ttp://www.fireproject.jp/feature/common-lisp/index.html
ttp://www.geocities.jp/m_hiroi/xyzzy_lisp.html
ttp://home.soka.ac.jp/~unemi/LispProlog/
ttp://www.haun.org/kent/lisp1/
ttp://wisdom.sakura.ne.jp/programming/lisp/index.html
0005デフォルトの名無しさん
2009/02/18(水) 00:25:09(和文)
ttp://www.geocities.co.jp/SiliconValley-SanJose/7474/index.html
ttp://lispuser.net
(英文)
http://wiki.alu.org:80/
http://www.cl-user.net
http://www.common-lisp.net
http://planet.lisp.org/
http://groups.google.co.jp/group/comp.lang.lisp
http://www.cliki.net/index
http://cl-cookbook.sourceforge.net/
http://www.gigamonkeys.com/book/
( http://www.apress.com/free/ よりpdf版が入手可能)
http://www.psg.com/~dlamkins/sl/cover.html
http://www.cs.cmu.edu/~dst/LispBook/index.html
その他の情報
http://ja.wikipedia.org/wiki/Common_Lisp
0006デフォルトの名無しさん
2009/02/18(水) 00:26:09(POPLOG: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html
Lisp, Prolog, ML のコンパイラ)
(WCL: http://wcl.kontiki.com/
Shared Library として使える Lisp)
(Movitz: http://common-lisp.net/project/movitz/movitz.html
フルスクラッチの Lisp OS)
(CADR LispM: http://www.heeltoe.com/retro/mit/mit_cadr_lmss.html
MIT で使われていた LispM のソースを公開したもの)))
((その他のリンク
(Common Lisp JP: http://www.lingr.com/room/gKpArxPn9wi
チャット)
(lush: http://lush.sourceforge.net/
Lisp Universal Shell)
(実践common lisp: ttp://pcl.lispuser.net/ 実践common lisp 非公式サポートページ)
(Paul Graham の ANSI Common Lisp:
http://www.pearsoned.co.jp/hed/search/onlinecatalog.html?id=276
Common Lisp の 参考書を探しているならこれ一択)))
0007デフォルトの名無しさん
2009/02/18(水) 01:17:07(乙 'make-thread)
0008デフォルトの名無しさん
2009/02/18(水) 01:23:030009デフォルトの名無しさん
2009/02/18(水) 02:32:40*、 *、 ｡*ﾟ *-+。・+。-*｡+｡*
／ ﾟ+、 ﾟ+、 *ﾟ ・ﾟ ＼ 。*ﾟ
∩ *。 *。 +ﾟ ∩ *
(´･ω･`) +｡ +｡ ﾟ* (´･ω･`)
と ﾉ *ﾟ *ﾟ ・ 。ヽ、 つ
と、ノ ・ﾟ ・ﾟ +ﾟ * ヽ、 ⊃
~∪ *ﾟ *ﾟ * +ﾟ ∪~ ☆
+′ +′ +ﾟ ﾟ+｡*。・+。-*｡+。*ﾟ
0010デフォルトの名無しさん
2009/02/18(水) 09:42:400011デフォルトの名無しさん
2009/02/18(水) 09:51:010012デフォルトの名無しさん
2009/02/19(木) 01:20:230013デフォルトの名無しさん
2009/02/19(木) 01:54:050014デフォルトの名無しさん
2009/02/19(木) 02:02:420015デフォルトの名無しさん
2009/02/19(木) 02:59:440016デフォルトの名無しさん
2009/02/19(木) 03:35:30まじ就職してえわ
0017デフォルトの名無しさん
2009/02/19(木) 06:37:27matlabと同じぐらいか
0018デフォルトの名無しさん
2009/02/19(木) 11:38:44乙
0019デフォルトの名無しさん
2009/02/19(木) 13:58:25へー、俺が想像してたよりも安い
0020デフォルトの名無しさん
2009/02/20(金) 11:35:29Clozure CL 1.3 release candidate
* Mac OS X 10.4 and later (PowerPC and x86)
* Linux (PowerPC and x86)
* FreeBSD 6.x and later (x86)
* Solaris (x86)
* MS Windows (x86)
0021デフォルトの名無しさん
2009/02/20(金) 12:50:06過去本スレで100万とか1000万とかとにかく高そうな話はあったけど
今は案外お手頃になってるのか
0022デフォルトの名無しさん
2009/02/21(土) 01:34:19グッドニュースさんきゅ。
0023デフォルトの名無しさん
2009/02/21(土) 04:51:38$599
なんて書いてあるけど
0024デフォルトの名無しさん
2009/02/21(土) 10:54:56もうしばらく待つか
0025デフォルトの名無しさん
2009/02/21(土) 12:10:120026デフォルトの名無しさん
2009/02/24(火) 12:14:03はでてないけど、高速化は期待できるのかも。
0027デフォルトの名無しさん
2009/02/26(木) 23:25:01(+ 1 2 . 3) ; <- こういうの
どうもCommonLispでは仕様で決まってなさそうなのですがなにか理由があるのでしょうか。
0028デフォルトの名無しさん
2009/02/26(木) 23:37:55002927
2009/02/27(金) 01:31:16HyperSpecで確認してみましたがSection 3.1.2.1 Form Evaluation のところにはproper-listでなければならないとは書いていないような気がします。
実装依存にせよエラーにせよ、書かない理由もよく分からないので気になります。
0030デフォルトの名無しさん
2009/02/27(金) 01:42:450031デフォルトの名無しさん
2009/02/27(金) 09:14:39だからISO Cと同じくらいのサイズに収まってる。
003227
2009/02/27(金) 20:24:16未定義の処理系依存エラーと把握しました。
今Lisp処理系を作っていてちょっと気になったので聞いてみました。
どうもありがとうございます。
0033デフォルトの名無しさん
2009/02/28(土) 15:33:37ではどれになるのでしょうか
0034デフォルトの名無しさん
2009/02/28(土) 18:30:33lisperは自分で自分用のフレームワーク作るから
0035デフォルトの名無しさん
2009/02/28(土) 22:25:50フレームワーク: ないことはないけど、 (2、3あった) そっちはあまり知らない。
0036デフォルトの名無しさん
2009/02/28(土) 23:17:23weblockとかhunchentootとか？
hunchentootは使ってて楽しいよ
0037デフォルトの名無しさん
2009/03/01(日) 09:33:05L-99: Ninety-Nine Lisp Problems
ttp://www.ic.unicamp.br/~meidanis/courses/mc336/2006s2/funcional/L-99_Ninety-Nine_Lisp_Problems.html
0038デフォルトの名無しさん
2009/03/02(月) 12:11:58画面を二分して上のS式をC-x C-eで評価したときに
(in-package :hoge)
と言う式を評価したときにslimeのREPLでは
CL-USER>
のままでhogeのパッケージに入ってもらうにはREPLで
(in-package :hoge)
と打たなければなりません。これは設定で解消できるのでしょうか?
それとも仕様でしょうか?よろしくおねがいします。
0039デフォルトの名無しさん
2009/03/03(火) 16:05:030040デフォルトの名無しさん
2009/03/04(水) 21:30:170041デフォルトの名無しさん
2009/03/06(金) 23:54:50うぃんどうず用のlispbox 付属のemacsの日本語対応はよくわからん。参考にしてntemacs-ja
やmeadowあたりを入れても良いかもな。
onjoさんも日本人用のものを作ってたと思うけど。
0042デフォルトの名無しさん
2009/03/08(日) 09:59:33windowsの人ならこれでも良いかもな。windowsでslimeまで使えるようにするのは
敷居が高いしね。
0043デフォルトの名無しさん
2009/03/08(日) 19:46:49うちはWindowsXPがx64なのでsbclが動かないから試せないんだ
0044
2009/03/09(月) 14:30:40AllegroCommonLispのLispBoxでasdf-installをしようと思ったのですが
CL-USER> (asdf-install:install :fare-match)
Package "ASDF-INSTALL" not found. [file position = 14]
[Condition of type READER-ERROR]
; Evaluation aborted
とエラーが出てうまくいきません
何か特別な操作が必要なのでしょうか
004544
2009/03/09(月) 15:21:10http://www.cliki.net/asdf
このサイトには
If you have SBCL, OpenMCL, ECL or ACL, it's bundled and you need only (require 'asdf).
こう書いてあるのにどうしてなんでしょうか
0046デフォルトの名無しさん
2009/03/09(月) 18:45:40ttp://www.cliki.net/ASDF-Install
004744
2009/03/14(土) 18:48:08ここを参考にして
CL-USER> (pushnew "C:/asdf-install/asdf-install/" asdf:*central-registry* :test #'equal)
("C:/asdf-install/asdf-install/" *DEFAULT-PATHNAME-DEFAULTS*)
CL-USER> (asdf:operate 'asdf:compile-op :asdf-install)
; Evaluation aborted
入力してみたんですが
component "asdf-install" not found
[Condition of type MISSING-COMPONENT]
こうなってしましました
0048デフォルトの名無しさん
2009/03/14(土) 19:35:30asdf-install を＊ちゃんと＊どっかから持ってきた?
004944
2009/03/14(土) 19:51:43これをCドライブ直下に解凍し、
http://cclan.cvs.sourceforge.net/cclan/asdf/
さらにここからasdf-install.lispをダウンロードしてasdf-install.asdと同じフォルダに入れています
0050デフォルトの名無しさん
2009/03/14(土) 21:57:48> EmacsでのLisp開発環境としてSLIMEを使用しているのですが、
> 画面を二分して上のS式をC-x C-eで評価したときに
> (in-package :hoge)
> と言う式を評価したときにslimeのREPLでは
> CL-USER>
> のままでhogeのパッケージに入ってもらうにはREPLで
> (in-package :hoge)
> と打たなければなりません。これは設定で解消できるのでしょうか?
> それとも仕様でしょうか?よろしくおねがいします。
(defpackage :hoge
(:use :common-lisp)) C-x C-e
(in-package :hoge) C-x C-e
C-x o でREPLにカーソルを持ってきて
，キーを押下
ミニバファでCommand:って出るからchange-packageとして
Package: hoge
005238
2009/03/15(日) 15:37:10非常に助かりました。
0053デフォルトの名無しさん
2009/03/15(日) 16:30:10専ブラアップデイトしろ
0054デフォルトの名無しさん
2009/03/18(水) 12:45:21C-x oじゃなくてslime selecterにキー割り当てるのはしないの？
0055デフォルトの名無しさん
2009/03/18(水) 20:35:22やっちまったぜぇ
ありがとう
>>54
> >>51
> C-x oじゃなくてslime selecterにキー割り当てるのはしないの？
slime selecterの説明が必要だろ
この場合は C-x o じゃ駄目か？
0056デフォルトの名無しさん
2009/03/18(水) 20:51:19最近 slime モードのテキストバッファ(要は lisp ファイルを編集している時)
の、日本語入力が不自由なんだけど、これは *BSD で Wnn7 を使い続けてる
俺ん所だけの現象？？？
0057デフォルトの名無しさん
2009/03/18(水) 21:19:270058デフォルトの名無しさん
2009/03/18(水) 21:37:00うち固有だとは思うんだが、今年の正月すぎからスペースで変換しなった
repl バッファは変換する。たぶん egg のキーマップ周辺
slime はとりあえず動いてるし、日本語出力する用事もないし、「かな漢」
までめんどうみてる暇もないので放置状態
emacs のバージョン問題もあるかも知れない
0059デフォルトの名無しさん
2009/03/18(水) 21:56:24お主、ブラックボックスは嫌いなのではないか？
フフフ。丁度良い物がある。
つ SKK
0060デフォルトの名無しさん
2009/03/19(木) 01:02:130061デフォルトの名無しさん
2009/03/19(木) 01:11:260062デフォルトの名無しさん
2009/03/19(木) 10:34:430063デフォルトの名無しさん
2009/03/19(木) 12:14:240064デフォルトの名無しさん
2009/03/19(木) 16:54:41`(with-open-file (os ,filename :direction :output :if-exists :supersede)
,@body))
として、
(util-fout "filename" (format os "hello world"))
などと使うような util-fout を重宝して使っているのですが、
すぐに分かるとおり、os は外部変数補足をするので困っています。
もっと良い設計はありませんか？
with-open-file をそのまま書けばいい。というのももっともですが、、、
0065デフォルトの名無しさん
2009/03/19(木) 22:24:29C-c C-z
0066デフォルトの名無しさん
2009/03/20(金) 00:16:33REPLでぐだぐだコード書く時に同じよーなマクロ使うけど、
困るような所では使わないなあ。
(defmacro >> (fn &body body)
`(let ((*standard-output*
(open ,fn :direction :output :if-exists :append :if-does-not-exist :create)))
(prog1 (progn ,@body)
(close *standard-output*))))
(>> "./hoge.txt" (mapc #'print '(hoge fuga hage)))
普通にプログラムを書く時はwith-open-fileを使った方が
良いと思ってるんだけどどうなんだろ。
慣用句っぽいマクロとかあるのかな。
0067デフォルトの名無しさん
2009/03/20(金) 02:11:14アナホリックマクロ
0068デフォルトの名無しさん
2009/03/20(金) 02:14:19http://www.komaba.utmc.or.jp/~flatline/onlispjhtml/variableCapture.html
0069デフォルトの名無しさん
2009/03/20(金) 17:18:20> >>51
> C-c C-z
おぉ，正しくはこれか
ありがとう
でも，つい C-x o を押してしまうよ（笑
007064
2009/03/23(月) 12:18:02アナフォリックマクロ＆自分のコードということで、
"os" の変数名を長くしてパッケージに入れることまではして、
とりあえずそのままにしました。
0071デフォルトの名無しさん
2009/03/24(火) 21:50:34common lispから使う方法はないのでしょうか
簡単に言うとシェルスクリプトをcommon lispで書きたいのです
0072デフォルトの名無しさん
2009/03/25(水) 01:29:33(ext:run-shell-command "ls")
とか？
sbclの場合sb-ext:run-programだそうな
0073デフォルトの名無しさん
2009/03/25(水) 02:22:440074デフォルトの名無しさん
2009/03/25(水) 02:23:02(ext:cd)
0075デフォルトの名無しさん
2009/03/27(金) 16:16:58defpackage の中の :export に記述する必要があるはずですが、
クラスをパッケージの中で定義する際に、
クラス名がエクスポートされていればいつでもスロットのアクセス関数等も
エクスポートされているようにするにはどうしたら良いですか？
全てのアクセス関数を :export に書かないといけないとすると不便すぎるのですが。
0076デフォルトの名無しさん
2009/03/27(金) 21:27:32なんか方法あるのかね
自分が使ってる有名どころのパッケージのソース見てみたけど全部列挙してるね。
まあ、外部とのインターフェースとなる部分だから慎重さが必要な部分だし不便ぐらいでちょうどいいんじゃない
defpackageは便利マクロであってエクスポートの唯一の手段じゃないからCLOSの機能を駆使すればできそうにも思うけど自分には無理だ
0077デフォルトの名無しさん
2009/03/27(金) 21:27:44もれも仕事ではJavaとかなんで>>75の言いたいことはわかる気がするが、
CLOSの場合はアクセス関数といってもクラスに所属するのものではないからなぁ。
CLOS流儀に馴染むというか、考え方をかえてもらうほうが建設的かな。
本当に細粒度にアクセサを公開しないといけないの？もっと美しいインターフェースは設計できない？
0078デフォルトの名無しさん
2009/03/27(金) 23:21:48読む側からしたら頭の方にexportでまとまってた方が追うのが楽じゃないかなとか思った。
ちょっとずれるけど、これ思いだした。
ttp://d.hatena.ne.jp/patterson/20081115/1226724801
>Q2:defclassを書くのって面倒くさい、黒田さんは全部書いていますか？
>A2:emacsの機能で楽してるけど、全部書いている。
>
>Q2:マクロは使わないのですか？
>A2:マクロを入力量を減らすために使うのは勧めない。
>Editorでがんばるべき。マクロは新しい語彙を入れ込むためのもの。
>安易に使うべきでない。自然言語の世界でも自分勝手な言葉を
>話すやつとはつき合いたくない。
0079デフォルトの名無しさん
2009/03/27(金) 23:42:10上手に作れば読みやすいソースになる。
オブジェクト指向の人がやたらクラスを作ってスパゲティにするのと似てるかも。
関数を作るにしてもinlineを使えば埋め込むこともできるけど、これは最適化のときの話
だもんな。
008075
2009/03/27(金) 23:49:23なるほど。アクセス関数は総称関数側だったんですね。
defclass で書いてるのでクラス側にあるのかと勘違いしていました。
じつは MOP でなんとかならないかといろいろ勉強してたんですけど、
ギブしました。
defpackage の :export の部分を間違えずに書けるように、
ファイル内のシンボル等の定義を読み、公開用には ":" をつけながら
全て出力するツールを作ってたんですけど、
これをアクセス関数にも適用できるように変更することとしました。
それでとりあえず良しとします。
0081デフォルトの名無しさん
2009/03/27(金) 23:58:14こういうのは違うかな
http://common-lisp.net/project/moptilities/documentation/metabang.moptilities-package/function-generic--functions.html
試してないけど総称関数を列挙してくれそうな雰囲気。
0082デフォルトの名無しさん
2009/03/28(土) 00:23:54> (defclass a () ((a :reader a-of)))
#<STANDARD-CLASS A>
> (moptilities:generic-functions 'a)
(#<STANDARD-GENERIC-FUNCTION A-OF (1)>)
取り出せたけど関数オブジェクトからどうやって元のシンボルに戻せば。。。うう
0083デフォルトの名無しさん
2009/03/28(土) 00:36:58他の関数を使えば望みのことはできそうだ
> (moptilities:slot-names 'a)
(A)
> (moptilities:slot-properties 'a 'a)
(:NAME A :INITARGS NIL :INITFORM NIL :READERS (A-OF) :WRITERS NIL
:DOCUMENTATION NIL)
クラスのスロットの属性にアクセスできりゃもうこっちのもんでしょ
アクセサ関数のシンボルを取り出してexportしてやればいい
0084デフォルトの名無しさん
2009/03/28(土) 01:14:01指定したクラスのアクセサ関数（リーダ関数だけを見てるのでもうちょっとリファイン必要）を全部exportする。
(defun export-slot-accessors (cls)
(loop for a in (loop for s in (moptilities:slot-names cls)
nconc (destructuring-bind (&key readers &allow-other-keys)
(moptilities:slot-properties 'a s) readers))
do (export a)))
しかしなあ主にパッケージ使う側の人間から言わしてもらうとあれこれエクスポートするパッケージは使いにくいぞな
0085デフォルトの名無しさん
2009/03/28(土) 06:12:53そんなのだめだぁ。必要もないものexportしないでくれぇぇぇ。
exportするものは厳選すべき。
0086デフォルトの名無しさん
2009/03/28(土) 09:10:070087デフォルトの名無しさん
2009/03/28(土) 22:55:28リスナーやエディタウィンドウで日本語'を入力したいのですが、まともに
入力／表示出来ません。こういうものですか?
Windows版ではどうですか?
0088デフォルトの名無しさん
2009/03/28(土) 23:40:53008987
2009/03/29(日) 11:45:50情報ありがとうございます。
うーん、Mac版も内部的にはちゃんと処理しているみたいなんですけど。
Slime経由で使えばいいのかな…。
0090デフォルトの名無しさん
2009/04/08(水) 09:59:330091デフォルトの名無しさん
2009/04/09(木) 09:49:11単一ディスパッチの言語だとクラスは名前空間の導入という側面があると
思いますが、多重ディスパッチの言語だとメッセージ送信先がひとつではないため、
一意に定まらないと思います。
よってCLOSのクラスでは名前空間の導入は行えない、これは分かります。
ここからが質問なんですが、CLOSにおいて、総称関数の名前空間の汚染に対しては
どのように対処すればよいのでしょうか？
パッケージシステムが解なのかと思いましたが、そうなると、オブジェクトごとにパッケージを
用意する必要がありますので、とても面倒な気がします……
0092デフォルトの名無しさん
2009/04/09(木) 10:13:17・総称関数は名前空間を越えて共通の名前であることが有用性上に重要。
それを名前空間を汚染するという風には考えない。
そのくらい名前は重要。
0093デフォルトの名無しさん
2009/04/09(木) 11:23:31ありがとうございます。ですが、メッセージ名を気をつけても、現実としてメッセージ名の
衝突は起こると思います。
たとえばC++で申し訳ないんですが、
class Foo
{
virtual void update() = 0;
};
class Bar
{
virtual void update(bool flag) = 0;
};
があるとすると、メッセージ名がupdateと同じでもメッセージのプロトコルが違います。
C++なら単一ディスパッチなので、メッセージ送信先とメッセージ名で呼ぶべきメッセー
ジのプロトコルが定まります。
ですが同じことをCommon Lispでしようとしたら、パッケージにくるんで、呼び出し元で
(foo:update foo-instance)
(bar:update bar-instance t)
とする方法か、もしくは総称関数を
(defgeneric update (o &rest rest))
と定義するくらいしか思いつきません。前者はどうみても冗長ですし、後者はCommon Lisp
の引数チェック機構が死にます。
根本的に勘違いしてる可能性もありますが、うまい方法はないでしょうか。
0094デフォルトの名無しさん
2009/04/09(木) 12:38:25(defclass foo () ())
(defclass bar () ())
(defgeneric update (obj &rest args))
(defmethod update ((obj foo) &rest args)
(declare (ignore args))
...)
(defmethod update ((obj bar) &rest args)
(destructuring-bind (flag) args
...))
何か問題があるのだろうか?
0095デフォルトの名無しさん
2009/04/09(木) 13:33:16ありがとうございます。
この場合困るのが、クラスBarを後から追加した場合です。
クラスFooを作ったときに作った総称関数とメソッドの定義を変更しないといけませんが、
これはOpen-Closed-Principleの観点から言ってよい方法であるとはいえません。
これを回避しようとしたらおそらくはパッケージシステムを使うことになるのでしょうが、
(foo:update foo-instance)
(bar:update bar-instance obj)
という冗長な記述になってしまいます。
あるいはパッケージにくるんだ上で、
(defgeneric update (obj &rest args))
という総称関数を作ってdefmethodで分岐するという手もありますが、単一ディスパッチの
言語では必要無かった苦労（パッケージング、defmethodの実装）を強いられる、という点で
腑に落ちません。
もし「総称関数は名前が重要。衝突しないように名前は決めるべき」というのが解ならば、いうのは
簡単です。
ですが、それを真に実現しようと思ったら、作るべきクラスのインターフェイスを書く前からすべて把
握する必要があります。これは非現実的です。
この辺りCLOSではどうやって解決するのがよいのでしょうか？
それともこんなものなのでしょうか。
0096デフォルトの名無しさん
2009/04/09(木) 15:03:53つか flag に相当する部分は, 普通, クラスに閉じ込めないか?
通常, リファクタリングの最有力候補だよね >>93 って.
> 言語では必要無かった苦労（パッケージング、defmethodの実装）を強いられる、という点で
> 腑に落ちません。
どっち転がってもメソッドは定義しなきゃいけないわけで,
たいした手間じゃないだろうに…
(defmethod bar ((obj foo))
(if *bebhavior-flag*
...))
(let ((*behavior-flag* t))
(bar (make-instance 'foo)))
的な, 逃げもなくはないが…
0097デフォルトの名無しさん
2009/04/09(木) 17:30:52・メッセージ名が同じ
・プロトコルが異なる
この二つを満たすメッセージを定義する上手い方法が総称関数には無いのではないか、という点です。
単一ディスパッチの言語にはあるにもかかわらず、です。
リファクタリング等の話は前提を覆しています。
>どっち転がってもメソッドは定義しなきゃいけないわけで,
>たいした手間じゃないだろうに…
単一ディスパッチの言語で必要のないこと、という点で大きな手間です。
単一ディスパッチの言語ならばメソッドのパッケージングもクラスによって分岐するメソッドの
定義も不要です。
もし統一的に表すために新たに総称関数を新たに定義した場合、その総称関数をどこに配置
するかという事も新たに考えねばなりませんし、機械でできそうな処理を人間が書く必要が
あるという点でLisp的ではない気がします。
もしこのような場合、Common Lispでは単一ディスパッチ言語が提供していたクラスによる名
前空間の導入を手動で行わなければならない、そういう仕様だ、というのならそういうものな
のかとあきらめます。
ですが、もし上手い方法があるのであれば教えてほしいと思った次第です。
0098デフォルトの名無しさん
2009/04/09(木) 18:24:35上のほうで誰かが名前重要って書いてるよね
updateって名前がまずだめ。「更新」てどんだけ広い概念を総称させとる
そらぶつかるわ
総称関数はメッセージ名じゃないし
マルチプルディスパッチの言語では簡単なことが単一ディスパッチの言語だとくそ面倒くさくなるよね。そして逆のこともあるよ
既知の概念で理解できないものを否定して安心したがる心理はある程度理解するが、なぜ君の知ってる言語の延長線上にLispがあると思った？別もんだぞ
でもってC++に帰りな。マジオススメ。C++のほうがうまく書けるものをなんでLispでやる
0099デフォルトの名無しさん
2009/04/09(木) 19:29:08すいません、わからない点があるのですが、
>総称関数はメッセージ名じゃないし
確かに総称関数の名前がメッセージ名では無いとすると、今までの私の指摘は当たらないことになります。
ですがそれならば、総称関数の名前はオブジェクト指向における何を表現しているのでしょうか？そしてどういう
名前が適切なのでしょうか？
updateが出たのでJavaのObserverパターンの実装を例に挙げます。Observableの実装は
どうでもよいとして、JavaのObserverの実装を機械的にCommon Lispに変換しますと
(defgeneric update (o obj arg))
になると思いますが、貴方の話ですとこの総称関数名はまずいということになります。
（クロージャで事足りるでしょうが、ここではそういう話はしてないのに注意してください）
クラス名をプレフィックスやサフィックスにしたり、クラス名のパッケージで包むという方法は考えられますが、
それは単一ディスパッチの言語に比べて冗長であるのは先に書いた通りです。
この場合、どのような名前が適切になりますか？
>既知の概念で理解できないものを否定して安心したがる心理は
多重ディスパッチや総称関数について一度も否定してません。
ただ総称関数だと上手く記述できない場面があるのではないか、という話をしているだけです。
これを否定と捉えて煽るのはちょっとひねくれすぎてるのではないかと。
0100デフォルトの名無しさん
2009/04/09(木) 19:41:21>マルチプルディスパッチの言語では簡単なことが単一ディスパッチの言語だとくそ面倒くさくなるよね。そして逆のこともあるよ
要するに今指摘してる点が多重ディスパッチで困難な点、ということなのでしょうか？
0101デフォルトの名無しさん
2009/04/09(木) 20:15:41Java 風の思想をそのまま持ち込むとうまく当て嵌らないのはアタリマエで、
デザインパターンを持ち出して「これをCLで書くと…」なんて議論はナンセンス。
だいたいオブジェクト指向なんてのも広すぎる概念で、
CLのオブジェクト指向は Java とは違ったオブジェクト指向なんだよ。
Java なんか一旦忘れろよ。
■ このスレッドは過去ログ倉庫に格納されています