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

「コンパイラ・スクリ ..

2:デフォルトの名無しさん
05/11/06 19:45:58
★コンパイラ一般

・色々なツールの紹介
　URLﾘﾝｸ(catalog.compilertools.net)
・コンパイラ関連のリンク集
　URLﾘﾝｸ(www.ulis.ac.jp)
・スクリプティング言語資料室(仮) (リンク集)
　URLﾘﾝｸ(www.kt.rim.or.jp)
・Compiler Construction
　URLﾘﾝｸ(rananim.ie.u-ryukyu.ac.jp)
・Compiler Construction　(1997)
　URLﾘﾝｸ(rananim.ie.u-ryukyu.ac.jp)
・情報システム工学実験 III コンパイラ・コンパイラ
　URLﾘﾝｸ(math.cs.kitami-it.ac.jp)
・OS/Programming 簡単な C コンパイラ
　URLﾘﾝｸ(www.csg.is.titech.ac.jp)
・正規表現
　URLﾘﾝｸ(hp.vector.co.jp)
・コンパイラ研究・開発情報の一集積所
　URLﾘﾝｸ(compilers.cs.uec.ac.jp)
・Links and Selected Readings
　URLﾘﾝｸ(www.gnu.org)
・国産のコンパイラ共通インフラストラクチャCOINS
　URLﾘﾝｸ(www.coins-project.org)

3:デフォルトの名無しさん
05/11/06 19:47:47
★字句・構文解析

・Lex and YACC primer/HOWTO （邦訳）
　URLﾘﾝｸ(www.linux.or.jp)
・Turbo Pascal Lex/Yacc
　URLﾘﾝｸ(www.musikwissenschaft.uni-mainz.de)
・Jim Roskind's LALR(1) C++ Grammar
　URLﾘﾝｸ(www.empathy.com)
・Flexと Bisonを同時に使う
　URLﾘﾝｸ(guppy.eng.kagawa-u.ac.jp)
・KITE_ASM (yacc,lex)
　URLﾘﾝｸ(www.arch.cs.kumamoto-u.ac.jp)
・bison用のC++ LALR skeleton
　URLﾘﾝｸ(www.bj-ig.de)
・ANTLR（非yaccのパーサジェネレータ）
　URLﾘﾝｸ(www.antlr.org)
・JavaCC(Java Compiler Compiler)
　URLﾘﾝｸ(javacc.dev.java.net)
　URLﾘﾝｸ(village.infoweb.ne.jp)
　URLﾘﾝｸ(www.asahi-net.or.jp)
・CUP, JLex, JFlex
　URLﾘﾝｸ(www.cs.princeton.edu) (JLex, CUP)
　URLﾘﾝｸ(www.jflex.de)
・SableCC
　URLﾘﾝｸ(www.sablecc.org)
・￢＜＞＜∪∪ （notavacc）LALR(1)
　URLﾘﾝｸ(ne.cs.uec.ac.jp)
・boost::spirit（C++のテンプレートでEBNFの構文を模倣）
　URLﾘﾝｸ(spirit.sourceforge.net)
　URLﾘﾝｸ(boost.cppll.jp)（マニュアル日本語化プロジェクト）
　URLﾘﾝｸ(www.fides.dti.ne.jp)

4:デフォルトの名無しさん
05/11/06 19:48:38
★ごみ集め

・GC FAQ -- draft
　URLﾘﾝｸ(www.iecc.com)
・A garbage collector for C and C++
　URLﾘﾝｸ(www.hpl.hp.com)
・一般教養としての Garbage Collection
　URLﾘﾝｸ(www.is.s.u-tokyo.ac.jp)
・Garbage Collection : Algorithms for Automatic Dynamic Memory Management
　URLﾘﾝｸ(www.amazon.com)

★処理系,スクリプト

・kikyou.info (吉里吉里というゲームのスクリプト)
　URLﾘﾝｸ(kikyou.info)
・tiny C コンパイラ (C)
　URLﾘﾝｸ(www.watalab.cs.uec.ac.jp)
・6809用 Micro C コンパイラ
　URLﾘﾝｸ(www.axe-inc.co.jp)
・Portable Object Compiler (Obj-C >> C のトランスレータ？)
　URLﾘﾝｸ(users.pandora.be)
・自作コンパイラの部屋(PL/1, Pascal等)
　URLﾘﾝｸ(www.tokumaru.org)
・『Rubyソースコード完全解説』サポートページ
　URLﾘﾝｸ(i.loveruby.net)
・『やさしい Lisp の作り方』『やさしい Java インタプリタの作り方』
　URLﾘﾝｸ(www.okisoft.co.jp)
・MSによるPEフォーマット仕様書(日本語)
　URLﾘﾝｸ(www.interq.or.jp)

5:デフォルトの名無しさん
05/11/06 19:49:35
★学会

・PLDI
　URLﾘﾝｸ(research.microsoft.com)
　コンパイラの研究に関する最新成果を知りたければまずはここ。
・POPL
　URLﾘﾝｸ(www.cs.princeton.edu)
　PLDIよりは理論寄りだが大いに参考になる。
・ICFP
　URLﾘﾝｸ(icfp06.cs.uchicago.edu)
　関数型言語に関する学会。とても難しい。
・OOPSLA
　URLﾘﾝｸ(www.oopsla.org)
　オブジェクト指向言語に関する学会。最近はやや低調？
・ICCC
　URLﾘﾝｸ(www.st.cs.uni-sb.de)
　ヨーロッパ系。派手さはないが堅実。

6:1
05/11/06 19:55:29
つうわけで立てました。>>3だけリンクがhttp～になってないのは、
http://が多すぎます、と怒られたため。

7:デフォルトの名無しさん
05/11/06 20:02:13
キチガイ隔離スレ立て乙です。

8:デフォルトの名無しさん
05/11/06 20:04:45
で、教材に向いているコンパイラってなによ

9:デフォルトの名無しさん
05/11/06 20:07:04
>>8
マジレスするとMinCaml

10:デフォルトの名無しさん
05/11/06 21:02:37
書籍関係のテンプレは？

11:デフォルトの名無しさん
05/11/06 21:05:41
>>1乙
取りあえず、禁句一覧は以下の通りとする。
（以下よろ）

12:1
05/11/06 21:36:56
>>10
ごめん、飛ばしたらしい。

★参考書籍

・コンパイラ　原理・技法・ツール　１＆２
　URLﾘﾝｸ(www.amazon.co.jp)
　URLﾘﾝｸ(www.amazon.co.jp)
　通称ドラゴンブック。バイブル。
・コンパイラ構成法　原田賢一
　URLﾘﾝｸ(www.amazon.co.jp)
　URLﾘﾝｸ(www.hara.cs.keio.ac.jp)　(ソース、正誤表のダウンロード)
・プログラミング言語処理系岩波講座ソフトウェア科学〈5〉佐々政孝
　URLﾘﾝｸ(www.amazon.co.jp)
　一冊で済ませたい人へ。
・コンパイラの構成と最適化中田育男
　URLﾘﾝｸ(www.amazon.co.jp)
　最適化がメインだが、構文解析からコード生成までの基本事項も解説されている。
・コンパイラの仕組み　渡邊　坦
　URLﾘﾝｸ(www.amazon.co.jp)
　薄い奴(185p)を読みたい人に。
・21st Century Compilers (Alfred V. Aho, Sethi, Ravi Sethi, Jeffrey D. Ullman, Monica Lam)
　URLﾘﾝｸ(www.amazon.co.jp)
　まだ出ていない。
・スモールコンパイラの制作で学ぶプログラムのしくみ
　URLﾘﾝｸ(www.cbook24.com)
　初心者向けの優しい解説本。

13:デフォルトの名無しさん
05/11/06 21:54:48
>>1 に書いてある低消費電力化まで
考慮する処理系なんてあるの？

14:前スレの971
05/11/06 21:57:31
拡張ライブラリを書くのに、俺言語のソースを文字列リテラルの形で
C中に埋め込むのはありか、と質問していたものです。

現時点の案としては、
a)文字列リテラルでCにソースを埋め込む。
b)バイトコードを埋め込む。
c)シリアライズしたものを埋め込む。
d)Cでゴリゴリ書く。
ってとこですね。

b)はバイトコード実行系でないからパス、
c)は、なにしろCなので、シリアライザもデシリアライザも書くのが大変だからパス、
d)は、やっぱり書くのが面倒(いちいち関数呼んで型を変換したり、オブジェクトを
　GCの管理下に入れたりするのが)。

ってことなんですが、こういったデメリットを上回るデメリットがa)にあれば
やめるけど、今のところ思いつきません。
パースなんて重い処理じゃなし、それも1回動くだけだし。

前スレ973に笑われるだけなら、笑わせとくよ俺は。情報科出じゃないし。

というわけで引き続き情報よろしく。

15:デフォルトの名無しさん
05/11/06 22:03:58
いまどきのプログラム言語の作り方（randy (著)）
って、買ってみた人いる？
どんな感じなんでしょ。

16:デフォルトの名無しさん
05/11/06 22:07:34
ｽﾚﾘﾝｸ(tech板:138番)

17:デフォルトの名無しさん
05/11/06 22:11:17
>>13
少なくとも研究レベルではよく聞くね。

18:デフォルトの名無しさん
05/11/06 22:11:52
>>15 書名でぐぐれば目次が見つかる

19:14
05/11/06 22:44:18
俺言語の改良点早くかきこめ馬鹿
特にLispで威張ってたやつらw

20:デフォルトの名無しさん
05/11/06 22:51:15
>>18
Amazonはチェックしたんだけど、良さそうな気がする

21:デフォルトの名無しさん
05/11/06 22:54:03
>>19
ごめん。全然気付いてなかった。
Lisper　じゃないけど、俺は普通に　a　で良いとおもう。

22:デフォルトの名無しさん
05/11/06 22:57:23
このスレでは異端かもしれんが、
難しい理論や高度な技術よりも、
使い易いってことの方が言語としては大切な気がするんだけど。

すまん、スルーしてくれ。

23:デフォルトの名無しさん
05/11/06 23:10:50
>>19
とりあえず、Lispに出来るだけ近い言語にしとけばいいと思う。

24:本物の14
05/11/06 23:16:54
なんのこっちゃ。
わけわからん行動する奴がいるなあ...

25:本物の14
05/11/06 23:21:12
肝心のことを書き忘れた。

>>21
>Lisper じゃないけど、俺は普通に a で良いとおもう。

どうもです。
私には a)の方法で特に問題があると思えないんですよね。
やっぱりa)でいくとします。

26:デフォルトの名無しさん
05/11/06 23:22:25
急に新スレに移ったので驚きました。
あわてて前スレを読み終わったところです。

前スレの最後のほうで、ECMAScript(JavaScript)にはLispと同じような
言語的能力がある、という話が出ていたのですが、それはどのような点なのですか？
Lispは簡単なプログラムが書けるくらいですが、是非教えてください。

27:デフォルトの名無しさん
05/11/06 23:38:34
>>14
a)でいいと思うけど、.hに入れるか別の拡張子にして
#includeするのを薦めてみる。

>>26
GC, クロージャ, 関数オブジェクトあたりだと思う。
関数の合成とかカリー化とかできて、その辺がLispと似通ってる。
この辺はRubyでもサポートされてる。

28:デフォルトの名無しさん
05/11/06 23:48:07
> カリー化とかできて、
できたっけ？

> この辺はRubyでもサポートされてる。
されてたっけ？

29:14
05/11/06 23:49:36
>>27
>.hに入れるか別の拡張子にして#includeするのを薦めてみる。

そうすることで、#includeされる方のファイルでは俺言語そのままで書けるなら
いいんですが、実際にはそうも行かないと思ってるんですけど、
27さんが想定しているメリットはそれ以外のことですか?

30:デフォルトの名無しさん
05/11/06 23:58:13
>>29
ソースコード中に点在するのは避けた方が良いってことじゃないか？

31:デフォルトの名無しさん
05/11/07 00:00:24
>>26
URLﾘﾝｸ(d.hatena.ne.jp)

>Cの皮を被ったLisp
>JavaScriptには、Cのような中括弧や、不格好なforステートメントがあるため、
>一般的な手続き型言語のように見えます。しかし、それは間違っています。
>JavaScriptは、CやJavaよりも、LispやSchemeのような関数型言語と多くの
>共通点を持っているのです。JavaScriptには、リストの代わりに配列があり、
>プロパティリストの代わりにオブジェクトがあります。関数はファーストクラスであり、
>クロージャを備えています。*2括弧のバランスをとる手間なしに、ラムダを利用できるのです。

32:デフォルトの名無しさん
05/11/07 00:19:38
>>29
makefile使うなら俺言語→ヘッダの簡単なスクリプト書いて規則に入れちゃえば？
周辺ライブラリの一部を俺言語で実装するというのは結構Unix系のこんなにスクリプト
が流行る前の言語で見た気がする、ただ組み込み前提では無い為よく見かけたのは起動時
に初期化スクリプトを読むorVMイメージをロードする、もしくはCへのトランスレータ
を介して自己に結合するという方法だった気がするけど

33:デフォルトの名無しさん
05/11/07 00:20:44
もうグダグダだなこのスレ。S/N比が悪すぎる。

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

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

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

34:14
05/11/07 00:22:05
>>32
です。その、俺言語→Cの変換スクリプトを俺言語で書いて、
miniperlのような形でまずmakeし、そのmini俺言語で変換スクリプトを
動かして.cを生成するのがいいかなあ、と思ってます。

35:デフォルトの名無しさん
05/11/07 00:51:15
昔はあんなにぼろくそに言われたJavaScriptもこんなに人気になるんだな。
ブラウザ以外の用途でも結構お目にかかるようになってきた。

36:デフォルトの名無しさん
05/11/07 01:05:17
>>35
例えばどこで? SVGとかかな

37:デフォルトの名無しさん
05/11/07 01:06:23
>>36
Flash、PDF、Macのダッシュボードとか。

38:デフォルトの名無しさん
05/11/07 01:08:29
ダッシュボードは違うか

39:デフォルトの名無しさん
05/11/07 01:11:44
>>33
お前はLispでもいじってろw

40:デフォルトの名無しさん
05/11/07 01:14:39
ダッシュボードもそうだしLaszloというRAIフレームワークもJSだ。
RhinoやSpiderMonkyなど組み込みもあるし、組み込み用ライブラリが増えるといいな

41:デフォルトの名無しさん
05/11/07 01:22:56
だれか >>28 に答えて。俺も気になる。

Flash や Laszlo は ActionScript じゃないの？
ていうかさすがにこういう話題のときは ECMAScript って言おうよ。

42:デフォルトの名無しさん
05/11/07 01:25:04
まあESだな。エンジョイプログラミング復興のためにもスクリプトアプリには頑張ってもらいたい。

43:デフォルトの名無しさん
05/11/07 01:30:16
JavaScriptの開発はデバッグが苦しい、
というのは旧世代的な思い込みでしょうか。

44:デフォルトの名無しさん
05/11/07 01:33:06
>>41
URLﾘﾝｸ(www.google.com)
URLﾘﾝｸ(www.google.com)

45:デフォルトの名無しさん
05/11/07 01:33:45
IEならスクリプトデバッガがあるし、狐ならJSコンソールがある。
変数監視系のデバッグツールまでいくと聞かないけどね。

46:デフォルトの名無しさん
05/11/07 01:44:24
>>45
デバッガの有無というより、形無し言語だからでは?

47:41
05/11/07 01:51:57
ははぁ、どっちもarityメソッドとか使って
ライブラリにできなくもない、という感じですか。
勉強になりました。ありがとう。

48:デフォルトの名無しさん
05/11/07 01:53:40
ふむ。しかしまぁ、JSでデバッガが必要な規模のコードなんて書かないけどねぇ。
Ajaxなら必要なのかも知れんけど1000行程度の外部JSファイルで1アプリ分かけない？

49:デフォルトの名無しさん
05/11/07 02:02:09
デバッグツールなんて、ベースがLISPだったら簡単に作れるのにね。
こういうレベルの話ばっかだからダメなんだよ。
わかれよ。

50:43
05/11/07 02:09:10
かつては、型がない、開発環境がない、実装間の互換性がない、の三重苦でしたが、
後ろ2つまではわりと解決されてるっぽいですね。
型はまあ、趣味の問題かなぁ。

>>49
言語ユーザとしての話に過ぎませんでしたね。すみません。

51:デフォルトの名無しさん
05/11/07 02:14:09
コードでエラーはなくともIEが突然落ちるJSはまだまだ怖い。

52:デフォルトの名無しさん
05/11/07 04:27:21
そういや、前スレの埋め立て時に出てた話題だケド、
GCまで作ってる人って、そんなに珍しいの？
俺の作ってる俺スクリプトでは、今、GCを作ってる途中なんだが・・・

53:デフォルトの名無しさん
05/11/07 05:11:32
そんなに珍しくも無いんじゃない？明示的削除構文の無い言語でオブジェクト
をサポートする言語なら必須でしょ。値,文字列,配列のサポートのみで
配列内に配列を入れない制約をして良いならリファレンスカウンタで処理できるけど

ただ自分の場合はCのスタックを直にスキャンするような方式にはしなかった
けど、その分ちょっと処理が重くなったかもしれない

54:デフォルトの名無しさん
05/11/07 05:15:20
ECMAScript作った時はクロージャサポートの為構文木もGC対象にしなきゃいけなかった
んでちょっとめんどくさかった、それ以外良い方法が思いつかなくて

55:デフォルトの名無しさん
05/11/07 05:27:44
このスレ的にはファイナライザってどうなんでしょ、俺言語でnativeのdll呼び出し
できるように作った都合上native側で確保したリソースの管理・エラーレポート用
にファイナライザを実装したのですが、GCとの相性が悪くてかなり気持ち悪い思い
気分だったのですが

56: ◆LispYaxRvY
05/11/07 06:54:53
>>55
GC対象になったファイナライザ付きオブジェクトは、
ファイナライザ用のスタックに一端退避して保護対象にする。
GC後にそのスタックの各々に対してファイナライザを起動、
処理が終わったオブジェクトは処理済みマークか何かを付けて保護から外す。
処理済みオブジェクトは次回のGCか何かで回収する。
こんなんでどうかな。

57:デフォルトの名無しさん
05/11/07 07:03:38
>>31
俺はLispは知らないECMAScripterなんだけれど、
ラムダが利用できますってどういう意味なんだろう。

クロージャは頻繁に利用しています。便利すぎる。

58:デフォルトの名無しさん
05/11/07 07:56:47
>>56
ふむふむ、現状ではGC実行中に全てのGCを止めた状態でファイナライザを実行して
いるのですが、そのように2本化してしまってファイナライザ実行中は通常GCのみ許可、
ファイナライザ処理のみ禁止としてしまう方が融通効きそうですね、アドバイス
ありがとうございます、早速検討してみる事にします。

59:14
05/11/07 08:11:32
>>52
>GCまで作ってる人って、そんなに珍しいの？

珍しいと思い込んでる妄想クンがひとり暴れてただけでしょ。

60:デフォルトの名無しさん
05/11/07 08:11:43
>>57
ラムダは無名関数リテラルが扱えるという意味で、括弧のバランスはLISPの
大量の括弧を書く話と対比してと受け取った、間違えてるかもしれないけど。

ECMAScriptはクロージャにおけるthisが呼び出しコンテキストに左右されてしまい
必ずしもオブジェクトを指しているとは限らない所と、感情的にだけど宣言なし
で未宣言の変数を使った時に宣言先がグローバルになる所、それからクラスメンバ
の未宣言がエラーにならない所が気持ち悪く感じた。

最新の4th(普及してないけど)での型宣言の書式も冗長な気がするし
でも文句は多いけど頑張って欲しいとは思う。

61:デフォルトの名無しさん
05/11/07 08:16:09
>>60
クロージャにおけるthisが呼び出しコンテキストに左右されるのは
クロージャがある以上当然の設計だと思うんですが。ActionScriptもそうだね。

左右されないthisを使いたいなら、例えば次のように書けばいいはず。
var constThisFunc = function(instance) { return function(x,y){/*real function using 'instance' instead of 'this'*/}; }(this);

62:デフォルトの名無しさん
05/11/07 08:30:24
>>60
なるほど、無名関数のことでしたか。
ありがとうございます。ラムダについては機会があれば詳しく調べてみます。

63:デフォルトの名無しさん
05/11/07 08:33:11
>>61
そそ、そこでthisをクロージャメインと考えると妥当なのだけど、一応オブジェクト
機能もあるのでthis==オブジェクトと考えたい部分もあって、例えば

var a=new Foo();
eventList.add(a.onMouseDown);

みたいな書き方をしたいと、確かにコンストラクタに相当する関数の先頭で
var me=this;
などとしてクロージャコンテキストに入れてしまえば良いだけなんですが、
言語標準の機能としてあればもっと安心かなぁ、という所です。

ActionScriptはそもそもECMAScript実装なので基本的には同じでは？

64:デフォルトの名無しさん
05/11/07 08:37:58
>>63

> などとしてクロージャコンテキストに入れてしまえば良いだけなんですが、
> 言語標準の機能としてあればもっと安心かなぁ、という所です。

なるほど、早とちりすまんでした。
最近は癖でthisを必要が無くても常にクロージャに含めてしまっているので、
いまや何の違和感もないですが、言われてみれば言語標準の機能として
自分自身のオブジェクトを指すキーワードを入れても不自然ではないですよね。

> ActionScriptはそもそもECMAScript実装なので基本的には同じでは？

知らなかった、恥です。

これだけ普及しているのに、なかなかECMAScriptの開発環境出てこないなぁ…

65:デフォルトの名無しさん
05/11/07 10:16:50
実装依存な仕様が多くて、一般的なものを作っても無駄なんじゃなかろうか

66:デフォルトの名無しさん
05/11/07 10:46:27
ちょっとスレ違いかもしれないけど、VBで構文解析しようと思ったらこれ！っていう
ツールある？lex/yaccみたいなのあったら知りたい、、、
現状再帰下降構文解析とかちまちま書いてるんだけど、、、

67:デフォルトの名無しさん
05/11/07 15:11:20
実装依存な仕様というか、仕様範囲外のライブラリが多いからね。
あと、組み込み用途がほとんどだから、ES開発環境自体も
ホームページエディタやFlash MXなど組み込む対象物の開発環境に
組み込めないといけないのも難しいし、今さら感もある。

ところで、俺言語にJSを組み込ませてみたいと思ってるんだけど、
こういうアイデアを実現した言語って既出？
俺言語は関数型言語なので、
手続き型で書きたいところはさっくりJSでかけるよー、
って感じにしたいんだけど。実行速度は気にしてない。

let f x = g (x - 1)
function g(x) { return f(x + 1); }

みたいなのが書けるの。

68:デフォルトの名無しさん
05/11/07 15:40:23
>>67
関数型言語に手続き型記述を埋め込むという話なら、
それこそ前スレで大人気(w)のlispのprog形式とか、
もうちっと今時の言語ならHaskellのMonadとか。

言語に他の言語要素を埋め込むという話なら…
CにSmalltalkを埋め込んだObjective-Cとかかなぁ。

69:デフォルトの名無しさん
05/11/07 18:09:08
Lispの次は俺言語かw

70:デフォルトの名無しさん
05/11/07 18:15:51
だがそれがスレの趣旨にはあってるからなｗ

71:デフォルトの名無しさん
05/11/07 19:55:50
俺言語は隔離すれでやってくれよw

72:デフォルトの名無しさん
05/11/07 20:04:12
>>71
はぁ？

73:デフォルトの名無しさん
05/11/07 20:07:51
隔離スレかどうかは知らないけど、過疎ってるスレ結構あるからな～。
少数で占有すんのもアレなんで、そっちを有効活用するのもアレかと。

74:デフォルトの名無しさん
05/11/07 20:11:46
>>71
はぁ？

俺言語にLispもいれろw

75:デフォルトの名無しさん
05/11/07 20:12:55
俺言語といえば
スリムドカン？だっけか
どうなったんだべ？

76:デフォルトの名無しさん
05/11/07 20:15:07
>>75
宣伝乙ｗ

77:デフォルトの名無しさん
05/11/07 20:17:12
>>75
おみゃーらはようｗ
おみゃーらはようｗ

78:デフォルトの名無しさん
05/11/07 21:00:10
>14
遅レスだけど。
おいらだったら a') ローダを実装して別ファイルの俺言語ソースを読み込む
ですな。
俺言語ソースを変更するたんびに再コンパイルはちょっとスマートじゃないね。
最近のPCは速いからあまり気にする必要がない、つうのはあるかもしれんが……

79:デフォルトの名無しさん
05/11/07 21:25:22
>>78
インタプリタ本体＋標準拡張ライブラリは1ファイルに
という制限があったと思った。

80:デフォルトの名無しさん
05/11/07 21:29:58
>>79
俺様言語の仕様ぐらいちゃんと覚えとけw

81:デフォルトの名無しさん
05/11/07 21:31:45
質問ですけれど、自分言語ってどういうときに必要になるんですか？

82:デフォルトの名無しさん
05/11/07 21:43:18
Lispと一緒で、勉強なり研究なりするとき。
あと、夜のおかずかな？w

83:デフォルトの名無しさん
05/11/07 21:52:30
>>81
特定のドメインに特化した言語を作ることで
開発効率を上げたりとか。

84:デフォルトの名無しさん
05/11/07 21:54:06
>>83
COBOLだな？
俺もそろそろDB直結も可能なCOBOLスクリプトが欲しいと思ってたとこだ。

85:デフォルトの名無しさん
05/11/07 22:00:34
>>82-83
ありがとう。

何らかのフォーマットに対するパーサまでなら良く作りますが
言語を解釈するところまで作ったことはありませんでしたが、
このスレで自分言語を作っている人が多くて、
もしかして何か知らないメリットみたいなものがあるのかと質問しました。

86:デフォルトの名無しさん
05/11/07 22:21:56
>>82 いいかげんウザイ。キモすぎる。Lisp と共に消えてくれ

87:デフォルトの名無しさん
05/11/07 22:27:56
>>85
俺言語があれば他人が作った気に入らないクソ言語でストレス溜めながら
書く必要がなくなるじゃん。それだけでもメリット。
例えばJavaがクソ言語だと思ってる人が仕事か何かでクソで書かなきゃ
いけなくなった時、Javaで俺言語を作って仕事を俺言語で片付ければ２度おいしい。
クソ言語上に俺言語を作っておけば以降のクソ言語の仕事でも俺言語上だけで
仕事できるし、そういう人は俺言語を弄ってるだけで楽しいだろう。
クソ言語から早急に離脱するためには、それなりの俺言語の設計をする
必要があるけど、クソ言語だけで仕事をする苦労に比べたらマシだし
モチベーションにも繋がると考えるだろう。俺言語のためならクソ言語で
書く作業もあまり苦にならないはずだ。
他にも、もしかするとそれでクソ言語の勉強にもなるかもしれない。
あるいはクソだと思っていた言語の良いところが見えて改心するかもしれない。
逆にクソ言語はどこまで行ってもクソだったと確信するかもしれない。

88:デフォルトの名無しさん
05/11/07 22:30:31
>>87
それってオナニーではないでしょうか？

仕事は他の人と一緒にやるものですよ

89:デフォルトの名無しさん
05/11/07 22:31:48
>>88
俺言語はオナニーに決まってるだろ。
それ以外の何かだと思ってる奴はきっと勘違いしてる。

90:デフォルトの名無しさん
05/11/07 22:33:05
>>87
クソ、クソとずいぶんお下品だと見受けられますね。

91:デフォルトの名無しさん
05/11/07 22:41:19
ゲーム作ってると使うよー。
デザイナーにパラメータいじってもらうのとか、
コンパイルせずに修正する箇所があるときに使う。
実行形式の再起動なしで、挙動を変更したり、テストが楽になる
でも最近、Luaとか既存のLLでいいじゃんという気がしてきた。
俺言語メンテまんどくせ。

92:デフォルトの名無しさん
05/11/07 22:43:38
>>90
やっぱ上品に「うんち」って書かなきゃね。

93:デフォルトの名無しさん
05/11/07 22:44:00
オナニーですよ　(*´∀｀)
飽きたら捨てるで問題ないでしょー。

94:デフォルトの名無しさん
05/11/07 22:46:45
オナニーがセックスまで進化したのがLISP

95:デフォルトの名無しさん
05/11/07 22:50:20
そろそろ倦怠期

96:デフォルトの名無しさん
05/11/07 22:51:37
>>94
あーなるほど、ぼこぼこ子供(方言、派生言語)が出来上がる意味ではな。

97:78
05/11/07 22:58:00
>79
その制限て何か意味あるの？タダのクソ仕様にしか見えんが……

>81
個人的に一番多いのが、自作アプリなんかの設定ファイルかな。
最近はXML使うことも多いけど、ルールは結局自分で決めなきゃいかんからね。

98:デフォルトの名無しさん
05/11/07 23:15:14
今度は四日ぶりに来たが、凄いことになってるな
読む必要なさそうだから、読まないけどよ

99:デフォルトの名無しさん
05/11/07 23:17:36
>>91
おーなるほど、確かにデザイナーさんなど、
プログラムに慣れていない人のために書くのはありそうですね。
言語というより設定ファイルとパーサみたいな印象でしょうか。

>>97
上を書いてからこのレス読みました。確かに設定ファイルも言語ですよね。

100:14
05/11/07 23:17:50
>>97
>その制限て何か意味あるの？タダのクソ仕様にしか見えんが……

インストールが楽。実行形式ひとつ、パスの通ったところに投げ込めば
動くってのはそれなりのメリットだと思うが。
もっと拡張ライブラリが増えて、必要なライブラリだけをオンデマンドで
読み込むとかするようになったら別ファイルにもするけど、今のところ
実行形式単体で動くのはメリットだと思ってる、ってこと。

まあこれをメリットだと思わない人もいるだろうけどさ。

101:14
05/11/07 23:35:37
しまった100getしとくんだった…
なんてくだらん話は置いといて。

>>55
うちの言語では、ネイティブ側で確保したオブジェクトへのポインタ型に
ファイナライザを付けられるようにしてる。それ以外のオブジェクトにはなし。
あとで知ったんだけど、Luaもそんな感じらしい。ていうかLuaの場合は、
確保の逆順にファイナライザを呼ぶことを保証してるらしい。

>>56
>ファイナライザ用のスタックに一端退避して保護対象にする。

ええと、このスタックから参照張られたオブジェクトについてファイナライザ
走らせる前に、これらのオブジェクトを起点にしてまたmarkするのでしょうか?
この解釈であってる?

102:デフォルトの名無しさん
05/11/08 00:41:05
>>9
そのわりにテンプレには入ってないな

103:デフォルトの名無しさん
05/11/08 04:01:29
相談室八になって、多少はまともになったなw
まぁ、他の擦れでもそうだけど、嵐って擦れ変わりで無くなるもの。

ところで、その俺言語公開してんの？名前だけでもさらして見れば？

104:14
05/11/08 08:08:50
>>103
まともに公開してるんならこんなとこで名前晒すバカはいないと思うが。

こんなこともわからずに、本当に作ったんならupしろ! できないなら脳内言語だ!
とかわめくキチガイがいたから、前スレは荒れたんだよな。
# あのキチガイは誰も彼も脳内で同一人物化してたしなw

105:デフォルトの名無しさん
05/11/08 08:12:14
語るに落ちるというやつですね。
誰もまだ何も言っていないうちから脳内言語脳内言語とｗ

こんな場末の空間で作れもしないものを作ったとアピールするのは
無駄な努力なのでやめたほうがいいと思いますｗ

106:デフォルトの名無しさん
05/11/08 08:48:36
>>105に同意
手探りでレスするのも情報の小出しを食らうのも鬱陶しい

107:デフォルトの名無しさん
05/11/08 08:51:55
>>106
小出しというが、情報を与える側から見れば　「与えなければならない情報をどこまで削れるか」　なんだよな。
いきなり膨大な量の情報を与えられても、それはそれで困るぞ。

昨日思い知った。

108:デフォルトの名無しさん
05/11/08 08:53:43
んー。VBでparser作る時みんなどうやってんだろ？不思議不思議。

109:デフォルトの名無しさん
05/11/08 10:13:32
なんで単なる相談や経験やアイディアの提示が
「作れもしないものを作ったとアピールする」
と読めるのかが不思議。
もしかして当人がアピールしたくて仕方ないけど何も作れなくて悔しいのかな？

110:デフォルトの名無しさん
05/11/08 10:16:25
>>108
VB使うようなプロジェクトでは普通はパーサなんか作らないからです！

…とか言い切ってみる。
まぁXMLの形式に載せてXMLパーサとか使うんじゃないの？
VBやったことないけどMSXMLのDLLくらいなら呼べるんでしょ？

111:デフォルトの名無しさん
05/11/08 10:20:30
>>108
LLで手作りなら全く問題なかろう？
パーサジェネレータが無いとつらい文法ならそもそもＶＢと言う選択肢棄てるだろうし
ＶＢ自体で済みそうな話の部分に自前文法の言語実装する必要あるとは思えないし。

112:デフォルトの名無しさん
05/11/08 10:36:58
>>111
手作りの場合、漏れは構文解析よりも字句解析のほうが
コードが泥臭くて面倒だなー。
適当にやっつけるにせよ有限オートマトン作るにせよ。

113:108
05/11/08 12:15:17
はぁ、、、そもそもVBでこんなことするのがおかしいのか、、、ショック

実は設定ファイルを書くための簡単な自分言語？が必要なんです。
その設定ファイルは現場の人に書いて貰う予定なんで、あまり難しいの無理だし。
がんがって書くか、、、

114:デフォルトの名無しさん
05/11/08 13:20:33
>>113
ならLL文法で十分ぢゃないか。
LL系の学習用の簡単なソースならMicroPlan(パスカル系でセルフコンパイラのソースが付いてた）
とか言うのが大昔のBitに掲載されてたから図書館で探してみれば？

115:114
05/11/08 13:22:10
これね
URLﾘﾝｸ(www.google.co.jp)

116:デフォルトの名無しさん
05/11/08 13:34:18
>>113
設定ファイルならDTDも簡単に書けそうだし、
もうオリジナル言語なんかやめてXMLにしちゃえｗ
一々オリジナル言語設計するより作成もメンテも楽だぞ。
ツールも揃ってきてるし検証パーサ使えば検証もサボれるし。
XSLでHTMLに変換すれば整形表示も簡単ｗ

117:デフォルトの名無しさん
05/11/08 13:39:01
XMLのおかげで、パーサを書く手間がずいぶん減った気がする。
既に存在しているフォーマットを読むとき以外は使わなくなった。

118:デフォルトの名無しさん
05/11/08 13:58:23
VisualBasic XMLでググってみると
URLﾘﾝｸ(kamoland.com)
こんなページがあった。どうやら割と簡単に使えそうじゃないか。

119:デフォルトの名無しさん
05/11/08 14:51:38
果てしなくどうでもいいことだけど、日本人は何でVisual Basicにスペース入れずに書くの？

120:デフォルトの名無しさん
05/11/08 14:54:30
>>119
果てしねーーーーー

121:デフォルトの名無しさん
05/11/08 14:57:38
分かち書きで単語を区切る言語圏に居ないからじゃないのか？

122:118
05/11/08 15:26:02
>>119
漏れの場合は：
スペースはデフォルト設定のMS-IMEでは変換キーなため
日本語入力時は一続きの入力が終わって意図的に変換するとき以外は
スペースキーに触らない。
大文字でスタートするIMEの英字入力モード中はスペースは変換でなく
スで、ペースになるのではあるが、やっぱり触るのに心理的抵抗があり、
入れなくて済むものは入れずに済ましたい心理的傾向がある。
多分それが原因。

123:118訂正
05/11/08 15:27:00
スで、ペース→スペース

124:108
05/11/08 15:42:04
XMLか、、、勉強不足で良く分からないんだけど、例えば、

if (isExist("hoge")) i+3; else i+2;

みたいな条件分岐も何とかなる？

125:デフォルトの名無しさん
05/11/08 15:56:39
「設定ファイル」内でどの程度の計算記述能力が必要かにもよるが、
条件分岐を表現するエレメントを書けば書けない事はなかろう。
（例えばmakeのような働きをするANTのファイルはXMLで書かれている。
あるいはXSLスタイルシートはそれ自身XML形式で、
関数型言語スタイルでかなり複雑な変換処理が書ける）
ただ条件付設定ファイルレベルならばいいが
本格的な汎用スクリプトが必要になるようだと
XMLでは不可能ではないまでもあんまりおいしくなくなる可能性はある。
設定ファイルでどんな種類の条件分岐や計算が必要になるかを
把握することが鍵。

126:デフォルトの名無しさん
05/11/08 16:31:29
>>125
つかそんなXMLを生エディタで書かされる方はたまらんだろう。
108が設定ファイルをXMLにするのなら、むしろそのＸＭＬを生成する条件設定アプリ作る方がマシじゃなかろうか？

127:デフォルトの名無しさん
05/11/08 17:24:44
>>126
いずれにせよ「設定ファイル」として想定される内容次第だな。
ある程度定まったパターンの処理ばかりであるならXML化してもいいが
汎用スクリプト言語的でどんな種類の処理がかかれるかについて
設計時に把握しきれないなら
そもそもXMLを選ばないほうがいい可能性が高いし…。

別の言い方をすれば、主に値や型の宣言が並ぶスタイルならXML向きだが、
複雑な制御フローや汎用の演算セットがあるようなら向かない可能性が高い。
XMLは元来「文書」を表現するためのものだから
「設定ファイル」の性質が「文書」に近ければXMLで比較的表現しやすいし、
「文書」から離れて手続きプログラム的になるとXMLでは段々表現し辛くなる

条件設定アプリはその中間くらいの複雑さのときの解だな。

128:デフォルトの名無しさん
05/11/08 18:07:45
>>124
あくまでも一例
<if test="isExist('hoge')">
<true>i+3</true>
<false>i+2</false>
</if>

実際はXSLなどを参考にしつつもうちょっとマシなのがいいと思うけど。

129:デフォルトの名無しさん
05/11/08 18:14:01
XMLなんて馬鹿の思いつきだよ。
する～よろ>>ALL

ところで、俺言語いいじゃないか。
どんどん語ってくれ！

130:デフォルトの名無しさん
05/11/08 18:24:45
>>129
そういう根拠を述べない決め付けはよくないな。
技術者ならば各手法の選択に当たって目的に対する得失を比較せねばな。

>>127、>>125でも述べた通り、
XMLを使ったほうが開発・維持の手間が減らせる場合は確かにある。
逆に使わないほうがいい場合もある。万能な方法はない。

131:デフォルトの名無しさん
05/11/08 18:42:53
データ構造を記述するだけの場合にはXMLは非常に優れた能力を持つよね。
でもプログラムを記述する場合にXMLを使う例は今のところあまりないと思う。
JavaMLなんてものもあるけれど、あれは構文木をXMLにしただけだし（うろ覚え）。

132:108
05/11/08 18:48:24
んー。XMLでもできそうな気がしてきた。VB使う限りはXML使うのが楽っぽい。
VBはもう終っちゃう言語だろうけどさ、、、
一応XML使ってみるよ。条件分岐が少し多いだけで、多分、そんなに複雑にはなら
ないから多分大丈夫かと。

133:デフォルトの名無しさん
05/11/08 18:57:28
>>131
代入や演算、一般的な条件分岐などで
データ・フローやコントロール・フローが複雑になると
XMLではおそらく読みにくくなる。
データ構造記述は比較的それらが単純で局所的な要素が多いからな。

ANTなんかはタスクの依存関係を記述してプログラムのビルドやセットアップを行う
スクリプト的側面を持つが、処理のパターンが依存関係とコマンドというように定型的で
宣言的だからXMLでも比較的追いやすい。

もう一つの基準はスクリプトや設定ファイルの処理で
ツリー構造を作るところまでの仕事が占める割合だな。
データ構造記述の場合パースしてツリーができればかなりがとこ仕事は終わっている。
タスクの依存関係を記述するANTの場合も然り。
けれど代入や分岐などを認め複雑なデータフローや
コントロールフローなどを処理する必要が生じるとツリーを作った後が中心になってくる。
XMLパーサを使うことでコストが減るのはパースする部分までだから、
ツリーなどのデータ構造を作った後の処理の比重が重いと旨みは減る。

134:デフォルトの名無しさん
05/11/08 19:04:01
もう一つXML使ってメリットがありうるのはスクリプト自身を処理する
スクリプトを書くなどメタな処理をする場合だな。
スクリプト自身をデータとして処理する予定がある場合や、
XPathなどを駆使してXMLファイル内にXMLファイルの構造を辿るような記述を埋め込む場合だ。
XSLやXML Schemaなどはこのような例だな。

135:デフォルトの名無しさん
05/11/08 19:18:46
XSLTはかなり良く設計されていると思う。XML Schemaはノーコメント。

あと、企業独自言語で、XML内にスクリプトを埋め込むというのを何度か見た。
SVGとかも確か、スクリプト(ECMAScript?)をエレメントの中に記述したよね。
よく考えれば、SVGをいうまでもなくXHTMLもそうか。

136:デフォルトの名無しさん
05/11/08 19:37:30
>>128
うへえ。
いろんな意味でLISPのS式の方がいいじゃん。

137:デフォルトの名無しさん
05/11/08 19:48:04
みんな! 136がVB用のLispパーサを書いてくれるそうですよ!

138:デフォルトの名無しさん
05/11/08 19:48:36
>>136 ログ嫁

139:デフォルトの名無しさん
05/11/08 19:52:00
ばかかお前ら？
XMLのコンテンツとして、文をいれる訳？？？
まだ、*ispの方が遥かにいいよw

140:デフォルトの名無しさん
05/11/08 19:53:13
ん、配列扱える言語なら基本的なLISPぐらい書けるでしょ。
VB使う機会があったら書いてみるよ。

141:デフォルトの名無しさん
05/11/08 20:07:38
いや、、お前らよく考えろ。XMLなんて素人に書けないぞ。結局XMLを生成する
アプリ作る必要が出てくるに違いない。いや、中間言語としてXMLを使うのは
悪くは無いかもしれんが、、、

142:デフォルトの名無しさん
05/11/08 20:14:25
>>141
その通りだが、Lispもそうなんだよな。デザイナーが書ける言語って何だろう。

143:デフォルトの名無しさん
05/11/08 20:17:42
デザイナーとプログラマーのプログラミングに対する意識は人それぞれといえまったく違うみたいだしなぁ

144:デフォルトの名無しさん
05/11/08 20:36:48
設定ファイル解釈系相談室、の方が実態に即してるんじゃないか、このスレ。

145:デフォルトの名無しさん
05/11/08 20:58:04
>>142
素人受けして、文法に柔軟性がある言語があるが、
あえて名前は書かないw

146:デフォルトの名無しさん
05/11/08 21:10:57
>>145
ほほぅ、、もしかして「日本語」か？

147:デフォルトの名無しさん
05/11/08 21:12:48
>>145
詳しく

148:145
05/11/08 21:13:20
>>146
その通りw

149:デフォルトの名無しさん
05/11/08 21:45:40
りんごタソは、やまとなでしこ。

150:デフォルトの名無しさん
05/11/08 21:51:52
>>142
素朴な疑問だが、どこから「デザイナー」が出てきたんだ?

設定ファイルにLispというと、.emacs.elの感覚かねえ…
素人にはお勧めできないわな、そりゃ。

151:デフォルトの名無しさん
05/11/08 22:17:56
>>150
あ、ごめん、俺は昔デザイナーがカスタムタグベースのJSPを書けなくて
ショックを受けて、プログラムをする必要のある素人といえばデザイナーが
脊髄反射で出てきてしまった…

152:デフォルトの名無しさん
05/11/08 22:43:01
>>108&113
ここでこういうレスを入れるの自体スレ違いかもしれないけど、iniファイルじゃ
駄目なの？制御構文が絡まなければ別段パーサなんて作る必要性感じないんだけど

153:デフォルトの名無しさん
05/11/08 22:51:32
>>101
>うちの言語では、ネイティブ側で確保したオブジェクトへのポインタ型に
>ファイナライザを付けられるようにしてる。それ以外のオブジェクトにはなし。

成程成程、自分の場合作っているのがECMAScriptのスーパーセットなもので
その辺はファイナライザを指す特定のシンボルを動的検索です、ちょっとオーバー
ヘッドが気になるのだけど致し方無しという所です。

>ええと、このスタックから参照張られたオブジェクトについてファイナライザ
>走らせる前に、これらのオブジェクトを起点にしてまたmarkするのでしょうか?

うちの場合も構文木でスタックは持ってないんだけど、要はオブジェクトリスト
を管理している所を2本化してチェック走らせれば良いのでは、と理解しました。

# ちなみに構文木辿っている途中の中間計算で使用されているオブジェクトは
リファレンスカウンタ介してGC時に除外する方式取ってます、ちょっとオーバーヘッド
あるけど。

154:デフォルトの名無しさん
05/11/08 23:30:51
デザイナー自体は>>91で出てるね。

デザイナーが書ける(こともある)プログラミング言語というと、
やっぱりFlashのActionScriptじゃないかな。

155:14
05/11/09 00:15:53
>>153
うーんと。
ファイナライザがあるとGCが厄介だ、というのは、ファイナライザの中で
thisをグローバル変数か何かに放り込まれると、オブジェクトが「復活」する
からだよね?
んで、復活するのは、ファイナライザを呼ぶオブジェクトそのものだけでなく、
そのオブジェクトから辿れるオブジェクトすべてだから、
>ええと、このスタックから参照張られたオブジェクトについてファイナライザ
>走らせる前に、これらのオブジェクトを起点にしてまたmarkするのでしょうか?
と書いたわけだけど。ただ、今読み返すと、>>56氏も>>58氏も、そんなことは
当然として書いてるように思える。恥さらしましたかね。

ちなみに.NET FrameworkのGCについて以下のページに説明があって、

URLﾘﾝｸ(www.microsoft.com)

下の方に、ファイナライザを含むオブジェクトのGCの話も書いてある。
でも、俺にゃ「完結キュー」がなぜ必要かわからないし(オブジェクトごとの
フラグじゃいかんの?)、復活の話も書いてあるけど、.NETのGCがどう対処してる
のかもよくわからない… 俺がアホなのか。

156:デフォルトの名無しさん
05/11/09 10:53:26
>>141
素人さんにはXMLに限らずどんな形式言語でも書けない。
だからユーザとして想定する相手の技術レベルよっては
どのみち設定ウィザードみたいなものは必要。

157:デフォルトの名無しさん
05/11/09 11:02:10
>>152
どっちみち.iniファイルの中の仕様を決めねばなるまい、
あれだって単純とはいえ一応形式言語だぞ？

それと>>124を見る限り、
>>108は簡単な設定ファイル内で簡単な条件判定くらいはするつもりらしい。

次ページ