【入門】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)
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 なんか一旦忘れろよ。
0102デフォルトの名無しさん
2009/04/09(木) 22:31:460103デフォルトの名無しさん
2009/04/09(木) 23:16:29概念A に対しては パッケージX:update
概念B に対しては パッケージY:update
という別の名前を使うんだよ。
自分の知らないことを自分の知っている範囲の見方でしか切らないくせに
> これを否定と捉えて煽るのはちょっとひねくれすぎてるのではないかと。
とか笑ってしまうわ。
0104デフォルトの名無しさん
2009/04/09(木) 23:25:38＞問題にしてるのは
＞・メッセージ名が同じ
＞・プロトコルが異なる
C++のオーバーロードのおかげで「同じメッセージ」のように見えるが、実態としてメッセージとしてもプロトコルとしても同じではないものな希ガス。
というか、あえて言うならメンバ関数名とシグネチャあわせてひとつのメッセージ名でないの？
function update(target, flg) {
target[arguments.callee.name+'With'+flg.constructor.name].apply(null, arguments);
}
function updateWithBoolean(target, flg) { // update(obj, true)相当
/* ほげほげ */
}
function updateWithNull(target) { // update(obj)相当
/* ふがふが */
}
↑こういう付加情報からのメッセージ名推測(?)みたいな動的なことをC++,Java他はコンパイル時に暗黙のうちにやっているというだけでないのかな。
＞この二つを満たすメッセージを定義する上手い方法が総称関数には無いのではないか、という点です。
＞単一ディスパッチの言語にはあるにもかかわらず、です。
異なるメッセージをプレフィクスに基づいて同じメッセージのように推測するという「特別扱い＝オーバーロード」があるかないかというだけで、
単一ディスパッチ/多重ディスパッチの問題じゃないんじゃないかと思うぞ。Objective-Cなんかこういうことしてくれないでしょ。単一ディスパッチ”なのにもかかわらず”。
＞もし統一的に表すために新たに総称関数を新たに定義した場合、その総称関数をどこに配置
＞するかという事も新たに考えねばなりませんし、機械でできそうな処理を人間が書く必要が
＞あるという点でLisp的ではない気がします。
そこでLisp的にはマクロの出番なんでないかな。
※Lisp系のスレでJavascriptで答えてしまってすまないorz
0105デフォルトの名無しさん
2009/04/10(金) 00:18:06で、総称関数のラムダリストには決まりがある
それぞれのラムダリストは同じ個数の必須引数を持っていなければならない
それぞれのラムダリストは同じ個数の付加引数を持っていなければならない
その他いくつかの決まり事がある。>>93はこの決まりを守ってない
だからCLOSでは書けない。あきらめがつくならあきらめてくれ
総称関数がクラスの所有物でない時点で、関数名のみで自己説明的であるべきなんだよ
衝突しやすい名前選んどいて衝突したとかいうな
それでも衝突した場合にはどちらをインポートするかどっちもしないのか選べるんだし
どちらもインポートしなければ>>93の場合、あなたがどう見ても冗長と
言ってる方法で明示するしかないし自分にはどう見ても冗長に見えない
必要にして十分なことしか書いてない
0106デフォルトの名無しさん
2009/04/10(金) 00:21:17どういうつもりだてめー
そういう言葉は、オレたちの世界にはねーんだぜ……
そんな、弱虫の使う言葉はな……
「メッセージ名」…そんな言葉は使う必要がねーんだ。
なぜなら、オレや、オレたちの仲間は、
CLOSすると、頭の中に思い浮かべた時には！
切り替えが終わっちまってるからだッ！
だから使った事がねぇー
わかるか？俺の言ってる事…え？
「総称関数」なら、使ってもいいッ！
0107デフォルトの名無しさん
2009/04/10(金) 01:06:120108デフォルトの名無しさん
2009/04/10(金) 01:16:05総称関数なＣＬＯＳだと「この関数の仕事は何か」から考えるから、
両者だと発想の順序が逆っていうか。
総称関数の名前がぶつかったらどうしようって心配は、
ある意味クラス名がぶつかったらどうしようって心配くらいには杞憂なんじゃないかな。
0109デフォルトの名無しさん
2009/04/10(金) 01:26:36>というか、あえて言うならメンバ関数名とシグネチャあわせてひとつのメッセージ名でないの？
ああ、確かにそう考えると視野が広がります。
多重ディスパッチだと、メッセージ送信先もメッセージ名の一部と考えることができ、
そしてCLだとたまたまオーバーロードの機能が無い＝異なるシグネチャから実行すべきメッ
セージの実装を決定する機能が無いと。
>>105
>だからCLOSでは書けない。あきらめがつくならあきらめてくれ
わかりました。
>総称関数がクラスの所有物でない時点で、関数名のみで自己説明的であるべきなんだよ
私は先に上げた場面をCLOSで解決できるのか、そして解決できないのであればその対処法を
欲していたので、この命名指針の提示は非常に助かります。
>どちらもインポートしなければ>>93の場合、あなたがどう見ても冗長と
>言ってる方法で明示するしかないし自分にはどう見ても冗長に見えない
冗長といってるのは、メソッドに対してクラスが名前空間を導入するという単一ディス
パッチの言語に対しての話なので、CLの視点では確かに必要十分ですね。
冗長と感じるか否かはただ単に慣れの問題かもしれません。
>>108
なるほど、わかりました。
私の中では解決することができました。長々とすいません。
ありがとうございました。
0110デフォルトの名無しさん
2009/04/10(金) 01:36:33Lispの世界で広く使われている枠組みの上では無理ってだけで、
その気になればいくらでも新しい枠組みを言語レベルで追加できる余地があるってのは大きい。
0111デフォルトの名無しさん
2009/04/10(金) 02:00:03そりゃいきなりクラスのメソッドって概念がブチ壊されたんだ、衝撃を受けるのは当然だ！
割と適当に作れたアクセサまでインターフェース並に外から丸見えになっちまうんだからな。
オレだってヤバイと思う！
だが！オレたちのチームの他のヤツならッ！
あともうちょっとで喉元に喰いつけるって時に、俺の知ってる〜できないんですね終了とか思考停止したりはしねぇ！
たとえ処理系の見た目がショボかろうと、ライブラリが揃ってなかろうともな！
オメーはマンモーニなんだよ！Java基準でビビったんだ！IDE支援に甘ったれて名前の命名を軽視してんだ！
分かるか？え？俺のいってる事。
Java のせいじゃねぇし、CLOSのほうが優れていると主張するわけでもねー。ただ、「違っている」だけだ。
だが、心の奥のところでオメーには他の思考モデルを認めるのにビビリがあるんだよ！
成長しろ >>109！ 成長しなきゃオレたちは「栄光」をつかめねぇ。
0112デフォルトの名無しさん
2009/04/10(金) 02:15:080113デフォルトの名無しさん
2009/04/10(金) 08:29:10もっと普通の表記がいいとおもいませんか
0114デフォルトの名無しさん
2009/04/10(金) 08:54:18普通って何だよ？
このスレ的には CLOS が普通なんじゃね？
その質問はナンセンス。
0115デフォルトの名無しさん
2009/04/10(金) 09:28:180116デフォルトの名無しさん
2009/04/10(金) 10:28:21closの力不足もあるのかなあ
0117デフォルトの名無しさん
2009/04/10(金) 10:39:02java風のが欲ければ自ら作る必要があるね。グレアムおじさんのon lisp
でもオブジェクト指向言語の作りかたはかいてるので参考にすればいい。
CLOSはjava/C++族のものにくらべると繋りがゆるやかだし、
面倒な処理は少いんだが、だからマルチディスパッチでも
とりあえつあつかえる。言葉は同じオブジェクト指向でも、
考えかたは違いが大きいので、同じ目線で考えないことは
理解する上でも大切かな。
むしろ、CにCLOS風のゆるやかなオブジェクト指向を加えてもらったほう
がありがたい。C-LOS言語とでも名付けてね。
0118デフォルトの名無しさん
2009/04/10(金) 10:43:33グレアムおじちゃんみたいに忌み嫌うことはないけど、普段から多様すると、
スパゲティメイカーに早変りなので注意が必要かな。
0119デフォルトの名無しさん
2009/04/10(金) 17:44:53／／／）
／,.=ﾞ''"／
／ i f ,.r='"-‐'つ＿＿＿_ こまけぇこたぁいいんだよ！！
/ / _,.-‐'~／⌒ ⌒＼
／ ,i ,二ﾆ⊃（ ●）. （●）＼
/ ﾉ ilﾞフ::::::⌒（__人__）⌒::::: ＼
,ｲ｢ﾄ､ ,!,!| |r┬-| |
/ iﾄヾヽ_/ｨ"＼ `ー'´ ／
0120デフォルトの名無しさん
2009/04/10(金) 22:27:25単純に dynamic loader がらみの話じゃね?
g++ 一つとってみても abi ころころ変わるから,
他の言語でサポートするとなると結構大変だもん
0121デフォルトの名無しさん
2009/04/10(金) 23:29:29標準ライブラリにメッセージ渡し式のOOシステムが入っているので
興味のある人は見てみるといいんじゃないだろうか。
0122デフォルトの名無しさん
2009/04/10(金) 23:49:370123デフォルトの名無しさん
2009/04/10(金) 23:59:010124デフォルトの名無しさん
2009/04/11(土) 02:06:370125デフォルトの名無しさん
2009/04/11(土) 08:28:14こーゆうの？なんていうか、俺には冗長過ぎて無理だった。
http://www.foldr.org/~michaelw/projects/jclos/
0126デフォルトの名無しさん
2009/04/11(土) 10:17:49冗長だなぁ。。orz
0127デフォルトの名無しさん
2009/04/11(土) 12:15:05そこの参考文献の
Andreas Paepcke,
"User-Level Language Crafting (Introducing the CLOS Metaobject Protocol)"
面白いよね。タイムリーな話題。
;;; 馬鹿syntax sugar系じゃないよ。
0128デフォルトの名無しさん
2009/04/11(土) 12:42:45という思考だと、読む以前の問題じゃないのかなと思ったり
0129デフォルトの名無しさん
2009/04/11(土) 12:52:45そんな書き方しねえよ。
0130デフォルトの名無しさん
2009/04/11(土) 17:50:310131デフォルトの名無しさん
2009/04/12(日) 17:05:35(name-of instance)
じゃないの？
0132デフォルトの名無しさん
2009/04/12(日) 18:47:16>>131みたいに、インスタンスのnameプロパティへのアクセサをどう命名するかってユーザーレベルの話とは違くて
クラスの名前を取得する場合の話
0133デフォルトの名無しさん
2009/04/13(月) 03:27:49長い名前でもいいんじゃない
mutiple-value-bind
なんて素でうちこまないし
0134デフォルトの名無しさん
2009/04/13(月) 04:25:130135デフォルトの名無しさん
2009/04/13(月) 04:58:37なんかイヤな名前だな
0136デフォルトの名無しさん
2009/04/14(火) 22:27:49むちぷる ばりゅー ばいんど
むしろ何か惹かれるものがあるが・・・
0137デフォルトの名無しさん
2009/04/15(水) 15:18:31なんてありそうでないか
0138デフォルトの名無しさん
2009/04/16(木) 08:24:380139デフォルトの名無しさん
2009/04/16(木) 12:18:230140デフォルトの名無しさん
2009/04/16(木) 13:41:18cl-pngぐらいしかないのでしょうか
0141デフォルトの名無しさん
2009/04/19(日) 15:27:490142デフォルトの名無しさん
2009/04/21(火) 18:09:290143デフォルトの名無しさん
2009/04/21(火) 22:36:300144デフォルトの名無しさん
2009/04/23(木) 02:35:30環境構築の段階でつまづいていますのでご教示下さい。
1) SBCLでwinアプリ作成
=>最初にDOSプロンプトが立ち上がってしまうのでDOSプロンプトを立ち上げないようにしたい。
っていうかファイルでかすぎ
2) CLISPでwinアプリ作成
=>最初にDOSプロンプトが立ち上がってしまうのでDOSプロンプトを立ち上げないようにしたい。
3) ECLでFFIの利用方法が分からない。exeを実行しようとすると以下の様になる。
errorlog: http://www.4shared.com/file/101112943/cb682248/ecl.html
SBCL、CLISP、ACLはconflict起こさないし、一般的なライブラリだと思ってるのですが・・・
3-2) ECLでLispbuilderがインストールできない。
errorlog: http://www.4shared.com/file/101061621/13a90384/lispbuilder.html
ちなみに"C:/etc/cvs/ecl/site/lispbuilder-sdl/trivial-garbage/trivial-garbage.c"というファイルは存在しないので意味がわかりません。
4) ACL(free)でそもそもexeの作成方法が分からない。
目的はLispでwindowsアプリを作ることです。
とりあえず1〜4のどれかひとつでも打開出来れば後はなんとかなると思うんですが・・・
他の方法でも普通のwindowsアプリを作成する方法があればそれでも構いません。
商用ACLを買うというのは無しの方向で
どなたかお力添えをよろしくお願いいたしますm(_ _)m
0145デフォルトの名無しさん
2009/04/23(木) 03:51:28アプリを作りたいんだったらlisp系言語は向いてないと思うよ。
よいハカーは道具を適材適所で使います。
プログラミングのお勉強がしたいということならまずは*nixのインスコがおすすめ。
0146デフォルトの名無しさん
2009/04/23(木) 04:02:2210
> (* 5 *)
50
> (* 5 *)
250
"*"を変数として通常使用することもないと思いますが、
なぜ最初の"(* 5 *)"の後に"*"が50になるのか解説求む。
0147デフォルトの名無しさん
2009/04/23(木) 04:19:20http://www.lispworks.com/documentation/HyperSpec/Body/v__stst_.htm
The variables *, **, and *** are maintained by the Lisp read-eval-print loop to save the values of results
that are printed each time through the loop.
0148デフォルトの名無しさん
2009/04/23(木) 04:22:26> 4) ACL(free)でそもそもexeの作成方法が分からない。
フリーのExpress editionにはその機能はついていません。
スタンドアロン実行ファイルを作成するにはEnterprise editionに付属している
Runtime licenseが必要になります。
> 目的はLispでwindowsアプリを作ることです。
現時点では、フリーの処理系でまともにWinアプリを作成するのは非常に難しいと思います。
私は試したことがないですが、Winアプリの作成をサポートしてるLispWorksやCorman CLを
使うのがいいんじゃないでしょうか。特にCorman CLはWindows専用という珍しい処理系で、
Win32 APIを簡単に扱えることを売りにしているようです。
0149デフォルトの名無しさん
2009/04/23(木) 09:01:15これだって立派なWinアプリなのに…
0150デフォルトの名無しさん
2009/04/23(木) 09:37:07アプリ作りをするんだったらlinixやFreeBSDじゃまいか？
0151デフォルトの名無しさん
2009/04/23(木) 10:25:26■ このスレッドは過去ログ倉庫に格納されています