「コンパイラ・スクリプトエンジン」相談室6at TECH
「コンパイラ・スクリプトエンジン」相談室6 - 暇つぶし2ch331:デフォルトの名無しさん
05/05/27 20:52:11
>>329
lispの例題とかで見たこと無い?
ものすげーえげつない再帰呼び出しのテストだと思ってくれ。

332:デフォルトの名無しさん
05/05/27 21:35:57
>>331
すまんが、そういう話じゃない
関数呼び出しのテストにしても変数が1個や2個の値参照程度では
違いは出にくいということ

333:デフォルトの名無しさん
05/05/27 21:41:48
こんな感じ?

extern yattarman(){
printf("アフォ\n");
}


334:デフォルトの名無しさん
05/05/27 21:50:56
ack(m,n) = n+1            if m = 0
       ack(m-1, 1)       if n = 0
       ack(m-1, ack(m,n-1))  otherwise

335:デフォルトの名無しさん
05/05/27 21:53:10
>>334
すまんが、そういう話じゃない
関数呼び出しのテストにしても変数が1個や2個の値参照程度では
違いは出にくいということ

336:デフォルトの名無しさん
05/05/27 22:06:19
ここはお前の話をみんなで静聴するスレじゃないぞ。
各人がしたいように話を転がしていくだけだ。

337:デフォルトの名無しさん
05/05/27 22:08:15
仕切り厨の自己否定乙ww


338:デフォルトの名無しさん
05/05/28 00:28:16
>>337
すまんが、そういう話じゃない
関数呼び出しのテストにしても変数が1個や2個の値参照程度では
違いは出にくいということ

339:デフォルトの名無しさん
05/05/28 03:12:13
>>333
そう、それだ!


340:デフォルトの名無しさん
05/05/28 04:15:37
>>333
extern coffee(){ 
printf("ボケ\n"); 
} 

extern lighter(){ 
printf("ゴルァ\n"); 
} 


341:デフォルトの名無しさん
05/05/28 23:34:48
アメ、コーヒー、ライター?


342:デフォルトの名無しさん
05/05/29 01:10:17
ヤッターマン

343:デフォルトの名無しさん
05/06/04 04:52:17
そろそろN88BASIC作ろうと思うんだけど、どう?

344:デフォルトの名無しさん
05/06/04 12:18:56
N05BASICの誤りでは?
どんな畑になることやらw


345:デフォルトの名無しさん
05/06/04 21:04:29
>>344
???

346:デフォルトの名無しさん
05/06/04 21:16:13
>>345
しぃーっ!見ちゃだめ!

347:デフォルトの名無しさん
05/06/04 22:01:33
bison -v で出力される *.output と言うファイルの書式の解説って
マニュアルには含まれてないと思うのですが、ありますか?


348:デフォルトの名無しさん
05/06/04 22:05:10
>>347
人が見て理解できれば十分だと思うけど……


*.output ファイル自体をいじるとか、そういうことを考えているの?

349:デフォルトの名無しさん
05/06/04 22:34:23
>>348

state 100
nls -> '\n' . (rule 200)

とかあった場合、この点(.)は何を意味するものなの?


350:デフォルトの名無しさん
05/06/05 00:02:52
オライリーの本読め。解説してあったと思うが。

なくてもそれくらい見当つかないんじゃ困るとは思う。


351:デフォルトの名無しさん
05/06/05 00:12:32
lex&yacc でイイデツカ?


352:デフォルトの名無しさん
05/06/05 00:22:29
うん。


353:デフォルトの名無しさん
05/06/05 03:26:05
>>344
それ以前に2000年問題に対応してください

354:デフォルトの名無しさん
05/06/05 03:35:03
>>344==353

355:デフォルトの名無しさん
05/06/05 11:17:47
>>349
LALR(1)

356:351
05/06/05 18:39:22
>>352
ありがとう。

>>355
LALR(1) の標準記法とかあるのですか?


357:デフォルトの名無しさん
05/06/05 18:47:49
>>356
標準かどうかしらんが
LALR(1)を勉強した人なら一瞬で分かる。

358:デフォルトの名無しさん
05/06/05 19:46:23
>>353
畑は1年単位のサイクルの筈。


359:デフォルトの名無しさん
05/06/05 23:06:16
>>344==353==358

360:デフォルトの名無しさん
05/06/06 08:56:20
並列化コンパイラを作ることになったんですが、
なにをどうすればいいかわかりません
良い本、サイトなどあれば教えてください

361:デフォルトの名無しさん
05/06/06 09:14:01
TAに泣きつけ。

362:デフォルトの名無しさん
05/06/06 10:51:43
並列化のための補助文法を言語的に持っているという意味?
それとも複数の演算素子にコードを割り振る方?


363:360
05/06/06 17:05:12
そもそもコンパイラそのものがわかっていないので
1から勉強できるようなものがあると助かるとです

364:デフォルトの名無しさん
05/06/06 18:37:44
360は早稲田の学生

365:デフォルトの名無しさん
05/06/06 19:54:03
>>363
まずは、りんご畑系の本を勧める。


366:360
05/06/07 02:28:10
>>364
駅弁です

>>365
リンゴ畑とは?

367:デフォルトの名無しさん
05/06/07 23:42:17
予約語と識別子との区別を、字句解析時に行ってしまうのがいいのか、構文解析時になってから行うのがいいのか悩んでいます。
字句解析時に行ったほうがわかりやすいような気もするけど、構文解析時に行ったほうが柔軟になるし(予約語と同じ名前のメソッド名を定義できるとか)。
みなさんはどうしてますか。

368:デフォルトの名無しさん
05/06/07 23:52:07
作ろうとしている言語の文法を合うように
決めればいいんじゃない?

つまんない意見でごめんな

369:デフォルトの名無しさん
05/06/07 23:59:39
ほぼ同意。

ps.りんご畑だとパーサだったかな?


370:デフォルトの名無しさん
05/06/08 00:12:20
typo
×文法を合うように
○文法に合うように


371:デフォルトの名無しさん
05/06/08 01:10:48
>>367
>予約語と同じ名前のメソッド名を定義できるとか

そもそもこんなことができると紛らわしいからよした方が…
ワインバーグが「プログラミングの心理学」のどっかにそんなことを書いていたはず。


372:デフォルトの名無しさん
05/06/08 01:17:01
>>371
古い概念にとらわれるな


373:デフォルトの名無しさん
05/06/08 10:02:30
>>372
歴史に学べ

374:デフォルトの名無しさん
05/06/08 10:04:01
>>367
ifという名前のローカル変数を作ってしまってif文が使えない
とかいうことになるので、字句解析でやっといた方がいいんじゃないかな。

375:デフォルトの名無しさん
05/06/08 10:41:04
素人な質問だけど、構文解析どう書くの?
IDENT expr IDENT block IDENT block
で$1と$3と$5がそれぞれ"if" "then" "else"であることを
アクションでチェック?現実に実現可能なもの?

376:デフォルトの名無しさん
05/06/08 12:25:52
構文木を識別子以外のものに基づいて組み立てれば無問題。括弧とか。



377:デフォルトの名無しさん
05/06/08 12:26:47
>>360
育男ちゃんに代打ちしてもらえばいいじゃん

378:デフォルトの名無しさん
05/06/08 13:08:32
文法の、どこに error を噛ませれば良いのか分からんですたい

379:デフォルトの名無しさん
05/06/08 13:39:49
エラーが発生したらなかったことにしたい単位のところ。
全てが式の言語なら式。Cみたいのなら文か関数。
例外処理のcatchのようなもんだ。


380:デフォルトの名無しさん
05/06/08 20:52:34
それよりも的確な場所でエラーを検出することができるかどうかだよ

極端な言語で言えば、LISP系はソースコードの何行目でエラーが出た、
とかの検出が困難。
S式として妥当ならreadが通ってしまう。
readに通した時点で行の情報は失われる。

よく知らないけどLISPのエラー検出の最小単位って関数かな?
エラー検出とかのためにリストがどの行のものか保存するLISP処理系ってある?


381:デフォルトの名無しさん
05/06/08 20:56:29
VCのコンパイラって/Pオプションでプリプロセッサを通した結果がとりだせるじゃないですか
bccではそのようなコンパイルオプションってないですか?

382:367
05/06/08 21:04:00
ご回答いただいた皆様、どうもありがとうございます。
そもそもの動機は、事前にすべての予約語を予測することができない(あとで必ず新しい予約語を追加したくなる)ので、
せめて識別子がくることが明確にわかっている場所でなら、予約語でも識別子として使えるようにしておけば、
新しい予約語を追加したときに、多少なりとも影響を小さくできるかなと思ったからです。
また個人的には「switch」や「end」をメソッド名として使えたらなーと思うことがあったので、メソッド名であることが明らかなら
予約語でもメソッド名にできるようにしたかったのです。(Rubyだとそれができるみたい)

しかーし、発想をかえまして、予約語になんらかのプレフィックスをつけることにしました。
PHPやPerlでは、変数名と予約語がかぶらないように変数名のほうにプレフィックスをつけますが、
それとは逆に予約語にプレフィックスをつければ、変数名やメソッド名とかぶらなくてすむんじゃないかと。
ifやwhileにプレフィックスをつける言語なんてきわものっぽいですが、なんか気に入ったのでこれでいくことにします。

スレ汚しすみませんでした。

383:デフォルトの名無しさん
05/06/08 21:06:52
>>379
いや、俺が気になるのは、それが全てのエラーを正しく捕まえてくれるのかと、無限ループが起きないかどうかです
……多分、yyerrok の挙動の理解が甘いような気がするんだけど

根元に error を仕込みたいですけど、エラーリカバリ後のゴミが結構引っかかります orz

384:デフォルトの名無しさん
05/06/08 21:54:44
もれが気になるのは、ねーちゃんのケータイかどうかってことだ。


385:デフォルトの名無しさん
05/06/08 21:59:44
>>384
どっからそういう話になるんだ?
誤爆?


386:デフォルトの名無しさん
05/06/08 22:12:00
URLリンク(www.sidhe.org)
Parrotの実装について

387:デフォルトの名無しさん
05/06/08 23:24:31
予約語と識別子の区別はなんとでもなると思うが、
後から追加した予約語の文法定義はどうやって追加するの?
ってあたりが気になった。

388:デフォルトの名無しさん
05/06/09 20:22:41
>>380
gaucheとか、エラー時に行番号を表示してくれるから何かやってるんじゃない?


389:デフォルトの名無しさん
05/06/09 23:54:13
>>380
>>388
構文木のノード毎に、行数を覚えておけば済むでしょ


390:デフォルトの名無しさん
05/06/10 00:05:29
>>389
(´,_ゝ`)プッ

391:デフォルトの名無しさん
05/06/10 00:49:48
gaucheってランタイムエラーのときも行数表示するん?

392:デフォルトの名無しさん
05/06/10 00:50:19
  「人権擁護法案」を知って下さい。どう考えるかは 貴方次第です。

法務省 第154回国会(常会)提出主要法律案 人権擁護法(案)
URLリンク(www.moj.go.jp)

ズームイン朝でおなじみ、 辛坊治郎さんのコラムです。
URLリンク(shinsho.shueisha.co.jp)

こちらは櫻井よしこさんのコラムです。
URLリンク(blog.yoshiko-sakurai.jp)

櫻井よしこ 人権擁護法案緊急リポ(SAPIO 6月22日号6月8日発売)
URLリンク(www.uplo.net)
URLリンク(www.uplo.net)
URLリンク(www.uplo.net)
URLリンク(www.uplo.net)

他にもこのような方々が危険性を危惧しています。
西尾幹二
URLリンク(nitiroku-nishio.jp)
西村幸祐
URLリンク(nishimura-voice.seesaa.net)

タックルと報道2001とチャンネル桜の動画。
URLリンク(nur.ath.cx)


参考資料 国連の勧告といわれる物

国内機構の地位に関する原則(パリ原則)
URLリンク(www.moj.go.jp)


393:デフォルトの名無しさん
05/06/10 09:18:46
>>391
するよん。バックトレースにも表示される。

394:デフォルトの名無しさん
05/06/10 13:02:02
>>367
字句解析で識別するしかない。

予約語のない(キーワードと同じ変数名が使える)言語としてはPL/Iがある(あっ
た、というべきか)。が、たとえ予約語のない言語でもキーワードは字句解析
で識別しないとダメだろう。

そのような言語では、具体的にはこういうふうにする。

stmt: IF expr THEN ....(略)

expr: Identifier

Identifier: IDENTIFIER | IF | THEN ...

むろんCのような文法ではこれはconflictをおこすので無理だが、
PL/Iならなんとかなるかもしれない。もっともPL/IがLR(1)で記述できるかど
うかは不勉強にして知らない。もっと長い先読みが必要かもしれない。


395:りんごタン
05/06/11 11:18:27
>>394

> むろんCのような文法ではこれはconflictをおこすので無理だが、
> PL/Iならなんとかなるかもしれない。

どういうことですか?

PL/1 自体、リアルでは使ったこと無いんですが(つまり、本の知識のみ)
conflict の発生に大きな違いがでますか?


396:デフォルトの名無しさん
05/06/11 12:39:18
>>394
LISP みたいに () で囲むというような規則を厳守すれば、キーワードの識別は意味解析まで遅らせられる気がしますが

397:デフォルトの名無しさん
05/06/12 10:53:24
URLリンク(llvm.cs.uiuc.edu)

RubyComp: A Ruby-to-LLVM Compiler Prototype (Anders Alexandersson, M.S. Thesis)

Abstract:

Dynamic programming languages are not generally precompiled, but are interpreted at run-time.
This approach has some serious drawbacks, e.g. complex deployment,
human readable source code not preserving the intellectual properties of the developers and
no ability to do optimizations at compile-time or run-time.

In this paper we study the possibility to precompile the Ruby language, a dynamic object-oriented language,
into Low Level Virtual Machine (LLVM) code for execution by the LLVM run-time,
a compiler framework for lifelong optimization of an application.
The result of the project is a Ruby compiler prototype, describing the infrastructure and overall design principles
to map the highly dynamic properties of the Ruby language into low-level static constructs of the LLVM language.

The LLVM framework supports different hardware platforms, and by using LLVM as the target of compilation
the benefits of that portability are gained.


398:デフォルトの名無しさん
05/06/12 13:34:32
ほう。
漏れ自身はRubyは全然使ってないんだが、
世界中にファンが居るんですね。

動的言語としてのRubyの言語仕様のうち、
コンパイルしにくい要素って何なのでしょうか

399:デフォルトの名無しさん
05/06/12 17:17:28
eval?

400:デフォルトの名無しさん
05/06/12 17:23:55
(´・ω・`) エヴァってても関係無いがな

401:デフォルトの名無しさん
05/06/12 17:38:48
evalとリフレクション?

>>400
ないの?
lisp系以外でevalのある言語のコンパイラってある?
perlccやexerbのようなのでなく。

402:デフォルトの名無しさん
05/06/12 17:53:24
Lisp 以外のネイティブコンパイラは知らないけど、
Lisp と同じようにすれば良いかと
(スタンドアローンは要件に無かったから)

403:デフォルトの名無しさん
05/06/12 18:29:58
LISP房とRUBY房ほど、有名な房はいないなW


404:デフォルトの名無しさん
05/06/12 18:31:03
房?

405:デフォルトの名無しさん
05/06/12 19:38:28
JavaとかC++は??

406:デフォルトの名無しさん
05/06/12 20:48:33
>>403
2大棒


407:デフォルトの名無しさん
05/06/12 21:30:37
>>398
コンパイルしにくいというよりは、staticに決めにくいということでは?
メソッド呼び出しをstaticにすることなんか絶対にできないし、
クラス定義でさえ実行文だから、staticにクラスを作成しておくこともできないし、
ローカル変数と引数なしのメソッドの見分けもつかないし。
staticにできることといえば、事前に構文解析してツリーつくるぐらいだけじゃねえか?

408:デフォルトの名無しさん
05/06/12 22:13:27
>>407
Rubyは知らないが、アンタの話がピント外れなのはよく判る。

409:デフォルトの名無しさん
05/06/12 22:34:09
>>408
スレ的にピントをぼかしてるのはおまい様ではないのかえ?


410:デフォルトの名無しさん
05/06/12 22:37:21
>>407
>staticにできることといえば、事前に構文解析してツリーつくるぐらいだけじゃねえか?

そう、exerbはまさにそれ。
でもevalがあるからパーサが不要というわけじゃない。
結局スクリプトにインタプリタをくっつけただけ(に毛が生えた程度)

411:デフォルトの名無しさん
05/06/12 23:01:58
>>410
でもその”毛”は結構デカイんだよな(w


412:デフォルトの名無しさん
05/06/12 23:06:40
剛毛

413:デフォルトの名無しさん
05/06/12 23:13:18
>>402
lispのevalってコンパイラではどんな風に実装されてるの?
多分S式に特化した工夫があるんだよね。

>>411
作るのは大変だろうけど、そんなに実行効率変わるもんなの?

414:デフォルトの名無しさん
05/06/12 23:33:12
おれは、どちらかというとパイパン派だけどな


415:デフォルトの名無しさん
05/06/13 00:13:17
>>409
ほっといてやれよ、408が知らないのはRubyだけじゃないだろ。

416:デフォルトの名無しさん
05/06/13 00:51:55
LISPのevalがする仕事ってのは入力リストを
コードと見なしてマクロ展開しながら評価してくだけ。
S式になってる時点で字句解析が済んだリストの状態ってことだから、
たとえば動的に作成した引数リストを渡したいだけならreadしたものを
そのままapplyに渡せたりするので、少し工夫すればevalを使う
必要はあんまりない。
ほとんどコンパイル済みのクロージャとかで間に合う。
この辺rubyとかperlのevalの事情とはだいぶ違う。

417:デフォルトの名無しさん
05/06/13 01:18:37
よくあるようなschemeコンパイラが出力するネイティブコードには
1) プログラム全体のS式(パースなどはされてるかも)
2) S式を評価するインタプリタ(eval)
に加えて、最適化用に
3) defineされた関数をコンパイルしたネイティブコード
があらかじめ含まれてる、って理解でいいかな。

しかし一部のschemeコンパイラ(chezとか)の異常な速さには、
もっと秘密がありそうだw

418:デフォルトの名無しさん
05/06/13 01:30:09
は? 1を含む必要が理解できないんだが。


419:デフォルトの名無しさん
05/06/13 01:44:14
>>417
ChezやGaucheなどの速い部類のschemeは
read後のevalの代わりにcompileフェーズが入る。
もちろんマクロはcompile直前に全て展開される。
read→compile→run(→write)

420:デフォルトの名無しさん
05/06/13 01:59:54
>>418
あ、schemeはリフレクションみたいにプログラムをデータとして扱うことはできないのか。
じゃquoteされてるとこだけでいいのかも。(自信なし)

>>419
あー、JITか。なるほどなるほど。サンクスです。
Rubyも爆速コンパイラ作ってJITやhotspotすればいいんだな。(無理)

421:デフォルトの名無しさん
05/06/13 02:01:09
>>416
むしろevalが出てくるLISPコードは下手糞が書いたものか、
自分で評価周りを拡張するとかの特殊用途ぐらい。

422:デフォルトの名無しさん
05/06/13 02:02:31
>420
誤解があるようだけど
schemeのS式もLISPと同じくプログラム=データですよ。

423:デフォルトの名無しさん
05/06/13 02:09:49
いったんdefineされた関数の定義を、S式として取り出して扱うこともできるんでしたっけ。
(define (f x) x) の f から '(lambda (x) x) を取り出すみたいな。
だとしたら>>417の1がいるかな、と思ったんですが。

424:デフォルトの名無しさん
05/06/13 02:46:12
>>423
かなり昔のLISPの本を読んだね?
今はdefine定義された関数を評価するとクロージャという
Schemeオブジェクトとして抽象化される。
クロージャからデータ(コードの印字表現)は基本的に取り出すことはできない。
コンパイルすると不要な情報は消えてしまうし、できたとしても処理系依存で実装される。
もちろん取り出せる処理系もある。
まあ、これ以上詳しくはschemeスレで聞くか、適当な入門サイトでも見た方が。

425:398
05/06/13 12:14:36
下らん。もう一回言うね。

  >>397の研究内容を踏まえて、
  動的言語としてのRubyの言語仕様のうち、
  コンパイルしにくい要素って何なんだろうね。

426:デフォルトの名無しさん
05/06/13 13:26:07
>>425
は?今まで言われてきた通りじゃないの?

>the main difficulty of compiling Ruby is the fact that the program can
>be updated during run-time

とあるから、論文の著者自体は>>407を問題視してると思われ。
つか、論文あるんだから読めよ。

427:デフォルトの名無しさん
05/06/13 13:43:04
>>424
なるほど、ありがとうございました。
schemeというとプログラム=データだってよく聞くんですが、
その本質の意味や利点をいまいち理解できてないんですよね。
入門サイトに行ってきます。

428:デフォルトの名無しさん
05/06/13 14:05:56
>>426
ちょっと目を通した。
>>407そのまんまの話で、proof of conceptという事でがっくり。
今後に期待といった感じか。

429:398
05/06/13 18:15:38
>>426
論外だな。もう一回言うね。

  >>397の研究内容を踏まえて、
  動的言語としてのRubyの言語仕様のうち、
  コンパイルしにくい要素って何なんだろうね。

430:398=428 ◆Nj.Bk96Vy2
05/06/13 18:21:49
>>429をスレ荒らしと判定。レス削除依頼を出します。

431:デフォルトの名無しさん
05/06/13 19:47:55
>>429
そもそもrubyはコンパイルできないじゃん
しにくいという以前に、できない言語なんだよ

432:デフォルトの名無しさん
05/06/13 20:41:35
英語読めないんだね

433:デフォルトの名無しさん
05/06/13 21:28:11
>>431
はぁ?
そんな言語ありませんが?

アフォですか?


434:デフォルトの名無しさん
05/06/13 21:44:05
コンパイルの定義で揉める巧妙な書き込みがなされているな

435:デフォルトの名無しさん
05/06/13 21:44:44
Rubyは存在しないらしい、という学説がここに提唱されました

436:デフォルトの名無しさん
05/06/13 22:35:40
具体的な根拠も書かずに煽るだけの輩がいるからねぇ

437:デフォルトの名無しさん
05/06/13 23:19:26
>>436
発狂?

438:デフォルトの名無しさん
05/06/13 23:23:15
Rubyの開発周りはキチガイだらけだからね

439:デフォルトの名無しさん
05/06/13 23:25:50
なんだ荒らしか

440:ptr->433
05/06/14 00:13:09
要は、コンパイラが作れないような言語はないってことでしょ?


441:デフォルトの名無しさん
05/06/14 00:31:05
インタプリタが作れる言語ならコンパイラは原理的には作れるね。
コンパイルするメリットがあるかどうかはともかく。

442:デフォルトの名無しさん
05/06/14 01:18:12
eval

443:デフォルトの名無しさん
05/06/14 03:51:04
下らん。もう一回言うね。

  >>397の研究内容を踏まえて、
  動的言語としてのRubyの言語仕様のうち、
  コンパイルしにくい要素って何なんだろうね。


444:デフォルトの名無しさん
05/06/14 03:57:46
>>443をスレ荒らしと判定。レス削除依頼を出します。

445:デフォルトの名無しさん
05/06/14 07:50:41
>>425をスレ荒らしと判定。レス削除依頼を出します。

446:デフォルトの名無しさん
05/06/14 07:59:05
うへ、プ板版のkouei35みたいなやつが居るな。
こういう奴がいると強制ID制度ほしくなるな。


447:デフォルトの名無しさん
05/06/14 10:36:44
>>434
件の論文は、中間コードへのコンパイルの事だと思うのだけど。Ruby-toLLVM compiler
こっちではネイティブコードへのコンパイルを想定してる様な雰囲気ですよね。

>>428
sRubyについて調べてみては?

448:デフォルトの名無しさん
05/06/14 10:54:58
なんだRubyの人って説明不足で揉めるような書き込みが大得意なんだな。
最初からLLVMって書いてあるのに。

449:デフォルトの名無しさん
05/06/14 11:02:24
>>447
> sRubyについて調べてみては?

えぇ~と、なんか前聞いた覚えあるんだけどこれかな?

URLリンク(thekode.net)
Robert Feldt, sRuby - A Ruby dialect for low-level programming

450:デフォルトの名無しさん
05/06/14 11:15:29
これだからRubyがからむと嫌なんだ・・・

451:デフォルトの名無しさん
05/06/14 11:51:46
中間コードへのコンパイルもネイティブコードへのコンパイルも
本質的に他言語への翻訳でしょ。

コンパイルの定義で揉めるというのは、
「インタプリタとスクリプトをくっつけて単体実行可能にしたもの」
を出力するのはコンパイルと言えるか否か、という話じゃないの?

>>450
まあでも、字句解析構文解析のかみ合わなくて不毛な話題よりは
今の方が面白いよ。

452:デフォルトの名無しさん
05/06/14 18:30:27
下らん。もう一回言うね。

  >>397の研究内容を踏まえて、
  動的言語としてのRubyの言語仕様のうち、
  コンパイルしにくい要素って何なんだろうね。


453:デフォルトの名無しさん
05/06/14 19:03:05
そんなに何度も繰り返すなら、
まずはコンパイルしにくくない要素のコンパイルをあなたが説明してね。


454:デフォルトの名無しさん
05/06/14 19:55:33
ここまでくると荒らしだな

455:デフォルトの名無しさん
05/06/14 20:22:40
>>450
lispもなw


456:デフォルトの名無しさん
05/06/14 21:15:48
Lisp で荒れる理由: アンチが厨だから
Ruby で荒れる理由: ユーザが厨だから

457:デフォルトの名無しさん
05/06/14 21:18:31
>Lisp で荒れる理由: アンチが厨だから

Lispユーザーが平気でこう言うあたりが、荒れる真の理由かねw

458:デフォルトの名無しさん
05/06/14 21:39:52
まあ日本のLisp人口の多数派は40前後のおっさんだからね。

459:デフォルトの名無しさん
05/06/14 21:45:03
Lispは40年前に生まれた言語だから、生まれた時から、Lispってる計算になる

460:デフォルトの名無しさん
05/06/14 21:46:43
>>458
こういう FUD を平気で言うあたりがアンチが厨だという証拠w

461:デフォルトの名無しさん
05/06/14 21:50:00
年齢が40前後がなんでFUDになるのだろう。

462:デフォルトの名無しさん
05/06/14 21:55:53
この公式はどうだろう
アンチLISP=Rubist

アンチRuby=LISPer

463:デフォルトの名無しさん
05/06/14 21:58:23
>>460は数少ない現役厨房Lisperか。大事にせにゃw

464:デフォルトの名無しさん
05/06/14 22:02:58
>>462
すなわち、こういう事のようだな(↓)

LISPシンパ≒Rubyシンパ


465:デフォルトの名無しさん
05/06/14 22:18:29
………………………… き り す て …………………………

466:デフォルトの名無しさん
05/06/14 22:20:02
lispもなw

たったこの一言が原因で、しつこく粘着して
しっかりと荒らすんだから、ある意味すごい

467:デフォルトの名無しさん
05/06/14 22:28:37
………………………… Reset …………………………

468:デフォルトの名無しさん
05/06/14 22:46:48
このスレでLispとRubyの話題は禁止ということで

469:デフォルトの名無しさん
05/06/14 22:55:05
………………………… >>468 を は つ げ ん き ん し …………………………

470:デフォルトの名無しさん
05/06/14 23:11:53
荒れてる原因はRubyでもLispでも信者でもアンチでもないと思うんだが…
単に話が理解できないバカが原因だろ?

471:デフォルトの名無しさん
05/06/14 23:11:57
3大禁句(↓)

Li(ry
Ru(ry
りん(ry


472:デフォルトの名無しさん
05/06/14 23:14:03
>>458
ってことは、煽りでなくて若者には人気がないってことですか?(LISP)
素朴な疑問としてなんでなんでしょうね?

(書籍が少ないから?)


473:デフォルトの名無しさん
05/06/14 23:15:10
>>470
はげどう

474:デフォルトの名無しさん
05/06/14 23:19:01
>>472
↓で同じ質問をして、身をもって知ってみてはどうか?
スレリンク(tech板)

しかし粘着がまだいるな

475:デフォルトの名無しさん
05/06/14 23:24:31
>>472
書籍って言語解説書のこと?
そんなもの必要なの??
要らないと思うなぁ。

476:デフォルトの名無しさん
05/06/14 23:27:03
>>472
Lispの黄金時代というのが太古の昔あっての。
汎用機屋以外は、猫も杓子もLisp Lisp、
Lispしか動かないマシンが続々と発売された。
普通の商売としてLispを使った経験のある人間がその世代なんじゃ。

477:デフォルトの名無しさん
05/06/14 23:31:32
ありえん。
数式処理屋、エキスパートシステム屋、AI屋、あと画像処理屋くらいなもんだろう
Lisp専用機使ってたのは

478:デフォルトの名無しさん
05/06/14 23:37:11
LISPのアンチというのがわからんな。
LISPの機能とかは他の言語で代用は無理だからなあ。
まあEmacsなかったらm4以下の存在だったかもしれない。

479:デフォルトの名無しさん
05/06/14 23:39:59
アンチを作りたくてしょうがなさそうな発言だね。

480:デフォルトの名無しさん
05/06/14 23:42:36
>>478のようなやつがなんでこのスレにいるんだ…あきらかに無縁だろ…

481:472
05/06/14 23:50:38
>>475
やはり本がないと(汗

>>477
専用器なんてあったんですか!
ある意味凄い。


482:デフォルトの名無しさん
05/06/14 23:56:08
シンボリ


483:デフォルトの名無しさん
05/06/15 00:02:03
>>477
「Lisp専用機」という存在自体が今の人間にとってはそれこそ「ありえん」だろう。
この黄金期も短かった。
最大の理由は、当時登場した万能太陽神に信仰を奪われたこと。
おまけの理由としては、一大国家施策としてヤンキーでなくおふらんすの言語を推進したこと。

今となっては>>478が言うように、エディタのおまけ言語としてしかLispをさわったことのない
人間のほうが多くなってしまった。

484:デフォルトの名無しさん
05/06/15 00:04:03
IPSJ>コンピュータ博物館>年表と日本の歴史的コンピュータ
 ワークステーション・Lispマシン
  URLリンク(www.ipsj.or.jp)
  URLリンク(www.ipsj.or.jp)

 1974:MIT:CONSマシン
 1974:Xerox PaloAlto:Altoワークステーション上にInterLispを移植
 1976:MIT AIラボ:CADRマシン
     →Symbolics、LMI(LISP Machine Inc.)社の商用Lispマシンの原型となった

 1979:神戸大:神戸大Lispマシン開発
  URLリンク(www.ipsj.or.jp)
 1982:大阪大:LispマシンEVLIS開発
  URLリンク(www.ipsj.or.jp)
 1983:電電公社:通研LISPマシンELIS試作機稼動
  URLリンク(www.ipsj.or.jp)
 1984:理研:数式処理計算機FLATS開発
  URLリンク(www.ipsj.or.jp)
 1984:富士通:Lispマシン FACOM α 発表
  URLリンク(www.ipsj.or.jp)

485:デフォルトの名無しさん
05/06/15 00:08:57
>483
フランス産はどれも優雅だねぇ。

486:デフォルトの名無しさん
05/06/15 00:29:25
フランスの言語って何?
OCaml は何やら汚らしい感じがするが

487:デフォルトの名無しさん
05/06/15 00:37:50
Prolog?Ada?

488:デフォルトの名無しさん
05/06/15 01:59:55
>>484
すげーな富士通までやってたのかw
当時どれだけ影響力あったかわかるな。

489:デフォルトの名無しさん
05/06/15 02:15:24
技術的系譜はこんな感じだそうです。(IPSJ情報)

 神戸大TAKITEC→富士通FACOM α(試作機)→理研FLATS(発案:故後藤英一先生, 設計協力:富士通, 製作:三井造船)→FLATS2
                              →富士通FACOM α(製品版)

 阪大EVLIS(並列処理)…→?

湯浅先生達の超並列機は、どういう技術的系譜にあるのだろう・・・?

490:489
05/06/15 02:29:29
訂正。FLATSは各種の高速化技法を導入したオリジナルですね。

・神戸大TAKITEC→富士通FACOM α(試作機)→富士通FACOM α(製品版)
            \NTT武蔵野通研 ELIS → NTT-IT ELIS-8100/VME/8200 (LSI開発協力:沖電気)

            ・理研FLATS(発案:故後藤英一先生, 設計協力:富士通, 製作:三井造船)
                              →後藤磁束量子情報プロジェクト FLATS2

・阪大EVLIS(並列処理)…→?


491:デフォルトの名無しさん
05/06/15 02:29:36
やっぱりこのスレでLISPとRubyの話は厳禁

492:デフォルトの名無しさん
05/06/15 02:31:33
………………………… >>491 は げ ん き ん …………………………

493:デフォルトの名無しさん
05/06/15 02:41:27
Lispは別に問題ないよ
Rubyが出てくると荒れてるだけ

494:デフォルトの名無しさん
05/06/15 02:51:33
>>493
これだけスレ違いのレスが続いて何が「Lispは別に問題ないよ」だよ

495:デフォルトの名無しさん
05/06/15 03:19:40
荒らしてる本人に自覚が無いだけだな

496:デフォルトの名無しさん
05/06/15 08:25:59
スレ違いなんだよ こっちでやれ
CommonLisp Scheme Part13
スレリンク(tech板)

497:デフォルトの名無しさん
05/06/15 13:18:50
スレが進んでるなぁ……


地面に置かれた砂糖に集まるアリみたい。
アリは嫌いだよ。急所噛まれた事あるから。

498:デフォルトの名無しさん
05/06/15 14:30:40
>コンパイルの定義で揉める巧妙な書き込みがなされているな
>なんだRubyの人って説明不足で揉めるような書き込みが大得意なんだな。

この内容で揉めたほうがマシだったな。現状よりは。

499:デフォルトの名無しさん
05/06/15 18:51:24
>>484
LISP専用マシンが何故必要とされたの?
今に例えると、例えば、 Ruby専用マシンみたいなものだよね?
全然考えられない!


500:デフォルトの名無しさん
05/06/15 19:15:09
頭悪すぎ

501:デフォルトの名無しさん
05/06/15 19:26:30
>>499
速いからだよ

502:デフォルトの名無しさん
05/06/15 20:16:45
>>499
特定の言語を効率よく実行できる専用マシンは、昔のようにハードのオマケでソフトが在った時代には普通だった
ちなみに、今の御時世では Java 専用マシンがあったりする

別に不思議じゃない

503:デフォルトの名無しさん
05/06/15 20:27:33
・当時、汎用機アーキテクチャの標準(IBM/360~370)は姿を現していたが、
 それ以外のアーキテクチャはまだまだ未発達もしくは未普及だった。
 当時の汎用機アーキテクチャでは必ずしも効率的に実行できない処理のために、
 科学技術計算専用マシンや特定言語専用マシンの研究が始まりつつあった。

・MITのMacプロジェクトでLispアプリケーションを蓄積したが、
 実行には高価な中~大型汎用機(ITS, GE Multics, DEC-10/20)が必要で、
 小回りが効かなかった。
 そこでPDP並みの価格で中~大型機並みの性能を持つ
 Lisp用パーソナル・ワークステーションが開発された。

504:デフォルトの名無しさん
05/06/15 22:11:57
>>499には時代という物が理解できないんだろうな。


505:デフォルトの名無しさん
05/06/15 22:22:50
>>499
>>500-504まで、誰もわかってないようだからわからないことを気に病むことはないよ。
同時代のおっさんにはあまりに自明のことなんだが、
わかったからといって何かの足しになるわけでもなし。
スレ違いだし、このへんでひっぱるのはやめよう。



506:デフォルトの名無しさん
05/06/15 22:34:42
最近見た中で一番ショボいハッタリだ

507:デフォルトの名無しさん
05/06/15 22:50:41
20代のLISP使いだけど
おっさんネタはさっぱりわからんなあ

昔のPC板ってのがあるから
いいかげん懐古ネタは他所でやんなさいよ

昔のPC
URLリンク(bubble3.2ch.net)

508:デフォルトの名無しさん
05/06/15 22:54:22
>>507
いやPCの話じゃないんだが…

と一応ツッコミは入れとくが、スレ違いということには同意

509:デフォルトの名無しさん
05/06/15 23:04:49
>>507
ちらっとその板みたが、自分からみたらちっとも昔ではないのですな。
すでにPC前提ってあたりで昔ではないのですよ。

荒らすつもりじゃ無く純粋に懐古趣味としての昔話かと思って期待がはずれたのです。


510:デフォルトの名無しさん
05/06/15 23:42:23
>>507
アホか。リアルタイムで知らない事でも、
文献やWebを駆使して勉強するもんだよ。
特にLispなんて80年代に最盛期を迎えた言語だからな

511:デフォルトの名無しさん
05/06/16 19:36:39
LISPの全盛期はいつだ? 80年代か? MLは今なんだよ…。

512:デフォルトの名無しさん
05/06/16 20:28:40
>>511
> MLは今なんだよ…。
いいえ。

513:デフォルトの名無しさん
05/06/16 21:22:31
80年代つーと洋楽だなあ

514:デフォルトの名無しさん
05/06/16 21:24:57
>>511
桜木君…

515:デフォルトの名無しさん
05/06/16 22:03:41
いいかげんにしろ、スレ違いだ。

516:デフォルトの名無しさん
05/06/16 23:46:50
そ /                  _r  、    、   .ヽ、 R
| L_   , - ´  ̄ ̄ ` ヽ 、   ',ヽー/_ヽーヽ/ヽイ _) u
な < /           ヽ,  /     λ       ヽ. b
の //    イ      ヽ   .i く  チ\イ_レヽ_/ルノヽ ) y
か \! !イ-/─レイ、ル─ヽ, / >i .レイ ,r=、   ,.-=ゝiイ  ヽ, y
| .| ̄i /イ,r=-、   ,-=ヽiミ}<] !レイレi { !_r!   i、_r! リ  ) 最
,、 / .レ| i { i、r!   i、_r!} ア   |   | !,""  ___ "" ! !  く. 高
 `   | i,""  ____  "" | | | .|  ! i ヽ、 !   j  ,イレ  > ! !
     i リヽ、 !   `j   ,イ !|  | |ノル `レ ,_--_イiレ - 、/ ̄ヽ、
     レi レ`レ ,--_イ レ、 リレ'    rイくi-/ / , ---ヽ、/__
人/ヽ、_    ,イくi--//__人__人_   ,く,_[><]__//_(⌒)-、i,_ ノ
はあ /  / i  (>Y<) ) 最R今 (   ,ヽi  '    (_ゝ_ヽ_ノノノ ´
はは i  / .!   `´  ). 高u 夜 (  ./ .!      ヽ、___ノ
はは > / イ、    ヽ, ! b も (  / <、_ 、     _ く
はは < /  ヽr----─> ! y  ( / /  /      ヽ\

517:516
05/06/17 00:33:33
誤爆しました

518:俺の学生時代はi386でGoferかな
05/06/17 00:36:23
>>516
さっさと氏ねよ

>>511-512
定理証明系の開発は70年代
SML/NJの開発は80年代半ば
その後87~98がHaskell標準化・・・もしかして進歩止まってるやん

519:デフォルトの名無しさん
05/06/17 00:39:16
>>518
スレ違いのお前もな

520:デフォルトの名無しさん
05/06/17 00:42:57
>>519 はぁ?煽りやり過ぎて、話題がスレ違いかどうか判断もできなくなってるのか。

521:デフォルトの名無しさん
05/06/17 00:44:16
>>520
どこからどう見てもスレ違い

522:デフォルトの名無しさん
05/06/17 00:45:07
キチガイが粘着中

                まともな人はしばらくお待ち下さい

523:デフォルトの名無しさん
05/06/17 00:47:39
やっぱりこのスレでLISPとRubyの話は厳禁だな

524:デフォルトの名無しさん
05/06/17 03:45:37
MLじゃないの?

525:デフォルトの名無しさん
05/06/17 20:09:56
>>523
ではmallocとfreeについて話そう。

526:デフォルトの名無しさん
05/06/17 20:11:36
>>525
やっぱこのスレではコンパイラについて話さないとな

527:デフォルトの名無しさん
05/06/17 21:22:29
lambda liftingについて分り易く教えてください

528:デフォルトの名無しさん
05/06/19 04:50:11
荒らしがいなくなるとスレが止まるんだなぁ。
つかLispもMLも禁止の言語処理系スレって…。

>>526
コンパイラの定義を教えてくれ。

>>527
URLリンク(foldoc.doc.ic.ac.uk)

529:デフォルトの名無しさん
05/06/19 09:55:44
LALR(1) を勉強するのにお勧めの書籍かサイトありましたら
教えて下さい。


530:デフォルトの名無しさん
05/06/19 11:02:50
・コンパイラの構成と最適化 中田 育男
 URLリンク(www.amazon.co.jp)


531:デフォルトの名無しさん
05/06/19 15:27:01
>>528
よくわからない
変数が増えただけに見えるorz
引数渡しにするってことかな?

532:デフォルトの名無しさん
05/06/19 16:10:29
だいたいLispやMLの全盛期の話のどこがスレの趣旨に沿ってるんだよ?
そんな話はLispやMLのスレでやれよ

533:デフォルトの名無しさん
05/06/19 16:52:39
>>531
処理系を作る立場で考えてみると良いんじゃないかな。

534:デフォルトの名無しさん
05/06/19 18:01:40
>>530
それって最適化でしょ?メインは


535:デフォルトの名無しさん
05/06/19 19:57:38
>>529
Dragon Bookでいいんじゃないの。


536:デフォルトの名無しさん
05/06/19 20:34:44
>>530
良書には違いないが、LALRつーわけどもないだろ。


537:デフォルトの名無しさん
05/06/19 20:56:36
>つーわけどもないだろ。


538:デフォルトの名無しさん
05/06/19 21:05:16
>>536をparseするのにお勧めの書籍かサイトありましたら
教えて下さい。



539:デフォルトの名無しさん
05/06/19 21:08:06
>>538
・コンパイラの構成と最適化 中田 育男
 URLリンク(www.amazon.co.jp)

540:デフォルトの名無しさん
05/06/19 21:13:07
>>538
Dragon Bookでいいんじゃないの。

541:536
05/06/19 22:33:02
スマソ、「つー訳でもないだろ」の誤りorz


542:デフォルトの名無しさん
05/06/20 00:02:19
>>536
> LALRつーわけでもないだろ。

 ?
 コンパイラ本の一つも読まずにアフォレス、とても痛い小学生だな


543:デフォルトの名無しさん
05/06/20 07:23:45
>>541を意味解析するのにお勧めの書籍かサイトありましたら
教えて下さい。


LALRの良書っていうわけでも無いだろ
ってことか?
じゃあ>>541がLALRの良書を薦めてくれ。

544:デフォルトの名無しさん
05/06/20 17:15:35
そもLALR一つに絞った本が良書と言えるのか?

545:デフォルトの名無しさん
05/06/20 19:51:09
>>544
それってyaccの入門書のレベルな希ガス

546:デフォルトの名無しさん
05/06/20 21:58:07
>>545
いや、案外その手の本は扱ってない。


547:デフォルトの名無しさん
05/06/20 22:17:16
はぁ?
LALRわかんなきゃyacc/bisonは使えないじゃん

548:デフォルトの名無しさん
05/06/20 22:28:32
>>547
理屈ではそうだけど、実際はそうじゃないんだよ。


549:デフォルトの名無しさん
05/06/21 01:20:40
全然自慢にならねぇ主張だな。
わけわかんないけど使ってるって?へ

550:デフォルトの名無しさん
05/06/21 01:31:52
紳士的に解釈すれば、ツールの使い方がわかれば
LALRアルゴリズムの詳細なんて知らなくても良い
ということじゃないかなあ。
いや、ある程度は知ってないとまずいかな。
yaccの作成するテーブルがどういう理屈で作成されてるかぐらいは・・

551:デフォルトの名無しさん
05/06/21 01:33:23
いやちゃう。
単にyaccが吐いたコードにアクション追加したり文法をデバッグするのが無理

552:デフォルトの名無しさん
05/06/21 04:07:32
>>550
どうだろう?yaccって結構簡単に使えるけど、それとLALRの理解は別だと思う。
極端な話し、関数電卓ぐらいのパーサならLALRの知識なんて必要ないし。

ちがうかな?


553:デフォルトの名無しさん
05/06/21 04:29:04
それで結局、今出てるyacc/lex本のLALRの解説は充実してるのか?

554:デフォルトの名無しさん
05/06/21 09:30:36
何するつもりか知らないけど、
LALRだけ勉強しようというのは効率が悪いから
普通の文法解析の教科書では一通りの文法を説明している。

・再帰下降パーサで書ける文法
・LALRパーサじゃないと書きにくい文法
・その他、演算子順位文法、属性文法
とか知っておくと、扱いたい文法が上記のいずれに近いのか、
素早くもしくは効率的に実装するには、どうすれば良いか
判断できるようになると思う。


555:デフォルトの名無しさん
05/06/21 11:58:26
[課題Q]3角形の底辺の長さ,高さをキーボードから読込み,その面積を計算するプログラムを作成しなさい.
ただし,底辺の長さ,高さ,面積の値を入れる変数名をそれぞれteihen, takasa,mensekiとし,いずれも実数型(double型)とする.


void main( void )
{
double teihen, takasa, menseki;

printf( "底辺は?\n" ); /* 入力を促すメッセージを表示 */
scanf( "%d", &teihen );

menseki = teihen * takasa / 2;
printf("%f\n",menseki);
}

これ誰か完成させてくれ

556:デフォルトの名無しさん
05/06/21 12:28:11
>>555=スレ違いのキチガイ

557:デフォルトの名無しさん
05/06/21 13:09:35
次スレから「相談室」ってのを外そうよ。
この文字だけ見て書き込んでいるとしか思えない致傷多すぎる。


558:デフォルトの名無しさん
05/06/21 13:24:09
>>555は単なる構ってチャンだろ。キチガイはさっさと逝け

559:デフォルトの名無しさん
05/06/21 21:03:15
標準入力から直接入力すると、行末の改行が削れてしまうんですが、
それを考慮すると行番号の計測ってどうやるんでしょうか

560:デフォルトの名無しさん
05/06/21 21:13:37
>>559 スレ違い。初心者向け相談室へ逝け

561:デフォルトの名無しさん
05/06/21 23:43:16
LALRの話しもすれ違い???


562:デフォルトの名無しさん
05/06/22 01:15:48
構文解析の話なんてつまらんだろ

563:デフォルトの名無しさん
05/06/22 01:24:54
おれはおもしろいと思うよ。
むしろ他人の作った完成品を貶したり褒めたりするのはよそでやってほしい。

564:デフォルトの名無しさん
05/06/22 04:10:23
文法なんて結局は宗教戦争みたいなもんじゃん。
他人の作った完成品の工夫を見て学ぶのもおもしろいよ。
つか、このスレはいつまでたっても構文解析か荒らしの話しかしてないし…。

565:デフォルトの名無しさん
05/06/22 13:00:54
字句解析・構文解析 ⇒ つまらん。話したくない
意味解析・目的コード生成 ⇒ 各々の機械語スレへどうぞ
各種言語に依存した…… ⇒ 厨は引っ込め


このスレは、何について話すスレなんだ?

566:デフォルトの名無しさん
05/06/22 13:20:55
>>565
実装レベルの話はどうでもいい。

567:デフォルトの名無しさん
05/06/22 13:21:16
>>565
というか厨はお前だろ。

568:デフォルトの名無しさん
05/06/22 16:42:34
>>565
うーん、そこで「他でヤレ」っつってるのは、
単なる荒らしだと思うよ。相手にする必要なし。

つか荒らし被害者のフリして荒らすなって(笑

569:デフォルトの名無しさん
05/06/22 18:08:49
>>1
> 字句解析・構文解析から,データフロー解析,ループ並列化,タスク並列化,SSA変換,
> CPS変換,レジスタ割付,命令スケジューリング,ソフトウェアパイプライン等各種最適化,
> それにVM,GC,JIT,リンク時最適化,動的バイナリ変換などなど。
> 意味論に関する話題も歓迎です。

字句解析・構文解析以外にも沢山話題はあるじゃない。

570:デフォルトの名無しさん
05/06/22 18:12:09
じゃとりあえず話題をどうぞ(マジ

最近、プログラミング言語系の開発とかやってないなぁ~(遠い目


571:デフォルトの名無しさん
05/06/22 18:17:23
んじゃ制御フローの話題でも。
最近は制御フロー解析はstructuralな手法に移りつつあるようだけど、reducibleでないループ
はどうしてる? そこだけ古典的な方法でやってる?

572:デフォルトの名無しさん
05/06/22 18:20:19
質問するときは、まず相手を探し、次に質問を選ばなきゃ。
>>570に書いたとおり、俺はスルー

573:572
05/06/22 18:23:37
つか俺、ドラゴンブックの和訳出る手前で
コンパイラーに関する体系的な勉強が止まってる。
ドラゴンブックに型変数の話がちょこっとしか載ってなくて、興味が萎えたんだよなぁ。


574:デフォルトの名無しさん
05/06/22 18:33:58
subset型が欲しいなと思うときはある。
y : { x in Int | P(x)}みたいな感じで。
ただしimpredicativeなものは勘弁。

575:デフォルトの名無しさん
05/06/22 18:34:32
Matz召還して議論したらどぉーお?

576:デフォルトの名無しさん
05/06/22 18:52:50
>>574
Pascalの範囲型みたいな話だね。
構文上の判りやすさはさておいて、
そーゆーのはObject指向で解決できるのでわ?
(constractorや各種演算子で範囲型を外れないようにチェックして、
 もし外れたら例外発生、とか)

577:デフォルトの名無しさん
05/06/22 18:55:32
オブジェクト指向と型は何の関係もない

578:デフォルトの名無しさん
05/06/22 19:10:02
オブジェクト指向のクラスを型とみなす事「も」できる。
通常のOOプログラミングでは、型とクラスの相違は曖昧にされる事が多い。
理論では識別したがるみたいだけどw

579:デフォルトの名無しさん
05/06/22 19:12:12
なんで区別したがるんだっけ?
何度か読んだ覚えがあるけどど忘れした

580:デフォルトの名無しさん
05/06/22 20:13:18
俺も教えて欲しい

581:デフォルトの名無しさん
05/06/22 20:31:22
Haskellなんか、クラスと型は別もんだけど
そういう意味じゃないの?

582:デフォルトの名無しさん
05/06/22 20:32:48
クラスがあるのに静的型が無い言語とか、そもそもクラスが無い言語とかもあることから来たのでは?

583:デフォルトの名無しさん
05/06/22 21:06:03
言語処理系に関する研究の進展によって、
それまで言語処理系の内部機構だったものが、
言語ユーザに安全かつ判りやすい形で開放される事がある。
・・・メモリー・アロケーション然り、ユーザ定義型しかり。型変数、型推論も。

Lispとか、OOとか、そーゆー「開放」を前倒しした形で試すには、
良いプラットフォームなのでわ?と

584:デフォルトの名無しさん
05/06/22 21:11:57
>>583
日本語でお願いします

585:583じゃないが
05/06/22 21:15:44
言語として本格的に実装する前の実験段階の実装には、LISP や OO を使うと良いのではないか?


って読んだ

586:デフォルトの名無しさん
05/06/22 21:21:16
お前の日本語力、理解力が低いのは、よく判った。

これまでの言語処理系発展の歴史の中で、
それまで言語処理系内部の仕組みとしてユーザの立ち入りを禁止していた機構
  例えば:メモリーの動的アロケーション、型の追加定義、型を推測する仕組み
が、簡潔かつ安全な形でユーザに開放されてきた。

・Lispのように高階関数で言語の実行機構を弄る事ができる言語、
・オブジェクト指向言語のように、データと操作をカプセル化して新しい型を定義しやすい言語、
は、上記のような「新しい機構のユーザへの開放」を実験するのに適しているのではないか?

                                                       以上


587:583=586
05/06/22 21:22:41
>>585
介錯かたじけないっす。
>>586>>584宛ての熱いラブレターでつ・・・

588:583じゃないが
05/06/22 21:25:17
読みにくいです

589:デフォルトの名無しさん
05/06/22 21:28:39
はい。反省。
さっき翻訳の真似事で下訳してたから、
むちゃくちゃな語順の日本語をしゃべってるかもしれない・・・

590:デフォルトの名無しさん
05/06/23 00:07:11
>>586
アフォ


591:デフォルトの名無しさん
05/06/23 00:11:25
哀れな奴

592:デフォルトの名無しさん
05/06/23 02:12:10
字句解析はできる
コンパイルも通って実行もできる
でも実行した結果は意味不明

そんな感じの文章

593:デフォルトの名無しさん
05/06/23 04:16:57
重箱の隅つつくだけ

594:デフォルトの名無しさん
05/06/24 04:24:43
>>553
O'Reilly の Lex & Yacc には少なくても無い。
用語の説明コーナーに出ているだけ


595:デフォルトの名無しさん
05/06/24 22:01:28
bison でのエラーメッセージの出し方で質問です。

スクリプト言語を作ろうとしてて
入力にエラーがあったときに詳細なエラーメッセージを出したいんですが
どのようにしたらいいでしょうか?

例えば
if x != 0 {
^
'(' expected.
とか出したいんですが、そもそも「if文の途中」というのが
取れるんでしょうか?

また、現在注目しているトークンの値(yylexからの戻り値)
はどこかに格納されてるでしょうか?


596:デフォルトの名無しさん
05/06/24 22:08:57
まあ>>595くらいのレベルがこのスレにちょうどあってる気がする

597:デフォルトの名無しさん
05/06/24 23:12:59
見てると、LispとRuby、両方ともアンチが厨なだけに見える。
厨だから、ちょっとこの二つが出てくるとすぐ暴れだして
荒れる。

598:デフォルトの名無しさん
05/06/24 23:18:57
>>597
わかってないな。
何かを貶す時の基本は度外れに褒めまくること。
そうすれば>>597のようなアホがほいほいつられてくれる。

599:デフォルトの名無しさん
05/06/25 00:32:42
>>595
lexerはどうしてるの?
Lex等を使わずに自分で書いたのなら、どこまで処理してるかは把握してるのでは?

lookahead tokenの値は変数yycharにおさめられてます。


600:デフォルトの名無しさん
05/06/25 01:21:33
>>595 bisonのオプション
#define YYERROR_VERBOSE 1 /* Enable verbose error messages. */
マニュアルにも出てるはず

> そもそも「if文の途中」というのが
> 取れるんでしょうか?
bison の error を使えば if文の途中でパース失敗した
ときのアクションとか付けられる
なんか説明しづらいけどマニュアルのサンプルに出てそう

601:デフォルトの名無しさん
05/06/25 09:59:34
>>595
すれ違い。

Lisperより


602:595
05/06/25 10:03:24
みなさんありがとうございます。これから試してみようと思います。

>599
flexを使ってます。bison側で「@x」と書けば、トークンの位置が取れると
URLリンク(www1.kcn.ne.jp)
に書いてあったんですがまだ試してません。yycharですか、ありがとうございます。

>600
YYERROR_VERBOSE は試してみました。多少わかりやすいエラーメッセージが
yyerrorに与えられるようになったんですが、自動生成じゃなく自分でエラーメッセージを
決めたいんです(Cコンパイラが出すような)。

error は今のところトップレベルでやっちゃってるんで、
そこを文それぞれにもってかないとだめなんですね。


603:デフォルトの名無しさん
05/06/25 12:44:21
>>601
死ね。


604:デフォルトの名無しさん
05/06/25 19:51:54
>>601 ってなにもの?
Lisp 屋からみてもはずかすぃんだけど...


605:デフォルトの名無しさん
05/06/25 22:03:06
>>604
おまぃLisp屋を騙ってる素人だろ。
Lispはプログラムとしていきなり構文木書かせるから、
文法パーサ(yacc, bison, Rie)はイラネェ~んだよ

だから、「コンパイラ/スクリプトの話題に文法パーサはイラネェ」
プログラミングに精通してる人向けのジョークなんじゃねぇ?
;; あ、素人の人には判らない話だから、
;; そこの人、ムキになって否定しないように・・・



606:デフォルトの名無しさん
05/06/25 22:06:14
よく分からんが、>>605 が素人だということはよく分かった

607:デフォルトの名無しさん
05/06/25 22:15:28
はいはい、わかったわかった(苦笑

608:デフォルトの名無しさん
05/06/25 22:16:27
まあ、大体はあってるんじゃないか。
全くいらないってわけじゃないが、他と比べて
簡単であることは間違いない。

609:デフォルトの名無しさん
05/06/25 22:19:30
文法パーサ・ジェネレータは 使わない。
S式に関する文法は      ある。

妙に関心してるのも出てくる始末(苦笑
素人相手にジョーク飛ばすのも大変だなぁ。


610:デフォルトの名無しさん
05/06/25 22:22:26
なるほど。
>>605 みたいにスーパーな Lisp 屋ならば、
SICP の超循環評価器なんてイラネェ~んだろうな。


611:デフォルトの名無しさん
05/06/25 22:42:27
>>609
なんだ、お前は「文法パーサ」って言葉でツールの類を指してたのか。

612:デフォルトの名無しさん
05/06/25 22:49:41
601でギャグを言ったつもりだったっぽいなw

613:デフォルトの名無しさん
05/06/25 22:50:45
yacc の検索結果のうち 日本語のページ 約 17,600 件中 1 - 10 件目 (0.15 秒)

構文解析器 の検索結果のうち 日本語のページ 約 10,200 件中 1 - 10 件目 (0.23 秒)

パーサ の検索結果のうち 日本語のページ 約 53,700 件中 1 - 10 件目 (0.19 秒)

パーザ の検索結果のうち 日本語のページ 約 8,720 件中 1 - 10 件目 (0.04 秒)


文法パーサ の検索結果のうち 日本語のページ 約 24 件中 1 - 5 件目 (0.22 秒)


614:デフォルトの名無しさん
05/06/25 22:58:59
久しぶりにに揚足鶏取れたんで、大喜びか。
下らない人間だ


615:デフォルトの名無しさん
05/06/25 23:00:52
「LALR文法パーサ」=構文パーサの一種

バカは覚えときな。

616:デフォルトの名無しさん
05/06/25 23:06:07
LALR文法パーサに該当するページが見つかりませんでした。

検索のヒント
- キーワードに誤字・脱字がないか確かめてください。
- 違うキーワードを使ってみてください。
- より一般的な言葉を使ってみてください。
- キーワードの数を少なくしてみてください。


617:デフォルトの名無しさん
05/06/25 23:13:04
荒らすなよ

618:デフォルトの名無しさん
05/06/25 23:14:09
Googleで検索できない単語は間違っていると信じている、
痛い素人が粘着しているな。哀れな奴

619:デフォルトの名無しさん
05/06/25 23:27:41
以前、LALR(1)の書籍orサイトを尋ねたものですが、
なかなかLALRのみっていうのは無いんですね。

ところで、皆さんはどうやって学習されましたか?
学習されたときの書籍とか覚えていましたら、教えて下さい。


620:デフォルトの名無しさん
05/06/26 00:25:28
>>604
おまぃLisp屋を騙ってる素人だろ。
Lispはプログラムとしていきなり構文木書かせるから、
文法パーサ(yacc, bison, Rie)はイラネェ~んだよ

だから、「コンパイラ/スクリプトの話題に文法パーサはイラネェ」
プログラミングに精通してる人向けのジョークなんじゃねぇ?
;; あ、素人の人には判らない話だから、
;; そこの人、ムキになって否定しないように・・・


621:デフォルトの名無しさん
05/06/26 00:31:50
>>620 が素人なのはよくわかった。


622:デフォルトの名無しさん
05/06/26 00:32:51
はいはい、わかったわかった(苦笑


623:デフォルトの名無しさん
05/06/26 00:34:45
別に文法パーサって言葉自体はいいだろ。
ただし、yaccなどのジェネレータを「文法パーサ」と言ってしまってるから
誤解を生むってこと。
なお、googleで検索してる奴はほっとけ。

624:デフォルトの名無しさん
05/06/26 00:36:46
URLリンク(en.wikipedia.org)

625:デフォルトの名無しさん
05/06/26 00:38:46
>>624
で?w

626:デフォルトの名無しさん
05/06/26 00:42:29
いいですか~

yaccはパーサではありません。
yaccはパーサを作ってくれるものです。

はい、ここ!試験に出ますよ~
良い子は覚えておきましょうねぇ~

627:デフォルトの名無しさん
05/06/26 01:14:56
>>626
foo.yを解釈するパーサと言えなくもないけどな

628:デフォルトの名無しさん
05/06/26 01:41:04
俺の頭はパッパラパーさ(parser)!

629:デフォルトの名無しさん
05/06/26 02:09:28
>>619
旧DragonBook。
あれを読んでたのは大学のころだな。みんなで輪講して、手でLR(0)itemを列
挙して、lookaheadを求めて、表を作成して…とかやった覚えがある。

ところで、LRパーサーの生成方法を知りたいの?
それともyaccの使い方を知りたいの?
前者だったらやっぱりDragonBookを熟読。読んでるだけでは意味不明でも、
簡単な文法(足し算だけの電卓プログラムとか)のLR表を手で生成して
みるとわかってくるよ。

後者ならO'Reilly本で足りるでしょう。


630:デフォルトの名無しさん
05/06/26 05:31:33
>>627
yacc全体をそうは言えない。パース以外の仕事もするから。

631:デフォルトの名無しさん
05/06/26 10:31:04
「パーサ=構文解析器」だから「文法パーサ」って馬から落馬系じゃなければ
*.yなどの文法をパースするパーサのこと。
609の「文法パーサ・ジェネレータ」は「コンパイラ・コンパイラ・コンパイラ」って意味だな。

632:デフォルトの名無しさん
05/06/26 14:18:10
yaccは内部にパーサを持ってはいるんだろうけど、
lispはパーサが要らないんだ!って文章を強引に正しくするために
それを持ち出すのは苦しすぎる。

633:デフォルトの名無しさん
05/06/26 14:21:07
yaccは、*.yをパースしたあと、その情報を使って
新たなパーサを作り出すツールであって、
ただ仕事の過程でパーサを使ってるだけ。
だから、yacc=パーサとは普通いわないし、誤解を生むだけ。
間違ってるといえるかもしれない。


634:デフォルトの名無しさん
05/06/26 21:28:17
yaccはパーサージェネレーターだろ

635:デフォルトの名無しさん
05/06/26 21:30:42
lisp にはパーサは要らないって言っているけど、
「んじゃパーサ無しでどうやってS式をパースするんだい」 って話になるんだけどどうしよう

636:デフォルトの名無しさん
05/06/26 21:31:30
>>629
ちょっと横レスすまんが、

> 旧DragonBook。

って何?新ドラゴンってあるの?
それとも21世紀本のこと?

> 後者ならO'Reilly本で足りるでしょう。

どうだろうね。俺もその本持ってるけど、
あんまり役に立つとは思えないんだけど。


637:デフォルトの名無しさん
05/06/26 23:05:19
相変わらず変なのが粘着してるスレだな。

638:デフォルトの名無しさん
05/06/27 00:20:14
>>636
初版は1977年、もう絶版だから今の若い人は知らんか。

Principles of Compiler Design
Alfred V. Aho, Jeffrey D. Ullman
Addison Wesley
ISBN 0-201-00022-9

Amazonにも画像が無かったが、ぐぐってみたら
URLリンク(www-users.cs.york.ac.uk)
の上から二番目にあるな。



639:デフォルトの名無しさん
05/06/27 04:44:46
ああ。その本なら随分前に培風館から出ていたな、Winston Lisp第一版と同じシリーズで

640:636
05/06/27 21:02:19
>>629
失礼いたしやした。
大変参考になりやした。

m(_ _)m


641:デフォルトの名無しさん
05/06/28 21:23:10
素人です。

相乗り質問で恐縮ですが、LALR(1) の1って先読みトークンの数ですよね?
このことは、YACCにシフトされているシンボルの数の最大値が1ということにはつながらないのですか?



642:デフォルトの名無しさん
05/06/28 21:26:35
素人です。

>>641
知りません。

643:デフォルトの名無しさん
05/06/28 21:27:41
っていうかマジレスすると

>YACCにシフトされているシンボルの数の最大値が1

は合っているんだっけ?

644:デフォルトの名無しさん
05/06/28 22:19:16
ヒロシです。
分からんとです。


645:デフォルトの名無しさん
05/06/29 00:10:28
>>641
そうです。
LR(k)、LL(k)のkは、高々k個の先読みでパースできる文法(のクラス)を表しています。


646:619
05/06/29 06:55:18
>>629

> 旧DragonBook。
> あれを読んでたのは大学のころだな。みんなで輪講して、手でLR(0)itemを列
> 挙して、lookaheadを求めて、表を作成して…とかやった覚えがある。

情報ありがとうございます。
でも、もう手に入らないんですね。

> ところで、LRパーサーの生成方法を知りたいの?
> それともyaccの使い方を知りたいの?
|
> 後者ならO'Reilly本で足りるでしょう。

パーサー自体の生成方法までは、とても考えが及びません。

目的としては、後者です。だとすると、
やはり、O'Reillyの本が定番なんですかね。

入手して、若い頃のようにじっくり勉強してみたいと思います。 (^^;
ありがとうございました。


647:デフォルトの名無しさん
05/06/29 07:47:49
>>646
O'ReillyってLALRの説明まではしてなかったような。
とりあえず使いたいならO'Reillyでいいけど、
yaccを使いこなしたいなら、LALRをきちんと勉強したほうがいい。
コンフリクトしたらシフト優先とか、
自分で変な書式の式を追加するときに、%left とかがどう動くのかとかは
LALRを知らないと理解できない。

648:デフォルトの名無しさん
05/06/29 08:05:26
>>641
LALR(n)だと、
「シフトするトークンは1つだけど、n個先読みしてからシフトするか還元するか決める」
という考え方と
「最大n個シフトしてみて、ダメだったらシフトしなかったことにして還元する」
という考え方ができそう。

649:デフォルトの名無しさん
05/06/29 12:40:16
LALR(k): k-token LookAhead, Left-to-right parse, Rightmost-derivation,
LL(1):   Left-to-right and Left-most Parsing

650:デフォルトの名無しさん
05/07/01 21:58:05
>>647
で、貴方のお勧めは?


651:デフォルトの名無しさん
05/07/02 21:06:34
りん(ry


652:デフォルトの名無しさん
05/07/02 21:52:02
…………… く ず れ す ……………

653:デフォルトの名無しさん
05/07/04 19:03:27
>>652
恐らく lisper w


654:デフォルトの名無しさん
05/07/04 20:28:29
↑間違いなくアンチLISPer w

655:デフォルトの名無しさん
05/07/04 21:55:27
…………… き ち が い ね ん ち ぁ く ち う 。 よ う ち ゅ う い ……………

656:デフォルトの名無しさん
05/07/05 00:54:08
>>655
お前が一番の粘着だw


657:デフォルトの名無しさん
05/07/06 21:55:12
VC++でlexファイル(lex.yy.c)をコンパイルすることはできますか?
Windows版のflexとbisonは見つけたんですが、よく考えたら
gccで-ll(flexなら-lfl)オプションを付けないとコンパイルすることができない・・・

そもそも、gccがlflで何を取り込んでいるのかがわからず。
windowsでflex&bisonを使っているひとがいれば、教えていただけないでしょうか。

658:デフォルトの名無しさん
05/07/06 21:58:34
>>657
lfl は付けなくても平気。中に入っているのは確か main 関数だけだった筈だから

659:デフォルトの名無しさん
05/07/07 12:19:19
>>657 >>658

yywrap()も入ってるよ。
以下の関数定義をどっかに入れれば大丈夫。

int yywrap(void)
{
return 1;
}


660:デフォルトの名無しさん
05/07/09 18:00:12
PHPやPerlでは、変数を $var のように表します。
「$」と「var」のあいだにはスペースを入れることができません。
ということは、字句解析でトークンに分解するときに、「$」と「var」の2つに分解するのではなく、
「$var」というひとつのトークンとして認識しているのでしょうか。
(字句解析が「$」と「var」の2つに分解すると、間にスペースを入れられると思うから。)

「$var」を認識するのに、字句解析で1つのトークンとして認識するのがいいのか、それとも
2つに分解して構文解析時に「$var」であると認識するのがいいのか、迷ってます。

661:デフォルトの名無しさん
05/07/09 18:26:38
>>660
1トークンでいいと思うが。2トークンにするメリットが特に見当たらんし。

662:デフォルトの名無しさん
05/07/09 20:03:51
1トークンと考える方が不自然。
2トークンでしょう。(Perl/PHPのソース確認してないけど)

理由:
1. Perlの場合、変数名の前に異なるプリフィクスを使う場合がある。
   例)配列宣言    @array、 配列参照    $array[index]
     連想配列宣言 %assoc、連想配列参照 $assoc{key}
 左側(配列コンテキスト)と、右側(スカラーコンテキスト)を、異なるトークンと認識したら、
 変数名管理上、トークンからプリフィクス(@, %, $)を外した名前を切り出す必要があり、
 トークンの扱いとして不自然。

2.プリフィクス(@, %, $)と、識別子(var, array, assoc)の間に空白を許すか否かは、
 単なる構文定義上の問題であり、2トークンで空白を許さない定義が可能。

                                                   いじょ

663:デフォルトの名無しさん
05/07/09 20:23:45
PHPに@や%ないじゃん

664:660
05/07/09 20:27:10
>>661
ありがとうございます。そんな気はするんですが、いまいち確信がなくて。

>>662
1.の場合でも、プリフィックスと変数名は別々に渡しませんか?
今はトークンを取得する関数gettoken()と、文字列を取得する関数getvalue()を用意していて、次のようにしています。
入力   gettoken()     getvalue()
------------------------------
'foo'   STRING      "foo"
100   INTEGER     "100"
3.14   DOUBLE     "3.14"
x     NAME       "x"
$var   VAR_SCALAR  "var"
@var   VAR_ARRAY  "var"
%var   VAR_ASSOC  "var"

(最後の2つはつけくわえてみました。)
特に不自然ではないと思うのですが、どうでしょう。自信もないですが。

2. について、「2トークンで空白を許さない」ためのうまい方法がよくわかりません。
よろしければ教えてください。

665:デフォルトの名無しさん
05/07/09 20:34:41
空白もトークンとして切り出せ

666:デフォルトの名無しさん
05/07/09 21:59:11
>>665
空白をトークンにするぐらいなら、プリフィクス込みでトークン切り出して、
プリフィクスを取り除いたシンボル名でシンボルテーブル検索した方が
楽だと思うけどなぁ。

まぁ、どっちでも動けば構わんので、あとは趣味の問題だが。

667:デフォルトの名無しさん
05/07/09 22:27:32
>>663
PHPにも
$hoge = 1;
$varname = "hoge";
echo $$varname; // => 1

とかあるけどな!


668:デフォルトの名無しさん
05/07/09 23:13:32
Perlで$$は、ポインターの値参照だったっけ

669:デフォルトの名無しさん
05/07/09 23:38:16
ああ、そうか。

Perl5 だと参照使えるから ${$foo->{'a'}} なんてのもアリなんだな。それだと
確かに字句解析レベルではプリフィクスとシンボル名を分けた方が無難だ。

670:デフォルトの名無しさん
05/07/10 00:40:01
>>665
ええっー、空白をトークンとするんですか。
構文解析がかなり面倒になるんですけど。

>>669
「$」のあとに英数字が続けば変数名、それ以外なら「$」であるというのじゃだめでしょうか。

671:デフォルトの名無しさん
05/07/10 00:44:50
>>664
了解。1トークンで充分だと思う。

Perlの

672:671
05/07/10 00:46:02
>>664
了解。1トークンで充分だと思う。

Perlの $って、Cのポインタ演算子みたいな扱いするから、誤解した。

673:デフォルトの名無しさん
05/07/10 00:47:00
>>670
そもそも「Perl5 のようなスカラー・配列・ハッシュ、さらにその参照を任意に
組み合わせてデータ構造を作れるような言語にするのか?」ってトコロから
考える必要があるかと。

単に $foo, @foo, %foo, $$foo ぐらいで済む程度の文法なら 670 の案や
1トークン方式で良し。Perl5 フルコンパチにしたければ変数関係だけで
{}, [] の のネストが発生するので、ネストは正規言語では処理できない
ことを考えると、ある程度は構文解析に逃がした方が楽そう。

674:デフォルトの名無しさん
05/07/10 21:13:41
いずれにせよ、スレ違い
Li(ry)


675:デフォルトの名無しさん
05/07/10 21:17:02
LISPなら字句解析も構文解析も要らないのに。

676:デフォルトの名無しさん
05/07/10 21:24:23
すまん。素でわかんないんだが、「LISP は字句解析が要らない」ってのは
    1.0
ってのが出てきたとき、それがシンボルか数値かリストかどうかを判断しなくても良いってことなのか?

あと、「LISP は構文解析が要らない」ってのは、カッコの対応が取れて無くても気にしないってことなのか?

677:デフォルトの名無しさん
05/07/10 21:27:15
>>675-676 ネタ決定

678:デフォルトの名無しさん
05/07/10 21:56:58
字句解析がいらない
→入力をreadするとS式が出てくる

構文解析がいらない
→S式をevalすると結果が出てくる

679:デフォルトの名無しさん
05/07/10 22:00:33
それは要らないんじゃなくて、組み込みになってるだけじゃないの
自分で一から作るなら、どっちも必要でしょ

680:デフォルトの名無しさん
05/07/10 22:15:01
自分で一から作るつもりならLISP必要ないよ

681:676
05/07/10 22:25:03
なんかよく分かった。そりゃ必要ないよな LISP 側で全部用意してもらえてるんだし

682:デフォルトの名無しさん
05/07/10 22:32:57
あえてLISPを使う意味は中間形式としてS式で処理できるからじゃないかと
S式に優位性を感じないなら必要ない

683:デフォルトの名無しさん
05/07/10 22:34:15
昔prologスレで見た流れだ。
prologインタプリタをprologで書ける人とCで書ける人ではどちらが優れているか?

684:デフォルトの名無しさん
05/07/10 22:44:38
>>678
つまんねぇネタ。

685:デフォルトの名無しさん
05/07/11 01:56:10
ネタに見えるのか。

686:デフォルトの名無しさん
05/07/11 03:28:22
>>685
お前が言わんと欲する所が、あまりに陳腐過ぎて、
細かい説明するのが面倒つうこと。

687:デフォルトの名無しさん
05/07/11 06:30:49
Lisper は他でやってくれ


688:デフォルトの名無しさん
05/07/11 11:37:21
そのLIPSぐらいしか話題ないってことなんじゃないの。

689:デフォルトの名無しさん
05/07/11 16:37:20
>>688
燃料投下(>>674)までの流れを見た上で言ってるのか?

690:デフォルトの名無しさん
05/07/11 18:35:40
燃料に見えるのか。

691:デフォルトの名無しさん
05/07/11 18:55:26
688はキヤノン社員

692:デフォルトの名無しさん
05/07/11 19:22:03
ここはLisp擦れ


693:デフォルトの名無しさん
05/07/11 19:49:05
内部イテレータのある言語を設計してみたいと思ってるんですが、
Ruby以外に内部イテレータを持ってる言語って何がありますか?
Rubyの内部イテレータではなく、一般に内部イテレータとは
匿名関数と本質的にどの点で違うものなんでしょうか。

694:デフォルトの名無しさん
05/07/11 20:15:01
「Rubyの内部イテレータ」について説明してくれたら答えられるかも。

695:デフォルトの名無しさん
05/07/11 21:29:03
>>693
>Ruby以外に内部イテレータを持ってる言語って何がありますか?
このスレでさんざん出てきてるLISPというやヴぁい言語のインライン関数が元ネタ。
Rubyで内部イテレータとわざわざ限定してるのは対象データの
コンテナを抽象化して取り出すことを目的にしてるからじゃないかと。

>一般に内部イテレータとは匿名関数と本質的にどの点で違うものなんでしょうか。
質問の意図が不明だけど、まず役割が違うでしょ。
内部イテレータに匿名関数(ブロック)を渡してぶん回すんだし。
匿名関数側は取り出す要素の構造以外知らなくていいし、
内部イテレータはぶん回すコンテナの構造以外知らなくていい。
外部イテレータとの違いはここにある。


696:デフォルトの名無しさん
05/07/11 22:43:27
つまり、Ruby>Lisp ってことですか?


697:デフォルトの名無しさん
05/07/11 22:54:58
mapとどう違うんだ?

698:デフォルトの名無しさん
05/07/11 23:07:43
mapが何か関係あるのか?

699:デフォルトの名無しさん
05/07/12 00:25:21
ここはLispとRubyの話は禁止
どうしてもやりたいのなら別スレ立ててそっちでやってください

700:デフォルトの名無しさん
05/07/12 00:25:38
>>693
Smalltalkにはブロックという概念があり、これがちょうどRubyの内部イテレータ(ブロック)に相当します。
Lispのmapとも似ていますが、どちらかというとSmalltalkのほうに似ているんじゃないでしょうか。
Smalltalkとの違いは、Rubyでは基本的にメソッド1つにつき1つのブロックしか渡せませんが、Smalltalkは複数のブロックを渡すことができることです。

なおRubyでは、昔は本当にイテレータとしてのみ使われていましたが、今は他の用途にもよく使われるため、現在ではブロックと呼ばれることが多いようです。
また「内部イテレータ」というのは使われ方の名称であって、機能としては「クロージャ」というのがプログラミング言語一般の用語です。
(「クロージャ」という機能を「内部イテレータ」として使うということ)

701:デフォルトの名無しさん
05/07/12 01:06:35
実装的にはイテレータとしてのみブロックを渡す場合は、
真面目にクロージャを作る場合よりも省略できる部分が、
結構あるんだよね。
あと、内部イテレータと外部イテレータにはそれぞれ、
長所と短所がある。簡便なのは内部イテレータだが、
複雑なイテレーションの場合は外部イテレータのほう
が良い場合もある。
個人的なオススメはクロージャが扱えるオブジェクト
指向言語なら外部イテレータを基本に設計して、内部
イテレータはライブラリで用意する、というやり方。


702:デフォルトの名無しさん
05/07/12 02:56:11
>実装的にはイテレータとしてのみブロックを渡す場合は、
>真面目にクロージャを作る場合よりも省略できる部分が、
>結構あるんだよね。

詳細きぼんぬ

703:デフォルトの名無しさん
05/07/12 03:01:01
>>702
環境をスタックからヒープに移すタイミングの問題。


704:デフォルトの名無しさん
05/07/12 04:07:52
特殊用途向けに制限掛かったクロージャ?

705:デフォルトの名無しさん
05/07/12 07:33:41
>>693
構文に関して言えば、
内部イテレータに特化した構文(だったものも含む)を持ってる言語は
俺の知ってる限りでRubyとSmalltalkだけかな。
他になんかあったっけ?

706:デフォルトの名無しさん
05/07/12 09:26:54
>>705
SmalltalkのCollection関係の
 aCollection do:[each: 一件ごとの処理].
とかは言語組込みの構文じゃなくてクラスライブラリの命名ルールだよ。


707:デフォルトの名無しさん
05/07/12 21:43:33
つまり Ruby が最高言語ということでファイナルアンサ?


708:デフォルトの名無しさん
05/07/12 21:54:55
ここの連中はRubyとLISPの名前を出せばほいほい釣れるよ。

709:デフォルトの名無しさん
05/07/13 08:56:12
あたしのために喧嘩なんてしないでッ

710:デフォルトの名無しさん
05/07/14 20:44:00
                         .,Å
                      .r-‐i'''''''''''i''''‐-、
                    o| o! .o  i o !o
                    .|\__|`‐´`‐/|__/|
                     |_, ─''''''''''''─ ,、 /
                    、-'      u   -、  
                  / U          0 \
                 /          /     i
                 |   ● ,,.   .,, ●      | 
      __   .      !    (_人__)        ノ
  /´ ̄       `!.      丶_   u        U ノ
  |  `にこ匸'_ノ .       '-、、,,,,,,_______,,,,,,、、-'
  ノ u  {                 _.. -―| :{   ,/ /   \
. / l   | __  / ̄ ̄`>'´   ノ'    ´ {、    \
/ |/     {'´    `ヽ. " ̄\ U `ヽ.    __,,.. -‐丶 u  ヽ
| / ヾ、..  }      u' 〉、    }    `ー''´  /´ ̄ `ヽ '" ̄\
! :}  )「` ノ、     ノ l\"´_,,ニ=-― <´  ヽ{  ノ(   `、  |
l   、_,/j `ー一''"   },  ノ ,  '''''""  \   ヽ ⌒ヾ      v  |
ヽ   _         /   } {. { l ┌n‐く  ヽ/ ``\        ノ
  `¨´    `¨¨¨¨´ ̄`{ 0  `'^┴'ー┘|ヾ    }、 u'   `  --‐r'′ キングヤッタス!!



711:デフォルトの名無しさん
05/07/14 22:08:03
>>709
リンゴタン?


712:デフォルトの名無しさん
05/07/15 22:18:25

LALR age


713:デフォルトの名無しさん
05/07/16 18:07:28
現在確認されている厨

・RUBY厨
・LISP厨
・りんご厨
・LALR厨



714:デフォルトの名無しさん
05/07/16 18:13:11
上から3番目のは、昔かたぎのFlash職人(元Macromedia Director職人)か?

715:デフォルトの名無しさん
05/07/16 18:22:18
>>713
LALRもダメでつか

716:デフォルトの名無しさん
05/07/16 19:13:12
りんごってVIPのことだろ

717:デフォルトの名無しさん
05/07/16 21:10:41
ここで暴れてる荒らしは、荒らしな上にアンチLISPにアンチRubyに
アンチLALRか。
救いようがねぇなw


718:デフォルトの名無しさん
05/07/16 21:13:59
志村坂上

719:デフォルトの名無しさん
05/07/18 15:40:14
すいません超初心者なんで的外れなことを覚悟で質問します。

bison/flexではいたコードってVCでコンパイルできますか??

720:デフォルトの名無しさん
05/07/18 15:50:45
>>719
やってみればいいじゃん

721:デフォルトの名無しさん
05/07/18 16:57:29
ってゆーかRUBY最強

722:デフォルトの名無しさん
05/07/18 17:30:55
>>708

723:659
05/07/22 02:50:23
>>719

>>657-659 読め。

bison/flexで吐いたコードをVC++でコンパイルした経験は、俺はある。


724:723
05/07/23 23:01:08
>>723
ありがとうございます。よく読んでいませんでした。

とりあえず原田賢一著 コンパイラ構成法という本を購入しました。
これから勉強します。

725:719
05/07/23 23:01:49
すいません719です

726:デフォルトの名無しさん
05/07/25 02:13:48
LexやYACC等のツールを使わないとコンパイラ作れない奴なんざ
雑魚だろマジで。


727:デフォルトの名無しさん
05/07/25 02:15:53
>>726
字句解析とか構文解析とか、単純なんだから別に自動生成でいいやん。
ていうか、こういうツールだって、どういうことやってるのか理解できない人には使えないと思うよ。

728:デフォルトの名無しさん
05/07/25 14:06:30
>>726
rubyの作者を雑魚あつかいですか?

729:デフォルトの名無しさん
05/07/25 15:05:00
>>726のようなことを言う奴はコンパイラのバックエンドをろくに書けない奴に多い。
たぶんフロントエンドだけがやっとで挫折したんだろう。


730:デフォルトの名無しさん
05/07/26 10:08:34
LexやYACC等のツールを使わないとコンパイラ作れない奴が雑魚なら、
LexやYACC等のツールを使わずにコンパイラを作る奴はフジツボ。
LexやYACC等のツールを使えない奴はプランクトン。

731:デフォルトの名無しさん
05/07/26 12:20:11
ここは酸っぱい葡萄が多いインターネットですね。

732:デフォルトの名無しさん
05/07/26 20:48:40
イソップ童話キタ━━━(゚∀゚)━━━ !!!!

733:デフォルトの名無しさん
05/07/26 21:15:44
言語鍛冶が覆面で議論するスレはここですか?

734:デフォルトの名無しさん
05/07/29 11:04:33
JavaScriptのコンパイラコンパイラが欲しいんだけれど、調べた限りではないみたいなので、
これを機会に時間のあるときに作ってみようと思ったのだけれど、
コンパイラコンパイラ実装の参考文献で良書はありますか?英文和文問いません。

735:デフォルトの名無しさん
05/07/29 22:56:38
ネタとしてスルー。

736:デフォルトの名無しさん
05/07/30 01:54:03
JavaScriptでかかれたコンパイラコンパイラ?(まさか~)

でも文脈からだとJavaScriptの構文を理解するbisonコードくさいんだけどさ。


737:デフォルトの名無しさん
05/07/30 02:03:01
コンパイラコンパイラが生成するコードがJavaScriptのものなんじゃないの?

738:デフォルトの名無しさん
05/07/30 02:04:06
Mozillaのソースとか・・・・・・・・

739:734
05/07/30 02:13:44
>>737
そう、そういう意味です。
JavaScriptで出来たコンパイラコンパイラなんてあれば面白いけれど…

740:デフォルトの名無しさん
05/07/30 06:12:34
>>734>>734


741:デフォルトの名無しさん
05/07/30 06:52:32
ドライバだけJavaScriptなら簡単なんじゃん?

742:デフォルトの名無しさん
05/07/30 07:54:28
CからJavaScriptに変換するトランスレーター作れよ

743:デフォルトの名無しさん
05/07/30 17:52:12
>>734
LALRパーサージェネレータでよければ、kmyaccでサポートしてます。
URLリンク(www005.upp.so-net.ne.jp)

こうした方がいいという意見も歓迎。

JavaScriptで書いたデモの例
URLリンク(www005.upp.so-net.ne.jp)


744:734
05/07/30 19:50:44
>>742
それは良いアイデアですね。
JavaScriptの言語的機能は制限されるのが残念ですが、
とにかく使いたいだけならそれは良さそうです。

>>743
おお、これはそのまま使えますね!ありがとうございます。
早速使ってみます。助かりました。

745:デフォルトの名無しさん
05/07/30 21:10:39
>>744
使うにあたってはプロトタイプを手直しした方がいいでしょうね。

ところで、JavaScriptでは入力を得る手段が限られていると思うのですが、
どんな対象をパースするのか、さしつかえなければ教えてもらえませんか?


746:734
05/07/30 23:40:21
>>745
助言ありがとうございます。
JavaScript ObfuscatorをJavaScriptで書こうかと思っていました。

747:デフォルトの名無しさん
05/07/30 23:57:26
>>746
ようするにスクリプトを読まれたく無いと。
ただそれだけ?



748:734
05/07/31 00:11:31
>>747
そういうわけじゃないですよ。どちらかといえば趣味です。

その時は手動で構文解析を作りましたけれど、
チェスの掲示板に棋譜を読み込むためにPGNファイルのフォーマットをパースするなど、
JavaScriptでコンパイラコンパイラが作れればいいなーと思うことは稀にありました。

749:デフォルトの名無しさん
05/08/03 12:01:25
ちょっと趣旨が変わってしまいますが…
状態遷移を扱うのに適するエンジンってありませんか?

やりたいことは、入力を受け付けて、新しい状態を出力するモジュールです。
その状態遷移ルールは何らかの自作エディタでペトリネットやUMLの
アクティビティ図のように記述しておきます。

単にゴリ押しで、定義データに各遷移ルールを記述しておき、制御モジュールで
パターンマッチングで次の状態を探すだけでも可能ですが、トークンのJoinとか
考えると、いろいろ内部情報を保持する必要があります。

普通のスクリプトやゲームのシナリオなんか参考になる気もしますが、今回の場合、
有限状態機械に特化したもので十分です。
また、状態遷移図の定義の変更は頻繁に行われます。

もし、美しいアーキテクチャがあるなら、ゴリ押しのエンジンを作り直したいと
思っているのですが、オブジェクト指向で機械の内部状態とか定義方式を美しく
表現している設計って、どこかにないでしょうか?

750:デフォルトの名無しさん
05/08/03 13:04:20
>>749
>オブジェクト指向で
限定しない方が良いよ。OO に限定するとステートパターンしか出てこないから

751:デフォルトの名無しさん
05/08/03 13:10:40
状態遷移を美しく表現する設計は興味があるな。
世の中ではどんな形なんだろう

752:デフォルトの名無しさん
05/08/03 21:01:28
オブジェクト1つが、1つの有限状態機械だと思ってる。
UMLでもステートチャート図あるし
状態遷移をオブジェクト指向で表そうとするのは適切でないような気がするけど

753:デフォルトの名無しさん
05/08/03 22:18:27
う~ん、でも、オブジェクトを入出力とするエンジンって有り得ないですかねぇ。
事前の状態遷移定義に従って、オブジェクトAがエンジンによってBに変えられるような。

別にオブジェクト指向に拘る訳じゃないですが、オブジェクト指向を例にとると、
1つのオブジェクトが、エンジンに渡されると、2つのオブジェクトに分岐したり、
その逆に2つのオブジェクトが揃ったら、1つのオブジェクトに合流したり…
さらに、その合流待ちの状態が無限って訳にはいかないだろうから、生存時間が決まってたり。

こういうのって、昔から学術的には扱われてると思うのですが、
実際に実装するとなると、どういう定義記述方法にして、どんな内部状態を持たせるのかなぁと。
もしかして、何か美しい設計が、すでにあるのかと思った次第です。

今なら、定義はXMLになるのかなぁ…

754:デフォルトの名無しさん
05/08/03 22:40:13
>>753
まさか…oさん?

755:デフォルトの名無しさん
05/08/04 00:07:42
CodeProject に XML を利用したステート・マシンのサンプルがあったような気が・・・
気のせいだったかも

756:デフォルトの名無しさん
05/08/04 05:06:54
要求に合うかどうか判らないけど、
Object指向でPush-down automatonならFinate State Machine。
尚、定義ファイルのパースは別途必要です。

757:デフォルトの名無しさん
05/08/04 16:54:55
>>754 いいえ違います。

>>755
URLリンク(www.codeproject.com)
キャ━━(*´∀`*)━━ !!!!!
と思いましたが、よく見ると、これ、現状のコードとスタート地点同じ気がします…
この先、アクティビティ図とか、ペトリネットレベルまで拡張していくと、
ごちゃごちゃしてきて、もっと美しい設計無いのかと思った次第です。
だから、この先にある、汎用性のあるものが知りたいと…
我侭で申し訳ありません。

>>756
有限状態オートマトンの汎用エンジンに、興味あります。
Radiumさんの過去ログに記述ありました。月末の2日分です。
URLリンク(www.radiumsoftware.com)

このEventStudioというものが、なんか実現してるっぽいです。
URLリンク(www.eventhelix.com)
少し詳しく読んでみたいと思います。


758:デフォルトの名無しさん
05/08/05 23:48:44
boost::fsm...

759:デフォルトの名無しさん
05/08/06 22:01:29
>>750
StatePatternで何か不都合があるのか?

760:デフォルトの名無しさん
05/08/07 00:27:31
URLリンク(www.eventhelix.com)

これは、どの辺がいいの?解説求む。

761:デフォルトの名無しさん
05/08/17 09:13:09
Windows上で、JITで生成したnative codeを、
DLL形式でファイルに保存して実行するのではなくて、
メモリに保存して実行する方法を教えてください。

762:デフォルトの名無しさん
05/08/18 02:30:07
誰かC++の関数スタックを活かしながらSchemeの継続を実装する方法を教えてください。
……できそうにないのはわかっているけど、あきらめるのはちょっとくやしい……

763:デフォルトの名無しさん
05/08/18 03:50:57
>>762
大域脱出のみに使われるような継続であることがSchemeのプログラム
を解析して証明できる場合なら、setjmp/longjmpでいけるんじゃね?
Schemeコンパイラ関連の文献読むと、色々ヒントが書いてあるよ。

764:デフォルトの名無しさん
05/08/19 00:42:56
やっぱり脱出方向だけにしてsetjmp/longjmpぐらいしかないか……

真面目に継続使いたかったら(自前でstack作ったりして)継続を管理するしかないのかな。
……Commandパターン使って少しでも手を抜くとするか……

765:デフォルトの名無しさん
05/08/19 03:04:24
>>764
SchemeをCPSでCにコンパイルする方式。
URLリンク(home.pipeline.com)

C関数はreturnしないので、スタックはヒープとして使う。
いっぱいになったらcopying GC。


766:デフォルトの名無しさん
05/08/19 23:28:22
自作言語に正規表現libをなんとかして融合しようと思ってるんだけど
リテラルとして組み込むと内部で正規表現objectと文字列リテラルの切り分け
みたいなのが別途必要っぽいし、ライブラリとして組み込むと呼び出し手順が
複雑になって結局使われないんじゃないかとか色々考えても良さげな方法が
みつからなかった。

つーかrubyみたくperlの真似して/~/にすると//という1行コメントと勘違いする
かもしんないし、/はそもそも割り算に使ってるし。
独創的な構文にしすぎてメンテする俺自身忘却するようなの作っても
それはそれで意味ないし別に/~/でもいいけどよ、出現位置によってトークンの
意味が変わるのって言語として変な気がするんだけどおまえらどうですか?



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