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

プログラミング言語処理系の開発に興味のある人達のスレッドです。

字句解析・構文解析から，データフロー解析，ループ並列化，データ分散，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 あたり

★コンパイラ一般

・色々なツールの紹介
　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/

★字句・構文解析

・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

★ごみ集め

・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

★参考書籍

・コンパイラ　原理・技法・ツール　１＆２
　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
　初心者向けの優しい解説本。

★学会

・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/
　ヨーロッパ系。派手さはないが堅実。

ということで、新スレです。

>>7
乙。中田先生の本のテンプレ、ナイスでつ。

せっかくなのでネタ振りなど。
ループ並列化とかベクトル化する前には配列の添字解析をやると思いますが、
みなさんはどういう方法を使ってますか？

私はとりあえず普通のomega testでやってますが、解析→最適化→再解析→…
と、最適化の度に解析すると結構重いです。再解析のコストを下げられるような
方法はないですかねえ。

枝刈りすりゃいいんじゃない？

記憶が定かでないが、オメガテストって枝刈りするような方法ではなかったような…

中田先生の「コンパイラ構成法」で一通り勉強し、VSMと簡単な言語の設計はそれなりに理解できたのですが、
効率的なレジスタ割付といった実際のコード生成や最適化技法など、少々物足りなく感じる箇所がありました。
そこで、次にドラゴンブックか「コンパイラの構成と最適化」に手をつけてみようと思っているのですが、どちらがオススメでしょうか？
ドラゴンブックの場合、1&2を両方揃えないと体系的な解説は得られないのでしょうか。

教えてエロい人(´･ω･`)

全部買えよ

そういう用途なら「コンパイラの構成と最適化」が良いと思う。
これの後半は代表的な最適化手法の論文紹介になってるから。

>>9
その手の問題はどうしようもない気がするなあ。
気象庁向けとかなら、コンパイル時間は1時間くらいなら我慢してくれるはず。

>>13-14
ありがとうございます。
流石に両方買うとなると安月給の私には結構な出費なので、
>>14氏に従ってコンパイラの構成と最適化を買ってみたいと思います。

# この手の本は書店で内容を吟味できないのが辛いですね・・・

>>16
JUNKDOなら朝行って夕方まで読み込んでから買えるよ。

中田先生の本にはオメガテストも載ってたね。
旧日立の人だけあって、あの辺には強い。

初歩的な質問で申し訳ないんですが、Cで書く場合、識別子などを記録するためのハッシュはどのように実装するのが賢いですか？
自前でハッシュ関数やハッシュ表の生成などを書くべきか、それとも良いライブラリ等がありますでしょうか？
また、ハッシュ関数を書く場合はどんなアルゴリズムが適していますか？
namespaceのような階層化されたものを実装したいので、それに適した方法を教えていただけるとありがたいです。

大物待望論が出てるけどw
ちょっと現実的な質問になると、スルー決め込みw

>>192
階層化させるならハッシュよりも
パトリシアかトライの方が向いてる

名前空間の階層化とtrieがどう関係するのでしょうか？

>>21
なるほど。trieを使うわけですか。
ありがとうございます。

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

これは何かうまい方法をつかって克服できる問題でしょうか？
もしくは、ユーザが作る階層なんて大して深くならないと仮定してＯＫにしてしまうべきでしょうか？
欲を言えば「名前の長さ＋階層の深さ」で検索できてほしいところです。

>>23
トライだと、名前の途中のノードを持ってこれるでしょ。
検索はその途中のノードから行えば良い。
平衡木みたいな再構築をしない前提ならば、
ノードアドレス（またはインデックス）が、
そのままユニークな完全ハッシュ値として使える。

例えば
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度で済むので
階層構造を表現する場合はトライ木ベースの構造が適している。

>>23
あ、もちろんトライ木の構築は１つで済む。
１から作るなら途中ノードを抜き出したとき、
そこにデータを格納できるような実装にすればいい。
C言語のように翻訳単位などでリンケージが変わる場合は、
木を別に用意するか、単に初期化する。

ぐだぐだになってるので>>25を一部書き直す。

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

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

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


それと、トライ木の表現方法自体に色々手法があるので
最適だと思えるものを自分で選択する必要がある。
一番最適なのは赤黒木などの平衡木だけど、挿入処理が遅かったり、
木の組み換えをする影響でノード値を完全ハッシュ値として使えない
などの問題が出てくる。
この辺は複雑さ、バランスのトレードオフで選択するしかない。

>>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; /* 各識別子へのポインタ */
};
という感じでしょうか？
もしこれだと???にアドレスのとりうる最大値を入れることとなり、すさまじいメモリの食い方をしてしまいますね・・・。
さすがにこんなのではないと思うのですが、よかったら検索の行われ方やノードの構造あたりを教えてもらえませんか？
すみません、かなり勘違いしてしまっていると思うので、よろしくお願いします。

あと万一誤解を与えてしまっていると申し訳ないので、一応確認しておくと、
（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
  }
}
というように、「指定階層から上方向にたどり、いちばん初めに見つかったもの」を検索結果としたいのです。

>>29
namespace毎に、
ハッシュ表と、親のnamespaceへのポインタ
を持っとけばいいんじゃない？

ns1::ns2::ns3::foo のときは、まず ns3 のハッシュ表を foo で検索してヒットするのでそれ。
ns1::foo の方は、最初に ns2 のハッシュ表を検索しても見つからないので、親のns1のハッシュ表を検索。
ns3::foo は、ns2 のハッシュ表に ns3 は名前空間でそれのハッシュ表はどれという情報が入っていて、ns3のハッシュ表を foo で検索して発見。

>>30
元々はまさにおっしゃる通りの方法で、namespaceごとにハッシュ表に識別子を登録する形でやるつもりでいました。
それで最初の質問が>>19だったんです。
そこでtrieを使う方法が適しているという意見をいただいたので、それについて質問しているところでした。

ところでハッシュを使う場合ですと、ハッシュ関数はどういうアルゴリズムを使うのが良いでしょうか？
（この質問は>>19でもした質問でした）
また、ハッシュ関数そのものも去ることながら、namespaceごとにハッシュ表をつくるとかなりメモリを食うことになると思うのですが、どのように対処すべきでしょうか？

よく見たらsageて質問してましたね。
すみません、ageさせてもらいます。

sage で質問しちゃいけないというルールは微塵も無い

>>19
オススメかどうかしらんがCのライブラリならrubyの中のst.c
/* This is a public domain general purpose hash table package written by Peter Moore @ UCB. */
なのでライセンス的な問題ないし。

やはり、最後はいつもRuby。
後発有利？

いやrubyはちょくせつかんけーない
rubyもどこやらから持ってきてるんだけど一時配布元がわからんかったので

>>31
今時のマシンだったら、よっぽどアホなことしない限り、
速度もメモリ消費も問題にならない。
適当に教科書写したり、
>>34みたいなの探して使え。

> written by Peter Moore @ UCB.
UCBはやはりバークレーなのかな。

>>35
後発が有利なのは確か。

先発をインスパイアするからなぁ。

>>34
どうもありがとうございます。参考にさせてもらいます。
導入してみて問題なければそのまま使うかもしれません。

yaccとかraccとかでは、文法ファイルをこんな感じで書きますよね。

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

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

プログラムコードの中で他の '}' がでてきても、yaccやraccは自分の '}' をちゃんと検出しています。
この仕組みがすごく不思議なんですけど、どうやってるのか教えてください。

>>42
> とてもそうは思えないんですけど
why?

>>43
ええっ、解析しているんですか？
それって、yaccはCのパーサを丸ごと内蔵していて、raccはRubyパーサを丸ごと内蔵しているってことですよね。
とてもそうは思えないんですが。パターンマッチとかじゃないんでしょうか。

>>42
bisonあたりのソース見てみれば？
おいらは構文解析くらいはしてると思うけどね。

少なくともBNFの記述に使われるトークンぐらいは解析してるとｵﾓ

直感的には、意味は解析せずとも、構文くらいは解析するだろうと思う。たいした手間じゃないし。

自分のおつむの程度でyaccの作者のレベルを量るなよ。
それにしても極端だな、中間の{,}の数を数えているとかは候補に上がらんのだろうか。

で実際にはyaccは括弧の対応(とCのコメントと文字列)を見てる。
bisonはよく知らん。

>>45-47
こんなインチキ文法ファイルが通るから、Cの構文解析なんか絶対してないはず。

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

raccも同様だった。

>>48
それか。どうもありがとう。
コメントと文字列と、あと文字も見なきゃいけないよね。

実はその方法も考えたんですが、raccだと正規表現やら%r{...}やらいろんなことを考慮しなきゃいけないから
それもないだろうと決め込んでました。がんばれば何とかなるのかな。

ソースを見れば分かる話では・・・

raccは適当に解析してるようですよ。
ttp://i.loveruby.net/ja/rhg/fin.html
でもそれなりに動いててすげえなあと思います。

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

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

>がんばれば何とかなるのかな。
Rubyならripper使えばなんとかなるのかな

LISPならその辺何もしなくて良いので楽です。

>>58
先発

関東では、「つぎ」「このつぎ」「こんど」のどれかw

>>58
ｶﾞﾝｶﾞﾚ

MinGW上でBison++1.21.8＆Flex-2.5.4a使ってるんだけど
C++用に生成させた複数のパーサ＆レクサ（って言うのか）を使ってるときに
なぜかあるパーサが違うパーサ用のレクサを使ってしまうという現象に悩まされています。
同じ目にあったことある人いる？
ちなみにflexのソースには%option prefix=hogehoeを指定しています。
nmコマンドでオブジェクトを見るとちゃんと別々のレクサが生成されているようだけども…。

>>53
Lisper

>>57
たぶん小物w

やっぱり最初はLISP作ることにします。
ありがとうございました。

やっぱり最後はRuby作ることにします。
ありがとうございました。

LLVM, SUIF, Trimaran, Zephyr, COINS ...
といろいろありますが、それぞれの向き／不向きとか使いやすさとか実際に使っている人が
いたらいろいろ情報キボンヌ。

>>56は悩ましい1週間のデバッグの末ようやく解決した。

両方のパーサの*_y.hがincludeされてるソースが存在した。
両方のマクロ定義とinline関数定義が干渉したらしい。
オリジナルを書いたフランス人曰く
「Linuxでは動いているからMinGWのリンカのせいではないか？」
などと言っていたが、むしろLinux上で無事動いてたのがむしろラッキー？
という感じの立派なバグだったようだ。

>>62
ファイル名のキャピタライズのせいだったりして（実は違うファイル名:linux,実は同じMinGW）

>>61
情報はあるが、「キボンヌ」とか言ってる奴に答える気はしない。

>>63
綴りも全然違うのでそれはない。

単純に.hファイルのインクルードの連鎖の結果で2組のパーサ＆レクサの定義を含む.hファイル2つが
一個のファイルにインクルードされて利用された結果、マクロ定義が衝突して、
（FlexにC++コードを生成させたときのマクロの利用方法は少々トリッキーなので）
同じであるべきinlin関数についてコンパイル単位ごとに複数の異なる版
（正しい版と別のパーサ用のレクサにすり替わった版）が生じたことによるもの。
Linux版で動いていたのは複数の異なる版を持つinline関数という
規格上未定義である状況に対するコンパイラの挙動の違いで偶然正しく動いていただけ。

>>63
あ、でも移植作業初期にはそういうトラブルもあったですよ。
MinGW環境からLinuxファイルサーバにsamba経由でアクセスしてるときに
同一ディレクトリ内に大文字小文字違い以外全く同一のファイル名のファイルがあって。
（ソースにそういう紛らわしい名をつけるのもどうかとは思うがｗ）


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

で、C++で書かれているSUIFという意見もあったが
Javaで書かれているCOINSを使おうと思っている。
Javaならクダンのフランス人が好きなGCも動的ロードも言語が標準で持ってるし、
SAXパーサもJavaの方が本家だし、
Unitテストやリファクタリングをサポートする開発環境Eclipseもあるし、
Rubyとも多分縁が切れるし、移植に悩まなくて済みそうだし、
何より今の壊れ物C++＆Rubyコードがそのまま持ち込まれる可能性が低いｗ

>>66
是非coinsの会員になってください。
製品にcoinsを使いながら、たくさんあるバグや未実装部分を解決してくれると嬉しい。

コインズって名前なんとかならんかな。
小銭とって細々やってるイメージしか沸かないんだがw

でも、あれだけやって gcc に敗けてるのは不思議。
gcc の優秀さが伺われる。おそるべし

別に不思議でもなんでもない。
ストールマンをはじめ、MITのエースハッカーたちが寄ってたかって
何年もかけて作り上げたものに勝てるわけないじゃん。

>>69
やってみなきゃわからん

>>67
実はすでに幽霊っぽい会員だが・・・

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

かなり特殊なバックエンドのためのフロントエンド＋汎用っぽい最適化部
として考えてるからあんまり普通のコンパイラの機能が未実装多いと困るなぁ。
COINSのためにまだ1行も書いてない今ならまだ間に合うか・・・SUIFにするか？！

学校の演習で使ったが、未実装たくさんあったぞ。
cfrontですら未実装で四苦八苦してる始末。
あと、最適化なんて目も当てられない。

>>72
うーむ。

・時期はいつごろのこと？
（一応今年の3月までがそのプロジェクト本来の研究期間だったような…。）
・演習用にわざと虫食いにしてあったという可能性は？
（完成してたら演習にならないから。）

>>72
最適化ならテンプレに良書があった筈
紹介してあげたら？

Lisperより

>>73
迷わず行けよ。行けばわかるさ。

いや、ここはひとつ日本のcompiler業界のために頑張ってはくれまいか。

>>74
テンプレにのっている日本語の教科書の著者の半数がCOINSに関わっているんだが？

俺もCOINSを薦める。COINSは研究として面白みのある部分以外はまだまだ手薄なので、
泥臭い部分を仕上げる企業人が必要だと思う。

>>75
実績作らないとイカンので、今のプロジェクトから逸脱しない範囲で
論文のネタが拾えるなら行ってもいいんだけどな・・・。
ただの実装では論文のネタにならんからなー。

>>73
・時期は今年の4月以降。
・後者の可能性はない。

まあダウンロードしてファイル読めばだいたいわかるし、テストコード書いて
吐かれたアセンブラ見ればわかる。

>>77
ところが企業じゃなくて一応は公費が使われてる研究所なんだよなー。
その上プロジェクトのテーマはコンパイラの技術は必要としているが、
コンパイラそのものではない。

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

もっともコード生成部こそはウチのプロジェクトでまさに作りたいところなんで、
問題がそこらあたりならばまぁいいんだけどね。
ただ、そのコード生成部はあまり一般CPU向けではなかろうなぁ。
それに初手ではトランスレータとして実現するつもりだし。

>>80
キーワードは次のうちどれ?

1. reconfigurable
2. energy consumption
3. multi-core
4. cell
5. DSP
6. hetero cache

>>81
のーこめんとでｗ

>>80
どんなコンパイラ作るのか知らないけど、cfrontについては/test/c/report.txt見れば
未実装部分はだいたいわかると思う。
なんか、cfrontを作るために、汎用的なHIRじゃなくて、HIR-Cをわざわざ作ってたり、
fortranもどうも特殊なことしないと作れないっぽいし、駄目駄目な印象しかないんだがなあ。

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

>>81
本命1、対抗2ってとこかな．
3や５は企業しかやらないんじゃない？

構文解析器ってどうしても再帰的な処理になるから
どこでエラーが出てるのか、デバックが難しいんですけど
みなさんどうしてます？

字句解析の時点でトークンにファイル名と行番号を持たせる

流れを無視して悪いが>>70がいいこと言った

>>70
というか思考実験もせずに文句言う奴最近おおいと思う。

>>85
デバッガを使う。

>>85
何らかの形でログ出力。

>>89
デバッガ使うような言語じゃないのです。。。

>>90
やっぱりそれですかね。

ふつー86

>>85は構文解析器のデバッグをしたいのか、それで作った言語のデバッグを
したいのか、どっちだ?

何々?手書きしてるの?
yaccとかなら.outputみれば簡単よ

>>86
行番号まで持たせるって、一般的ですか？

86じゃないけど一般的。
エラー出力のポリシーによるだろうけど最低限リテラルや変数名には
持っておかないと正確なエラー情報が出せない。

>>96
勉強になりました。ありがとうございます。

＞構文解析器のデバッグをしたいのか、それで作った言語のデバッグを
＞したいのか、どっちだ?

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

セミコロン区切り式の言語で、「文にセミコロンがありません」みたいなエラーってどうしたら出せますか？
Bisonの構文解析で「そこにセミコロンさえあれば正しい文法だったのに・・・」みたいなことは検出できるのですか？
多くのコンパイラ・インタプリタはその辺妥協してシンタックスエラーとか、予期しない〜ですとか言うだけなようですが、何とかして親切なエラー出力がしたいのです。

Syntax ERROR: 予期しない〜が出現しました。(もしかしてセミコロンがなかったり……)

>>100
レスどうもありがとう。
ナイスなアイデアだけど、どのシンタックスエラーだとセミコロン忘れな「可能性がある」のかすら判別できないヘタレな漏れです。
全ての構文エラーにセミコロンがなんちゃらって入れるのちょっとしつこいし・・・。
むつかすぃ

>>99
コンパイラがプログラマの意図を察しないと行けないから
完璧には無理だろうね。

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

小さな親切大きなお世話になる気がするよ。

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

実際BCCなんかは、そのものズバリ「ステートメントにセミコロン（;）がない」と言ってくれます。
（gccは欠けたセミコロンの直後のトークンで、symtax error before 〜 しか言ってくれません。）
とりあえず、BCCのように正しく検出してくれる実例があるので、何とかなるのではないかと考えたのですがどうでしょうか？
もしかして、かなり特殊な手法が必要？

あ…しまった勘違い
x = y * z = 1;
って文法通らないですね…

ちなみにBCCだと
「左辺値が必要」
という、至極真っ当なエラーを出します。
いったいどうやって実現してるんでしょう？

煽りじゃないけど、正しいエラーを出してるんじゃなくて、
あなたが、典型的なミスを侵していて、それにそのまま当てはまっているだけだとおもう。

むしろ、gccの方が厳密で正しいと思われ。

マイクロソフトのコンパイラもそうだけど、
適切なエラー報告してくれるコンパイラは
生成系使ってないんでない?

再帰下向きならこの手のエラー得意だし。

ベンダーに限れば、生成系使わずに、独自に実装しているだろうね。
生成系を使いこなせていれば、あるていどのエラー処理は行えると思うけど。


例えば、文中にいきなり "キーワード if " が現れたら、セミコロンの有無を俺は疑う。
適当にやるのなら、この程度でいいんじゃないか？

>107
論理が飛躍してないか？

JavaだけどEclipse最強のエラー訂正。
C++は遥かにむずかしいだろうけど。

>>109
>>107ではないが、全然してないと思うぞ

>>111
そうかなぁ
少なくとも生成系云々のくだりは俺も飛躍を感じるけど。

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

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

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

>>110
Eclipseってそんなにエラーの出し方スゴイんですか！こちらもちょっとリサーチしてみます。

あれ、もしかして「生成系」ってbisonやyaccのように構文解析器を生成するたぐいって意味でしたか・・・
ちょっと113で的外れなこと言ったかも

適切なエラーが出せるんだったら、ソース自動修正とかできそうだなw

MS製品は自動修正あるよ

改行された箇所でシンタックスエラーになったときに
セミコロンを補ってやると結構精度いいエラー訂正になりそうな予感。

そしてエラー（例えば()の対応が取れてないとか）のある
長い式の途中の改行で;を挟みさらにド嵌るというシナリオはどうか？

自動追加のできる；って単に冗長なだけと思ってしまうが。。。
なにか根本的な勘違いでもしてるんだろうか？

元々はその冗長性がプログラムのポカミスを見つけてくれるってことじゃないかと。

実際には自動追加なんてできないんだから、冗長さもポカミスを防ぐもないだろう。



ECMAScript を除いてな。

ECMAScriptって元JavaScript？自動追加してるの？>>121
----
冗長にも見える";"があることである行の構文エラーが
他の行へ波及しにくくなる効果があるんじゃないかな？

>>122
ttp://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/7_Lexical_Conventions.html#section-7.9
この仕様のせいでECMAScript(JavaScript含む)の字句・構文解析は超複雑になる。

>>123
スゲェ、決めた奴は狂ってるとしか思えん。

;をCRCか何かと勘違いしてる奴がいるなw

>>125
はて。そんなやついたか？

>>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)の区切りと見なしてくれたと思う）

>>126

>>120

>>125
分からないなら黙っておいた方がいいよ？ｗ

情報理論的にはあってるけどなw

>>125
";"を忘れたってエラーじゃなくて
";"はあるけどその行の中で何か構文エラーがある場合を考えてみれ。
例えば正しい式には";"が現れないと仮定できれば
"("と")"の対応が正しくないとかの場合でも後続の文の中に際限なく終わりの括弧を探さずとも
その文一つが間違っているだけだと結論できるだろう。
つまりエラーを局所化できるわけでエラーを見つける目的には役立っている。

いいたいことはわかるんだけど、それって;のおかげというより
構成単位を文で区切る手続き型言語の特性じゃないかな。
関数型言語ではしばしば"エラーを局所化"できず
不幸になることがある。

もし;がなかったらどんなプログラムで
"エラーを局所化"できず不幸になるか
具体例をあげてほしい。

別に;でなくても'\n'でも同じじゃないの？

>>133
確かにw

>>133
理論上は区切るものがあればよいというのはその通りで、
確かに記号は";"に限ったものでもない。";"は文の区切り記号の選択肢の一つ。
実際スクリプト言語とかは文の区切り記号に改行を使うものも多いが、
その場合長い式を書くときに一々改行をエスケープしなければならない。
（スクリプト言語の中にはシェルのように1文ごとの対話的な使用を
想定するものもあり、その場合改行が区切りというのは自然でもある。）

あと関数型でも宣言の体裁を文のスタイルにして何らかの区切り記号を使うことは可能だ。
式を中心に考えて文の意識が希薄になっているメジャーな関数型言語があることは確かだが、
文法的レベルで文を意識せず区切り記号を使わないことが関数型言語の本質というわけではない。
逆に手続き型（代入や副作用を許す）でも文なしで式だけで構成することは不可能ではない。
例えばLispで代入を使いまくるような書き方は可能だし、
Cで","演算子や三項演算子を濫用するような書き方も一応は可能だ。
（読みにくいからあえてそういう言語を実装するほどの実用性はなさそうだけれど。）

荒れるかもしれないから言語名は避けるけど
某スクリプト言語では+とか-とかの演算子や
(や,の後の改行は勝手にエスケープしてくれるよ。

ここら辺は処理系の実装の問題だと思うけど。

>>136
まぁしかし本当にエラーかも知れないので勝手にエスケープもやや微妙。

プログラミング言語は今のところ所詮は曖昧さを殆ど許容できない形式言語だから
親切にするつもりで付け加えたことだとしても
言語の挙動があまり複雑になりすぎれば結局ユーザは覚え切れなくて戸惑うし、
最近は言語本体のみならず周辺ツール
（構造を意識するエディタやリファクタリングツール）も
セットで考えることが増えてきているわけだから
そういう面からもあまりに例外の多い構文・字句規則は
トータルで開発コストを押し上げる可能性を孕んでいる。

>>136
ついでに言えば、ソフトウェアの可搬性の問題を考えると
同じ言語で環境や実装が変わるとエラーの出方がひどく変わる、
特にエラーになったりならなかったりするというのは
絶対ダメとは言わないが決して望ましいことではないから
「実装の問題」とばかりもいえない。

ECMAScriptみたいな、セミコロン自動補完という仕様とか

それはザっと斜め読みしたけど
個人的な印象では";"ごときの補完処理のために
設計・開発コストを掛けすぎてる気がしないでもない。

ただまぁ計算機の能力やツール類の進歩でコストは変わるから
将来的なエラー補完のための予備的実験って意味くらいはあるのかなぁ。

>>136
その言語すばらしい！
まさに新世代向け言語！

ECMA-Scriptの";"補完は実装も楽だし好きだけどな

>>142
時代遅れw

>>136
文末のセミコロンを省略できるようにしたり、関数呼び出しの括弧を
省略できるようにしたり、そんなくだらんことでスキャナを無駄に複雑にして、
ユーザにとっても落とし穴だらけの文法にして、その見返りに、
いったいどんな「いいこと」があるんだ?

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

# 信者がうざいので俺も言語名は伏せとく。

そこまで言ったらもう何も伏せれてねーよｗ
俺はRubyを好きでも嫌いでもないが
日本語でも「スクリプト」なら「。」はしばしば省略するぞ。
つーか明らかに価値観次第だろ。



とつっこみたいのをぐっと我慢して>>144はスルーで。

すなわち、より進化した言語ということでしょうな。
言い換えれば、よりユーザに近いということでもある。

このことは、より高級ということでもある。

>>144
セミコロン一つ付ける事には、慣れるのに時間がかかるんだよ。
漏れも昔は、文末にセミコロンを付けるのが苦手だったから、
その辺の気持ちは分からなくもない。

要するに、記述を省略する事に関するメリットとデメリットを考えるべき話題やね。
メリットは、把握すべき内容が少なくなる。デメリットは、内容が曖昧になる。

>>148
曖昧にはならんよ。

>>149
ユーザから見て曖昧ってことじゃなくて？

たしかに落とし穴だらけなんだけどなれりゃあ便利なんだな。

いまだに if f x && y とかにひっかかるけどｗ
if f (x && y) になるのね、これ。and使えってことなんだろうけど。

>>151
なに、その糞みたいな syntax。

>>144
省略といえば、こないだ初めてPerlを使ったんだが、こりゃ酷いな。
これほどクソな文法設計の言語は過去にも未来にもないんじゃないか？
いい特徴を持っているだけに残念でならない。
ということで Perlを反面教師にしてください。

でも、PerlってACMプログラミングコンテストだかなんだかで
有利な言語として有名なんだよ。
極めると凄いらしい。

VZエディタのマクロみたいだな。

ACM/ICPCはC/C++/Javaだけだぞ。

ICFPだろ。

ICFPで有利と有名なのはHaskellとOCamlとDylanだが、
Perlは初めて聞いた。入賞したことあったっけ。

有名なのはHaskellとOcamlじゃないか？
Dylanはちょっと違うんじゃないか。
Perlは確か2004のLightning Divisionで圧倒的だった。

>>152
構文糖で低血糖

>>147
FORTRANとかの行指向の言語をやった後だと文区切りが";"一つで済むのは天国。
空文が許されてればさらに極楽(Pascalは空文がなかったので編集が面倒だった)。
最近だとC/C++でプリプロセッサマクロを書いてるときやデバッグしてるときは
結構ストレス溜まる。

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

提案。
perl みたいになんでも省略可能なスクリプト言語って作れないかな。
作った自分しか使えないくらいの。

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

haskellとかでも十分短く書ける気もするが。あれは省略しているわけではないか

スクリプトの欠点
短く書ける物しか書けない→大規模なプログラムに用いると管理しきれなくなってハターン→(;´*`)ﾏﾂﾞｰ

>>163
その欠点をも克復したオブジェクト指向スクリプト言語があるんだけど、
あえて言語名はいわない。当スレでは禁句らしいからなw

lispだな

>>164
Rubyと拡張ライブラリを使って大規模なコンパイラを書かれてしまい
その移植で今酷い目に合っているのが俺だルシム
やっぱスクリプト言語はスクリプト言語。濫用はほどほどに…。

>>166
移植って言うけど、ruby.exe が移植できればいいだけの話しでは？

>>166
おまいを最近いろんなスレで見かける気がするのだが・・・？

>>162
> コードが短く書ける→よってバグも少ない
その理屈はおかしいだろｗｗｗｗ

>>169がおかしい件について

>>169
まぁでかいコードよりは物理的に少なかろうて。

perlみたいに、ただ枝葉末節を省略することで短くしても
バグは少なくならないんじゃないのか？
本質的に短くならないと。

BrainFu*k 並みに短くしたら逆に分かりにくい

BrainFu*kはちょっと込み入った処理になると正直短くないけどな…

>>167
拡張ライブラリが曲者でね。
Rubyででかいコードを書くと実行速度の問題とか
ある処理に利用可能なライブラリやツールがないなどの理由で
だんだんと拡張ライブラリとして実現されるパートが増えていく。
最初はテキスト処理のスクリプトでチョチョイと終わるはずだったコードは3年の時を経て
Ruby本体に迫るサイズの巨大な拡張ライブラリを擁するコンパイラもどきにまで育ったというわけだ。
拡張ライブラリはC(実際のウチのケースではCから呼び出されるC++コードが大部分)で
書かれているがRubyのオブジェクトやルーチンを呼ぶのでそれ単独では実行できないから
デバッグはいつもRubyごとgdbに掛けるなどして行うことになる。そしてそれはたまらなくメドい作業。
特にC++のコードがそもそもバギーだったりパーサ・ジェネレータが関与したり
XMLパーサも関与したりConservativeGCも同居したり移植先がWindowsであったりする場合は。

>>168
気のせい。別人。無関係。ということにしておいてくださいおながいします。
決して煮詰まってるからあちこちのスレで憂さを晴らしているなどということはない筈です。
信じてください。

>>175
そういうLispを使うべきところでRubyなんか使ったのが運の尽きだな。

>>175
コテつけたまえよ
あぼーんしちゃるから

>>177 ばか〜？
コテ付け必要なのは、>>176 でしょw

>>175 なんか泥沼って感じですね。
ただ、他の言語では正直そこまで持たなかったのでは？

>> 176
単純にLispを使うべきところってのを知らないんじゃないの。
僕も仕事だから仕方なくC++でコンパイラ書くのに付き合ってるけどあまりに効率悪いんで
うんざりしてきた。スケジュールもカツカツだから絶対失敗すると確信してるけど放置してる。

>>178
中途半端に持ってRubyで書かれたロジックとC/C++のロジックが分離しようもなく
絡み合ってしまう前に潔く書きなおされることになったほうが
幸せだった可能性が高くはあるまいか？

>>179
Lispもどうかなぁ。気が進まないなぁ。Lisp使うくらいならいまどきの言語である
MLとかHaskellとか使うかもなぁ。いずれにせよ読み書きできる人間が少ないけどな。

C/C++に置き換わる言語は今のところLispだけ。
Rubyなんて書き始めの頃から破綻するのなんて判ってた筈。
最初からLispで書いてれば良かったね。

ちょっと話を戻すが。

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

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

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

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

>>151が言うような落し穴を開けてまで、こんなわけのわからん文法を持ち込むことに、
いったいどんなメリットがあるのか、それがわからんのだよなあ。

182を要約するとS式マンセー、ってことでよろしいか？

Scheme! Scheme!!
でも、速い実装無いみたいだね、Scheme……

>>175
煮詰まったんならもういいじゃん。
終わったことをウダウダアチコチのスレに書き込むな。

>>182
括弧要らないのは楽だし。
つうか、別に付けてもいーんだから、付けたいならつければよいって話。
俺はあきらかに省略できるところは省略して楽してる。

どうでもいいけどさ
エラーメッセージで「；」が無いよとか言われると、
解ってんならつけて実行しろよって言いたくなるよね

>>185
最近は「行き詰った」ときも「煮詰まった」って言うんだよ。

>>184
PetiteじゃないChezって無茶苦茶速いって噂だけど。誰か真相知らない？

>>182
151 のようなケースでカッコを省略して書いたりはしないよ。読みにくいし。
演算子メソッドを自然に書けるようにカッコが省略可能になっている。
a + 2 は正式に書くと a.+(2) なもんで。
最近は DSL の作成にこのルールが役に立っていると感じてる。
DSL の例は http://onestepback.org/articles/lingo/

>>185
終わってないんだよ。現在進行形でこの深夜にもぐつぐつぐつと…。
今夜もついさきほどすごいコードが書かれているのを
発見してしまってちーとばかり脱力してるところさ。

まぁ気に入らないなら頭がオカシイ電波野郎がいるとでも思ってスルーしてくれ。
あんまり簡単に個人特定されても困るので残念ながら固定は名乗れないが。

>>188
そもそもPetiteChezの時点でインタプリタとは思えない速さだ。

>>190
> まぁ気に入らないなら頭がオカシイ電波野郎がいるとでも思ってスルーしてくれ。
スルーしたいからコテかトリ付けろや、カス。
個人特定なんか簡単にできるかよ。

ここは変な人が常駐してるので気になさらずに>190

>>190=193
自演乙

俺としちゃ190よりも、

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

コテなりなんなり付けて欲しいとこだけどな。

"Lisp" "Ruby" "りんご" をｱﾎﾞｰﾝ

>>187
低脳だけな

言葉遣いから低能云々はともかく
「煮詰まってる（>>175）」を「煮詰まった（>>185）」と勝手に過去形にしたうえ
「もういいじゃん」と一方的な感情的評価でに突き放し、
「あちこちのスレに書き込むな」と命令形で
別にスレの話題からそれほど逸脱してるわけでもないのに
特定の話題や書き手を排除しようとする心の狭さは如何なものか？
その上アボンしたいからコテ名乗れと指示するに至っては
とんだジャイアニストと言わざるを得ない。

まぁただの愚痴はマ板辺りでやってほしいところだな

>>175がへりくだって見せたから図に乗ったんだろｗｗｗ

>>199
一応流れとしては
スクリプト言語で大きなプログラムを書いてマズくなった事例なんじゃないの？
書き方は愚痴っぽかったけど。

じゃあ後でまとめておこうか。

>>201
それはそうだけど、もし C とか　lisp
なんかでかいていたら、とっくの昔に破綻してたんじゃない？

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

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

ただ、凄いとはおもうけどね。

>>203
　>>180前半。

>>196
あと、LR(1) だっけ？w

大規模なコンパイラを、将来のこと考えずに拡張を繰り返しても
大丈夫な言語なんてあるのか？

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

おっと、変な奴が出てくると困るから一応言っとくけど、
Rubyは個人的には大好きだ。

Lisp Ruby りんご

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

>>206
Lisp は、いくらなんでも選択にはならんだろw

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

変な奴の例

つ>>206-207

>>208
うん、

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

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

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

# ちなみにRubyは本当に好きです

Ruby何がそんなにいいの？

>>211
変な奴

つ210=212

>>213
ちっ、ばれたか

>>207
Lisp Ruby りんご

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

というか、基本設計の差が大きくでるように思える。
なんせ、あのアーキテクチャですからね。

美人言語処理担当っているのかなぁ。
はぁはぁ

Lisp Ruby りんご

cellの大変なところは

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

あたりか。ちょっとコンパイラ側の負担が大きすぎな気もする。

Rubyネタ、別に面白くもなんともないから
もう書かなくていいよ。

>>218
ちゃんとフィルタ用のキーワードいれてるんだから文句いうな

Lispって、学術的な意義とか歴史的な意味はすごいんだろうけど、
果して実用的なんだろうかと、ふと思ってしまう。

どういう意味で?
Windowsで使えるフリーで高速でバイナリコンパイルでき日本語も使えGUIも使える
処理系がないという意味だとか、安価な土方を大量動員できるとかいう意味では
違うとは思うけど。
普通にプログラムを書くだけだったら例えばCやPascalなんかよりずっと楽だよ。

「普通のプログラム」ってのが何かによるだろ。
ちょっとしたデータ処理を書くにはLispの方が楽だけども、
もうちょっと広義にあらゆるプログラムに対応できるという意味では
CやPascalの方が圧倒的に実用的だが。

「もうちょっと広義にあらゆるプログラムに対応できる」わけでないからといって
実用的でないということにはならないと思うけど。
PerlでもRubyでもPythonでもJavaでもいいけど、「〜ができない→その言語は
実用的じゃないね」とはならないでしょ?

まぁ適材適所だわな。
万能な言語があると思ってるのなら、夢見すぎだ。

>>221
慣れもあるのでしょうが、自分だったら全くコード書く気が起きない。
（書けないんじゃないよ。）
あと、世の中の出回ってるソフトでLispでかかれたコードに出会ったことがない。
（Lispの機能を示すために書かれているコードを除いて。）

こんな意味です。

俺の記憶が正しければ、gccのコード生成部はLispのような書き方がされていた気がするが

コード生成ルールの定義、ね

>>225
>あと、世の中の出回ってるソフトでLispでかかれたコードに出会ったことがない。

GNU Emacsかなあ。
しかし、Emacsのカスタマイズ言語がe-lispじゃなかったら、
もっと多くの人がいろんな機能を作ってたんじゃ、と思わなくもない。
つか、俺もちっこいのはいくつか書いたけど、挫折した…

昔の人工知能とかアルゴリズムの論文なんか見てるとLispっていうかS式やけに見るよ。

Emacs開発開始当時、他にろくな選択肢がなかったんじゃないかな。
Emacsが未だに生き残っていることを考えると、
その中での選択としては大正解だったと思われる。
いい加減時代に合わなくなってきてるのには同意。

vi信者に喧嘩を売ってるのかね？

形態素解析の茶筌の文法書や辞書ファイルなんかもS式だった気が

>>230
一応C言語はあったけど･･･
Cはろくな選択肢じゃないの？
それどころかむしろ、228も含めた多くの人は、C（に似たような言語）こそが一番
良かったと思ってるんじゃないのか？

何で組み込みの話してるのにいきなりCが出るんだ。

秀丸の拡張言語とかCに似てるじゃん。

Lispが言語的に優れていてもそれほど普及しなかったのは、
・計算機資源を食う
・書き手の能力を問う
の二点が大きかったから。前者は今じゃ全然問題にならなくなったから、
後者をクリアしてる若い連中が「これいいじゃん」と騒ぎ始めた。

漏れみたいな、後者をクリアできないロートル＆無能には手続き型言語で十分さ。

そう感じさせる要素が時間の経過によって様々に咀嚼されていろんな言語に現れ、
パンピーにも理解できるところへおりてきたのでかなりギャップは小さくなった
んじゃないかな。

今だと後者のふるいの役割はHaskell辺りだろうか。

>>233
Gosling emacs の Mocklisp は C like な構文だったんじゃなかったっけ。
まあ結局生き残ってはいないわけだが。

今から30年後にC言語は生き残ってるかな。
FORTRANみたいに特定分野で亡霊化してそう。

30年後は誰もプログラミングしません

>>238
よくわからんが、それはlispって名前がついてるのに
lispじゃなくてCなのか？
ただ、構文だけの話ではないの？

検索で出てきたけど
RMS Lecture at KTH http://gnu.mirrormonster.com/philosophy/stallman-kth.ja.html
＞いつかは MOCKLISP を本物の LISP に置き換えようと

ここの説明ではC LIKEかどうかはわからんな。
ともかくLISPフロントエンドみたいな言語の話ではないのね。

lispは使いもんになんねーってこと以外は優れていると思うよ

>>240
今の技術の推移速度じゃ、それは無理だろ。
IT業界のハードの発展速度は確かに凄まじいものがあるとはいえ、
ソフトウェア業界の技術の発展速度は、藻前の想像以上に遅い。

>>243
Lispに嫉妬する俺言語オーナーのスレはここですか？
ちなみに普段言語は何をお使いですか？ｗ

　　　　 ＿＿＿＿_
　　 ／::::::::::::::::::::::::::＼　　　　　 　
　 /::::::::::::::::::::::::::::::::::::::＼　　 　 　
　 |:::::::::::::::::|＿|＿|＿|＿|　　 　　
　 |;;;;;;;;;;ノ　　　＼,, ,,／ ヽ　　　　
　 |::（ 6　　ー─◎─◎　）　　　
　 |ノ　　（∵∴　（ o o）∴）　　　
／|　　　<　　∵　　 ３　∵>　　　
::::::＼　　ヽ　　　　　　　 ノ＼　　　
:::::::::::::＼＿＿＿＿＿ノ:::::::::::＼　　

>>245
事実を言っただけなのに何を怒っているの？
なにか気に障ること言った？
あっ！もしかしてキティちゃん？

>>236
苫米地英人博士が、CommonLisp大好きらしいのだが、
漏れは、CommonLispの分厚い仕様書見て引いた。
なんだ、Schemeの方がシンプルでわかりやすいじゃん、と。
当時はR4RSと首っ引きで格闘して、研究してたなぁ。

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

EmacsLisp使いで業界で有名なK林氏は、大学院の同期
なんだが、元気にしてるんだろか。

とりあえず、SchemeはLispだから。
話はそれからだ。

Lisp だって？ダサ。Ruby のほうが圧倒的に優れているよ。
言語以前に Lisp は S 式をつかうところからしてユーザビリティが低いもん。
今時コンパイラやスクリプトを書くならオブジェクト指向 == Ruby が最高

LISPでCコンパイラ作って遊んでるけど楽だよ。

どう見ても>>246が一番キレてるけどね。
それをスルーしてるあたり、同一人物かなｗ

>>244
> 今の技術の推移速度じゃ、それは無理だろ。

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

>>250
Rubyは正直知らないんだが、言語のプロトタイプ作って研究するのに
字句解析、構文解析、ツリー構築からやれと？
LispでS式で書いてしまえば、ツリーまで出来上がってくるから、言語の
動作の部分に時間と労力を注げるわけだが。

とりあえずLISPでもここまでできますよ、というサンプルうぷしました。
http://mata-ri.tk/up1/src/1M0593.zip.html
DLKey:251
ブートストラップして実行ファイル作ってるからLISPの痕跡はほぼないので
ただのCコンパイラもどきに見えると思う。
適当にサンプルソース添付したんで遊んでみてね。

>>255
感動ｽﾀ!
すごいなぁ orz
俺ももっと勉強せにゃ

>>254
250じゃないけど、S式の魅力ってそういうところにあるの？
いや、もちろんそういう利点があるのはわかるんだけど、
それだけなのかなってずっと疑問だった。ぜひ教えてください。

Lispだって、C言語コンパイラ作るんなら字句解析からやらなきゃ駄目だろ。

まあそういった字句解析みたいな類の本質的でない部分を
後回しにできるってこともあるんじゃないかと。
設計があやふやな状態であれ、何かを試したい事があればすぐに
本質に取り掛かれるって意味でS式は便利なものだよ。

>>255
とりあえず元のLispのソースきぼんぬ

rubyは便利だがあの文法がキモ過ぎる。
なまじ便利なだけにムカつく。

>>255
参考までに、処理系は何?

　　　　　　　 ＿＿＿＿＿＿＿＿＿＿＿
　　　　　 /´　 , -‐- ､.　　　　　　　　　　 /　　　スマップの中居
.　　　 　 i　　/::::::::::　　`''‐ ､..__,. ‐'´ヽ.　/　　 　稲垣・・・
.　　　 　 ! 　,'::::::::::　 　 、　　　　　　　∨　　　　アーティストのガクト
　　　　　|　 i::::::::::　　、 ､`''ｰ---‐''´　 ヽ
　　　　　|.　l:::::::: ／へ.＼` ｰ---‐ ´／,.ﾍ　　　　彼らが今脚光を浴び
　　　　 │　＼::::::::　＿＼＼,　　　/∠_　 |　 　　誰もが賞賛を惜しまないのは
　　　 　 |. /"ヽヽ:::=＝｡＝`,,　　 /=｡＝=│　　　言うまでもなく
　　　 　 | { i⌒| |:::::` ｰ-‐'　 　 .::.＼-‐ ´│　　　ただ　彼らが美形だったからだ・・・・
　　　 ／|. l ト､|.|:::::: ｰ-‐ '　　 ::::::::::: l::-‐'.|
　　／　 |　ヽ.._||::r':; -‐‐'　r __::::::::::::: l ｰ､|　 　　 勘違いするな　歌が上手いからじゃない
_／　 　 |　　 /l!:::/:: ー----------ｰ'--.|　　　　彼らは美形　ゆえに　今　その　全て
.!　　 　 .|　 ./ ::|::::::::::　　　　　 　 　 　 　 |　　　　人格まで肯定されている
|　　 　 │./　 ::|::::::::::: 　 　 =====　　 　 |＼ 　　 もし彼らが不細工だったらどうか・・・？
|　　　　 |/　　 ::|:::::::::::::...　　　 　 　 　 ,.イ　 .!`
|　　　　 |＼　　 :`'' ‐- ､::_:....... 　 ,. ‐'´/|　　│　　目も当てられない顔だったらどうか・・・・？
|　　　　│　＼ 　 ::::::::::::::::::｀~`''"::::::::/ .|　 　 |

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

もう心に刻まなきゃいけない・・・・・・！

>>260
そのうちしかるべき場所で正式に公開するかもしれませんが、
現在は仕事の方が忙しいのでそれどこではないですね。
配布形態も考え中なので気長にお待ちください。
>>262
255の原始言語にあたるLISPも自作のコンパイラです。
そのLISPの原始言語はやはりCで、今のブートストラップは
C-LISP->LISP'->C'->C''という手順を踏みます。
コンパイラ最適化部はLISPで考えたほうが楽なので
今後C''+LISP'併合->何か
という流れにできないか構想中です。

LISPだと初めから木構造になってるから楽とか言うけど、
今はJavaでもC++でもXMLライブラリがある。

>>265
なんでそこで XML ライブラリが出てくるよ。

木構造ならXMLちょちょいと書けばいいだけだから。

>>267
プログラムを表す木構造をXMLで書くの？

話の流れからするとそういうことになるだろうね。
Lispの構文木をListで書くって話だったろう。
今は専用のエディタもあるし、楽だよ。

×Lispの
○Lispでは

個人的には、構文解析をサボりたいのならlispよりprologの方が楽だと思う。
でも余り処理系作成者に人気ないね。

>>271
昔AIとかExpert Systemとかで痛い思いした人とか、痛い話とか一杯あるから。 orz

>>271
パーザの類を作るだけなら、Prologもいいかもしれませんが、
バックエンドのRTL生成、アセンブラコード生成はどうしますか？
それ以前に、Prologはツリーなどのデータ構造を持てなかった
と思うのですが。
ただ、パタンマッチ、バックトラック、カットなどの機能はいいですね。
なので、Lispで美味しいとこだけエミュレートしたいわけです。

>>268
The Evolution of Language
http://homepages.inf.ed.ac.uk/wadler/language.pdf

>>273
ごく普通にリストがあるんだが。それとは別な話？

>>259
はい、そういう利点があるのはわかるんです。でも、それだけなんでしょうか。
「S式信者」と呼ばれる人たちがいるくらいだから、
きっともっと他の何かがあるんじゃないかと思うんですが…。

>>271
Prologインタプリタの字句・構文解析を使うって事ですか？
それとも構文解析ルールをPrologで書き下すってことですか？

>>276
＞きっともっと他の何かがあるんじゃないかと思うんですが…。
それだけじゃないんだが、少なくとも言語処理の観点から見るとそれだけ。

結局はLispはあまり現実のソリューションとしては採用されてないのは事実。

>>276
> >>271
> Prologインタプリタの字句・構文解析を使うって事ですか？
> それとも構文解析ルールをPrologで書き下すってことですか？

構文解析ルールをPrologで書くと、BNFっぽくなるから、案外
便利かもよ？flex,bisonでやれ、と言われそうだが。

>>277
言語処理じゃない観点での利点ってなんですか？

>>279
Lispだと処理系作成者は字句・構文解析を一切やらなくてすむ、
(構文解析済みのツリーをユーザに書かせることになるからですが)
という話でしたから、それとは別の話なのですね。
あと、構文解析までが楽でもその先が辛そう、というのは>>273さんと同意見です。
常日頃からProlog使ってる人ならそうでもないでしょうけど。

久し振りに伸びてると思ったらlisp寝たかw
まったくお前ら好きだネ。

lisp/ruby/綾

>>278
でもおいら入社して研修終了後にいきなりsymbolicsの仕事だった

初めてのLispだったYorz

>>277
俺も知りたい。参照かキーワードでもいいから教えて欲しい。

>>280 >>283
スマン。俺も知りたい。なぜ LISP スキーがそこまで S 式に拘ってるのか。

？？？
「それだけじゃないんだが」の部分を説明してくれればいいんだけど・・・。

何かあったのは確か。良く思いだせん。


……頭の中から搾り出してみると、プログラム本体をデータ (リスト) として扱えるから AI に最適とか書いてあった。
ぶっちゃけ良くわからん。

コードもデータも同じように記述出来るというのは大きな利点。
それと関連して、他人のコードでも読みやすく理解しやすい（慣れれば）。

>>277 >>278
ふむ。ｻﾝｸｽ。ぶっちゃけ良く分からんに同意。

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

素養が足りないせいか、どっちも飛躍を感じる。
さっきから調べてるんだが、前者の話はしばしば見かける。（後者は初耳）
でもどの説明も、この間をかみ砕いて説明してはくれてない。

間違えた。>>277 >>287だった。

プログラムをデータとして扱える→マクロが書ける

んで、これが「他人のコードでも読みやすく理解しやすい」に繋がるかというと、
むしろ逆なんじゃないかという気がしてならない w

別にLispスキーというわけではないが…

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

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

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

「AIに最適」は「lispの作者が人工知能の研究者でもあり、
自分のプログラムをlispで書いたからそういう印象をもたれているだけ」
的な話がOnLispに書いてあるね。

伝わるかどうか知らんが，ざっと説明してやるから Lisp 話は Lisp スレでや
れよ．

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

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

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

でもカリカリにチューニングしたいなら手間はかかるが C のほうが優れている．

>>288
＞素養が足りないせいか、どっちも飛躍を感じる。 
俺も本で見ただけです。すんません。

>>291 >>292
なるほどーーー！！！
Lispのマクロって構文木の書き換えのことなんだ！
プログラム＝データっていうのはそういう意味なんだ！！

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

共感するかはともかく納得できました。
もやもやした物が解消して、すべてが1つにつながった気がします。
聞いて良かった。感動しました。感謝します。

なんかLispがすごいものに見えてきた。
使ってみたい。
Windowsでネィティブコンパイルできる使えるコンパイラない？IDEつきだとなおよし

>>295
別にすごいものでもなんでもないけれど。
Cしか知らないのなら、一度こういうものも知っておくとよいかもしれないね。

>>296
同意。むしろひどいものだよね。
破綻した言語っていう言葉がぴったりで。

はいはいわろすわろす

デバッグが大変なんじゃないの？
型がないうえにマクロばりばりなんて恐ろしいように思えるが。

無限の可能性を秘めためちゃくちゃ凄い言語だよ。
他の言語の仕様をLispに自分で追加できちゃうんだから。

>>299
確かにその辺は欠点かもしれないけど、
最近UnitTestとかもてはやされたよね？
ああいう感じの開発スタイルが昔からLispではデフォ。

言語研究で、新しいfeatureをちょっと実装してみたいときには
確かに便利そうだなぁ。

>>299
Cのマクロと違って、平常時から気楽に使うものではないんだろう。

>>300
Lispは全く素人だが、たとえば、LispにRubyの仕様を取り込めたりするのですか？
なんか、言語の概念が凄い。

で、結局Windows向けネィティブコンパイラはないのか。
そりゃ誰もつかわん

Allegro Common Lisp使えばいいじゃん。
WIndows向けでネイティブコンパイルできるしIDEも完備されてる。
まぁ価格が高いので「誰も使わん」のじゃなくて「貧乏人には使えん」がな。

どうでもいいけどいつからココLispスレになったんだ？

Lispをけなしてた奴って結局Lispを使えないか使ったこともない奴ばっかりだったね。

Rubyをけなしてた奴って結局Rubyを使えないか使ったこともない奴ばっかりだったね。

Rubyはそもそもまともに相手にされていないような。

構文解析どころかパージングすらいらないforth厨がきましたよっと。

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

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

凄いとは思うんだけどね。rubyは

>309
どのへんが本末転倒で、どのへんがベターな落としどころなのか
ちょっとききたい

最悪の落としどころだ(´Д`) > Python

> 構文解析どころかパージングすらいらないforth厨がきましたよっと。

一瞬「バージンすらいない」に見えた。

生まれた時から経験済み。(;´Д`)

>>311
俺のように頭の悪いLisp挫折組はPythonは良い落とし所なんだがなぁ。
どのあたりが最悪なのかちと解説希望。

>>304
あるにはあるが、別にネイティブコンパイラいらんだろ。
研究用なんだから、スクリプトだろうがハードウェアだろうが動けば良い。

>>315
成果物を他人に広く使ってもらうためには、いるんだよね
ランタイムのインストールが必要見たいのは、なかなか

>>316
だからネイティブコンパイラはあるって言ってるし、試すだけなら
インタプリタでもよいだろう。日本語読めないの？

>>317
だから高くて一般人には手に入らないんだろ？

>>318
フリーだが

>>316
いやいや、人に見せるもの作りたいなら普通にC++とか使うだろう＾＾；
研究用っていう意味わからないかな。

つ研究用＝実用性無し

研究ってひとくくりにするから伝わらないんじゃないか。
言語研究でのプロトタイプの大半はぶっちゃけおもちゃだよ。

実用性から考えるなら、言語の設計で重要なのは標準APIだと思うけど。

>>303
取り込めたりする。
実際CLOSという、Lisp自身の機能だけで実現された
オブジェクト指向ライブラリがある。
まあもっとも、RubyよりCLOSの方がだいぶ前だけどね。

過去においては時代のはるか先を行っていた言語だし、
時代の進化についていける言語でもある。

>>321
和炉他w

研究してみないと役に立つかどうかわからんから
研究用がほとんど役に立たないのは当たり前じゃん。

得られた成果が次世代の言語に取り入れられていくんだよ。

役に立つ研究なんか、役に立たんよ。

つうか 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 スレで!!]

以下の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>

宿題の予感

これは BNF として正しいよ。ループするかどうかは全然別の話。

>>324
というか、CLOSがRubyの設計土台のひとつじゃなかったっけ。

>>326
研究で作ってみて役に立つことがわかったなら、
それがそのまま役に立つ可能性もあるじゃん。滅多にないけど。

E・∇・ﾖﾉｼ　＜333ｹﾞｯﾄ♫

>>309
> 構文解析どころかパージングすらいらないforth厨がきましたよっと。

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

forthはBNFパーザさえ組み込めるんだよ？

>>334
それとはちょっと違うが、
C++はパーサ・ジェネレータなライブラリがあるよｗ
普通のパーサジェネレータなツールと違うところはC++のソースとしてBNFが書けて
コンパイル時にパーサが作られる（生成＆コンパイル）こと。
ライブラリは演算子の多重定義機能とテンプレート機能を駆使
(Expression Template technique & Template Maeta-programming technique)
して作られている。
http://spirit.sourceforge.net/

spiritはちょっと規模が大きくなるとコンパイル時間がヤヴァイ

spirit ってどこがいいの？

>>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っていうのは何行？

なんか男性○の大きさを競い合ってる厨房に似てるなぁ。。。

>>338
インタプリタ（Forth）とコンパイラ（C++)では自ずと違いも出るさ。
パースした結果をどう利用するかとか速度とかね。
だから「ちょっと違う」と書いた。
あんまり字面だけみて脊髄反射しなさんな。

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

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

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

要は適材適所で。

最近のこのスレは勉強になるなぁ。少なくとも高房の漏れには。

工房でなくても勉強になるような話題がゴロゴロ出てるからなぁ・・・
このスレで勉強にはならないとかいうヤシは、大学院レベルだろ。

このスレ煽りしかないじゃん…。

このスレの煽りの内容を理解するためには、それなりの高度な知識が必要なんだがな。
これだから自覚の無い連中は・・・まあ、マ板の専門系全般に言える事だが。

ここム板

少なくとも相談室7になってから勉強になるようなレスにはお目にかかっていないと思うけどな。

>>342
同意。

>>345
スマソ、言い間違えた。ム板と言いたかったんだ。

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

このスレの住人には一般教養なのかもしれんが・・・

>>346
それは、たまたま貴女の専門とする分野が、Lisp等と重なっているからでは？
実用的な言語の話しになると、きっと目から鱗とおもいますぞ。

> C++が動きさえすれば動くから移植に関して心配しなきゃいけない要素が少ないとか
> ビルドの手順が単純とか、ソースとの融合度が高いから気軽に使えるとかが
> 利点じゃないかな。

いつの間にC++はそんなに枯れた言語になったのやら w

アンテナ仕舞い込んでボケッと生きていると、
皆にはごく当たり前のことが「いつの間にか」起こっていたりするんですよね :-)

>>344
はいはいわろすわろす

あーあ、それは敗北宣言なのにー

そうやってだらだらと会話を続けようとするから質が落ちる

>>350
程度問題ではあるけどな。
ちゃんと規格どおりに動かないC++の処理系がまだあるのは知らないでもない。

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

もっとも古いパーサ・ジェネレータなら確かに昔ながらの比較的枯れた機能だけ使って
書かれていて確かに枯れているかもしれんがその分だけ使い勝手は悪い。
例えばBisonやFlexではC++向にコードを吐かせた場合、
確かにtemplateなどの新しい機能を使わないソースを吐くが、
マクロが濫用されていてデバッグは今時のソースより面倒だし、
当てにしているstreamの仕様が古くてワーニングが出まくったりもする。

>>354
そう思うなら自分のだらだらしたレスも控えればいいのにー

Python(やHaskell?)のようにインデントや2次元の配置などで
ブロック構造を示したい場合、どんなふうに字句解析すれば良いんでしょうか。

思いつきだけど。
連続するtab文字を一個のトークンにして
そこに幾つtabがあったかをリテラルのデータを覚えておく要領で
補助的なデータとして渡すとか。
で構文解析のときは行頭のタブ数が変わるまで同じブロックだと思う。

タブやスペースの数そのものを覚えておく必要はないだろう。
字句解析から構文解析に渡すのは
インデント深くなった(1)
インデント浅くなった(n) [n >= 1]
の2種類のトークンだけでいいと思うが。
そして
インデント浅くなった(n)
はn個の
インデント浅くなった(1)
で表現すればよく、結局括弧のペアを用いるのと変わらない。

覚えておく必要がないってのは構文解析部以後でってことね。
字句解析ではインデントの深さと文字幅をスタックで覚えておく。

>>359
つまり、Lispと同じ。
結論：Lispは究極の言語

>>361
「アセンブラでなんでも書けるから高級言語なんて不要！不要！不要！」論
を思い出した。

何の関係も無いことを急に思い出すことって
たまにあるよね。

LispがあるからXMLは不要！論もあったねｗ

まあ実際不要だしな。
Lispで何十年も昔からやってきたことが今更流行ってるって感じ。
つくづくLispって凄い言語だったんだなって思う。

>>365
こういう保守的で新しいことを覚えられない人たちが
業界から一掃されるといいんだけどね

うはｗｗｗｗ天然記念物ｗｗｗｗ

>>365
スルーした方がいいのかもしれんが、マジレスするとだな。
プログラミング言語というのは
人間に対して計算の記述方法というインターフェースを提供するという意味で
ある意味UIだからある処理がとにかく記述できれば
それでいいってもんでもなかろうということだ。

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

それはCUIでなんでもできるし
計算モデル上の新しい概念がまずCUIで試されたりもするけれど
GUIはやっぱり有用であるが如く。

↑もうすこしわかりやすくたのむ↓

LISPの代わりになるものが出来ればそれもいいんだけどね。
現実には大きくなりすぎたり、あれもこれも必要になったり、
パフォーマンスが悪くなったりと、なかなかうまく調和がとれない。

telnetとftpで問題なく通信はできるけど
httpをブラウザから使うのが有用であるが如く。

の方が実感できるかな？ｗ
今まさに使ってるわけだから。

>>371
つまりtelnet/ftp→http(HTML)→XML→S式と進化していくって言いたいわけ？

構文を極力シンプルにして、諸機能の解析を意味解析時や実行時に行うと。
この点では XML も LISP も同じ。たぶん。

PHPやrhtmlみたいな埋め込み言語見ればわかるけど、
それで何がやりたいかって、結局LISPみたいな事なんだよな。
そういった言語の存在はLISPを知っている人間からすると限定的すぎて
まるで無駄なアプローチに見えるけど、それしか知らなかった人間から見れば
実現する上ではそれしかなかったんだと。

このスレ見てるとLispというのはセックスのように思えてくる。
慣れた人間には普通のことになるが
通過儀礼を経験していない童貞は過剰な反応をする。
ときどき>>361みたいに経験したての少年のようなこっぱずかしい
状態から卒業できない人もいる。

>>356
この煽りの内容を理解するためには、それなりの高度な知識が必要なんだがな。
これだから自覚の無い連中は・・・まあ、マ板の専門系全般に言える事だが。

コピペうざい

半月ぶりにスレ見て、ずいぶんレスがついてるなあと思ったら
Lisperの戯言スレと化していたのな
内容的にもレベル低いし

死ねよいっぺん

内容を問うなら>>378自身はどうなるんだｗ
気に入らないならあぼーんすればいいのに。
つーかおまえが死ね。

Lisp関連レスあぼーんしたら、このスレ半月レスなしも同然なんだがなｗ

>>368 と >>371 は同一人物か？
表現がうまいなw

>>378
俺的には結構おもしろいけどな。このスレ。
いろんな意味で勉強になる。

Spirit 最強

Flex/Bison 死滅確定

Lisp Delphi(Pascal) Ruby

以上三言語を日本三大厨房言語に任命する

厨房ってのは、褒められてるものを叩きたくなるもんなんだよ。
そういうやつは、何らかの信者がこれは凄い！とか言ってると
絶対叩くの。
LispもRubyも叩いてるのは同じ奴だよ絶対。

そして、残念ながら褒められてるやつの中には本当に凄いものもあるんだよねｗ

日本三大厨房言語っていったら

HSP VB PHP だろ。

特にVB厨がタチ悪い。

>>384
最後の一文の必死さが哀れを誘うな

最初の三文だけにとどめておけばいいものを

必死でもなんでもなく、ただの事実だな。
ツッコミたいなら「褒められているやつの中には本当に凄いものなんて無い」
というのを、明確な根拠を付けて口にすべき。

Lisp最強とかRuby一番とか言ってるのは、
実はアンチの演技じゃないの、と思ってるわけだがどうか。

>>385
激しく同意。VBとPHPは世界的。

>>387
386の発言から、わずか2分以内でそれだけの文章を書きこんで「必死でない」ですか
必死でなくてなんなんだ

つうかそれが事実であったとしても
厨房とやらに叩かれてるものが、凄いものであるかどうかとは別やん
しかも世の中、凄いものであっても、叩かれるに値する欠点を有するものがほとんどだし
何アホ抜かしてるんだろうね

>>389
384と387が同一人物ではないから必死ではないんじゃないかなｗ

>>387ではないですが。
>>389(=>>390)はこの程度の文(!=文章)を書くのに
30分かかるのかもしれないけど、
普通の人は>>387程度なら2分で書けます。

コンパイラの話を城

できれば毎回決まってyaccだとかあの辺のパーサーの話になってつまらんので、
コードの最適化みたいな他の話題にしてくれ

初心者が最初に詰るのがパーサだからな。

>>389
専用ブラウザを使いだすと、いわゆる「即レス」をすることは珍しくなくなるよ。
板を巡回中、スレ一覧をリロードしていると、既読スレが「新着有り」に変わる瞬間に頻繁に出くわす。
その時、リロードしたのが新着レス投稿の1分後で、行って読むのに10秒、レス書くのに1分なら、
>>386-387間の2分46秒は簡単に達成されるからね。

これって以前は誰でも当たり前に考えつくことだと思ってたんだけど、
IEあたりを使ってスレに張り付いた経験があったりするとなかなか想像できないみたいで :-)
これまでにも何度か「即レスの仕組み」を説明してあげたことがある。

>>396
それって、この天気の良い秋晴れの午後にパソコンの前に座っていたことを証明するだけでは？

死ねとか専ブラ使えとかいう話はもういいよ。
DAGの話でもしようぜ。

誰も専ブラ使えなんて言ってないと思うけど。

即レス返している時点で専用ブラウザ起動しっぱなしで２ちゃんねるチェックしているってことだろ？
それを自慢げに言われてもな〜

>>400
つまり、一つスレを読むたびに専ブラ閉じるとか、
一度の2ch巡回で一つしかスレ読まないとか、
そういうのが君にとっての「普通」ということ？

>>400
昨今は即レスが常駐を意味しなくなっている
という話だと思うんだが・・・

本気で誤読してるん？

この話の落としどころは、389本人が自分のレスのわずか40秒後に
それだけの文章、と称した相手よりもっと長いレスを続けて書き込んでるところだと思う

「即レス=>必死」ではないという話だよな…。
やっぱり本物の馬鹿がいるようだな。

余計な事を言ったようで本当に申し訳ありません。
心の中にとどめておくべきでした…。
勉強になるレスの多かったあの頃、カムバック

>>401 >>402
400ではないが、常駐という言葉に齟齬があるんじゃないか?
400は、「コンピュータを起動して２ちゃんねるをチェック可能」な状態を言っているが、
401と402は「実際にチェックしている」状態を常駐と言っている。

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


まぁ要するに、争点は２ちゃんブラウザ起動しっぱなしがヤバいかどうか、だな。

>>406
いや、396が説明しているのは

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

ということに関してで、起動しっぱなしとかはまったく関係無いと思うよ

起動しっぱなしはともかく数分ごとに駄レス返すような奴はキモイと思うけど。

不利な展開だと思ったら
話題をすり替えて印象批判に移行するのは
まあお約束

Lisp厨がなぜ厨と呼ばれるか良くわかったよ

>>378あたりから雰囲気悪くなったな。

LISPの話でもしようぜ。

専ブラって投稿確認メッセージもスルーだからキチガイに鋏だな。


>>411
つまり半月ぶりにキチガイが帰ってきた結果がこれかと。

常駐とかいう話は384と387が同一人物でないと成り立たないな。
しかし、387は384と同一人物でないわけで。
つまり、たまたまその時間に387がレスを見ただけなわけでｗ

>>411
このスレの趣旨とLISPの話は関係ありません。LISPの話がしたければLISPスレに逝け。
これ以降はLISP話は禁止させていただきます。
趣旨にご賛同いただけない場合は別のスレを立ててそちらでやってください。

>>414
だが断る

Boostから、ライブラリ一式落としてきて、Splint見てみたんだが、
これって、LL(k)パーザ生成テンプレートという理解で、おｋ？

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

とりあえず、自前でSchemeインタプリタ作りたいので、まずSTLの
勉強からやりなおそうか・・・orz
C++どころかANSI Cすら満足に書けなくなっていることに気づいて
青くなってる。職場では某国産RISCマイコンのアセンブラしか書いて
ないから。

>>412
荒れてるのは、俺のいないときばかりなんだがｗｗｗ

>>417
荒らしているのはお前だろ、どうせ。
らくに自作自演できると思うな、クソが。
しらないふりをしようとしても、みんな気付いてんだよｗｗｗｗｗ
大した知識も無いくせに、知ったかぶって一人で痛い知識をさらして
歓んでんのか？楽しいか？何が「俺のいないときばかり」だ、お前が荒らしを
迎えてるんだよ、この永世童貞が。二度とこのスレに来るんじゃねぇセフルオナニスト

このスレ見てるとRubyというのはセックスのように思えてくる。
慣れた人間には普通のことになるが
通過儀礼を経験していない童貞は時に拒否反応を示すことがある。

>>414
つかとっくに Lisp な人はこのスレから引きあげてるみたいだよ…入門スレで
Forth もどきのコンパイラが投稿されてた。こっちでつづければよかったのに
残念だなぁ…。

>>420
お前も向こうに行けよ、氏ね

>>420
残念だ。
>>421
お前が一番うざいよ

るび厨が好き放題暴れてるな・・・
何が彼らをそこまで駆り立てるのか

>>423
おそらくお前はruby嵐工作員だろ？w
おれはruby使いじゃないが、それだけ魅力に取りつかれた奴が多いのは事実だな。

言語というのは、魅力的かどうかというのも重要な要素になると最近つくづく思う。

いるのは荒らしだけということに気づけ。
ruby厨もLisp厨もいない。
いるのは、アンチruby厨、アンチLisp厨

> おれはruby使いじゃないが
俺ならもうちょっと自然な書き方するな

イスラムとキリストの戦いと同じで、
どちらの信者も唯一神だと思っているから、
否定されると怒り狂うわけですよ。

俺は暇つぶしに荒らしているだけ。

>>427
いらんことするなw

では多神教の日本的アニミズムに染まっているワタクシはOKでよろしいな（ｗ

なんでそれぞれの言語には得手不得手があると言う事を認められないかなぁ？
言語論争とかエディタ論争とかに関してフレームアップするといつも疑問に思う。

rubyが他の何より最も役に立つ、という状況はうまく想像できないな。
何か説得力のある実例があればいいんだが。

言語論争のネタに最適ｗｗｗｗｗｗｗｗ

よっしゃきたー

荒れてきたー

>>430
lispが役に立つ状況だって全く想像できないのだが。
emacsを例に出す奴は、時代に完全に乗り遅れていることを認識すべき。
eclipse使えよｗｗｗｗ

lispはバックエンドでいまだに沢山見かけるよ。
それの対極とは言わないけどRubyはフロントエンド向きってことなんだろう。
効率よりも書きやすさ？

>>433

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

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

たとえばどういうところか、教えてもらえませんか？

有名なところでは US の YAHOO Store は Lisp で動いてるらしい。

>>433
Rubyはフロントエンド向きというが、無計画が祟ってそろそろ綻びが目立ってきた。
今の開発チームにそういったバイタリティがあるかどうかは知らないけど
バージョン2.0あたりで一度根本的に仕様を見直さないとやばいかも。

もうグダグダだなこのスレ。S/N比が悪すぎる。

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

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

どの言語がいいわるいだの開発体制がどうだのという話はどっか隔離スレを
作ってやってくれ。

しかし最適化の話には殆ど反応がないからなあ。
スレの最初の方ではそういう話題も振られていたようだが、>>9に対して>>10のような頓珍漢な
答えが返ってくるところだし、構文解析の話を禁止したら寂れると思う。

だって、最適化なんて全くしてないインタプリタにしたり
Cのソース吐かせたりするだけでそこそこ役に立つから。
最適化なんて、現状労力に見合わん。

ソースを最適化するよりも、早いマシン買う方がコスト的には安上がりだからなぁ・・・

構文解析ぐらいまでは学部の授業で扱ったりするから
ある程度盛り上がれるけど、
最適化まで話せる人間は2chじゃほとんどいないんじゃない？

>>437
気持ちは分かるが、やってくれといったらそうなるほど甘く無いぞ。
Nの半分は、スルーできないアホ住民らしいし。

Lisp Ruby Delphi Java C# VB PHP HSP
などの厨房や初心者や信者がでしゃばってくる類の言語の話は一切禁止・一切スルーということにしようよ

〜禁止とか、〜ｳｻﾞｽとか言ってる暇あったら自分から話題を提供すればいいのに。

そうやって一切禁止した結果がゲ製作板
開発効率と速度とスクリプトの責任のバランスの話なんておもしろかったのに

>>443-444
信者や厨房のくだらない話を見るくらいなら過疎ってたほうが遥かにマシ

マシとか言うなら見なきゃいいのに。

>>445
帰れよクズ

一連の流れの中で唯一「ほほう」と思ったのは、
富豪プログラミングの元祖みたいなlispと、
ミニマリズムの求道者みたいなforthが、どっちも
「人間の手で構文木を作り上げる」というアプローチに帰着してるのが、
面白い傾向だなとは思ったなあ

>>446
このスレは見たいが厨房や信者のくだらない話は見たくない、というかスレ違い。

>>448
今時のマシンから見ると、その元祖はめちゃくちゃ小さな機械なんだよね。
まぁFORTHはもっと小さいんだけどさ。

スタックコンピュータラブラブな論文集めた本があった気がするが、誰かタイトル覚えてませぬか？

lispだって構文は単純だし、
5つの基本関数さえあれば実装できるって話だったNe(希ガス)
だから結構minimalistな言語であるXe(希ガス)

>>451
そういうレスが荒れの原因。以後スルーでよろしく。

lispがforthにミニマリズム自慢をするのは、
「スーパーカブはガソリン食わないよ」
と言ってるのに、
「Ｆ−１マシンはインディーカーよりはガソリン食わないよ（だからスーパーカブよりすごい）」
と言ってるのと一緒やぞｗ

なんだかんだいってJavaの時代なわけだし。

>>453
その喩えの対応関係がよくわからないなぁ。解説求む。

>>452
自分の荒らしスレスルー能力が低いからって
十把ひとからげに話題ごとスルーを強制するキミほどではないと思う。

ああまたアホが……どうしようもないなこのスレ。
>>452
ミニマリストかどうかなんて処理系の実装と関係ない修飾語句にわざわざ
ひっかかるお前が悪い。

>>368、>>371でも書いたことだがなんせ言語の構文規則はUIだと思うから、
minimalistがとにかくスバラシイと思ってるわけでもないぞ。
だから「自慢」という表現は適切でないな。

minimalistな言語は処理しやすいからメタな処理が書きやすく、
プログラミングの新技法の実験とかしやすいけど、
込み入った記述が紛れて読みにくくなる傾向はあるから
よく使われる込み入った意味の「慣用句」をマークするために
専用の構文を割り当てるというのは実用上それなりに意味のある戦術だと思う。

>>456
構文のデザイン戦術・戦略の話の一環だと理解して応答しているが違うのか？

>>452 の言いたい事がさっぱりわからん。

>>368 >>371 >>457 を単体で見ると
Lispを褒め称えてるようにしか見えないのに、
前後の文脈からするとそうでもない。

とりあえず名前欄に452と書いてる奴は>>455で>>452にレスしてるので
このスレの>>452とは別人だと思うんだけど
名前欄に452と書いてる奴はいったい何がしたいんだ？

>>459
褒め称えてる？
ちゃんと得失（得点と失点）両方挙げてるつもりなんだがなー。

数字ハンドル間違えた。スマソ。

無理してこの話題続けなくてもいいのに

>>463
別に無理はしていないぞ？
興味関心の赴く所に従って書いているだけで。
むしろ荒れてるとされたであろうレスをザックリ無視しただけ。
どんな構文をデザインするかということに関する戦略・戦術は
言語設計の重要な楽しみだろう？

>>461

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

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

括弧が邪魔だ、とか、全部の構文が同じように見えるのが嫌、とか
そういう話ならそれはそうだと思うけど。

Lisp結局全然使われてないでしょ？
一部の信者が作ったシステムに組み込まれていることはあっても、
標準化されている、もしくはそれに近いのはEmacsだけだし。

そうそう。そのラス2行の話が失点にもなりうるって話ですよ。
全部の構文が同じようだからこそメタな処理が簡単に実現できる一方で
全部同じように見えると人間が読むときに注目しにくいという面がある。
（別にlispに限った話ではない言語設計上の一般的なトレードオフについて考えています。）

>>466
使われてないという（割とありふれた）指摘だけでなく、
なぜそうなるに至ったのかを分析しないと
よりよい言語設計の検討に繋がっていかないわけで…。

そこでその得失について考えてみているわけです。

>>466
>>Lisp結局全然使われてないでしょ？
>>468
>使われてないという（割とありふれた）指摘だけでなく、
>なぜそうなるに至ったのかを分析しないと
>よりよい言語設計の検討に繋がっていかないわけで…。

言語設計の検討はいいんですが、Lispが使われていない原因の分析はスレ違いだと思います。

>>469
そのスレ違い定義は少々杓子定規杉ではないですか？
そんな杓子定規ではオチオチ例を挙げて分析することもできない…。

で、私は取り敢えず構文の着目しやすさと一様性のトレードオフという観点から
構文の形式の一様度の高いLispを例にとって考えてみたということです。

>>466
標準としては ANSI Common Lisp がある。

ForthもANSI Forthぐらいある！

Forthは構文やセマンティクスがキモイで一蹴されるケースが多いけど、
Lispは関数スタイルやスコープなどが一貫してるので、
まあなんとか読めなくはないレベルに留まってるかな、と思う人は意外と多いはず。
そういう人がそれ以上を求めるならそれこそマクロの鬼になったり、
括弧大杉とかの理由なら適当なフロントエンドを作ればいいやと考えるだろう。
現状はまともに自己拡張ができる言語がこの２種ぐらいしかないので、
そういった機能が欲しい場合そもそも他のパッケージングされた言語と比べる意味がない。

また、これらの言語は数百から数千行程度である程度の処理系実装が可能でもあるので
俺言語オナニー入門者にとっては最適の素材と言える。
これらの特性はどこの馬の骨とも知れない他人の作った物が気持ち悪いだとか、
既存の物を探してきて覚えるというわずらわしい感情を全く抱かずに済むという利点がある。
可搬性を考えても他の処理系とS式レベルの互換を取るなどそれこそ朝飯前だろう。

そういうのはチラシの裏でやってくれ

おまいらまったく議論の内容が的外れですよ。
「LISPが使われてない」ということにしたい一部のキチガイが
キーワード出るたび脊髄反射してるだけですよ。

でも、使われてないのは事実。
ごく例外をもって、広くつかわれていると言い張っている馬鹿Lisperがいるだけw
その点Rubyは一味も二味も違う。

あと、ANSI化してないのも発展している言語の特長だと思う。

>476
>あと、ANSI化してないのも発展している言語の特長だと思う。
さすがRubistの言う事は一味も二味も違うな

わかったから信者同士の言い争いはほかのスレでやってくれ

このスレはコンパイラやスクリプトを作る人がぶち当たった問題点について議論するスレだよな？

各言語のマニアやフリークが誹謗中傷合戦をするところじゃないはずなのに何でいちいち突っかかるんだ？

Lispは結局使われているの？使われていないの？
EmacsとYahooの機能のうちのある部分だけ？

GCCとか、どっかの大学が作ってるコンパイラでも使われてるじゃん。

>>481
あれで使ってるというのだろうか？

商用だとAutoCADとか音楽関係のソフトの拡張言語としていくつか入ってた様な。

Cannaとかautocadとか。
SchemeだけどGNOMEとかGIMPとか。
あとは初期のPostgresがlispだったとか。
和田研フォントの中を覗いたらlispだった。
最近面白いと思ったのはこの辺。ttp://common-lisp.net/project/ucw/

>>472
マジか！マジで初めて知った。頑張るなーANSIも。

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

>>475
貶すためにくらべるんじゃなく、
得失を理解して新たな技術を生み出すために
比べる必要がある。
貶すやつや信者の主張すらも止揚してこそだろう。
私はLisp信者と呼ばれる人々の主張に一分の理を認めたからこそ
その主張と現状を共に説明するような観点を探すことで
初めて一様さによるメタ処理記述の容易さと
ソースコード上の特定の視認性のトレードオフに思いが至ったから
「信者」のレスすらも無駄だったとは（個人的には）思わんね。

>>482
中間表現みたいなのをとりあえずS式にしとくってのは十分ありえる
拡張を目的に１つの言語として独立してるし、胸を張って使ってると言えるだろうｗ

・高い自己拡張性
・（根っこのデータ構造がスタックかリストかの違いはあるが）単純な基礎構造
・構文構造を人間に書かせてしまうという思想
・（↑に伴う）初めて見たら「何これ？」と思う構文

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

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

＃使い方によっては、ね
＃どっかの信者みたく全ての状況で万能だと言い切る気はない

>>484
ワロタよ。こんなもんで使われてるというのか？w
低級言語らしく、目標も低いようだなw

音楽ソフトっつーと SONAR や CakewalkのCALかな
http://home.wanadoo.nl/t.valkenburgh/CAL.html

いつからここは言語オタの独演会会場になったのでつか？

確かに、ソフト自体もさるとながら、使われ方も軽いようですね。

要するに全然使われて無いじゃないか、Lisp…
XMLの代わりにLispで十分、とか言っていた人がこのスレにいたよね
お元気ですか？

まあアプリケーションに組み込む場合を考えると、言語構造がやたら複雑でも困るだろう。
LISPはサイズ的にも難易度的にもちょうどいいんじゃないの。

逆に組み込み用途だとRubyは全く使い物にならないのは認める。
なんかあったっけ？

luaとかJavaScriptみたいなLispから構文木取っ払ったような言語が
今後はがんばってくれます。

なるほど、スクリプトエンジンも適材的所ということですね。
Rubyerより

Lispは馬鹿には良さがわからん言語だから使われてないだけだよ。
XMLの代わりにLispで十分だけど、XMLの方が馬鹿にもわかりやすいから
使いやすくていいんじゃない？

そういえば、JavaScriptもLispに非常に近い言語だね。
これはLispそのものではないけれど、メジャーなんじゃないの？

比較的Rubyと近い言語のはずのPythonが、
組み込み用途でも結構頑張ってるのにRubyは使えないのは何でだろうと言ってみるテスツ

いや、Rubyも組み込みで使えるでしょ。
ただメジャーじゃないだけ。

数式処理の有名どころもLispのがあったんじゃなかったか？
まあLispのS式がアプリの前面に出てくる事ってあんまないけどね。
素人に出力見せるとゲ！って思われるのはある意味仕方が無い。
個人的には全部大文字に変換されるのがいけないと思うんだが。
デフォでcase-sensitiveを有効にする時代なんじゃなかろうか。

Rubyは馬鹿にも良さが分かる言語だから広く使われている。
また、熱狂的なファンも多い。

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

*Ruby ＝　阪神ファン
*Lisp ＝　ロッテファン

>>497
CUIは馬鹿には良さがわからん環境だから使われてないだけだよ。
GUIの代わりにshで十分だけど、GUIの方が馬鹿にもわかりやすいから
使いやすくていいんじゃない？

telnetは馬鹿には良さがわからん環境だから使われてないだけだよ。
web brouserの代わりにtelnetで十分だけど、web brouserの方が馬鹿にもわかりやすいから
使いやすくていいんじゃない？

>>501
確か、Maximaがそうだね。他にもあった気がする。

>>502
どうかな。Rubyが特別馬鹿にも良さがわかりやすい言語とは思えない
（Lispよりはマシかもしれないけど）し、歴史的、世界的に見ると
RubyよりLispのほうが使われてそうだけどね。
Lispなんて使われてないことにしたい厨房が暴れてるだけで。

>>503
ある程度はその通りじゃない？
ごく一部のソフト、例えば、グラフィックソフトなんかはGUIじゃないとまずいけど。

GUIとかCUIとか言ってる頓珍漢は何が言いたいの？

CUIはバッチ処理、GUIは対話処理に優れる
研究用途やサーバでもないとコンソールの良さが生かされる場面はほとんどなく
そうでない人たちがGUIを求めるのは当然

まあ結局パソコン上級者になるとキーボードばかり使うようになって
GUIでもCUIでも結局一緒になるんだけどね。

XMLが馬鹿にわかりやすいと言っている人間は、XML Schemaをしらないんだろうな

>>507
ってそのままlispとrubyにも当て嵌まらないか？

つまり

lisp=cui
ruby=gui

キーボード操作をする余地を残してる間は素人

LispとかRubyとか、使われていない言語に執着するのはなんで？

>>486
>>487
すまん、不勉強で悪いが、
逆ポーランド記述はスタック構造マシンにもっとも適した記述だからforthが生まれてるんだよね？
で、Ｓ式ってのはリスト構造マシンにもっとも適した記述としてlispの類も生まれてると。
で、昔のプアな環境ではスタック構造マシンはともかくリスト構造マシンは「贅沢」だったわけだが、
今のリッチな環境では最下層の仮想マシンにリスト構造マシンを据えても全然無問題だから、
リスト系言語を中間言語に据えるのもありちゃう？という認識でＯＫか？

と、スレ本題に近いことを聞いてみる

両極端だからでしょ？
俺的にはbison/flex+Cがマンセーなんだけど。

>>509
XML SchemaがXMLじゃないだろｗ
XMLという馬鹿にもわかりやすい土台を使って作られた言語。
LispでXMLSchema相当のことをやることもできるが、
それだともっと敷居が高くなるからやらないだけのことｗ

lispを設定ファイルとして使うゲームを昔見た気がする。
QuakeだかDoomの最初の頃だとおもったが。
でも実装は簡単そうだけど、保守性がなさそう（偏見）

>>512
定期的に煽りがはいるから。

>>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回音読しろ

普通のやつらの上を行け
http://www.shiro.dreamhost.com/scheme/trans/beating-the-averages-j.html

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

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

>>519
ﾊｲﾊｲﾜﾛｽﾜﾛｽ
信者は自分のスレに帰ってね

>>518
言い方が悪かったな。とっくの昔にLispで同じようなことをやってるのさ。
Lisp自体にもうXML Schemaと同等の機能が備わっているからね
新たに言語を作る必要がないわけさｗ

>>520
君はバカの壁って本を知ってるかい？
買ってから、100回音読してみたらｗ

語尾にｗを付けないと精神的優位性を保てないのですか？

まあそういうことにしといたら？勉強しろよｗ

>>506
単なる当てこすりだから気にするなｗ

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

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

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

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

>>487
JVMのスタックマシンはバイトコードの仕様記述のために存在するだけ。
レジスタ指定部をバイトコードから取り除くことでハードウェア独立を達成しながら
バイトコードの命令語長を短くするために採用された。
なので
最近のJVMではオペランド・スタックの部分も
それほどバカ正直にスタックマシンとして実装されているわけではない。

トータルの得失考えて、Lispがもっともパワフルなんだけどなあ。

普通のやつら〜の抜粋が出てきたとこでそろそろ内容的にLISPスレにシフトした方が
いいんじゃないかと思ったけど、まあ別にどうでもいいや・・。

それはそうと>>518はなかなかいいことを言っているな

あれが引用してる記事って何十年前の話なんだ？

まあ、キーボード操作してる人から見ればいちいちマウスなんか使わないよ。
出来るけどやらないだけさ。

Lisp厨はなぜ一般的にそれが使われていないかという現実から目を背けているよね
みんながバカで理解できないから、という自己矛盾をはらんだ理由ではなく、
まじめにどのような理由があるのだろうか

Lisperは保守的な人が多いのですねｗ

>>531
>>519に長々とその分析が書いてあるよ。

まあ、結構使われてるんだけどね。

一言で言えば、バカに良さがわからない言語だからだな。
これはほとんどの人が納得すると思うんだけど。

Lispの開発環境ってどんなのがあるの？

最近ならDr.Scheme（PLT Scheme)が一番初心者にもとっつきやすいかな。

>>534
それって、わからない人をバカと定義しているだけで、何の解決にもなっていないですよ

>>535
slime

>>534
バカしか相手にしていないんじゃないのか？

>>537
いや、事実だから、疑問の解決にはなってるんじゃないかな。

今日はLISP祭りですか？


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

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

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

って感じで、みなさんはLISPのパワーってやつをもっと知るべきだと思います

>>540
おまｗｗｗｗｗｗｗｗ、それ本気で言ってるの？ｗｗｗｗｗｗｗｗ
Lisperがバカなのが事実だろ？
と言われても反論できないジャマイカｗｗｗｗｗ

>>541
ただ荒らしているだけ。一人食いつきが良くてさｗｗｗｗ

Win向けのまともな実装がないし
細かい方言のせいでソース互換なし
バイナリも作れない
思考実験や手元で働かせるにはいいが
配布するには向いてない

>>541
C++で書かれたC++はあると思うぞ。CはC++のサブセットだから、
Cで書かれたC++を含めると、ほとんどのC++がそうじゃないか？

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

まあ、C++やOcamlも強力なパワーを持ってると思うけどね。

実はLispどころかRubyすら全然しらないけれど、
荒れているので便乗しているだけですｗｗｗｗｗｗｗ

>>542-543
とうとう本性が現れました

>>547
気付くのおそっｗｗｗｗｗ

>>546　>>548
なるほど、Lispのアンチってこういう奴だったのか。
どちらの言い分が正しいか非常に納得。

荒れたらまた来るね

>>550
傍から見ていて、Lispについて勉強になったので、またきてください。
今度はもう少し頑張って突っ込んでみてください。

>>545
いやいや、おれが言いたいのはそんなことじゃなくて、
どんな言語であれ、いずれは自己記述ができるのは自明の理なわけですよ
（HSPみたいなのは知らないけど）

LISPは処理系関係者以外でも言語自身に手が伸ばせる数少ない言語なのです！
ってことが言いたいわけ
処理系のソースなんて必要ない

>>541
ところで、LispでLisp書いて何が嬉しいんですか？

>>549
違う

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

>>550
実は俺も荒らしながらLispの情報を学べてよかった

>>553
>>541は多分マクロのことを言ってるんだと思う。

DelphiはDelphiで書かれてないのがバレて干されてしまいました

>>553
接ぎ木の様に処理系能力を継承しつつ言語機能を向上できるんだあ！

と言ったら驚きますか？
驚きますよね
仕組みは実に明快なんで説明しませんが
つーかそんなことはLISPスレの兵にでも聞いてください

違う違う。LispでLisp自身簡単に書けるんだよ。
readっていう反則的な関数があるせいでもあるんだけどねｗ

558＞555

Lisp Ruby Delphi Java C# VB PHP HSP
などの厨房や初心者や信者がでしゃばってくる類の言語の話は一切禁止・一切スルーということにしようよ

C++は最強だぜ！

Pythonばかりえこひいきだ

Lisp Ruby Delphi Java C# VB PHP HSP
などの厨房アンチがでしゃばってくる類の言語の話は一切禁止・一切スルーということにしようよ

>>554
お前、アンチLispだっていう自覚もないのなｗ
ああ、アンチLisp信者かｗｗｗ

>>384が的中ｗ

当然ながらLISPでLISPを書くのが日常的なものだとすると、
完全に俺竜LISPへ書き換えてしまったり、
全く別のものへ変えてしまったりも、
まあ多少の根性でなんとかなります

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

必要な物は多少の根性と若さ、息継ぎは必要ありません
まさに勢いのあるチャレンジャーのためにあつらえたかのような言語、
それがLISPの正体なのだあ！

最近荒らしてる奴を特定できるようになってきた

Lispの布教は別のスレでやってくれるかな

おまいら、他人が生み出したものじゃなくて、自分のオリジナルな物やアイデアを自慢しあおうぜ！

…俺には何もないがな

強力な言語だと自動的に熱狂的信者が沸いてきて、
熱狂的信者がいると自動的に厨房アンチが沸いてくるから。
半自動的に荒れてるようなもん。

>>569
ここだけの話だがな。アセンブラ作ったの俺。

>>571
すげぇええええええ！！！！！！！！！

スレ的には　Lisp -> Forth 変換プログラムを作ってみるといいんじゃね？
とか思った。

>>566
Lispはまさに前線向きの言語だよな。
おれもお前の言霊でなんかやる気がでてきた。
がんばるぞー。

そういえば、俺流言語をC++で書こうとして挫折して
Lispで書いたとか言ってる奴がいたなあ。
今何やってるのかなあいつ。

>>564がむかついたので、次はLisp厨のふりをして荒らします

>>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

Forthも昔からその小ささは魅力的ではあったんだけど、
後置記法というのは判るが基本プリミティブ（というのか？）が異質でいまいちわからんのだな。
四則演算程度ならともかく構文なんかは後置記法でどうすんのか、とか
暗黙的なスタック操作関係とか色々疑問が。
つーかこれじゃスレ違いな単なる愚痴だったか。

>>577
ソフトパイプの発明が1かよ！
俺がやったのは0.1くらいだな。

>>576
勘弁してください。

>>577
元々の問題の難しさから言ってgraph coloringは5だろ。

graph coloringはx86みたいな制約の多いCPUには使いにくいね。
みんなどうしてるんだろう。

HSPが果たしてきた役割というのを再認識すべきだと思う

なんだこののびは……
みたところ>>437がダイナマイトっぽいな。
次スレから「○○禁止」っつー発言を禁止しようぜｗ


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

っ ゲーデルの不完全性定理

同人製作のために作られた場当たり的なツール
生い立ちはCと似てるね

つーかなんでこの板にIDないんだろう。

>>573
Lisp スレに Forth もどき -> Lisp トランスレータ (30行くらい？) がでてたよ。
関数定義と if ... else ... end と四則演算しかないみたいけど。

同意
ID議論スレpart2まで行って投票も200を超えたのに無視されてる

Lisp Ruby Delphi Java C# VB PHP HSP
などの厨房や初心者や信者がでしゃばってくる類の言語の話は一切禁止・一切スルーということにしようよ

>>584
不完全性定理自体はこのスレの範囲外な気がしますが、
そこから意味論の話題に行くなら面白そうですね。
でもこのスレでは、構文解析厨と、
（具体的なお題を出さない）最適化屋さんのような、
実装スキー（と思われる人）しかいないんですよね。
だめそうならMLスレやHaskellスレに移住したほうがいいかと。

で、具体的に何の話をしましょう。（お題出せなくてすみません）

groovyとか面白そうだなって思ってるんだけどこのスレ的にはどうなんだろう？

>>590
じゃあ>>9の話題を。

>>590
操作的意味論と表示的意味論の関係を述べよ

>>590
>>1の各トピックについて順に語っていこうか．

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

っていうか具体的な言語の話を禁止しても良いんじゃないかと思った。

>>594
じゃあ終わりから順で。

>>593
どっちも形式的意味ではあるけど全然別物だと思うんですが、
何か論理的な対応とかあるんでしょうか。

りんごタソは、Lisp と Ruby どっちが好きなんだろう？
やっぱり宝石の方が好きかな？

ハァハァ

>>596
>>592は無視？

>>599
傍聴したいやつはいるようだが、
自ら話したいやつは一人もいない予感。

>>451
燃料投下する気はないけど嘘はよくないので訂正入れとく。７個ね。

ttp://ja.wikipedia.org/wiki/%E7%B4%94LISP
と勘違いしたんじゃないかな。

つーかぶっちゃけ
LISPも知らん奴がプログラミング言語を語るなんて
信じられない

言語の理論研究の主流はLispからMLやHaskellに移りつつある気が。
なぜかこのスレではほとんど出てこないけど。

あと、オブジェクト指向のように、理論より実践が先行してできた
プログラミングパラダイムもあるので必ずしも信じられないことはない。
が、このスレでそんなアイデアが出てくる可能性は万に一つもないだろうなぁ。

型推論が流行ってる？

Lisp信者もアンチLispもいいかげんにしろよ

>>604
Lispそのものを対象にした研究は、昔からあまりなかった気が。
意味論なんかも定義されちゃったし、λ計算なんかと似てるし。
アルゴリズムの説明や実現に使われることが多かった気がする。

>>604
ここのLisperは本流に乗り損ねた亜流の集りってことに
早く気づけよw

一方のオブジェクト指向言語では Ruby はまさに本流。

は？どういう論理展開ですか？

Ruby房の寝言にまともに付き合ってると
頭がどんどん悪くなるよ。

↓亜流なオーラを隠せないタイトルの書籍群

Rubyを256倍使うための本 無道編
Rubyを256倍使うための本 邪道編
Rubyを256倍使うための本 界道編
Rubyを256倍使うための本 極道編
Rubyを256倍使うための本 魔道編
Rubyを256倍使うための本 黄道編
Rubyを256倍使うための本 網道編
Rubyを256+倍使うための本 場外乱闘編
Rubyを256+倍使うための本 紅玉制覇編
Rubyの冒険 旅立ち篇―Rubyで簡単プログラミング入門

Lisp本の定番ってありますか？
この擦れ見てたら勉強したくなってきたw

× 一方のオブジェクト指向言語では Ruby はまさに本流。
○ 一方のオブジェクト指向言語では Java はまさに本流。
　 Ruby はその成果を Ruby に焼き直すだけ。

Javaはただメジャーなだけ。
本流はSmalltalk。

>>612
入門では無いが、今だとこれか？
http://www.amazon.co.jp/exec/obidos/ASIN/4894714337/
http://www.amazon.co.jp/exec/obidos/ASIN/4894712261/

本読むだけじゃなく、mapcarとかapplyあたりが使いこなせるように少し
練習する必要はある。そうしないと入り口には立てない。

Javaは教育用の言語でしょ？
実用性が低すぎて最悪だピョン

>>616
IT土方は、それで必死に企業のERPシステムなんぞ作っていたりするわけだが。

Javaの実用性が低いとは思えないけど。
統合開発環境のサポートがあれば非常に高い生産性をあげられるし。

ネット用の言語じゃなかったのか・・・

目的と手段をはき違えた奴が各言語厨だと言うことが本日の書き込みで解ったわけだが、
なんでそういう奴ってどこにでも湧いてくるんだ？

lispで書いたlispの話が出てたが、
Wirth御大の「Pascalで書いたPascal」は「おー文書として綺麗に見える」と関心した記憶があるなあ。
forthで書いたforthも見たことあるが、あれはあれで「うんうんいい意味でも悪い意味でもforthだねえ」と思ったっけ。
ちなみにCOBOLで書いたCOBOLも見たことあるが、ノーコメントｗ

>>618
統合開発環境の性能がよければ生産性が高いのはどの言語でも一緒だと思うが？
smalltalkみたく統合環境そのものが言語であるってのもあるしな。
forthやlispほど求道者じゃないかもしれんが、smalltalkの自己拡張性もあなどれんぞ
あと、伏兵でHyperCardとかなｗ

>>611
メジャーゆえに、色んな本が出版されるわけよ。
その点lispは心配いらんなw

>>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ですらメチャクチャなコードを書くやつがいるのに
こんな自由度の高い言語を開発部隊に使わせる気にはなれない。

>>621
懐かしいなぁハイパカ。
今思うとHyperTalkは結構よくできた言語だったんじゃないかと。
生産性は微妙だが。

>>624
Hypertalkはめちゃくちゃ良くできてたと思う、IDEはなかったが、
あれで日曜プログラマを沢山排出したってのは非常に重要だと思う。
今だと同じ部分を担ってるのがflash関係だけどね。

「LispでLispがかけるから凄い」というのがLisperのより所なのか？
笑っちゃいかんが、ワロタw

>>626
それを言うなw

>>626
単にパーサが書けるとか、そういう話と勘違いしてない？

>>621

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

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

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

HyperCardもsmalltalkも「子供のために作られた」言語だよね、そういや。

lispがめちゃくちゃ柔軟で強力で凄い言語だってのは
ゆるぎないんだから、もうそろそろこの話はやめないか？
続けても意味がない。

>>623
いや、マクロの話じゃないよ。
そりゃ、マクロも所々使っているけど、普通にPascalでPascalを書くのと同じで
LispでLispを書くっていう話。
ただ、比較的短い。
>>615の本にも載ってるけど、本にして10ページ。

>>629
ぶっちゃけ、オブジェクト指向ってコンピュータに疎い人向けの機能だからなぁ

>>632
それを言うなw

>>632
今度はオブジェクト指向信者を呼ぶつもりか、うぜぇ。

いかし、オブジェクト指向って曲者なのは事実。
いままでの設計手法ではまるで歯が立たん。

イベントドリブン型には適していると思うけど＜オブジェクト指向

>>635
Lispがあれば楽勝

>>637
何が？オブジェクト指向的なプログラミング？それとも設計？

コンパイラやスクリプト作ろうという人は、結局自分の言語作りたいってことだから
言語の話題は良く伸びるんだろうね。

>>635
そうでもないぞ。

モジュール設計の手法が身について無いと、ちょっとデカい
モノを作ろうとすると、簡単におかしな状況に陥るから。

やっぱ、設計を勉強する順番は、
データ構造→モジュール設計→オブジェクト指向
だと思うんだがな。

スレ違いだが。

>>639
ほとんどが信心してる言語のオナニー書き込みか、
それ以外の言語をけなす書き込みなのが問題

というか、このスレの住民の目的はなんなんだろう？

>>640
ちょっと言葉が抜けてた。

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

と言いたかったんだ。

要するに、古い設計手法をある程度知った上でオブジェクト
指向に手を出さないと、色々と問題の発生する可能性が高いぞ。

>>643
言語は、うまく広まれば人気者になれるからねぇ
みんな有名になりたいのでは？

>>645
個人が適当に作る言語が広まるはずもないと思うけど…
あのRubyですら、使用ターゲットを明確に規定していないために
きちんとした位置を確保できないというのに。

Rubyは広まってるし、まつもとは有名だろ。

新しい言語の必要性が全然わからない。Rubyしかり。


というか言語なんて所詮手段であり、それを目的にする意味がわからない。

>>645
信者が布教すれば布教するほどむしろ嫌われる現実に気づくのはいつなんだろうな・・・

知名度は上がって欲しいんだけどね。
ユーザによって貶められるのは何とも何とも (´ー｀)y-~~

>>648
同意

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

Lispは古い言語だからある程度は仕方ないにせよ、Rubyなどは存在意義がわからない。
何か言語を使うとき、LispやRubyを使う選択肢を今後選ぶはめになるなんて想像できない。

実用言語と研究用言語と自己満足言語の違いだな

言語設計というかAPI設計の話だよな
ただ、JavaScriptのように、素人が使うことを前提とした言語設計みたいなのはあるな

JavaScriptが言語としてどういいのか教えてくれ

>>654
・メンバの継ぎ足しが強引に出来ること
・メンバへのアクセスがfoo.bar foo['bar']の両方で出来ること

>>655
それって >>653 が言ってた素人云々とは関係あんの？

>>654
関数オブジェクトとか、クロージャとか？

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

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

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

割と先進的な言語ではあると思う。
素人が使うことを前提としているというのは聞いたことがない。
確かに素人が使ってる言語という気はするが。

>>656
さぁ？俺はJSのいいとこ言っただけだよ。
でもマクロ用の言語をチョイスしろって言われたら
LuaやLispよりJS選ぶかな

JavaScriptはブラウザさえあれば特別な実行環境を必要としないってのが一番ウケたんだろうな
言語仕様として見た時に、あれだけ方言が多い言語はどうかと思う…

JavaScript はクロシージャが分かると世界が広がる。
逆にそれが分かっていないと、あまり他の言語とかわらん気がする。

おまえら、言語関連のスレでJavaScriptとECMAScriptの区別がつかないのかよ。

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

>>656
素人向けの言語使用としては、セミコロン省略とかかな

ごめ、「クロージャ」だ。
激しく間違えた orz

ECMAScriptの素人向け仕様
・基本的に上から順に実行されていく手続き型
・一番外のスコープでのみ、宣言せずに変数を使用可能
・特定の条件でセミコロンを自動補完
・型が無い

こんなところ？俺も実はJavaScriptそんなに詳しくないんだけど。

660はVB出身だな、気にするな

ECMAScriptの実装はやったことがないけれど、言語仕様見て面倒そうだなぁとは思った。

実用言語≠研究用言語≒自己満足言語

>・基本的に上から順に実行されていく手続き型

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

下から順に実行されていく手続き型なんてあるのか？馬鹿

JavaScriptはLispと似てるところがいいところ。
クロージャとか

>>663
スコープではなく、functionの外でのみvar宣言がいらない、じゃなかったっけな

>>667
C言語だと、まずmain関数からスタートするよね

グローバルスコープから実行が開始されるってことね

確かに、素人が軽く使う際になるべく問題を起こさないように苦心しているのはよくわかった

仕事でJavaScriptを使って大規模なコードを書いている経験からすると、
マルチスレッドがECMAScriptの言語使用で決まっていれば良かったんだけどな

>>673
JavaのThreadなんて神がかって使いやすいし
マネてくれればJSの強みになるんじゃないかな？
Runnableを強引に実装できるってすげー

C++erな俺はsynchronizedだけでもいいから欲しい・・・・(;´Д`)

synchronized よりも lock の方が短くて(・∀・)ｲｲ!

>>674
Runnableってどんなのですか？

>>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

>>677
runというvoidメソッドを実装しなさい！って決まりを付けたインタフェースですよ。
JavaでいうインタフェースってのはC++でいう全部abstractなメソッドのクラスのこと

補足すると
Runnableインタフェースを実装したクラスのrunがThreadのmainとして走る仕様
Threadそのものも継承できるけど、Runnableを使ったほうがスマート

Runnable だったら、むしろ C# の非同期デリゲートとか Io のアクタメッセージとかの方が強力だと思う。
Cw には更に凄いものがあるらしいが。

コンパイラの話じゃないね｡･ﾟ･(ﾉД`)･ﾟ･｡

Runnnable自体は単にrunメソッドを持ってるだけの何の実体もないクラス(インターフェース)だよ
多分言わんとしてるところは無名内部クラスのほうなんじゃないかと思われ

setIntervalとかあるし、スレッドが無いわけではない

>>678
本当にそれだけの理由だったのかどうかは当事者に聞かないとわからないけれどもね。
他のシステムならともかく、Yahooのトラフィックをさばききれず、
他の安定したフレームワークに乗り換えたというのはいかにも有りそうだし、
それはリーズナブルな判断だと思う。

653を読まずにただ興味から質問したんだ
回答してくれた人thx

groovyってどう？

純粋に質問だけど、Javaのスレッドのどういうところが好きなの？

>>681
コンパイラの話ではないけど、言語を設計するという観点では重要だよな

>>683
シングルスレッドだよ。
例えばsetTimeout(function(){},0);は、現在のコンテキストが終わるまで実行されない。

>>687
implements Runnableとクラス宣言時に書き
runにその内容を記述するだけでそれがスレッドとして動くようになる。
そんな実にシンプルで分かりやすいところ。

負荷に耐える状況で使われているLispのフレームワークなんてあるの？

>>680
>Threadそのものも継承できるけど、Runnableを使ったほうがスマート

とまあこのように、スマートじゃない方法を残しているところが
Javaの設計のタコなところだと思うんだが。

>>689
よくわからんけどｻﾝｸｽ。
それをそのままJavaScriputに組み込むのは可能なのかな。
もっとプロトタイプベースのJavaScriptらしいやりかたがある気がする。

>>683 >>688
実装によるんじゃない？

>>676
いまや、キーワードは長いほうがいいんだよ。統合環境で自動補完してくれるから。

>>687
synchronizedがオブジェクトと関数のみにかけられ、
言語レベルでそれがサポートされているところなんかは
設計がしやすいし、後でソースが読みやすいね。

まあ、世の中Lispの敷居の高さを超えられないバカが多いということだね。
JavaScriptは敷居を低くしたLispだから、流行ったんだろうね。

JavaのThreadなるものを全く使った事なく妄想で言うが、

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

みたいな関係ではなく？

>>692
> >>683 >>688
> 実装によるんじゃない？
仕様に書いてある。現在の主要ブラウザはすべてECMA-262 3rd Edition準拠

Lispの敷居が高い？どういう冗談だ

>>694
昨日、Lisp厨に化けて荒らすと宣言していた奴か？

>>695
Runnableクラスをスレッドに投げるときは
new Thread(runnableInstance).start();
みたいな感じになります。

>>695
ヒント：Threadはクラス、Runnableはインターフェース

>>697
大半の奴はLispを見て、
「うわーなんだこの見にくい括弧は。最悪。」
で、ろくに学習する前に終わる。

これじゃあ良さを理解するどころじゃないわな。
そういうことだ。

>>701
思い込み激しすぎ。>>690

で、Lispを学ぶためにオススメな環境は？xyzなんたらとか？

>>702
この目で何百人と見てきてるんだけどｗ

>>703
今のところ、LispはEmacsやxyzzyを使っていない限り使い道ないし…
学ぶんだったら自分で実装するのが一番かな

>>703
PLT Scheme

>>704
この語尾のｗは昨日荒らした例のLisp厨だよな。放置で>>ALL

せっかく面白い話だったのに、Lispのせいでまた荒れるのか

>>678

ざまぁ見ろ！LISPER目！
これからは、オブジェクト指向言語の時代だ！

ああ、昨日荒らすふりして俺からLispについて学んでた奴かｗ

hoge.run = function() {alert('ｽｯﾄﾞﾚ!');}
startRun(hoge);

JavaのをそのままJSにもってくるとこんな感じの実装になるのかな？

>>709
CLOS

しかしここまで理解されてない言語も珍しいな。

>>704
同意。つーか、みんなどこも一緒でしょ？
ただ、Lispを悪く書くと変なのが粘着するからだれも書かないだけ。

smalltalkの話しようぜ

>>712
まじれすすると、それほど設計が悪いということでもある。（有る意味ね）

今時はプログラムの入門と言ったらJavaだしな。
アメリカではPythonだけど（てかあれ元々教育用言語だし）

>>690
米軍が使ってるんじゃなかったかな。たまにニュースに研究所の求人とかでてるよ。
その辺で俺は LISP のイメージが悪い。

>>711
Rhinoのスレッド拡張は

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

関数がfirst-classなんだからこっちのほうが素直だろうね。

>>717
それはLISPじゃなくて米軍が嫌いなんだろう・・・

>>718
神がかってるなｗ

つうかものスゴい狂人がいるな… Ruby とか Lisp によほど嫌な思いででもあるんだろうなぁ
はやく ID 導入してほしい。あぼーんが楽になるのに。

米軍が使ってるからﾜﾛﾀ
717にはAdaを紹介したい。

>>718
これ関数を引数に渡してるの？
すごいね。

>>717
妄想で語るなw
おれはAdaで苦しんでいるというのに。

>>712
JavaScriptも、「最も誤解された言語」と言われてるらしい。
Lispの宿命か。

>>723
すごいの？
JavaScriptでは、無名関数を渡すことなんてざらなんだけど

>>717
> 米軍が使ってるんじゃなかったかな。
それはフレームワークとは言わない

CLOSはね、漏れ修士論文のネタだったんだよ。
といっても本家CommonLispでなく、Schemeに載ったTinyCLOSだったけどな。
作者はどちらもG.Kiczales。TinyCLOSは、C++やJavaから見ると非常に違和感
あるオブジェクト指向だと思う。いきなりメソッドをdefgeneric(virtual宣言
みたいなもの)して、メソッドにオブジェクトと引数をアプライするという記法
だから。

そりゃLisp使えるもんなら使いたいけれど、
大抵の用途では他に優れた言語があるんだからしょうがないよな。

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

Lispはマニアが楽しむための言語だと思うけど。もしくは教育用か。

Lispが教育用？なんかHSPを”入門言語”としてすすめるくらい無謀だな

>>729
研究用。漏れはMLを使うけど。

>>725
実は最近JavaScript勉強して、懺悔したい気分になった。

>>730
S式の教育用って意味じゃない？

プログラム言語の教育用としては、やはりCが良いと思う

必死こいてオナニーしてる信者
必死こいて貶してるアンチ

必死こいて勉強してる俺

>>729
そういうのはただライブラリが揃ってるとか、開発環境があるとか
それだけのことが多いから、優れてるとはいわないんじゃないかなあ。
Cのライブラリが一番揃ってて生産性が高いからと言って、
PascalやJava他の言語より優れてるとはいいたくないな。

だからお前らいい加減、JavaScriptとECMAScriptを区別しようよ。
JavaScriptはブラウザの拡張も含めた話をするときだけに使ってくれ。例えばRhinoとか。

>>736
生産性の高さを自分で勝手にライブラリが充実してることと結びつけて
それをもってCが生産性高いとか言い出す意味不明さ

>>736
いや、ライブラリなどの環境がそろっているというのが、
最終的な生産性を決めることなんじゃないかな。

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

あと、Cは全然生産性が高くないです。バグを誘発しやすいし、標準ライブラリも酷い。
あえて反論を恐れずに書くならば、JavaとPHPの生産性が高いと思う。

ではActionScriptの話をしよう

まあ、言語なんて何でもいいじゃん
目的達成に一番便利なもの選べば間違いないんだし。
LispでもCでもJAVAでもOcamlでもRubyでも
どうせ皆使えるんでしょうどんな言語でも。

>>738のあとの>>739ワラタ

なんでだよｗ
でもE4Xにいち早く対応したのには感心するよ。

>>741
コンパイラ・スクリプトエンジン相談室で何でその話になるんだ

>>739
少なくとも、Cはgccやruby、python、perlなどの実装に使われてる。
これは、そういった用途では生産性が高いことを意味していると思う。

このスレってさ、言語を作る話題のスレなんだよね…。
どう見ても言語を使う話題しか出てないけど…。

ライブラリは当然多い方がいい。
自分が作る処理系ではそーしてください。終了。
でいいんじゃないか？

>>745
今度は生産性の高さのオレ定義を作り出しましたｗ

なぜLisp信者はこれほどたくさんいるのに、
もっと環境を充実させようとしないのだろう。

GUIの簡単なプログラムを書く言語にLispを使えたらいいのに
VBだけは使いたくない…

>>739
まあそうなんだけど、このスレで言うLispの素晴らしさって言語仕様のことだと思う。
ライブラリがないということは、はじめからLispの欠点として認めてるんじゃないかな。

>>744
それほど、「コンパイラ・スプリプトエンジン相談室」してねえジャン

>>748
そういう信者は初心者を寄せ付けないことに優越感を見出す人間が多いから

優れている、優れていないを議論するなんて不毛だよな

>>750
してなかったらいいのか？
バカは消えろ

>>747
>>738で意味不明と書いたものの、>>739があっさり意味を理解して
一瞬にして赤っ恥を掻いた奴がまた現れましたｗ

>>752
だから禁止にしようって前々からいってるんだけど信者が聞く耳をもつわけがなく

客観的に優れているか優れていないかを証明するためには、
ライブラリの充実や実世界での使用くらいしか指標がないのが
Lisp使いにとっては厳しいところ。

>>748
なんだかんだ言ってユーザーがそれほど多くないのと、
GUIとか作りたい初心者の気持ちがわからない
CUIラブの上級ユーザーが多いからだと思う。

作る話題以外は当然だがすでに禁止されているはずだ。スレ違いなんだから。

他言語の話題を出すときは自分の作ってる言語とどう関係してるか
ちゃんと説明すること。
(自分はこうしようと思ってるけど他言語は違う設計になっている。
こうすると何がいいの？とか)

>>755
むしろ、アンチが聞く耳もってない。

>>757
とはいえ、CUIで世の中に配布するためにはCがベストソリューションという罠
新しい世界で必要な言語にLispを選べればいいんだけどね

>>759
アンチだろうが信者だろうがおんなじことだよ。放置すればいなくなるのに。

>>760
どこからそのベストソリューションと言う結論が出てくるの？

>>748
>GUIの簡単なプログラムを書く言語にLispを使えたらいいのに
>VBだけは使いたくない…

どうせWindowsなら、WSH上でJScriptでも使ってればいいのでは?
俺使ったことないけど。

>>763
WSHでGUIプログラムをどうやって書くんだ？？

>>764
書けなかったっけ。じゃあ俺の勘違い。すまん。

>>762
ごめん、思い込みかも。
LinuxでCUIベースのプログラムのソースを取ってきたときに
C以外は見たことがなかっただけでした。

だから、LisperはCなみのスピードを出すコンパイラを
待ってんだよ!

WSHでWinAPIを呼び出すdyncallというのが確かあった。
それ使えば出来る。

>>764
ちょっとはググれや

>>768
コールバック関数が書けないからアウト

>>767
Lispって構文汚いけどCより速いってイメージだったんだけど違うの？

>>766
つMaxima

>>725
>JavaScriptも、「最も誤解された言語」と言われてるらしい。

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

こいつな。
ところでここではやっぱり、
| セミコロンの挿入も大きな誤りでした。
って書かれてるぞ。

>>767
仕様上かなり難しいと思われ・・・

>>７６６
いや、いいとこついてるよ。

WSHはhta作ればいいっしょー
あれは個人的にナイスな開発環境だと思っている

>>771
Cよりは遅い。Cはマシンにべったりだからかなり速いし、メモリ食わないし、
出力ファイルのサイズが小さい。
・・・って、これ常識だと思うのだが、、、

>>７７４
つまり、基本設計時点で（ry

>>773
セミコロンがなぜ誤りだったかはかかれていないね。
しかしそのページはとても参考になった。ありがとう

そもそもLispでシステムコール呼んでる場面見たことないな。

>>776
HTAはいいよね。IE前提でさえなければね。
あれは言語というよりプラットフォームだから残念。

>>778
その基本設定こそが最大の利点だよ。
まあ、Cよりパフォーマンスが出ないという点では劣っているけどね。
その代わり最大の利点を手に入れた。

>>７８０
つまり、基本設計時点で（ry

>>777
いや普通あんな汚い構文見てたらCより速いから使ってるのかな？って思うじゃん

TkかGTKにでもつなげばwindows上でもlinux上でもGUIプログラムなんか書けるだろ。

パフォーマンスはたいした問題じゃないと思う。Javaですらあれだけ流行っているし。
問題は、Lispがそれを効果的に使ってもらえる場所を探し出せなかったことだと思う。

>>784
さすがにそこまでの超初心者はどっか行けよ。

CISC RISCに続いてLISPプロセッサを作ればよいのだよ

LISPが汚くて遅いと知ってて使うのが上級者？

>>781
そもそもWSHが(ry

>>786
Javaの成功は企業の後押しが大きいからなあ。
Lispはユーザーが少ないということと初心者に優しくないことに尽きる。

>>790
その通りだった。申し訳ない

HTA4Ajaxがそのうち登場するからズボン降ろして黙ってまっとれ

>>789
そう。まあ今では結構速い部類だけどね。

>>786
いや、パフォーマンスが重要なところだってあるよ、だから適材適所なんだってば・・・

>>788
はるか昔にできて、滅んだ。

Lispのネイティブコンパイラってピンからキリまであるけど
高いやつならCとほとんど変わらないスピードでるぞ。
少なくともC++よりは速い。無知はひっこんでおけ。

>>791
いや、一番の問題は、使い道が無いことでしょう。
普通の人は、言語を覚えることを目標にせず、何かの目標の手段に言語を使うからね。

>>793
それが事実でマルチプラットホームだったりしたら射精が止まらないんだが

>>797
C++だって高いコンパイラ使って適切なコード書けばC並みに速いわ。

JavaもC++と遜色ない速度になりますが、何か？

>>797
FortranやPascalとタメをはるOOPとしてDが登場したから世の中分からないものだよ

重要なのは　開発速度＞実行速度

>>795
Lispの適所がないということは、適材ではないということ？

>>７９８
いいこと言ったな
言語を設計＆実装する上で、参考になる。

HTAでajaxなんて今でも使えるんだけど…

>>798
まず、使い道がどこかにあっても理解されてない。その原因は初心者に優しくないから。

そして、使い道がない大きな理由は、ライブラリがないから。その原因はユーザーがいないから。
その原因は初心者が少ないから。

>>８０３
その点では、宝石言語s はずば抜けていい。

LISP厨はまだ居るの？
いい加減隠居してほしいんだけど

LispとRubyは言語を覚えるために勉強したな。マジで楽しかった。
全く役に立ってないけど、アイデアの幅が広がったかもしれない

>>792
マルチプラットフォームがいいならXULとかどうよ

>>807
そのりくつは　おかしい
自己矛盾している

>>810
とあるハッカーはLISPを実践で使う機会は無いがものの考え方の訓練として学べと言ってるしな

>>811
ここでいうプラットフォームはブラウザなので、XULだとMozillaオンリーでよろしくないかと
HTAだとまだOSのサポートがあるだけ救いがある

いろんな言語が使えるHyperCardさえあればなあ

Scheme(Lisp方言)はGIMPの拡張書くのに使える。
GNU標準スクリプト言語になったらしいけどその後どうなったんだろう…

>>812
いや、矛盾してないよ。全ての根本原因は「初心者に理解できない」に帰着する。
とても道理にかなっている。

>>813
なるほど、同じようなことを考える人はいるもんだな。
しかし、やっぱりLispは教育用言語か

Javaが使われてるっていったってサーバーの分野でしょ？
GUIとかのクライアントではあんまり使われてないじゃない。
まぁいろいろがんばってるみたいだけど

>>816
そもそもGIMPとかEmacsの拡張書こうとする奴が少ないんだよ。

>>817
言語の前に論理学を学びなさい

>>792
MPが前提でAjaxと言ってしまった。すまんな。

なんか、みんな思い思いのことかいとらんか？w
おそらくLisperw

もしEmacsのマクロがC言語ライクだったら

EmcasLispには誰も言及しないのか

>>821
お前がな

>>797
>Lispのネイティブコンパイラってピンからキリまであるけど
>高いやつならCとほとんど変わらないスピードでるぞ。

初心者な質問ですまんが、そういうのって、マクロ使ったら、ネイティブコード
破棄してインタプリタで実行するの?

>>819
サーバの分野で使われているのは、それ単体でかなり大きなアドバンテージだと思う。
PHPなんてサーバでしか使われていないしね。

>>823
固定つけてください
NGにしたいんで

>>823
痛いところをつかれたようだ

もし、おれがりんごたその夫だったら。。。

>>819
IBMが嫉妬の憎悪を燃やしてるからな
SUNという今にもサラ金に手を出しそうな家に生まれた超絶美少女みたいな

>>827
そんなコンパイラ無いって…

LinuxでCが多いのはgccの功績でしょうなあ。
まあ開発環境ってのはでかい。

>>833
コンパイラなら早くなる、けどマクロ使えないってダメじゃん・・・

>>834
Windowsがこれだけ普及したのも、Visual Studioの使いやすさがでかいと思う

LispのJITコンパイラとか、誰か作ってそうだけどな

とここまで書いてわかった。Lispは金にならないから人が少ないんだな

>>835
？

初心者に優しくない→人が少ない
使い道がよくわかってない→人が少ない
金にならない→人が少ない

下に行くほど説得力が増す不思議

>>838
じゃあどうやってマクロの処理してるの？

>>839
下に行くほど説得力が増すように並べたからだろ？
何を言ってるんだ？

どうせLispなんか作っても、「うわｗ括弧キモｗｗｗ」
とか言われるだけだから、自分で使うだけで十分。
GNUとかの凄い人が採用してくれるし。

>>839
いや、一番上が一番説得力高いんだが・・・

>>840
マクロの展開はコンパイル時に終わるのだが…。

C言語って初心者にやさしいとはとても思えないけど、使える人が多いよね
Lispが普及しない理由に初心者にやさしくない、というのは間違っている気がする

>>842
採用ってどこで？

>>845
いや、初心者にはとても優しいよ。少なくともLispに比べればね。
Cを一から教えてLispを一から教えてみればわかる。

>>845
なぁ、お前この言葉知ってる？

「とっつき」

>>846
とりあえず、今まではEmacs、GIMP、で採用された後、GNUの標準スクリプトとして採用された。
これからは知らんけど、どっかで採用されるんじゃないの。GNUの標準スクリプト言語だし。

>>842
そりゃGNUの一番偉い人はEmacsの作者だから

Ruby ＞＞＞＞＞ HSP ＞＞＞＞＞＞＞ C ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ Lisp

>>827
コンパイラへ渡す前に展開されるからネイティブコードになるよ。C++ 厨の俺
に言わせればテンプレートみたいなもん。

てーか作りたい言語が静的な型なら ML や Haskell から入門したほうがいいよ。

GNUとEclipseがかみ合わないのはそのためか。
ApacheとかほとんどJavaに首っ丈だしな

よくわかった。Lisp信者は、
・Lispを理解しない人間を馬鹿と定義し、
・Lispを一般に広く知らしめようとせず、
・Lispが最高であることを信じて疑わない

s/Lisp/オウム/g

>>853
GNUの思想はもう古いだろ

>>854
2番目だけあたってる。

>>854
Lispは使い道が無い　も加えてくれ

>>855
GNUは昔は企業に対抗するためのものだったのに
最近は企業が体よく技術を宣伝するためのツールと化してると思う

まあLispを理解できなくても、頭のいい奴はいるよ。
ただの毛嫌いとか、そういう奴らの一部はそうだろう。

>>859
覚える必要がない、というのが大部分だろう。
言語設計に興味を抱かないとなかなか出会えない言語だし。

どんな糞なものでも知るだけでひとつ賢くなる。
Lispなんかはふたつ賢くなれる糞みたいなもんさ。

事実に対して仮定を持ち出す
　「確かにLisperは少ないが、もし最もユーザーが多かったらどうだろうか？」

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

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

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

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

知能障害を起こす
　「Lisp＞＞＞＞＞＞＞＞＞＞＞＞＞他の言語」

Lispはゴミ，Lisperは社会のゴミ

>>861
わざわざ「ふたつ賢くなれる」とつけるあたりLisp信者の驕りが見え隠れするな

>>862
詭弁ガイドラインに

捏造をする

を加えた方がいいな。

Lispをいいと思うことは一向に構わないが、
主観で人にそれを押し付けるのだけはやめてほしい。

今夜のLisp叩きが始まったのも元はといえばLisp信者の鬱陶しい主張だ。

googleで検索した結果

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

よって Ruby ＞＞＞＞＞＞＞＞＞＞ Lisp

いや、元はと言えば、Lispに対する普通の事実に納得できなかっただけじゃない？

>>864
俺はCOBOLだってふたつ賢く慣れると思ってるぞ

>>868
それが主観ね

>>868
たとえ事実でも言い方を間違えたら反感買うだけだよ

D Language の検索結果 約 276,000,000

これのどこが、「コンパイラ・スクリプトエンジン相談室」なんだ?

Java の検索結果 約 331,000,000
C の検索結果 約 1,660,000,000
N88BASIC の検索結果 約 27,700

>>872
866も主観だね。

>>753
これのどこが、「コンパイラ・スクリプトエンジン相談室」なんだ?

馬鹿だな、LISPより遅い言語はいっぱいあるよ
ttp://shootout.alioth.debian.org/

>>873
だよな、だからもう次スレからでもいいからはっきりと
言語仕様の優劣や言語仕様とは無関係な既存言語の話は禁止にしようぜ

確認だけど、>>868が言うところの、「Lispに対する普通の事実」ってのは、
「括弧だらけでわけわからんので誰も使ってない」ってことでいいよな?

で、それに納得できなかったLisp厨が暴れている、と。

言語使用の優劣を禁止するのはありだと思う

優劣なんて主観でしか決まらないし

もともとは、アンチRubyが暴れてて、そいつがついでにLispも叩き出しただけだった。
だが、RubyよりLispに熱狂的信者がいてLisp一色になった。

100人がLispを勉強すると、
50人はcar, cdrで挫折
25人は階乗で挫折
12人はreverseで挫折
7人はちょっとしたプログラムは書けるようになるが、list, cons, appendの区別がつかない
3人はこの言語の有用さに疑問をもち
2人は信者になるがそれ以上先に進まない

そして、運がよければ、最後の1人は立派なlisperになる。
が、会社ではCのプログラムしか書かせてもらえない。

>>875
866はともかく、お前が主観で話しているというのが問題だ。

結論：LISPERはクズ



終了！

>>881
二行目に同意

久しぶりに除いたら…すごいことになってるな。真性自作自演か…ちかごろ珍しいねぇ。

>>886
お前がそれを書き込むことで得られるメリットって何だ？

>>882
全然違う。

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

あたりだと思う。

>>877
Cライクな言語の独壇場だな

昔どこぞの国のお偉い先生が
「実行速度が遅いからといって、その言語が悪いわけではない
コンパイラが良くなればいいのだから」
と言ってたような、言わないような。
俺は覚えやすい言語が、それがLISPであれなんであれ問わず、
コンパイラでもVM（インタープリタを含む）でもいいから
高速で実行してくれて
かつ値段に比例してスピードが上がるのではなく、
皆が自由につかえるのが一番だと・・・思う。

>>882 >>888
おまいら自身はどこですか？

>>882 ﾜﾛｽ
>>888 ﾂﾏﾝﾈ

>>878

たとえばさ、

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

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

結論：「信者が悪い」

Haskellレベルの型推論器を作るのってどのくらい大変ですか？

とりあえず Ruby と Lisp と Forth は禁止な w
このスレはこの、自由に語りあってくれ厨房言語以外のネタで www

>>895
RubyとLispはわかるとしてなんでForth？

A:「俺が今作ってる言語では、Rubyみたいに文末のセミコロンが省略できるように
　しようと思うんだけどどうやったらできますか？」
アンチ:「やりかたなんかしらんがやめとけやめとけやめとけやめとけ！！！」
信者：「ムキーーーー！！！」

だったような。

知ってる単語並べただけでしょ

Forth 信者きたよ www 信者は退場してください
Forth はどこにも使われてないだろ？せいぜいブートしたときとか細い用途で
実際コンパイラ作成にもスクリプト言語にもつかわれてないじゃん
なんか日本語もどきの糞言語があったけどな www

エンジンスレなのにRubyがダメって分けわからーん。
エンジンにしては内部のコードが綺麗と評判じゃん。（特定のものが異様な無理をしてるけど）

最初はおぼろげな記憶しかないんだけどさ。
確かこんな感じだったと記憶。

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

まあ、過去ログ見ればわかるんだけどなー。

>>896

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

Forthでなんでも出来ると主張し始めたら止まらない。

実際Forthで何でもできるの？
マクロでLispインタプリタとか出来ちゃったり？

バカだね。Ruby の内部が綺麗？信者は救いようがないな wwwww
構文木をそのまま実行する前世代的なアレが信者フィルターには「綺麗」？ w

>>900
綺麗というか、setjmpとlongjmpを使いまくって
内部のコード(C)もRubyっぽく書けるように設計してあるんだよね。
だからもともとRubyが好きな人には評判がいいんだと思う。

>>903

私は信者ぢゃないけど、Cより低レベルな言語だから何でも出来ると言うのは嘘ぢゃない。

>>902
途中で紹介されたリンク先の文章でも LISP は良く知らないけど FORTH のほう
がスゴい!! と信者的妄想炸裂だったなどっちも 50 歩 100 歩の糞言語なのに www

>>906
なんだそういう意味でか。

アセンブラのほうがもっと何でもできるぞ

>>904
構文木をそのまま評価すれば、
インタプリタのソースコードはシンプルになるんじゃないですか？
遅いけど。

アセンブラは移植しにくいですね

FORTHはアセンブラと同レベルだから
なんでもできるは否定しないけど、なにもできないも否定しない

>>907
熱狂的信者がいて、それに耐えられないこいつが貶しているということは、
結構凄い言語かも知れんな。
Forth。

RubyはIBMでJavaの補助ツールとして使えると紹介された実績もある。
ニーズがある言語は良い言語だ

Forthはメジャーな言語。PDFとPostScriptがある。

まあ、俺から言わせて見ればここで話題になる言語なんざ、ニーズがありまくりの超メジャー言語
ばかりだよ。

Forthは熱狂的な信者というより
頭がアレな信者(Forthの作者含め)が多い

>>910
Ruby 信者必死だな ww 遅いってわかってるのに？ 未だにバイトコード + VM
構成にできないだけなのにそれを美点と解釈するわけね。じゃぁ YARV はコー
ドが複雑になるからいらないんですか www Python とか Perl は何年前からバ
イトコード + VM 構成だか知ってる？ w おまえらが普段馬鹿にしてる PHP ですら… www