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

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

[前50を表示]
350:デフォルトの名無しさん
09/08/13 14:27:07
行の1文字目で処理を分ける程度でいいんじゃね？

351:デフォルトの名無しさん
09/08/13 14:33:22
１文字で思い出したけど、変数名が１文字の場合はハッシュ使わないで
２６個のテーブルってのどう？

352:デフォルトの名無しさん
09/08/13 14:41:29
いつの時代のＢＡＳＩＣだよ

353:デフォルトの名無しさん
09/08/13 15:08:53
Rubyの話をもちっと聞かせてくれ。
俺も拡張機能用にPythonを組み込んだアプリは良く見るが
Rubyを組み込んだアプリは見たことが無い。
これは単にRubyが歴史が浅いからなのか、それともRubyが組み込みで使えない深い理由があるのか？

354:デフォルトの名無しさん
09/08/13 15:33:13
>>352
難読化したjQueryとかじゃね？

355:デフォルトの名無しさん
09/08/13 16:00:40
じゃあこのスレっぽく話を広げようか
俺341だけど、言いだしっぺっぽいので

まず指摘されてたけど、メモリ管理の点で、1.8時代はネイティブスレッドとは
破滅的に相性が悪かったし、ウィンドウシステム・３D・DirexX関係も
相性はあまりよくない。

それに対してPythonは参照カウントとマーク＆スイープの組み合わせで、
マーク＆スイープもおとなしいタイプ。
参照カウントってのはちょっとダサいが、質実剛健だしその点では好感。

あと、これは俺の想像だけど、Pythonの作者は、PythonからCを使うってのと
CからPythonを使うってのを対称的で対等なものとして考えている雰囲気があるし、
技術的に変なこだわりはなくて、いろんなところに配慮しながら無難な実装をしてる。

Rubyは実装技術オタクのMatzが作ったので、変なところでこだわってたり
無駄に離れ業やってたりしてタチが悪い
ただし、Rubyは将来的にはマルチVMも可能にしようという方向で動いてるようだから
そこらへんは変わってくるかもしれない

356:デフォルトの名無しさん
09/08/13 20:56:15
とりあえず Google SketchUp が Ruby 組み込みだったはず。

357:デフォルトの名無しさん
09/08/14 01:20:18

Q. 64bitプログラムとは、どのような文を書くといいのですか

A. コンパイラが64bitコンパイルできるなら何でも64bitプログラムになります

心底「ダメだこのバカ」と思った

358:デフォルトの名無しさん
09/08/14 09:35:58
>>357
つぶやきはtwitterで

359:デフォルトの名無しさん
09/08/14 11:41:34
>>357
スレ違い

64bitのソフトウェアってどうやって作るの？
ｽﾚﾘﾝｸ(tech板)

そのセリフの人物によっては

ハズレの外注を引いたときの対応 2人目
ｽﾚﾘﾝｸ(prog板)
【まるで】使えない新人 0x1C
ｽﾚﾘﾝｸ(prog板)

など

360:デフォルトの名無しさん
09/08/14 21:52:07
トークンという物について質問させてください。
例えば s = "ABC"; という文があった場合トークンは、
1. s
2. =
3. "
4. ABC
5. "
6. ;
でいいのでしょうか？とくに文字列が "ABC" で1つのトークンなのか
"とABCと"で3つのトークンなのかがわかりません。

361:デフォルトの名無しさん
09/08/14 21:59:32
s
=
"ABC"
;
と分けるのが一般的かと思います

362:デフォルトの名無しさん
09/08/15 00:06:09
Forthは"が単独トークンになるね。

363:345
09/08/15 00:07:23
スクリプトエンジンのスレだから、
「組み込み用途における技術的観点での比較」に絞ってレスする。
宗教戦争を煽る気はない。

>>346
>あまりその辺の分野は活発ではないような気がする。

Rubyは組み込みの実績が少ないし活動が活発ではないという理由かな。
それは技術的な理由からは外れている気がする。そうなった理由(背景)がこのスレの主題。

>>349
>そのせいで、パーサとVMが独立できないので、言語まるごと組み込む必要が
>あるのが大変なんじゃないかと。

Rubyが言語まるごと(パーザ+VM)組み込む必要があるのは事実。
ただし、個人的な感覚として、アプリケーションにスクリプトを組み込む目的の多くは、
ユーザによるアプリケーション機能の自由な拡張(スクリプティング)なのだから、
まるごと実装は欠点にはならないと思う。(JavaVMのようなコンパイラ系は別)

(長いので続く)

364:345
09/08/15 00:10:47
(>>363の続き)

>>355
>まず指摘されてたけど、メモリ管理の点で、1.8時代はネイティブスレッドとは
>破滅的に相性が悪かったし、

Rubyとネイティブスレッドとの破滅的な相性の悪さは事実なので同意。
ただし、多くのアプリケーションでは、ネイティブスレッドが前提とはならない
(あるいはRubyの疑似スレッドでもかまわない)ケースが大半を占めるのではないかと思う。

>ウィンドウシステム・３D・DirexX関係も相性はあまりよくない。

RubyもGNOME, WxWidget, Qt, Cocoa, SDLとウィンドウ(GUI toolkit)は揃っているし、
3DもOpenGL拡張ライブラリがあるから、相性が悪い理由にはならない。
DirectXは(おそらく)Rubyで対応しておらず、Phytonの実績が多いのかも(?)しれないが、
それは実績が多いという事実の言明だけであって、具体的な技術面の指摘ではない。
そもそも、これらは拡張ライブラリであってエンジン組み込みではないからスレ違い。

>それに対してPythonは参照カウントとマーク＆スイープの組み合わせで、
>マーク＆スイープもおとなしいタイプ。

GC制御に関わる所有ルールの難解さは、RubyにもPythonにも同様に存在する。
またGC方式の差異は、組み込み用途の利点とは直接的に結びつかないのでスレ違い。
(もし関連性があると考えているなら、具体的に差異を説明してください)

>あと、これは俺の想像だけど、Pythonの作者は、PythonからCを使うってのと
>CからPythonを使うってのを対称的で対等なものとして考えている雰囲気があるし、

対称性はRubyも変わらない。実装の難易度も同等というのが、個人的な実感。

(まだ続く)

365:345
09/08/15 00:15:27
(>>364の続き)

>技術的に変なこだわりはなくて、いろんなところに配慮しながら無難な実装をしてる。

これは(スレ違いだけど)同感で、PythonがSimple is bestを追求してるのは好感。ただし、

>Rubyは実装技術オタクのMatzが作ったので、変なところでこだわってたり
>無駄に離れ業やってたりしてタチが悪い

については、組み込み用途とは無関係だし、Rubyがスキャナとパーザの実装で
離れ業をしている事を除けば、具体性の無いMatzへの個人批判でしかないのでスレ違い。

以上、個人の印象/主観を除いたRubyの組み込み用途における技術的な問題点をまとめると、

- 言語まるごと(パーザ+VM)組み込む必要がある
- ネイティブスレッドとの破滅的な相性の悪さ

の二点のみ。組み込み用途に限れば、Pythonと比較した決定的な欠陥は見当たらない。
実際、拡張ライブラリ(Ruby->C呼び出し)を自作できるRubyプログラマであれば、
Ruby組み込み(C->Ruby呼び出し)も難儀な実装作業ではない、というのが個人的な実感。
(PythpnでもPython->C呼び出しが実装できない人であれば(その逆の)組み込みが難しいのは同じ)

(ゴメン、次で最後だから許して)

366:345
09/08/15 00:18:02
(>>365の続き)

あと(技術的な観点ではないけど)付け加えるとすれば、
Pythonは公式文書として組み込み方法が解説されているのに対して、
Rubyはインタプリタソース(ruby-1.8.x-xxx.tar.gz)に含まれるごく簡単な解説が
唯一の公式文書であるため、自力でネット/書籍から情報を得る必要があるという差異が、
組み込み実績という結果に大きく影響していると思われる。

これだけだと何の事か分かりずらいと思うので、最後に具体的なアドバイスをまとめる。

- RubyプログラマはRuby組み込みで、PythonプログラマはPython組み込みを選ぶのが楽
- ただし、ネイティブスレッドが前提なアプリケーションであれば、Pythonしかない
- どちらも知らない人は、(解説文書が整備されている)Phyton組み込みが無難な選択(=お勧め)
- ただし、言語の選択は、システム全体を見渡してから判断すべき(解説文書の有無だけで
　言語を選択すると、本末転倒になる恐れがある(木を見て森を見ず))

長文/連投のスレ汚し、失礼しますた。

367:デフォルトの名無しさん
09/08/15 00:43:35
元々の話のゲームのスクリプト用途とかなら
既に挙げられてはいるけど lua みたいな
最初から組み込み用に作られたものを使うのが無難じゃないかな
変に難しいこと考えなくても楽に組み込めるし

368:デフォルトの名無しさん
09/08/15 00:53:25
長過ぎて読んでないが、
結局Rubyを無理やり組み込む人はいないと

369:デフォルトの名無しさん
09/08/15 00:53:49
これだけ長文でレスしたくせに、中身がほとんど無いじゃないか。
スレ違いをいちいち長ったらしく指摘しなくていいからもっと短くまとめろよ。

> あと(技術的な観点ではないけど)付け加えるとすれば、
> Pythonは公式文書として組み込み方法が解説されているのに対して、
> Rubyはインタプリタソース(ruby-1.8.x-xxx.tar.gz)に含まれるごく簡単な解説が
> 唯一の公式文書であるため、自力でネット/書籍から情報を得る必要があるという差
> 異が、組み込み実績という結果に大きく影響していると思われる。

付け加えじゃなくて、ここが一番重要なところだろ。

370:デフォルトの名無しさん
09/08/15 00:58:42
機能的にはschemeやjavascript辺りのサブセットがVMで動けば十分
バランスが取れたのがlua
実際にスクリプトを書かせる対象を想定しないとな

371:デフォルトの名無しさん
09/08/15 01:04:13
>>366
まず、俺の主観が入っているってのはその通り。その点はすんまそん
てかあまり深く考えずに書き込んだけど、363氏の説明の方がほとんど
正しいと思います。

いくつか書きたいのは、

PythonのGCは停止時間（いわゆるレスポンス）が悪くない。
循環参照を解消するために定期的に
マーク＆スイープする必要があるけど、そのタイミングは制御できる。
たとえばゲームでいえばシーン暗転の時にやるとか。
Rubyは逆で、楽だけど大味な制御しかできない
以前に256倍網道編でarton氏がpure rubyでゲーム作ってたけど、
実際実行すると結構カクカクだった

ついでにいうとCから使ってるとファイナライザが欲しくなるが、
CPythonならスコープはずれたら解放されることが（個別実装の仕様として）
保証されるので楽。

これらが決定的な利点・欠点かどうかは状況に依存するね。もちろん

あと実装じゃなくて完全にスレチだけど、ライセンスが違うのと、
（用途によるが）配布の際にバイトコード化可能かいう点もある。

以上で撤収します

372:デフォルトの名無しさん
09/08/15 01:40:39
forthってGCってあるんだっけ？
あれ？ディクショナリ内にメモリって確保するんだっけ？

373:デフォルトの名無しさん
09/08/15 01:48:28
組み込み用スクリプトのインタプリタとライブラリのデバッグに時間を掛けたくないよね
ゲーム本体よりも大きいと本末転倒だし
ソースがせいぜい２～３ファイル、合計数百行程度、使えるライブラリは関数をテーブルに登録ぐらいが理想か

374:345
09/08/15 02:21:05
>>371
>まず、俺の主観が入っているってのはその通り。その点はすんまそん

こちらこそネチネチ書いてスマンかったです。ただ主観/印象で論議すると
宗教戦争に陥りがちだから、それを避けたかった。分かってくださいませ。

>Rubyは逆で、楽だけど大味な制御しかできない

RubyもGCを明示的に起動できますよ。シーン暗転前に起動すればいいと思いますが....。

>実際実行すると結構カクカクだった

カクカクになるのは、GCとは別の要因ではないかと思います。
GCが原因なら、(比較的あいた間隔で)実行が固まったように見えるはずですから。

>CPythonならスコープはずれたら解放されることが（個別実装の仕様として）
>保証されるので楽。

これは、(Cスタック上に)auto変数としてPythonVMを確保すれば、そのVMと実行環境が
まとめて自動的に解放されるということでしょうか？
もし本当なら、(Rubyと比較して)かなりプログラマの負担が減りますね。
あと同一プロセス上でのマルチVM(インタプリタ)も簡単に実現できると思われますし。

>あと実装じゃなくて完全にスレチだけど、ライセンスが違うのと、

Rubyライセンスは、とっても緩やかなものです。Matzは言語オタクだから、
(権利の主張よりも)自分の作品を使ってくれることに喜びを感じてるのだと想像させるほどに。

>（用途によるが）配布の際にバイトコード化可能かいう点もある。

これも、(オプソなプロジェクト以外では)採用を決めかねない大きなPythonの利点ですね。
ソース非公開というニーズは多いと思いますから、>>363の最後の段落は撤回します。

375:デフォルトの名無しさん
09/08/15 02:49:20
いまさらなんだが既存のスクリプトエンジンを組込む話は
組込み系言語スレがふさわしいと思う。

376:デフォルトの名無しさん
09/08/15 03:05:22
javascriptはBOTとかのチートツールで使われてる

377:デフォルトの名無しさん
09/08/15 03:08:01
>>375
でもあそこでpとかrとか言ったら荒れるんだよね

378:デフォルトの名無しさん
09/08/15 08:17:18
>>355
> 参照カウントってのはちょっとダサいが、質実剛健だしその点では好感。

mark & sweepと併用するやり方は、
どっちをメインにするとしても、極めて有効なやり方だよ。

379:デフォルトの名無しさん
09/08/15 09:46:27
Rubyは実装として美しくない
最近の高スペックPC当て込んだ

バブル言語だろ

380:デフォルトの名無しさん
09/08/15 10:16:03
Forthは基本的にはライブラリ（辞書）管理もFILOだから、
GCという概念がない。動的なデータ構造も（スタック以外）ないし。

PostScriptは確かスナップショットのようなものを取って、
明示的に指定してそのスナップショット以降に確保されたものを
解放するとかそういう機能がある、と思った。

381:デフォルトの名無しさん
09/08/15 11:29:43
おれ科学計算系で、3回くらいPythonが組み込まれてるソフトを
触ったことがあるよ。個人的な感想だが、pythonの微妙に面倒臭いところが、
組み込みだと逆にぴったり使いやすいんだわ。説明しづらいけど。
Rubyの自由さは組み込み向けだと正直いらない。

382:デフォルトの名無しさん
09/08/15 13:30:14
>>363-366
おおむね同意だが、>>349に対するレスはやや違うと思う。
漠然とスクリプトエンジンと題した場合、真っ先に求められるのは
書いたスクリプトをその場で実行できる手軽さであり、
必然的にインタプリタの要件を満たすことになる。
これに現在主流がバイトコンパイル式であることを勘案すると
言語まるごと(パーサ+VM)を組み込むことがほぼ確定になる。

まあオレがオレオレ処理系を作るときはスクリプトのコンパイラは
事実上のジェネレータとして実装して、
生成物は汎用のスクリプトの処理系に渡してしまうから
自作部分は純粋なコンパイラになるわけだが。

開発用にはそれとは別にスクリプトのタイムスタンプを見て
自動的にコンパイル作業を行う機能を追加することになるだろう。

383:デフォルトの名無しさん
09/08/15 13:32:25
ruby のライセンスは GPL よりは緩いけど
他の組み込み向け言語に比べると
だいぶめんどくさい方だと思うけどな
まぁライセンス云々はスレ違いだけど

384:デフォルトの名無しさん
09/08/15 13:58:23
>>382
パーサーの要不要は用途次第かと
ゲーム用とかだと開発時は素早く試行錯誤したいが
リリース後は基本的にはスクリプトをいじる必要がないので
そういう場合パーサーは無駄なので最終的には外せる方が良い
実行環境がプアなものは特に

385:デフォルトの名無しさん
09/08/15 14:58:43
これが噂の「すり合わせ」というやつか

386:デフォルトの名無しさん
09/08/15 17:01:08
生インタプリタも、中間形式分離型も両方ある奴がほしい、という
要望ってこれからも大きいかな？

今のところメジャーなもので、実現したものってないような気がするけど。

387:デフォルトの名無しさん
09/08/15 17:41:29
Ruby, Python等のダイナミック言語でパーサを分離するのは無理じゃないか？
例えばPerlだと、実行せずに静的にパースすることは不可能なわけだし。
URLﾘﾝｸ(perlmonks.org)

388:345
09/08/15 18:25:09
>>387
Pythonであれば、以下のようなカキコがあるから、
パーザとVMは分離できるように見えるけど、違うの？
Pytonにはevalは存在しないみたいだし(>>349参照)

>>371
>（用途によるが）配布の際にバイトコード化可能かいう点もある。

389:デフォルトの名無しさん
09/08/15 19:16:11
>>380
> Forthは基本的にはライブラリ（辞書）管理もFILOだから、
> GCという概念がない。動的なデータ構造も（スタック以外）ないし。

それは嘘。
FORTHを採用する場合、
後置記法を採用するくらいだから、
非常に小さいインタプリタが必要とされている局面。
だからプアな処理系が多いと言うだけで、
GCをバッチリ実装した処理系はあってもいい。

データがFILOで済むというのも嘘。
辞書に登録したら不必要になる順序はプログラム次第。

390:デフォルトの名無しさん
09/08/15 19:56:55
まあ誰もスクリプトでFORTHなんか使いたくないからどうでもいいけどなｗ

391:387
09/08/15 20:03:53
>>388
実際にPythonやRubyでパースが曖昧になるようなケースは知らないが、
evalがあると分離しにくいのは確かだろうね。ちなみにPythonにもevalはある。

392:デフォルトの名無しさん
09/08/15 21:33:03
そこれりすぷれすよ

393:デフォルトの名無しさん
09/08/15 21:35:35
Rubyが使われないのは単に実績がないからなんでしょ
どんどん使えばいいと思うよ

394:デフォルトの名無しさん
09/08/15 21:45:11
組み込みスクリプト用のLispってあるの？

395:デフォルトの名無しさん
09/08/15 21:50:20
emacs lisp

396:デフォルトの名無しさん
09/08/15 22:02:09
Ypsilon

397:デフォルトの名無しさん
09/08/15 23:35:53
elisp

398:デフォルトの名無しさん
09/08/15 23:43:00
ruby

399:デフォルトの名無しさん
09/08/16 00:05:29
>>394
小さな独自Lisp系ならいくらでもあるよ(CLとかSchemeとかの規格準拠じゃなければ8ビット機でだって動くんだもの)

400:345
09/08/16 01:27:27
>>391
え、Pythonにもevalあるんですか？！うーむ
どちらが真実かは、結局は自分で調べなさいということですな。

401:デフォルトの名無しさん
09/08/16 01:36:23
python -c 'print eval("1+1")'

402:345
09/08/16 01:52:09
>>401
再現しますた。わざわざありがトン。

403:デフォルトの名無しさん
09/08/16 02:37:35
>>394
LISPerは自分用のがあるから
他人の糞LISPなんて使わない

404:デフォルトの名無しさん
09/08/16 02:50:00
>>403
というか、そんな結論ありきな考え方をするやつなら
そもそもこんなスレに来る必要がないわけだが。

405:デフォルトの名無しさん
09/08/16 08:26:25
> データがFILOで済むというのも嘘。
> 辞書に登録したら不必要になる順序はプログラム次第。

少なくとも伝統的なFORTHなら辞書は一方向リンクトリストで最後に
登録されたものから順につながってるし、最後に登録されたワードを
グローバルなワークエリアが指している。
FORGETワードは、特定のワード以降に登録されたワードを全部捨てて
しまう。

そういう構造だから、基本的にGCはない。

406:デフォルトの名無しさん
09/08/17 10:10:39
>>394
ISLISP

407:デフォルトの名無しさん
09/08/26 22:10:05
ABAPのEBNFください

408:デフォルトの名無しさん
09/08/31 11:13:52
ANTLRで苦戦していて質問したいのですが、このスレでいいでしょうか？
もしくは専用スレを立てる？

409:デフォルトの名無しさん
09/08/31 11:40:06
このスレでいい。

410:408
09/08/31 11:58:13
お言葉に甘えて。

ng
　　: n=TOKEN (v=INT|v=FLOAT)
　　　　-> ^(PARAM $n $v)
　　;

ok
　　: n=TOKEN v=(INT|FLOAT)
　　　　-> ^(PARAM $n $v)
　　;

ngルールみたいな書き方はダメでしょうか？
antlrは通るのですが、C言語からそれを呼び出すと
セグメンテーションフォールトします。

411:408
09/08/31 11:59:43
ごめん。ngルールとokルールが逆だった。
v=(INT|FLOAT)がNGで(v=INT|V=FLOAT)がOK.
ANTLR的にv=(INT|FLOAT)という書き方はNGなのでしょうか？

412:デフォルトの名無しさん
09/09/06 21:10:45
出来ればツール頼らずに
手続き型言語作りたいんだけど
どのくらい大変なん

413:デフォルトの名無しさん
09/09/06 21:16:35
コンパイラもアセンブラもリンカもエディタもツールですよ・・・

414:デフォルトの名無しさん
09/09/06 21:40:42
Brainfuckならパンチカード手打ちしてもできるんだろうな

415:デフォルトの名無しさん
09/09/06 21:42:28
TinyBASICくらいの規模なら机上でいけるんじゃないかな

416:デフォルトの名無しさん
09/09/06 21:49:12
ツールってyaccとかlexのことか？
なくても大差ないと思うよ

417:デフォルトの名無しさん
09/09/06 21:57:54
>>412
LLで混乱しない文法なら問題ないんじゃないの？
このスレだったと思うけどμplanとかpascalの構文なら自己記述できるし

418:デフォルトの名無しさん
09/09/06 22:00:52
>>412
どういうコードに落とし込むかってあたりが問題になる位で落としやすいＶＭを設計すれば32Kワードもありゃ言語コンパイラは書ける
UCSD p-systemとかが実際そんなものだ

案ずるより産むが易しってあたりの言語なら悩む前に書き始めてみればいい
コード公開してもいいのなら行き詰まってから助けを求めに此処に戻ってこい

419:デフォルトの名無しさん
09/09/06 22:09:00
いまどきこだわることはないと思うが、
たいがいの言語ならちょいと工夫すればだいたいトップダウンパーザで書ける。

420:デフォルトの名無しさん
09/09/06 22:10:26
>>412
PerlやRubyで書けば、素で描いてもまあ２週間くらいで。

421:デフォルトの名無しさん
09/09/06 23:56:56
LISPだと数分～数時間

422:デフォルトの名無しさん
09/09/07 00:03:58
yane lispおすすぬ

423:デフォルトの名無しさん
09/09/07 00:42:09
Lisperあっち行け

424:デフォルトの名無しさん
09/09/07 12:57:23
おおっ
わからない単語がいっぱいでてきた
たくさんレスありがとう

>>416
そういうことです

>>418
Lispなら作れたからアルゴリズムで行き詰る事は多分無いんだけど
Lispに比べると全然ソース量が桁違いになりそうでヘタレてる･･･

>>420
2週間！！
以外と速い
頑張ってみます

425:デフォルトの名無しさん
09/09/07 20:43:59
Lispすげー

426:デフォルトの名無しさん
09/09/08 07:46:38
Lisp作れたならその上でマクロ書けば数日で手続き型言語作れないか？

427:デフォルトの名無しさん
09/09/08 10:19:06
LISPのインタプリタの作り方ならLISPの入門書の最後に例題で出ているレベル
JavaとかのGC機能が前提の言語ならそんなに難しくないはず
コンパイラなら知らん

LISPのインタプリタと手続き型言語のインタプリタはつくりがまったく違うと思うけどなあ

428:デフォルトの名無しさん
09/09/08 11:44:23
↓このスレの住民なら1レス以内に作れるレベル

429:デフォルトの名無しさん
09/09/08 11:57:33
LISPで全部できると思うならそうすればいい。
ただ、なぜいつまで経ってもLISP系が主要プログラミング言語にならないかの理由についても考慮すべき。

>>424
パーサー、構文木構築、構文木消化・変換、出力を順番に作って中間出力を目で確認する。
中間出力はPerlならData::Dumper、RubyならYAMLで。
この辺がC/C++ではしち面倒くさすぎてスクリプト言語でコンパイラを実装する理由。
よほど大規模なマイ言語のスクリプトを構築しない限りは速度面の不満も出ないしね。

430:デフォルトの名無しさん
09/09/08 12:03:55
>>429
C++はSTLとかを使えば面倒な部分がなくなってスプリクト言語で実装するレベルにならない？

431:デフォルトの名無しさん
09/09/08 12:20:47
>>424
Lispの処理系を書いたことがあるってことは、コンパイラ理論は知っているんだよな？

インタプリタ、中間コード吐いてVM上で動かす、ネイティブバイナリ吐く、
と色々パターンがあるが、基本はまず、再起下降パーサー書いて抽象構文木に
落として、実行するインタプリタを書く。それが出来たら（中間表現に落として
最適化して）コード生成。

432:デフォルトの名無しさん
09/09/08 12:33:59
>>430
C++のSTLでYAML並みの読み書き柔軟性得るのにどれだけコストが必要か考えてみて。

433:デフォルトの名無しさん
09/09/08 14:11:55
boost:serialization ってものも

434:デフォルトの名無しさん
09/09/08 14:19:38
ruby信者は痛いので気づいたらそれ以降触らないようにしてる

435:デフォルトの名無しさん
09/09/08 14:33:52
大体IRを一々ファイルに書き出す必要もねーだろw
Pretty-printerを書いとけば十分

436:デフォルトの名無しさん
09/09/08 16:19:41
>>432
シリアライゼイションを覚えたての子供ですね？

437:デフォルトの名無しさん
09/09/08 16:33:32
ANTLR3でトークンとしてヒットするけど出力しないトークンはどうやって定義すれば良いのでしょうか。
このTOKENでDQを無視してSTRINGだけツリーパーサーで欲しいのですが…
SKIP()はセグメンテーションフォールトで落ちました.

TOKEN
: DQ STRING DQ ;

fragment
DQ : '"' ;

fragment
STRING : ( ES | ~('\\'|'"') )* ;

fragment
ES
: '\\' ('b'|'t'|'n'|'f'|'r'|'\"'|'\''|'\\');

438:デフォルトの名無しさん
09/09/11 21:46:52
ADD 3 TO 4

という文があった場合
BNFするとしたら、どうするのがカッコいいですか？

439:デフォルトの名無しさん
09/09/11 21:52:46
<文> ::= "ADD" "3" "TO" "4"

440:デフォルトの名無しさん
09/09/11 21:57:39
>>439
ATSにする場合どうすればいいの？

441:デフォルトの名無しさん
09/09/11 22:39:18
キンコンキンコンキンコンキンコンキンコンキンコン

442:デフォルトの名無しさん
09/09/14 19:04:29
AST? ATS?

443:デフォルトの名無しさん
09/09/14 20:50:35
>>442
AST
AST
AST
たすけてください

444:デフォルトの名無しさん
09/09/14 20:53:29
>>439みたいな文法だったらツリーにする必要なくね

445:デフォルトの名無しさん
09/09/14 21:01:21
だね。
リスト（線形）でじゅうぶん。

446:デフォルトの名無しさん
09/09/14 21:02:35
自然言語を再現したいのか
本当に "ADD" <NUM> "TO" <NUM> なのかでずいぶん違うよな

447:デフォルトの名無しさん
09/09/14 21:17:13
"ADD" <NUM> "TO" <NUM>
なのです

その跡にFROMとかつくかもしれないのです
お願いします

448:デフォルトの名無しさん
09/09/14 21:23:58
それでも再帰構造さえなければツリーはいらん

449:デフォルトの名無しさん
09/09/14 21:30:25
でも、その後学のために
作ってみたいのです

お願いします

450:デフォルトの名無しさん
09/09/14 21:31:10
だから構文そのものがツリー構造じゃないからツリーにならないんだって

451:デフォルトの名無しさん
09/09/14 21:38:38
>>450
COBOLみたいな構文もツリー構造じゃないから無理？

452:デフォルトの名無しさん
09/09/14 23:39:27
COBOLに式あったっけかな。
要するに、
<式> :== <式> + <式>
とか
<文> :== <IF文> | ...
<IF文> :== "IF" <式> "THEN" <文> ("ELSIF" <文>)* ("ELSE" <文>)? "FI"
みたいな再帰的な構文があると、再帰的なデータ構造でないと
いけないわけで、木が必要になる。

アセンブラみたいなのだったらリスト（線形）で十分。
SQLってどうなの？　識者求む。

453:デフォルトの名無しさん
09/09/15 02:07:23
副問合せ句とかが在るから、再帰じゃないと表現できないんじゃないかな。

ところで、ORACLEのマニュアルにある図ってなんって言ったっけ？
BNFが図になってる奴。

454:デフォルトの名無しさん
09/09/15 03:14:36
構文図

455:デフォルトの名無しさん
09/09/15 10:36:28
Expression ::= "ADD" Factor "TO" Factor
Factor ::= Num | "(" Expression ")"
Num ::= "0".."9"+
かもしれん。
これならツリーになる？

456:デフォルトの名無しさん
09/09/15 10:49:33
AND, OR, UNION等は再帰で定義するから木で表す。

457:デフォルトの名無しさん
09/09/15 11:25:21
>>455
その構文のインスタンスはツリーに出来る。
その構文そのものは再帰があってDAGになる。

458:デフォルトの名無しさん
09/09/17 02:22:52
デザインパターンを駆使してコンパイラを自作しています。

・字句解析＝Chain Of Responsibility
・構文解析＝Interpreter

のように作っていてうまくいっているのですが、
意味解析はどのパターンを使えばいいでしょうか？
どこかのサイトでVisitorを使うとか見たような気がするのですが。

459:デフォルトの名無しさん
09/09/17 08:28:50
>>458
先に仕様があってそれから設計を施していくわけで、
手段と目的を混同しちゃいかん。
誰も君のコンパイラの設計がどうなってるのかなんて知らんだろ。

460:デフォルトの名無しさん
09/09/17 09:34:27
つか, 関数型言語なら別の選択あるだろうけど,
手続き型言語の場合, パーサジェネレータ使った方が
早い処理系ができるだろうに………

461:デフォルトの名無しさん
09/09/17 10:02:39
>>460
それは文法によるだろう。

言語処理系の書きやすさを第一に考えて言語を設計した場合、
手書きの再帰下降パーサでも十二分な速度が出ることはD言語などで実証されている。

462:デフォルトの名無しさん
09/09/17 10:08:28
Interpreterで構文解析っておかしいだろ
どういう設計なのか知らんがVisitorとInterpreterは相互変換できるからどっちかに統一するべき

463:デフォルトの名無しさん
09/09/17 12:13:30
性能はむしろ手書きのパーサのほうが出る。

手書きパーサが不利で、パーサジェネレータが有利なのは以下のような点。
・構文規則とアクションがすっきり分離させて記述できる
・LL(1) に収まらない文法を記述するためのテクニックに煩わされない
・規則をあれこれ変更するのが簡単

あと現代的なテクニックをかじりたいならパーサコンビネータライブラリとか使ってみたら？

464:デフォルトの名無しさん
09/09/17 17:32:14
Scalaの勉強していてパーサコンビネータを触っていたんだけど、
電卓の次に思い浮かぶ使い道がコンパイラとかインタプリタになってしまう。
その間ぐらいで、手ごろな練習のネタって無いものかなぁ？

465:デフォルトの名無しさん
09/09/17 18:49:33
>>464

発想の出発点を見直せば、その人なりのネタは見つけられると思うけどね。

自分だと、最近はRubyでツール作りする機会が多いから、そのコマンド引数
(サブコマンドやオプション指定の組み合わせ)を解釈するのにRaccを使うことがある。
他にも差分記述のある知識表現にPrologのDCGで簡単なDSL(ドメイン固有言語)を作ってみたり、
同じ発想で差分記述のできるテストデータ記述言語をRaccで記述したり。
極端な例だと、Webアプリのプロトタイプ開発で、画面遷移を制御するためにyaccを使い、
画面(フォーム)定義言語もyaccで実装するというマニアックな設計をしたことも。

要は「パーサ」イコール「言語処理系」という思い込みを捨て、単なる再帰的な
データ構造の処理に適した「道具」にすぎないと考えれるのがいいのではないかと思う。

466:デフォルトの名無しさん
09/09/17 18:52:17
>>465
オレだったらそういう用途の処理用データはXMLやらYAMLやらで定義ちゃうだろうな。

467:デフォルトの名無しさん
09/09/17 19:15:33
>>465
おまえUNIX板のyacc&lexスレの>>120だろ

468:デフォルトの名無しさん
09/09/17 20:08:43
>>464
・ラムダ式の使える関数電卓
・文字列がメールアドレスとして正しいかチェックするプログラム（コメントのネストにも対応）
・装飾をネストできる独自Wiki
・テンプレートエンジン

469:465
09/09/17 20:21:28
>>466

最初は同じ事を考えていたんだ。でも、自分一人で作る/使うぶんにはいいんだけど、
他のメンバが使う/使わせることを考えると、エラー処理(構文検査)も考えなけりゃならない。
XMLならDTDやRELAX-NG、YAMLならKawflyみたいなスキーマ定義が必要になる。
そこまでするくらいなら、汎用パーザを使うのがいいんじゃないかと、最終的に判断した。
パーザで適切な構文木さえ構築してしまえば、あとはVisitorパターンを駆使することで、
XMLでもYAMLでも(Latexでも....)出力形式の切り替えは簡単な処理で実現できるからね。

>>467

あたり

470:デフォルトの名無しさん
09/09/17 21:00:25
>>465
なるほど、使い道としては面白いですね。ちょうど今、コマンドライン解析のあたりやってるし。
でも、勉強としてやってるんで、これが正解ってのがあるほうがいいです。
仕様も自分で考えるんだと、パースしやすいような仕様にしてしまうんで。

>>468
メールアドレスって、foo@examples.comだけじゃなく、"foo" <foo@examples.com>, …のほうですよね。
それはやりがいがありそうなネタですね。

471:デフォルトの名無しさん
09/09/17 21:10:01
>>470
・PCRE(Perl 5 Compatible Regular Expression Library)の正規表現のパーズ。
・POSIX shellの文法のパーズ。

472:デフォルトの名無しさん
09/09/17 23:33:28
>>462
Interpreterパターンって構文解析の為のパターンじゃないの？

473:デフォルトの名無しさん
09/09/17 23:39:58
InterpreterはASTのノードに自分自身と子の評価を行う処理を直接埋め込むことで
ASTをそのまま実行するパターンだよ
あらかじめ構文解析を行ってASTを作っておく必要がある

474:デフォルトの名無しさん
09/09/19 03:37:23
Wikipedia項目ﾘﾝｸ

ウィキペディアには
Interpreter パターン = 構文解析のために、文法規則を反映するクラス構造を作る。
って書いてあるんだけど。

475:デフォルトの名無しさん
09/09/19 04:51:05
デザインパターンとか大層なもんじゃないでしょ

476:デフォルトの名無しさん
09/09/19 05:27:58
Interpreterパターンが構文解析のために利用されるのは正しい表現だと思われ。
あらかじめ構文規則に沿ってオブジェクトを配置する必要があるのは事実だけど、
それは構文解析とは別の話しだし、(yaccみたいな)パーザジェネレータも同じだから。(>>473)

最近はデザインパターンから入る若者が多いから、ごっちゃにして考えやすいけどね。
まあ、デーザインパターンなんて大層なもんじゃないという意見に同意するよ。(>>775)

477:デフォルトの名無しさん
09/09/19 06:03:46
>>462=473=476?
君はたぶんいろいろと間違って理解してるからGOF本をしっかり読みなおした方がいいよ
確かにデザインパターンは大層なものじゃないとは思うが、間違った理解は周りの人を
混乱させてむしろ害悪だから

478:デフォルトの名無しさん
09/09/19 06:12:44
>>477
具体的にドゾー

479:デフォルトの名無しさん
09/09/19 06:44:13
>>478
＞VisitorとInterpreterは相互変換できる
できない
VisitorとInterpreterでは全く目的が異なる

＞InterpreterはASTのノードに自分自身と子の評価を行う処理を直接埋め込むことで
＞ASTをそのまま実行するパターンだよ
処理を直接埋め込むこと、そのまま実行することは必須ではない
（GOF本「実装」欄の２．を参照）

＞あらかじめ構文解析を行ってASTを作っておく必要がある
ASTの生成方法までは定義されていないが、Interpreterパターンと言った場合、
（ASTを生成する）Clientオブジェクトもパターンの構成要素に含めて考える方が一般的
（GOF本「構成要素」欄と「実装」欄の１．を参照）

480:476,478
09/09/19 07:03:29
>>477
自分は>>462,473じゃないヨ

>>479
まったく、その通りだね

ところで、GOF本のアレをInterpreterパターンと呼ぶのはどう思うかな？>>all
自分にはインタプリタという言葉のニュアンスから違和感があるんだけど

と、スレらしい話題に戻してみる

481:デフォルトの名無しさん
09/09/19 13:20:31
逆。Parsingにinterpreter patternってのは単純な場合のみ。
ASTインスタンスの生成を行うのは、interpreter patternの仕事だけど、
(ASTインスタンス生成は解釈の特殊な形態の一つ)
parsingそのものはInterpreter patternの仕事じゃない。
単純な例だと一体化しているので、混同しているケースが結構多い。
日本語版wikipediaの記述がその例。(これは古い英語版を元にしている)

GoFより
> The pattern doesn't address parsing. When the grammar is very complex,
> other techniques (such as a parser) are more appropriate.

482:デフォルトの名無しさん
09/09/19 18:12:25
GOFの神格化進んでいるんだね。怖いね。

483:デフォルトの名無しさん
09/09/19 18:24:39
必要以上に貶めている人がいるから
訂正してくれてるだけでしょ？

484:デフォルトの名無しさん
09/09/19 20:17:37
ヤレヤレ

485:デフォルトの名無しさん
09/09/23 08:13:49
形式言語と正規表現って別物ですか?
同じものですか?

486:デフォルトの名無しさん
09/09/23 08:33:39
>>485

正規表現は形式言語の一種である、という解釈でだいたい合っていると思う。
C言語はプログラミング言語の一種である、と同じ解釈ね。
あと、そういう言い方をするなら、正規表現ではなく正規言語だろうね。

487:デフォルトの名無しさん
09/09/23 08:48:28
正規表現と正規言語は別のものだが？

488:デフォルトの名無しさん
09/09/23 09:02:34
正規表現と正規言語と正規文法はどういう関係ですか?
コンパイラの理論の基になっているのは生成文法なんですか?
もし、チョムスキーが生成文法を発表しなかった世界があったら
その世界で使われているコンパイラはどんな物だと思いますか?
COBOLとFORTRUNとlispですか?

489:デフォルトの名無しさん
09/09/23 09:11:11
ちったあ自分で調べろ

490:デフォルトの名無しさん
09/09/23 10:16:49
古い変な本しか手に入らないか
周囲に変なことを吹き込む人がいるか
釣りか

なんにせよ調べる気はあるまい

491:デフォルトの名無しさん
09/09/23 10:20:38
それにしてもチョムスキーのこんな持ち上げ方って久々に見たｗ

492:デフォルトの名無しさん
09/09/23 10:22:29
調べる＝知ってる人に聞く
じゃないの？
本やネットってゴミ情報が多すぎて
知りたい情報にたどりつくまで
手間と時間がかかりすぎるからさ
知ってる人にズバリ答えてもらうのが一番なのよ

493:デフォルトの名無しさん
09/09/23 10:36:03
チョムスキー理論の理解こそが自然言語処理実現の第一歩だぁー！！と
必死になって文献を読みあさっていた、過去の自分を思い出すw

494:デフォルトの名無しさん
09/09/23 11:51:45
文字列が長すぎて
strlen()が'\0'にたどりつくまで
手間と時間がかかりすぎる
って話を思い出した

495:デフォルトの名無しさん
09/09/23 15:01:14
こんなこと如きで他人に苦労させるなカス >488
自分で勉強するつもりが無いのならこんなスレ覗くなボケ
URLﾘﾝｸ(www.bing.com)
URLﾘﾝｸ(www.google.co.jp)

496:デフォルトの名無しさん
09/09/23 15:05:34
と思ったが、最後のは少し興味あるな。
チョムスキーが発表しなくても、同様の概念（ＴＭとか再帰とか翻訳とか形式体系とか）はあるから
結局は同じようなものに落ち着くような気がする。

497:デフォルトの名無しさん
09/09/23 15:43:24
BNF自体はチョムスキーの発明でもないしな

498:デフォルトの名無しさん
09/09/23 15:56:41
インド人だっけ？凄いよね。

499:デフォルトの名無しさん
09/09/23 16:02:39
誰がインド人？

500:デフォルトの名無しさん
09/09/23 16:06:52
っ Wikipedia項目ﾘﾝｸ

501:デフォルトの名無しさん
09/09/23 17:21:39
大体が↓のような感じで構文解析までが行われると思うのですが、

ソースコード → 字句解析 → トークンリスト → 構文解析 → 構文木

トークンリストはトークンクラスのリストと表せますが、
構文木はどのような形になると思いますか？

502:デフォルトの名無しさん
09/09/23 17:36:26
構文要素クラスの木構造

503:デフォルトの名無しさん
09/09/23 17:38:26
開始記号クラスかな

504:デフォルトの名無しさん
09/09/23 17:45:32
このあいだまでは「パニーニ」と表記してた気がするが、最近は「パーニニ」なのか。
昔インド人の先生に尋ねたら俺の耳にはパニニーと聞こえたが。

てかBNFはバッカス（と、本人はあまり乗り気でないようだがナウア）の功績だろ一応はやっぱ。

505:デフォルトの名無しさん
09/09/23 20:01:10
インド人の発音は独特だから

506:デフォルトの名無しさん
09/09/24 00:29:14
日本人の発音の方がはるかに独特です

507:デフォルトの名無しさん
09/09/24 00:35:57
かもしれぬ
インド人と言っても様々だ
が、日本人がインド人の発音を聴き取るのは慣れないと無理
驚くというか途方に暮れるぞ

508:デフォルトの名無しさん
09/09/24 01:41:42
詳しく！

509:デフォルトの名無しさん
09/09/24 02:38:16
>>507
そこでインド人を右へ

510:デフォルトの名無しさん
09/09/24 05:56:31
なるほど。たしかみてみよう

511:デフォルトの名無しさん
09/09/24 14:00:01
確かめた結果、
ザンギュラのスーパーウリアッ上
でした

512:デフォルトの名無しさん
09/09/24 14:23:33
ダトル・オブ・ぷよぷよ

513:デフォルトの名無しさん
09/09/25 20:00:42
ゆとり教育は嘆かわしい。
中学生の息子の机に数学のノートが開いていた。
なんと、数式にビックリマークを付けて遊んでいた。
出てくる数字はほとんどが1桁の整数のかけ算。
しかも答が間違ってる。
小学校の九九の復習にもなってない。
本当に嘆かわしい...。

514:デフォルトの名無しさん
09/09/25 20:16:35
>>513
ゆとり教育でなければ九九ができるようになるはずだという発想がすでにおかしい
人任せにしてないで、自分で教えてあげたら？
多分、どっかでつまずいてそのままになってるんだと思うよ。

515:デフォルトの名無しさん
09/09/25 20:22:54
>>514
ネタにマジレス、カコワルイ。
ここは息子インタプリタが自然数の階乗をパースして計算していると考えるんだ。

516:デフォルトの名無しさん
09/09/25 21:06:42
ネタだと気付かないところがすでにおかしい

517:デフォルトの名無しさん
09/09/25 22:11:00
不思議なインド人に対抗するには
九九じゃなくて二五六二五六やらせるべき

518:デフォルトの名無しさん
09/09/25 22:30:37
>>513を読んで想像すべきだった状況の例
3!×5!=720

519:デフォルトの名無しさん
09/09/25 22:40:00
>>513って親がゆとり世代だった、ってオチ？

520:デフォルトの名無しさん
09/09/25 22:40:49
階乗は習ってねーや

521:デフォルトの名無しさん
09/09/26 00:53:30
「ジョークを解説するのはカエルを解剖するのと似ている。
解剖されたカエルには誰も興味を示さないし、カエルは死ぬ」

522:デフォルトの名無しさん
09/09/26 01:15:17
なんかえらく主観的な格言だなぁ
説得力のある文体に騙されそうになるけど

523:デフォルトの名無しさん
09/09/26 01:25:10
解剖したカエルは、フランス人スタッフがおいしく頂きました。

524:デフォルトの名無しさん
09/09/26 08:36:52
最初からコンテキストもなにもなしにジョークを投下するやつが悪い

525:デフォルトの名無しさん
09/09/26 23:45:56
antlrworksで正規表現の

[0-9]{1,16}

ってどうやって書けばいいの？

526:デフォルトの名無しさん
09/09/27 04:32:51
日本ではコンパイラの研究ってあんまはやってないの?
有名な研究室ってどこ?

527:デフォルトの名無しさん
09/09/27 09:31:33
>>526
コンパイラ site:ac.jp で検索してみるとか。

528:デフォルトの名無しさん
09/10/01 23:19:37
タイガーブックの最新版ってどうよ？
今月末に出るけど

529:デフォルトの名無しさん
09/10/02 20:43:42
どうよ？だと？
自分で買ってきて報告しろやヴぉけ

530:デフォルトの名無しさん
09/10/02 22:48:49
無駄無駄
どうよ？厨はいつだって人から貰うだけ

531:デフォルトの名無しさん
09/10/03 00:06:04
俺の上腕二頭筋どうよ？

532:デフォルトの名無しさん
09/10/03 00:14:32
すごく・・・ぷよぷよです・・・

533:デフォルトの名無しさん
09/10/03 05:55:58
タイガーブックがついに邦訳されて今月末に出版されるよ

534:デフォルトの名無しさん
09/10/03 07:23:00
無駄無駄
されるよ？厨はいつだって人から貰うだけ

535:デフォルトの名無しさん
09/10/03 12:42:47
preccsより腐ってない
フリーのプロトコルコンパイラ知りませんか？

536:デフォルトの名無しさん
09/10/03 14:04:03
尻いりませんか？だと？
いいのかい？ホイホイ突いちまって

537:デフォルトの名無しさん
09/10/03 14:39:57
>>535

preccsのドコが腐っていると感じたのかな？
自分は初見だったのでググってみて、CSPというかOccamの実装という印象を持った。
そのうえで、予想される「腐って」いそうな点をあげてみる。(実際には触っていないヨ)
・コンパイラの実装がバグだらけ
・マルチスレッディングに対応していない
・デバッグが難しい
・プロトコル記述(状態遷移)が直感的ではない
・メッセージ処理機能が不十分
・プロトコル定義の網羅性に欠ける

あと、このスレよりもネットワークプログラミングスレ向きな話題かも。
このスレだと「自分の好みに合ったコンパイラを作れ！」なレスが中心になってしまう気がする。

538:デフォルトの名無しさん
09/10/04 04:03:23
実質パーサの話題に終始してるがな
コンパイラですらない
インタプリタでもない

539:デフォルトの名無しさん
09/10/04 10:59:49
じゃ、話題の提供ヨロシク

540:デフォルトの名無しさん
09/10/05 13:04:03
Pythonでコマンドを作って、
自作のスクリプトでそのコマンドを呼び出すという仕組みで処理系を構築してる。
すでにある程度動いてるんだが、
現状手動で作成してるコマンドの一覧をPythonのプログラム側からどうやって吐き出そうかなと考えているところ。
sed/awkあたりで簡単に切り貼りできるような形式を用意できるといいかなぁ。
できればコマンドのマニュアルも一緒に生成できるといいんだが。

現在固定になってるコマンド一覧は実際にはXMLファイルで、
コンパイラがデシリアライズの形で一括で読み込める仕組みにしている。
XMLを手作業で編集するのはしんどいので、シリアライズで書き出す簡単なプログラムを用意して、それを毎回手で編集してる。

541:デフォルトの名無しさん
09/10/05 13:38:45
>>540
JavaDocみたいに定型のコメントを書くのはどうですか？

542:デフォルトの名無しさん
09/10/05 14:02:58
pydoc

543:デフォルトの名無しさん
09/10/06 12:51:07
実装には命令型言語より関数型言語の方が向いているのかな
Pugsが出てからずいぶん経つのにPerl6まだ出ない

544:デフォルトの名無しさん
09/10/06 13:45:27
>>543
そんな漠然としたレベルの話だと、好みでとしかいいようがないんじゃ。
ただ、Haskellの論理的な記述能力は空恐ろしいものがあるな。
例えばYAMLパーサのリファレンス実装はHaskell製だ。
HTMLの仕様書用意されてはいるが仕様の詳細までは網羅されておらず、参考程度にしかならない。
で、ソースコードみてみたら、ほとんどBNF式そのまんま。
これをネイティブで解釈するんかHaskellは……。

545:デフォルトの名無しさん
09/10/06 13:51:06
再帰下降パーザを書くのに関数型言語は合ってると思う
パーザ以外の部分は知らん

546:デフォルトの名無しさん
09/10/06 22:35:37
Haskellは新しく演算子をユーザ定義できるからな。
優先順位を付けて。それが例えinfixでも。
出来る奴が書いたコードの記述力は破壊的。
Parser Combinatorの発明は、奴等ならではだろう。

547:デフォルトの名無しさん
09/10/06 22:44:43
>>546
> Haskellは新しく演算子をユーザ定義できるからな。
> 優先順位を付けて。それが例えinfixでも。

それPrologでもできるよ。何十年も前から

次ページ