トップページ⇒tech
1001コメント342KB

「コンパイラ・スクリプトエンジン」相談室7

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2005/10/14(金) 19:56:30
プログラミング言語処理系の開発に興味のある人達のスレッドです。

字句解析・構文解析から，データフロー解析，ループ並列化，データ分散，SSA変換，
CPS変換，レジスタ割付，命令スケジューリング，ソフトウェアパイプライン，
SIMD命令生成，VLIW向けクラスタリング，スクラッチメモリ向け最適化，リンク時最適化，
JIT，動的バイナリ変換等の各種最適化，それにVM，GC，低消費電力化などなど。
意味論に関する話題も歓迎です。

前スレ
1 http://pc.2ch.net/tech/kako/981/981672957.html
2 http://pc2.2ch.net/test/read.cgi/tech/1021136715/
3 http://pc5.2ch.net/test/read.cgi/tech/1070089173/
4 http://pc5.2ch.net/test/read.cgi/tech/1100097050/
5 http://pc8.2ch.net/test/read.cgi/tech/1106129164/
6 http://pc8.2ch.net/test/read.cgi/tech/1115335709/ (前スレ)
関連リンクは多分 >>2-10 あたり
0002デフォルトの名無しさん2005/10/14(金) 19:56:56
★コンパイラ一般

・色々なツールの紹介
　http://catalog.compilertools.net/
・コンパイラ関連のリンク集
　http://www.ulis.ac.jp/~nakai/rel_web_compilers.shtml
・スクリプティング言語資料室(仮) (リンク集)
　http://www.kt.rim.or.jp/~kbk/
・Compiler Construction
　http://rananim.ie.u-ryukyu.ac.jp/~kono/lecture/2000/compiler/index.html
・Compiler Construction　(1997)
　http://rananim.ie.u-ryukyu.ac.jp/~kono/lecture/1997/compiler/compiler.html
・情報システム工学実験 III コンパイラ・コンパイラ
　http://math.cs.kitami-it.ac.jp/~fuchino/proin/experimentIII-2000/jikken.html
・OS/Programming 簡単な C コンパイラ
　http://www.csg.is.titech.ac.jp/~chiba/lecture/os/
・正規表現
　http://hp.vector.co.jp/authors/VA007799/viviProg/doc_regexp.htm
・コンパイラ研究・開発情報の一集積所
　http://compilers.cs.uec.ac.jp/
・Links and Selected Readings
　http://www.gnu.org/software/gcc/readings.html
・国産のコンパイラ共通インフラストラクチャCOINS
　http://www.coins-project.org/
0003デフォルトの名無しさん2005/10/14(金) 19:57:12
★字句・構文解析

・Lex and YACC primer/HOWTO （邦訳）
　http://www.linux.or.jp/JF/JFdocs/Lex-YACC-HOWTO.html
・Turbo Pascal Lex/Yacc
　http://www.musikwissenschaft.uni-mainz.de/~ag/tply/tply.html
・Jim Roskind's LALR(1) C++ Grammar
　http://www.empathy.com/pccts/roskind.html
・Flexと Bisonを同時に使う
　http://guppy.eng.kagawa-u.ac.jp/~kagawa/1999/SysProg/both.html
・KITE_ASM (yacc,lex)
　http://www.arch.cs.kumamoto-u.ac.jp/project/kite/kiteasm/
・bison用のC++ LALR skeleton
　http://www.bj-ig.de/software/bison/
・ANTLR（非yaccのパーサジェネレータ）
　http://www.antlr.org/
・JavaCC(Java Compiler Compiler)
　https://javacc.dev.java.net/
　http://village.infoweb.ne.jp/~fwif0083/program/java/javacc/javaccgrm.html
　http://www.asahi-net.or.jp/~DP8T-ASM/java/tips/JavaCCHelloWorld.html
・CUP, JLex, JFlex
　http://www.cs.princeton.edu/~appel/modern/java/ (JLex, CUP)
　http://www.jflex.de/
・SableCC
　http://www.sablecc.org/
・¬＜＞＜∪∪ （notavacc）LALR(1)
　http://ne.cs.uec.ac.jp/~koto/notavacc/
・boost::spirit（C++のテンプレートでEBNFの構文を模倣）
　http://spirit.sourceforge.net/
　http://boost.cppll.jp/HEAD/libs/spirit/index.html（マニュアル日本語化プロジェクト）
　http://www.fides.dti.ne.jp/~oka-t/cpplab-boost-spirit.html
0004デフォルトの名無しさん2005/10/14(金) 19:57:31
★ごみ集め

・GC FAQ -- draft
　http://www.iecc.com/gclist/GC-faq.html
・A garbage collector for C and C++
　http://www.hpl.hp.com/personal/Hans_Boehm/gc/
・一般教養としての Garbage Collection
　http://www.is.s.u-tokyo.ac.jp/~vu/01/jugyo/processor/process/soft/compilerresume/gc/gc.html
・Garbage Collection : Algorithms for Automatic Dynamic Memory Management
　http://www.amazon.com/exec/obidos/ASIN/0471941484/

★処理系,スクリプト

・kikyou.info (吉里吉里というゲームのスクリプト)
　http://kikyou.info/
・tiny C コンパイラ (C)
　http://www.watalab.cs.uec.ac.jp/tinyCabs.html
・6809用 Micro C コンパイラ
　http://www.axe-inc.co.jp/pds/mc09.html
・Portable Object Compiler (Obj-C >> C のトランスレータ？)
　http://users.pandora.be/stes/compiler.html
・自作コンパイラの部屋(PL/1, Pascal等)
　http://www.tokumaru.org/
・『Rubyソースコード完全解説』サポートページ
　http://i.loveruby.net/ja/rhg/
・『やさしい Lisp の作り方』『やさしい Java インタプリタ の作り方』
　http://www.okisoft.co.jp/esc/go.html
・MSによるPEフォーマット仕様書(日本語)
　http://www.interq.or.jp/chubu/r6/reasm/PE_FORMAT/intro.html
0005デフォルトの名無しさん2005/10/14(金) 19:57:47
★参考書籍

・コンパイラ　原理・技法・ツール　１＆２
　http://www.amazon.co.jp/exec/obidos/ASIN/4781905854/
　http://www.amazon.co.jp/exec/obidos/ASIN/4781905862/
　通称ドラゴンブック。バイブル。
・コンパイラ構成法　原田 賢一
　http://www.amazon.co.jp/exec/obidos/ASIN/4320029224/
　http://www.hara.cs.keio.ac.jp/kCompiler/　(ソース、正誤表のダウンロード)
・プログラミング言語処理系 岩波講座 ソフトウェア科学〈5〉 佐々 政孝
　http://www.amazon.co.jp/exec/obidos/ASIN/4000103458/
　一冊で済ませたい人へ。
・コンパイラの構成と最適化 中田 育男
　http://www.amazon.co.jp/exec/obidos/ASIN/4254121393/
　最適化がメインだが、構文解析からコード生成までの基本事項も解説されている。
・コンパイラの仕組み　渡邊　坦
　http://www.amazon.co.jp/exec/obidos/ASIN/4254127081/
　薄い奴(185p)を読みたい人に。
・21st Century Compilers (Alfred V. Aho, Sethi, Ravi Sethi, Jeffrey D. Ullman, Monica Lam)
　http://www.amazon.co.jp/exec/obidos/ASIN/0321131436/
　まだ出ていない。
・スモールコンパイラの制作で学ぶプログラムのしくみ
　http://www.cbook24.com/bm_detail.asp?sku=4774121770
　初心者向けの優しい解説本。
0006デフォルトの名無しさん2005/10/14(金) 19:58:01
★学会

・PLDI
　http://research.microsoft.com/conferences/pldi06/
　コンパイラの研究に関する最新成果を知りたければまずはここ。
・POPL
　http://www.cs.princeton.edu/~dpw/popl/06/
　PLDIよりは理論寄りだが大いに参考になる。
・ICFP
　http://icfp06.cs.uchicago.edu/
　関数型言語に関する学会。とても難しい。
・OOPSLA
　http://www.oopsla.org/
　オブジェクト指向言語に関する学会。最近はやや低調？
・ICCC
　http://www.st.cs.uni-sb.de/cc/
　ヨーロッパ系。派手さはないが堅実。
0007デフォルトの名無しさん2005/10/14(金) 19:58:30
ということで、新スレです。
0008デフォルトの名無しさん2005/10/14(金) 20:01:46
>>7
乙。中田先生の本のテンプレ、ナイスでつ。

0009デフォルトの名無しさん2005/10/14(金) 20:11:51
せっかくなのでネタ振りなど。
ループ並列化とかベクトル化する前には配列の添字解析をやると思いますが、
みなさんはどういう方法を使ってますか？

私はとりあえず普通のomega testでやってますが、解析→最適化→再解析→…
と、最適化の度に解析すると結構重いです。再解析のコストを下げられるような
方法はないですかねえ。
0010デフォルトの名無しさん2005/10/14(金) 20:19:29
枝刈りすりゃいいんじゃない？
0011デフォルトの名無しさん2005/10/14(金) 20:23:27
記憶が定かでないが、オメガテストって枝刈りするような方法ではなかったような…
0012デフォルトの名無しさん2005/10/14(金) 21:27:03
中田先生の「コンパイラ構成法」で一通り勉強し、VSMと簡単な言語の設計はそれなりに理解できたのですが、
効率的なレジスタ割付といった実際のコード生成や最適化技法など、少々物足りなく感じる箇所がありました。
そこで、次にドラゴンブックか「コンパイラの構成と最適化」に手をつけてみようと思っているのですが、どちらがオススメでしょうか？
ドラゴンブックの場合、1&2を両方揃えないと体系的な解説は得られないのでしょうか。

教えてエロい人(´･ω･`)
0013デフォルトの名無しさん2005/10/14(金) 21:54:43
全部買えよ
0014デフォルトの名無しさん2005/10/14(金) 22:07:21
そういう用途なら「コンパイラの構成と最適化」が良いと思う。
これの後半は代表的な最適化手法の論文紹介になってるから。
0015デフォルトの名無しさん2005/10/14(金) 22:09:31
>>9
その手の問題はどうしようもない気がするなあ。
気象庁向けとかなら、コンパイル時間は1時間くらいなら我慢してくれるはず。
0016デフォルトの名無しさん2005/10/14(金) 22:16:28
>>13-14
ありがとうございます。
流石に両方買うとなると安月給の私には結構な出費なので、
>>14氏に従ってコンパイラの構成と最適化を買ってみたいと思います。

# この手の本は書店で内容を吟味できないのが辛いですね・・・
0017デフォルトの名無しさん2005/10/15(土) 00:54:44
>>16
JUNKDOなら朝行って夕方まで読み込んでから買えるよ。
0018デフォルトの名無しさん2005/10/15(土) 04:57:55
中田先生の本にはオメガテストも載ってたね。
旧日立の人だけあって、あの辺には強い。
0019デフォルトの名無しさん2005/10/15(土) 12:51:23
初歩的な質問で申し訳ないんですが、Cで書く場合、識別子などを記録するためのハッシュはどのように実装するのが賢いですか？
自前でハッシュ関数やハッシュ表の生成などを書くべきか、それとも良いライブラリ等がありますでしょうか？
また、ハッシュ関数を書く場合はどんなアルゴリズムが適していますか？
namespaceのような階層化されたものを実装したいので、それに適した方法を教えていただけるとありがたいです。
0020デフォルトの名無しさん2005/10/15(土) 22:18:28
大物待望論が出てるけどw
ちょっと現実的な質問になると、スルー決め込みw
0021デフォルトの名無しさん2005/10/15(土) 22:33:52
>>192
階層化させるならハッシュよりも
パトリシアかトライの方が向いてる
0022デフォルトの名無しさん2005/10/16(日) 00:11:47
名前空間の階層化とtrieがどう関係するのでしょうか？
0023192005/10/16(日) 01:31:33
>>21
なるほど。trieを使うわけですか。
ありがとうございます。

それでtrieを使う場合、trieを名前空間の各階層にそれぞれ別個に作るということでしょうか？
その場合、名前で検索するときに階層をたどることになるので、各階層で名前の長さに依存した検索になってしまいます。
そうすると検索にかかるコストが「階層の深さ×名前の長さ」ということになってしまう問題があります。

これは何かうまい方法をつかって克服できる問題でしょうか？
もしくは、ユーザが作る階層なんて大して深くならないと仮定してＯＫにしてしまうべきでしょうか？
欲を言えば「名前の長さ＋階層の深さ」で検索できてほしいところです。
0024デフォルトの名無しさん2005/10/16(日) 16:47:17
>>23
トライだと、名前の途中のノードを持ってこれるでしょ。
検索はその途中のノードから行えば良い。
平衡木みたいな再構築をしない前提ならば、
ノードアドレス（またはインデックス）が、
そのままユニークな完全ハッシュ値として使える。
0025デフォルトの名無しさん2005/10/16(日) 16:59:05
例えば
namespace1.namespace2.namespace3.foo
という名前空間込みの変数を格納する場合、
名前空間ごとにノードを保持しておく。上の場合なら
namespace1 | namespace2 | namespace3 | foo
と言う風に区切り、それぞれの中間ノードを保持する
trieのチェイン構造を大まかに表現すると下のようになる
#<ns 001(ns1)> -　#<ns 002(ns2)> -　#<003(ns3)> - #<004(foo)>

後は、trieで検索したとき、例えば#<ns-node 003>にたどり着けば
namespace1.namespace2.namespace3を参照していることがわかる。

不完全ハッシュと違って文字列走査が必ず1度で済むので
階層構造を表現する場合はトライ木ベースの構造が適している。
0026デフォルトの名無しさん2005/10/16(日) 17:05:14
>>23
あ、もちろんトライ木の構築は１つで済む。
１から作るなら途中ノードを抜き出したとき、
そこにデータを格納できるような実装にすればいい。
C言語のように翻訳単位などでリンケージが変わる場合は、
木を別に用意するか、単に初期化する。
0027デフォルトの名無しさん2005/10/16(日) 17:17:23
ぐだぐだになってるので>>25を一部書き直す。

trieのチェイン構造を大まかに表現すると下のようになる
#<001(ns1)> -　#<002(ns2)> -　#<003(ns3)> - #<004(foo)>
この番号はノードのアドレス（またはインデックス）

後は、trieで検索したとき、例えば#<003>にたどり着けば、同時に
namespace1.namespace2.namespace3を参照していることがわかる。

また、検索結果が#<004>ならば
namespace1.namespace2.namespace3.fooを参照していることになる。
検索に失敗（ノードが見付からない）すれば未定義とわかる。


それと、トライ木の表現方法自体に色々手法があるので
最適だと思えるものを自分で選択する必要がある。
一番最適なのは赤黒木などの平衡木だけど、挿入処理が遅かったり、
木の組み換えをする影響でノード値を完全ハッシュ値として使えない
などの問題が出てくる。
この辺は複雑さ、バランスのトレードオフで選択するしかない。
0028232005/10/17(月) 03:24:04
>>24-27
ご丁寧にありがたいです。
ただ、まだまだ自分の理解不足・知識不足で検索の仕方が把握しきれないです。
trieの検索というと以下のイメージだったのですが
node -(f)-> node -(o)-> node -(o)-> node　（search_node(trie, "foo")で検索）
そうではなく、
node -#addr-> node -#addr-> node -#addr-> node
ということでしょうか？
そうすると各ノードの構造体は例えば、
typedef struct _node node;
struct _node {
  node * subnodes[???];
  id * ptr; /* 各識別子へのポインタ */
};
という感じでしょうか？
もしこれだと???にアドレスのとりうる最大値を入れることとなり、すさまじいメモリの食い方をしてしまいますね・・・。
さすがにこんなのではないと思うのですが、よかったら検索の行われ方やノードの構造あたりを教えてもらえませんか？
すみません、かなり勘違いしてしまっていると思うので、よろしくお願いします。
0029232005/10/17(月) 03:52:25
あと万一誤解を与えてしまっていると申し訳ないので、一応確認しておくと、
（C++風に書くと）
namespace ns1 {
  int foo;
  namespace ns2 {
    namespace ns3 {
      int foo;
      foo; // これは素直にns1::ns2::ns3::foo
    }
    foo; // ns2にfooはないので、これはns1::foo
    ns3::foo; // これはns1::ns2::ns3::foo
  }
}
というように、「指定階層から上方向にたどり、いちばん初めに見つかったもの」を検索結果としたいのです。
0030デフォルトの名無しさん2005/10/17(月) 11:46:56
>>29
namespace毎に、
ハッシュ表と、親のnamespaceへのポインタ
を持っとけばいいんじゃない？

ns1::ns2::ns3::foo のときは、まず ns3 のハッシュ表を foo で検索してヒットするのでそれ。
ns1::foo の方は、最初に ns2 のハッシュ表を検索しても見つからないので、親のns1のハッシュ表を検索。
ns3::foo は、ns2 のハッシュ表に ns3 は名前空間でそれのハッシュ表はどれという情報が入っていて、ns3のハッシュ表を foo で検索して発見。
003119=23=28=292005/10/17(月) 12:59:24
>>30
元々はまさにおっしゃる通りの方法で、namespaceごとにハッシュ表に識別子を登録する形でやるつもりでいました。
それで最初の質問が>>19だったんです。
そこでtrieを使う方法が適しているという意見をいただいたので、それについて質問しているところでした。

ところでハッシュを使う場合ですと、ハッシュ関数はどういうアルゴリズムを使うのが良いでしょうか？
（この質問は>>19でもした質問でした）
また、ハッシュ関数そのものも去ることながら、namespaceごとにハッシュ表をつくるとかなりメモリを食うことになると思うのですが、どのように対処すべきでしょうか？
0032192005/10/17(月) 18:28:24
よく見たらsageて質問してましたね。
すみません、ageさせてもらいます。
0033デフォルトの名無しさん2005/10/17(月) 20:17:09
sage で質問しちゃいけないというルールは微塵も無い
0034デフォルトの名無しさん2005/10/17(月) 20:43:34
>>19
オススメかどうかしらんがCのライブラリならrubyの中のst.c
/* This is a public domain general purpose hash table package written by Peter Moore @ UCB. */
なのでライセンス的な問題ないし。
0035デフォルトの名無しさん2005/10/17(月) 21:26:52
やはり、最後はいつもRuby。
後発有利？
0036デフォルトの名無しさん2005/10/17(月) 22:10:41
いやrubyはちょくせつかんけーない
rubyもどこやらから持ってきてるんだけど一時配布元がわからんかったので
0037デフォルトの名無しさん2005/10/17(月) 22:25:08
>>31
今時のマシンだったら、よっぽどアホなことしない限り、
速度もメモリ消費も問題にならない。
適当に教科書写したり、
>>34みたいなの探して使え。
0038デフォルトの名無しさん2005/10/17(月) 23:32:50
> written by Peter Moore @ UCB.
UCBはやはりバークレーなのかな。
0039デフォルトの名無しさん2005/10/18(火) 00:10:24
>>35
後発が有利なのは確か。
0040デフォルトの名無しさん2005/10/18(火) 00:12:13
先発をインスパイアするからなぁ。
0041192005/10/18(火) 02:04:11
>>34
どうもありがとうございます。参考にさせてもらいます。
導入してみて問題なければそのまま使うかもしれません。
0042デフォルトの名無しさん2005/10/18(火) 14:12:54
yaccとかraccとかでは、文法ファイルをこんな感じで書きますよね。

expr : expr '+' expr { ... }
　　　| expr '-' expr { ... }
　　　| NUM

このとき、yaccやraccは { ... } の中のプログラムコード（yaccならC、raccならRuby）をまじめに解析してるんでしょうか。
とてもそうは思えないんですけど、解析していないとしたら、どうやって終わりの '}' を検出しているんでしょうか。

プログラムコードの中で他の '}' がでてきても、yaccやraccは自分の '}' をちゃんと検出しています。
この仕組みがすごく不思議なんですけど、どうやってるのか教えてください。
0043デフォルトの名無しさん2005/10/18(火) 14:36:46
>>42
> とてもそうは思えないんですけど
why?
0044422005/10/18(火) 14:47:35
>>43
ええっ、解析しているんですか？
それって、yaccはCのパーサを丸ごと内蔵していて、raccはRubyパーサを丸ごと内蔵しているってことですよね。
とてもそうは思えないんですが。パターンマッチとかじゃないんでしょうか。
0045デフォルトの名無しさん2005/10/18(火) 14:49:02
>>42
bisonあたりのソース見てみれば？
おいらは構文解析くらいはしてると思うけどね。
0046デフォルトの名無しさん2005/10/18(火) 14:49:35
少なくともBNFの記述に使われるトークンぐらいは解析してるとｵﾓ
0047デフォルトの名無しさん2005/10/18(火) 14:54:08
直感的には、意味は解析せずとも、構文くらいは解析するだろうと思う。たいした手間じゃないし。
0048デフォルトの名無しさん2005/10/18(火) 15:05:44
自分のおつむの程度でyaccの作者のレベルを量るなよ。
それにしても極端だな、中間の{,}の数を数えているとかは候補に上がらんのだろうか。

で実際にはyaccは括弧の対応(とCのコメントと文字列)を見てる。
bisonはよく知らん。
0049422005/10/18(火) 15:17:53
>>45-47
こんなインチキ文法ファイルが通るから、Cの構文解析なんか絶対してないはず。

%token NUM
%%
exp　:　NUM　　　　 { hogehoge - {} '}' }
　　 | exp exp '+'　{ $$ = $1 + $2; }
　　 | exp exp '-'　{ $$ = $1 - $2; }
;
%%

raccも同様だった。
0050422005/10/18(火) 15:23:15
>>48
それか。どうもありがとう。
コメントと文字列と、あと文字も見なきゃいけないよね。

実はその方法も考えたんですが、raccだと正規表現やら%r{...}やらいろんなことを考慮しなきゃいけないから
それもないだろうと決め込んでました。がんばれば何とかなるのかな。
0051デフォルトの名無しさん2005/10/18(火) 15:27:56
ソースを見れば分かる話では・・・
0052デフォルトの名無しさん2005/10/18(火) 16:28:00
raccは適当に解析してるようですよ。
ttp://i.loveruby.net/ja/rhg/fin.html
でもそれなりに動いててすげえなあと思います。

私が生成系作ったときはここらへん面倒なんで
似非インデントブロックにしちまいましたよ。
'{'のあとその行末に'}'があったらそこまで、なかったら
以降の行の同じ桁にある'}'までをアクションとして扱う感じで。

こんなもんでも十分っちゃ十分でしたよ。実用上。

>がんばれば何とかなるのかな。
Rubyならripper使えばなんとかなるのかな
0053デフォルトの名無しさん2005/10/18(火) 20:24:42
LISPならその辺何もしなくて良いので楽です。
0054デフォルトの名無しさん2005/10/18(火) 21:49:12
>>58
先発

関東では、「つぎ」「このつぎ」「こんど」のどれかw
0055デフォルトの名無しさん2005/10/18(火) 22:41:34
>>58
ｶﾞﾝｶﾞﾚ
0056デフォルトの名無しさん2005/10/19(水) 11:48:21
MinGW上でBison++1.21.8＆Flex-2.5.4a使ってるんだけど
C++用に生成させた複数のパーサ＆レクサ（って言うのか）を使ってるときに
なぜかあるパーサが違うパーサ用のレクサを使ってしまうという現象に悩まされています。
同じ目にあったことある人いる？
ちなみにflexのソースには%option prefix=hogehoeを指定しています。
nmコマンドでオブジェクトを見るとちゃんと別々のレクサが生成されているようだけども…。
0057デフォルトの名無しさん2005/10/19(水) 21:50:53
>>53
Lisper
0058デフォルトの名無しさん2005/10/19(水) 22:34:15
>>57
たぶん小物w
0059デフォルトの名無しさん2005/10/20(木) 00:14:51
やっぱり最初はLISP作ることにします。
ありがとうございました。
0060デフォルトの名無しさん2005/10/20(木) 19:13:43
やっぱり最後はRuby作ることにします。
ありがとうございました。
0061デフォルトの名無しさん2005/10/21(金) 00:42:07
LLVM, SUIF, Trimaran, Zephyr, COINS ...
といろいろありますが、それぞれの向き／不向きとか使いやすさとか実際に使っている人が
いたらいろいろ情報キボンヌ。
0062562005/10/21(金) 04:51:26
>>56は悩ましい1週間のデバッグの末ようやく解決した。

両方のパーサの*_y.hがincludeされてるソースが存在した。
両方のマクロ定義とinline関数定義が干渉したらしい。
オリジナルを書いたフランス人曰く
「Linuxでは動いているからMinGWのリンカのせいではないか？」
などと言っていたが、むしろLinux上で無事動いてたのがむしろラッキー？
という感じの立派なバグだったようだ。
0063デフォルトの名無しさん2005/10/21(金) 05:16:44
>>62
ファイル名のキャピタライズのせいだったりして（実は違うファイル名:linux,実は同じMinGW）
0064デフォルトの名無しさん2005/10/21(金) 07:02:42
>>61
情報はあるが、「キボンヌ」とか言ってる奴に答える気はしない。
0065562005/10/21(金) 11:46:37
>>63
綴りも全然違うのでそれはない。

単純に.hファイルのインクルードの連鎖の結果で2組のパーサ＆レクサの定義を含む.hファイル2つが
一個のファイルにインクルードされて利用された結果、マクロ定義が衝突して、
（FlexにC++コードを生成させたときのマクロの利用方法は少々トリッキーなので）
同じであるべきinlin関数についてコンパイル単位ごとに複数の異なる版
（正しい版と別のパーサ用のレクサにすり替わった版）が生じたことによるもの。
Linux版で動いていたのは複数の異なる版を持つinline関数という
規格上未定義である状況に対するコンパイラの挙動の違いで偶然正しく動いていただけ。
0066562005/10/21(金) 12:07:49
>>63
あ、でも移植作業初期にはそういうトラブルもあったですよ。
MinGW環境からLinuxファイルサーバにsamba経由でアクセスしてるときに
同一ディレクトリ内に大文字小文字違い以外全く同一のファイル名のファイルがあって。
（ソースにそういう紛らわしい名をつけるのもどうかとは思うがｗ）


>>61
実は、今回の移植作業で現在開発中のコンパイラの壊れ物っぷりに
つくづく懲りたのでコンパイラ・フレームワークを使って
本格的に書き直す計画を立てている。

で、C++で書かれているSUIFという意見もあったが
Javaで書かれているCOINSを使おうと思っている。
Javaならクダンのフランス人が好きなGCも動的ロードも言語が標準で持ってるし、
SAXパーサもJavaの方が本家だし、
Unitテストやリファクタリングをサポートする開発環境Eclipseもあるし、
Rubyとも多分縁が切れるし、移植に悩まなくて済みそうだし、
何より今の壊れ物C++＆Rubyコードがそのまま持ち込まれる可能性が低いｗ
0067デフォルトの名無しさん2005/10/21(金) 18:24:27
>>66
是非coinsの会員になってください。
製品にcoinsを使いながら、たくさんあるバグや未実装部分を解決してくれると嬉しい。
0068デフォルトの名無しさん2005/10/21(金) 19:09:29
コインズって名前なんとかならんかな。
小銭とって細々やってるイメージしか沸かないんだがw

でも、あれだけやって gcc に敗けてるのは不思議。
gcc の優秀さが伺われる。おそるべし
0069デフォルトの名無しさん2005/10/21(金) 19:40:34
別に不思議でもなんでもない。
ストールマンをはじめ、MITのエースハッカーたちが寄ってたかって
何年もかけて作り上げたものに勝てるわけないじゃん。
0070デフォルトの名無しさん2005/10/21(金) 19:53:12
>>69
やってみなきゃわからん
0071562005/10/21(金) 20:12:12
>>67
実はすでに幽霊っぽい会員だが・・・

・・・ちょっとまって、そんなにあるの？バグと未実装（ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ）。

かなり特殊なバックエンドのためのフロントエンド＋汎用っぽい最適化部
として考えてるからあんまり普通のコンパイラの機能が未実装多いと困るなぁ。
COINSのためにまだ1行も書いてない今ならまだ間に合うか・・・SUIFにするか？！
0072デフォルトの名無しさん2005/10/21(金) 20:48:38
学校の演習で使ったが、未実装たくさんあったぞ。
cfrontですら未実装で四苦八苦してる始末。
あと、最適化なんて目も当てられない。
0073デフォルトの名無しさん2005/10/21(金) 21:16:13
>>72
うーむ。

・時期はいつごろのこと？
（一応今年の3月までがそのプロジェクト本来の研究期間だったような…。）
・演習用にわざと虫食いにしてあったという可能性は？
（完成してたら演習にならないから。）
0074デフォルトの名無しさん2005/10/21(金) 21:17:17
>>72
最適化ならテンプレに良書があった筈
紹介してあげたら？

Lisperより
0075デフォルトの名無しさん2005/10/21(金) 21:23:36
>>73
迷わず行けよ。行けばわかるさ。

いや、ここはひとつ日本のcompiler業界のために頑張ってはくれまいか。
0076デフォルトの名無しさん2005/10/21(金) 21:25:45
>>74
テンプレにのっている日本語の教科書の著者の半数がCOINSに関わっているんだが？
0077デフォルトの名無しさん2005/10/21(金) 21:38:06
俺もCOINSを薦める。COINSは研究として面白みのある部分以外はまだまだ手薄なので、
泥臭い部分を仕上げる企業人が必要だと思う。
0078デフォルトの名無しさん2005/10/21(金) 21:39:38
>>75
実績作らないとイカンので、今のプロジェクトから逸脱しない範囲で
論文のネタが拾えるなら行ってもいいんだけどな・・・。
ただの実装では論文のネタにならんからなー。
0079デフォルトの名無しさん2005/10/21(金) 21:40:01
>>73
・時期は今年の4月以降。
・後者の可能性はない。

まあダウンロードしてファイル読めばだいたいわかるし、テストコード書いて
吐かれたアセンブラ見ればわかる。
0080デフォルトの名無しさん2005/10/21(金) 22:03:34
>>77
ところが企業じゃなくて一応は公費が使われてる研究所なんだよなー。
その上プロジェクトのテーマはコンパイラの技術は必要としているが、
コンパイラそのものではない。

>>79
うひゃぁ。まいったなぁ。

もっともコード生成部こそはウチのプロジェクトでまさに作りたいところなんで、
問題がそこらあたりならばまぁいいんだけどね。
ただ、そのコード生成部はあまり一般CPU向けではなかろうなぁ。
それに初手ではトランスレータとして実現するつもりだし。
0081デフォルトの名無しさん2005/10/21(金) 22:24:39
>>80
キーワードは次のうちどれ?

1. reconfigurable
2. energy consumption
3. multi-core
4. cell
5. DSP
6. hetero cache
0082デフォルトの名無しさん2005/10/21(金) 22:50:09
>>81
のーこめんとでｗ
0083デフォルトの名無しさん2005/10/21(金) 22:55:24
>>80
どんなコンパイラ作るのか知らないけど、cfrontについては/test/c/report.txt見れば
未実装部分はだいたいわかると思う。
なんか、cfrontを作るために、汎用的なHIRじゃなくて、HIR-Cをわざわざ作ってたり、
fortranもどうも特殊なことしないと作れないっぽいし、駄目駄目な印象しかないんだがなあ。

まあ最適化のところを置き換えるみたいだし、研究の内容によっては使えるかもしれない。

0084デフォルトの名無しさん2005/10/21(金) 23:07:01
>>81
本命1、対抗2ってとこかな．
3や５は企業しかやらないんじゃない？
0085デフォルトの名無しさん2005/10/22(土) 00:59:55
構文解析器ってどうしても再帰的な処理になるから
どこでエラーが出てるのか、デバックが難しいんですけど
みなさんどうしてます？
0086デフォルトの名無しさん2005/10/22(土) 01:02:16
字句解析の時点でトークンにファイル名と行番号を持たせる
0087デフォルトの名無しさん2005/10/22(土) 01:58:50
流れを無視して悪いが>>70がいいこと言った
0088デフォルトの名無しさん2005/10/22(土) 03:52:36
>>70
というか思考実験もせずに文句言う奴最近おおいと思う。
0089デフォルトの名無しさん2005/10/22(土) 10:57:01
>>85
デバッガを使う。
0090デフォルトの名無しさん2005/10/22(土) 11:31:26
>>85
何らかの形でログ出力。
0091852005/10/22(土) 14:31:21
>>89
デバッガ使うような言語じゃないのです。。。

>>90
やっぱりそれですかね。
0092デフォルトの名無しさん2005/10/22(土) 14:51:37
ふつー86
0093デフォルトの名無しさん2005/10/22(土) 15:49:44
>>85は構文解析器のデバッグをしたいのか、それで作った言語のデバッグを
したいのか、どっちだ?
0094デフォルトの名無しさん2005/10/22(土) 16:14:28
何々?手書きしてるの?
yaccとかなら.outputみれば簡単よ
0095デフォルトの名無しさん2005/10/22(土) 20:33:57
>>86
行番号まで持たせるって、一般的ですか？
0096デフォルトの名無しさん2005/10/22(土) 22:32:00
86じゃないけど一般的。
エラー出力のポリシーによるだろうけど最低限リテラルや変数名には
持っておかないと正確なエラー情報が出せない。
0097デフォルトの名無しさん2005/10/22(土) 22:50:34
>>96
勉強になりました。ありがとうございます。
0098852005/10/23(日) 00:29:34
＞構文解析器のデバッグをしたいのか、それで作った言語のデバッグを
＞したいのか、どっちだ?

構文解析器のデバッグですね。
ちなみに字句解析の際にトークンに行番号持たせてます。

0099デフォルトの名無しさん2005/10/23(日) 08:22:03
セミコロン区切り式の言語で、「文にセミコロンがありません」みたいなエラーってどうしたら出せますか？
Bisonの構文解析で「そこにセミコロンさえあれば正しい文法だったのに・・・」みたいなことは検出できるのですか？
多くのコンパイラ・インタプリタはその辺妥協してシンタックスエラーとか、予期しない〜ですとか言うだけなようですが、何とかして親切なエラー出力がしたいのです。
0100デフォルトの名無しさん2005/10/23(日) 09:37:58
Syntax ERROR: 予期しない〜が出現しました。(もしかしてセミコロンがなかったり……)
0101992005/10/23(日) 15:37:55
>>100
レスどうもありがとう。
ナイスなアイデアだけど、どのシンタックスエラーだとセミコロン忘れな「可能性がある」のかすら判別できないヘタレな漏れです。
全ての構文エラーにセミコロンがなんちゃらって入れるのちょっとしつこいし・・・。
むつかすぃ
0102デフォルトの名無しさん2005/10/23(日) 15:52:15
>>99
コンパイラがプログラマの意図を察しないと行けないから
完璧には無理だろうね。

例えば、(あまりよくない例だが…)
x = y * z = 1;
に対して「y の後に ; がありません」というエラーは果して適切か？

小さな親切大きなお世話になる気がするよ。
0103デフォルトの名無しさん2005/10/23(日) 16:40:55
>>102
うーん、「意図」とは関係なく、機械的には無理そうですかね？
x = y * z = 1;
の場合だと、（Cのようなポインタの記法があったと仮定すると）確かにyの後ろにセミコロンがあっても文法的に通り得ます。
しかし、パーサ的にはその時点で構文自体がエラーではないので、解釈し続けることが出来るのではないでしょうか。
問題は実際にエラーを検出したときに、それがセミコロンによるものなのかどうかを調べる手段があるかどうか、という感じだと思います。
つまり、セミコロンが無くてもたまたま文法が通ってしまうようなところでセミコロンを忘れた運の悪いユーザには、残念ながらエラーは出せないです。
（そのシチュエーションがありうるかどうかまではちょっとわからないですが・・・）

実際BCCなんかは、そのものズバリ「ステートメントにセミコロン（;）がない」と言ってくれます。
（gccは欠けたセミコロンの直後のトークンで、symtax error before 〜 しか言ってくれません。）
とりあえず、BCCのように正しく検出してくれる実例があるので、何とかなるのではないかと考えたのですがどうでしょうか？
もしかして、かなり特殊な手法が必要？
0104デフォルトの名無しさん2005/10/23(日) 16:44:06
あ…しまった勘違い
x = y * z = 1;
って文法通らないですね…
0105デフォルトの名無しさん2005/10/23(日) 16:49:13
ちなみにBCCだと
「左辺値が必要」
という、至極真っ当なエラーを出します。
いったいどうやって実現してるんでしょう？
0106デフォルトの名無しさん2005/10/23(日) 16:55:55
煽りじゃないけど、正しいエラーを出してるんじゃなくて、
あなたが、典型的なミスを侵していて、それにそのまま当てはまっているだけだとおもう。

むしろ、gccの方が厳密で正しいと思われ。
0107デフォルトの名無しさん2005/10/23(日) 17:34:47
マイクロソフトのコンパイラもそうだけど、
適切なエラー報告してくれるコンパイラは
生成系使ってないんでない?

再帰下向きならこの手のエラー得意だし。
0108デフォルトの名無しさん2005/10/23(日) 18:51:06
ベンダーに限れば、生成系使わずに、独自に実装しているだろうね。
生成系を使いこなせていれば、あるていどのエラー処理は行えると思うけど。


例えば、文中にいきなり "キーワード if " が現れたら、セミコロンの有無を俺は疑う。
適当にやるのなら、この程度でいいんじゃないか？
0109デフォルトの名無しさん2005/10/23(日) 20:57:02
>107
論理が飛躍してないか？
0110 2005/10/23(日) 20:58:59
JavaだけどEclipse最強のエラー訂正。
C++は遥かにむずかしいだろうけど。
0111デフォルトの名無しさん2005/10/23(日) 21:20:22
>>109
>>107ではないが、全然してないと思うぞ
0112デフォルトの名無しさん2005/10/23(日) 21:22:53
>>111
そうかなぁ
少なくとも生成系云々のくだりは俺も飛躍を感じるけど。

0113992005/10/23(日) 23:33:43
>>106
「正しいエラー」というものもあるのかどうか何とも言えないけど、gccのエラーの出し方も色々見て参考にしてようと思います。
（あ、gccファンも多いと思うので一応言っておくけど、別にgcc＜bccみたいな議論をしたいわけじゃないです・・・。単にbccのような「典型的なミスへのエラー」はどうしたら出せるか、という話です。多くの場面でgcc＞bccという風に言われてるようですし）

>>107
生成系とか再帰下向きっていう言葉はちょっと初耳なんでこれから調べてみます。
飛躍しているという意見も出てますが、さっぱりついていけてないんでもうちょいがんがります。

>>108
なるほど、目星をつけてやるっていうのも手ですね。（実装作業としてはかなり大変そうですが）
ちなみに独自の実装だと出来そうということですが、普通にyacc系のパーサで実装するのは困難ということなのでしょうか？

>>110
Eclipseってそんなにエラーの出し方スゴイんですか！こちらもちょっとリサーチしてみます。
0114992005/10/23(日) 23:36:14
あれ、もしかして「生成系」ってbisonやyaccのように構文解析器を生成するたぐいって意味でしたか・・・
ちょっと113で的外れなこと言ったかも
0115デフォルトの名無しさん2005/10/24(月) 08:54:40
適切なエラーが出せるんだったら、ソース自動修正とかできそうだなw
0116デフォルトの名無しさん2005/10/24(月) 09:48:14
MS製品は自動修正あるよ
0117デフォルトの名無しさん2005/10/24(月) 14:13:07
改行された箇所でシンタックスエラーになったときに
セミコロンを補ってやると結構精度いいエラー訂正になりそうな予感。
0118デフォルトの名無しさん2005/10/24(月) 14:16:05
そしてエラー（例えば()の対応が取れてないとか）のある
長い式の途中の改行で;を挟みさらにド嵌るというシナリオはどうか？
0119デフォルトの名無しさん2005/10/24(月) 14:17:04
自動追加のできる；って単に冗長なだけと思ってしまうが。。。
なにか根本的な勘違いでもしてるんだろうか？
0120デフォルトの名無しさん2005/10/24(月) 14:26:18
元々はその冗長性がプログラムのポカミスを見つけてくれるってことじゃないかと。
0121デフォルトの名無しさん2005/10/24(月) 14:42:19
実際には自動追加なんてできないんだから、冗長さもポカミスを防ぐもないだろう。



ECMAScript を除いてな。
0122デフォルトの名無しさん2005/10/24(月) 15:12:24
ECMAScriptって元JavaScript？自動追加してるの？>>121
----
冗長にも見える";"があることである行の構文エラーが
他の行へ波及しにくくなる効果があるんじゃないかな？
01231212005/10/24(月) 15:41:45
>>122
ttp://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/7_Lexical_Conventions.html#section-7.9
この仕様のせいでECMAScript(JavaScript含む)の字句・構文解析は超複雑になる。
0124デフォルトの名無しさん2005/10/24(月) 16:22:28
>>123
スゲェ、決めた奴は狂ってるとしか思えん。
0125デフォルトの名無しさん2005/10/24(月) 16:37:58
;をCRCか何かと勘違いしてる奴がいるなw
0126デフォルトの名無しさん2005/10/24(月) 16:43:43
>>125
はて。そんなやついたか？
0127デフォルトの名無しさん2005/10/24(月) 16:44:12
>>123
なんと、そんな裏があったのか。
以前構文解析器書いてるとき

stmt_list: /* empty */ | stmt_list stmt
stmt: ';' | expr ';' | '{' stmt_list '}' | IF '(' expr ')' stmt | 〜 etc.
expr: ID | '(' expr ')' | expr '+' expr | 〜 etc.

って感じでやるときに、ちょっと遊び心で

stmt_list: /* empty */ | stmt_list stmt | stmt_list expr /* stmt_list expr を追加 */
stmt: ';' | '{' stmt_list '}' | IF '(' expr ')' stmt | 〜 etc. /* expr ';' を除去 */
expr: ID | '(' expr ')' | expr '+' expr | 〜 etc.

にしてみたら、JavaScript風にソース中のセミコロン省略しても割と正しく解釈されたから、これくらいに単純なのかと思っていた。
（あまり厳密には確認しなかったけど、conflictの兼ね合いで式(expr)ができるだけ長くなるような位置で文(stmt)の区切りと見なしてくれたと思う）
0128デフォルトの名無しさん2005/10/24(月) 17:18:37
>>126

>>120
0129デフォルトの名無しさん2005/10/24(月) 18:07:26
>>125
分からないなら黙っておいた方がいいよ？ｗ
0130デフォルトの名無しさん2005/10/24(月) 21:23:42
情報理論的にはあってるけどなw
0131デフォルトの名無しさん2005/10/25(火) 10:15:11
>>125
";"を忘れたってエラーじゃなくて
";"はあるけどその行の中で何か構文エラーがある場合を考えてみれ。
例えば正しい式には";"が現れないと仮定できれば
"("と")"の対応が正しくないとかの場合でも後続の文の中に際限なく終わりの括弧を探さずとも
その文一つが間違っているだけだと結論できるだろう。
つまりエラーを局所化できるわけでエラーを見つける目的には役立っている。
0132デフォルトの名無しさん2005/10/25(火) 20:02:33
いいたいことはわかるんだけど、それって;のおかげというより
構成単位を文で区切る手続き型言語の特性じゃないかな。
関数型言語ではしばしば"エラーを局所化"できず
不幸になることがある。

もし;がなかったらどんなプログラムで
"エラーを局所化"できず不幸になるか
具体例をあげてほしい。
0133デフォルトの名無しさん2005/10/25(火) 21:47:47
別に;でなくても'\n'でも同じじゃないの？
0134デフォルトの名無しさん2005/10/25(火) 23:23:32
>>133
確かにw
01351312005/10/26(水) 12:15:05
>>133
理論上は区切るものがあればよいというのはその通りで、
確かに記号は";"に限ったものでもない。";"は文の区切り記号の選択肢の一つ。
実際スクリプト言語とかは文の区切り記号に改行を使うものも多いが、
その場合長い式を書くときに一々改行をエスケープしなければならない。
（スクリプト言語の中にはシェルのように1文ごとの対話的な使用を
想定するものもあり、その場合改行が区切りというのは自然でもある。）

あと関数型でも宣言の体裁を文のスタイルにして何らかの区切り記号を使うことは可能だ。
式を中心に考えて文の意識が希薄になっているメジャーな関数型言語があることは確かだが、
文法的レベルで文を意識せず区切り記号を使わないことが関数型言語の本質というわけではない。
逆に手続き型（代入や副作用を許す）でも文なしで式だけで構成することは不可能ではない。
例えばLispで代入を使いまくるような書き方は可能だし、
Cで","演算子や三項演算子を濫用するような書き方も一応は可能だ。
（読みにくいからあえてそういう言語を実装するほどの実用性はなさそうだけれど。）
0136デフォルトの名無しさん2005/10/26(水) 13:32:47
荒れるかもしれないから言語名は避けるけど
某スクリプト言語では+とか-とかの演算子や
(や,の後の改行は勝手にエスケープしてくれるよ。

ここら辺は処理系の実装の問題だと思うけど。
01371312005/10/26(水) 13:45:18
>>136
まぁしかし本当にエラーかも知れないので勝手にエスケープもやや微妙。

プログラミング言語は今のところ所詮は曖昧さを殆ど許容できない形式言語だから
親切にするつもりで付け加えたことだとしても
言語の挙動があまり複雑になりすぎれば結局ユーザは覚え切れなくて戸惑うし、
最近は言語本体のみならず周辺ツール
（構造を意識するエディタやリファクタリングツール）も
セットで考えることが増えてきているわけだから
そういう面からもあまりに例外の多い構文・字句規則は
トータルで開発コストを押し上げる可能性を孕んでいる。
01381312005/10/26(水) 13:49:20
>>136
ついでに言えば、ソフトウェアの可搬性の問題を考えると
同じ言語で環境や実装が変わるとエラーの出方がひどく変わる、
特にエラーになったりならなかったりするというのは
絶対ダメとは言わないが決して望ましいことではないから
「実装の問題」とばかりもいえない。
0139デフォルトの名無しさん2005/10/26(水) 13:50:49
ECMAScriptみたいな、セミコロン自動補完という仕様とか
0140デフォルトの名無しさん2005/10/26(水) 13:58:26
それはザっと斜め読みしたけど
個人的な印象では";"ごときの補完処理のために
設計・開発コストを掛けすぎてる気がしないでもない。

ただまぁ計算機の能力やツール類の進歩でコストは変わるから
将来的なエラー補完のための予備的実験って意味くらいはあるのかなぁ。
0141デフォルトの名無しさん2005/10/26(水) 18:40:32
>>136
その言語すばらしい！
まさに新世代向け言語！
0142デフォルトの名無しさん2005/10/26(水) 20:05:04
ECMA-Scriptの";"補完は実装も楽だし好きだけどな
0143デフォルトの名無しさん2005/10/26(水) 20:30:02
>>142
時代遅れw
0144デフォルトの名無しさん2005/10/26(水) 22:38:58
>>136
文末のセミコロンを省略できるようにしたり、関数呼び出しの括弧を
省略できるようにしたり、そんなくだらんことでスキャナを無駄に複雑にして、
ユーザにとっても落とし穴だらけの文法にして、その見返りに、
いったいどんな「いいこと」があるんだ?

セミコロンひとつ打つのがそんなに大変かねえ。日本語の文の終わりに
「。」があるのと同じじゃん。

# 信者がうざいので俺も言語名は伏せとく。
0145デフォルトの名無しさん2005/10/26(水) 23:08:04
そこまで言ったらもう何も伏せれてねーよｗ
俺はRubyを好きでも嫌いでもないが
日本語でも「スクリプト」なら「。」はしばしば省略するぞ。
つーか明らかに価値観次第だろ。



とつっこみたいのをぐっと我慢して>>144はスルーで。
0146デフォルトの名無しさん2005/10/26(水) 23:37:03
すなわち、より進化した言語ということでしょうな。
言い換えれば、よりユーザに近いということでもある。

このことは、より高級ということでもある。
0147デフォルトの名無しさん2005/10/27(木) 01:06:16
>>144
セミコロン一つ付ける事には、慣れるのに時間がかかるんだよ。
漏れも昔は、文末にセミコロンを付けるのが苦手だったから、
その辺の気持ちは分からなくもない。
0148デフォルトの名無しさん2005/10/27(木) 01:12:56
要するに、記述を省略する事に関するメリットとデメリットを考えるべき話題やね。
メリットは、把握すべき内容が少なくなる。デメリットは、内容が曖昧になる。
0149デフォルトの名無しさん2005/10/27(木) 03:27:21
>>148
曖昧にはならんよ。
0150デフォルトの名無しさん2005/10/27(木) 03:31:14
>>149
ユーザから見て曖昧ってことじゃなくて？
01511362005/10/27(木) 03:37:24
たしかに落とし穴だらけなんだけどなれりゃあ便利なんだな。

いまだに if f x && y とかにひっかかるけどｗ
if f (x && y) になるのね、これ。and使えってことなんだろうけど。
0152デフォルトの名無しさん2005/10/27(木) 04:15:13
>>151
なに、その糞みたいな syntax。
0153デフォルトの名無しさん2005/10/27(木) 04:38:29
>>144
省略といえば、こないだ初めてPerlを使ったんだが、こりゃ酷いな。
これほどクソな文法設計の言語は過去にも未来にもないんじゃないか？
いい特徴を持っているだけに残念でならない。
ということで Perlを反面教師にしてください。
0154デフォルトの名無しさん2005/10/27(木) 04:41:02
でも、PerlってACMプログラミングコンテストだかなんだかで
有利な言語として有名なんだよ。
極めると凄いらしい。
0155デフォルトの名無しさん2005/10/27(木) 06:04:53
VZエディタのマクロみたいだな。
0156デフォルトの名無しさん2005/10/27(木) 06:39:38
ACM/ICPCはC/C++/Javaだけだぞ。
0157デフォルトの名無しさん2005/10/27(木) 07:05:11
ICFPだろ。
0158デフォルトの名無しさん2005/10/27(木) 07:38:33
ICFPで有利と有名なのはHaskellとOCamlとDylanだが、
Perlは初めて聞いた。入賞したことあったっけ。
0159デフォルトの名無しさん2005/10/27(木) 07:50:52
有名なのはHaskellとOcamlじゃないか？
Dylanはちょっと違うんじゃないか。
Perlは確か2004のLightning Divisionで圧倒的だった。
0160デフォルトの名無しさん2005/10/27(木) 08:40:25
>>152
構文糖で低血糖
0161デフォルトの名無しさん2005/10/27(木) 10:56:54
>>147
FORTRANとかの行指向の言語をやった後だと文区切りが";"一つで済むのは天国。
空文が許されてればさらに極楽(Pascalは空文がなかったので編集が面倒だった)。
最近だとC/C++でプリプロセッサマクロを書いてるときやデバッグしてるときは
結構ストレス溜まる。

スクリプト言語は大々的に開発環境・ツール使って大規模なソフトウェアを正確に書くのが
本来の趣旨ではなく、取り敢えず動くものをお手軽に普通のテキスト・エディタでやっつける
ってのが正しい使い方なんだろうから、スクリプト言語の文法規則にその手の
ユーザ補完機能っぽい小技が組み込まれるのはあるいは妥当なのかもしれんなぁ。
（私の個人的な趣味には合わんけどｗ）
0162デフォルトの名無しさん2005/10/27(木) 11:21:14
提案。
perl みたいになんでも省略可能なスクリプト言語って作れないかな。
作った自分しか使えないくらいの。

スクリプトの利点
コードが短く書ける→よってバグも少ない→(ﾟДﾟ)ｳﾏー

haskellとかでも十分短く書ける気もするが。あれは省略しているわけではないか
0163デフォルトの名無しさん2005/10/27(木) 11:53:07
スクリプトの欠点
短く書ける物しか書けない→大規模なプログラムに用いると管理しきれなくなってハターン→(;´*`)ﾏﾂﾞｰ
0164デフォルトの名無しさん2005/10/27(木) 18:33:08
>>163
その欠点をも克復したオブジェクト指向スクリプト言語があるんだけど、
あえて言語名はいわない。当スレでは禁句らしいからなw
0165デフォルトの名無しさん2005/10/27(木) 18:39:40
lispだな
0166デフォルトの名無しさん2005/10/27(木) 18:59:50
>>164
Rubyと拡張ライブラリを使って大規模なコンパイラを書かれてしまい
その移植で今酷い目に合っているのが俺だルシム
やっぱスクリプト言語はスクリプト言語。濫用はほどほどに…。
0167デフォルトの名無しさん2005/10/27(木) 20:35:13
>>166
移植って言うけど、ruby.exe が移植できればいいだけの話しでは？
0168デフォルトの名無しさん2005/10/27(木) 20:41:06
>>166
おまいを最近いろんなスレで見かける気がするのだが・・・？
0169デフォルトの名無しさん2005/10/27(木) 21:01:53
>>162
> コードが短く書ける→よってバグも少ない
その理屈はおかしいだろｗｗｗｗ
0170デフォルトの名無しさん2005/10/27(木) 21:12:07
>>169がおかしい件について
0171デフォルトの名無しさん2005/10/27(木) 21:45:01
>>169
まぁでかいコードよりは物理的に少なかろうて。
0172デフォルトの名無しさん2005/10/27(木) 22:06:42
perlみたいに、ただ枝葉末節を省略することで短くしても
バグは少なくならないんじゃないのか？
本質的に短くならないと。
0173デフォルトの名無しさん2005/10/27(木) 22:12:22
BrainFu*k 並みに短くしたら逆に分かりにくい
0174デフォルトの名無しさん2005/10/27(木) 22:13:50
BrainFu*kはちょっと込み入った処理になると正直短くないけどな…
0175デフォルトの名無しさん2005/10/27(木) 22:14:26
>>167
拡張ライブラリが曲者でね。
Rubyででかいコードを書くと実行速度の問題とか
ある処理に利用可能なライブラリやツールがないなどの理由で
だんだんと拡張ライブラリとして実現されるパートが増えていく。
最初はテキスト処理のスクリプトでチョチョイと終わるはずだったコードは3年の時を経て
Ruby本体に迫るサイズの巨大な拡張ライブラリを擁するコンパイラもどきにまで育ったというわけだ。
拡張ライブラリはC(実際のウチのケースではCから呼び出されるC++コードが大部分)で
書かれているがRubyのオブジェクトやルーチンを呼ぶのでそれ単独では実行できないから
デバッグはいつもRubyごとgdbに掛けるなどして行うことになる。そしてそれはたまらなくメドい作業。
特にC++のコードがそもそもバギーだったりパーサ・ジェネレータが関与したり
XMLパーサも関与したりConservativeGCも同居したり移植先がWindowsであったりする場合は。

>>168
気のせい。別人。無関係。ということにしておいてくださいおながいします。
決して煮詰まってるからあちこちのスレで憂さを晴らしているなどということはない筈です。
信じてください。
0176デフォルトの名無しさん2005/10/27(木) 22:22:01
>>175
そういうLispを使うべきところでRubyなんか使ったのが運の尽きだな。
0177デフォルトの名無しさん2005/10/27(木) 22:25:50
>>175
コテつけたまえよ
あぼーんしちゃるから
0178デフォルトの名無しさん2005/10/27(木) 23:34:47
>>177 ばか〜？
コテ付け必要なのは、>>176 でしょw

>>175 なんか泥沼って感じですね。
ただ、他の言語では正直そこまで持たなかったのでは？
0179デフォルトの名無しさん2005/10/27(木) 23:36:24
>> 176
単純にLispを使うべきところってのを知らないんじゃないの。
僕も仕事だから仕方なくC++でコンパイラ書くのに付き合ってるけどあまりに効率悪いんで
うんざりしてきた。スケジュールもカツカツだから絶対失敗すると確信してるけど放置してる。
0180デフォルトの名無しさん2005/10/27(木) 23:50:03
>>178
中途半端に持ってRubyで書かれたロジックとC/C++のロジックが分離しようもなく
絡み合ってしまう前に潔く書きなおされることになったほうが
幸せだった可能性が高くはあるまいか？

>>179
Lispもどうかなぁ。気が進まないなぁ。Lisp使うくらいならいまどきの言語である
MLとかHaskellとか使うかもなぁ。いずれにせよ読み書きできる人間が少ないけどな。
0181デフォルトの名無しさん2005/10/28(金) 00:03:09
C/C++に置き換わる言語は今のところLispだけ。
Rubyなんて書き始めの頃から破綻するのなんて判ってた筈。
最初からLispで書いてれば良かったね。
0182デフォルトの名無しさん2005/10/28(金) 01:10:31
ちょっと話を戻すが。

たとえば、たかがhello, world.のために #include <stdio.h>だのmainだの
書かなければならないCや、classだのpublic static void mainだの書かなければ
ならないJavaとかに比べ、1行で済むスクリプト言語は、そういう小さなプログラムでは
便利だってのは分かる。でかいプログラムだと結局関数やクラスは必要なんだけどな。

また、変数の宣言がいらないことで、書くのも手軽だし、読むときも、
ソースをぱっと見たときに本質的な部分だけが見えるので読みやすい、ってのも、
あまり同意はしないけど、言っていることは分かる。

だから、スクリプト言語が小さなプログラムには向いているってのは
わかるんだが。

しかし、セミコロンってのは... セミコロン、たかが1文字、たった1文字だぜ。
これが省略できようができまいが、タイプの手間はほとんどまったく変わらないし、
読むときに邪魔になるとも思えない。むしろセミコロンを強制する方が、
文法がシンプルになる分、処理系はもちろん人間にも優しいだろう。
関数呼び出しの括弧もしかり。

>>151が言うような落し穴を開けてまで、こんなわけのわからん文法を持ち込むことに、
いったいどんなメリットがあるのか、それがわからんのだよなあ。
0183デフォルトの名無しさん2005/10/28(金) 01:18:26
182を要約するとS式マンセー、ってことでよろしいか？
0184デフォルトの名無しさん2005/10/28(金) 01:25:02
Scheme! Scheme!!
でも、速い実装無いみたいだね、Scheme……
0185デフォルトの名無しさん2005/10/28(金) 01:26:01
>>175
煮詰まったんならもういいじゃん。
終わったことをウダウダアチコチのスレに書き込むな。

>>182
括弧要らないのは楽だし。
つうか、別に付けてもいーんだから、付けたいならつければよいって話。
俺はあきらかに省略できるところは省略して楽してる。
0186デフォルトの名無しさん2005/10/28(金) 01:28:53
どうでもいいけどさ
エラーメッセージで「；」が無いよとか言われると、
解ってんならつけて実行しろよって言いたくなるよね
0187デフォルトの名無しさん2005/10/28(金) 01:29:32
>>185
最近は「行き詰った」ときも「煮詰まった」って言うんだよ。
0188デフォルトの名無しさん2005/10/28(金) 01:30:11
>>184
PetiteじゃないChezって無茶苦茶速いって噂だけど。誰か真相知らない？
0189デフォルトの名無しさん2005/10/28(金) 01:30:14
>>182
151 のようなケースでカッコを省略して書いたりはしないよ。読みにくいし。
演算子メソッドを自然に書けるようにカッコが省略可能になっている。
a + 2 は正式に書くと a.+(2) なもんで。
最近は DSL の作成にこのルールが役に立っていると感じてる。
DSL の例は http://onestepback.org/articles/lingo/
0190終わりたいよ・・・2005/10/28(金) 01:42:13
>>185
終わってないんだよ。現在進行形でこの深夜にもぐつぐつぐつと…。
今夜もついさきほどすごいコードが書かれているのを
発見してしまってちーとばかり脱力してるところさ。

まぁ気に入らないなら頭がオカシイ電波野郎がいるとでも思ってスルーしてくれ。
あんまり簡単に個人特定されても困るので残念ながら固定は名乗れないが。
0191デフォルトの名無しさん2005/10/28(金) 02:06:33
>>188
そもそもPetiteChezの時点でインタプリタとは思えない速さだ。
0192デフォルトの名無しさん2005/10/28(金) 03:03:51
>>190
> まぁ気に入らないなら頭がオカシイ電波野郎がいるとでも思ってスルーしてくれ。
スルーしたいからコテかトリ付けろや、カス。
個人特定なんか簡単にできるかよ。
0193デフォルトの名無しさん2005/10/28(金) 03:05:15
ここは変な人が常駐してるので気になさらずに>190
0194デフォルトの名無しさん2005/10/28(金) 03:22:59
>>190=193
自演乙
0195デフォルトの名無しさん2005/10/28(金) 08:12:08
俺としちゃ190よりも、

文脈関係なくLisp, Lispと口走るキチガイや、
文脈関係なくRuby, Rubyと口走る馬鹿や、
文脈関係なくりんご、りんごと口走るキモデブに

コテなりなんなり付けて欲しいとこだけどな。
0196デフォルトの名無しさん2005/10/28(金) 08:41:27
"Lisp" "Ruby" "りんご" をｱﾎﾞｰﾝ
0197デフォルトの名無しさん2005/10/28(金) 08:58:00
>>187
低脳だけな
0198デフォルトの名無しさん2005/10/28(金) 17:57:44
言葉遣いから低能云々はともかく
「煮詰まってる（>>175）」を「煮詰まった（>>185）」と勝手に過去形にしたうえ
「もういいじゃん」と一方的な感情的評価でに突き放し、
「あちこちのスレに書き込むな」と命令形で
別にスレの話題からそれほど逸脱してるわけでもないのに
特定の話題や書き手を排除しようとする心の狭さは如何なものか？
その上アボンしたいからコテ名乗れと指示するに至っては
とんだジャイアニストと言わざるを得ない。
0199デフォルトの名無しさん2005/10/28(金) 18:00:46
まぁただの愚痴はマ板辺りでやってほしいところだな
0200デフォルトの名無しさん2005/10/28(金) 18:00:47
>>175がへりくだって見せたから図に乗ったんだろｗｗｗ
0201デフォルトの名無しさん2005/10/28(金) 18:02:15
>>199
一応流れとしては
スクリプト言語で大きなプログラムを書いてマズくなった事例なんじゃないの？
書き方は愚痴っぽかったけど。
0202デフォルトの名無しさん2005/10/28(金) 18:06:41
じゃあ後でまとめておこうか。
0203デフォルトの名無しさん2005/10/28(金) 18:39:31
>>201
それはそうだけど、もし C とか　lisp
なんかでかいていたら、とっくの昔に破綻してたんじゃない？

あまり、将来のこと考えずに拡張をくりかえしてたようだし

おっと、変な奴が出てると困るから一応行っとくけど、
Ruby は個人的にはそれほど好きではない。

ただ、凄いとはおもうけどね。
0204デフォルトの名無しさん2005/10/28(金) 18:50:28
>>203
　>>180前半。
0205デフォルトの名無しさん2005/10/28(金) 18:55:34
>>196
あと、LR(1) だっけ？w
0206デフォルトの名無しさん2005/10/28(金) 19:26:48
大規模なコンパイラを、将来のこと考えずに拡張を繰り返しても
大丈夫な言語なんてあるのか？

拡張云々は横に置いても、手続き型で静的型検査もないRubyは
大規模なコンパイラを書くのに向いてる言語ではないだろうな。
周りの人間が許すならML、だめならJavaが妥協点だろうか。
それでもだめなら泣きながらCかLisp。

おっと、変な奴が出てくると困るから一応言っとくけど、
Rubyは個人的には大好きだ。
0207デフォルトの名無しさん2005/10/28(金) 19:29:33
Lisp Ruby りんご

Cell processor向けcompilerはなかなかやりがいがありそうだね。
SPEはハードの制約がきついから、最適化の差がはっきりでそう。
0208デフォルトの名無しさん2005/10/28(金) 19:50:07
>>206
Lisp は、いくらなんでも選択にはならんだろw

おっと、変な奴が出てくると困るから一応言っとくけど、
Lispは学術的にはすばらしい言語だと思ってるよ。
0209デフォルトの名無しさん2005/10/28(金) 19:52:19
変な奴の例

つ>>206-207
02102062005/10/28(金) 20:06:21
>>208
うん、

おっと、変な奴が出てくると困るから一応言っとくけど、
Lispは学術的にすばらしい言語だと思ってるよ。

と言うのが面倒だったからお世辞で入れただけ。
それに周りの人間がMLを許さないならLispも許さないよ。S式信者除く。

おっと、変な奴が出てくると困るから一応言っとくけど、
S式は可読性にも記述性にもすぐれたすばらしいものだと思ってるよ。

# ちなみにRubyは本当に好きです
0211デフォルトの名無しさん2005/10/28(金) 20:19:24
Ruby何がそんなにいいの？
0212デフォルトの名無しさん2005/10/28(金) 20:40:06
>>211
変な奴
0213デフォルトの名無しさん2005/10/28(金) 20:43:00
つ210=212
0214デフォルトの名無しさん2005/10/28(金) 20:52:35
>>213
ちっ、ばれたか
0215デフォルトの名無しさん2005/10/28(金) 22:54:30
>>207
Lisp Ruby りんご

> Cell processor向けcompilerはなかなかやりがいがありそうだね。
> SPEはハードの制約がきついから、最適化の差がはっきりでそう。

というか、基本設計の差が大きくでるように思える。
なんせ、あのアーキテクチャですからね。
0216デフォルトの名無しさん2005/10/28(金) 23:46:41

美人言語処理担当っているのかなぁ。
はぁはぁ
0217デフォルトの名無しさん2005/10/28(金) 23:55:28
Lisp Ruby りんご

cellの大変なところは

1. local memoryのconsistencyの自前管理
2. branchのhint命令の挿入
3. evenとoddを考慮したscheduling
4. instructionのstarvation回避
5. 間接参照の処理
6. SIMD化

あたりか。ちょっとコンパイラ側の負担が大きすぎな気もする。
0218デフォルトの名無しさん2005/10/29(土) 00:15:42
Rubyネタ、別に面白くもなんともないから
もう書かなくていいよ。
0219デフォルトの名無しさん2005/10/29(土) 16:12:19
>>218
ちゃんとフィルタ用のキーワードいれてるんだから文句いうな
0220デフォルトの名無しさん2005/10/29(土) 21:34:52
Lispって、学術的な意義とか歴史的な意味はすごいんだろうけど、
果して実用的なんだろうかと、ふと思ってしまう。
0221デフォルトの名無しさん2005/10/29(土) 22:11:50
どういう意味で?
Windowsで使えるフリーで高速でバイナリコンパイルでき日本語も使えGUIも使える
処理系がないという意味だとか、安価な土方を大量動員できるとかいう意味では
違うとは思うけど。
普通にプログラムを書くだけだったら例えばCやPascalなんかよりずっと楽だよ。
0222デフォルトの名無しさん2005/10/29(土) 22:25:11
「普通のプログラム」ってのが何かによるだろ。
ちょっとしたデータ処理を書くにはLispの方が楽だけども、
もうちょっと広義にあらゆるプログラムに対応できるという意味では
CやPascalの方が圧倒的に実用的だが。
0223デフォルトの名無しさん2005/10/29(土) 22:30:49
「もうちょっと広義にあらゆるプログラムに対応できる」わけでないからといって
実用的でないということにはならないと思うけど。
PerlでもRubyでもPythonでもJavaでもいいけど、「〜ができない→その言語は
実用的じゃないね」とはならないでしょ?
0224デフォルトの名無しさん2005/10/29(土) 23:20:31
まぁ適材適所だわな。
万能な言語があると思ってるのなら、夢見すぎだ。
0225２２０2005/10/29(土) 23:31:01
>>221
慣れもあるのでしょうが、自分だったら全くコード書く気が起きない。
（書けないんじゃないよ。）
あと、世の中の出回ってるソフトでLispでかかれたコードに出会ったことがない。
（Lispの機能を示すために書かれているコードを除いて。）

こんな意味です。
0226デフォルトの名無しさん2005/10/29(土) 23:32:25
俺の記憶が正しければ、gccのコード生成部はLispのような書き方がされていた気がするが
0227デフォルトの名無しさん2005/10/29(土) 23:33:10
コード生成ルールの定義、ね
0228デフォルトの名無しさん2005/10/30(日) 00:00:32
>>225
>あと、世の中の出回ってるソフトでLispでかかれたコードに出会ったことがない。

GNU Emacsかなあ。
しかし、Emacsのカスタマイズ言語がe-lispじゃなかったら、
もっと多くの人がいろんな機能を作ってたんじゃ、と思わなくもない。
つか、俺もちっこいのはいくつか書いたけど、挫折した…
0229デフォルトの名無しさん2005/10/30(日) 00:28:38
昔の人工知能とかアルゴリズムの論文なんか見てるとLispっていうかS式やけに見るよ。
0230デフォルトの名無しさん2005/10/30(日) 00:29:23
Emacs開発開始当時、他にろくな選択肢がなかったんじゃないかな。
Emacsが未だに生き残っていることを考えると、
その中での選択としては大正解だったと思われる。
いい加減時代に合わなくなってきてるのには同意。
0231デフォルトの名無しさん2005/10/30(日) 00:35:46
vi信者に喧嘩を売ってるのかね？
0232デフォルトの名無しさん2005/10/30(日) 00:41:06
形態素解析の茶筌の文法書や辞書ファイルなんかもS式だった気が
0233デフォルトの名無しさん2005/10/30(日) 00:44:28
>>230
一応C言語はあったけど･･･
Cはろくな選択肢じゃないの？
それどころかむしろ、228も含めた多くの人は、C（に似たような言語）こそが一番
良かったと思ってるんじゃないのか？
0234デフォルトの名無しさん2005/10/30(日) 00:46:27
何で組み込みの話してるのにいきなりCが出るんだ。
0235デフォルトの名無しさん2005/10/30(日) 00:48:55
秀丸の拡張言語とかCに似てるじゃん。
0236デフォルトの名無しさん2005/10/30(日) 00:49:26
Lispが言語的に優れていてもそれほど普及しなかったのは、
・計算機資源を食う
・書き手の能力を問う
の二点が大きかったから。前者は今じゃ全然問題にならなくなったから、
後者をクリアしてる若い連中が「これいいじゃん」と騒ぎ始めた。

漏れみたいな、後者をクリアできないロートル＆無能には手続き型言語で十分さ。
0237デフォルトの名無しさん2005/10/30(日) 03:03:43
そう感じさせる要素が時間の経過によって様々に咀嚼されていろんな言語に現れ、
パンピーにも理解できるところへおりてきたのでかなりギャップは小さくなった
んじゃないかな。

今だと後者のふるいの役割はHaskell辺りだろうか。
0238デフォルトの名無しさん2005/10/30(日) 03:47:11
>>233
Gosling emacs の Mocklisp は C like な構文だったんじゃなかったっけ。
まあ結局生き残ってはいないわけだが。
0239デフォルトの名無しさん2005/10/30(日) 04:54:44
今から30年後にC言語は生き残ってるかな。
FORTRANみたいに特定分野で亡霊化してそう。
0240デフォルトの名無しさん2005/10/30(日) 06:46:30
30年後は誰もプログラミングしません
0241デフォルトの名無しさん2005/10/30(日) 07:23:25
>>238
よくわからんが、それはlispって名前がついてるのに
lispじゃなくてCなのか？
ただ、構文だけの話ではないの？
0242デフォルトの名無しさん2005/10/30(日) 08:04:43
検索で出てきたけど
RMS Lecture at KTH http://gnu.mirrormonster.com/philosophy/stallman-kth.ja.html
＞いつかは MOCKLISP を本物の LISP に置き換えようと

ここの説明ではC LIKEかどうかはわからんな。
ともかくLISPフロントエンドみたいな言語の話ではないのね。
0243デフォルトの名無しさん2005/10/30(日) 09:32:12
lispは使いもんになんねーってこと以外は優れていると思うよ
0244デフォルトの名無しさん2005/10/30(日) 10:03:27
>>240
今の技術の推移速度じゃ、それは無理だろ。
IT業界のハードの発展速度は確かに凄まじいものがあるとはいえ、
ソフトウェア業界の技術の発展速度は、藻前の想像以上に遅い。
0245デフォルトの名無しさん2005/10/30(日) 10:14:59
>>243
Lispに嫉妬する俺言語オーナーのスレはここですか？
ちなみに普段言語は何をお使いですか？ｗ
0246￣￣＼|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣2005/10/30(日) 10:17:53
　　　　 ＿＿＿＿_
　　 ／::::::::::::::::::::::::::＼　　　　　 　
　 /::::::::::::::::::::::::::::::::::::::＼　　 　 　
　 |:::::::::::::::::|＿|＿|＿|＿|　　 　　
　 |;;;;;;;;;;ノ　　　＼,, ,,／ ヽ　　　　
　 |::（ 6　　ー─◎─◎　）　　　
　 |ノ　　（∵∴　（ o o）∴）　　　
／|　　　<　　∵　　 ３　∵>　　　
::::::＼　　ヽ　　　　　　　 ノ＼　　　
:::::::::::::＼＿＿＿＿＿ノ:::::::::::＼　　
0247デフォルトの名無しさん2005/10/30(日) 10:53:53
>>245
事実を言っただけなのに何を怒っているの？
なにか気に障ること言った？
あっ！もしかしてキティちゃん？
0248デフォルトの名無しさん2005/10/30(日) 11:16:08
>>236
苫米地英人博士が、CommonLisp大好きらしいのだが、
漏れは、CommonLispの分厚い仕様書見て引いた。
なんだ、Schemeの方がシンプルでわかりやすいじゃん、と。
当時はR4RSと首っ引きで格闘して、研究してたなぁ。

産総研の某氏は、無節操に言語仕様を拡張できるScheme
を、最悪ですね、と評していたが、当の某氏は大学院時代、
Scheme使いだったはず。

EmacsLisp使いで業界で有名なK林氏は、大学院の同期
なんだが、元気にしてるんだろか。
0249デフォルトの名無しさん2005/10/30(日) 11:18:17
とりあえず、SchemeはLispだから。
話はそれからだ。
0250デフォルトの名無しさん2005/10/30(日) 11:46:04
Lisp だって？ダサ。Ruby のほうが圧倒的に優れているよ。
言語以前に Lisp は S 式をつかうところからしてユーザビリティが低いもん。
今時コンパイラやスクリプトを書くならオブジェクト指向 == Ruby が最高
0251 ◆LispYaxRvY 2005/10/30(日) 11:52:18
LISPでCコンパイラ作って遊んでるけど楽だよ。
0252デフォルトの名無しさん2005/10/30(日) 11:59:59
どう見ても>>246が一番キレてるけどね。
それをスルーしてるあたり、同一人物かなｗ
0253デフォルトの名無しさん2005/10/30(日) 12:05:16
>>244
> 今の技術の推移速度じゃ、それは無理だろ。

速度なんか関係ないだろ。どんなに技術が進歩しても、それまでソフトウェア化の
対象じゃなかった分野が対象になるだけの話。

0254デフォルトの名無しさん2005/10/30(日) 12:14:31
>>250
Rubyは正直知らないんだが、言語のプロトタイプ作って研究するのに
字句解析、構文解析、ツリー構築からやれと？
LispでS式で書いてしまえば、ツリーまで出来上がってくるから、言語の
動作の部分に時間と労力を注げるわけだが。
0255 ◆LispYaxRvY 2005/10/30(日) 12:20:22
とりあえずLISPでもここまでできますよ、というサンプルうぷしました。
http://mata-ri.tk/up1/src/1M0593.zip.html
DLKey:251
ブートストラップして実行ファイル作ってるからLISPの痕跡はほぼないので
ただのCコンパイラもどきに見えると思う。
適当にサンプルソース添付したんで遊んでみてね。
0256デフォルトの名無しさん2005/10/30(日) 12:25:11
>>255
感動ｽﾀ!
すごいなぁ orz
俺ももっと勉強せにゃ
0257デフォルトの名無しさん2005/10/30(日) 12:26:15
>>254
250じゃないけど、S式の魅力ってそういうところにあるの？
いや、もちろんそういう利点があるのはわかるんだけど、
それだけなのかなってずっと疑問だった。ぜひ教えてください。
0258デフォルトの名無しさん2005/10/30(日) 12:39:36
Lispだって、C言語コンパイラ作るんなら字句解析からやらなきゃ駄目だろ。
0259デフォルトの名無しさん2005/10/30(日) 12:50:53
まあそういった字句解析みたいな類の本質的でない部分を
後回しにできるってこともあるんじゃないかと。
設計があやふやな状態であれ、何かを試したい事があればすぐに
本質に取り掛かれるって意味でS式は便利なものだよ。
0260デフォルトの名無しさん2005/10/30(日) 12:52:30
>>255
とりあえず元のLispのソースきぼんぬ
0261デフォルトの名無しさん2005/10/30(日) 13:20:26
rubyは便利だがあの文法がキモ過ぎる。
なまじ便利なだけにムカつく。
0262デフォルトの名無しさん2005/10/30(日) 13:22:35
>>255
参考までに、処理系は何?
0263デフォルトの名無しさん2005/10/30(日) 14:10:09
　　　　　　　 ＿＿＿＿＿＿＿＿＿＿＿
　　　　　 /´　 , -‐- ､.　　　　　　　　　　 /　　　スマップの中居
.　　　 　 i　　/::::::::::　　`''‐ ､..__,. ‐'´ヽ.　/　　 　稲垣・・・
.　　　 　 ! 　,'::::::::::　 　 、　　　　　　　∨　　　　アーティストのガクト
　　　　　|　 i::::::::::　　、 ､`''ｰ---‐''´　 ヽ
　　　　　|.　l:::::::: ／へ.＼` ｰ---‐ ´／,.ﾍ　　　　彼らが今脚光を浴び
　　　　 │　＼::::::::　＿＼＼,　　　/∠_　 |　 　　誰もが賞賛を惜しまないのは
　　　 　 |. /"ヽヽ:::=＝｡＝`,,　　 /=｡＝=│　　　言うまでもなく
　　　 　 | { i⌒| |:::::` ｰ-‐'　 　 .::.＼-‐ ´│　　　ただ　彼らが美形だったからだ・・・・
　　　 ／|. l ト､|.|:::::: ｰ-‐ '　　 ::::::::::: l::-‐'.|
　　／　 |　ヽ.._||::r':; -‐‐'　r __::::::::::::: l ｰ､|　 　　 勘違いするな　歌が上手いからじゃない
_／　 　 |　　 /l!:::/:: ー----------ｰ'--.|　　　　彼らは美形　ゆえに　今　その　全て
.!　　 　 .|　 ./ ::|::::::::::　　　　　 　 　 　 　 |　　　　人格まで肯定されている
|　　 　 │./　 ::|::::::::::: 　 　 =====　　 　 |＼ 　　 もし彼らが不細工だったらどうか・・・？
|　　　　 |/　　 ::|:::::::::::::...　　　 　 　 　 ,.イ　 .!`
|　　　　 |＼　　 :`'' ‐- ､::_:....... 　 ,. ‐'´/|　　│　　目も当てられない顔だったらどうか・・・・？
|　　　　│　＼ 　 ::::::::::::::::::｀~`''"::::::::/ .|　 　 |

これも言うまでもない　おそらく
中居は、音痴・・・　稲垣は、犯罪者・・・　ガクトは、いけすかないマイペース野郎
誰も相手にさえしない　わかりきったことだ・・・
翻って言おう　お前たちは不細工だから　今誰からも愛されることなく
貧窮し・・・・・・　ウジウジと・・・・・・　人生の底辺を・・・・・・　這って
這って　這って　這っているのだ・・・・・！　なぜか・・・・・？
それはおまえらが・・・・・・・・　ただ不細工だからだ　他に理由は一切ない
おまえらはもう20歳を越えて何年もたつのだから　もう気が付かなきゃいけない

もう心に刻まなきゃいけない・・・・・・！
0264 ◆LispYaxRvY 2005/10/30(日) 14:25:56
>>260
そのうちしかるべき場所で正式に公開するかもしれませんが、
現在は仕事の方が忙しいのでそれどこではないですね。
配布形態も考え中なので気長にお待ちください。
>>262
255の原始言語にあたるLISPも自作のコンパイラです。
そのLISPの原始言語はやはりCで、今のブートストラップは
C-LISP->LISP'->C'->C''という手順を踏みます。
コンパイラ最適化部はLISPで考えたほうが楽なので
今後C''+LISP'併合->何か
という流れにできないか構想中です。
0265デフォルトの名無しさん2005/10/30(日) 15:11:14
LISPだと初めから木構造になってるから楽とか言うけど、
今はJavaでもC++でもXMLライブラリがある。
0266デフォルトの名無しさん2005/10/30(日) 15:21:16
>>265
なんでそこで XML ライブラリが出てくるよ。
0267デフォルトの名無しさん2005/10/30(日) 15:27:56
木構造ならXMLちょちょいと書けばいいだけだから。
0268デフォルトの名無しさん2005/10/30(日) 15:50:54
>>267
プログラムを表す木構造をXMLで書くの？
0269デフォルトの名無しさん2005/10/30(日) 15:54:31
話の流れからするとそういうことになるだろうね。
Lispの構文木をListで書くって話だったろう。
今は専用のエディタもあるし、楽だよ。
0270デフォルトの名無しさん2005/10/30(日) 15:55:09
×Lispの
○Lispでは
0271デフォルトの名無しさん2005/10/30(日) 16:19:11
個人的には、構文解析をサボりたいのならlispよりprologの方が楽だと思う。
でも余り処理系作成者に人気ないね。
0272デフォルトの名無しさん2005/10/30(日) 17:05:05
>>271
昔AIとかExpert Systemとかで痛い思いした人とか、痛い話とか一杯あるから。 orz
0273デフォルトの名無しさん2005/10/30(日) 17:23:04
>>271
パーザの類を作るだけなら、Prologもいいかもしれませんが、
バックエンドのRTL生成、アセンブラコード生成はどうしますか？
それ以前に、Prologはツリーなどのデータ構造を持てなかった
と思うのですが。
ただ、パタンマッチ、バックトラック、カットなどの機能はいいですね。
なので、Lispで美味しいとこだけエミュレートしたいわけです。
0274デフォルトの名無しさん2005/10/30(日) 18:13:10
>>268
The Evolution of Language
http://homepages.inf.ed.ac.uk/wadler/language.pdf
0275デフォルトの名無しさん2005/10/30(日) 18:15:14
>>273
ごく普通にリストがあるんだが。それとは別な話？
02762572005/10/30(日) 19:39:50
>>259
はい、そういう利点があるのはわかるんです。でも、それだけなんでしょうか。
「S式信者」と呼ばれる人たちがいるくらいだから、
きっともっと他の何かがあるんじゃないかと思うんですが…。

>>271
Prologインタプリタの字句・構文解析を使うって事ですか？
それとも構文解析ルールをPrologで書き下すってことですか？
0277デフォルトの名無しさん2005/10/30(日) 19:58:35
>>276
＞きっともっと他の何かがあるんじゃないかと思うんですが…。
それだけじゃないんだが、少なくとも言語処理の観点から見るとそれだけ。
0278デフォルトの名無しさん2005/10/30(日) 20:05:59
結局はLispはあまり現実のソリューションとしては採用されてないのは事実。
0279デフォルトの名無しさん2005/10/30(日) 20:08:34
>>276
> >>271
> Prologインタプリタの字句・構文解析を使うって事ですか？
> それとも構文解析ルールをPrologで書き下すってことですか？

構文解析ルールをPrologで書くと、BNFっぽくなるから、案外
便利かもよ？flex,bisonでやれ、と言われそうだが。
02802572005/10/30(日) 20:43:37
>>277
言語処理じゃない観点での利点ってなんですか？

>>279
Lispだと処理系作成者は字句・構文解析を一切やらなくてすむ、
(構文解析済みのツリーをユーザに書かせることになるからですが)
という話でしたから、それとは別の話なのですね。
あと、構文解析までが楽でもその先が辛そう、というのは>>273さんと同意見です。
常日頃からProlog使ってる人ならそうでもないでしょうけど。
0281デフォルトの名無しさん2005/10/30(日) 21:17:52
久し振りに伸びてると思ったらlisp寝たかw
まったくお前ら好きだネ。

lisp/ruby/綾
0282デフォルトの名無しさん2005/10/30(日) 22:00:09
>>278
でもおいら入社して研修終了後にいきなりsymbolicsの仕事だった

初めてのLispだったYorz
0283デフォルトの名無しさん2005/10/30(日) 23:58:53
>>277
俺も知りたい。参照かキーワードでもいいから教えて欲しい。
02842772005/10/31(月) 00:02:17
>>280 >>283
スマン。俺も知りたい。なぜ LISP スキーがそこまで S 式に拘ってるのか。
02852832005/10/31(月) 00:31:44
？？？
「それだけじゃないんだが」の部分を説明してくれればいいんだけど・・・。
02862772005/10/31(月) 00:35:39
何かあったのは確か。良く思いだせん。


……頭の中から搾り出してみると、プログラム本体をデータ (リスト) として扱えるから AI に最適とか書いてあった。
ぶっちゃけ良くわからん。
0287デフォルトの名無しさん2005/10/31(月) 00:39:42
コードもデータも同じように記述出来るというのは大きな利点。
それと関連して、他人のコードでも読みやすく理解しやすい（慣れれば）。
02882832005/10/31(月) 01:09:14
>>277 >>278
ふむ。ｻﾝｸｽ。ぶっちゃけ良く分からんに同意。

プログラムをデータとして扱える→AIに最適
プログラムをデータとして扱える→他人のコードでも読みやすく理解しやすい

素養が足りないせいか、どっちも飛躍を感じる。
さっきから調べてるんだが、前者の話はしばしば見かける。（後者は初耳）
でもどの説明も、この間をかみ砕いて説明してはくれてない。
02892832005/10/31(月) 01:10:17
間違えた。>>277 >>287だった。
0290デフォルトの名無しさん2005/10/31(月) 01:21:30
プログラムをデータとして扱える→マクロが書ける

んで、これが「他人のコードでも読みやすく理解しやすい」に繋がるかというと、
むしろ逆なんじゃないかという気がしてならない w
0291デフォルトの名無しさん2005/10/31(月) 01:23:18
別にLispスキーというわけではないが…

S式ならではの利点というとマクロが挙がると思う。
プログラムにプログラムを渡してプログラムを生成して元のプログラムに埋め込む、
とかそういう機能。
「こんな機能のある言語があったらいいんじゃね？」とか思ったら
コンパイラ作らなくてもマクロを書くだけで済む。

あとはS式が再帰的な構造をしているので、
再帰的プログラミングと相性が良い→宣言的にプログラムが書ける→読みやすいプログラムになる
マクロでプログラムが簡潔になる→読みやすいプログラムになる
って話はある。
括弧だらけになるけど本当に読みやすいか？っていわれると首を傾げたくなるのは確か。

書籍としてはOnLispあたり読むといいかも。
マクロを使ってLispにPrologの機能を追加とかそういうのも書いてある。

「AIに最適」は「lispの作者が人工知能の研究者でもあり、
自分のプログラムをlispで書いたからそういう印象をもたれているだけ」
的な話がOnLispに書いてあるね。
0292デフォルトの名無しさん2005/10/31(月) 01:24:35
伝わるかどうか知らんが，ざっと説明してやるから Lisp 話は Lisp スレでや
れよ．

プログラムをデータとして扱えるということは，プログラムそのものを操作す
るときに言語のフル機能を使えるってことだ．

たとえば，C を使っているとして，突如コンパイラがターゲットにしていない
CPU を相手にする必要がでてきたとする．客の注文で言語仕様にもカスタマイ
ズがはいる．そこで，C はどれほど使えるか？残念ながら C 言語は C 言語を
作るのにほとんど役にたたない．コンパイラを作るときに，パーサーを書いて，
できあがったツリーを（一部の人は XML で保存したり処理したいかもしれない
ね？）操作する処理をつくって…

ところが，Lisp では言語のカスタマイズは標準機能だ．プリミティブをターゲッ
ト用にコンパイルするコードジェネレータはつくるはめになるが，抽象構文木
の操作までは Lisp の機能が100% 利用できる．Lisp のマクロってのは構文木
の書換え機能みたいなもんだからね．最終的には Lisp のプリミティブに展開
されるので，Lisp 上で使っていた構文はほぼ使える．バックエンドは PIC マ
イコンなのに，構文は型推論付きパターンマッチ，とかね．

でもカリカリにチューニングしたいなら手間はかかるが C のほうが優れている．
02932772005/10/31(月) 01:25:33
>>288
＞素養が足りないせいか、どっちも飛躍を感じる。 
俺も本で見ただけです。すんません。
02942832005/10/31(月) 01:39:50
>>291 >>292
なるほどーーー！！！
Lispのマクロって構文木の書き換えのことなんだ！
プログラム＝データっていうのはそういう意味なんだ！！

大学のSchemeの授業じゃマクロまでやらなかったから全く分かってませんでした。

共感するかはともかく納得できました。
もやもやした物が解消して、すべてが1つにつながった気がします。
聞いて良かった。感動しました。感謝します。
0295デフォルトの名無しさん2005/10/31(月) 03:27:53
なんかLispがすごいものに見えてきた。
使ってみたい。
Windowsでネィティブコンパイルできる使えるコンパイラない？IDEつきだとなおよし
0296デフォルトの名無しさん2005/10/31(月) 03:31:13
>>295
別にすごいものでもなんでもないけれど。
Cしか知らないのなら、一度こういうものも知っておくとよいかもしれないね。
0297デフォルトの名無しさん2005/10/31(月) 06:44:03
>>296
同意。むしろひどいものだよね。
破綻した言語っていう言葉がぴったりで。
0298デフォルトの名無しさん2005/10/31(月) 08:11:13
はいはいわろすわろす
0299 2005/10/31(月) 08:32:04
デバッグが大変なんじゃないの？
型がないうえにマクロばりばりなんて恐ろしいように思えるが。
0300デフォルトの名無しさん2005/10/31(月) 08:34:53
無限の可能性を秘めためちゃくちゃ凄い言語だよ。
他の言語の仕様をLispに自分で追加できちゃうんだから。
0301デフォルトの名無しさん2005/10/31(月) 08:59:17
>>299
確かにその辺は欠点かもしれないけど、
最近UnitTestとかもてはやされたよね？
ああいう感じの開発スタイルが昔からLispではデフォ。
0302デフォルトの名無しさん2005/10/31(月) 09:14:48
言語研究で、新しいfeatureをちょっと実装してみたいときには
確かに便利そうだなぁ。

>>299
Cのマクロと違って、平常時から気楽に使うものではないんだろう。
0303& ◆QWv3R1XL8M 2005/10/31(月) 11:03:26
>>300
Lispは全く素人だが、たとえば、LispにRubyの仕様を取り込めたりするのですか？
なんか、言語の概念が凄い。
0304デフォルトの名無しさん2005/10/31(月) 13:29:20
で、結局Windows向けネィティブコンパイラはないのか。
そりゃ誰もつかわん
0305デフォルトの名無しさん2005/10/31(月) 14:40:56
Allegro Common Lisp使えばいいじゃん。
WIndows向けでネイティブコンパイルできるしIDEも完備されてる。
まぁ価格が高いので「誰も使わん」のじゃなくて「貧乏人には使えん」がな。

どうでもいいけどいつからココLispスレになったんだ？
0306デフォルトの名無しさん2005/10/31(月) 14:55:44
Lispをけなしてた奴って結局Lispを使えないか使ったこともない奴ばっかりだったね。
0307デフォルトの名無しさん2005/10/31(月) 15:00:08
Rubyをけなしてた奴って結局Rubyを使えないか使ったこともない奴ばっかりだったね。
0308デフォルトの名無しさん2005/10/31(月) 15:09:00
Rubyはそもそもまともに相手にされていないような。
0309デフォルトの名無しさん2005/10/31(月) 15:12:02
構文解析どころかパージングすらいらないforth厨がきましたよっと。

rubyはオブジェクト指向の理想を追いすぎてて、
少し本末転倒になっちゃってるとこがあるような気がする。

どっちかというと現実解の落としどころという点でpythonの方が好きかな。

凄いとは思うんだけどね。rubyは
0310デフォルトの名無しさん2005/10/31(月) 15:58:25
>309
どのへんが本末転倒で、どのへんがベターな落としどころなのか
ちょっとききたい
0311デフォルトの名無しさん2005/10/31(月) 16:14:00
最悪の落としどころだ(´Д`) > Python
0312デフォルトの名無しさん2005/10/31(月) 17:05:50
> 構文解析どころかパージングすらいらないforth厨がきましたよっと。

一瞬「バージンすらいない」に見えた。
0313デフォルトの名無しさん2005/10/31(月) 19:11:32
生まれた時から経験済み。(;´Д`)
0314デフォルトの名無しさん2005/10/31(月) 19:11:55
>>311
俺のように頭の悪いLisp挫折組はPythonは良い落とし所なんだがなぁ。
どのあたりが最悪なのかちと解説希望。
0315デフォルトの名無しさん2005/10/31(月) 19:17:05
>>304
あるにはあるが、別にネイティブコンパイラいらんだろ。
研究用なんだから、スクリプトだろうがハードウェアだろうが動けば良い。
0316デフォルトの名無しさん2005/10/31(月) 20:14:40
>>315
成果物を他人に広く使ってもらうためには、いるんだよね
ランタイムのインストールが必要見たいのは、なかなか
0317デフォルトの名無しさん2005/10/31(月) 20:29:23
>>316
だからネイティブコンパイラはあるって言ってるし、試すだけなら
インタプリタでもよいだろう。日本語読めないの？
0318デフォルトの名無しさん2005/10/31(月) 21:01:28
>>317
だから高くて一般人には手に入らないんだろ？
0319デフォルトの名無しさん2005/10/31(月) 21:14:01
>>318
フリーだが
0320デフォルトの名無しさん2005/10/31(月) 21:18:08
>>316
いやいや、人に見せるもの作りたいなら普通にC++とか使うだろう＾＾；
研究用っていう意味わからないかな。
0321デフォルトの名無しさん2005/10/31(月) 22:01:42
つ研究用＝実用性無し
0322デフォルトの名無しさん2005/10/31(月) 22:22:55
研究ってひとくくりにするから伝わらないんじゃないか。
言語研究でのプロトタイプの大半はぶっちゃけおもちゃだよ。
0323デフォルトの名無しさん2005/10/31(月) 22:25:35
実用性から考えるなら、言語の設計で重要なのは標準APIだと思うけど。
0324デフォルトの名無しさん2005/10/31(月) 22:37:23
>>303
取り込めたりする。
実際CLOSという、Lisp自身の機能だけで実現された
オブジェクト指向ライブラリがある。
まあもっとも、RubyよりCLOSの方がだいぶ前だけどね。

過去においては時代のはるか先を行っていた言語だし、
時代の進化についていける言語でもある。
0325デフォルトの名無しさん2005/10/31(月) 22:55:00
>>321
和炉他w
0326デフォルトの名無しさん2005/10/31(月) 23:45:38
研究してみないと役に立つかどうかわからんから
研究用がほとんど役に立たないのは当たり前じゃん。

得られた成果が次世代の言語に取り入れられていくんだよ。
0327デフォルトの名無しさん2005/10/31(月) 23:48:36
役に立つ研究なんか、役に立たんよ。
03282922005/11/01(火) 00:21:17
つうか Lisp スレでやれっていったのに…．興味のある人は Lisp スレにどー
ぞ．Common Lisp 初心者スレあたりでさー．挫折した人もどーだい．もうちょっ
と 詳しく解説すっからさー．ここでつづけると興味ない人には迷惑じゃん．

* Lisp とコンパイル

Common Lisp の規格には compile という関数がある．もし，与えられた数を
2 倍するネイティブコードが欲しくなったら，あなたはどうするだろうか？(仮
にこの関数を daboo ダボー)と呼ぼう．
(defun daboo (x) (* 2 x))
(compile 'daboo)
となる．ここで，おもしろいのは
(compile nil '(lambda (x) (* 2 x)))
と，こうする事で x を二倍するネイティブコードが得られる．もし貴方が
Lisp について知識を持っているならば， (* 2 x) の部分がプログラムである
事に気づくかもしれない．また，(* 2 x) が Lisp のリスト構造の表記でもあ
る事に気づくかもしれない…

[続きは Lisp スレで!!]
0329デフォルトの名無しさん2005/11/01(火) 00:35:38
以下のBNFを作りましたが、expressionで
左再帰がある為ループしてしまいます。
正しいBNFに変換していただけないでしょうか？


<program> ::= <statement list>

<statement list> ::= <statement>
| <statement> <statement list>

<statement> ::= <expression>
| <command>
| <if statement>

<expression> ::= <number>
| <string>
| <expression> <operator> <expression>
| <identifier> = <expression>

<command> ::= <identifier>
| <identifier> <parameter list>

<parameter list> ::= <parameter>
| <parameter> <parameter list>

<parameter> ::= <expression>

<if statement> ::= if <expression> : <statement>
0330デフォルトの名無しさん2005/11/01(火) 00:42:59
宿題の予感
0331デフォルトの名無しさん2005/11/01(火) 00:43:52
これは BNF として正しいよ。ループするかどうかは全然別の話。
0332デフォルトの名無しさん2005/11/01(火) 03:23:02
>>324
というか、CLOSがRubyの設計土台のひとつじゃなかったっけ。

>>326
研究で作ってみて役に立つことがわかったなら、
それがそのまま役に立つ可能性もあるじゃん。滅多にないけど。
0333ハーピィ2005/11/01(火) 05:57:48
E・∇・ﾖﾉｼ　＜333ｹﾞｯﾄ♫
0334デフォルトの名無しさん2005/11/01(火) 15:58:35
>>309
> 構文解析どころかパージングすらいらないforth厨がきましたよっと。

まあこのページを読んでみなよ
http://gikoforth.s13.xrea.com/wiki/wiki.cgi?postpone%a4%c8immediate

forthはBNFパーザさえ組み込めるんだよ？
0335デフォルトの名無しさん2005/11/01(火) 18:44:38
>>334
それとはちょっと違うが、
C++はパーサ・ジェネレータなライブラリがあるよｗ
普通のパーサジェネレータなツールと違うところはC++のソースとしてBNFが書けて
コンパイル時にパーサが作られる（生成＆コンパイル）こと。
ライブラリは演算子の多重定義機能とテンプレート機能を駆使
(Expression Template technique & Template Maeta-programming technique)
して作られている。
http://spirit.sourceforge.net/
0336デフォルトの名無しさん2005/11/01(火) 18:50:33
spiritはちょっと規模が大きくなるとコンパイル時間がヤヴァイ
0337デフォルトの名無しさん2005/11/01(火) 18:52:47
spirit ってどこがいいの？
03383342005/11/01(火) 20:36:13
>>335
> 普通のパーサジェネレータなツールと違うところはC++のソースとしてBNFが書けて

>>334のリンク先読んだ？

> Forthで書かれたBNFパーサーはこのForthのもつ力をうまく利用している。
> BNF記法もどきでルールをかけばそのとおりにパースできる。
> BNF記法もどきの部分もFORTHのソースであり、パースされる部分も同じFORTHのソースである。

同じじゃんｗ

ForthのBNFパーザはたった15行だけど
　→ http://gikoforth.s13.xrea.com/wiki/wiki.cgi?BNF%a5%d1%a1%bc%a5%b5%a1%bcinFORTH

そのspiritっていうのは何行？
0339デフォルトの名無しさん2005/11/01(火) 21:34:29
なんか男性○の大きさを競い合ってる厨房に似てるなぁ。。。
0340デフォルトの名無しさん2005/11/01(火) 22:25:54
>>338
インタプリタ（Forth）とコンパイラ（C++)では自ずと違いも出るさ。
パースした結果をどう利用するかとか速度とかね。
だから「ちょっと違う」と書いた。
あんまり字面だけみて脊髄反射しなさんな。

>>336-337
C++が動きさえすれば動くから移植に関して心配しなきゃいけない要素が少ないとか
ビルドの手順が単純とか、ソースとの融合度が高いから気軽に使えるとかが
利点じゃないかな。で、コンパイル時間の増加がデメリット。

以上の特徴を考えるとシステムにちょっとしたスクリプティング機能をつけたいとか、
言語処理を本業としないプログラムに補助的に小規模な言語要素を組み込むのに
便利なんじゃなかろうか。例えばゲームにマクロ機能をつけるとか。

本格的なコンパイラやインタプリタなら
普通のジェネレータの方がいいでしょうな。
高度な文法に対応するとか実行性能が優れているとか高機能なのツールあるし。
それに言語処理が主な仕事となるプログラムの場合
ジェネレート＆コンパイルという余計なステップを導入したり
ジェネレータ自身の移植性を気に掛けてもいいだろうしね。

要は適材適所で。
0341デフォルトの名無しさん2005/11/01(火) 23:38:29
最近のこのスレは勉強になるなぁ。少なくとも高房の漏れには。
0342デフォルトの名無しさん2005/11/02(水) 01:25:08
工房でなくても勉強になるような話題がゴロゴロ出てるからなぁ・・・
このスレで勉強にはならないとかいうヤシは、大学院レベルだろ。
0343デフォルトの名無しさん2005/11/02(水) 02:11:18
このスレ煽りしかないじゃん…。
0344デフォルトの名無しさん2005/11/02(水) 02:33:59
このスレの煽りの内容を理解するためには、それなりの高度な知識が必要なんだがな。
これだから自覚の無い連中は・・・まあ、マ板の専門系全般に言える事だが。
0345デフォルトの名無しさん2005/11/02(水) 02:40:13
ここム板
0346デフォルトの名無しさん2005/11/02(水) 02:43:11
少なくとも相談室7になってから勉強になるようなレスにはお目にかかっていないと思うけどな。
0347デフォルトの名無しさん2005/11/02(水) 03:26:37
>>342
同意。
0348デフォルトの名無しさん2005/11/02(水) 03:28:06
>>345
スマソ、言い間違えた。ム板と言いたかったんだ。

>>346
このスレ来て三日目の漏れとしては、全然知らないネタが少なくないぞ。
そりゃ、ぐぐれば出て来る知識ではあるが、一般教養ではないからな。

このスレの住人には一般教養なのかもしれんが・・・
0349デフォルトの名無しさん2005/11/02(水) 03:30:01
>>346
それは、たまたま貴女の専門とする分野が、Lisp等と重なっているからでは？
実用的な言語の話しになると、きっと目から鱗とおもいますぞ。
0350デフォルトの名無しさん2005/11/02(水) 03:33:12
> C++が動きさえすれば動くから移植に関して心配しなきゃいけない要素が少ないとか
> ビルドの手順が単純とか、ソースとの融合度が高いから気軽に使えるとかが
> 利点じゃないかな。

いつの間にC++はそんなに枯れた言語になったのやら w
0351デフォルトの名無しさん2005/11/02(水) 05:59:51
アンテナ仕舞い込んでボケッと生きていると、
皆にはごく当たり前のことが「いつの間にか」起こっていたりするんですよね :-)
0352デフォルトの名無しさん2005/11/02(水) 09:21:42
>>344
はいはいわろすわろす
0353デフォルトの名無しさん2005/11/02(水) 09:27:44
あーあ、それは敗北宣言なのにー
0354デフォルトの名無しさん2005/11/02(水) 09:38:18
そうやってだらだらと会話を続けようとするから質が落ちる
0355デフォルトの名無しさん2005/11/02(水) 09:45:01
>>350
程度問題ではあるけどな。
ちゃんと規格どおりに動かないC++の処理系がまだあるのは知らないでもない。

でもまぁそれでも昔と違ってtemplate機能も含め規格はある程度定まってきてるわけだし、
環境の影響をあまり受けずにC++言語の規格の範囲内だけで
動作が確定しているという意味では
やっぱパーサジェネレータよりは一段ハードルが低いと思うよ。
（現状まだ問題があるにしても規格が定まった以上今後そう短くない期間で
そういう方向に改善が期待できるだろうし。）
仮にまともに動作するコンパイラがない場合は
結局ジェネレータ自身のコンパイルや
パーサジェネレータの吐いたコードがちゃんとコンパイルできる可能性も下がるわけで。

もっとも古いパーサ・ジェネレータなら確かに昔ながらの比較的枯れた機能だけ使って
書かれていて確かに枯れているかもしれんがその分だけ使い勝手は悪い。
例えばBisonやFlexではC++向にコードを吐かせた場合、
確かにtemplateなどの新しい機能を使わないソースを吐くが、
マクロが濫用されていてデバッグは今時のソースより面倒だし、
当てにしているstreamの仕様が古くてワーニングが出まくったりもする。
0356デフォルトの名無しさん2005/11/02(水) 10:03:33
>>354
そう思うなら自分のだらだらしたレスも控えればいいのにー
0357デフォルトの名無しさん2005/11/02(水) 16:52:12
Python(やHaskell?)のようにインデントや2次元の配置などで
ブロック構造を示したい場合、どんなふうに字句解析すれば良いんでしょうか。
0358デフォルトの名無しさん2005/11/02(水) 17:21:49
思いつきだけど。
連続するtab文字を一個のトークンにして
そこに幾つtabがあったかをリテラルのデータを覚えておく要領で
補助的なデータとして渡すとか。
で構文解析のときは行頭のタブ数が変わるまで同じブロックだと思う。
0359デフォルトの名無しさん2005/11/02(水) 17:53:56
タブやスペースの数そのものを覚えておく必要はないだろう。
字句解析から構文解析に渡すのは
インデント深くなった(1)
インデント浅くなった(n) [n >= 1]
の2種類のトークンだけでいいと思うが。
そして
インデント浅くなった(n)
はn個の
インデント浅くなった(1)
で表現すればよく、結局括弧のペアを用いるのと変わらない。
0360デフォルトの名無しさん2005/11/02(水) 17:58:33
覚えておく必要がないってのは構文解析部以後でってことね。
字句解析ではインデントの深さと文字幅をスタックで覚えておく。
0361デフォルトの名無しさん2005/11/02(水) 20:17:33
>>359
つまり、Lispと同じ。
結論：Lispは究極の言語
0362デフォルトの名無しさん2005/11/02(水) 22:42:06
>>361
「アセンブラでなんでも書けるから高級言語なんて不要！不要！不要！」論
を思い出した。
0363デフォルトの名無しさん2005/11/02(水) 22:56:07
何の関係も無いことを急に思い出すことって
たまにあるよね。
0364デフォルトの名無しさん2005/11/02(水) 23:10:49
LispがあるからXMLは不要！論もあったねｗ
0365デフォルトの名無しさん2005/11/02(水) 23:23:06
まあ実際不要だしな。
Lispで何十年も昔からやってきたことが今更流行ってるって感じ。
つくづくLispって凄い言語だったんだなって思う。
0366デフォルトの名無しさん2005/11/02(水) 23:42:55
>>365
こういう保守的で新しいことを覚えられない人たちが
業界から一掃されるといいんだけどね
0367デフォルトの名無しさん2005/11/02(水) 23:49:05
うはｗｗｗｗ天然記念物ｗｗｗｗ
0368デフォルトの名無しさん2005/11/03(木) 00:18:20
>>365
スルーした方がいいのかもしれんが、マジレスするとだな。
プログラミング言語というのは
人間に対して計算の記述方法というインターフェースを提供するという意味で
ある意味UIだからある処理がとにかく記述できれば
それでいいってもんでもなかろうということだ。

ある新しい計算モデルをとにかく記述できる言語の存在は
そのある記述法の性質を調べるという研究の段階では確かに有用だが、
その言語で書けたからと言って実際の現場においても全部その言語で作業するのが
人間やその集団という要素を含めて考えたときトータルで効率が良いとは限らない。

それはCUIでなんでもできるし
計算モデル上の新しい概念がまずCUIで試されたりもするけれど
GUIはやっぱり有用であるが如く。
0369デフォルトの名無しさん2005/11/03(木) 00:21:18
↑もうすこしわかりやすくたのむ↓
0370デフォルトの名無しさん2005/11/03(木) 00:22:01
LISPの代わりになるものが出来ればそれもいいんだけどね。
現実には大きくなりすぎたり、あれもこれも必要になったり、
パフォーマンスが悪くなったりと、なかなかうまく調和がとれない。
0371デフォルトの名無しさん2005/11/03(木) 00:22:12
telnetとftpで問題なく通信はできるけど
httpをブラウザから使うのが有用であるが如く。

の方が実感できるかな？ｗ
今まさに使ってるわけだから。
0372デフォルトの名無しさん2005/11/03(木) 00:30:45
>>371
つまりtelnet/ftp→http(HTML)→XML→S式と進化していくって言いたいわけ？
0373デフォルトの名無しさん2005/11/03(木) 00:35:48
構文を極力シンプルにして、諸機能の解析を意味解析時や実行時に行うと。
この点では XML も LISP も同じ。たぶん。
0374デフォルトの名無しさん2005/11/03(木) 00:48:55
PHPやrhtmlみたいな埋め込み言語見ればわかるけど、
それで何がやりたいかって、結局LISPみたいな事なんだよな。
そういった言語の存在はLISPを知っている人間からすると限定的すぎて
まるで無駄なアプローチに見えるけど、それしか知らなかった人間から見れば
実現する上ではそれしかなかったんだと。
0375デフォルトの名無しさん2005/11/03(木) 01:01:23
このスレ見てるとLispというのはセックスのように思えてくる。
慣れた人間には普通のことになるが
通過儀礼を経験していない童貞は過剰な反応をする。
ときどき>>361みたいに経験したての少年のようなこっぱずかしい
状態から卒業できない人もいる。
0376デフォルトの名無しさん2005/11/03(木) 02:38:06
>>356
この煽りの内容を理解するためには、それなりの高度な知識が必要なんだがな。
これだから自覚の無い連中は・・・まあ、マ板の専門系全般に言える事だが。
0377デフォルトの名無しさん2005/11/03(木) 02:59:44
コピペうざい
0378デフォルトの名無しさん2005/11/03(木) 02:59:45
半月ぶりにスレ見て、ずいぶんレスがついてるなあと思ったら
Lisperの戯言スレと化していたのな
内容的にもレベル低いし

死ねよいっぺん
0379デフォルトの名無しさん2005/11/03(木) 03:11:37
内容を問うなら>>378自身はどうなるんだｗ
気に入らないならあぼーんすればいいのに。
つーかおまえが死ね。
0380デフォルトの名無しさん2005/11/03(木) 03:22:27
Lisp関連レスあぼーんしたら、このスレ半月レスなしも同然なんだがなｗ
0381デフォルトの名無しさん2005/11/03(木) 04:38:04
>>368 と >>371 は同一人物か？
表現がうまいなw

>>378
俺的には結構おもしろいけどな。このスレ。
いろんな意味で勉強になる。
0382デフォルトの名無しさん2005/11/03(木) 10:25:37
Spirit 最強

Flex/Bison 死滅確定
0383デフォルトの名無しさん2005/11/03(木) 10:47:53
Lisp Delphi(Pascal) Ruby

以上三言語を日本三大厨房言語に任命する
0384デフォルトの名無しさん2005/11/03(木) 12:57:05
厨房ってのは、褒められてるものを叩きたくなるもんなんだよ。
そういうやつは、何らかの信者がこれは凄い！とか言ってると
絶対叩くの。
LispもRubyも叩いてるのは同じ奴だよ絶対。

そして、残念ながら褒められてるやつの中には本当に凄いものもあるんだよねｗ
0385デフォルトの名無しさん2005/11/03(木) 13:28:43
日本三大厨房言語っていったら

HSP VB PHP だろ。

特にVB厨がタチ悪い。
0386デフォルトの名無しさん2005/11/03(木) 13:42:07
>>384
最後の一文の必死さが哀れを誘うな

最初の三文だけにとどめておけばいいものを
0387デフォルトの名無しさん2005/11/03(木) 13:44:53
必死でもなんでもなく、ただの事実だな。
ツッコミたいなら「褒められているやつの中には本当に凄いものなんて無い」
というのを、明確な根拠を付けて口にすべき。
0388デフォルトの名無しさん2005/11/03(木) 15:09:48
Lisp最強とかRuby一番とか言ってるのは、
実はアンチの演技じゃないの、と思ってるわけだがどうか。

>>385
激しく同意。VBとPHPは世界的。
0389デフォルトの名無しさん2005/11/03(木) 15:15:21
>>387
386の発言から、わずか2分以内でそれだけの文章を書きこんで「必死でない」ですか
必死でなくてなんなんだ
0390デフォルトの名無しさん2005/11/03(木) 15:16:01
つうかそれが事実であったとしても
厨房とやらに叩かれてるものが、凄いものであるかどうかとは別やん
しかも世の中、凄いものであっても、叩かれるに値する欠点を有するものがほとんどだし
何アホ抜かしてるんだろうね
0391デフォルトの名無しさん2005/11/03(木) 15:22:18
>>389
384と387が同一人物ではないから必死ではないんじゃないかなｗ
0392デフォルトの名無しさん2005/11/03(木) 15:23:55
>>387ではないですが。
>>389(=>>390)はこの程度の文(!=文章)を書くのに
30分かかるのかもしれないけど、
普通の人は>>387程度なら2分で書けます。
0393デフォルトの名無しさん2005/11/03(木) 16:58:41
コンパイラの話を城
0394デフォルトの名無しさん2005/11/03(木) 17:05:55
できれば毎回決まってyaccだとかあの辺のパーサーの話になってつまらんので、
コードの最適化みたいな他の話題にしてくれ
0395デフォルトの名無しさん2005/11/03(木) 17:13:07
初心者が最初に詰るのがパーサだからな。
03963872005/11/03(木) 17:13:28
>>389
専用ブラウザを使いだすと、いわゆる「即レス」をすることは珍しくなくなるよ。
板を巡回中、スレ一覧をリロードしていると、既読スレが「新着有り」に変わる瞬間に頻繁に出くわす。
その時、リロードしたのが新着レス投稿の1分後で、行って読むのに10秒、レス書くのに1分なら、
>>386-387間の2分46秒は簡単に達成されるからね。

これって以前は誰でも当たり前に考えつくことだと思ってたんだけど、
IEあたりを使ってスレに張り付いた経験があったりするとなかなか想像できないみたいで :-)
これまでにも何度か「即レスの仕組み」を説明してあげたことがある。
0397デフォルトの名無しさん2005/11/03(木) 17:22:12
>>396
それって、この天気の良い秋晴れの午後にパソコンの前に座っていたことを証明するだけでは？
0398デフォルトの名無しさん2005/11/03(木) 17:23:27
死ねとか専ブラ使えとかいう話はもういいよ。
DAGの話でもしようぜ。
0399デフォルトの名無しさん2005/11/03(木) 17:26:51
誰も専ブラ使えなんて言ってないと思うけど。
0400デフォルトの名無しさん2005/11/03(木) 17:31:05
即レス返している時点で専用ブラウザ起動しっぱなしで２ちゃんねるチェックしているってことだろ？
それを自慢げに言われてもな〜
0401デフォルトの名無しさん2005/11/03(木) 17:34:49
>>400
つまり、一つスレを読むたびに専ブラ閉じるとか、
一度の2ch巡回で一つしかスレ読まないとか、
そういうのが君にとっての「普通」ということ？
0402デフォルトの名無しさん2005/11/03(木) 17:39:41
>>400
昨今は即レスが常駐を意味しなくなっている
という話だと思うんだが・・・

本気で誤読してるん？
0403デフォルトの名無しさん2005/11/03(木) 17:42:59
この話の落としどころは、389本人が自分のレスのわずか40秒後に
それだけの文章、と称した相手よりもっと長いレスを続けて書き込んでるところだと思う
0404デフォルトの名無しさん2005/11/03(木) 17:43:05
「即レス=>必死」ではないという話だよな…。
やっぱり本物の馬鹿がいるようだな。
04053412005/11/03(木) 17:44:25
余計な事を言ったようで本当に申し訳ありません。
心の中にとどめておくべきでした…。
勉強になるレスの多かったあの頃、カムバック
0406デフォルトの名無しさん2005/11/03(木) 17:45:40
>>401 >>402
400ではないが、常駐という言葉に齟齬があるんじゃないか?
400は、「コンピュータを起動して２ちゃんねるをチェック可能」な状態を言っているが、
401と402は「実際にチェックしている」状態を常駐と言っている。

もっと詳しく言えば、
400は２ちゃんブラウザを起動しっぱなしにするのはヤバい、と言っているが、
401、402はそれが当然、となっている。ここで食い違いがあるっぽい。


まぁ要するに、争点は２ちゃんブラウザ起動しっぱなしがヤバいかどうか、だな。
0407デフォルトの名無しさん2005/11/03(木) 18:17:18
>>406
いや、396が説明しているのは

専ブラによる即レス現象は、極端な話、わずか数分の2ch閲覧の間にも起こりうる

ということに関してで、起動しっぱなしとかはまったく関係無いと思うよ
0408デフォルトの名無しさん2005/11/03(木) 18:27:16
起動しっぱなしはともかく数分ごとに駄レス返すような奴はキモイと思うけど。
0409デフォルトの名無しさん2005/11/03(木) 18:31:31
不利な展開だと思ったら
話題をすり替えて印象批判に移行するのは
まあお約束
0410デフォルトの名無しさん2005/11/03(木) 18:39:51
Lisp厨がなぜ厨と呼ばれるか良くわかったよ
0411デフォルトの名無しさん2005/11/03(木) 18:44:52
>>378あたりから雰囲気悪くなったな。

LISPの話でもしようぜ。
0412デフォルトの名無しさん2005/11/03(木) 18:51:12
専ブラって投稿確認メッセージもスルーだからキチガイに鋏だな。


>>411
つまり半月ぶりにキチガイが帰ってきた結果がこれかと。
0413デフォルトの名無しさん2005/11/03(木) 19:10:41
常駐とかいう話は384と387が同一人物でないと成り立たないな。
しかし、387は384と同一人物でないわけで。
つまり、たまたまその時間に387がレスを見ただけなわけでｗ
0414デフォルトの名無しさん2005/11/03(木) 19:31:14
>>411
このスレの趣旨とLISPの話は関係ありません。LISPの話がしたければLISPスレに逝け。
これ以降はLISP話は禁止させていただきます。
趣旨にご賛同いただけない場合は別のスレを立ててそちらでやってください。
0415デフォルトの名無しさん2005/11/03(木) 19:33:01
>>414
だが断る
0416デフォルトの名無しさん2005/11/03(木) 19:37:14
Boostから、ライブラリ一式落としてきて、Splint見てみたんだが、
これって、LL(k)パーザ生成テンプレートという理解で、おｋ？

昔、研究でANTLRを少しいじったことがあるんだが、当時は
JAVA版再帰降下パーザしか吐けなくて、かつJAVAは16MB
もヒープを使うと「メモリが足りません」と泣きを入れてくる有様
だった。Open C++みたいなことやりたかったんだけど、できなかった
記憶があるなぁ。

とりあえず、自前でSchemeインタプリタ作りたいので、まずSTLの
勉強からやりなおそうか・・・orz
C++どころかANSI Cすら満足に書けなくなっていることに気づいて
青くなってる。職場では某国産RISCマイコンのアセンブラしか書いて
ないから。
0417デフォルトの名無しさん2005/11/03(木) 19:42:14
>>412
荒れてるのは、俺のいないときばかりなんだがｗｗｗ
0418デフォルトの名無しさん2005/11/03(木) 19:50:10
>>417
荒らしているのはお前だろ、どうせ。
らくに自作自演できると思うな、クソが。
しらないふりをしようとしても、みんな気付いてんだよｗｗｗｗｗ
大した知識も無いくせに、知ったかぶって一人で痛い知識をさらして
歓んでんのか？楽しいか？何が「俺のいないときばかり」だ、お前が荒らしを
迎えてるんだよ、この永世童貞が。二度とこのスレに来るんじゃねぇセフルオナニスト
0419デフォルトの名無しさん2005/11/03(木) 20:12:48
このスレ見てるとRubyというのはセックスのように思えてくる。
慣れた人間には普通のことになるが
通過儀礼を経験していない童貞は時に拒否反応を示すことがある。
0420デフォルトの名無しさん2005/11/03(木) 20:18:19
>>414
つかとっくに Lisp な人はこのスレから引きあげてるみたいだよ…入門スレで
Forth もどきのコンパイラが投稿されてた。こっちでつづければよかったのに
残念だなぁ…。
0421デフォルトの名無しさん2005/11/03(木) 20:20:18
>>420
お前も向こうに行けよ、氏ね
0422デフォルトの名無しさん2005/11/03(木) 21:01:30
>>420
残念だ。
>>421
お前が一番うざいよ
0423デフォルトの名無しさん2005/11/03(木) 21:39:45
るび厨が好き放題暴れてるな・・・
何が彼らをそこまで駆り立てるのか
0424デフォルトの名無しさん2005/11/03(木) 21:51:14
>>423
おそらくお前はruby嵐工作員だろ？w
おれはruby使いじゃないが、それだけ魅力に取りつかれた奴が多いのは事実だな。

言語というのは、魅力的かどうかというのも重要な要素になると最近つくづく思う。
0425デフォルトの名無しさん2005/11/03(木) 21:58:11
いるのは荒らしだけということに気づけ。
ruby厨もLisp厨もいない。
いるのは、アンチruby厨、アンチLisp厨
0426デフォルトの名無しさん2005/11/03(木) 21:58:25
> おれはruby使いじゃないが
俺ならもうちょっと自然な書き方するな
0427デフォルトの名無しさん2005/11/03(木) 22:06:46
イスラムとキリストの戦いと同じで、
どちらの信者も唯一神だと思っているから、
否定されると怒り狂うわけですよ。

俺は暇つぶしに荒らしているだけ。
04284242005/11/03(木) 22:47:09
>>427
いらんことするなw
0429デフォルトの名無しさん2005/11/03(木) 22:59:49
では多神教の日本的アニミズムに染まっているワタクシはOKでよろしいな（ｗ

なんでそれぞれの言語には得手不得手があると言う事を認められないかなぁ？
言語論争とかエディタ論争とかに関してフレームアップするといつも疑問に思う。
0430デフォルトの名無しさん2005/11/04(金) 00:14:22
rubyが他の何より最も役に立つ、という状況はうまく想像できないな。
何か説得力のある実例があればいいんだが。
0431デフォルトの名無しさん2005/11/04(金) 00:22:23
言語論争のネタに最適ｗｗｗｗｗｗｗｗ

0432デフォルトの名無しさん2005/11/04(金) 01:21:20
よっしゃきたー

荒れてきたー

>>430
lispが役に立つ状況だって全く想像できないのだが。
emacsを例に出す奴は、時代に完全に乗り遅れていることを認識すべき。
eclipse使えよｗｗｗｗ
0433デフォルトの名無しさん2005/11/04(金) 02:07:31
lispはバックエンドでいまだに沢山見かけるよ。
それの対極とは言わないけどRubyはフロントエンド向きってことなんだろう。
効率よりも書きやすさ？
0434デフォルトの名無しさん2005/11/04(金) 02:18:01
>>433

純粋に知らないので質問させてもらいたいのですが、

> lispはバックエンドでいまだに沢山見かけるよ。

たとえばどういうところか、教えてもらえませんか？
0435デフォルトの名無しさん2005/11/04(金) 02:31:47
有名なところでは US の YAHOO Store は Lisp で動いてるらしい。
0436デフォルトの名無しさん2005/11/04(金) 03:06:46
>>433
Rubyはフロントエンド向きというが、無計画が祟ってそろそろ綻びが目立ってきた。
今の開発チームにそういったバイタリティがあるかどうかは知らないけど
バージョン2.0あたりで一度根本的に仕様を見直さないとやばいかも。
0437デフォルトの名無しさん2005/11/04(金) 03:35:04
もうグダグダだなこのスレ。S/N比が悪すぎる。

次スレからは構文解析より後(Lispならmacroexpandの後)だけを対象に限定しようぜ。
表層だけしか見ない厨がよってたかって暴れたあげく
処理系開発と全然関係ない話するバカまでわいてくる現状はかなわん。

既成言語を出すのも、その言語自体の実装に関する話題か、その言語を使って
言語処理系を実装する話題のみに限定し、それ以外は禁止で構わないと思う。

どの言語がいいわるいだの開発体制がどうだのという話はどっか隔離スレを
作ってやってくれ。
0438デフォルトの名無しさん2005/11/04(金) 07:16:45
しかし最適化の話には殆ど反応がないからなあ。
スレの最初の方ではそういう話題も振られていたようだが、>>9に対して>>10のような頓珍漢な
答えが返ってくるところだし、構文解析の話を禁止したら寂れると思う。
0439デフォルトの名無しさん2005/11/04(金) 09:06:32
だって、最適化なんて全くしてないインタプリタにしたり
Cのソース吐かせたりするだけでそこそこ役に立つから。
最適化なんて、現状労力に見合わん。
0440デフォルトの名無しさん2005/11/04(金) 09:22:33
ソースを最適化するよりも、早いマシン買う方がコスト的には安上がりだからなぁ・・・
0441デフォルトの名無しさん2005/11/04(金) 09:35:06
構文解析ぐらいまでは学部の授業で扱ったりするから
ある程度盛り上がれるけど、
最適化まで話せる人間は2chじゃほとんどいないんじゃない？

>>437
気持ちは分かるが、やってくれといったらそうなるほど甘く無いぞ。
Nの半分は、スルーできないアホ住民らしいし。
0442デフォルトの名無しさん2005/11/04(金) 11:14:44
Lisp Ruby Delphi Java C# VB PHP HSP
などの厨房や初心者や信者がでしゃばってくる類の言語の話は一切禁止・一切スルーということにしようよ
0443デフォルトの名無しさん2005/11/04(金) 12:34:59
〜禁止とか、〜ｳｻﾞｽとか言ってる暇あったら自分から話題を提供すればいいのに。
0444デフォルトの名無しさん2005/11/04(金) 12:43:57
そうやって一切禁止した結果がゲ製作板
開発効率と速度とスクリプトの責任のバランスの話なんておもしろかったのに
0445デフォルトの名無しさん2005/11/04(金) 12:47:51
>>443-444
信者や厨房のくだらない話を見るくらいなら過疎ってたほうが遥かにマシ
0446デフォルトの名無しさん2005/11/04(金) 13:03:11
マシとか言うなら見なきゃいいのに。
0447デフォルトの名無しさん2005/11/04(金) 13:44:09
>>445
帰れよクズ
0448デフォルトの名無しさん2005/11/04(金) 13:59:12
一連の流れの中で唯一「ほほう」と思ったのは、
富豪プログラミングの元祖みたいなlispと、
ミニマリズムの求道者みたいなforthが、どっちも
「人間の手で構文木を作り上げる」というアプローチに帰着してるのが、
面白い傾向だなとは思ったなあ
0449デフォルトの名無しさん2005/11/04(金) 14:11:32
>>446
このスレは見たいが厨房や信者のくだらない話は見たくない、というかスレ違い。
0450デフォルトの名無しさん2005/11/04(金) 14:16:13
>>448
今時のマシンから見ると、その元祖はめちゃくちゃ小さな機械なんだよね。
まぁFORTHはもっと小さいんだけどさ。

スタックコンピュータラブラブな論文集めた本があった気がするが、誰かタイトル覚えてませぬか？
0451デフォルトの名無しさん2005/11/04(金) 14:48:46
lispだって構文は単純だし、
5つの基本関数さえあれば実装できるって話だったNe(希ガス)
だから結構minimalistな言語であるXe(希ガス)
0452デフォルトの名無しさん2005/11/04(金) 14:50:46
>>451
そういうレスが荒れの原因。以後スルーでよろしく。
0453デフォルトの名無しさん2005/11/04(金) 15:10:04
lispがforthにミニマリズム自慢をするのは、
「スーパーカブはガソリン食わないよ」
と言ってるのに、
「Ｆ−１マシンはインディーカーよりはガソリン食わないよ（だからスーパーカブよりすごい）」
と言ってるのと一緒やぞｗ
0454デフォルトの名無しさん2005/11/04(金) 15:12:14
なんだかんだいってJavaの時代なわけだし。
04554522005/11/04(金) 15:22:04
>>453
その喩えの対応関係がよくわからないなぁ。解説求む。

>>452
自分の荒らしスレスルー能力が低いからって
十把ひとからげに話題ごとスルーを強制するキミほどではないと思う。
0456デフォルトの名無しさん2005/11/04(金) 15:28:45
ああまたアホが……どうしようもないなこのスレ。
>>452
ミニマリストかどうかなんて処理系の実装と関係ない修飾語句にわざわざ
ひっかかるお前が悪い。
04574522005/11/04(金) 15:30:52
>>368、>>371でも書いたことだがなんせ言語の構文規則はUIだと思うから、
minimalistがとにかくスバラシイと思ってるわけでもないぞ。
だから「自慢」という表現は適切でないな。

minimalistな言語は処理しやすいからメタな処理が書きやすく、
プログラミングの新技法の実験とかしやすいけど、
込み入った記述が紛れて読みにくくなる傾向はあるから
よく使われる込み入った意味の「慣用句」をマークするために
専用の構文を割り当てるというのは実用上それなりに意味のある戦術だと思う。
0458& ◆YMjfxh6.bA 2005/11/04(金) 15:47:40
>>456
構文のデザイン戦術・戦略の話の一環だと理解して応答しているが違うのか？
0459デフォルトの名無しさん2005/11/04(金) 15:49:52
>>452 の言いたい事がさっぱりわからん。

>>368 >>371 >>457 を単体で見ると
Lispを褒め称えてるようにしか見えないのに、
前後の文脈からするとそうでもない。
0460デフォルトの名無しさん2005/11/04(金) 16:03:11
とりあえず名前欄に452と書いてる奴は>>455で>>452にレスしてるので
このスレの>>452とは別人だと思うんだけど
名前欄に452と書いてる奴はいったい何がしたいんだ？
04614522005/11/04(金) 16:04:09
>>459
褒め称えてる？
ちゃんと得失（得点と失点）両方挙げてるつもりなんだがなー。
0462謹んで訂正452→4512005/11/04(金) 16:05:48
数字ハンドル間違えた。スマソ。
0463デフォルトの名無しさん2005/11/04(金) 16:09:17
無理してこの話題続けなくてもいいのに
0464& ◆LMRaV4nJQQ 2005/11/04(金) 16:15:41
>>463
別に無理はしていないぞ？
興味関心の赴く所に従って書いているだけで。
むしろ荒れてるとされたであろうレスをザックリ無視しただけ。
どんな構文をデザインするかということに関する戦略・戦術は
言語設計の重要な楽しみだろう？
04654592005/11/04(金) 16:27:13
>>461

>>457 の
> 込み入った記述が紛れて読みにくくなる傾向はあるから
これをLispの欠点として挙げているのかな？

するとその直後、の部分、
> よく使われる込み入った意味の「慣用句」をマークするために
> 専用の構文を割り当てるというのは実用上それなりに意味のある戦術だと思う。
ここは、まさにLispのマクロの説明なわけです。
lisperがよく言う「CとかJavaとかでプログラムを書いてると繰り返しが多くて無駄だ」
っていうのはそういう話。

括弧が邪魔だ、とか、全部の構文が同じように見えるのが嫌、とか
そういう話ならそれはそうだと思うけど。
0466デフォルトの名無しさん2005/11/04(金) 16:47:18
Lisp結局全然使われてないでしょ？
一部の信者が作ったシステムに組み込まれていることはあっても、
標準化されている、もしくはそれに近いのはEmacsだけだし。
0467デフォルトの名無しさん2005/11/04(金) 16:47:59
そうそう。そのラス2行の話が失点にもなりうるって話ですよ。
全部の構文が同じようだからこそメタな処理が簡単に実現できる一方で
全部同じように見えると人間が読むときに注目しにくいという面がある。
（別にlispに限った話ではない言語設計上の一般的なトレードオフについて考えています。）
0468デフォルトの名無しさん2005/11/04(金) 16:53:32
>>466
使われてないという（割とありふれた）指摘だけでなく、
なぜそうなるに至ったのかを分析しないと
よりよい言語設計の検討に繋がっていかないわけで…。

そこでその得失について考えてみているわけです。
0469デフォルトの名無しさん2005/11/04(金) 16:58:10
>>466
>>Lisp結局全然使われてないでしょ？
>>468
>使われてないという（割とありふれた）指摘だけでなく、
>なぜそうなるに至ったのかを分析しないと
>よりよい言語設計の検討に繋がっていかないわけで…。

言語設計の検討はいいんですが、Lispが使われていない原因の分析はスレ違いだと思います。
0470デフォルトの名無しさん2005/11/04(金) 17:02:21
>>469
そのスレ違い定義は少々杓子定規杉ではないですか？
そんな杓子定規ではオチオチ例を挙げて分析することもできない…。

で、私は取り敢えず構文の着目しやすさと一様性のトレードオフという観点から
構文の形式の一様度の高いLispを例にとって考えてみたということです。
0471デフォルトの名無しさん2005/11/04(金) 17:18:21
>>466
標準としては ANSI Common Lisp がある。
0472デフォルトの名無しさん2005/11/04(金) 17:34:59
ForthもANSI Forthぐらいある！
0473デフォルトの名無しさん2005/11/04(金) 18:04:37
Forthは構文やセマンティクスがキモイで一蹴されるケースが多いけど、
Lispは関数スタイルやスコープなどが一貫してるので、
まあなんとか読めなくはないレベルに留まってるかな、と思う人は意外と多いはず。
そういう人がそれ以上を求めるならそれこそマクロの鬼になったり、
括弧大杉とかの理由なら適当なフロントエンドを作ればいいやと考えるだろう。
現状はまともに自己拡張ができる言語がこの２種ぐらいしかないので、
そういった機能が欲しい場合そもそも他のパッケージングされた言語と比べる意味がない。

また、これらの言語は数百から数千行程度である程度の処理系実装が可能でもあるので
俺言語オナニー入門者にとっては最適の素材と言える。
これらの特性はどこの馬の骨とも知れない他人の作った物が気持ち悪いだとか、
既存の物を探してきて覚えるというわずらわしい感情を全く抱かずに済むという利点がある。
可搬性を考えても他の処理系とS式レベルの互換を取るなどそれこそ朝飯前だろう。
0474デフォルトの名無しさん2005/11/04(金) 18:33:31
そういうのはチラシの裏でやってくれ
0475デフォルトの名無しさん2005/11/04(金) 18:42:33
おまいらまったく議論の内容が的外れですよ。
「LISPが使われてない」ということにしたい一部のキチガイが
キーワード出るたび脊髄反射してるだけですよ。
0476デフォルトの名無しさん2005/11/04(金) 18:50:52
でも、使われてないのは事実。
ごく例外をもって、広くつかわれていると言い張っている馬鹿Lisperがいるだけw
その点Rubyは一味も二味も違う。

あと、ANSI化してないのも発展している言語の特長だと思う。
0477デフォルトの名無しさん2005/11/04(金) 18:57:55
>476
>あと、ANSI化してないのも発展している言語の特長だと思う。
さすがRubistの言う事は一味も二味も違うな
0478デフォルトの名無しさん2005/11/04(金) 18:57:58
わかったから信者同士の言い争いはほかのスレでやってくれ
0479デフォルトの名無しさん2005/11/04(金) 19:05:10
このスレはコンパイラやスクリプトを作る人がぶち当たった問題点について議論するスレだよな？

各言語のマニアやフリークが誹謗中傷合戦をするところじゃないはずなのに何でいちいち突っかかるんだ？
0480デフォルトの名無しさん2005/11/04(金) 19:05:20
Lispは結局使われているの？使われていないの？
EmacsとYahooの機能のうちのある部分だけ？
0481デフォルトの名無しさん2005/11/04(金) 19:10:33
GCCとか、どっかの大学が作ってるコンパイラでも使われてるじゃん。
0482デフォルトの名無しさん2005/11/04(金) 19:23:40
>>481
あれで使ってるというのだろうか？
0483デフォルトの名無しさん2005/11/04(金) 19:28:03
商用だとAutoCADとか音楽関係のソフトの拡張言語としていくつか入ってた様な。
0484デフォルトの名無しさん2005/11/04(金) 19:32:40
Cannaとかautocadとか。
SchemeだけどGNOMEとかGIMPとか。
あとは初期のPostgresがlispだったとか。
和田研フォントの中を覗いたらlispだった。
最近面白いと思ったのはこの辺。ttp://common-lisp.net/project/ucw/
0485デフォルトの名無しさん2005/11/04(金) 19:32:57
>>472
マジか！マジで初めて知った。頑張るなーANSIも。

>>473
比べ物にならないと言い切ってそこで諦めちゃ進歩がないからな。
プログラミング言語の拡張性と記述能力、
メンテナンスや理解の容易さのバランスを如何に取るか
という観点から何か特徴を見出して比べないとな。

>>475
貶すためにくらべるんじゃなく、
得失を理解して新たな技術を生み出すために
比べる必要がある。
貶すやつや信者の主張すらも止揚してこそだろう。
私はLisp信者と呼ばれる人々の主張に一分の理を認めたからこそ
その主張と現状を共に説明するような観点を探すことで
初めて一様さによるメタ処理記述の容易さと
ソースコード上の特定の視認性のトレードオフに思いが至ったから
「信者」のレスすらも無駄だったとは（個人的には）思わんね。
0486デフォルトの名無しさん2005/11/04(金) 19:36:17
>>482
中間表現みたいなのをとりあえずS式にしとくってのは十分ありえる
拡張を目的に１つの言語として独立してるし、胸を張って使ってると言えるだろうｗ
0487デフォルトの名無しさん2005/11/04(金) 19:46:24
・高い自己拡張性
・（根っこのデータ構造がスタックかリストかの違いはあるが）単純な基礎構造
・構文構造を人間に書かせてしまうという思想
・（↑に伴う）初めて見たら「何これ？」と思う構文

って考えるとlispとforthって兄弟みたいな言語だと思うぞ。

>>486
Ｓ式じゃないが、javaのJVMコードはforth型のスタックマシン構造だったはず。
postscriptもforthの兄弟だが、あれもフロントエンド言語があるよね。
スタック言語と同じように、リスト系言語を中間言語とするというのは、
「使い方によっては」有効かもしんないと思うね。

＃使い方によっては、ね
＃どっかの信者みたく全ての状況で万能だと言い切る気はない
0488デフォルトの名無しさん2005/11/04(金) 19:46:46
>>484
ワロタよ。こんなもんで使われてるというのか？w
低級言語らしく、目標も低いようだなw
0489デフォルトの名無しさん2005/11/04(金) 19:53:17
音楽ソフトっつーと SONAR や CakewalkのCALかな
http://home.wanadoo.nl/t.valkenburgh/CAL.html
0490デフォルトの名無しさん2005/11/04(金) 19:54:37
いつからここは言語オタの独演会会場になったのでつか？
0491デフォルトの名無しさん2005/11/04(金) 19:54:50
確かに、ソフト自体もさるとながら、使われ方も軽いようですね。
0492デフォルトの名無しさん2005/11/04(金) 19:57:20
要するに全然使われて無いじゃないか、Lisp…
XMLの代わりにLispで十分、とか言っていた人がこのスレにいたよね
お元気ですか？
0493デフォルトの名無しさん2005/11/04(金) 19:58:05
まあアプリケーションに組み込む場合を考えると、言語構造がやたら複雑でも困るだろう。
LISPはサイズ的にも難易度的にもちょうどいいんじゃないの。
0494デフォルトの名無しさん2005/11/04(金) 20:00:44
逆に組み込み用途だとRubyは全く使い物にならないのは認める。
なんかあったっけ？
0495デフォルトの名無しさん2005/11/04(金) 20:03:41
luaとかJavaScriptみたいなLispから構文木取っ払ったような言語が
今後はがんばってくれます。
0496デフォルトの名無しさん2005/11/04(金) 20:06:17
なるほど、スクリプトエンジンも適材的所ということですね。
Rubyerより
0497デフォルトの名無しさん2005/11/04(金) 20:07:21
Lispは馬鹿には良さがわからん言語だから使われてないだけだよ。
XMLの代わりにLispで十分だけど、XMLの方が馬鹿にもわかりやすいから
使いやすくていいんじゃない？
0498デフォルトの名無しさん2005/11/04(金) 20:08:44
そういえば、JavaScriptもLispに非常に近い言語だね。
これはLispそのものではないけれど、メジャーなんじゃないの？
0499デフォルトの名無しさん2005/11/04(金) 20:11:07
比較的Rubyと近い言語のはずのPythonが、
組み込み用途でも結構頑張ってるのにRubyは使えないのは何でだろうと言ってみるテスツ
0500デフォルトの名無しさん2005/11/04(金) 20:11:44
いや、Rubyも組み込みで使えるでしょ。
ただメジャーじゃないだけ。
0501デフォルトの名無しさん2005/11/04(金) 20:12:15
数式処理の有名どころもLispのがあったんじゃなかったか？
まあLispのS式がアプリの前面に出てくる事ってあんまないけどね。
素人に出力見せるとゲ！って思われるのはある意味仕方が無い。
個人的には全部大文字に変換されるのがいけないと思うんだが。
デフォでcase-sensitiveを有効にする時代なんじゃなかろうか。
0502デフォルトの名無しさん2005/11/04(金) 20:13:48
Rubyは馬鹿にも良さが分かる言語だから広く使われている。
また、熱狂的なファンも多い。

野球で言うとこんなところか？

*Ruby ＝　阪神ファン
*Lisp ＝　ロッテファン
0503デフォルトの名無しさん2005/11/04(金) 20:15:28
>>497
CUIは馬鹿には良さがわからん環境だから使われてないだけだよ。
GUIの代わりにshで十分だけど、GUIの方が馬鹿にもわかりやすいから
使いやすくていいんじゃない？

telnetは馬鹿には良さがわからん環境だから使われてないだけだよ。
web brouserの代わりにtelnetで十分だけど、web brouserの方が馬鹿にもわかりやすいから
使いやすくていいんじゃない？
0504デフォルトの名無しさん2005/11/04(金) 20:17:09
>>501
確か、Maximaがそうだね。他にもあった気がする。

>>502
どうかな。Rubyが特別馬鹿にも良さがわかりやすい言語とは思えない
（Lispよりはマシかもしれないけど）し、歴史的、世界的に見ると
RubyよりLispのほうが使われてそうだけどね。
Lispなんて使われてないことにしたい厨房が暴れてるだけで。
0505デフォルトの名無しさん2005/11/04(金) 20:17:50
>>503
ある程度はその通りじゃない？
ごく一部のソフト、例えば、グラフィックソフトなんかはGUIじゃないとまずいけど。
0506デフォルトの名無しさん2005/11/04(金) 20:19:27
GUIとかCUIとか言ってる頓珍漢は何が言いたいの？
0507デフォルトの名無しさん2005/11/04(金) 20:20:45
CUIはバッチ処理、GUIは対話処理に優れる
研究用途やサーバでもないとコンソールの良さが生かされる場面はほとんどなく
そうでない人たちがGUIを求めるのは当然
0508デフォルトの名無しさん2005/11/04(金) 20:22:15
まあ結局パソコン上級者になるとキーボードばかり使うようになって
GUIでもCUIでも結局一緒になるんだけどね。
0509デフォルトの名無しさん2005/11/04(金) 20:24:06
XMLが馬鹿にわかりやすいと言っている人間は、XML Schemaをしらないんだろうな
0510デフォルトの名無しさん2005/11/04(金) 20:24:37
>>507
ってそのままlispとrubyにも当て嵌まらないか？

つまり

lisp=cui
ruby=gui
0511デフォルトの名無しさん2005/11/04(金) 20:25:28
キーボード操作をする余地を残してる間は素人
0512デフォルトの名無しさん2005/11/04(金) 20:27:48
LispとかRubyとか、使われていない言語に執着するのはなんで？
0513デフォルトの名無しさん2005/11/04(金) 20:28:34
>>486
>>487
すまん、不勉強で悪いが、
逆ポーランド記述はスタック構造マシンにもっとも適した記述だからforthが生まれてるんだよね？
で、Ｓ式ってのはリスト構造マシンにもっとも適した記述としてlispの類も生まれてると。
で、昔のプアな環境ではスタック構造マシンはともかくリスト構造マシンは「贅沢」だったわけだが、
今のリッチな環境では最下層の仮想マシンにリスト構造マシンを据えても全然無問題だから、
リスト系言語を中間言語に据えるのもありちゃう？という認識でＯＫか？

と、スレ本題に近いことを聞いてみる
0514デフォルトの名無しさん2005/11/04(金) 20:28:40
両極端だからでしょ？
俺的にはbison/flex+Cがマンセーなんだけど。
0515デフォルトの名無しさん2005/11/04(金) 20:28:41
>>509
XML SchemaがXMLじゃないだろｗ
XMLという馬鹿にもわかりやすい土台を使って作られた言語。
LispでXMLSchema相当のことをやることもできるが、
それだともっと敷居が高くなるからやらないだけのことｗ

0516デフォルトの名無しさん2005/11/04(金) 20:29:49
lispを設定ファイルとして使うゲームを昔見た気がする。
QuakeだかDoomの最初の頃だとおもったが。
でも実装は簡単そうだけど、保守性がなさそう（偏見）
0517デフォルトの名無しさん2005/11/04(金) 20:31:39
>>512
定期的に煽りがはいるから。
0518デフォルトの名無しさん2005/11/04(金) 20:33:39
>>515
ご冗談でしょうファインマンさん、って本知ってる？

催眠術に関するエッセイの最後で、
「出来るけどやらないだけのことさ、というのは、出来ない、を別の言い方で言っているだけだ」
という有名なラインがあるんだけれど、
（All the time you're saying to yourself, "I could do that, but I won't"
　　---which is just another way of saying that you can't.）

100回音読しろ
0519デフォルトの名無しさん2005/11/04(金) 20:39:42
普通のやつらの上を行け
http://www.shiro.dreamhost.com/scheme/trans/beating-the-averages-j.html

>Lispは、信者のみが見ることができる魔法の特性があるから素晴らしいんじゃない。
>単に、今ある言語の中でもっともパワフルだからだ。そして、みんながそれを
>使わない理由は、プログラミング言語とは単なる技術だけでなく、心の習慣でもあり、
>それは最も変化の遅いものであるというものだ。

>1960年頃にLispによって導入されたガベージコレクションは、近年では
>良い技術だと広く認められるようになった。
>実行時型判定も同じくポピュラーになりつつある。
>レキシカルクロージャは1970年代はじめにLispによって導入されたが、
>ようやくレーダーの端に捉えられはじめた。
>1960年代中頃にLispが導入したマクロは、まだ未知の世界だ。

0520デフォルトの名無しさん2005/11/04(金) 20:41:26
>>519
ﾊｲﾊｲﾜﾛｽﾜﾛｽ
信者は自分のスレに帰ってね
0521デフォルトの名無しさん2005/11/04(金) 20:42:01
>>518
言い方が悪かったな。とっくの昔にLispで同じようなことをやってるのさ。
Lisp自体にもうXML Schemaと同等の機能が備わっているからね
新たに言語を作る必要がないわけさｗ
0522デフォルトの名無しさん2005/11/04(金) 20:42:57
>>520
君はバカの壁って本を知ってるかい？
買ってから、100回音読してみたらｗ
0523デフォルトの名無しさん2005/11/04(金) 20:47:57
語尾にｗを付けないと精神的優位性を保てないのですか？
0524デフォルトの名無しさん2005/11/04(金) 20:48:48
まあそういうことにしといたら？勉強しろよｗ
0525デフォルトの名無しさん2005/11/04(金) 20:48:51
>>506
単なる当てこすりだから気にするなｗ

>>505、>>507
言いたいことはつまり作業種別ごとにトータルの得失考えて
インターフェースを選ぶべきってこと。言語設計も同じく。

>>513
歴史的に
パソコン前の汎用機時代にはむしろスタックの方がなく、
リンクリストでスタックを模倣する必要があった。
Lispは実はその時代に誕生した言語。

Forthはマイクロプロセッサ時代に誕生した言語で
マイクロプロセッサはメモリこそ少なかったけど
スタック機能は標準装備だった。

それぞれ（良し悪しの問題とは別に）生まれた環境を多少引きずっている。

>>487
JVMのスタックマシンはバイトコードの仕様記述のために存在するだけ。
レジスタ指定部をバイトコードから取り除くことでハードウェア独立を達成しながら
バイトコードの命令語長を短くするために採用された。
なので
最近のJVMではオペランド・スタックの部分も
それほどバカ正直にスタックマシンとして実装されているわけではない。
0526デフォルトの名無しさん2005/11/04(金) 20:50:06
トータルの得失考えて、Lispがもっともパワフルなんだけどなあ。
0527デフォルトの名無しさん2005/11/04(金) 20:50:33
普通のやつら〜の抜粋が出てきたとこでそろそろ内容的にLISPスレにシフトした方が
いいんじゃないかと思ったけど、まあ別にどうでもいいや・・。
0528デフォルトの名無しさん2005/11/04(金) 20:51:11
それはそうと>>518はなかなかいいことを言っているな
0529デフォルトの名無しさん2005/11/04(金) 20:51:18
あれが引用してる記事って何十年前の話なんだ？
0530デフォルトの名無しさん2005/11/04(金) 20:52:41
まあ、キーボード操作してる人から見ればいちいちマウスなんか使わないよ。
出来るけどやらないだけさ。
0531デフォルトの名無しさん2005/11/04(金) 20:53:30
Lisp厨はなぜ一般的にそれが使われていないかという現実から目を背けているよね
みんながバカで理解できないから、という自己矛盾をはらんだ理由ではなく、
まじめにどのような理由があるのだろうか
0532デフォルトの名無しさん2005/11/04(金) 20:54:18
Lisperは保守的な人が多いのですねｗ
0533デフォルトの名無しさん2005/11/04(金) 20:54:31
>>531
>>519に長々とその分析が書いてあるよ。

まあ、結構使われてるんだけどね。
0534デフォルトの名無しさん2005/11/04(金) 20:56:03
一言で言えば、バカに良さがわからない言語だからだな。
これはほとんどの人が納得すると思うんだけど。
0535デフォルトの名無しさん2005/11/04(金) 20:56:18
Lispの開発環境ってどんなのがあるの？
0536デフォルトの名無しさん2005/11/04(金) 20:57:15
最近ならDr.Scheme（PLT Scheme)が一番初心者にもとっつきやすいかな。
0537デフォルトの名無しさん2005/11/04(金) 20:57:32
>>534
それって、わからない人をバカと定義しているだけで、何の解決にもなっていないですよ
0538デフォルトの名無しさん2005/11/04(金) 20:57:48
>>535
slime
0539デフォルトの名無しさん2005/11/04(金) 20:58:07
>>534
バカしか相手にしていないんじゃないのか？
0540デフォルトの名無しさん2005/11/04(金) 20:58:16
>>537
いや、事実だから、疑問の解決にはなってるんじゃないかな。
0541デフォルトの名無しさん2005/11/04(金) 20:59:25
今日はLISP祭りですか？


LISPでLISPを書くことは日常的に行われていることだあ！

これって実に衝撃的なことだと思わない？

君はC++でC++が書けるか？
PythonでPythonが書けるか？
RubyでRubyが書けるか？
まあいつかは書ける日がくるかもしんないけど、
書けたとしても日常的ではないよね
PerlでPerlが書けたとしたらとっくにPerl6は登場してたさ

って感じで、みなさんはLISPのパワーってやつをもっと知るべきだと思います
0542デフォルトの名無しさん2005/11/04(金) 20:59:46
>>540
おまｗｗｗｗｗｗｗｗ、それ本気で言ってるの？ｗｗｗｗｗｗｗｗ
Lisperがバカなのが事実だろ？
と言われても反論できないジャマイカｗｗｗｗｗ
0543デフォルトの名無しさん2005/11/04(金) 21:00:44
>>541
ただ荒らしているだけ。一人食いつきが良くてさｗｗｗｗ
0544デフォルトの名無しさん2005/11/04(金) 21:00:47
Win向けのまともな実装がないし
細かい方言のせいでソース互換なし
バイナリも作れない
思考実験や手元で働かせるにはいいが
配布するには向いてない
0545デフォルトの名無しさん2005/11/04(金) 21:01:05
>>541
C++で書かれたC++はあると思うぞ。CはC++のサブセットだから、
Cで書かれたC++を含めると、ほとんどのC++がそうじゃないか？

あとOcamlはほとんどOcamlで書かれている。

まあ、C++やOcamlも強力なパワーを持ってると思うけどね。
0546デフォルトの名無しさん2005/11/04(金) 21:01:24
実はLispどころかRubyすら全然しらないけれど、
荒れているので便乗しているだけですｗｗｗｗｗｗｗ
0547デフォルトの名無しさん2005/11/04(金) 21:01:42
>>542-543
とうとう本性が現れました
0548デフォルトの名無しさん2005/11/04(金) 21:02:05
>>547
気付くのおそっｗｗｗｗｗ
0549デフォルトの名無しさん2005/11/04(金) 21:02:54
>>546　>>548
なるほど、Lispのアンチってこういう奴だったのか。
どちらの言い分が正しいか非常に納得。
0550デフォルトの名無しさん2005/11/04(金) 21:03:49
荒れたらまた来るね
0551デフォルトの名無しさん2005/11/04(金) 21:04:52
>>550
傍から見ていて、Lispについて勉強になったので、またきてください。
今度はもう少し頑張って突っ込んでみてください。
0552デフォルトの名無しさん2005/11/04(金) 21:08:19
>>545
いやいや、おれが言いたいのはそんなことじゃなくて、
どんな言語であれ、いずれは自己記述ができるのは自明の理なわけですよ
（HSPみたいなのは知らないけど）

LISPは処理系関係者以外でも言語自身に手が伸ばせる数少ない言語なのです！
ってことが言いたいわけ
処理系のソースなんて必要ない
0553デフォルトの名無しさん2005/11/04(金) 21:09:09
>>541
ところで、LispでLisp書いて何が嬉しいんですか？
0554デフォルトの名無しさん2005/11/04(金) 21:10:48
>>549
違う

まず、俺はアンチLispではない
また、俺が説得力がないだけで、アンチLispがどういうのかはまた別
日本人の一人が犯罪犯したからといって、すべての日本人がバカではないのと同じ
むやみやたらなレッテル貼りはアンチからすれば格好の餌だよ

>>550
実は俺も荒らしながらLispの情報を学べてよかった
0555デフォルトの名無しさん2005/11/04(金) 21:12:19
>>553
>>541は多分マクロのことを言ってるんだと思う。
0556デフォルトの名無しさん2005/11/04(金) 21:12:44
DelphiはDelphiで書かれてないのがバレて干されてしまいました
0557デフォルトの名無しさん2005/11/04(金) 21:13:44
>>553
接ぎ木の様に処理系能力を継承しつつ言語機能を向上できるんだあ！

と言ったら驚きますか？
驚きますよね
仕組みは実に明快なんで説明しませんが
つーかそんなことはLISPスレの兵にでも聞いてください
0558デフォルトの名無しさん2005/11/04(金) 21:15:13
違う違う。LispでLisp自身簡単に書けるんだよ。
readっていう反則的な関数があるせいでもあるんだけどねｗ
0559デフォルトの名無しさん2005/11/04(金) 21:18:57
558＞555
0560デフォルトの名無しさん2005/11/04(金) 21:22:26
Lisp Ruby Delphi Java C# VB PHP HSP
などの厨房や初心者や信者がでしゃばってくる類の言語の話は一切禁止・一切スルーということにしようよ
0561デフォルトの名無しさん2005/11/04(金) 21:24:01
C++は最強だぜ！
0562デフォルトの名無しさん2005/11/04(金) 21:24:48
Pythonばかりえこひいきだ
0563デフォルトの名無しさん2005/11/04(金) 21:25:22
Lisp Ruby Delphi Java C# VB PHP HSP
などの厨房アンチがでしゃばってくる類の言語の話は一切禁止・一切スルーということにしようよ
0564デフォルトの名無しさん2005/11/04(金) 21:27:00
>>554
お前、アンチLispだっていう自覚もないのなｗ
ああ、アンチLisp信者かｗｗｗ
0565デフォルトの名無しさん2005/11/04(金) 21:28:22
>>384が的中ｗ
0566デフォルトの名無しさん2005/11/04(金) 21:31:17
当然ながらLISPでLISPを書くのが日常的なものだとすると、
完全に俺竜LISPへ書き換えてしまったり、
全く別のものへ変えてしまったりも、
まあ多少の根性でなんとかなります

他の言語でやろうとすると一大イベントの大作業が
LISPだとものの数時間で終わったりするのです
しかも無計画な思いつきでもなんとかなったりします
ほんとだよ！

必要な物は多少の根性と若さ、息継ぎは必要ありません
まさに勢いのあるチャレンジャーのためにあつらえたかのような言語、
それがLISPの正体なのだあ！
0567デフォルトの名無しさん2005/11/04(金) 21:31:23
最近荒らしてる奴を特定できるようになってきた
0568デフォルトの名無しさん2005/11/04(金) 21:32:31
Lispの布教は別のスレでやってくれるかな
0569デフォルトの名無しさん2005/11/04(金) 21:33:58
おまいら、他人が生み出したものじゃなくて、自分のオリジナルな物やアイデアを自慢しあおうぜ！

…俺には何もないがな
0570デフォルトの名無しさん2005/11/04(金) 21:35:32
強力な言語だと自動的に熱狂的信者が沸いてきて、
熱狂的信者がいると自動的に厨房アンチが沸いてくるから。
半自動的に荒れてるようなもん。
0571デフォルトの名無しさん2005/11/04(金) 21:36:59
>>569
ここだけの話だがな。アセンブラ作ったの俺。
0572デフォルトの名無しさん2005/11/04(金) 21:37:40
>>571
すげぇええええええ！！！！！！！！！
0573デフォルトの名無しさん2005/11/04(金) 21:37:44
スレ的には　Lisp -> Forth 変換プログラムを作ってみるといいんじゃね？
とか思った。
0574デフォルトの名無しさん2005/11/04(金) 21:38:33
>>566
Lispはまさに前線向きの言語だよな。
おれもお前の言霊でなんかやる気がでてきた。
がんばるぞー。
0575デフォルトの名無しさん2005/11/04(金) 21:39:59
そういえば、俺流言語をC++で書こうとして挫折して
Lispで書いたとか言ってる奴がいたなあ。
今何やってるのかなあいつ。
0576デフォルトの名無しさん2005/11/04(金) 21:43:19
>>564がむかついたので、次はLisp厨のふりをして荒らします
0577デフォルトの名無しさん2005/11/04(金) 21:48:57
>>569
発明レベル

5: λ calculus、turing machine
4: parametric polymorphism、monad、offline partial evaluation、CPS
3: type inference、generational GC、strictness analysis、deforestation
2: graph coloring、G-machine、PRE、privatization
1: software pipeline、loop tiling、copy propagation
0578デフォルトの名無しさん2005/11/04(金) 21:51:53
Forthも昔からその小ささは魅力的ではあったんだけど、
後置記法というのは判るが基本プリミティブ（というのか？）が異質でいまいちわからんのだな。
四則演算程度ならともかく構文なんかは後置記法でどうすんのか、とか
暗黙的なスタック操作関係とか色々疑問が。
つーかこれじゃスレ違いな単なる愚痴だったか。
0579デフォルトの名無しさん2005/11/04(金) 22:05:51
>>577
ソフトパイプの発明が1かよ！
俺がやったのは0.1くらいだな。
0580デフォルトの名無しさん2005/11/04(金) 22:23:02
>>576
勘弁してください。
0581デフォルトの名無しさん2005/11/04(金) 22:32:53
>>577
元々の問題の難しさから言ってgraph coloringは5だろ。
0582デフォルトの名無しさん2005/11/04(金) 22:35:45
graph coloringはx86みたいな制約の多いCPUには使いにくいね。
みんなどうしてるんだろう。
0583デフォルトの名無しさん2005/11/04(金) 22:45:30
HSPが果たしてきた役割というのを再認識すべきだと思う
0584デフォルトの名無しさん2005/11/04(金) 22:46:08
なんだこののびは……
みたところ>>437がダイナマイトっぽいな。
次スレから「○○禁止」っつー発言を禁止しようぜｗ


というわけで(少しは)まともなお題

っ ゲーデルの不完全性定理
0585デフォルトの名無しさん2005/11/04(金) 22:46:31
同人製作のために作られた場当たり的なツール
生い立ちはCと似てるね
0586デフォルトの名無しさん2005/11/04(金) 22:48:39
つーかなんでこの板にIDないんだろう。
0587デフォルトの名無しさん2005/11/04(金) 22:52:39
>>573
Lisp スレに Forth もどき -> Lisp トランスレータ (30行くらい？) がでてたよ。
関数定義と if ... else ... end と四則演算しかないみたいけど。
0588デフォルトの名無しさん2005/11/04(金) 22:53:24
同意
ID議論スレpart2まで行って投票も200を超えたのに無視されてる
0589デフォルトの名無しさん2005/11/04(金) 22:57:07
Lisp Ruby Delphi Java C# VB PHP HSP
などの厨房や初心者や信者がでしゃばってくる類の言語の話は一切禁止・一切スルーということにしようよ
0590デフォルトの名無しさん2005/11/04(金) 23:01:18
>>584
不完全性定理自体はこのスレの範囲外な気がしますが、
そこから意味論の話題に行くなら面白そうですね。
でもこのスレでは、構文解析厨と、
（具体的なお題を出さない）最適化屋さんのような、
実装スキー（と思われる人）しかいないんですよね。
だめそうならMLスレやHaskellスレに移住したほうがいいかと。

で、具体的に何の話をしましょう。（お題出せなくてすみません）
0591デフォルトの名無しさん2005/11/04(金) 23:04:10
groovyとか面白そうだなって思ってるんだけどこのスレ的にはどうなんだろう？
0592デフォルトの名無しさん2005/11/04(金) 23:04:48
>>590
じゃあ>>9の話題を。
0593デフォルトの名無しさん2005/11/04(金) 23:08:30
>>590
操作的意味論と表示的意味論の関係を述べよ
0594デフォルトの名無しさん2005/11/04(金) 23:14:34
>>590
>>1の各トピックについて順に語っていこうか．

> 字句解析・構文解析から，データフロー解析，ループ並列化，データ分散，SSA変換，
> CPS変換，レジスタ割付，命令スケジューリング，ソフトウェアパイプライン，
> SIMD命令生成，VLIW向けクラスタリング，スクラッチメモリ向け最適化，リンク時最適化，
> JIT，動的バイナリ変換等の各種最適化，それにVM，GC，低消費電力化などなど。
> 意味論に関する話題も歓迎です。

0595デフォルトの名無しさん2005/11/04(金) 23:25:20
っていうか具体的な言語の話を禁止しても良いんじゃないかと思った。
0596デフォルトの名無しさん2005/11/04(金) 23:27:28
>>594
じゃあ終わりから順で。

>>593
どっちも形式的意味ではあるけど全然別物だと思うんですが、
何か論理的な対応とかあるんでしょうか。
0597真のストッパー2005/11/04(金) 23:32:04
りんごタソは、Lisp と Ruby どっちが好きなんだろう？
やっぱり宝石の方が好きかな？
0598デフォルトの名無しさん2005/11/04(金) 23:48:12
ハァハァ
0599デフォルトの名無しさん2005/11/04(金) 23:53:17
>>596
>>592は無視？
0600デフォルトの名無しさん2005/11/05(土) 00:03:54
>>599
傍聴したいやつはいるようだが、
自ら話したいやつは一人もいない予感。
0601デフォルトの名無しさん2005/11/05(土) 00:11:55
>>451
燃料投下する気はないけど嘘はよくないので訂正入れとく。７個ね。
0602デフォルトの名無しさん2005/11/05(土) 00:20:26
ttp://ja.wikipedia.org/wiki/%E7%B4%94LISP
と勘違いしたんじゃないかな。
0603デフォルトの名無しさん2005/11/05(土) 00:33:51
つーかぶっちゃけ
LISPも知らん奴がプログラミング言語を語るなんて
信じられない
0604デフォルトの名無しさん2005/11/05(土) 00:43:31
言語の理論研究の主流はLispからMLやHaskellに移りつつある気が。
なぜかこのスレではほとんど出てこないけど。

あと、オブジェクト指向のように、理論より実践が先行してできた
プログラミングパラダイムもあるので必ずしも信じられないことはない。
が、このスレでそんなアイデアが出てくる可能性は万に一つもないだろうなぁ。
0605デフォルトの名無しさん2005/11/05(土) 00:58:35
型推論が流行ってる？
0606デフォルトの名無しさん2005/11/05(土) 01:26:20
Lisp信者もアンチLispもいいかげんにしろよ
0607デフォルトの名無しさん2005/11/05(土) 08:32:20
>>604
Lispそのものを対象にした研究は、昔からあまりなかった気が。
意味論なんかも定義されちゃったし、λ計算なんかと似てるし。
アルゴリズムの説明や実現に使われることが多かった気がする。
0608デフォルトの名無しさん2005/11/05(土) 10:58:39
>>604
ここのLisperは本流に乗り損ねた亜流の集りってことに
早く気づけよw

一方のオブジェクト指向言語では Ruby はまさに本流。
06096042005/11/05(土) 11:52:53
は？どういう論理展開ですか？
0610デフォルトの名無しさん2005/11/05(土) 12:18:12
Ruby房の寝言にまともに付き合ってると
頭がどんどん悪くなるよ。
0611デフォルトの名無しさん2005/11/05(土) 12:25:13
↓亜流なオーラを隠せないタイトルの書籍群

Rubyを256倍使うための本 無道編
Rubyを256倍使うための本 邪道編
Rubyを256倍使うための本 界道編
Rubyを256倍使うための本 極道編
Rubyを256倍使うための本 魔道編
Rubyを256倍使うための本 黄道編
Rubyを256倍使うための本 網道編
Rubyを256+倍使うための本 場外乱闘編
Rubyを256+倍使うための本 紅玉制覇編
Rubyの冒険 旅立ち篇―Rubyで簡単プログラミング入門
0612デフォルトの名無しさん2005/11/05(土) 12:31:58
Lisp本の定番ってありますか？
この擦れ見てたら勉強したくなってきたw
0613デフォルトの名無しさん2005/11/05(土) 13:20:43
× 一方のオブジェクト指向言語では Ruby はまさに本流。
○ 一方のオブジェクト指向言語では Java はまさに本流。
　 Ruby はその成果を Ruby に焼き直すだけ。
0614デフォルトの名無しさん2005/11/05(土) 13:25:21
Javaはただメジャーなだけ。
本流はSmalltalk。
0615デフォルトの名無しさん2005/11/05(土) 13:27:41
>>612
入門では無いが、今だとこれか？
http://www.amazon.co.jp/exec/obidos/ASIN/4894714337/
http://www.amazon.co.jp/exec/obidos/ASIN/4894712261/

本読むだけじゃなく、mapcarとかapplyあたりが使いこなせるように少し
練習する必要はある。そうしないと入り口には立てない。
0616デフォルトの名無しさん2005/11/05(土) 14:22:28
Javaは教育用の言語でしょ？
実用性が低すぎて最悪だピョン
0617デフォルトの名無しさん2005/11/05(土) 14:23:42
>>616
IT土方は、それで必死に企業のERPシステムなんぞ作っていたりするわけだが。
0618デフォルトの名無しさん2005/11/05(土) 14:34:20
Javaの実用性が低いとは思えないけど。
統合開発環境のサポートがあれば非常に高い生産性をあげられるし。
0619デフォルトの名無しさん2005/11/05(土) 14:36:30
ネット用の言語じゃなかったのか・・・
0620デフォルトの名無しさん2005/11/05(土) 14:54:18
目的と手段をはき違えた奴が各言語厨だと言うことが本日の書き込みで解ったわけだが、
なんでそういう奴ってどこにでも湧いてくるんだ？
0621デフォルトの名無しさん2005/11/05(土) 16:17:14
lispで書いたlispの話が出てたが、
Wirth御大の「Pascalで書いたPascal」は「おー文書として綺麗に見える」と関心した記憶があるなあ。
forthで書いたforthも見たことあるが、あれはあれで「うんうんいい意味でも悪い意味でもforthだねえ」と思ったっけ。
ちなみにCOBOLで書いたCOBOLも見たことあるが、ノーコメントｗ

>>618
統合開発環境の性能がよければ生産性が高いのはどの言語でも一緒だと思うが？
smalltalkみたく統合環境そのものが言語であるってのもあるしな。
forthやlispほど求道者じゃないかもしれんが、smalltalkの自己拡張性もあなどれんぞ
あと、伏兵でHyperCardとかなｗ
0622デフォルトの名無しさん2005/11/05(土) 16:57:47
>>611
メジャーゆえに、色んな本が出版されるわけよ。
その点lispは心配いらんなw
0623デフォルトの名無しさん2005/11/05(土) 17:01:00
>>621
lispで書いたlispの話はそういうことじゃないと思う。
たぶんマクロの話。
俺の知ってる他の言語じゃ表すことができないんで上手く例を挙げられないんだけど。
(FORTHならできるんだっけ？)

たとえばCでもクラスを使いたいが言語のサポートがない、というとき。
そういうときは構造体をクラスに見立てて関数ポインタのテーブルを仕込んで
アレしてこれして…ということをする。
でも、コンパイル中に class { public : int .... というプログラムに出会ったら
struct { VTBL *vtbl; int ... }
というプログラムを吐いてそこに埋め込んでくれるようにできたら便利だよね？

実際Cのマクロでも似たようなことはできるけど、
残念ながらCのプリプロセッサとCは別の言語。
プリプロセッサはCの能力を使うことはできないし、
一度Cに変換してしまったらもう一度プリプロセッサにかけることはできない。
そしてできたとしてもCのプログラムはCで扱うのに適した形でない。
結局 cfront を作ることになった。

一方でLispは「「 Lisp で Lisp を書ける 」」。
Lispのマクロが吐くのはLispであるし、
LispのマクロはLispのプログラムだ。
LispがLispを吐き、そのLispがまたLispを吐く。
つまり、LispはLispのコンパイラをLispで強化できる。（他にも色々な言いかえができる）
結果、CLOSというLisp上でオブジェクト指向言語を実装したものができあがった。

・・・が、
規則でがんじがらめにされたJavaですらメチャクチャなコードを書くやつがいるのに
こんな自由度の高い言語を開発部隊に使わせる気にはなれない。
0624デフォルトの名無しさん2005/11/05(土) 17:01:17
>>621
懐かしいなぁハイパカ。
今思うとHyperTalkは結構よくできた言語だったんじゃないかと。
生産性は微妙だが。
0625デフォルトの名無しさん2005/11/05(土) 17:18:50
>>624
Hypertalkはめちゃくちゃ良くできてたと思う、IDEはなかったが、
あれで日曜プログラマを沢山排出したってのは非常に重要だと思う。
今だと同じ部分を担ってるのがflash関係だけどね。
0626デフォルトの名無しさん2005/11/05(土) 17:20:08
「LispでLispがかけるから凄い」というのがLisperのより所なのか？
笑っちゃいかんが、ワロタw
0627デフォルトの名無しさん2005/11/05(土) 17:28:41
>>626
それを言うなw
0628デフォルトの名無しさん2005/11/05(土) 17:32:59
>>626
単にパーサが書けるとか、そういう話と勘違いしてない？
0629デフォルトの名無しさん2005/11/05(土) 17:57:01
>>621

HyperCardの設計時の有名な逸話として、
開発チームのメンバーがあれもこれも機能を盛り込もうとした時に、
アトキンソンの大将が、
「そんな機能はうちの娘（当時９歳だったか）には理解できない」
といって複雑になりそうな機能追加をバッサバッサと切り落としていった、というのがあるね。

結果、カード＞バックグラウンド＞スタックという物凄くわかりやすい継承構造のもと、
知らず知らずのうちにオブジェクト指向で物を作っていく癖がついていくという
ナイス効果を生んだわけだ。

2.0以降になって大将の独裁体制からチーム構成が変更になった後は、
ありがちな機能追加でゴテゴテと見通し悪くなっちゃったけどね。
（それでもまだかなりすっきりしてるけど）

HyperCardもsmalltalkも「子供のために作られた」言語だよね、そういや。
0630デフォルトの名無しさん2005/11/05(土) 18:01:47
lispがめちゃくちゃ柔軟で強力で凄い言語だってのは
ゆるぎないんだから、もうそろそろこの話はやめないか？
続けても意味がない。
0631デフォルトの名無しさん2005/11/05(土) 18:25:03
>>623
いや、マクロの話じゃないよ。
そりゃ、マクロも所々使っているけど、普通にPascalでPascalを書くのと同じで
LispでLispを書くっていう話。
ただ、比較的短い。
>>615の本にも載ってるけど、本にして10ページ。
0632デフォルトの名無しさん2005/11/05(土) 18:56:12
>>629
ぶっちゃけ、オブジェクト指向ってコンピュータに疎い人向けの機能だからなぁ
0633デフォルトの名無しさん2005/11/05(土) 19:06:47
>>632
それを言うなw
0634デフォルトの名無しさん2005/11/05(土) 19:25:41
>>632
今度はオブジェクト指向信者を呼ぶつもりか、うぜぇ。
0635デフォルトの名無しさん2005/11/05(土) 19:59:42
いかし、オブジェクト指向って曲者なのは事実。
いままでの設計手法ではまるで歯が立たん。
0636デフォルトの名無しさん2005/11/05(土) 20:00:29
イベントドリブン型には適していると思うけど＜オブジェクト指向
0637デフォルトの名無しさん2005/11/05(土) 20:08:12
>>635
Lispがあれば楽勝
0638デフォルトの名無しさん2005/11/05(土) 20:15:24
>>637
何が？オブジェクト指向的なプログラミング？それとも設計？
0639デフォルトの名無しさん2005/11/05(土) 20:23:41
コンパイラやスクリプト作ろうという人は、結局自分の言語作りたいってことだから
言語の話題は良く伸びるんだろうね。
0640デフォルトの名無しさん2005/11/05(土) 21:00:13
>>635
そうでもないぞ。

モジュール設計の手法が身について無いと、ちょっとデカい
モノを作ろうとすると、簡単におかしな状況に陥るから。
0641デフォルトの名無しさん2005/11/05(土) 21:15:01
やっぱ、設計を勉強する順番は、
データ構造→モジュール設計→オブジェクト指向
だと思うんだがな。

スレ違いだが。
0642デフォルトの名無しさん2005/11/05(土) 21:18:30
>>639
ほとんどが信心してる言語のオナニー書き込みか、
それ以外の言語をけなす書き込みなのが問題
0643デフォルトの名無しさん2005/11/05(土) 21:31:42
というか、このスレの住民の目的はなんなんだろう？
06446402005/11/05(土) 21:32:49
>>640
ちょっと言葉が抜けてた。

＞そうでもないぞ。
＞
＞モジュール設計の手法が身について無い状態で
＞オブジェクト指向に手を出すと、ちょっとデカい
＞モノを作ろうとすると、簡単におかしな状況に陥るから。

と言いたかったんだ。

要するに、古い設計手法をある程度知った上でオブジェクト
指向に手を出さないと、色々と問題の発生する可能性が高いぞ。
0645デフォルトの名無しさん2005/11/05(土) 21:38:33
>>643
言語は、うまく広まれば人気者になれるからねぇ
みんな有名になりたいのでは？
0646デフォルトの名無しさん2005/11/05(土) 21:42:30
>>645
個人が適当に作る言語が広まるはずもないと思うけど…
あのRubyですら、使用ターゲットを明確に規定していないために
きちんとした位置を確保できないというのに。
0647デフォルトの名無しさん2005/11/05(土) 21:45:26
Rubyは広まってるし、まつもとは有名だろ。
0648デフォルトの名無しさん2005/11/05(土) 21:58:11
新しい言語の必要性が全然わからない。Rubyしかり。


というか言語なんて所詮手段であり、それを目的にする意味がわからない。
0649デフォルトの名無しさん2005/11/05(土) 22:14:58
>>645
信者が布教すれば布教するほどむしろ嫌われる現実に気づくのはいつなんだろうな・・・
0650デフォルトの名無しさん2005/11/05(土) 22:17:34
知名度は上がって欲しいんだけどね。
ユーザによって貶められるのは何とも何とも (´ー｀)y-~~
0651デフォルトの名無しさん2005/11/05(土) 22:30:32
>>648
同意

言語を作るのが面白いのはわかるけれど、ちゃんと目的意識を持って作った方が良いと思う。
JavaでもPHPでもC#でも（ここに出すのは嫌だがHSPでも）、どのように使用されるかを想定し、
それに適した言語の形を設計している。その想定が正しくて、需要があれば当然流行る。

Lispは古い言語だからある程度は仕方ないにせよ、Rubyなどは存在意義がわからない。
何か言語を使うとき、LispやRubyを使う選択肢を今後選ぶはめになるなんて想像できない。
0652デフォルトの名無しさん2005/11/05(土) 22:34:45
実用言語と研究用言語と自己満足言語の違いだな
0653デフォルトの名無しさん2005/11/05(土) 22:45:26
言語設計というかAPI設計の話だよな
ただ、JavaScriptのように、素人が使うことを前提とした言語設計みたいなのはあるな
0654デフォルトの名無しさん2005/11/05(土) 22:46:21
JavaScriptが言語としてどういいのか教えてくれ
0655デフォルトの名無しさん2005/11/05(土) 22:49:21
>>654
・メンバの継ぎ足しが強引に出来ること
・メンバへのアクセスがfoo.bar foo['bar']の両方で出来ること
0656デフォルトの名無しさん2005/11/05(土) 23:00:03
>>655
それって >>653 が言ってた素人云々とは関係あんの？
0657デフォルトの名無しさん2005/11/05(土) 23:01:49
>>654
関数オブジェクトとか、クロージャとか？

function complement (func) {
return function (x) { return !func(x); }
}

というような関数を作っておいて
var func2 = complement( func1 );
とするとfunc2 が指す関数は func1 の逆の真偽値を返す関数になる、とかできる。

あとはプロトタイプベースなオブジェクト指向とか。

割と先進的な言語ではあると思う。
素人が使うことを前提としているというのは聞いたことがない。
確かに素人が使ってる言語という気はするが。
0658デフォルトの名無しさん2005/11/05(土) 23:02:21
>>656
さぁ？俺はJSのいいとこ言っただけだよ。
でもマクロ用の言語をチョイスしろって言われたら
LuaやLispよりJS選ぶかな
0659デフォルトの名無しさん2005/11/05(土) 23:02:30
JavaScriptはブラウザさえあれば特別な実行環境を必要としないってのが一番ウケたんだろうな
言語仕様として見た時に、あれだけ方言が多い言語はどうかと思う…
0660デフォルトの名無しさん2005/11/05(土) 23:04:18
JavaScript はクロシージャが分かると世界が広がる。
逆にそれが分かっていないと、あまり他の言語とかわらん気がする。
0661デフォルトの名無しさん2005/11/05(土) 23:04:34
おまえら、言語関連のスレでJavaScriptとECMAScriptの区別がつかないのかよ。

>>659
言語仕様としてはECMAScriptに統一されている。
独自のビルトイン関数に方言が多いだけ。

>>656
素人向けの言語使用としては、セミコロン省略とかかな
06626602005/11/05(土) 23:06:20
ごめ、「クロージャ」だ。
激しく間違えた orz
0663デフォルトの名無しさん2005/11/05(土) 23:09:36
ECMAScriptの素人向け仕様
・基本的に上から順に実行されていく手続き型
・一番外のスコープでのみ、宣言せずに変数を使用可能
・特定の条件でセミコロンを自動補完
・型が無い

こんなところ？俺も実はJavaScriptそんなに詳しくないんだけど。
0664デフォルトの名無しさん2005/11/05(土) 23:10:06
660はVB出身だな、気にするな
0665デフォルトの名無しさん2005/11/05(土) 23:10:43
ECMAScriptの実装はやったことがないけれど、言語仕様見て面倒そうだなぁとは思った。
0666デフォルトの名無しさん2005/11/05(土) 23:11:29
実用言語≠研究用言語≒自己満足言語
0667デフォルトの名無しさん2005/11/05(土) 23:13:24
>・基本的に上から順に実行されていく手続き型

なんで、これが素人向けだ？w

下から順に実行されていく手続き型なんてあるのか？馬鹿
0668デフォルトの名無しさん2005/11/05(土) 23:14:04
JavaScriptはLispと似てるところがいいところ。
クロージャとか
0669デフォルトの名無しさん2005/11/05(土) 23:14:12
>>663
スコープではなく、functionの外でのみvar宣言がいらない、じゃなかったっけな
0670デフォルトの名無しさん2005/11/05(土) 23:15:03
>>667
C言語だと、まずmain関数からスタートするよね
0671デフォルトの名無しさん2005/11/05(土) 23:15:37
グローバルスコープから実行が開始されるってことね
0672デフォルトの名無しさん2005/11/05(土) 23:18:17
確かに、素人が軽く使う際になるべく問題を起こさないように苦心しているのはよくわかった
0673デフォルトの名無しさん2005/11/05(土) 23:19:35
仕事でJavaScriptを使って大規模なコードを書いている経験からすると、
マルチスレッドがECMAScriptの言語使用で決まっていれば良かったんだけどな
0674デフォルトの名無しさん2005/11/05(土) 23:24:39
>>673
JavaのThreadなんて神がかって使いやすいし
マネてくれればJSの強みになるんじゃないかな？
Runnableを強引に実装できるってすげー
0675デフォルトの名無しさん2005/11/05(土) 23:26:33
C++erな俺はsynchronizedだけでもいいから欲しい・・・・(;´Д`)
0676デフォルトの名無しさん2005/11/05(土) 23:27:18
synchronized よりも lock の方が短くて(・∀・)ｲｲ!
0677デフォルトの名無しさん2005/11/05(土) 23:30:16
>>674
Runnableってどんなのですか？
0678デフォルトの名無しさん2005/11/05(土) 23:31:44
>>663
>・特定の条件でセミコロンを自動補完

その話題は>>139のあたりで済んでるよ。
んで、そこから、Rubyは糞だという話になって、LispがLispがという馬鹿が出てきて、
今に至る w

ところで、Yahoo storeは、LispからC++とPerlに書き換えられたみたいね(部分かもしれんが)。
http://d.hatena.ne.jp/oooooooo/20050316#p1

このへんでPaul Grahamが愚痴ってる。
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02367.html
| (a) The reason they rewrote it was entirely that the
| current engineers didn't understand Lisp and were too
| afraid to learn it.

まあ世の中そういうもんだ w
0679デフォルトの名無しさん2005/11/05(土) 23:32:20
>>677
runというvoidメソッドを実装しなさい！って決まりを付けたインタフェースですよ。
JavaでいうインタフェースってのはC++でいう全部abstractなメソッドのクラスのこと
0680デフォルトの名無しさん2005/11/05(土) 23:34:30
補足すると
Runnableインタフェースを実装したクラスのrunがThreadのmainとして走る仕様
Threadそのものも継承できるけど、Runnableを使ったほうがスマート
0681デフォルトの名無しさん2005/11/05(土) 23:34:55
Runnable だったら、むしろ C# の非同期デリゲートとか Io のアクタメッセージとかの方が強力だと思う。
Cw には更に凄いものがあるらしいが。

コンパイラの話じゃないね｡･ﾟ･(ﾉД`)･ﾟ･｡
0682デフォルトの名無しさん2005/11/05(土) 23:36:40
Runnnable自体は単にrunメソッドを持ってるだけの何の実体もないクラス(インターフェース)だよ
多分言わんとしてるところは無名内部クラスのほうなんじゃないかと思われ
0683デフォルトの名無しさん2005/11/05(土) 23:36:54
setIntervalとかあるし、スレッドが無いわけではない
0684デフォルトの名無しさん2005/11/05(土) 23:37:10
>>678
本当にそれだけの理由だったのかどうかは当事者に聞かないとわからないけれどもね。
他のシステムならともかく、Yahooのトラフィックをさばききれず、
他の安定したフレームワークに乗り換えたというのはいかにも有りそうだし、
それはリーズナブルな判断だと思う。
06856542005/11/05(土) 23:38:46
653を読まずにただ興味から質問したんだ
回答してくれた人thx
0686デフォルトの名無しさん2005/11/05(土) 23:39:16
groovyってどう？
0687デフォルトの名無しさん2005/11/05(土) 23:39:24
純粋に質問だけど、Javaのスレッドのどういうところが好きなの？
0688デフォルトの名無しさん2005/11/05(土) 23:39:36
>>681
コンパイラの話ではないけど、言語を設計するという観点では重要だよな

>>683
シングルスレッドだよ。
例えばsetTimeout(function(){},0);は、現在のコンテキストが終わるまで実行されない。
0689デフォルトの名無しさん2005/11/05(土) 23:42:09
>>687
implements Runnableとクラス宣言時に書き
runにその内容を記述するだけでそれがスレッドとして動くようになる。
そんな実にシンプルで分かりやすいところ。
0690デフォルトの名無しさん2005/11/05(土) 23:42:55
負荷に耐える状況で使われているLispのフレームワークなんてあるの？
0691デフォルトの名無しさん2005/11/05(土) 23:44:11
>>680
>Threadそのものも継承できるけど、Runnableを使ったほうがスマート

とまあこのように、スマートじゃない方法を残しているところが
Javaの設計のタコなところだと思うんだが。
06926872005/11/05(土) 23:44:27
>>689
よくわからんけどｻﾝｸｽ。
それをそのままJavaScriputに組み込むのは可能なのかな。
もっとプロトタイプベースのJavaScriptらしいやりかたがある気がする。

>>683 >>688
実装によるんじゃない？
0693デフォルトの名無しさん2005/11/05(土) 23:45:20
>>676
いまや、キーワードは長いほうがいいんだよ。統合環境で自動補完してくれるから。

>>687
synchronizedがオブジェクトと関数のみにかけられ、
言語レベルでそれがサポートされているところなんかは
設計がしやすいし、後でソースが読みやすいね。
0694デフォルトの名無しさん2005/11/05(土) 23:45:34
まあ、世の中Lispの敷居の高さを超えられないバカが多いということだね。
JavaScriptは敷居を低くしたLispだから、流行ったんだろうね。
0695デフォルトの名無しさん2005/11/05(土) 23:46:10
JavaのThreadなるものを全く使った事なく妄想で言うが、

Runnableは使いやすいインターフェイス、そのかわり細かいチューニングができない
Threadは細かいチューニングができる、当然ややこしいインターフェイス

みたいな関係ではなく？
0696デフォルトの名無しさん2005/11/05(土) 23:46:21
>>692
> >>683 >>688
> 実装によるんじゃない？
仕様に書いてある。現在の主要ブラウザはすべてECMA-262 3rd Edition準拠
0697デフォルトの名無しさん2005/11/05(土) 23:47:08
Lispの敷居が高い？どういう冗談だ
0698デフォルトの名無しさん2005/11/05(土) 23:47:12
>>694
昨日、Lisp厨に化けて荒らすと宣言していた奴か？
0699デフォルトの名無しさん2005/11/05(土) 23:48:00
>>695
Runnableクラスをスレッドに投げるときは
new Thread(runnableInstance).start();
みたいな感じになります。
0700デフォルトの名無しさん2005/11/05(土) 23:48:20
>>695
ヒント：Threadはクラス、Runnableはインターフェース
0701デフォルトの名無しさん2005/11/05(土) 23:48:36
>>697
大半の奴はLispを見て、
「うわーなんだこの見にくい括弧は。最悪。」
で、ろくに学習する前に終わる。

これじゃあ良さを理解するどころじゃないわな。
そういうことだ。
0702デフォルトの名無しさん2005/11/05(土) 23:49:49
>>701
思い込み激しすぎ。>>690
0703デフォルトの名無しさん2005/11/05(土) 23:50:35
で、Lispを学ぶためにオススメな環境は？xyzなんたらとか？
0704デフォルトの名無しさん2005/11/05(土) 23:51:18
>>702
この目で何百人と見てきてるんだけどｗ
0705デフォルトの名無しさん2005/11/05(土) 23:51:38
>>703
今のところ、LispはEmacsやxyzzyを使っていない限り使い道ないし…
学ぶんだったら自分で実装するのが一番かな
0706デフォルトの名無しさん2005/11/05(土) 23:52:04
>>703
PLT Scheme
0707デフォルトの名無しさん2005/11/05(土) 23:52:55
>>704
この語尾のｗは昨日荒らした例のLisp厨だよな。放置で>>ALL
0708デフォルトの名無しさん2005/11/05(土) 23:53:33
せっかく面白い話だったのに、Lispのせいでまた荒れるのか
0709デフォルトの名無しさん2005/11/05(土) 23:54:17
>>678

ざまぁ見ろ！LISPER目！
これからは、オブジェクト指向言語の時代だ！
0710デフォルトの名無しさん2005/11/05(土) 23:54:30
ああ、昨日荒らすふりして俺からLispについて学んでた奴かｗ
0711デフォルトの名無しさん2005/11/05(土) 23:56:07
hoge.run = function() {alert('ｽｯﾄﾞﾚ!');}
startRun(hoge);

JavaのをそのままJSにもってくるとこんな感じの実装になるのかな？
0712デフォルトの名無しさん2005/11/05(土) 23:58:06
>>709
CLOS

しかしここまで理解されてない言語も珍しいな。
0713デフォルトの名無しさん2005/11/05(土) 23:58:32
>>704
同意。つーか、みんなどこも一緒でしょ？
ただ、Lispを悪く書くと変なのが粘着するからだれも書かないだけ。
0714デフォルトの名無しさん2005/11/05(土) 23:59:30
smalltalkの話しようぜ
0715デフォルトの名無しさん2005/11/05(土) 23:59:45
>>712
まじれすすると、それほど設計が悪いということでもある。（有る意味ね）
0716デフォルトの名無しさん2005/11/06(日) 00:00:39
今時はプログラムの入門と言ったらJavaだしな。
アメリカではPythonだけど（てかあれ元々教育用言語だし）
0717デフォルトの名無しさん2005/11/06(日) 00:00:41
>>690
米軍が使ってるんじゃなかったかな。たまにニュースに研究所の求人とかでてるよ。
その辺で俺は LISP のイメージが悪い。
0718デフォルトの名無しさん2005/11/06(日) 00:01:31
>>711
Rhinoのスレッド拡張は

hoge = function() { alert("ｽｯﾄﾞﾚ!"); }
spawn(hoge);

関数がfirst-classなんだからこっちのほうが素直だろうね。
0719デフォルトの名無しさん2005/11/06(日) 00:01:38
>>717
それはLISPじゃなくて米軍が嫌いなんだろう・・・
0720デフォルトの名無しさん2005/11/06(日) 00:02:16
>>718
神がかってるなｗ
0721デフォルトの名無しさん2005/11/06(日) 00:02:47
つうかものスゴい狂人がいるな… Ruby とか Lisp によほど嫌な思いででもあるんだろうなぁ
はやく ID 導入してほしい。あぼーんが楽になるのに。
0722デフォルトの名無しさん2005/11/06(日) 00:03:32
米軍が使ってるからﾜﾛﾀ
717にはAdaを紹介したい。
0723デフォルトの名無しさん2005/11/06(日) 00:03:51
>>718
これ関数を引数に渡してるの？
すごいね。
0724デフォルトの名無しさん2005/11/06(日) 00:04:13
>>717
妄想で語るなw
おれはAdaで苦しんでいるというのに。
0725デフォルトの名無しさん2005/11/06(日) 00:10:54
>>712
JavaScriptも、「最も誤解された言語」と言われてるらしい。
Lispの宿命か。
0726デフォルトの名無しさん2005/11/06(日) 00:11:44
>>723
すごいの？
JavaScriptでは、無名関数を渡すことなんてざらなんだけど
0727デフォルトの名無しさん2005/11/06(日) 00:12:28
>>717
> 米軍が使ってるんじゃなかったかな。
それはフレームワークとは言わない
0728デフォルトの名無しさん2005/11/06(日) 00:13:18
CLOSはね、漏れ修士論文のネタだったんだよ。
といっても本家CommonLispでなく、Schemeに載ったTinyCLOSだったけどな。
作者はどちらもG.Kiczales。TinyCLOSは、C++やJavaから見ると非常に違和感
あるオブジェクト指向だと思う。いきなりメソッドをdefgeneric(virtual宣言
みたいなもの)して、メソッドにオブジェクトと引数をアプライするという記法
だから。
0729デフォルトの名無しさん2005/11/06(日) 00:14:03
そりゃLisp使えるもんなら使いたいけれど、
大抵の用途では他に優れた言語があるんだからしょうがないよな。

優れたってのは、ツールとかアプリケーションサーバとか、
そういう生産性が優れたという意味ね。

Lispはマニアが楽しむための言語だと思うけど。もしくは教育用か。
0730デフォルトの名無しさん2005/11/06(日) 00:15:36
Lispが教育用？なんかHSPを”入門言語”としてすすめるくらい無謀だな
0731デフォルトの名無しさん2005/11/06(日) 00:16:03
>>729
研究用。漏れはMLを使うけど。
07327122005/11/06(日) 00:16:11
>>725
実は最近JavaScript勉強して、懺悔したい気分になった。
0733デフォルトの名無しさん2005/11/06(日) 00:16:31
>>730
S式の教育用って意味じゃない？

プログラム言語の教育用としては、やはりCが良いと思う
0734デフォルトの名無しさん2005/11/06(日) 00:17:06
必死こいてオナニーしてる信者
必死こいて貶してるアンチ
0735デフォルトの名無しさん2005/11/06(日) 00:18:17
必死こいて勉強してる俺
0736デフォルトの名無しさん2005/11/06(日) 00:19:18
>>729
そういうのはただライブラリが揃ってるとか、開発環境があるとか
それだけのことが多いから、優れてるとはいわないんじゃないかなあ。
Cのライブラリが一番揃ってて生産性が高いからと言って、
PascalやJava他の言語より優れてるとはいいたくないな。
0737デフォルトの名無しさん2005/11/06(日) 00:19:25
だからお前らいい加減、JavaScriptとECMAScriptを区別しようよ。
JavaScriptはブラウザの拡張も含めた話をするときだけに使ってくれ。例えばRhinoとか。
0738デフォルトの名無しさん2005/11/06(日) 00:22:10
>>736
生産性の高さを自分で勝手にライブラリが充実してることと結びつけて
それをもってCが生産性高いとか言い出す意味不明さ
0739デフォルトの名無しさん2005/11/06(日) 00:22:29
>>736
いや、ライブラリなどの環境がそろっているというのが、
最終的な生産性を決めることなんじゃないかな。

言語としてLispが特殊であるのは間違いないと思うし、
それを優れているというのも特に反対は無いけれど、
仕事で使う以上色々な意味でLispは選択できない。

あと、Cは全然生産性が高くないです。バグを誘発しやすいし、標準ライブラリも酷い。
あえて反論を恐れずに書くならば、JavaとPHPの生産性が高いと思う。
0740デフォルトの名無しさん2005/11/06(日) 00:22:39
ではActionScriptの話をしよう
0741& ◆pYE.a7FxDY 2005/11/06(日) 00:23:17
まあ、言語なんて何でもいいじゃん
目的達成に一番便利なもの選べば間違いないんだし。
LispでもCでもJAVAでもOcamlでもRubyでも
どうせ皆使えるんでしょうどんな言語でも。
0742デフォルトの名無しさん2005/11/06(日) 00:23:29
>>738のあとの>>739ワラタ
0743デフォルトの名無しさん2005/11/06(日) 00:24:25
なんでだよｗ
でもE4Xにいち早く対応したのには感心するよ。
0744デフォルトの名無しさん2005/11/06(日) 00:24:39
>>741
コンパイラ・スクリプトエンジン相談室で何でその話になるんだ
0745デフォルトの名無しさん2005/11/06(日) 00:24:43
>>739
少なくとも、Cはgccやruby、python、perlなどの実装に使われてる。
これは、そういった用途では生産性が高いことを意味していると思う。
0746デフォルトの名無しさん2005/11/06(日) 00:26:14
このスレってさ、言語を作る話題のスレなんだよね…。
どう見ても言語を使う話題しか出てないけど…。

ライブラリは当然多い方がいい。
自分が作る処理系ではそーしてください。終了。
でいいんじゃないか？
0747デフォルトの名無しさん2005/11/06(日) 00:26:26
>>745
今度は生産性の高さのオレ定義を作り出しましたｗ
0748デフォルトの名無しさん2005/11/06(日) 00:26:51
なぜLisp信者はこれほどたくさんいるのに、
もっと環境を充実させようとしないのだろう。

GUIの簡単なプログラムを書く言語にLispを使えたらいいのに
VBだけは使いたくない…
0749デフォルトの名無しさん2005/11/06(日) 00:27:24
>>739
まあそうなんだけど、このスレで言うLispの素晴らしさって言語仕様のことだと思う。
ライブラリがないということは、はじめからLispの欠点として認めてるんじゃないかな。
0750& ◆po73KQOmZk 2005/11/06(日) 00:27:53
>>744
それほど、「コンパイラ・スプリプトエンジン相談室」してねえジャン
0751デフォルトの名無しさん2005/11/06(日) 00:28:01
>>748
そういう信者は初心者を寄せ付けないことに優越感を見出す人間が多いから
0752デフォルトの名無しさん2005/11/06(日) 00:28:34
優れている、優れていないを議論するなんて不毛だよな
0753デフォルトの名無しさん2005/11/06(日) 00:29:15
>>750
してなかったらいいのか？
バカは消えろ
0754デフォルトの名無しさん2005/11/06(日) 00:29:19
>>747
>>738で意味不明と書いたものの、>>739があっさり意味を理解して
一瞬にして赤っ恥を掻いた奴がまた現れましたｗ
0755デフォルトの名無しさん2005/11/06(日) 00:29:31
>>752
だから禁止にしようって前々からいってるんだけど信者が聞く耳をもつわけがなく
0756デフォルトの名無しさん2005/11/06(日) 00:30:45
客観的に優れているか優れていないかを証明するためには、
ライブラリの充実や実世界での使用くらいしか指標がないのが
Lisp使いにとっては厳しいところ。
0757デフォルトの名無しさん2005/11/06(日) 00:30:57
>>748
なんだかんだ言ってユーザーがそれほど多くないのと、
GUIとか作りたい初心者の気持ちがわからない
CUIラブの上級ユーザーが多いからだと思う。
0758デフォルトの名無しさん2005/11/06(日) 00:33:10
作る話題以外は当然だがすでに禁止されているはずだ。スレ違いなんだから。

他言語の話題を出すときは自分の作ってる言語とどう関係してるか
ちゃんと説明すること。
(自分はこうしようと思ってるけど他言語は違う設計になっている。
こうすると何がいいの？とか)
0759デフォルトの名無しさん2005/11/06(日) 00:33:12
>>755
むしろ、アンチが聞く耳もってない。
0760デフォルトの名無しさん2005/11/06(日) 00:33:27
>>757
とはいえ、CUIで世の中に配布するためにはCがベストソリューションという罠
新しい世界で必要な言語にLispを選べればいいんだけどね
0761デフォルトの名無しさん2005/11/06(日) 00:34:08
>>759
アンチだろうが信者だろうがおんなじことだよ。放置すればいなくなるのに。
0762デフォルトの名無しさん2005/11/06(日) 00:34:13
>>760
どこからそのベストソリューションと言う結論が出てくるの？
0763デフォルトの名無しさん2005/11/06(日) 00:34:20
>>748
>GUIの簡単なプログラムを書く言語にLispを使えたらいいのに
>VBだけは使いたくない…

どうせWindowsなら、WSH上でJScriptでも使ってればいいのでは?
俺使ったことないけど。
0764デフォルトの名無しさん2005/11/06(日) 00:35:01
>>763
WSHでGUIプログラムをどうやって書くんだ？？
0765デフォルトの名無しさん2005/11/06(日) 00:35:59
>>764
書けなかったっけ。じゃあ俺の勘違い。すまん。
0766デフォルトの名無しさん2005/11/06(日) 00:36:35
>>762
ごめん、思い込みかも。
LinuxでCUIベースのプログラムのソースを取ってきたときに
C以外は見たことがなかっただけでした。
0767デフォルトの名無しさん2005/11/06(日) 00:36:52
だから、LisperはCなみのスピードを出すコンパイラを
待ってんだよ!
0768デフォルトの名無しさん2005/11/06(日) 00:37:00
WSHでWinAPIを呼び出すdyncallというのが確かあった。
それ使えば出来る。
0769デフォルトの名無しさん2005/11/06(日) 00:37:40
>>764
ちょっとはググれや
0770デフォルトの名無しさん2005/11/06(日) 00:37:48
>>768
コールバック関数が書けないからアウト
0771デフォルトの名無しさん2005/11/06(日) 00:37:54
>>767
Lispって構文汚いけどCより速いってイメージだったんだけど違うの？
0772デフォルトの名無しさん2005/11/06(日) 00:38:04
>>766
つMaxima
0773デフォルトの名無しさん2005/11/06(日) 00:38:20
>>725
>JavaScriptも、「最も誤解された言語」と言われてるらしい。

世界で最も誤解されたプログラミング言語
http://d.hatena.ne.jp/brazil/20050829/1125321936

こいつな。
ところでここではやっぱり、
| セミコロンの挿入も大きな誤りでした。
って書かれてるぞ。
0774デフォルトの名無しさん2005/11/06(日) 00:38:36
>>767
仕様上かなり難しいと思われ・・・
0775デフォルトの名無しさん2005/11/06(日) 00:39:21
>>７６６
いや、いいとこついてるよ。
0776デフォルトの名無しさん2005/11/06(日) 00:39:25
WSHはhta作ればいいっしょー
あれは個人的にナイスな開発環境だと思っている
0777デフォルトの名無しさん2005/11/06(日) 00:40:02
>>771
Cよりは遅い。Cはマシンにべったりだからかなり速いし、メモリ食わないし、
出力ファイルのサイズが小さい。
・・・って、これ常識だと思うのだが、、、
0778デフォルトの名無しさん2005/11/06(日) 00:40:35
>>７７４
つまり、基本設計時点で（ry
0779デフォルトの名無しさん2005/11/06(日) 00:41:58
>>773
セミコロンがなぜ誤りだったかはかかれていないね。
しかしそのページはとても参考になった。ありがとう
0780デフォルトの名無しさん2005/11/06(日) 00:42:28
そもそもLispでシステムコール呼んでる場面見たことないな。
0781デフォルトの名無しさん2005/11/06(日) 00:42:57
>>776
HTAはいいよね。IE前提でさえなければね。
あれは言語というよりプラットフォームだから残念。
0782デフォルトの名無しさん2005/11/06(日) 00:43:34
>>778
その基本設定こそが最大の利点だよ。
まあ、Cよりパフォーマンスが出ないという点では劣っているけどね。
その代わり最大の利点を手に入れた。
0783デフォルトの名無しさん2005/11/06(日) 00:43:46
>>７８０
つまり、基本設計時点で（ry
0784デフォルトの名無しさん2005/11/06(日) 00:44:09
>>777
いや普通あんな汚い構文見てたらCより速いから使ってるのかな？って思うじゃん
0785デフォルトの名無しさん2005/11/06(日) 00:44:27
TkかGTKにでもつなげばwindows上でもlinux上でもGUIプログラムなんか書けるだろ。
0786デフォルトの名無しさん2005/11/06(日) 00:44:36
パフォーマンスはたいした問題じゃないと思う。Javaですらあれだけ流行っているし。
問題は、Lispがそれを効果的に使ってもらえる場所を探し出せなかったことだと思う。
0787デフォルトの名無しさん2005/11/06(日) 00:44:49
>>784
さすがにそこまでの超初心者はどっか行けよ。
0788デフォルトの名無しさん2005/11/06(日) 00:45:11
CISC RISCに続いてLISPプロセッサを作ればよいのだよ
0789デフォルトの名無しさん2005/11/06(日) 00:45:42
LISPが汚くて遅いと知ってて使うのが上級者？
0790デフォルトの名無しさん2005/11/06(日) 00:45:45
>>781
そもそもWSHが(ry
0791デフォルトの名無しさん2005/11/06(日) 00:46:10
>>786
Javaの成功は企業の後押しが大きいからなあ。
Lispはユーザーが少ないということと初心者に優しくないことに尽きる。
0792デフォルトの名無しさん2005/11/06(日) 00:46:22
>>790
その通りだった。申し訳ない
0793デフォルトの名無しさん2005/11/06(日) 00:46:37
HTA4Ajaxがそのうち登場するからズボン降ろして黙ってまっとれ
0794デフォルトの名無しさん2005/11/06(日) 00:46:41
>>789
そう。まあ今では結構速い部類だけどね。
0795デフォルトの名無しさん2005/11/06(日) 00:46:59
>>786
いや、パフォーマンスが重要なところだってあるよ、だから適材適所なんだってば・・・
0796デフォルトの名無しさん2005/11/06(日) 00:47:24
>>788
はるか昔にできて、滅んだ。
0797デフォルトの名無しさん2005/11/06(日) 00:47:26
Lispのネイティブコンパイラってピンからキリまであるけど
高いやつならCとほとんど変わらないスピードでるぞ。
少なくともC++よりは速い。無知はひっこんでおけ。
0798デフォルトの名無しさん2005/11/06(日) 00:47:46
>>791
いや、一番の問題は、使い道が無いことでしょう。
普通の人は、言語を覚えることを目標にせず、何かの目標の手段に言語を使うからね。
0799デフォルトの名無しさん2005/11/06(日) 00:48:04
>>793
それが事実でマルチプラットホームだったりしたら射精が止まらないんだが
0800デフォルトの名無しさん2005/11/06(日) 00:48:21
>>797
C++だって高いコンパイラ使って適切なコード書けばC並みに速いわ。
0801デフォルトの名無しさん2005/11/06(日) 00:48:42
JavaもC++と遜色ない速度になりますが、何か？
0802デフォルトの名無しさん2005/11/06(日) 00:48:47
>>797
FortranやPascalとタメをはるOOPとしてDが登場したから世の中分からないものだよ
0803デフォルトの名無しさん2005/11/06(日) 00:48:59
重要なのは　開発速度＞実行速度
0804デフォルトの名無しさん2005/11/06(日) 00:49:06
>>795
Lispの適所がないということは、適材ではないということ？
0805デフォルトの名無しさん2005/11/06(日) 00:49:26
>>７９８
いいこと言ったな
言語を設計＆実装する上で、参考になる。
0806デフォルトの名無しさん2005/11/06(日) 00:49:58
HTAでajaxなんて今でも使えるんだけど…
0807デフォルトの名無しさん2005/11/06(日) 00:50:08
>>798
まず、使い道がどこかにあっても理解されてない。その原因は初心者に優しくないから。

そして、使い道がない大きな理由は、ライブラリがないから。その原因はユーザーがいないから。
その原因は初心者が少ないから。
0808デフォルトの名無しさん2005/11/06(日) 00:50:39
>>８０３
その点では、宝石言語s はずば抜けていい。
0809デフォルトの名無しさん2005/11/06(日) 00:50:53
LISP厨はまだ居るの？
いい加減隠居してほしいんだけど
0810デフォルトの名無しさん2005/11/06(日) 00:50:56
LispとRubyは言語を覚えるために勉強したな。マジで楽しかった。
全く役に立ってないけど、アイデアの幅が広がったかもしれない
0811デフォルトの名無しさん2005/11/06(日) 00:51:39
>>792
マルチプラットフォームがいいならXULとかどうよ
0812デフォルトの名無しさん2005/11/06(日) 00:51:45
>>807
そのりくつは　おかしい
自己矛盾している
0813デフォルトの名無しさん2005/11/06(日) 00:52:00
>>810
とあるハッカーはLISPを実践で使う機会は無いがものの考え方の訓練として学べと言ってるしな
0814デフォルトの名無しさん2005/11/06(日) 00:52:42
>>811
ここでいうプラットフォームはブラウザなので、XULだとMozillaオンリーでよろしくないかと
HTAだとまだOSのサポートがあるだけ救いがある
0815デフォルトの名無しさん2005/11/06(日) 00:52:47
いろんな言語が使えるHyperCardさえあればなあ
0816デフォルトの名無しさん2005/11/06(日) 00:52:55
Scheme(Lisp方言)はGIMPの拡張書くのに使える。
GNU標準スクリプト言語になったらしいけどその後どうなったんだろう…
0817デフォルトの名無しさん2005/11/06(日) 00:52:57
>>812
いや、矛盾してないよ。全ての根本原因は「初心者に理解できない」に帰着する。
とても道理にかなっている。
0818デフォルトの名無しさん2005/11/06(日) 00:53:31
>>813
なるほど、同じようなことを考える人はいるもんだな。
しかし、やっぱりLispは教育用言語か
0819デフォルトの名無しさん2005/11/06(日) 00:53:32
Javaが使われてるっていったってサーバーの分野でしょ？
GUIとかのクライアントではあんまり使われてないじゃない。
まぁいろいろがんばってるみたいだけど
0820デフォルトの名無しさん2005/11/06(日) 00:54:04
>>816
そもそもGIMPとかEmacsの拡張書こうとする奴が少ないんだよ。
0821デフォルトの名無しさん2005/11/06(日) 00:54:12
>>817
言語の前に論理学を学びなさい
0822デフォルトの名無しさん2005/11/06(日) 00:54:26
>>792
MPが前提でAjaxと言ってしまった。すまんな。
0823デフォルトの名無しさん2005/11/06(日) 00:54:28
なんか、みんな思い思いのことかいとらんか？w
おそらくLisperw
0824デフォルトの名無しさん2005/11/06(日) 00:54:42
もしEmacsのマクロがC言語ライクだったら
0825デフォルトの名無しさん2005/11/06(日) 00:54:43
EmcasLispには誰も言及しないのか
0826デフォルトの名無しさん2005/11/06(日) 00:54:44
>>821
お前がな
0827デフォルトの名無しさん2005/11/06(日) 00:54:52
>>797
>Lispのネイティブコンパイラってピンからキリまであるけど
>高いやつならCとほとんど変わらないスピードでるぞ。

初心者な質問ですまんが、そういうのって、マクロ使ったら、ネイティブコード
破棄してインタプリタで実行するの?
0828デフォルトの名無しさん2005/11/06(日) 00:55:12
>>819
サーバの分野で使われているのは、それ単体でかなり大きなアドバンテージだと思う。
PHPなんてサーバでしか使われていないしね。
0829デフォルトの名無しさん2005/11/06(日) 00:55:36
>>823
固定つけてください
NGにしたいんで
0830デフォルトの名無しさん2005/11/06(日) 00:55:53
>>823
痛いところをつかれたようだ
0831真のストッパー（￣＿￣）ニヤリ2005/11/06(日) 00:56:29
もし、おれがりんごたその夫だったら。。。
0832デフォルトの名無しさん2005/11/06(日) 00:56:32
>>819
IBMが嫉妬の憎悪を燃やしてるからな
SUNという今にもサラ金に手を出しそうな家に生まれた超絶美少女みたいな
0833デフォルトの名無しさん2005/11/06(日) 00:57:55
>>827
そんなコンパイラ無いって…
0834デフォルトの名無しさん2005/11/06(日) 00:58:00
LinuxでCが多いのはgccの功績でしょうなあ。
まあ開発環境ってのはでかい。
0835デフォルトの名無しさん2005/11/06(日) 00:59:05
>>833
コンパイラなら早くなる、けどマクロ使えないってダメじゃん・・・
0836デフォルトの名無しさん2005/11/06(日) 00:59:06
>>834
Windowsがこれだけ普及したのも、Visual Studioの使いやすさがでかいと思う
0837デフォルトの名無しさん2005/11/06(日) 00:59:49
LispのJITコンパイラとか、誰か作ってそうだけどな

とここまで書いてわかった。Lispは金にならないから人が少ないんだな
0838デフォルトの名無しさん2005/11/06(日) 00:59:54
>>835
？
0839デフォルトの名無しさん2005/11/06(日) 01:00:51
初心者に優しくない→人が少ない
使い道がよくわかってない→人が少ない
金にならない→人が少ない

下に行くほど説得力が増す不思議
0840デフォルトの名無しさん2005/11/06(日) 01:01:05
>>838
じゃあどうやってマクロの処理してるの？
0841デフォルトの名無しさん2005/11/06(日) 01:01:41
>>839
下に行くほど説得力が増すように並べたからだろ？
何を言ってるんだ？
0842デフォルトの名無しさん2005/11/06(日) 01:01:44
どうせLispなんか作っても、「うわｗ括弧キモｗｗｗ」
とか言われるだけだから、自分で使うだけで十分。
GNUとかの凄い人が採用してくれるし。
0843デフォルトの名無しさん2005/11/06(日) 01:02:29
>>839
いや、一番上が一番説得力高いんだが・・・
0844デフォルトの名無しさん2005/11/06(日) 01:02:37
>>840
マクロの展開はコンパイル時に終わるのだが…。
0845デフォルトの名無しさん2005/11/06(日) 01:02:44
C言語って初心者にやさしいとはとても思えないけど、使える人が多いよね
Lispが普及しない理由に初心者にやさしくない、というのは間違っている気がする
0846デフォルトの名無しさん2005/11/06(日) 01:03:31
>>842
採用ってどこで？
0847デフォルトの名無しさん2005/11/06(日) 01:03:46
>>845
いや、初心者にはとても優しいよ。少なくともLispに比べればね。
Cを一から教えてLispを一から教えてみればわかる。
0848デフォルトの名無しさん2005/11/06(日) 01:03:47
>>845
なぁ、お前この言葉知ってる？

「とっつき」
0849デフォルトの名無しさん2005/11/06(日) 01:05:05
>>846
とりあえず、今まではEmacs、GIMP、で採用された後、GNUの標準スクリプトとして採用された。
これからは知らんけど、どっかで採用されるんじゃないの。GNUの標準スクリプト言語だし。
0850デフォルトの名無しさん2005/11/06(日) 01:05:12
>>842
そりゃGNUの一番偉い人はEmacsの作者だから
0851デフォルトの名無しさん2005/11/06(日) 01:06:33
Ruby ＞＞＞＞＞ HSP ＞＞＞＞＞＞＞ C ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ Lisp
0852デフォルトの名無しさん2005/11/06(日) 01:07:04
>>827
コンパイラへ渡す前に展開されるからネイティブコードになるよ。C++ 厨の俺
に言わせればテンプレートみたいなもん。

てーか作りたい言語が静的な型なら ML や Haskell から入門したほうがいいよ。
0853デフォルトの名無しさん2005/11/06(日) 01:07:12
GNUとEclipseがかみ合わないのはそのためか。
ApacheとかほとんどJavaに首っ丈だしな
0854デフォルトの名無しさん2005/11/06(日) 01:07:12
よくわかった。Lisp信者は、
・Lispを理解しない人間を馬鹿と定義し、
・Lispを一般に広く知らしめようとせず、
・Lispが最高であることを信じて疑わない

s/Lisp/オウム/g
0855デフォルトの名無しさん2005/11/06(日) 01:07:54
>>853
GNUの思想はもう古いだろ
0856デフォルトの名無しさん2005/11/06(日) 01:08:27
>>854
2番目だけあたってる。
0857デフォルトの名無しさん2005/11/06(日) 01:08:29
>>854
Lispは使い道が無い　も加えてくれ
0858デフォルトの名無しさん2005/11/06(日) 01:09:46
>>855
GNUは昔は企業に対抗するためのものだったのに
最近は企業が体よく技術を宣伝するためのツールと化してると思う
0859デフォルトの名無しさん2005/11/06(日) 01:10:06
まあLispを理解できなくても、頭のいい奴はいるよ。
ただの毛嫌いとか、そういう奴らの一部はそうだろう。
0860デフォルトの名無しさん2005/11/06(日) 01:11:31
>>859
覚える必要がない、というのが大部分だろう。
言語設計に興味を抱かないとなかなか出会えない言語だし。
0861デフォルトの名無しさん2005/11/06(日) 01:12:10
どんな糞なものでも知るだけでひとつ賢くなる。
Lispなんかはふたつ賢くなれる糞みたいなもんさ。
0862デフォルトの名無しさん2005/11/06(日) 01:12:50
事実に対して仮定を持ち出す
　「確かにLisperは少ないが、もし最もユーザーが多かったらどうだろうか？」

ごくまれな反例をとりあげる
　「ヤフーのサービスにLispが使われていた」

自分に有利な将来像を予想する
　「何年かすれば、Lisperがプログラマの５割を占めることになるだろう」

主観で決め付ける
　「Lispより優れた言語なんて存在しない」

資料を示さず持論が支持されていると思わせる
　「世界では、Lispが最も優れているという見解が一般的だ」

知能障害を起こす
　「Lisp＞＞＞＞＞＞＞＞＞＞＞＞＞他の言語」
0863デフォルトの名無しさん2005/11/06(日) 01:13:47
Lispはゴミ，Lisperは社会のゴミ
0864デフォルトの名無しさん2005/11/06(日) 01:14:04
>>861
わざわざ「ふたつ賢くなれる」とつけるあたりLisp信者の驕りが見え隠れするな
0865デフォルトの名無しさん2005/11/06(日) 01:15:37
>>862
詭弁ガイドラインに

捏造をする

を加えた方がいいな。
0866デフォルトの名無しさん2005/11/06(日) 01:15:49
Lispをいいと思うことは一向に構わないが、
主観で人にそれを押し付けるのだけはやめてほしい。

今夜のLisp叩きが始まったのも元はといえばLisp信者の鬱陶しい主張だ。
0867デフォルトの名無しさん2005/11/06(日) 01:16:20
googleで検索した結果

Ruby 37,100,000
Lisp 8,470,000

よって Ruby ＞＞＞＞＞＞＞＞＞＞ Lisp
0868デフォルトの名無しさん2005/11/06(日) 01:16:53
いや、元はと言えば、Lispに対する普通の事実に納得できなかっただけじゃない？
0869デフォルトの名無しさん2005/11/06(日) 01:17:05
>>864
俺はCOBOLだってふたつ賢く慣れると思ってるぞ
0870デフォルトの名無しさん2005/11/06(日) 01:17:38
>>868
それが主観ね
0871デフォルトの名無しさん2005/11/06(日) 01:17:49
>>868
たとえ事実でも言い方を間違えたら反感買うだけだよ
0872デフォルトの名無しさん2005/11/06(日) 01:18:02
D Language の検索結果 約 276,000,000
0873& ◆D3ra0B2LiQ 2005/11/06(日) 01:19:02
これのどこが、「コンパイラ・スクリプトエンジン相談室」なんだ?
0874デフォルトの名無しさん2005/11/06(日) 01:19:18
Java の検索結果 約 331,000,000
C の検索結果 約 1,660,000,000
N88BASIC の検索結果 約 27,700
0875デフォルトの名無しさん2005/11/06(日) 01:19:25
>>872
866も主観だね。
0876デフォルトの名無しさん2005/11/06(日) 01:20:31
>>753
これのどこが、「コンパイラ・スクリプトエンジン相談室」なんだ?
0877デフォルトの名無しさん2005/11/06(日) 01:20:55
馬鹿だな、LISPより遅い言語はいっぱいあるよ
ttp://shootout.alioth.debian.org/
0878デフォルトの名無しさん2005/11/06(日) 01:21:34
>>873
だよな、だからもう次スレからでもいいからはっきりと
言語仕様の優劣や言語仕様とは無関係な既存言語の話は禁止にしようぜ
0879デフォルトの名無しさん2005/11/06(日) 01:22:22
確認だけど、>>868が言うところの、「Lispに対する普通の事実」ってのは、
「括弧だらけでわけわからんので誰も使ってない」ってことでいいよな?

で、それに納得できなかったLisp厨が暴れている、と。
0880デフォルトの名無しさん2005/11/06(日) 01:22:24
言語使用の優劣を禁止するのはありだと思う

優劣なんて主観でしか決まらないし
0881デフォルトの名無しさん2005/11/06(日) 01:22:43
もともとは、アンチRubyが暴れてて、そいつがついでにLispも叩き出しただけだった。
だが、RubyよりLispに熱狂的信者がいてLisp一色になった。
0882デフォルトの名無しさん2005/11/06(日) 01:22:55
100人がLispを勉強すると、
50人はcar, cdrで挫折
25人は階乗で挫折
12人はreverseで挫折
7人はちょっとしたプログラムは書けるようになるが、list, cons, appendの区別がつかない
3人はこの言語の有用さに疑問をもち
2人は信者になるがそれ以上先に進まない

そして、運がよければ、最後の1人は立派なlisperになる。
が、会社ではCのプログラムしか書かせてもらえない。
0883デフォルトの名無しさん2005/11/06(日) 01:23:14
>>875
866はともかく、お前が主観で話しているというのが問題だ。
0884デフォルトの名無しさん2005/11/06(日) 01:23:47


結論：LISPERはクズ



終了！
0885デフォルトの名無しさん2005/11/06(日) 01:23:50
>>881
二行目に同意
0886デフォルトの名無しさん2005/11/06(日) 01:27:14
久しぶりに除いたら…すごいことになってるな。真性自作自演か…ちかごろ珍しいねぇ。
0887デフォルトの名無しさん2005/11/06(日) 01:28:10
>>886
お前がそれを書き込むことで得られるメリットって何だ？
0888デフォルトの名無しさん2005/11/06(日) 01:29:14
>>882
全然違う。

50人はインストールや起動方法などで挫折
25人は括弧で挫折
12人は資料の少なさ、デバッグ等のやり方で挫折
7人は再帰で挫折
3人はちょっとしたプログラムしか書けない
2人は信者になるがそれ以上先に進まない

あたりだと思う。
0889デフォルトの名無しさん2005/11/06(日) 01:32:03
>>877
Cライクな言語の独壇場だな
0890デフォルトの名無しさん2005/11/06(日) 01:32:09
昔どこぞの国のお偉い先生が
「実行速度が遅いからといって、その言語が悪いわけではない
コンパイラが良くなればいいのだから」
と言ってたような、言わないような。
俺は覚えやすい言語が、それがLISPであれなんであれ問わず、
コンパイラでもVM（インタープリタを含む）でもいいから
高速で実行してくれて
かつ値段に比例してスピードが上がるのではなく、
皆が自由につかえるのが一番だと・・・思う。
0891デフォルトの名無しさん2005/11/06(日) 01:32:25
>>882 >>888
おまいら自身はどこですか？
0892デフォルトの名無しさん2005/11/06(日) 01:32:39
>>882 ﾜﾛｽ
>>888 ﾂﾏﾝﾈ
0893デフォルトの名無しさん2005/11/06(日) 01:33:44
>>878

たとえばさ、

A:「俺が今作ってる言語では、Rubyみたいに文末のセミコロンが省略できるように
　しようと思うんだけど」
B:「やめとけやめとけ。JavaScriptでも失敗した構文だって言われてるし」
信者:ムキー!!!

A, Bまでは十分にこのスレの主旨に合ってると思うんだけどな。

結論：「信者が悪い」
0894デフォルトの名無しさん2005/11/06(日) 01:34:24
Haskellレベルの型推論器を作るのってどのくらい大変ですか？
0895デフォルトの名無しさん2005/11/06(日) 01:34:46
とりあえず Ruby と Lisp と Forth は禁止な w
このスレはこの、自由に語りあってくれ厨房言語以外のネタで www
0896デフォルトの名無しさん2005/11/06(日) 01:35:17
>>895
RubyとLispはわかるとしてなんでForth？
0897デフォルトの名無しさん2005/11/06(日) 01:36:18
A:「俺が今作ってる言語では、Rubyみたいに文末のセミコロンが省略できるように
　しようと思うんだけどどうやったらできますか？」
アンチ:「やりかたなんかしらんがやめとけやめとけやめとけやめとけ！！！」
信者：「ムキーーーー！！！」

だったような。
0898デフォルトの名無しさん2005/11/06(日) 01:37:04
知ってる単語並べただけでしょ
0899デフォルトの名無しさん2005/11/06(日) 01:37:22
Forth 信者きたよ www 信者は退場してください
Forth はどこにも使われてないだろ？せいぜいブートしたときとか細い用途で
実際コンパイラ作成にもスクリプト言語にもつかわれてないじゃん
なんか日本語もどきの糞言語があったけどな www
0900デフォルトの名無しさん2005/11/06(日) 01:37:28
エンジンスレなのにRubyがダメって分けわからーん。
エンジンにしては内部のコードが綺麗と評判じゃん。（特定のものが異様な無理をしてるけど）
0901デフォルトの名無しさん2005/11/06(日) 01:38:05
最初はおぼろげな記憶しかないんだけどさ。
確かこんな感じだったと記憶。

A:「構文解析や字句解析の話題ばっかりだね」
B:「Lispならそんなのいらないのに」
アンチ:ムキー!!!

まあ、過去ログ見ればわかるんだけどなー。
0902デフォルトの名無しさん2005/11/06(日) 01:38:28
>>896

lisp信者よりもっと強烈だから。

Forthでなんでも出来ると主張し始めたら止まらない。
0903デフォルトの名無しさん2005/11/06(日) 01:39:10
実際Forthで何でもできるの？
マクロでLispインタプリタとか出来ちゃったり？
0904デフォルトの名無しさん2005/11/06(日) 01:39:22
バカだね。Ruby の内部が綺麗？信者は救いようがないな wwwww
構文木をそのまま実行する前世代的なアレが信者フィルターには「綺麗」？ w
0905デフォルトの名無しさん2005/11/06(日) 01:39:46
>>900
綺麗というか、setjmpとlongjmpを使いまくって
内部のコード(C)もRubyっぽく書けるように設計してあるんだよね。
だからもともとRubyが好きな人には評判がいいんだと思う。
0906デフォルトの名無しさん2005/11/06(日) 01:41:55
>>903

私は信者ぢゃないけど、Cより低レベルな言語だから何でも出来ると言うのは嘘ぢゃない。
0907デフォルトの名無しさん2005/11/06(日) 01:42:38
>>902
途中で紹介されたリンク先の文章でも LISP は良く知らないけど FORTH のほう
がスゴい!! と信者的妄想炸裂だったなどっちも 50 歩 100 歩の糞言語なのに www
0908デフォルトの名無しさん2005/11/06(日) 01:43:02
>>906
なんだそういう意味でか。
0909デフォルトの名無しさん2005/11/06(日) 01:44:06
アセンブラのほうがもっと何でもできるぞ
09109052005/11/06(日) 01:45:14
>>904
構文木をそのまま評価すれば、
インタプリタのソースコードはシンプルになるんじゃないですか？
遅いけど。
0911デフォルトの名無しさん2005/11/06(日) 01:46:50
アセンブラは移植しにくいですね
0912デフォルトの名無しさん2005/11/06(日) 01:48:05
FORTHはアセンブラと同レベルだから
なんでもできるは否定しないけど、なにもできないも否定しない
0913デフォルトの名無しさん2005/11/06(日) 01:48:36
>>907
熱狂的信者がいて、それに耐えられないこいつが貶しているということは、
結構凄い言語かも知れんな。
Forth。
0914デフォルトの名無しさん2005/11/06(日) 01:49:20
RubyはIBMでJavaの補助ツールとして使えると紹介された実績もある。
ニーズがある言語は良い言語だ
0915デフォルトの名無しさん2005/11/06(日) 01:49:39
Forthはメジャーな言語。PDFとPostScriptがある。
0916デフォルトの名無しさん2005/11/06(日) 01:50:51
まあ、俺から言わせて見ればここで話題になる言語なんざ、ニーズがありまくりの超メジャー言語
ばかりだよ。
0917デフォルトの名無しさん2005/11/06(日) 01:50:56
Forthは熱狂的な信者というより
頭がアレな信者(Forthの作者含め)が多い
0918デフォルトの名無しさん2005/11/06(日) 01:52:49
>>910
Ruby 信者必死だな ww 遅いってわかってるのに？ 未だにバイトコード + VM
構成にできないだけなのにそれを美点と解釈するわけね。じゃぁ YARV はコー
ドが複雑になるからいらないんですか www Python とか Perl は何年前からバ
イトコード + VM 構成だか知ってる？ w おまえらが普段馬鹿にしてる PHP ですら… www
0919デフォルトの名無しさん2005/11/06(日) 01:53:41
>>917
Forthの作者ってもしかしてムーアの法則のムーア？
0920デフォルトの名無しさん2005/11/06(日) 01:58:18
>　特徴としては、構文解析が不必要。
> PostScriptはForthと同じくスタック言語であり、演算も逆ポーランド記法を用いるため言語仕様がForthによく似ている。
> Java仮想マシン仕様はForth仮想マシンの仕様をベースにしている。
>　Intel 80x87 浮動小数演算コプロセッサのアーキテクチャはForthベースであった。

結構凄いじゃん。
0921デフォルトの名無しさん2005/11/06(日) 01:58:30
>>919
違うムーア

colorForthとかいってキの字が入った実装を提案しちゃうお茶目な天文台のおっちゃん
0922デフォルトの名無しさん2005/11/06(日) 02:04:43
>>910
たかがbreakやnextのためにlongjmp使いまくっといて、シンプルも何も
ないもんだと思うが…
Cのローカル変数にオブジェクトへの参照を持ってしまうもんだから、
コンサバGCにせざるを得なくなっているし(その分、拡張ライブラリが
書きやすくなっているのは確かだが)。

初心者が勉強用に構文木実行タイプの言語を作るのは止めないが、
やっぱり美しくない構造だと思うよ。
0923デフォルトの名無しさん2005/11/06(日) 02:06:31
Rubyが出てきたら急に生き生きと叩きだしたなｗ
0924デフォルトの名無しさん2005/11/06(日) 02:06:47
ForthってFourthにしたかったんだけど、
システムの制限で5文字までしか入らなくてForthにしたんでしょ？

といらないマジレス
09259052005/11/06(日) 02:07:19
インタプリタを対象言語風に書けるようにマクロや型を定義する、
というアイデアは面白いと思ってます。その恩恵は、
>その分、拡張ライブラリが書きやすくなっているのは確かだが
の通りです。あと、インタプリタ自体のハックも。

そもそも言語設計を考える研究段階では、
構文木の評価にしておくことは悪くないと思います。
Rubyはいつまでその段階なんだ、という主張ならわかりますが
それはスレ違いでしょう。
0926デフォルトの名無しさん2005/11/06(日) 02:11:44
煽りでもいいからforthについて語ってくれよ…
http://pc8.2ch.net/test/read.cgi/tech/1073673931/l50
9/11から書き込みねえよ…
09279222005/11/06(日) 02:13:21
>>925
>インタプリタを対象言語風に書けるようにマクロや型を定義する、
>というアイデアは面白いと思ってます。その恩恵は、
>>その分、拡張ライブラリが書きやすくなっているのは確かだが

922で書いた「拡張ライブラリが書きやすくなっている」というのは、
単にGCについてだけで、
「インタプリタを対象言語風に書けるようにマクロや型を定義する」
ってのは関係ないと思うんだけどな。

念のため書いとくが、俺は918とは別人ね。
09289052005/11/06(日) 02:17:28
>>927
あ、文脈無視して参照しちゃいましたね。すみません。

Rubyが好きな人にはRubyの拡張ライブラリが書きやすい、
という形に持っていってるのがうまいというか、面白いなーと。
もちろんこれは、他の言語にそのまま適用できる話だとは思いません。
0929デフォルトの名無しさん2005/11/06(日) 02:18:18
PHP extensionは便利だお
0930デフォルトの名無しさん2005/11/06(日) 02:19:51
> アイデアは面白いと思ってます。
Ruby はねわざとバイトコードな実装にしないの…
構文木をね直接評価するの…

> 悪くないと思います。
GC やスレッドがねアレだけど大丈夫なの…

研 究 段 階 だ か ら

信者が自分を納得させるための言い訳だな www
一人前なのは言い訳と PHP を叩くときだけですか ww
09319052005/11/06(日) 02:31:22
えーと。私の意見は
「構文木を評価する形で実装してみることは
通常の言語設計では、一回は必要な作業だ」、です。
そのまま実用に持って行くかどうかは
意見のわかれるところでしょう。
んで、そのサンプルコードとして
Rubyは悪くないんじゃないかと。(やや古いけど)解説本もあるし。

これと>>928は全く別の話のつもりでした。

>>929
PHPも拡張の工夫があるんでしょうか。
面白そうなので調べてみます。
0932デフォルトの名無しさん2005/11/06(日) 02:31:27
>>930
お前はRubyを叩くときが一番輝いてるよ
0933デフォルトの名無しさん2005/11/06(日) 02:32:22
>>905がいい人すぎて可哀想だ
0934デフォルトの名無しさん2005/11/06(日) 02:55:30
>>930が寝たら一気に止まったな…マジで自演なノカー
0935デフォルトの名無しさん2005/11/06(日) 03:29:19
スレが伸びてると思ったらメタな言語対決話で盛り上がってただけかよ
0936デフォルトの名無しさん2005/11/06(日) 06:10:04
一応VM型も構文木型も両方作った事あるのですが、ここで言われているように
構文木を辿る事自体がそんなにオーバーヘッドになるんでしょうか？

自分で作った時は構文木のトラバース自体のコストは全体のごく僅かで、殆ど
のコストは中間生成オブジェクトの生成とGC用の管理コストだったように思っ
たのですが、、、

確かに構文木を再帰的に辿る方式は注意して作らないと評価ルーチンに入る度
にスタックに自動変数で生成されてしまいがちになるというのはあるかとは思い
ますが単純なデータ構造ではPerlの評価ルーチンと比較してもそれ程悪化はしない
ように思いましたので少々疑問に思い書き込みさせて頂きました。

後PerlとRubyでは扱う内部データ構造の複雑さが全然違う(Perlの場合単純な
オブジェクトをリファレンスで管理するのみで関数コンテキストなども明示的
に生成する、Rubyの場合は一応ちゃんとしたオブジェクト構造のデータ+Mark Sweep型GC)
のでアロケーションコストも全然異なる為、構文評価方式だけでは速度は論じ
られないように思うのですが、間違ってますでしょうか？
0937デフォルトの名無しさん2005/11/06(日) 06:33:21
>>936
お前の作ったVM型とやらの質が悪いだけじゃないのか？
効率はまったく違うと思うぞ。
0938デフォルトの名無しさん2005/11/06(日) 06:51:28
>>937
確かにその可能性もあるかと思います、VMタイプのものは特化型の言語
だったので余り正確では無いですが、関数呼び出しなども含め同一
アルゴリズムの評価では大体Perlの1.5倍、演算効率では4〜5倍程度
の速度でした。

後は構文木を辿る形式でECMAScriptを実装した時は大体同一構文
の構文木のイテレーションのみでPerlの0.8倍程度、それに対し
最終的にはオブジェクトの生成コストやクロージャのサポート
コストが実行時間の大半を占めた結果になりました。

ただVMタイプで汎用言語を実装していない為、他に構文木を辿る
設計でオーバーヘッドになり易い個所などご教授頂ければと思い
936を書いた次第です。
0939デフォルトの名無しさん2005/11/06(日) 07:07:56
>>938
何言ってるのかよくわからんのだけど。
なんでPerlと比較してんの？
ちゃんとVMと構文木で比較できる状況を作って確かめてみれば？
0940デフォルトの名無しさん2005/11/06(日) 08:32:02
>なんでPerlと比較してんの？

Perlと比較したのは比較的シンプルな実装を持った言語である程度の速度
が確保できており、評価過程でそれ程複雑なObjectを生成していない言語
である為、構文実行コアの引き合いとして良いと思ったからです。
また説明する時具体的なものを引き合いに出す方が説明し易いと思った
からです。

>ちゃんとVMと構文木で比較できる状況を作って確かめてみれば？

ええ、それで実装データ型が値,配列,文字列のものについて確かめた所
では上に挙げたように倍程度違いました(ここまでは同機能) ただここから
一般的なオブジェクト+GC言語を実装した場合、全体の実行時間への寄与は
オブジェクトの生成コストの方が遥かに大きく、最終的に構文木であるか
VMであるかが速度に与える影響は相対的に小さなものに思えました。

またこの際、構文木方式で作成した言語であっても処理系によってはほぼ同等の
言語仕様のオープンソース言語でバイトコードを採用しているものと比較して高速
であるケースもあり(ソースを読んだところその言語はバイトコード部分には問題
無かったもののオブジェクトの管理やGC部分に問題があるように見えました)

Rubyが遅いのは構文木を直に辿っているからという話に若干疑問を持ち(別に
Ruby信者という訳ではありません)丁度上で展開されていたPerlとRubyの比較
でその部分がクローズアップされ、Rubyが遅い事の元凶であるとの主張がなさ
れていた事、それに対しRubyとPerlではインタプリタでサポートされるデータ
型の複雑さが全然違う為、本当に上で論じられている部分がボトルネックに
なっているのか知りたいと思った次第です。
0941デフォルトの名無しさん2005/11/06(日) 08:37:57
そんなに気になるならRubyのソースをいじって計測してみたら？
0942デフォルトの名無しさん2005/11/06(日) 08:39:35
長くなってしまいましたが、要点としては
構文木とVMの方式では確かにその部分の実行効率は変わるのだがRubyの
サポートするデータ型を想定した場合に、先の議論で展開される流れで
言われるようにその部分がそれ程重要な要素なのでしょうか？という質問
です。
0943デフォルトの名無しさん2005/11/06(日) 08:41:47
>>941
それをやりたくないから質問させて頂きました、先の議論の方が答えをご存知のようでしたので
0944デフォルトの名無しさん2005/11/06(日) 09:25:35
>>942
最適化の有無とかも絡んでくるから一概には言えないんじゃないの。
ただ変換しました、ってだけではそれほど差は出ないと思う。
Rubyの場合だとメソッド探索が遅くなる原因の１つとして知られている。
メソッドの型を動的に判定してるから下手にブロックをインライン展開するわけにもいかず、
言語仕様でも変えない限り探索のキャッシュのような消極的対処しかできない。
0945デフォルトの名無しさん2005/11/06(日) 09:31:51
　　　　　　　　 　 　 ／　　　 , 　 　 　　｀ヽ.
　　　　　　 　 　 　/〃//,. ,ｨl/|l ﾄ､ !、 、　 ヽ
　　　　　　　 　 ｰ'´| | l |1 | !l. ｌ| ! | l.|ヽ ! !､　',
　　　　　　 　 　 　 YﾚV!ﾋｴ「! |l.「_ト!Ll」| ｌ ｌ　 l
　　　　　　　　　　　! lﾊｲJ |　　´|_jヽ. ﾘ,! ! l. ｌ |
　　　　　　 　 　 　 |l |l.} ー , 　　Ｌ _,ﾊl.ｌトｌ ｌ. | l おじちゃんたち休日なのに2chなの？
　　　　　　 　 　 　 |l ｉｌﾄ､ 　 ｎ　　'' 　,1ｌ|ｨ| |l l |
　　　　　　 　 　 _　二,ニ^tュ--ｪ_t１」l.|l !リ|_lﾉ
　　　　　　　ｒ７´　　 ｆ ｒ┐| 〔/ミヽ>,-､￣´
　　　　　　　Y 　 　 　 ー个‐'t　 ﾊ-､_'ゝ、
　　　　　　　 ヽ ．＿･ ｒく￣ヽト-'丿 　ヽ l　　　　　　　　　っていうか流れ早すぎ
　　　　　　　 / (･_＿,）ゝi┬'´ﾊ｀ 　 　　'`|1
0946デフォルトの名無しさん2005/11/06(日) 09:36:49
>>945
休日”だから”2chなの
0947デフォルトの名無しさん2005/11/06(日) 09:41:20
ようやくLispの話題からはなれたかw
0948デフォルトの名無しさん2005/11/06(日) 10:02:11
>>944
Ruby終わってるな
09499472005/11/06(日) 10:11:36
こうやって蒸し返して自演叩きしてやるぜ ww
Ruby も Lisp も Forth も俺の的じゃねーぜ www
次の餌食はなんだ？
0950デフォルトの名無しさん2005/11/06(日) 10:14:52
>>944
>メソッドの型を動的に判定してるから下手にブロックをインライン展開するわけにもいかず、

ブロック(メソッド本体？)をインライン展開するようなスクリプト言語があるの？
バイトコードにした後のJIT最適化？
0951デフォルトの名無しさん2005/11/06(日) 10:15:39
Perlはインライン展開してたと思うけど。
09529472005/11/06(日) 11:11:49
947!=949
だからな、念のため。
0953デフォルトの名無しさん2005/11/06(日) 11:19:59
>>946
もうちょっと有意義に使おうぜってことでは。
そういうオレは今起きた。
09549472005/11/06(日) 11:22:28
947==949==952
だからな、念のため。w


09559492005/11/06(日) 11:24:52
今ママに怒られました。
後ろから見られていました。
本当にごめんなさい。
0956デフォルトの名無しさん2005/11/06(日) 11:32:52
947 == 949 の母でございます。

この度は、またしても息子がこのような発言をしてしまい、
皆様には大変ご迷惑をおかけしております。
不快な思いをさせてしまった事を深くお詫び申し上げます。
息子は幼い頃に父親を亡くし、そのショックでか内気で
陰気な子供になってしまいました。
まだ童貞のようです。
不憫に思いオナニーの仕方だけは教えてあげたのですが、
猿のように毎日毎日行為にふけるありさまです。
将来を大変心配しておりましたが、この2ちゃんねるという
サイトを知って以来、息子も少し明るくなったようです。
夕食の時には「今日コンパイラスレでね、信者がさあ…」などと、
どのように信者を煽ったかをとても楽しそうに話してくれるのです。
少しは人間らしさを取り戻したかなと思っていたのですが…
確かに息子はクズで御座います。
幾つになっても分別をわきまえずすべてが幼稚です。
生きていても世の中の役に立つ事がない事も十分承知しております。
でも、決して悪い子じゃないんです。
ただ信者叩きだけが唯一の生きがいなのです。
便乗荒しが発生すると必死に >>952 のように確認をとらないと自我が保てないのです。
どうぞ皆様、息子を暖かく見守ってやってくださいまし。
0957デフォルトの名無しさん2005/11/06(日) 11:35:18
とうとうレス埋めるだけの荒らしまで出てくるようになったか・・・
0958デフォルトの名無しさん2005/11/06(日) 11:36:16
勉強中の奴にいっとくが

主キーの定義は一つのカラムに。
内容はユニークなだけで意味の無いものにしておけよ。

参考書に書いてても伝票番号、明細番号とかの複合キーにしないように。
0959デフォルトの名無しさん2005/11/06(日) 11:36:45
こりゃまた、古い煽りを持ち出してきたな。今時誰も使わんぞ。
0960デフォルトの名無しさん2005/11/06(日) 11:38:29
Ruby って Perl よりサポートするデータ型多かったっけ？
似たようなもんなんじゃねぇの？
0961デフォルトの名無しさん2005/11/06(日) 11:41:18
たしかにここはくいつきがいいな。いっぱい釣れる。w
0962デフォルトの名無しさん2005/11/06(日) 11:51:17
Rubyソースコード完全解説
http://i.loveruby.net/ja/rhg/book/index.html
ここの14章によるとRubyはスタックを７本も使ってるらしい。
遅いのはこういった複雑性も絡んでるのでは。
0963デフォルトの名無しさん2005/11/06(日) 13:39:49
Rubyは継続持っているしな……スタックからヒープにコピーするから
遅いらしいけど……
0964デフォルトの名無しさん2005/11/06(日) 14:04:08
>>931
>んで、そのサンプルコードとして
>Rubyは悪くないんじゃないかと。(やや古いけど)解説本もあるし。

Rubyの評価器は、CPUによってはインラインアセンブラ使ってるし、
インタプリタコンパイルするのに最適化レベルを上げると
動かなくなっちゃったりするようなシロモノだからなあ。
初心者にはお勧めできない。

Rubyのインタプリタのソースがきれいだって言うけど、
それはあくまでPerlの腐れたソースと比較しての話じゃないか。
そういやRubyで書かれたプログラムは可読性が高いとも言うけど、
それはあくまでPerlで書かれたプログラムと比較しての話じゃないか。
0965デフォルトの名無しさん2005/11/06(日) 14:51:49
perlはさすがに古いだろｗ
0966デフォルトの名無しさん2005/11/06(日) 15:08:22
自前のプログラムにPythonスクリプトかRubyスクリプトかどっちか入れようと考えて、
一応ソース読めないと保守も出来んよなと思って、双方のソースを眺めたけど、
Pythonはなんとか追えたけど、ヘタレな漏れにはRubyは追えなかった。
ので、結局Pythonを組み込むことにしたヘタレな漏れでしたよと。
0967デフォルトの名無しさん2005/11/06(日) 15:25:45
Ruby のソースが可読性高いだって？
誰がそんな馬鹿なことを言ったんだ？
0968デフォルトの名無しさん2005/11/06(日) 15:39:49
文法の話はこのスレでいいのかね？

確かにRubyは可読性高くない書き方もできるわな。
自作のO(NP) のdiffプログラムは、コードの密度を馬鹿みたいに
上げたので、解読するのがけっこう大変だよ。

メッセージ連鎖も善し悪しだね。
0969デフォルトの名無しさん2005/11/06(日) 16:53:52
スレの流れを無視するが。

今作ってる俺言語は、ひとまず現状では(処理系が)実行形式単体で動くんだけど、
今、簡単なライブラリを付けようとしてて、そのライブラリを、Cで書いて組み込むのは
面倒だから嫌だと思ってる。でも、それを「俺言語」で書いて、
別ファイルに置き実行時に読み込むのは、実行形式単体で動くという
メリットを捨てることになるので避けたい。

こういうとき、.cの中に、文字列の形で「俺言語」のソースを置いて、
インタプリタの起動時にパースする、という方法を取るのは、そこそこ行われていることだろうか?
特に欠点はないと思ってるんだけど、「ダメダメそんなやり方じゃ」というような
点があれば指摘よろしく。
0970デフォルトの名無しさん2005/11/06(日) 17:00:27
漏れも似たようなことやった。
が、漏れ言語の場合、スタックマシン型の中間バイトコードを持ってたので、
そのバイトコードのHexダンプをunsigned char[] にして渡してた。
0971デフォルトの名無しさん2005/11/06(日) 17:05:29
>>970
>スタックマシン型の中間バイトコードを持ってたので、

いやあ、俺言語は上の方で叩かれてる構文木実行タイプなので、
バイトコード持ってないのよ w
でもま、「んなことやったら笑われる」ってレベルでおかしなことではない、
ってことでいいのかな。
0972デフォルトの名無しさん2005/11/06(日) 17:38:20
>>964
最適化レベルを上げて動かなくなるというのは、
コンパイラ側の問題だと思うが？

馬鹿か？おまえw
0973デフォルトの名無しさん2005/11/06(日) 17:40:52
>>971
クスクス

まぁ、情報科出なら笑われるかもw
09749712005/11/06(日) 17:52:22
>>973
で、対案は?
0975デフォルトの名無しさん2005/11/06(日) 17:55:28
しっかりライブラリまで作りこむしか、考えられんな。
0976デフォルトの名無しさん2005/11/06(日) 17:58:11
>>972
なんかわかりやすい馬鹿がいるなあ…
しかもわざわざageで書いて、自分の馬鹿っぷりを晒してるし。

http://www.amy.hi-ho.ne.jp/~lepton/program/prog/prog20.html
|「このプログラムは、必ずデバッグオプションを付けて、
| 最適化レベルは"2"でコンパイルして下さい」
|「どうして?」
|「いや、そうしてもらわないと困るんです」
|「リリース版なんだからデバッグオプションはだめだよ。
| なんで、そうしなくちゃいけないの?」
|「そうしないと、プログラムがSegmentation faultでこけるんですよ。
| なんででしょうねぇ・・・」

まあこういう馬鹿はときどき見かけるのは確かだが。
09779722005/11/06(日) 18:10:11
ま，一番キチガイかつバカなのは 2ch で荒しできない可哀そうなオレだけどなw
09789732005/11/06(日) 18:11:03
俺のように 2ch でスマートに一行レスをつけて自我を満足させるw
0979デフォルトの名無しさん2005/11/06(日) 18:15:01
>>976
Rubyの場合は、GCがメモリ配置(スタックポインタとか
ローカル変数とか)に強く依存してるから、
あまり高度な最適化をされると落ちるということ。
ていうか、そんなのCでGC組んだことがあれば
誰でも体験することだと思うけど…。

で、それはそれとして、コンパイラには
バグが一切ないとでも思ってるの？
0980デフォルトの名無しさん2005/11/06(日) 18:16:06
バイトコードなくても、シリアライズした結果埋め込めばいいんじゃないの
0981デフォルトの名無しさん2005/11/06(日) 18:29:59
>>979
>ていうか、そんなのCでGC組んだことがあれば
>誰でも体験することだと思うけど…。

CでGC組んだことは何回かあるが、体験したことねえなw
そりゃ、CスタックをスキャンするコンサバGCは作ったことないけどね。

「CスタックをスキャンするタイプのコンサバGC」が一概に悪いと
言うつもりはないが、こういう実装に強く依存する方法を使った処理系を、
教材として初心者には勧められないだろうとは思う。

>で、それはそれとして、コンパイラには
>バグが一切ないとでも思ってるの？

だれかそんなこと言ったっけか?

結局Ruby信者ってこんなキチガイばかりなのか…
0982デフォルトの名無しさん2005/11/06(日) 18:38:17
>>981
>こういう実装に強く依存する方法を使った処理系を、
>教材として初心者には勧められないだろうとは思う。

じゃあ、何がおすすめ？
Rubyが教材に向いてる最大の理由は「解説本がある」だと思う。
0983デフォルトの名無しさん2005/11/06(日) 18:40:51
>>979は信者なのか？
0984デフォルトの名無しさん2005/11/06(日) 18:45:28
> CでGC組んだことは何回かあるが、体験したことねえなw
>そりゃ、CスタックをスキャンするコンサバGCは作ったことないけどね。

嘘がしらじらしすぎてこっちが恥ずかしくなってくるよ

> 教材として初心者には勧められないだろうとは思う。

じゃあ何がお勧めなんだよゆってみろよ低脳
Ruby 信者にもキチガイはおおいが、ただウザいだけのお前よりははるかにマシ
0985デフォルトの名無しさん2005/11/06(日) 19:17:11
>>984
教材に向くのはLispだと、散々既出でしょ？
馬鹿か？お前？
0986デフォルトの名無しさん2005/11/06(日) 19:26:10
>>985
オイオイ必死だな。知ったかぶりの馬鹿じゃないならおまえの作った
GC の実装をウプしてみろよ。一個でいいからさ。あーごめんごめん、
それは無理だねできないよね？作ってないんだもんね？ごめんね。

じゃぁそれは無理だろうからこっちだけでも答えてみろよ。
教材に向く Lisp ってどれよ？知ったかぶりの馬鹿じゃないなら答えてみろよ。
必死にぐぐってもいいけど普通の処理系だと気合いの入った GC なんでとても
教材には向かないよね。学生が趣味でつくった実装とかだとショボすぎだしね。
09879812005/11/06(日) 19:26:31
>>984
>嘘がしらじらしすぎてこっちが恥ずかしくなってくるよ

嘘だということにしたいのですね? (笑)
Cからライブラリとして使うタイプでひとつ(コンサバじゃないのでmallocを
代替するような形では使えない。XDRのような形で型情報を与えた型についてのみ
使える)、自作言語のGCとしてふたつくらいは書いてるよ。

君がどんな妄想に取り付かれようと勝手だけどさ、見てて恥ずかしくなるから
こういう場で公言するのはやめてくれんかね。
0988デフォルトの名無しさん2005/11/06(日) 19:27:22
この勢いは危険だ

次スレ>>990
0989デフォルトの名無しさん2005/11/06(日) 19:36:04
1から10まで完全に教材に使えて、かつ実用的な処理系なんてねーよ。
一部うまくないところを取り出して全部否定するのは馬鹿のやること。
09909722005/11/06(日) 19:44:33
>>976
一般にはプログラムのミスと勘違いされているが、
厳密に言うと最適化ルーチンが成熟していない場合が原因であることも
あるんだよ。
09919722005/11/06(日) 19:46:37
おい、俺がジスレ担当かよorz
まぁいい、ジスレではLisp/Ruby/forth/りんご/GC/LALR(1)ぐらいを
禁句にすればいいんだっけか？
0992デフォルトの名無しさん2005/11/06(日) 19:49:22
ちょｗなんでGCまで入ってるのｗ

つか、「作る話題」のスレだから「使う話題」は禁止、
でいいと思う。
0993デフォルトの名無しさん2005/11/06(日) 19:49:40
いいじゃん。別にキチガイなアンチ野郎に気ぃつかう事もあるめぇ。
禁句とかナシの方向で。
0994デフォルトの名無しさん2005/11/06(日) 19:50:53
991手遅れ。次スレ立てたよ。
http://pc8.2ch.net/test/read.cgi/tech/1131273918/l50
0995デフォルトの名無しさん2005/11/06(日) 19:51:49
>>987

> 自作言語のGCとしてふたつくらいは書いてるよ。
脳内 GC に脳内自作言語かよ。おめでてーな。まぁ見せてみろ。話はそれからだ。
0996デフォルトの名無しさん2005/11/06(日) 19:52:52
>>990
>厳密に言うと最適化ルーチンが成熟していない場合が原因であることも
>あるんだよ。

だから何?

>最適化レベルを上げて動かなくなるというのは、
>コンパイラ側の問題だと思うが？

ってことにはならんだろ?

必要条件、十分条件からやり直したほうがいいよ。君。
0997デフォルトの名無しさん2005/11/06(日) 19:55:20
どうやら脳内 GC と脳内言語でできる人間の気分になった妄想野郎だった
ようだな。人間やりなおしたほうがいいよ。君。
0998デフォルトの名無しさん2005/11/06(日) 19:55:53
1000get!!!!!!!!
0999デフォルトの名無しさん2005/11/06(日) 19:58:13
脳内 GC で 1000 GET!!!! 3 つほど作りましたが何かぁぁぁぁ
1000デフォルトの名無しさん2005/11/06(日) 19:59:01
次スレでもよろしく wwwww
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。