「コンパイラ・スクリプトエンジン」相談室14at TECH
「コンパイラ・スクリプトエンジン」相談室14 - 暇つぶし2ch1:デフォルトの名無しさん
09/11/17 13:12:25
禁止事項【臨時】
・前スレの911自身の書き込み、またそれに関連した書き込みを禁止致します。
 (スレが荒れる原因となります)

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

過去スレ
1 URLリンク(pc.2ch.net)
2 スレリンク(tech板)
3 スレリンク(tech板)
4 スレリンク(tech板)
5 スレリンク(tech板)
6 スレリンク(tech板)
7 スレリンク(tech板)
8 スレリンク(tech板)
9 スレリンク(tech板)
10 スレリンク(tech板)
11 スレリンク(tech板)
12 スレリンク(tech板)
前スレ 13 スレリンク(tech板)
関連リンクは多分 >>2-10 あたり

2:デフォルトの名無しさん
09/11/17 13:13:56
Wikiのまとめページ
URLリンク(www6.atwiki.jp)

★コンパイラ一般

・色々なツールの紹介
 URLリンク(catalog.compilertools.net)
・コンパイラ関連のリンク集
 URLリンク(www.ulis.ac.jp)
・スクリプティング言語資料室(仮) (リンク集)
 URLリンク(www.kt.rim.or.jp)
・Compiler Construction
 URLリンク(www.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:デフォルトの名無しさん
09/11/17 13:15:21
★字句・構文解析

・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:デフォルトの名無しさん
09/11/17 13:17:00
★ごみ集め

・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:デフォルトの名無しさん
09/11/17 13:20:59
★学会
・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:デフォルトの名無しさん
09/11/17 13:21:55
★参考書籍

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

一部圧縮しようとしたが諦めた。
以上。

7:デフォルトの名無しさん
09/11/17 13:30:37
最近出た本
・最新コンパイラ構成技法(Modern Compile Implementation in ML(タイガーブック)の訳)
 URLリンク(www.amazon.co.jp)

・ふつうのコンパイラをつくろう
 URLリンク(www.amazon.co.jp)

・プログラミング言語を作る
 URLリンク(www.amazon.co.jp)

・やさしいインタープリタの作り方入門
・やさしいコンパイラの作り方入門
 URLリンク(www.amazon.co.jp)
 URLリンク(www.amazon.co.jp)

8:デフォルトの名無しさん
09/11/17 14:08:21
中田先生の第2版、取り次ぎに来たから少しだけ読ませて貰ったけど良い感じだった。
第一版の内容を全部覚えているわけじゃないし、ほんの数ページを見せて貰っただけだけど。

9:デフォルトの名無しさん
09/11/18 07:24:32
go最強だな

10:911
09/11/18 12:38:55
よう、愚民ども。911様とあがめろ。
本当の俺の力を見せつけるときが来たな。
中田の本で防御してドラゴンブックで攻撃だ!

11:デフォルトの名無しさん
09/11/18 14:15:33
.NET Micro Framework 4.0がApache License 2.0のオープンソースになると発表されたらしいが
オレオレ言語の実行環境として流用できるだろうか

12:デフォルトの名無しさん
09/11/18 14:59:20
よっぽど物好きでない限りCLIの上にのせる方が汎用性高くなるとは思うが

13:デフォルトの名無しさん
09/11/18 15:22:30
>>12
Windowsプラットフォーム前提であれば、そのとおりだろうな。

14:デフォルトの名無しさん
09/11/18 16:27:25
>>10
MAIL蘭。

15:デフォルトの名無しさん
09/11/18 17:15:21
>>11
MS社の囲い込み戦術か。JVMの方が汎用性が高いしJVMの地位は落ちないと思う。

16:デフォルトの名無しさん
09/11/18 17:24:54
JVMの方が汎用性が高い(キリッ

17:デフォルトの名無しさん
09/11/18 17:25:46
エロゲの話で恐縮だが、体験版をEXEではなくFLASHで遊ばせてくれる所が出てきた。
そのうちJVMで実行できるエロゲが販売されれば、OSの選択にLinuxと言うのも出てくると思う。
今はKVMでXPを動かしてるけど、JVM版が出ればMS社にOSのライセンス料を払わなくて良くなる。
ビデオテープの原動力がエロだったという事実を考えると、OSは今、officeとエロゲで選ばれてると思うからね。

18:デフォルトの名無しさん
09/11/18 17:32:19
中田先生の本、新版はハードカバーじゃないのか。本屋で見てきた。

19:デフォルトの名無しさん
09/11/18 17:49:07
>>17
それ別にJVMじゃなくてもよくね

20:デフォルトの名無しさん
09/11/18 20:47:27
>>18
ハードカバーじゃないのか。でも価格は変わっていないんじゃなかった?

>>10
防御力-1(w

>>19
クロスプラットホームのゲームならActionScriptが組みやすいね。
ActionScriptHACKを覚えるのがやっかいだけど。
Fileアクセスの場合はlocalで実行できるけど
httpアクセスの場合、local-http-serverが必用だけど。
saveオブジェクトを作らないといけないのが面倒っちゃ面倒。

21:デフォルトの名無しさん
09/11/18 20:52:36
>>18
マジか?
初版大事にしよう



22:デフォルトの名無しさん
09/11/18 20:55:44
IronActionScript

23:デフォルトの名無しさん
09/11/20 16:35:53
スレが進まない。誰か話題をプリーズ。

24:デフォルトの名無しさん
09/11/20 16:40:55
C++のコードを変換するのに十分な小さい言語を定義しない?

25:デフォルトの名無しさん
09/11/20 16:54:07
目新しさが無いな。

26:デフォルトの名無しさん
09/11/20 18:02:09
俺はすごく興味ある。スレ立ててみようよ。

27:デフォルトの名無しさん
09/11/20 19:14:21
すぐ過疎るよ

28:デフォルトの名無しさん
09/11/20 20:27:52
型推論でもどうよ

29:デフォルトの名無しさん
09/11/20 23:02:49
>>24
LISp

30:デフォルトの名無しさん
09/11/21 00:22:54
コンパイラの抽象構文木の出力がlispのソースコードっぽくなるなと思っていたら
lisp自体が抽象構文木だったんだってね

31:デフォルトの名無しさん
09/11/21 13:24:44
>>24
FORTH
ポインタ演算もバッチリ

32:デフォルトの名無しさん
09/11/21 15:18:06
うーん、話がつまらない。
この前のトライ木の実装とかif-then(とラベル管理とstack管理で)関数型言語を定義することが出来る
と言う話の方が断然面白かった。

もっと意味のある話は出来ないかな。
と言うわけで>>24を指示する。

33:デフォルトの名無しさん
09/11/21 16:43:26
それってまるっきりLISPの1実装の話なんですケド

34:デフォルトの名無しさん
09/11/21 17:30:00
>>24
>C++のコードを変換するのに十分な小さい言語
というのは、その言語が(別の何かに)変換するということ?
その言語に変換するということ?

35:デフォルトの名無しさん
09/11/21 17:32:58
Cでいいだろ

36:デフォルトの名無しさん
09/11/21 19:04:55
GNUですな。

37:デフォルトの名無しさん
09/11/21 19:13:56
ぐぬぅ

38:デフォルトの名無しさん
09/11/21 22:18:57
コンパイラ作るのに、オートマトンとかFIRST集合とかの知識ってまったく
必要ないよな

39:デフォルトの名無しさん
09/11/21 22:20:29
形式言語理論の知識は必須だろ。

40:デフォルトの名無しさん
09/11/22 03:06:53
自分の過去の経験からすれば、言語処理系(コンパイラ or インタプリタ)を
作るだけなら、形式言語理論の知識は必須とは思えないな。
カーニハンの本「UNIXプログラミング環境」を読んでyacc&lexで
C言語風のミニインタプリタを作って遊んだのが最初の経験だ。
当時はC言語の知識しか無かったけど、動く物を作ることはできたよ。

41:デフォルトの名無しさん
09/11/22 06:50:19
まあ動けばいいってだけなら本読んでコンパイラジェネレータの使い方覚えればなんとかなるだろうが、
ツール類が何をしてるのか理解するには初歩的な言語理論やオートマトンの知識は必要になってくるだろう。

42:デフォルトの名無しさん
09/11/22 06:54:41
うまくいかない時にどうしてうまくいかないか、を探るには
知識重要だな。

まぁLALRを使うならLLのための知識はいらないだろうがw

43:デフォルトの名無しさん
09/11/22 07:02:14
自分には必要ないからという理由で他人のチンコをちょん切りに行くのはどうかと思うんだ

44:デフォルトの名無しさん
09/11/22 10:15:03
>>43
どこでチンコの話が出てきたんだよw

45:デフォルトの名無しさん
09/11/22 12:35:51
俺も最初は形式言語の知識は不要だと思う。最初は逆ポーランドかS式を使うべきだと思う。

むしろ形式主義的な考え方を勉強した方がはるかに役に立つな。メタ数学オモシロス


46:デフォルトの名無しさん
09/11/22 19:17:56
良い感じになってきたね。
俺も>>45の意見に賛成。逆ポーランドから1歩ずつステップアップするのが吉。

>>41
俺はスクラッチ主義者(スピードを稼ぐため)なんだが、言っていることはその通りだな。

>>36
あんな出来損ないを作ってた奴ら(今はマシだけど)より、ここで定義した方が良い物が出来る予感。

47:デフォルトの名無しさん
09/11/22 19:39:52
出来損ないってバージョン1の頃のGCCのことを言ってるのか?

48:デフォルトの名無しさん
09/11/22 21:18:17
>>47
そう、まだ定義も決まってなかった頃の物。
GNUなんてOSも作れず、Linuxを自分たちの功績にして、
GPLでサポート等で金を稼げなんて言う奴ら。

商業ソフト(office等)の正常な商業活動が実質出来なきなくなり
ジャストシステム(エロゲ会社じゃないよw)ももうすぐやばそう。
これはMSの囲い込み政策も関連してるけど。

49:デフォルトの名無しさん
09/11/22 21:20:37
もちろん、GPLライセンスの功績は認めてるけど、
誰とは言わないがGNUの奴らは原理主義が多すぎ。

50:デフォルトの名無しさん
09/11/22 21:21:23
定義って何だ?

標準のことか?

51:デフォルトの名無しさん
09/11/22 21:26:46
>>50
そう、標準のこと。まあ、これ以上はスレチになるから辞めよう。
スレを無駄に使ってスマン。>all

52:デフォルトの名無しさん
09/11/22 23:39:48
標準って何の?


53:デフォルトの名無しさん
09/11/22 23:42:07
ああ、言語の標準の話か。
ごめん。

54:デフォルトの名無しさん
09/11/23 08:24:44
LinuxがBSDライセンスだったら今よりも良い状態だったかも
少なくともカーネル・ドライバ周辺は

55:デフォルトの名無しさん
09/11/23 12:22:18
言い出しっぺがやめようと言ってる話題をひきずるなよ。

56:24
09/11/23 21:28:33
>>51は私じゃないし…

57:デフォルトの名無しさん
09/11/24 13:22:10
>>56
やめようといってるのはライセンスがらみの話のことじゃないの?

58:デフォルトの名無しさん
09/11/24 17:35:52
つーか24も意味不明なんだが。
何をしたいの?

59:デフォルトの名無しさん
09/11/24 19:38:02
みんな >>24 に書かれていることを理解できてるのかな?
俺には理解できない…。

>>24>>34 の質問に答えてほしい。

60:デフォルトの名無しさん
09/11/24 19:44:04
>>24の言いたいのは、C++コンパイラ用の中間言語として十分な仕様を持った
小さな言語を定義したいってことじゃないの?別に意味不明だとは思わんかったけど。
たとえば、C++用というわけじゃないけど、C--とかあるよね。
URLリンク(www.cminusminus.org)

61:デフォルトの名無しさん
09/11/24 20:50:22
>>60
たとえば、がどこに掛かってるのか意味不明なんだが。
C--が何?
中間言語なら既存のものに合わせれば十分じゃないか。
君の意図もさっぱり判らん。

62:デフォルトの名無しさん
09/11/24 21:02:35
「既存のもの」のひとつとしてたとえばC--がある、と思うのだが?
なににつっかかってるんだ?

63:デフォルトの名無しさん
09/11/24 21:05:48
C--は中間言語じゃないし

64:24
09/11/24 21:13:30
私が言いたかったのは、まさにこの様な言語の事です。
今ダウンロードしたファイルを読んでる最中です。
>>60さん、どうもありがとうございます。

65:デフォルトの名無しさん
09/11/24 21:15:29
え?

66:デフォルトの名無しさん
09/11/24 21:27:16
なんてこった!
すごいなーえすぱーはいたんだなー

67:デフォルトの名無しさん
09/11/24 22:56:42
>>63
プログラマがC--でソースコードを直接書き下すことが想定されてるとでも?
ドキュメントと仕様見る限りではとてもそう見えないが。

68:デフォルトの名無しさん
09/11/24 22:57:52
Cのリテラルは対称性無さすぎ/再帰効かなすぎだから中間言語化なんて考えない方が……
そういう目的には木構造を表現できるS式 or 命令の連なりとして処理できる逆ポーランドが最適だってば。

69:デフォルトの名無しさん
09/11/24 23:00:16
>>68
C--はCと同列に扱っちゃだめだってば。少なくとも、Cよりははるかに機械生成されることを
想定してかなり低レベルなところまで扱える仕様になってる。つか、なんでそこで逆ポーランドとか
S式が出てくる?逆ポーランド(記法)とかS式はメタ言語であって、それ自体で何か意味のあるもの
じゃないだろ。

70:デフォルトの名無しさん
09/11/24 23:18:11
そう言われてみればそうかもね。
>24の字面からメタ言語の話かと思ってた。

71:デフォルトの名無しさん
09/11/24 23:31:55
メタ言語ってすごく意味の薄い言葉だね。

72:デフォルトの名無しさん
09/11/24 23:47:36
S式と逆ポを一括りにされると違和感が



73:デフォルトの名無しさん
09/11/25 00:01:26
結局俺言語作っても使わない。
だからまず最初に俺言語Cトランスレーターを作る。可逆でな。
C→俺言語
俺言語→C
これで俺言語の役立たず度が計れる。
作れない→論外

74:デフォルトの名無しさん
09/11/25 00:23:06
俺言語で俺言語をビルドできれば神

75:デフォルトの名無しさん
09/11/25 01:00:51
>>73
C++テンプレートやLispマクロのようなコード生成を含む機構あると可逆はつらくない?

76:デフォルトの名無しさん
09/11/25 07:39:22
作る価値の薄い「パワーの無い」言語ほど>>73を実現しやすいのが
突っ込み所かもね。

77:デフォルトの名無しさん
09/11/25 08:23:15
>>60
仕様書を軽く読んでみたけど、面白いね。
C言語は構造化アセンブリ言語だと言われることがあるけど、
人間様がプログラミングすることを意識した高級言語として設計されていた。
でもC--言語は、C言語風の構文だけど、まさしく構造化アセンブリ言語だ。

78:デフォルトの名無しさん
09/11/25 09:40:48
>>72
S式は人間がリスト構造を書いてやる、
逆ポは人間がスタックマシンの機械語列を書いてやる、
どちらも機械可読(機械易読)な構造を人間が書いてやるという意味では

>>73
それって、
#define BEGIN {
#define END }
のことを「俺言語」って言ってないか?

URLリンク(minnie.tuhs.org)

79:デフォルトの名無しさん
09/11/25 14:12:27
>>78
予約語が増えるw

80:デフォルトの名無しさん
09/11/25 15:07:24
Cから俺言語はともかく、初めから俺言語をCに変換する手段はあるといいね

81:デフォルトの名無しさん
09/11/25 15:49:18
バイナリを吐くだの最適化だのといったことを
Cコンパイラに丸投げするのは悪くない話。

82:デフォルトの名無しさん
09/11/25 16:01:29
移植やクロスも楽そうだしな

83:デフォルトの名無しさん
09/11/25 16:02:55
Rubyもそれで作ってれば馬鹿にされずに済んだのに。

84:デフォルトの名無しさん
09/11/25 16:07:42
Ruby to Cのそういうものを作った例はあるよ。かなり昔だけど。
結局たいして速くならない。

メソッドを動的にディスパッチしたりとかする必要があるのは変わらないから。

85:デフォルトの名無しさん
09/11/25 16:54:49
ライブラリ作るのめんどくさい。
ところで、漏れは数値と文字列の自動変換て好きくないのだが
文字列しか変数に入らなくって、基本は正規表現風パターンマッチと変換だけの言語って
…面白くないですね。すみません。AWKみたいだし。


86:デフォルトの名無しさん
09/11/25 18:15:16
ライブラリの性能で全てが決まるよ。ガンバレ。
数値と文字列の自動変換、俺も嫌い。

87:デフォルトの名無しさん
09/11/25 23:40:40
もうライブラリを細かく実行ファイルにしちゃって
画像も音声もみんなパイプで渡せるようにするか
ファイルに作らせるかすれば、シェルスクリプトで全部できるんじゃね?
っていうか組み合わせればどんどんすごいことになっていかね?
と、石田先生のUnix入門を読んだときは思っていた。


88:デフォルトの名無しさん
09/11/25 23:51:19
64bit浮動小数点のINFとNaNの間に文字型とか入らないかな?50bitくらい使えそうなのだけど。
大富豪型プログラミングになれは、1Cell=64bitでいいよね。
もっと気張っておく?1Cell=4096byteとか。フラグメントはメモリマッパ任せとか。

89:デフォルトの名無しさん
09/11/26 13:17:20
>フラグメントはメモリマッパ任せとか。
これ昔実験したけどあんまり早くならないよ
MMU周りのコードにもよるかもしれないけど

90:デフォルトの名無しさん
09/12/04 19:00:23
>>前スレ
IF GOTOで全部の構造式が出来るか。当たり前だけど力業だな。

>>89
MMUの全面的な支援がないと難しいんじゃない?

91:デフォルトの名無しさん
09/12/05 00:42:03
>>90
R4000系でやったんだけど基本がストールで検出なんでキャッシュがコケまくるんだよね
それだったらキャッシュが十分に効くようにして世代別のGCを普通に実装した方がはやかったんだ。



92:デフォルトの名無しさん
09/12/05 02:00:10
タイガー本の和訳が出てたけど、買った人いる?


93:デフォルトの名無しさん
09/12/05 23:38:12
yanecあげ

94:デフォルトの名無しさん
09/12/06 20:50:47
もう一つの日本電気?

95:デフォルトの名無しさん
09/12/06 23:40:27
re2c+UTF32なサンプルってmonaの所の他にありませんか?

96:デフォルトの名無しさん
09/12/17 20:40:42
>・前スレの911自身の書き込み、またそれに関連した書き込みを禁止致します。
> (スレが荒れる原因となります)

kwsk

97:デフォルトの名無しさん
09/12/17 20:52:15
いちいち蒸し返すなよ.前スレ嫁

98:デフォルトの名無しさん
09/12/18 20:53:22
よめんからきいてんのよ!

99:デフォルトの名無しさん
09/12/18 21:13:37
911の事なんて語りたくもない

100:デフォルトの名無しさん
09/12/20 10:53:59
同意w

101:デフォルトの名無しさん
09/12/20 21:22:18
9.11テロか?

102:デフォルトの名無しさん
09/12/20 23:49:03
C--は既に廃れてる。
GIMPLE@gccはどうよ?

103:デフォルトの名無しさん
09/12/21 19:49:27
ATI Stream/NVIDIA CUDA両対応のC言語コンパイラ

9??の事かw

>対象のC言語の記述はforループによる繰り返し制御構造で、
>特に2重の入れ子構造をもったループを効率的に扱えるという。
>SIMD型アクセラレータ上での実行に適した演算の多くはこの形式で記述できるという

104:デフォルトの名無しさん
09/12/22 22:13:57
>>103
変数の依存性でスピードが全然違うんだろうね。
相互に依存しない物ってなんだろう?
例えばクイックソートは依存するよね。

105:デフォルトの名無しさん
09/12/22 23:25:25
911wの話が本当になったw

106:デフォルトの名無しさん
09/12/23 00:58:04
911知りたい (T_T)

107:デフォルトの名無しさん
09/12/23 13:10:30
ここのスレの方が一歩送れてたか。
911の言動は感心できないが、方向性とかはちゃんと見てたな。

そうなるとNECのベクター型とIntelの提携だな。

>>106
911が自分の考えの中にエロゲの事を必ず入れていた。
それがこのスレのエロゲを卑下する人達の逆鱗に触った。
プログラムコードがエロゲ界でも経験豊かで秀逸なコンパイラをスクラッチで作っている人が出てきたら、
40才でエロゲ作ってたら氏ね。とか罵詈雑言。
911と、そのエロゲプログラマが作ったコードでその人を見れないスレ住人の中に確執。

おれは911も悪いと思ったが、コードで人を見れない奴はイヤだな。

108:デフォルトの名無しさん
09/12/23 13:12:20
configureにも使われてるm4という汎用マクロ言語を勉強しよう

109:デフォルトの名無しさん
09/12/23 13:25:41
> プログラムコードがエロゲ界でも経験豊かで秀逸なコンパイラをスクラッチで作っている人

……

110:デフォルトの名無しさん
09/12/23 13:32:31
秀逸なコンパイラ→オールドスクールなコンパイラ
ASCII創成期かと思ったよ。
しかし作者を叩く人は少なく、変な持ち上げ方をしている奴が馬鹿にされただけ。

111:デフォルトの名無しさん
09/12/23 13:52:14
> ASCII創成期かと思ったよ。

えーなに、GAME(言語)ですか?

112:デフォルトの名無しさん
09/12/23 14:36:30
ああ、構文すらもマクロで組めるパスカルライクなゲーム様汎用コンパイラ。

113:デフォルトの名無しさん
09/12/23 14:42:21
いままで100本ぐらいエロゲを作って、
その他win3.1/95時代に色々なプログラムで稼いだ金を使って、
エロゲ会社立ててポルシェ乗り回してる成功者だね。

ブログでは引っ越しするからアーロンチェアとか
after effectとか高位物をいろいろみんなに配ってる。

114:デフォルトの名無しさん
09/12/23 14:43:20
LISPとPASCALで良い意味でも悪い意味でもOLD SCHOOL。

115:デフォルトの名無しさん
09/12/23 14:48:22
ブログ見てきた。
こんな事やっちゃって、この人は自分が妬まれる位置にいることを分かってないね。

116:デフォルトの名無しさん
09/12/23 14:52:09
いいじゃないのさ。一攫千金。金があってこそできる善行だってある。

117:デフォルトの名無しさん
09/12/23 14:52:18
話は戻すけど、依存性のないループなんてほぼ無いんじゃないか?
どういった用途に使われるコンパイラだろう。
昔、IntelC/C++コンパイラ使ったときは落胆した。VSの方が早いんだもん。
あれはライブラリの料金なのかね。

118:デフォルトの名無しさん
09/12/23 14:54:15
>>116
まあそうだけどさ。
表だってやらなきゃ妬まれないのに。
泥棒にも狙われるぞ。

119:デフォルトの名無しさん
09/12/23 14:56:31
でも、アーロンチェアとafter effectとA3スキャナとGP225は欲しいな。
田舎だから家だけは広いし。

120:デフォルトの名無しさん
09/12/23 14:58:08
>>117
ハマルと早いよ。しかし、クリティカルな部分はV-TUNEでカリカリ書いた方が速い。

121:デフォルトの名無しさん
09/12/23 15:17:07
FORTRANコンパイラ由来で、ループの直前のイテレーションにのみ依存するだとか、
行のループの間隔で依存するだとか、そういうものを検出する技法はたんとある。

122:デフォルトの名無しさん
09/12/23 15:22:14
>>121
そっか。中田氏の最適化の本は斜め読みした程度だけど、
そこまで進んでいるのか。

しかしIntelコンパイラは上手く使いこなせなかった。
PentiumのUVの2パイプを意識して手でASMを組んだ方が速かったな。
そのときはV-TUNEが役に立った。

123:デフォルトの名無しさん
09/12/23 15:33:16
>>122 いや論文レベルの話

124:デフォルトの名無しさん
09/12/23 16:15:01
スパコンのベクトル化コンパイラはある程度やってるよ。
手でコンパイラ好みのコードに書き直さないと、
ハードウェアの性能は引き出せないけど。

125:デフォルトの名無しさん
09/12/23 17:39:15
やはり並列化は大変だね。

126:デフォルトの名無しさん
09/12/23 22:44:48
9??の話を続けるのも何だし、もうそろそろ何か新しい話題に移ろう。

127:デフォルトの名無しさん
09/12/24 02:56:36
>>110
ちょっと聞きたいんだけど、大量のファイルを高速でコンパイルでき、
構文までマクロで組める汎用コンパイラをスクラッチからあなたは実際に組んだの?
実装は無しなんて言ったら何でもOKだよね?
噛みつきたいんじゃなく、そこまで自信満々だったら見せてよ。
サブセットでもいいからさ。
例の奴の話を蒸し返すのは嫌なんだけど自信満々で言われるとあなたがどれぐらい凄いか興味がある。

128:デフォルトの名無しさん
09/12/24 03:06:29
>>110
今細かく見たらマクロの機能もMASM6を超えてんじゃん。
これのどこがASCII創刊時の機能だと言い切れるの?

129:デフォルトの名無しさん
09/12/24 05:07:09
>>127
鼻息荒いね。
ここでは実装は軽視される。
ある意味浮世離れしているスレだよ。
その氏のは前スレで言ってることが本当ならば実装は凄いよ。
しかし、エロゲには必要ないがオブジェクト指向とかがこのスレの本分。
あと、ここに来ている全員が凄腕ではなく一部だけだと思うから、
煽りにいちいち反応しない方が良いよ。体に悪い。

130:デフォルトの名無しさん
09/12/24 05:16:31
俺は凄腕だけどね。多分、学会関連で知れていると思う。

131:デフォルトの名無しさん
09/12/24 05:18:37
129=130ね。

132:130
09/12/24 05:21:10
中田なんてオヤジが権威とされてる時点で世界に遅れてる。
ドラゴンブックも古い。
出版不況じゃなければ一般向けの本を出したいよ。

133:130
09/12/24 06:18:10
>>130
じゃあ、オマエが見せてみろよ。
>>110
オマエモナ。

どっちが良いか判断してやる。

134:デフォルトの名無しさん
09/12/24 06:19:22
すまん、名前間違えた。

135:デフォルトの名無しさん
09/12/24 06:25:54
>>129
最終的に実行スピードとバグの無さが全てだよ。
オブジェクト指向なんてGCの問題もあるしファイル単位で関数郡をつくればいいし。
構造化で十分だと思ってる。
それを考えると114の言語が現在ではベターだと思う。

136:デフォルトの名無しさん
09/12/24 06:34:14
>>135
おまいさんも鼻息荒いな。
某氏のコンパイラはエロゲの現状に即してる。そしてハイスピード、バグを出さない仕様。
FORTRAN,C,JAVA,どれも得意分野違うじゃん。
ここは実装の話だけじゃないんだよ。
しかし
>>110
がどれぐらい出来るかは示して欲しいな。だって他人を卑下したんだから
俺も叶わないスーパープログラマなんだろうな。

137:デフォルトの名無しさん
09/12/24 07:04:12
>>136
そんな物組めないの分かってるのに性格悪いなw

138:デフォルトの名無しさん
09/12/24 09:28:57
こういった情報系の大学でお薦めのところありますか?
国内で。やはり東大ですか? orz


139:デフォルトの名無しさん
09/12/24 09:36:02
頭悪いのがまだ居座ってるのがわかったのでそういう質問は勘弁してください

140:デフォルトの名無しさん
09/12/24 12:01:39
>>139
本当にそう思ってるのならそんな1行レス辞めなよ。それこそ頭悪そうだ。

141:139
09/12/24 12:07:10
>>140
お前の腐った目から見て俺の頭が悪そうでもまったく問題ない。実際には俺の頭は良いんで。

142:デフォルトの名無しさん
09/12/24 12:09:40
Rubyで3DCGのファイルフォーマットのパーサーを書いたら
すんげー遅い(8秒ぐらい)なんですが何とかなりませんか
1秒以下が希望です。


143:デフォルトの名無しさん
09/12/24 12:09:51
>>141
はいはい。どこの院生ですか、お坊ちゃま。
あとサンプルあげてよ。口ではいくらでも言えるからね。

144:デフォルトの名無しさん
09/12/24 12:12:41
>>143
SEEKが遅いとか?
ホットポイントが明確でないときついな。

145:139
09/12/24 12:25:59
>>143
日本語読めないのか? お前の腐った目にどう映ろうが俺は構わないのに、誰がサンプルなんか上げるかw

さあ、あとは「上げられないんだろ」とか好きなだけ妄想して、
「最後にレスした俺が勝ち」ゲームの勝者となりたまえw

146:デフォルトの名無しさん
09/12/24 12:26:38
自称天才の馬鹿の集まりでした。以上。

147:デフォルトの名無しさん
09/12/24 12:28:07
自称天才で構ってちゃんで馬鹿の集まりでした。以上。

148:デフォルトの名無しさん
09/12/24 12:31:53
>>142
一般的な手順を踏むしかないわな
プロファイラでボトルネックを発見し、そこを何とかできないか考える
ただ、少なくとも今のところ、Rubyはお世辞にも速い言語じゃないので、
頑張ってもどうにもならない可能性は否定できない

149:デフォルトの名無しさん
09/12/24 12:50:26
院生呼ばわりで勝った気か。2ちゃん脳社会人の典型だな。

150:デフォルトの名無しさん
09/12/24 13:52:28
僕は実装が見たいとかあんまし思わないんですが、なんで世の殿方は実装とか珍重するのでしょうか。
ただのプログラムじゃん。
わかんない。田代とかもわかんない。得るものが少ないと思います。
したがってジャンプに載ってる実装をメインテーマにした実装コメントというか
もよくわかりません。ただのプログラムです。
さらにそもそも女子はなぜ実装の話ばかりするのですか。
あまつさえ学校でも実装の話をしたりするのですか。僕は賛成ですが。
いや賛成なのは実装の話が出るからじゃないです。なんとなくいいからです。
僕は女子高生の実装とかそういうものは大好きです。
いや問題なのは女子高生の制服ではなくてパンツです。
パンツが見えててもかまいませんが、布だと思います。
いやそうではなくて、なぜパンツの出るような服を着るかということです。僕は賛成ですが。
すいません。まちがいました。もういいです。

151:デフォルトの名無しさん
09/12/24 13:52:36
香ばしいんだけど
テンプレのサイトあちこち潰れててどこも古めかしいんだけど今ならどこ見りゃいいでしょうか

152:デフォルトの名無しさん
09/12/24 14:16:11
>>142
その3DCGのファイルフォーマットって具体的には何?

もしそれがXML形式で、標準ライブラリのREXMLを使っているのなら、
代わりにたとえばLibXml(URLリンク(libxml.rubyforge.org))のような
C言語で記述された拡張ライブラリを使いなさい。

もしそれが構造化テキスト形式で、手作業でパーザを書いているなら、
Raccと(標準ライブラリの)strscanを使ってパーザを書き直しなさい。
RaccランタイムとstrscanもC言語で記述された拡張ライブラリです。

速い遅いはデータ量とマシン性能に依存するからあいまいになるけど、
上記の方法なら数キロステップのテキストを1秒以内で読み込みできるよ。
あとは>>148が書いてくれているプロファイラの活用かな。

153:デフォルトの名無しさん
09/12/24 14:25:46
>>141
日本語が不自由な方がこんな事を言うなんて…

154:デフォルトの名無しさん
09/12/24 14:41:17
>>139
ここまで頭の悪い奴がどんなコードを組むかは興味がある。

155:デフォルトの名無しさん
09/12/24 15:21:26
変態という名の紳士、いやいや天才という名のキチガイが何匹か紛れ込んでるみたいだけど
本物はこんな所に居ない。今までだってちゃちな物ばかりだったし。

>>142
Rubyは重いよ。趣味でやるなら良いけど仕事では用途を選ぶ。
ホットポイントを見つけて最適化という地道な作業と>>152氏の
事をやってみるしかない。後はRubyスレで聞いた方が速いよ。

156:デフォルトの名無しさん
09/12/24 15:33:03
今は実行環境にJVMがあるからお気楽にコンパイラ作れるね。
>>155
うさみちゃんだっけ?

157:デフォルトの名無しさん
09/12/24 15:34:42
しかしここが進むときは荒れるときで、決まって現物のコンパイラが出てこないね。

158:デフォルトの名無しさん
09/12/24 15:45:44
出せるわけないじゃん、馬鹿だな~

159:157
09/12/24 15:54:27
何故出てこれないか考えられないなんて馬鹿だねw

160:デフォルトの名無しさん
09/12/24 16:14:47
「考える」ことは誰でもできるね。
馬鹿はそれを「わかる」と混同しがち。

161:デフォルトの名無しさん
09/12/24 16:31:31
>>151
学生が作ってたところとかのきなみ全滅だな。
せっかくwikiがあるし、そっちのまとめを参照ってことにするか次スレから。

162:デフォルトの名無しさん
09/12/24 19:15:51
BNFで何か楽しい言語定義してよ。

163:デフォルトの名無しさん
09/12/24 19:26:32
楽しい言語とは?
BrainfuckとかWhitespaceみたいなやつ?

164:デフォルトの名無しさん
09/12/24 19:28:13
Brainfuckなんて良いね。面白そう。

165:デフォルトの名無しさん
09/12/25 00:27:10
この産業も斜陽だしな
萌えとかエロとかは、食っていくに必要

166:デフォルトの名無しさん
09/12/25 13:07:49
では萌えキャラに質問形式でプログラムを作らせて実行さすUIはどうか
うまく実行できるとエロい事が起こる

167:デフォルトの名無しさん
09/12/25 13:43:06
>>110
> しかし作者を叩く人は少なく、変な持ち上げ方をしている奴が馬鹿にされただけ。

図星のレスで荒れたなw

168:デフォルトの名無しさん
09/12/25 19:15:47
だって誰もコンパイラ見せてくれないんだもん。当然荒れるよ。

169:デフォルトの名無しさん
09/12/25 20:09:50
ないそではふれないっていうか・・


170:デフォルトの名無しさん
09/12/25 22:03:13
>>166
普通に Lisp 優位だろうな。それやるとなると


171:デフォルトの名無しさん
09/12/26 03:46:24
点呼を取ります。
A)仕事で使用に耐えうる大量のファイルを高速でコンパイル出来る物を作った人
B)言語をスクラッチで作った人
C)トランスレーターをスクラッチで作った人
D)ツールを使って作った人。

自分はB。構造化言語。

172:デフォルトの名無しさん
09/12/26 05:00:57
おれもBだ、言語的には3つ作った。

173:デフォルトの名無しさん
09/12/26 05:35:30
>>171
そのツールには、yaccのようなパーサジェネレータを含みますか?
もしYesなら、Bで4つ、Dで5つ作りました。

また、Bの1つとDの2つは仕事で活用しました/しています。
わざわざ新しい言語を作る目的には、高速なコンパイル実行が要求される
場合もあるかと思いますが、扱う問題に応じた計算モデルをベースに
言語を設計した場合、コンパイル速度は大きな課題にはならないことがあります。
自分の作ったミニ言語達は、処理速度は遅いですが、仕事での使用に耐えうる
モデル記述が可能であり、どれも実用性があります。

174:デフォルトの名無しさん
09/12/26 10:42:19
自分は
C×1 (NC工作機械制御用にRatforみたいな文法のマクロプロセッサを1つ)、
D×3 (flex/bison使用×1, jflex/cup使用×2)
ただ、最近は言語と一緒に、Eclipse上で動くエディタとデバッガと
カバレッジ測定ツール一緒に作れって要望が割と出るので面倒だ。

175:デフォルトの名無しさん
09/12/26 10:55:54
UTF-8専用の正規表現コンパイラなら作ったことあるが。
状態遷移マシンにコンパイルするので当然速い。
その他は省略。

176:デフォルトの名無しさん
09/12/26 11:13:15
よくわからないんだけど、Aが一番偉いって言う設定なの?

大量のファイルを高速でコンパイルできることが必要なときもあるけど、
必要でないときもあるし。まして仕事なら、必要ないのに過剰に実装して
俺スゴイとか言ってるのはただのアホだろ。

しかも、なんでその点が実装の経験を判断する基準になってるの?


ツールを使ったか使ってないかがなぜ問題になるのかも謎。
体育会系の発想かな?

LLなら手書きしても大して変わらないし、LALR(1)とかを手書きしたから偉い
って思うやつがいたりするのか・・・?

楽していいもの作るのが優秀なプログラマだと思うけどね。根本的な
発想の違いがある気がする。


すまんマジレスしてしまった

177:デフォルトの名無しさん
09/12/26 11:15:37
前スレで馬鹿にされた人が書いたから。

178:デフォルトの名無しさん
09/12/26 12:31:39
大量のファイルを高速でコンパイル出来る物と言う言葉が頭に残っていたから。
後手書きは体育会系かな?

179:デフォルトの名無しさん
09/12/26 12:35:34
しかしこんだけ組んでる人が居るとなったら、
本来の相談室に戻した方が良いと思うけどネタがないね。

180:デフォルトの名無しさん
09/12/26 12:38:21
しかしこんだけ組んでる人が居るとなったら、
本来の相談室に戻した方が良いと思うけどネタがないね。

181:デフォルトの名無しさん
09/12/26 12:43:51
しかしこんだけ組んでる人が居るとなったら、
本来の相談室に戻した方が良いと思うけどネタがないね。

182:デフォルトの名無しさん
09/12/26 17:46:18
俺は3つ作ったやつだが。ここのスレはほとんどROMだ。
最近はやりの機能や、言語的に高度な機能は、自作実用言語には
要らないんだよ。 使いたければ既存の言語を使うので十分。
結局、オリジナルな言語が欲しいのは既存の言語でめんどくさい部分を簡略化して
組込みたいor使いたい、だから記述が簡単であり、専門的な目的に強力に特化した
言語を作ってる。だからここの話題とはなじまない。

183:デフォルトの名無しさん
09/12/26 18:27:58
>>182
いわゆるDSLでんな

184:デフォルトの名無しさん
09/12/26 19:02:20
非正格な言語のコンパイラを作るとしたら、
flex/bisonでは間に合わないでしょうか?

185:デフォルトの名無しさん
09/12/26 19:08:33
flex/bisonは文法を解析するだけのツールだから正格も非正格も関係ないのでは

186:デフォルトの名無しさん
09/12/26 21:12:50
>後手書きは体育会系かな?
作った言語自身でセルフコンパイルさせる必要があったので全部手書きしたことある
いまから考えたら第1段階だけyacc使えばよかったとは思うけど


187:デフォルトの名無しさん
09/12/26 21:58:53
flex/bison 使ってるからスクラッチとはいえないかも知れないが、
宇宙系のやつを作ったことがある。

188:デフォルトの名無しさん
09/12/26 22:30:53
前にも聞いたけど、ネタがないなら再投下させてもらうけど、
タイガー本の和訳ってどう?読んだ人いる?

帯の宣伝文句で、「実装と理論の卓越したバランス」みたいなことが
書いてあったけど、実際どう?

まぁ和訳を読むくらいなら原書読めばいいじゃんと思わなくはないけど

原書の情報でもいいからおせーてください

189:デフォルトの名無しさん
09/12/26 22:47:46
虎本ってML知らなくても読める?

190:デフォルトの名無しさん
09/12/27 02:13:05
しかしお笑いだなw
GPCPUだかなんだか知らんけど前のスレの奴の言ったとおりの物が出てきたよ。
次はループをタスク間で動的に実行か。VMかOSの力が必用なことも言ってたとおりだなw
俺達は馬鹿と紙一重の奴を相手にしてたのか(自嘲

191:デフォルトの名無しさん
09/12/27 02:28:53
GPGPUのことか?

192:デフォルトの名無しさん
09/12/27 08:05:47
本人が必死だな

193:デフォルトの名無しさん
09/12/28 04:11:01
いや、グリッド化では当たり前の未来の技術になってきてる。
言っていることと本人の性格は必ずしてイコールでは無いと言うこと。
結論を述べれば、方向性は合っていて研究中。

194:デフォルトの名無しさん
09/12/28 15:47:54
そんなコンパイラや実行環境はこのスレの趣旨からはみ出てないか?

195:デフォルトの名無しさん
09/12/28 16:37:24
ぶっちゃけ前スレの流れを断ち切りたい。

196:デフォルトの名無しさん
09/12/28 18:15:40
年寄りだからそのうちくたばるだろ

197:デフォルトの名無しさん
09/12/28 20:51:30
年寄り?

198:デフォルトの名無しさん
09/12/28 21:03:56
若造が精一杯背伸びしてるみたいだが。

199:デフォルトの名無しさん
09/12/28 21:06:45
糞じじいは縁側で Lisp でもさわってろ

200:デフォルトの名無しさん
09/12/30 01:51:29
GCのないLISPを考えてみる
原因はクロージャとconsなわけであるが

201:デフォルトの名無しさん
09/12/30 02:51:34
今時、GCのない言語なあ
Cのシェアを奪えるのかい


202:デフォルトの名無しさん
09/12/30 14:26:29
クロージャはともかくconsをfree()するのは嫌。

203:デフォルトの名無しさん
09/12/30 20:59:12
クロージャは何トカ解析すれば消えるらしいけど
consはしょうがないね。定数的に使うか、
破壊禁止にして循環構造を防げば参照カウンタで済む。
カウンタ自体のオーバーヘッド考えるとやりたくないけど。
ただ参照カウンタ式はオーバーフローの対策が要る。
1セル高々16bitにして65535になった時点で例外を投げるか。


204:デフォルトの名無しさん
09/12/31 00:47:20
この年になっても、正直クロージャがあってよかったと思える場面に出会えてない。
みんなこんなもん?

205:デフォルトの名無しさん
09/12/31 01:09:26
お前の使っている言語に
簡単に使えるクロージャはあるの?


206:デフォルトの名無しさん
09/12/31 02:20:18
URLリンク(zip.2chan.net:81)

207:デフォルトの名無しさん
09/12/31 02:47:02
>>200
new lispってのがそんな事やってた様な気がするが

208:デフォルトの名無しさん
09/12/31 03:03:35
何の対策もない処理系でも、あらかじめ必要分を確保するとかで、
範囲内のGC起動を抑止するってことは可能だから
機能縮小してまでGCレスにする事もない気がする。

209:デフォルトの名無しさん
09/12/31 13:52:29
寿命解析すれば自動的に抑止することもできるよ。
実用的には適当なところで打ちきらないとダメ。
stalinみたいに最適化に数時間かかると用途が限られる。

210:デフォルトの名無しさん
10/01/02 21:27:38
Domain-Specific Languagesの総本山ってどこだっけ?


211:デフォルトの名無しさん
10/01/03 10:23:53
pragmatic programmers のことをさがしてるのかな?
元々Unixの設定ファイルとか、Lispの方からの伝統的なものだが。

212:デフォルトの名無しさん
10/01/04 06:59:23
GCが有る言語は嫌いだ。リアルタイム処理が確実に出来ない可能性がある。
クリティカルパスを切れば良いんだけどね。

並列コンピュータのコンパイラは今後進歩するのかね。疑問。
>>193や某氏の言う通りになるほど甘くはないと思うんだが。

213:デフォルトの名無しさん
10/01/04 08:12:44
1980年代から研究も実装もあるんだからまずはサーベイだろ。

214:デフォルトの名無しさん
10/01/04 23:43:37
>>211
DSLの英語のページどこだっけ?

215:デフォルトの名無しさん
10/01/04 23:53:47
DSLs in Boo: Domain-Specific Languages in .NET
これどうなのか書評教えてくれ

216:デフォルトの名無しさん
10/01/06 18:40:08
DSLってC++界隈では低く見られてない?
DSLはどうせC++か何かのコードを生成するんだろ
とか、汎用の言語の方が偉いとか。

217:デフォルトの名無しさん
10/01/15 12:07:43
つーか、言語自体が全般的に(ry

218:デフォルトの名無しさん
10/01/16 12:09:19

・明快入門コンパイラ・インタプリタ開発 C処理系を作りながら学ぶ(林晴比古実用マスターシリーズ)
URLリンク(www.amazon.co.jp)

219:デフォルトの名無しさん
10/01/16 12:13:53
林晴比古(笑)

220:デフォルトの名無しさん
10/01/16 12:21:08
読んだことないから本当に風評通りに酷いのか分からん。
昔は酷かったが成長してるのかもしれんし。

221:デフォルトの名無しさん
10/01/16 17:15:16
老化してるよ

222:デフォルトの名無しさん
10/01/17 11:31:56
数字読み込み関数は数字じゃない文字が来るまで文字をくっつけて返す
識別子読み込み関数は[A-Z][A-Z0-9_]*を文字をくっつけて返す
"(", ")"はそのまま返す

みたいにS式っぽいものトークン分解しています

"(123ABC)"を "(", 数字, 識別子, ")" てトークン分解
しちゃうんですけど数字と識別子が別れていないので
これはエラーにしたいです (123 ABC)と区別付きません
普通はどうやってこういうのをトークン分解するんでしょうか



223:デフォルトの名無しさん
10/01/17 12:02:51
>222
普通どうするかは知らないが「数字じゃない文字が来るまで」のところで判定すりゃいいだけなんじゃないの?

224:デフォルトの名無しさん
10/01/17 12:16:30
数字を読んでるときにアルファベットが出てきたらエラーにする。

225:222
10/01/17 12:32:55
なる・・・ほど・・・
ありがとです

226:デフォルトの名無しさん
10/01/17 12:35:56
>>225
まず本を一冊通読すべき。

227:デフォルトの名無しさん
10/01/17 12:50:05
スレチな気もしますが、ざっと見た感じこのスレが一番近い気がするのでここで質問します。

自作のインタプリタ言語用の文法を考えています。
Ruby,Python,JavaScriptあたりを参考にしてクラス系オブジェクト指向言語に
しようと考えていますが、いくつか悩んでいます。ご意見いただければ助かります。

まず、class宣言の文法です。上に挙げた言語の中では、Rubyの物を借りようと考えています。
class MyClass
 def my_method(arg)
 end
end
という風にしようと思っていますが、
例えば、メソッドが複数ある場合、endが関数宣言の最後なのかクラス宣言の最後なのか、
見分けがつかない事があるように思えます。
これはPythonではもう少しマシですが、クラス宣言が並んでいる場合に、
どのクラスのメソッド宣言なのかわかりにくい所があると思います。
JavaScriptでは、
MyClass.prototype.my_method = function(arg){
}
のように宣言されるので、この問題はないのですが、初学者が理解しにくい点、
メソッドの宣言を一箇所にまとめる事を強制できない点から自分の趣味には合わないと感じます。

そもそも巨大なクラスを宣言すべきでない、という意見もありますが、 -> URLリンク(d.hatena.ne.jp)
実際問題、読みにくいコードが多いように思えます。
他の便利な記法をご存知の方はいらっしゃいますか?
また、上記の記法のうちで、どれが好きですか?
ご意見ください。

228:デフォルトの名無しさん
10/01/17 13:00:40
class MyClass
 def my_method(arg)
 end def
end class

229:デフォルトの名無しさん
10/01/17 13:08:55
>>227
古いfortran風にブロックの対応を明示するという記法もあるよ。
#面倒なうえに逆に見難くなるなので嫌い。
class MyClass
 def my_method(arg)
 end def my_method
end class Myclass

見分けやすさというレベルならもっと単純に
ブロックの対応を表すコメントを追加する方がよいと思う。
有名なエディタを公式環境と決めて、それ用の自動追加マクロを作ればOK。
class MyClass
 def my_method(arg)
 end //def my_method
end //class Myclass


230:デフォルトの名無しさん
10/01/17 13:11:48
Python(Haskell)みたく、オフサイドルールにしちゃえば?
URLリンク(ja.wikipedia.org)

231:227
10/01/17 21:19:28
レスありがとうございます。

>>228
見ていてVBのend subを思いだしました。
end def、end classというのは予約語を増やさないという意味で良いですね。
予約語を増やしてもいいのなら、シェルスクリプト風に
class MyClass
 def my_method(arg)
 fed
ssalc
というのも簡潔でしょうか。

>>229
コメントで良いという意見ももっともです。

>>230
インデントだけだと、
class Hoge
 class Fuga
  def foo
  // Is here end of function or class?
 def bar
のようにネストした時に、どれがどれかわからなくないですか?


232:デフォルトの名無しさん
10/01/17 22:27:53
beginとendの対応が見えるような短いブロックなら,インデントだけでも見難くはないと思うんだよね
長くなるとendはあってもなくても変わらないし

233:227
10/01/17 22:35:10
>>232
まったくその通りだと思います。
「インデントよりもendの方が良いけど、もっと良いのないですか?」
という質問ではなく、
「インデントも、endも、わかりにくいのですが、もっと良いのないですか?」
という質問のつもりでした。
わかりにくかったのでしたらすみません。

インデントの場合
メソッド宣言は1インデント
メソッドの中身は2インデント
と決めうちで書ければ良いかとも思いましたが、
それはそれでありえないと思いました。



234:デフォルトの名無しさん
10/01/18 22:10:44
もう JavaScript みたいにするしかないじゃん

235:デフォルトの名無しさん
10/01/19 01:14:24
そういえば、0123abcをエラーにしてませんでした。気をつけよっと。

xml風
<class>A
 <def>add a b
  a+b
 </def>
</class>
/def /classはキーワード
class A
 class B
  def a,b
   a+b
  /def
 /class
 def a b
  a + b
 /def
/class

endじゃなくてe
class A
 class B
  def add a,b
   a+b
  edef
eclass
def add a,b
a+b
edef
eclass
とか。

236:デフォルトの名無しさん
10/01/19 03:26:02
SGMLつかえよ

237:デフォルトの名無しさん
10/01/19 07:51:05
>>235
XMLベースなら改行に意味を与えない方がよいよ、とマジレス。

238:デフォルトの名無しさん
10/01/19 09:17:19
YAMLっぽいのはどう?

A:
- {add(a,b): a+b}
- {sub(c,d): c-d}

B:
...

239:デフォルトの名無しさん
10/01/19 11:03:57
LISPでいいだろ
アホか

240:デフォルトの名無しさん
10/01/19 18:49:07
>>239
ヒント:クラス系オブジェクト指向言語

241:デフォルトの名無しさん
10/01/19 19:38:34
>>240
CLOS


242:デフォルトの名無しさん
10/01/19 19:54:49
endだけで構文解析すりゃいいだろ?
インデントでなんて馬鹿げてる。

243:デフォルトの名無しさん
10/01/19 23:35:14
URLリンク(nadesi.com)

forth 系のアプローチ…だと…

244:227
10/01/20 00:14:50
>>234
意味さえ分れば、プログラムは作りやすいですよね。

>>235
XMLありえなす。

edef はどうかと思いましたが、endefはアリかもw

>>238
XMLのと合わせて思ったんですが、
Squeak(smalltalk)の開発環境みたいなUIで表示するのは有ですかね?
まあ、自分のテキストエディタが使えないといけない、
と思う人は特定数いそうですけど。

>>241
不勉強なんですが、
CLOSはプロトタイプベースに近いのではないかと思ったんですが、
どうでしょう?
マルチメソッドだけでがんがれ、という意味であれば、
それはそれでネストしないはずなので、答としてアリな気はしますね。

>>243
構文解析という意味だと、>>235 さんのedefアプローチに近いですね。
わかりやすい予約語を作れればいけそうですね。

245:デフォルトの名無しさん
10/01/20 00:29:45
>>244
CLOSはクラスベースだよ。defclassで定義する
カプセル化はしないだけ

246:227
10/01/20 00:29:52
連投すみません。

メソッド呼び出しの構文について質問です。
Rubyでは、
my_object.my_method arg1, arg2
のようにメソッド呼び出しの括弧を省略する事ができます。
これはとても便利だと思うので、自作の言語にもこの文法を取り込みたいです。

一方で、JavaScriptのように関数をファーストクラスオブジェクトとして
扱いたいという要求もあります。
window.set_on_exit(object.my_event_handler)
などとして、イベントハンドラを追加できるような文法を考えています。

Rubyでは、
a = my_object.my_method
とした時に、my_methodが呼び出され、実行結果が変数aに代入されます。
しかし、自作の言語の現在の仕様では、メソッド自体が変数aに代入されます。
この差をどう埋めるべきかで悩んでいます。

案としては、
- 特定のメソッドの時には引数は評価されないようにする。
- a = &(object.method) か a = object.&method のように&を必要とする。
などがありますがどれも綺麗ではないです。

個人的に一番良いかなと思っている仕様は、
a = object.method   <= methodが返る
a = object.method arg <= methodが実行される
a = object.method()  <= methodが実行される
という、引数があれば関数呼び出しで、引数が無い場合は括弧の省略は不可という仕様です。

これは分かりにくいでしょうか?
ご意見頂ければ幸いです。

247:デフォルトの名無しさん
10/01/20 00:43:05
場当たりな文法は破綻しやすいからなあ。
引数を二つ取る関数に引数を一つ渡したらどうなるの?

Curryingとかを調べてみると良いかも。

248:227
10/01/21 01:24:49
>>247
場当たりに見えるという事はまだ作り込みが甘いんですね。

>引数を二つ取る関数に引数を一つ渡したらどうなるの?
Rubyでは、呼び出し時にエラーになりますし、
JavaScriptでは、Undefindを渡したのと同じ動作をすると思います。
このどちらかが分りやすいかなと考えています。

>Curryingとかを調べてみると良いかも。
説明が足りなかったですね。
2引数の関数を呼び出す場合には、
hoge(a, b) か
hoge a, b
と書くようになる事を考えています。

カリー化については、構文によるサポートはいらないのではないかと
思っています。
単にカリー化を使いこなせてないだけかもしれませんが、
あまり常用する物とは思えませんし、Haskellのような構文で部分適用を
サポートすると、静的に型を解析しない言語では、
意図せずカリー化を行ってしまい、混乱するのではないかと思います。

逆にカリー化を行いたい場合には、
Rubyのようにメソッドが基本的にオブジェクトではない言語では、
currying_function = currying(method(:hoge), arg1)
curring_function(arg2)
のようにメソッドをオブジェクト化する必要がありますが、
メソッドや関数が初期からオブジェクトであれば、
currying_function = currying(hoge, arg1)
curring_function(arg2)
のように黒魔術(リフレクション)を使わずに簡潔に書けると思います。

249:デフォルトの名無しさん
10/01/21 04:10:49
URLリンク(merd.sourceforge.net)
URLリンク(homepage.mac.com)

メソッドがだとすると、その obj の生成、複製、破棄とか
気になるといえば気になるのにゃあ・・・

250:デフォルトの名無しさん
10/01/21 15:27:35
引数をあらわす括弧と、演算子の優先度をあらわす括弧が
ネストした時に、どれがどれかわからなくないですか?

251:デフォルトの名無しさん
10/01/21 15:33:19
わからなくない

252:デフォルトの名無しさん
10/01/21 23:36:25
>>250
形式言語とパーザの勉強して、
「曖昧な文法」ってどんなのがあるか理解しよう。

253:デフォルトの名無しさん
10/01/22 00:13:45
perlfunc

List operators take more than one argument,
while unary operators can never take more than one argument.
Thus, a comma terminates the argument of a unary operator,
but merely separates the arguments of a list operator.

254:デフォルトの名無しさん
10/01/22 00:18:23
明快入門コンパイラ・インタプリタ開発 C処理系を作りながら学ぶ

神本だった。ここでうだうだ糞文法の質問している奴
読めや

255:デフォルトの名無しさん
10/01/22 00:19:20
本を紹介するんならICBMくらい書けや

256:デフォルトの名無しさん
10/01/22 00:21:06
>>255
あー?お前誰に命令してるんじゃ?


257:デフォルトの名無しさん
10/01/22 00:22:43
>>255
あー? テポドン2号落とすぞコラ

258:デフォルトの名無しさん
10/01/22 00:24:52
テポドン2号だと?
おまえ、それかっぱえびせんじゃねえか

259:デフォルトの名無しさん
10/01/22 02:22:16
ワロヒコ乙

260:227
10/01/22 03:00:20
>>249
C#などのように扱い始める時にオブジェクトの生成を行う方法と、
JavaScriptのようにメソッドの定義時に行う方法があると思っていますが、
後者の方が心理モデルを構築しやすく、理解しやすいと思っています。
オブジェクトにはフィールドとメソッドがペタペタくっついてる、と
説明すると、初学者にも理解してもらいやすいのではないでしょうか?

>>250-253
たしかに分かり難い所があるかもしれません。
この点に関しては、>>253 であげられた所ドユメントでも、
> the simple (but occasionally surprising) rule is this:
と書かれています。
Perlは各関数が取る引数の数によってどうパースされるかが変わります。
Rubyでは、"p (1) - 2"というコードで 1.6 と 1.8 で結果が違います。
また、Ruby 1.8 では、引数の数でも変わります。

これらをふまえると、単純に関数名の後ろのスペースの有無で評価結果を
変えるのが良いのではないかと思っています。

私は過去にCなどの言語で関数名の後ろにスペースを入れるべきという主張を
見た事がありませんし、while, for 等の構文と関数呼び出しを
スペースの有無で見わけるという、コーディング規約も一般的だと思います。
そのため、自由度は減りますが、見た目的には良いのではないでしょうか?

>>254
どのような点が良いのでしょうか?
Cのような低いレイヤの処理系を実装するとなるとinline化の判断や
可変長配列サポートの仕方とかが気になりますが、
その辺はまっとうな方法を紹介してますか?
土日に本屋に行って探してみます。
>>255
じゃあ、ABMで。

261:デフォルトの名無しさん
10/01/22 05:11:45
>Rubyでは、"p (1) - 2"というコードで 1.6 と 1.8 で結果が違います。
>また、Ruby 1.8 では、引数の数でも変わります。

Ruby作ってる奴ってアホだろ

262:デフォルトの名無しさん
10/01/22 07:37:29
> while, for 等の構文と関数呼び出しを
> スペースの有無で見わけるという、コーディング規約も一般的だと思います。

ナンセンス。
エディタと文法と実行モデルを区別しようぜ。

263:デフォルトの名無しさん
10/01/22 08:52:13
>>261
a +b と a + b で意味が違うとかな。
アホ扱いされる一面ではある。

>>260
そういう、レキシカルアナライザの挙動が、パーサに左右される状態に依って変わる、
なんていう言語はパーサとレキシカルアナライザを作るのが大仕事になる。

なに考えてるのかわからんが素直に正規表現でトークンを切り出して、LL(1)かLALR(1)で
処理できる文法にしたほうがよい。まずは。

264:デフォルトの名無しさん
10/01/22 10:13:13
>>260
> Cのような低いレイヤの処理系を実装するとなるとinline化の判断や
> 可変長配列サポートの仕方とかが気になりますが、
> その辺はまっとうな方法を紹介してますか?

お前、自分のレベルにあった本をまず読めよ。
なんで上から目線なんだw

265:デフォルトの名無しさん
10/01/22 11:26:13
ワロヒコの本を紹介するような椰子には、上から目線で当然だろwwwww

266:227
10/01/23 00:12:26
>>261, >>263
知らなかった。確かに違う。> a +b と a + b で意味が違う
この辺、複雑なルールなのに穴に落ちる事が少なく
普通の使用者は気がつかないようになってるのが、凄いですね。
本当にRubyの作者はアホですね。
このRubyのやつとか、Perlの関数名によってパース結果が変わるのとか、
真似するのはやめるべきですね。シンプルよりも使いやすさを求めるのではなく、
許容できない使いにくさが無い範囲でシンプルな文法を目指したいですね。

>>246 で書いた文法の場合、正確に文法を書くとすると、
関数呼び出し ← id ( '('? (式 ',')+ ')'? / '()' )
参照 ← id
にしようと考えています。( ?は省略可能, /はor, +は一回以上の繰り返し)
要は、idの後ろからその式の終端までに他の式があれば
関数呼び出しとして扱うつもりです。

LL(1)だと、 a(1) と a = 1 が両方パースできません。
PEG文法の範囲の文法が使いやすくて良いと思います。パーサの実装も楽です。
LLだと無限大相当ですが。

267:227
10/01/23 00:13:47
>>262
区別できてる気はしませんが、話したいのは文法についてです。

while (true);
myfunc(true);
のように書き分けるコーディング規約は一般的だと思いますが、違いますか?
検索して3番目に出てきたPearライブラリの規約では、
URLリンク(pear.php.net)
> 制御構造では、関数コールと区別するために、 制御キーワードと開きカッコの間に空白を 1 つ置きます。
と書かれていました。皆これを当然と思っているのなら、
関数名の後ろにスペースを入れた場合、エラーになるまたは違う解釈をする、
というのは落とし穴にならないのではないでしょうか?

>>264
設計、実装にあたり参考になる本を紹介してもらう事もあるかもしれませんが、
それは、それでよろしくおねがいします。
ちなみにどんなレベルが私に合ってると思いますか?

>>265
私が言うのも何ですが、何でこのスレではそこまで煽られてるんですか?

268:デフォルトの名無しさん
10/01/23 01:51:17
>>266の文法はPEGとしても>>246の例と一致していないよ。たとえば
「func a, b,」や「func (a,」が関数呼び出しにマッチしている。
書きたかったのは下のような奴じゃないかと思うんだけど。

関数呼び出し := id ( '()'
/ 式 ( ',' 式 )*
/ '(' 式 ( ',' 式 )* ')' )

で、この文法ってRubyと大差ない複雑さだよ。
「f f, f a, b, c」とか、式の中に裸の「,」が出てきたら困るよね。

269:デフォルトの名無しさん
10/01/23 02:34:05
横レス失礼

>>266,267
言っている事が矛盾している気がするヨ。

>>266では、a +b と a + b で意味が違う事を問題としているが、
これはRubyが構文によってセパレータ(字句区切り子)の解釈が異なる事に起因する。
しかし「二項演算子の前後には空白を入れる」という一般的なコーディング規則に
従っていれば実用上の問題は生じない。

対して、>>267ではwhile文と関数呼び出しという二つの構文で、セパレータの
解釈が異なることを問題としていない。それを一般的なコーディング規則であるから、
問題は生じない(落とし穴にならない)と主張している。

Rubyの構文が汚いのは分かるから、>>263が助言しているように、
まずはセパレータでトークンを区切って素直にパーズできる文法で設計することを勧める。

270:デフォルトの名無しさん
10/01/23 02:48:19
>>268
ここはこれでも全然煽られてないんだよ。
能力を持った人しか来れないし。
逆にエロゲの人でも能力を持っていればそれほど煽られない(煽られないことはないが)。
君みたいにダメプログラマで上から目線なら、今までだったらもっと煽られて相手にされてないよ。

トークンの切り出し程度で悩んでるなんて、ここに来る資格はない(断言

271:デフォルトの名無しさん
10/01/23 03:16:08
偉そうなこと言っといて安価ミスってると恥ずかしいよね

272:デフォルトの名無しさん
10/01/23 03:47:25
ああ(笑

273:デフォルトの名無しさん
10/01/23 09:48:12
>>267
>while (true);
>myfunc(true);
>のように書き分けるコーディング規約は一般的だと思いますが、違いますか?
少なくとも、コーディング規約としては一般的ではない。


274:デフォルトの名無しさん
10/01/23 10:15:29
ワロヒコって言った奴ちょっと出てこい

275:デフォルトの名無しさん
10/01/23 10:33:34
>>273
CのK&RやJavaは、そうやって書き分けるだろ。それが一般的。
GNUが特殊だと思う。

276:デフォルトの名無しさん
10/01/23 10:34:47
>>273
そうか?いたって一般的だと思うが
少なくともここにある規約は全部そうなってる
URLリンク(www.objectclub.jp)

277:デフォルトの名無しさん
10/01/23 12:07:05
>>246
俺はそれでいいと思う。PythonとRubyの折衷案みたいだね。

r = obj.method1
s = r a, b
obj.method2 c, s, d
こんな3行があったとき、sを使わずにrの結果を直接method2に渡すと
r = obj.method1
obj.method2 c, r a, b, d
となる。
これをパースするのが難しそうな気がする。

278:デフォルトの名無しさん
10/01/23 13:44:15
>>275
気にしてなかったけど、意外と多いね。

URLリンク(www.google.com)

空白の有無で意味が変わるのは個人的には気持ち悪いけど、
俺が使う訳じゃないしな。

279:デフォルトの名無しさん
10/01/23 14:13:45
URLリンク(developer.mozilla.org)
URLリンク(google-styleguide.googlecode.com)
URLリンク(lxr.linux.no)
URLリンク(cvsweb.netbsd.org)
> Space after keywords (while, for, return, switch).
URLリンク(httpd.apache.org)
> There is a space between the keyword and the opening bracket.

Mozilla, Google, Linux, NetBSD, Apache はキーワードの後ろは
空白を空けるスタイルだった。コーディングスタイルと構文規則
では要求される厳密性が違うけどね。インデントの強制くらいなら
受け入れられ易いとは思うけど。

280:227
10/01/23 15:47:09
>>268, >>277
その点は見逃していました。
たしかに(人間にとって)パースするのが難しいですね。
試しにRubyで試してみた所、
def a(*x)print"a";p x end;def b(*x)print "b";p x end;a 1,b 2,3
syntax error, unexpected tINTEGER, expecting kDO or '{' or '('
との事です。引数列の中では、関数呼出の括弧は省略不可なのでしょうか?

PEG文法は貪欲なアルゴリズムなので
a 1,b 2,3 は a(1,b(2,3)) になります。
これは罠になる事が多いでしょうか?
このようなコードはとても読みにくいとは思いますが、
そもそも書く方も混乱するので書かれにくく、
プログラムを書く時の罠にはならないかと思います。

>>273, >>275, >>276
GNUのコーディング規約はスペース開けるんですね。知りませんでした。
論点としては、
while の後ろにスペースを開けるのが一般的かどうかではなく、
関数名の後ろにスペースを開けない事が一般的かどうかですね。
これも、func (1)+2 という罠コードを書かないという風にすればいいんですが。

どちらも、RubyのようにWarningを出す等の処理をすれば良いですかね?


281:227
10/01/23 15:48:12
脇道
>>268
すみません、適当を書きました。
手元のでは a(0)[1](2) みたいなののサポートも入ってたのですが、
今回は省略です。

>>269
矛盾というか、同じ論法で正反対の結論になってると言いたいわけですね。
それは前提となるコーディング規約が重要なのではないでしょうか?
私は二項演算子の前後に空白を入れるのはそんなに一般的でないと思っています。
皆さんはどうですか?

>>269,>>270
今論じてる、fun(foo,bar)とfun foo,bar の間の話に、
トークナイズ(字句解析)は関係ないと思ってるんですが、私の言葉の使い方は間違ってますか?
"fun(foo,bar);" => ['fun','(','foo',',','bar',')',';'] という処理の事を字句解析と言うと認識してるんですが。


282:デフォルトの名無しさん
10/01/23 19:05:04
二項演算子の間に空白を入れる人は多いよ。
fun(foo,bar)とfun foo,barを同居させた奴が前スレにいたよ。
エロゲプログラマだったけど。

283:デフォルトの名無しさん
10/01/23 19:06:39
関数宣言の時にカッコの後ろに空白をいれるのは検索性を良くするためで、
来れも結構いるよ。

284:デフォルトの名無しさん
10/01/23 19:14:54
そもそも>>246

>引数があれば関数呼び出しで、引数が無い場合は
>括弧の省略は不可という仕様です

これがおかしい
そんな半端に括弧を省略して何になる
a = call object.method
だろ
文法より意味論をまず確定しろ

285:デフォルトの名無しさん
10/01/23 19:15:22
>>276
>少なくともここにある規約は全部そうなってる
>URLリンク(www.objectclub.jp)
それ、みんな
「Java コーディング標準(オブジェクト倶楽部バージョンを~用に変換したもの・・・」
だから、全部同じスタイルになっててあたりまえだろw

>>279
Open source系は、キーワードの後ろにスペース入れる事が明記されてるのが多いね。
pearもそうだ。


286:デフォルトの名無しさん
10/01/23 19:36:35
もうちょっと勉強してから質問しないと、低レベルすぎて話にならないよ。
9??の馬鹿の方がまだ良かったかな。

しかし、こんな素人にみんないつのまに優しくなったんだ?


287:デフォルトの名無しさん
10/01/23 19:40:29
レベルより態度。

288:デフォルトの名無しさん
10/01/23 19:40:31
高卒でも
URLリンク(kenjikakera.asablo.jp)
の様に構文を自由に変えられるコンパイラを作ってるんだから、
麻布と京大の名が泣くぞ。ちんこ。

289:デフォルトの名無しさん
10/01/23 19:47:40
9??の態度は最悪だったなw
その後にマルチスレッドのコンパイラが出たのは、人格と能力はべつもんと知ったな。

290:デフォルトの名無しさん
10/01/23 19:50:17
>>283
自己レス
カッコの後ろ->カッコの前。恥ずかしい…orz

291:デフォルトの名無しさん
10/01/23 19:57:45
>>288
これが18年前に作られたそうだ。OO的にはダメダメだけどエロゲ程度で作るのなら関数型が分かり易くて良いだろう。

292:デフォルトの名無しさん
10/01/23 20:00:47
しかもコンパイルスピードは高速らしい。
makeを内蔵してマスター時のスピードを少しでも上げるんだとさ

293:デフォルトの名無しさん
10/01/23 20:03:16
まあ、物を見てないんでホントかどうかは怪しいが。

294:デフォルトの名無しさん
10/01/23 20:03:45
計算機はプログラマの人格には無頓着だからな。
ネットでは人格が変わる人もいるから、そっちかもしれんが。

295:デフォルトの名無しさん
10/01/23 20:06:09
Horizontal Layoutってどう思う?
1 + 2*3
と書くと2*3を先に計算して
1+2 * 3
と書くと1+2を先に計算するって奴。

296:デフォルトの名無しさん
10/01/23 20:08:31
きもい。Cの優先順位が身に染みてるけど、メンテのためにカッコをいれる。
それに比べて>>295は俺にはなじまん。

297:デフォルトの名無しさん
10/01/23 20:08:45
1 + 2 * 3
は?

298:デフォルトの名無しさん
10/01/23 20:13:51
スペース同じなら * 優先

299:デフォルトの名無しさん
10/01/23 20:14:39
同じなら左優先

300:デフォルトの名無しさん
10/01/23 20:20:31
GAME言語は左優先だったな
APLもだっけ?

1 2 3 ADD MULがいいか
MUL(1, ADD(2, 3))がいいか
(MUL 1 (ADD 2 3))がいいか

((1 2 ADD) 3 MUL)
Lisp+Forthも面白いか。
でも世の中にはカンマと小数点が逆の国があるらしくて
そういう国の人はどう思うのだろうというのも時々


301:295
10/01/23 20:20:33
聞いておいてなんだけど自分もキモいと思う。
採用している言語もほとんどないしね。

>>297
1+2*3
1 + 2 * 3
のように均等に分けた場合は演算子の優先順位で決まるらしい。

302:デフォルトの名無しさん
10/01/23 20:25:06
1/((2+3)*4) とかどうするの?
1  /  2+3 * 4 とか書くの?
空白多すぎて読み辛いよ・・

303:デフォルトの名無しさん
10/01/23 20:28:39
Smalltalkも左優先。

>>302
空白の数で優先度が決まるのかw。
いっそ、空白やTABの数で演算子の種類が略

304:デフォルトの名無しさん
10/01/23 20:31:14
Smalltalk はメッセージ式のルールが上位にあるからシンプルで分かり易い。

305:デフォルトの名無しさん
10/01/23 20:32:34
>>300
>にはカンマと小数点が逆の国
フランス、スペイン、イタリア、ドイツあたりがそうらしい。
'.'の代わりにスペースを使う場合もあるとか。

306:デフォルトの名無しさん
10/01/23 21:01:14
>Smalltalk はメッセージ式のルールが上位にあるからシンプルで分かり易い。
今でも慣れない、四則演算は小学校で習うから体に染みついてる

数値演算でバグだすとマジ悩む>>Smalltalk


307:デフォルトの名無しさん
10/01/23 21:13:02
Scalaの、通常の四則演算を多記号に拡張したような規則は
面白いなあと思ってたんだが、アレは元ネタがあるんだろうか

308:デフォルトの名無しさん
10/01/23 22:10:18
だいたい、文字列みたいな一次元で表現しようとするから困るんだよ。
二次元に数式置いて、近い順に演算するってのはどう?

三次元に拡張して、上の段が掛け算、下の段が割り算でもいいよ。
この球の中の総和、みたいな。


309:デフォルトの名無しさん
10/01/24 00:07:00
「左結合」「右結合」という術語があるんだから使いましょうや。

310:デフォルトの名無しさん
10/01/24 02:47:29
>>303
whitespace

311:デフォルトの名無しさん
10/01/24 23:43:34
>>307
URLリンク(www.scala-lang.org)
これのこと?


312:デフォルトの名無しさん
10/01/25 08:32:47
>>308
trifungeやると

313:デフォルトの名無しさん
10/01/25 13:54:25
>>291
おまいは関数型言語をわかっていてそれを関数型と言ってるのか?
どっかのおかしな事典の「C言語は関数型言語」というトンデモを信じてないか?

314:デフォルトの名無しさん
10/01/25 14:03:04
手続き型と勘違いしてるのでは

315:デフォルトの名無しさん
10/01/30 07:37:00
291の発言は?だが、「関数型言語」の定義を聞かれると
答えるのは難しい。

316:デフォルトの名無しさん
10/01/30 07:47:49
実は「関数型言語」という語の意味が二種類あるという落ちか。
古い定義だと「subroutine以外にfunctionを使える言語」なんでCを含むんだよね。


317:デフォルトの名無しさん
10/01/30 09:05:34
細かい違いな気がするけど

何かを返す返さないで記述が違うのは
便利な気がする・・・basic

void 使え・・・c

ソース嫁・・・動的型付

318:デフォルトの名無しさん
10/01/30 09:09:08
> 古い定義だと「subroutine以外にfunctionを使える言語」なんでCを含むんだよね。

[要出典]

Cはsubroutineをfunctionと「呼んでいる」言語であって。

319:デフォルトの名無しさん
10/01/30 09:53:07
値を返すサブルーチンを関数と呼ぶのはCに限らずFortranとかPascalとかあるが、
それらが「関数型言語」と呼ばれていたのは聞いたことがない

320:デフォルトの名無しさん
10/01/30 10:11:12
LISPも正格評価で逐次処理、関数は置き換えではなく呼び出しだから、
関数型ではなく実質的に手続き型言語と言えなくもない

321:デフォルトの名無しさん
10/01/30 10:22:57
古い論文だとFortranをfunctional languageと呼ぶことがあるんだけど懼
まあ、聞いたことないのが当たり前だと思う。
自分も最初に聞いたとき訳が分からなかったし。

あと、その訳語として「関数型言語」が主流だったどうかは知らない。
ごめん。

322:デフォルトの名無しさん
10/01/30 10:32:12
>>321
具体的にその論文名を。

323:デフォルトの名無しさん
10/01/30 10:52:26
threaded interpretive language とか書名聞いて
何ぞと思って調べてみたら forth と z80 の解説書だった

俺もどこで見たか忘れたけど、Cを関数言語と呼んでた
記憶が・・・まぁ文脈というか時代背景によるよね > 用語の定義

324:デフォルトの名無しさん
10/01/30 10:58:59
技評の「新ANSI C言語辞典」を持ってる人がいたら、それの
「関数型言語」の項を見てもらいたいのだが...

325:デフォルトの名無しさん
10/01/30 11:08:31
>>322
論文は手元にないんで無理。
WebならURLリンク(www.liv.ac.uk)が近いかな。

むしろちょっと疑問なんだけど、
"functional language"に同綴り異義語があった
というのってそんなに興味深いのか。

326:デフォルトの名無しさん
10/01/30 11:19:10
>>324
通りすがりの漏れが引用しますよ
p.294 関数型言語 の項より

「関数型言語(functional language) 関数型のプログラミング言語。
LISP、LOGO、APL、BCPL、B、Cなどがある」

327:デフォルトの名無しさん
10/01/30 11:22:51
そのころの基準で関数型じゃない言語って何だ?
FORTRAN、COBOLは違うのか?
BASIC? 関数を言語仕様に入れただけで、分類が型が変わるのか?
アセンブラ?

328:デフォルトの名無しさん
10/01/30 11:58:43
どうでもいいからブログでやってろ

329:デフォルトの名無しさん
10/01/30 12:27:44
>>326
たぶんそれが日本でデマが流行ってる元凶。
時代によって変わったりなどしない。B も C も関数型じゃない。

>>325 も HPC の専門家らしいので、言語屋じゃない。
言語屋が C を functional などと言った例はないはず。

330:デフォルトの名無しさん
10/01/30 12:52:56
素直にこの辺りを参照した方が良いと思う。
URLリンク(ja.wikipedia.org)

俺解釈だと「処理が関数の変数と値に依存する言語」「独立して書かれている処理は独立している」だな。

331:デフォルトの名無しさん
10/01/30 13:02:29
「Cを関数型と呼ぶ人が一部にいたのかどうか」
「その事実は万人が知っていてしかるべきか」という話になってしまっているが
なんにせよCもFortranも関数型言語ではないし
LISPにしても、延々とこんな話を続ける理由になるほど手続き型言語っぽくはない

332:デフォルトの名無しさん
10/01/30 13:03:14
>>330
バカ

333:デフォルトの名無しさん
10/01/30 15:53:39
LISPとCに根本的な違いが無いのに
「LISPは関数言語」というデマがいつからか
流行ったのが酷いと思うけど。

334:デフォルトの名無しさん
10/01/30 16:11:15
> 根本的な違い
根本的というのが曖昧すぎて、何とも言えないな。つまりどういう要素が根本的なのか。

335:デフォルトの名無しさん
10/01/30 16:24:30
LISPとCでどこが違うのか言ってみてよ。

336:227
10/01/30 17:59:10
Haskellも副作用(モナド)あるから関数型じゃないよね、とか燃料投下してみる。

337:デフォルトの名無しさん
10/01/30 18:22:26
OCamlはもっと微妙。

338:デフォルトの名無しさん
10/01/31 08:20:21
関数型言語と呼べるための必要条件は何だろう?
素朴には、すべてのプログラムが数学的な関数だけで構成されていること、だが、
これだとほとんどの言語が失格だな。

339:デフォルトの名無しさん
10/01/31 08:29:30
>>338 それは十分条件じゃないか?
下手するとHaskellぐらいしか満たせないw

340:デフォルトの名無しさん
10/01/31 10:14:20
トランスレータって何時頃からあるんだろう
A言語をC言語に変換する

コンパイラ・スクリプトエンジンというよりは
テキスト処理の範疇なような気がするけれども

でも欠点があるから、技法として主流足りえない

あれか出力先の言語・ビルド環境による影響大
適用できる範囲が、自然と絞られざるを得ないとか

toy program というような捕らえ方が一般に正しい
反応なような気もする…

341:デフォルトの名無しさん
10/01/31 10:19:47
toy rograam じゃなくて toy language だった
なれない言葉使おうとするじぶんかっこ悪いorz

342:デフォルトの名無しさん
10/01/31 10:27:21
有名なものでは "Software Tools" (「ソフトウェア作法」) の Ratfor が 1974 年。

初期の C++ は、C 言語へのトランスレータだった。テキスト処理で済むような
内容ではなかったけどね。

343:デフォルトの名無しさん
10/01/31 11:39:44
Cにうまく変換すれば、可搬性でも速度でも申し分ないはず
でもCの再解釈分だけオーバーヘッドがある
D&Eを読むと、初期のC++処理系(Cfront)がトランスレータだったいせいで
生成コードの品質が悪いとか、本格的な言語ではないとか誤解されたと書いてあるが

>toy language というような捕らえ方が一般に正しい
真実どうなのかはともかく、多数の認識は今でもそうなのかも?

344:デフォルトの名無しさん
10/01/31 11:45:36
OOSC初版の頃のEiffelもCへのトランスレータだったはず
今でもそうなのかは知らないが

345:デフォルトの名無しさん
10/01/31 11:48:35
コンパイラ入門―構文解析の原理とlex/yacc、C言語による実装

糞本だった。お前ら責任取れよ


346:デフォルトの名無しさん
10/01/31 11:55:57
>>345
どの辺が糞なのか書いてないから責任とってあげない

347:デフォルトの名無しさん
10/01/31 13:25:00
馬鹿には有効活用できない本を馬鹿に薦めた責任とかそういうこと?

348:デフォルトの名無しさん
10/01/31 13:41:31
良書だった記憶があるけどなあ
薄い割に説明はかなり噛み砕いてあるし、
かといって理論的な部分を無視してるわけでもない

もっとも、内容としては構文解析・yacc/lexの最低限の使い方で終わってるから
詳細は別途ドラゴンブックとかを頼らないといけない
その辺も含めて、巻末に関連書籍の紹介が載ってたはず

349:デフォルトの名無しさん
10/01/31 17:47:18
でもこの本高校生か大学1年程度の
レベルの本だから意味なくね?

350:デフォルトの名無しさん
10/01/31 18:42:04
>>349
この本はそのレベルの人には非常に良い本だし、その良き本を糞本扱いできる程高度な知識を持つものなら手にとって数ページ眺めるだけで自分に必要ないことを理解するハズだよね?
それがわからないという事、つまり>>345の中の人は……(以下自粛


351:デフォルトの名無しさん
10/01/31 19:00:19
よっぽどデカい本屋じゃないと、置いてなくない?

352:デフォルトの名無しさん
10/01/31 22:09:25
関数型言語をラムダ算法を元に解説するのはもう古いの?
真っ先に出てくると思ったのに。

353:デフォルトの名無しさん
10/02/01 03:45:35
理論背景って研究者にしか意味無いからな…

354:デフォルトの名無しさん
10/02/01 13:01:04
でもそういう基礎理論があれば関数型は動作を類推できるじゃないか
コンパイラの設計法にも関わる事だと思うけどな
そういうのを知らないとRubyみたいに仕様が破綻することになる

355:デフォルトの名無しさん
10/02/01 13:06:45
>>352
破壊的リスト操作をラムダ算法で解説できるんですかあなたは?

356:デフォルトの名無しさん
10/02/02 11:59:29
>>352
C#はラムダ式があるから関数型言語だ、ということにしたくないんだろうな。
無名関数はPerlにもある。
もう「値を返すサブルーチン」と同じくらい当たり前になってしまった。

357:デフォルトの名無しさん
10/02/02 12:17:13
ラムダがありゃ関数型言語、という新説が登場しますた

358:デフォルトの名無しさん
10/02/02 13:26:55
文法のlambdaとラムダ計算は別物だよね

359:デフォルトの名無しさん
10/02/02 13:42:28
>>358
それはlambdaのない言語が言い訳するときのセリフ

360:デフォルトの名無しさん
10/02/02 17:10:19
大事なのはクロージャ

361:デフォルトの名無しさん
10/02/02 22:19:21
Objective-Cの勝利。

362:デフォルトの名無しさん
10/02/02 23:29:26
>>352
ほとんどの言語はチューリング完全
チューリング完全ということはチューリングマシンと同じ計算能力を持つ
チューリングマシンとラムダ計算は等価
よってほとんどの言語は関数型である
なんてことになって不都合とか

363:デフォルトの名無しさん
10/02/02 23:31:47
SQLいいよSQL

364:デフォルトの名無しさん
10/02/03 00:14:36
上向き構文解析って遅いし
意味の無い概念じゃないですか

還元とか意味が全くないし

365:デフォルトの名無しさん
10/02/03 08:34:34
オマエが意味を理解できなくても、LALR(1) パーサは現実に働いているわけだが

366:デフォルトの名無しさん
10/02/03 17:06:29
>>364
上向き構文解析って下向きより遅いの?

367:デフォルトの名無しさん
10/02/04 06:44:51
俺のは左向き

368:デフォルトの名無しさん
10/02/04 06:56:20
誰もお前のつむじの向きなんか聞いてない

369:デフォルトの名無しさん
10/02/05 22:54:42
つむじの向きとか何馬鹿言ってんの?ちんこの向きだろ。


370:デフォルトの名無しさん
10/02/07 15:21:49
野暮がすべてを台無しにする

371:デフォルトの名無しさん
10/02/09 00:39:14
遅い

372:デフォルトの名無しさん
10/02/10 16:53:19
ゴスロリ言語

373:デフォルトの名無しさん
10/02/11 19:45:00
おい、Language Implementation Patterns: Create Your Own Domain-Specific and General Programming Languages (Pragmatic Programmers)
これ良書かおしえろ

374:デフォルトの名無しさん
10/02/11 20:43:05
やだ

375:デフォルトの名無しさん
10/02/13 09:02:14
>>373
良書です

376:デフォルトの名無しさん
10/02/13 09:24:04
>>375
嘘つくんじゃねーよ
ANTLR使い方書いてあるだけの
糞本じゃねーかよ

377:デフォルトの名無しさん
10/02/14 09:29:24
上付きとか下付きとか、マンコの形なんかどうだっていい

378:デフォルトの名無しさん
10/02/14 09:36:02
リンクの冒険の話はスレ違いだ

379:デフォルトの名無しさん
10/02/15 18:41:31
>>343
> でもCの再解釈分だけオーバーヘッドがある

そんな一般論は言えない。

380:デフォルトの名無しさん
10/02/16 13:36:59
>>376
たまたまCanalが悪かっただけさ。
つかANTLRで生成されたコード読めばいいだけじゃないか。
それにコードはdmozなりsf.netなり探せばあるだろ。まったく。

Nils M Holm氏による著書
URLリンク(www.bcl.hamilton.ie)

Parsing Techniquesで知られるDick Grune氏のサイト
URLリンク(www.cs.vu.nl)
ダウンロード先 : fURLリンク(ftp.cs.vu.nl)

これでもbomb!と抜かすなら自分の力量が足りないか考えることだな。

381:デフォルトの名無しさん
10/02/22 17:10:32
Aanal ねぇ

382:デフォルトの名無しさん
10/02/26 15:25:43
しつもん
Pythonみたいなインデント指向の言語を字句解析・構文解析するアプローチを教えてください

383:デフォルトの名無しさん
10/02/26 15:36:09
>>382
lexierでインデントを見て、begin、end的なダミーのスコープ限定子を出力すればいいんじゃね

384:デフォルトの名無しさん
10/02/26 15:52:22
>>382
どの言語だか忘れたが、
一旦、インデント数をひとつのパラメータ付き構文要素として、構文木に埋め込み、
これをもう一度構文解析して、構文木を再構成する実装を見たことがある。

実際はステートとして、現在のインデント数を持っておき、
>>383のように、ソースには現れない隠れ構文要素を構文木に構成しながら、
解析するのが簡単だと思う。


385:デフォルトの名無しさん
10/02/26 21:41:22
CPythonの実装は>>383みたいな感じのようだね。INDENT, DEDENTっていうトークンが用意されてる。

386:デフォルトの名無しさん
10/02/26 23:34:26
indentの逆はででーんとdedentなのか
明日会社で自慢しよう

387:デフォルトの名無しさん
10/02/27 00:08:22
インデントでブロック構造なんて信じられない。バグは大丈夫なのか?

388:デフォルトの名無しさん
10/02/27 00:11:28
あと、いくらCPUパワーが上がっても、コンパイルスピードと実行スピードが言語仕様のせいで全く上がらない。
Cにキャリー機能を追加してライブラリと最適化を強化する方が良いのでは?

389:デフォルトの名無しさん
10/02/27 02:00:25
>>387
だれでも最初はそう思うんだよね

でも実際やってみるとほとんど問題ないってわかる

390:デフォルトの名無しさん
10/02/27 02:05:56
>>387
ちょっと長めのコードをコピペすると…

391:デフォルトの名無しさん
10/02/27 02:07:51
コピペ防止効果もあるのか、いいじゃないか

392:デフォルトの名無しさん
10/02/27 02:16:34
コードの移動に支障が出るんだから良い訳無いだろw

393:デフォルトの名無しさん
10/02/27 02:28:29
インデントブロック構造はネストしたブロックから抜ける構造の表現に難があるよな。
ネストが深くなるだけの構造だとキレイだけど。

394:デフォルトの名無しさん
10/02/27 04:21:33
例外処理を作るときに、いちいちインデントを気にし、
少しでも気楽にコピペで作るときにインデントを気にし、
良いこと少ないね

395:デフォルトの名無しさん
10/02/27 04:53:40
>>389
pretty printできないから嫌い


396:デフォルトの名無しさん
10/02/27 05:25:30
>>390-392
pythonはモジュール化が簡単だからそこは問題にならない

>>393
try: except: else: finaly: で問題なし

>>394
お前の能力が低いことはわかった



次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch