08/07/03 20:08:09
>>944
しまった、誤爆です。でもここでもいいか。
946:デフォルトの名無しさん
08/07/03 20:08:10
Python上であればPythonから簡単に呼べるという幻想でしょ。
たぶん性能が悪くて使い物にならないと思うけど。
どうせやるなら Java VM か .NET CLR 上が面白いだろうね。
947:デフォルトの名無しさん
08/07/03 20:19:03
>>943
C/C++ではGUIの仕様の統一が図れないしi386やLinux／Winのみをターゲットにしている事も多い。
JAVAは純正はポータブルじゃないしクローンは（よくなったとはいえ）まだ不完全。
PythonやOCamlは派生処理系はあるもののメインに概ね統一されてるしポータビリティもいいしGUIもある。
という理由です。
FiclやLuaみたいにANSI-Cが必要十分条件なCL or Schemeがあればそれが一番いいんですが。
（といってもGUIの問題が残るけど）
948:デフォルトの名無しさん
08/07/03 20:25:10
要はgccとPOSIXとXがある環境ではどこでも動いてよ！ってことです。
949:デフォルトの名無しさん
08/07/03 20:25:51
gcl がそれに近いかなあ
950:デフォルトの名無しさん
08/07/03 20:32:05
GCLはソースが古すぎてビルドできませんでした（古い関数が使われている？）
その末裔のECLはBoehmGCをportしたらビルドできましたけど
951:デフォルトの名無しさん
08/07/03 20:35:57
どっちにしても Python 上に作ってもまともな性能なんて出ないよ
952:デフォルトの名無しさん
08/07/03 20:39:54
Python上に作るっていうか
JavaVMにおけるKAWAとかSISCみたく
PythonVM上で直接実行されるようにすれば
CLispくらいにはなりませんかね？
953:デフォルトの名無しさん
08/07/03 20:54:24
>>947
ocamlやpython,rubyのGUIって標準はtcl/tkちゃうん？
clはltkが一応あるよ。
954:デフォルトの名無しさん
08/07/03 22:03:04
>>947
PythonやLuaの実装言語はCなんだから、
CでGUIを統一できないとか移植性がないとか言うのはおかしいでしょ
955:デフォルトの名無しさん
08/07/03 22:42:58
PythonやLuaやRubyは言語≒実装なので事実上の標準という縛りがあるから
その上で動くもののポータビリティが保たれることを利用して
SchemeやCLよりも低レベルでポータビリティを実現して欲しいんです。
いろいろな処理系を移植するのは骨が折れるので。
LuaにGUIがあるのかどうかは知りませんが
必要十分条件が明白な言語の代表として名前をあげました。
POSIXでXlibとgccがあればフル機能は無理でも標準機能はビルドできる、くらいの条件があって欲しいです。
956:デフォルトの名無しさん
08/07/03 22:47:32
欲しいものはよく判った。でも今のところ無いと思う。
性能が出なくて労力の割に面白くないから、誰も作らないんじゃないかと想像できる。
だが、やってみなくちゃ判らないぞ。>>955の偉業に期待だ。
957:デフォルトの名無しさん
08/07/03 23:06:28
>>955
ansiなscheme or CLにTcl/Tkをポートする方が楽そう。
958:デフォルトの名無しさん
08/07/03 23:30:13
GUI込みならPythonアプリはそれほどポータブルではない。
959:デフォルトの名無しさん
08/07/04 00:08:49
>>955
LuaにGUIはないが、君の言う通り「Luaよりも低レベルで」ポータビリティを実現できる
Cで書ける部分を無理にLuaで書くことはない
960:デフォルトの名無しさん
08/07/04 00:30:30
>>955
Python上で実装してポータビリティを上げるって
衝撃の馬鹿理由だな。
961:デフォルトの名無しさん
08/07/04 00:49:27
ポータビリティとライブラリを重視するのは良いと思う
性能重視は競争が激しいし供給過剰だし
962:デフォルトの名無しさん
08/07/04 01:03:14
もうすぐ次スレだな
963:デフォルトの名無しさん
08/07/04 01:15:09
ypsilon vs gauche
964:デフォルトの名無しさん
08/07/04 04:50:03
pythonはポータブルじゃないよ
日本じゃ人気がないから
965:デフォルトの名無しさん
08/07/04 07:10:54
おれは最近、仕事でpythonばっかり書いてるよ。
時々lispとの微妙な違いに悲しくなるけど、確かにlisperとしても許容できる、
良い言語だわ。ほぼどこでも動くし、ライブラリも沢山。
そのうち趣味でもpythonばかりになるかも。
966:デフォルトの名無しさん
08/07/04 08:39:27
ANSI-Cが必要十分条件だとGC書けねーよ
967:デフォルトの名無しさん
08/07/04 09:28:25
>>933-935
matlabに慣れてるからpython.numpyが使いやすい
しかしちょっと高度なこともしてみたい
全部lispでやったほうがいいのだろうか
968:デフォルトの名無しさん
08/07/04 09:28:57
>>938-939
pyffi
969:デフォルトの名無しさん
08/07/04 09:57:24
>>967
あまり融合度が高くないが、
URLﾘﾝｸ(clisp.cons.org)
matlabじゃないが、
URLﾘﾝｸ(nlisp.info)
970:デフォルトの名無しさん
08/07/04 13:08:28
ピンボールの話題がまだ出ていない件
971:デフォルトの名無しさん
08/07/04 13:09:16
ごめん。>>963見落とした
972:デフォルトの名無しさん
08/07/04 14:30:26
「事実上の標準」はTck/TkでもXlibでもなくGLUTというオチ
973:デフォルトの名無しさん
08/07/04 16:42:13
>>970
ピンボールよりメタボールの方が面白そうだなあ
974:デフォルトの名無しさん
08/07/04 22:21:52
evalでschemeが評価できるpythonとか逆にschemeでpythonが評価できるとか
975:デフォルトの名無しさん
08/07/04 22:32:26
データの互換性があると使いやすいのだろうが、LispのconsセルとPythonのtupleには
微妙な違いがあったり、symbolに相当するものが無かったり、PythonってLispのようで
Lispでないって感じだよね。
976:デフォルトの名無しさん
08/07/06 17:33:24
うわさのypsilonをコンパイルしようとしたらエラーで止まっちゃったわ。
x86_64に対応してないって書いてたわ。残念。
977:デフォルトの名無しさん
08/07/07 21:52:16
Scheme on Java > SISC
継続不完全でもJavaとのリンク強ならKawa
978:デフォルトの名無しさん
08/07/08 18:34:57
まず考えるべきことは、なぜC/C++とのリンクが弱い (と思われている) かだ
979:デフォルトの名無しさん
08/07/10 12:45:38
>>976
32bitでコンパイルすればいいじゃん。