top recent

プログラミング

関連ページ

プログラミング言語 プログラミング言語:高階関数 プログラミング言語:Lisp プログラミング言語:Haskell プログラミング言語:スクリプト系 「Rubyで関数プログラミング」へのコメント プログラミング:企画もの プログラミング言語:URLメモ プログラミング言語:文法談義 アスペクト指向プログラミング プログラミング言語:FPsystem プログラミング言語:高階関数:談話室 プログラミング:企画もの:お題1 プログラミング:企画もの:お題2 プログラミング:企画もの:お題3 文芸的プログラミング プログラミング言語:糊

目次

  1. ほかの関連ページ...
  2. 状態管理の2つの方法...
  3. 隠蔽と抽象化とアンチ隠蔽と...
  4. プログラムはRunするものなのか?...
  5. LispかSmalltalkの処理系をひとつでも...
  6. 末尾呼び出しの変形と、条件文の変形との、類似性...
  7. エラー番号いってよし...
  8. 代入文の特殊性...
  9. Javaコーディング標準...
  10. 並列プログラミングへのアプローチ...
  11. RunつーかEval...
  12. dW: プログラミング改善への道: 第5回 モジュールとオブジェクト...
  13. parrlen()?...
  14. 再帰と連鎖と直列と並列...
  15. StandAloneとSmartLink...
  16. GUIをAPIとして用いるプログラミング法...
  17. 文芸的プログラミングを利用したスクリプト配布...
  18. あらためて...
  19. 構文解析ってめんどくさいのう...
  20. SNOBOL...
  21. パターン+アクションを入れ子に出来る拡張Awk...

ほかの関連ページ

OOP
FP
プログラム意味論

[[id:1099]] 2002-09-03 21:26:40


状態管理の2つの方法

Schemer's way (プログラミング言語:Lisp) を読んで、でもやっぱり俺は思うのだ。

Schemeのやりかた(つまりクロージャ)でオブジェクトのようなものをやれる、と言われても、
じゃあオブジェクトでクロージャのようなものをやれるんじゃないの?と。

つまり、クロージャとオブジェクトは、どっちがよりプリミティブな概念か?というと、これはどっちもどっちの同程度なんじゃないか?と。

以上、直感に過ぎないので、諸兄の反証を期待してますm(__)m

ちなみに、オブジェクト指向のアーキテクチャに幾通りもあるってのはソノトオリなんだが、
じゃぁどれがより一層プリミティブか?というと、そりゃやっぱりプロトタイプで動的なOOPでしょー。
なぜなら、そういうのをプリミティブだと呼ばないならば、
Schemeのような言語のありかたをプリミティブだと呼ぶことに意味が無くなってしまうから(笑)。

そうでなく例えばC++を初元のように感じる人は、最終的にはアセンブラしかプリミティブだと思えないハズだ。
で、この議論においては、そういう立場は関係ない(ぉ)ので…。

----
クロージャとオブジェクトの類似点や相異点については、
DelphiのMethodPointer (Delphi) またはその延長に位置するであろう未知の洗練された文(笑)が
説明になっている、というのを勝手に期待しています。
でもたぶん駄目だと思うので、これも諸兄による改訂を期待ぃ。

なんてーか、編物がクロージャであり、織物がオブジェクトって感じかなーと邪推。
関数(?)と同じ流れの中で状態を表現するのが前者、
関数(?)と直交の位置に状態を表現するのが後者、だから。

#フェルトは知ったこっちゃありません(劇ぉ

クロージャとオブジェクト

signature: 戯

[[id:583]] 2002-08-05 12:39:48


隠蔽と抽象化とアンチ隠蔽と

"ざうちゅう"の頁に、

>マウスや画面などのハードウェアもオブジェクトとして抽象化されており、それらのごく基本的な部品にまで手の届くようなシステムを書くことができます

とあるが、これの意味するものは結構重大な事柄であり、かつその割には省みられてない、ような気がする。

思うにこれの味噌は、「抽象化されてる」のにも関わらず「隠蔽されていない」、
という点なんじゃなかろうか?

抽象化と隠蔽とを混同している人が、ちと多いような気がする。
隠せば使いやすくなる、というのは間違いであることがしばしば有るのに。

Squeakの例では多分、たとえばマウスならマウスを、抽象化することによって、
むしろマウスを「隠したりしなくても」使いやすくなっていたり
誤用を回避できるようになっていたり、するのではなかろうか?

そりゃハードやOSのレイヤくらいは丸ごと隠したほうが良いことが多いだろうが、
隠すという行為を再帰的に繰りかえすことでトップレベルだけを見せるようにすれば
それでなにかが使いやすくなる、と思いこむのは、たぶん大抵の場合、間違いだ。

だって、隠しちゃったら使えなくなるでしょ(^^;
使っても良い(安全な、とか)部品ならば、むしろ見えるところに沢山有るほうが、幸せでは?

部品を集めて、よりおおきな部品を作ることはできるが、
隠されてしまった部品は、もう使えないのだから。

だから、せめて我々は、「できるだけ小さい単位を」隠蔽の対象とすべき、なのじゃないかなあ?

ところで、そういう意味では、Javaの標準ライブラリは、Cよりは(笑)イケてる。
文字列とか数とかの「小さい単位」の部品は、たくさん有るからね。
ファイルも、ファイル名という概念とファイル内容という概念が、別クラスに別れてる。
我々は、それらを組みあわせて、ライブラリ(すこし大きめな部品)やアプリを、作ることができる。

普通の奴らの上を行くという概念は、言語(仕様)の比較だけじゃなく、ライブラリ(仕様)の比較にも、有効な概念なのではないかな?

----
Tiki:フレームワークによると、
フレームワークの成長過程として、 Fine-grained Objects という概念が有るようだ。


signature: 戯

----

仕様、境界条件までは抽象化できませんからねー。

肝に止めておきます。

----
ある種のテキストファイルの加工に最適化された言語だと (プログラミング言語:スクリプト系) に出てくる、common practice という言葉も、重要だろう。
つまり、あるpractice がcommonであるかどうかによって、その処理に対応するコードを作るときの態度や心構え(^^;を、
切り替えると良いのではないか。もちろん結果としてのコードの位置付けも切り替える。

-ところで、common practiceみたいな、何かを表すための非常に的確なひとことを、
--既存のもの(無数の言葉)の中から「探す」には、どういう経験をすればいいのだろう?
--新規に「考案する」には、どういう精神様態を持てばいいのだろう?(^^;

[[id:607]] 2002-08-23 18:46:34


プログラムはRunするものなのか?

ソフトウェアに書くほうが似合うかな?

これって、継続 (グラフ計算ソフト(仮称))継続とフォーカス? (グラフ計算ソフト(仮称))
読んでて思うんですが、プログラムが「run」するのって、当然なことなのでしょうか?

まずはメモリなりなんなりの上に「状態」が有り、
必要に応じて(つまりオプショナルに)それにスレッドが寄生(^^;する、と
思う心は愚かでしょうか? -戯

----
VBやDelphiみたいな開発環境で、ソースを書いたりWidgetを並べたりしてから
「run」する(そういうメニューがある)んだけど、これが違和感なんだよね。

俺は別に何かrunさせたい対象が有るわけじゃないのに。
ただただ、作ったWidget配置を「表示」したいだけだったり、
作ったClassのInstanceを「生成」したいだけだったり、するんだよね。

それらを実現する手段を「run」と呼ぶのは、それこそ、実装上の都合というか小手先の問題
でしかないはずなのだが…

----
Delphiで開発中に表示されているフォームや部品は、開発対象となっているそのクラスのインスタンスが表示されているんでしょうか。それとも編集中は見た目だけ同じハリボテが表示されていて、インスタンスは Run する時にはじめて生成されるんでしょうか?
編集中も実物がインスタンスとしてそこに表示される仕組みなら Squeak / Hypercard / Emacs と同じ系列だと思うんですけど。

-Delphiについて:
-Formはハリボテです。今Coding中のForm子孫Classではなく、Formそのものか、IDE用に特化したFormの子か、だと思われるFormがIDEによってnewされます。
--その際、店子Component Instanceの管理は、Formの動的な店子管理Property群(ComponentsとかComponentCountとか)で管理してる。既存Classには静的なMember変数が生成できないのだから当然そうなる。
--Coding中の本番Formでも動的な仕組みは生きる。同時に静的なMember変数も有る。二重管理(^^;。ユーザーProgramからは、ソースとしての綺麗さや処理速度が欲しいなら静的経由で、Iterationなどをしたいなら動的経由で、Componentに触れればいい。
-Componentは常に本物がnewされます。自作モノも。ハリボテは有りません。
-Delphiは、本番Modeと練習Mode、もとい実行Modeと設計Modeという概念が有ります。
--細かくいえば、更にComponent永続情報のLoad中Modeとか、も有る。
---ComponentはForm上で生成されるとき、(そのForm上の全部のCompoが)Newされる→(同)Load中Modeに遷移→(同)Loadされる→(同)設計Modeか実行Modeに遷移、という手順を踏む。
----Load中から設計/実行に遷移する(全部のCompoのLoadが終わった)とき、各Compoにイベントが飛んでくる。永続情報の整合性がCompo「間」で取れた後にすべき処理を、そこでする。
-----つまり、そのイベントの前が「非Run」であり、後が「Run」である(^^;;; Run部のMethodを書かないことが出来る(NOPにする:そして実際それで問題ないClassも多い)。
--だから設計ModeのForm上で自律(?)的に動くComponentは作れる(自律)。
--Component(部品)は自分Instanceが今どのModeに居るかを知るPropertyが有ります。Modeを確認しつつ挙動を変えることも可能。
---Load中ModeならSetterを呼ばれても直ぐには(値をメモリ上に保持する以外に)なにもしない、というIdiomは、頻出します。Run「すべきではない」時間帯、という感じ?

うーん、もしかして、そういうモードの区別がない、強いて言うなら常に実行Modeでありながらプログラミングもできるようなインタラクティブな開発環境を使ったことがない?
-経験の有無は無関係ではないですか?それを調べたところで「思う心は愚か」かどうかとか「小手先の問題」かどうかとかは、判らないのだから。
そうですね。失礼しました。
個人的な意見ですが、モードの区別のない開発環境で作られたアプリケーションは、同じ環境の中に同等の存在として、アプリケーションも開発ツールも存在しているわけですから、開発やデバッグは非常に楽ですが、スタンドアローンで動作するバージョンを生成するのに手間が掛かったり、逆に開発環境と切り離すことが難しかったり、厳密には不可能だったり、使用できる機能に制限がかかったりすることがあるような気がします。

[[id:719]] 2002-09-12 13:55:37


LispかSmalltalkの処理系をひとつでも

いじり倒せば、そういうRunのない環境のよさや欠点もよく分かるようになると思うんですけどね。
戯さんを見てると皿の周辺をぐるぐる回ってなかなか食べようとしないって感じです。

----
え?LispってRun無しなんですか?
あれをRun無しと呼ぶならbbbbだってRun無しってことになると思うんですが、
bbbbをRun無しだと思ったことは無いし…。

そりゃそうとGive me 時間 (T_T) -戯
----
LispはRun無しだと思いますよ。
#永続化された情報から処理系の上に特定の状態を呼び出すことをRunと呼ばなければ。
EmacsのバッファとかウィジェットとかはRunなしで表示されたり動作したりすると思います。

ところでグラフ計算ソフト(仮称)でいう手続きオブジェクトの呼び出しってトリガーはどういうタイミングを想定していますか?
----
「Lispのは評価であってRunではない。」というのはただの言葉遊びのように思います。
ーばし
----
LispやSmalltalkはVBやDelphiのように、開発環境と開発対象が明確に分かれていないという意味でRunなしだと思っています。
戯さんが言っているRunなしってRAD的な視点でいくと、ウィジェットをキャンバスに置いた時点でそれがそのものとして動き始める、という意味ですよね。SqueakのMorphic環境みたいな。
--SHIMADA
----
あーなるほど。理解しました。
HyperCardとかもそんな感じですね。
ーばし

[[id:721]] 2002-08-05 12:41:44


末尾呼び出しの変形と、条件文の変形との、類似性

A=func(){hoge(); A();}

A=func(){loop{hoge();}}
とが
等価なのと、

if (A) {if (B) {C();}}

if (A and B) {C();}
とが
等価なのとは、

似てるよね?

----
しかも、

A=func(){hoge(); A(); fuga();}
が(上と同じやり方で)変形できないのと、

if (A) {if (B) {C();}else{D();}}
が(上と同じやり方で)変形できないのとは、

これまた似てるよね?

----
#ああ。日本語は構造化しにくい言語だなー(ぉ -戯

[[id:840]] 2002-08-05 12:43:14


エラー番号いってよし

エラーの分類を「番号(整数)」で管理しようとすると、ある番号と別の番号が作る間隔に対して、
3つめの新しい番号を「外挿」や「内挿」したくなる事が頻繁に生じるので、
-その番号の変化を管理するのがとても大変である。変化させた番号ってどこで参照してたっけ?と。
-逆に、番号を一旦決めたら変化させないというコーディング規約にしてしまうと、番号体系が醜くなりやすいし。

-そうか。行番号BASICのReNumberコマンドは、全自動リファクタリング用システムだったのか。GOTO文の引数とかも自動修正してくれるしさ。

プログラミングにおけるMagicNumberの弊害についての議論と同じことになるのだが、
そういう数字は、文字列な「名前」をつけることで、扱い易くすることが良いとされる。

#嘘格言:
#竹は竹林に晒せ(ぉ。
#隠すんじゃなく、竹林という空間に行けば(ある特定の)竹が有るはずで、探す範囲がそれだけ限定される、という状態を期待できるように下準備をしよう。

で、なんで「名前」をつけると扱い易くなるのだ?

それは名前が文字列だから、だなあ。 -戯

文字列に出来て数字に(Nativeでは)出来ないこととして、それ自体が持つ情報の「構造化」ってのが、有る。
/usr/local/bin/rubyとかjava.lang.Objectとかいう文字列が、構造(この場合はTree構造)のある情報を格納した文字列の一例。

分類に「構造」が見出せるとき(大抵そうなるだろう)、それを整数で捌こうとするのが、無理がある。
分類の構造を文字列(や、それと同じくらいに表現力のある何か)に展開すべきだ。

で、もはや蛇足だが(^^;、javaとかrubyとかdelphiとかの例外「クラス」は、これである。
エラーの分類を、クラスの継承という構造(Tree構造)にマップすることで、事なきを得るわけだ。

Plan9:UNIX との違い (URLメモ)
>Plan9には "signal" が存在しない。UNIX の signal はもうすっかり枯渇してしまっている。Plan9では数字の signal ではなく文字列を signal の代わりに使う。

を見て、ふと上記のようなことを考えた。
枯渇するのは当然だ。32bit(ぉ)分の空間を生のまま与えられたら人(の可読能力)は満足させられるかというと、そんなことは無い。

蛇足2:
一方、整数では簡単だが文字列とかだと面倒になるのが、たとえばメモリ管理だったりする。不定長だから。
各種の古臭い系においては、その面倒を嫌って「あえて無理に整数を採用する部分」は、多かったのではないかな?
ん。クラス継承って、LinkedListで実装するのかな。
----
メインフレーム/COBOL系だと、9(4) とか X(4) とかで定義しますね。
-前者がPACK10進の4桁、後者がCHARの4桁。
構造がある場合は「コード」、無い場合は「区分」と呼び名が分かれていたりします。
エラーコード4桁とした場合、分類の区分が上2桁で詳細の区分が下2桁とか。
-おお!そんな法則(?)性が有ったのですね!もっと早く知って(誰かが教えてくれて)いたら、多くのProjectで随分楽になったのにな(T_T)
--そういうメタな(?)情報を、誰も教えてくれない、ってのが(アレゲな)業務プログラミングをさせられるときの悩みかも。既に知ってる人は暗黙知化しちゃってるし、知らない人はTopicの存在を想像することも出来ない。
--一般的(?)な知識なら辞典や事典に載っているんですが、そうでない知識って奴が、常に曲者になります。つらい…
-- コードと区分の使い分けくらいなら Data Oriented Analysis についての文献なんかには載っているんじゃないかなあ。って僕はOJTで教わったので区分を英語でなんというかすら知らないんですが。

[[id:903]] 2002-09-25 01:03:23


代入文の特殊性

プログラミングの教科書の最初のほうに大抵、
i = i + 1;
という文が出て来て、更に
「これって変な感じがしますが、プログラムの世界では``変じゃない''んです。これで当り前なんです。この文が実行されたあとiの値が変わるんです。」
と頭ごなしの文章がつづく。

説明ではなくて定義だよね。ここで系が変わっている。
そういう世界にジャンプしているんだ。

強く条件づけされてしまって、プログラムが書けるようになる頃には、それがローカルな世界だということさえ気づかなくなってしまうが…。

----
なるほど。逆にいうと、それまで小学校で学んできて、上記の文で否定されている、「算数」のやり方もまた「ローカル」なんだけども、
#どちらのほうが特殊だ、というものではない。たまたま算数のほうが時代的に先輩である(計算機は先輩の記法を借用した)だけで。
そのこともまた誰も(小学校もプログラム教科書も)教えてくれてない、ということなんだろうな。

名前(に限らないが)空間、というものが存在するということを、誰かがきちんと教えたほうが良いんじゃないかな。

言い換えればそれは、「頭を切り替える」ということを(きちんと)教える、ということに繋がると思う。
#愚痴:これの下手な人って、少なくとも日本人には多いんだよね。皆(同一名前空間内)で渡れば怖くない主義だから。

[[id:920]] 2002-08-05 12:52:36


Javaコーディング標準

http://objectclub.esm.co.jp/eXtremeProgramming/CodingStd.pdf
べつにJavaに限ったことではなく参考にしたいので。

興味深いのが「好め」という命令文の存在。
好きになるべきである、という(強い)推奨、である。

#つまり、なんでもかんでも任意に好めばいい、というものでは``ない''ということ。

[[id:923]] 2002-08-05 16:38:58


並列プログラミングへのアプローチ

http://www.ueda.info.waseda.ac.jp/~ueda/readings/tuusinkogyo.html
GHC開発者の記事

[[id:987]] 2002-08-15 16:33:34


RunつーかEval


かな > プログラムはRunするものなのか? (#4)

> まずはメモリなりなんなりの上に「状態」が有り、
> 必要に応じて(つまりオプショナルに)それにスレッドが寄生(^^;する、と

ふと思ったんですが、同じようなイメージって関数型言語にも論理型言語にもあるんじゃないかと。

プログラムとして、ものごとの「関係性」が定義されてる。そのどこかの値を要求したら、スレッドが寄生して必要な部分だけをちゃちゃっと評価してくれると。

「状態」を一生懸命排除しようとしてる関数型言語なんかのほうが、「run」というイメージから遠いように思えます。プログラムは数学的定義の羅列みたいなもので、そこに「ある」。それをどんな順序でも良いから簡約して答えをくれ、って感じ。

関数型だとプログラムが静的になっちゃうんだけど、prologだとassertなんかでプログラム=事象の関係性=グラフ、が自分自身でいじれる。これってかなりグラフ計算ソフト(仮称)にも近いような。

--Schemer
----
Prologって「カット」とか見ると手続き臭いにおい(RUN的にほひ)が結構残っているように感じます。
ーばし

[[id:724]] 2002-09-02 10:32:42


dW: プログラミング改善への道: 第5回 モジュールとオブジェクト

http://www-6.ibm.com/jp/developerworks/linux/020412/j_l-road5.html
『OOP、FP、PPとは、一体何でしょうか。これらは、プログラミング方法論、概念の束、プログラミング・チームのための規則の積み重ねに過ぎません。OOP、FP、PPはツールであり、すべてのプログラマーが最初にすべきことは、そのツールを知ることです。
 :
 :
プログラミング・チームは、最もよく知っているツールを使うことで満足してしまうこともありますが、これこそまさに起こりうる最悪の事態といえます。コンピューター・プログラミング業界のように激しく変化する革新的な業界においてごく一部のツールのみを利用し続けるということは、すなわち、そのチームが数年のうちに何もできないチームになってしまうということを意味します。効率の向上、コードの改善、チームの革新に繋がるものであれば、プログラマーはあらゆる方法論を組み合わせることができるべきなのです。』

※PP = 手続き型プログラミング

[[id:1104]] 2002-09-02 18:36:43


parrlen()?

C言語(ANSI C)には標準で、strlenとかstrcpyとかの「charの」配列を扱う関数群が付いてくる。

なんで、同じ調子で、「void*の」配列を扱う関数群が、付いてないのだろう?
parrlen、parrcpy、などなど…

#もちろん自作するのは簡単なのだが、それを言い出したらstrlenだって同じなので。

末尾の1ワード(?)余計な領域にNULLを書くというお約束で取り扱えば、文字列と同じ考え方でやれるはず。

[[id:1120]] 2002-09-03 21:11:11


再帰と連鎖と直列と並列

「漢数字」SqueakNihongo3 動けばいい版 改め それは桁が知っている…版 へ差し替え (プログラミング:企画もの:お題3)に、連鎖とか再帰とか帰納とかカスケードとかいう話が有りますが、
これってTikiGuion:パターンのカルシウム/直列と並列でいうところの
直列と並列という問題に、帰着(?)できるかな。

つまり、あるObject(OOP用語に限らず)から別のObjectへのチェーンを知っているのは誰か?と。

OOPだと、Iterativeなコンテナにぶら下げる(並列)か、NextObjectを直接参照する(直列)か、を選択するってことかな。

ただし、この直列並列っていう分類は相対的なものであって、たとえば、
Objectを「手続き/関数をぶらさげたコンテナのElement」だと解釈すると、
Objectレベルでの直列繋ぎも、手続きレベルでは並列繋ぎになっちゃうんだけどね(^^;

Lispだとどうなんでしょうね。
処理そのもの(ってなんだ?)が別(自分かもだが)の処理を知ってるなら真性直列だし、
Closureかなんかが知っているなら間接直列だし。

[[id:1167]] 2002-09-11 15:17:28


StandAloneとSmartLink

re:プログラムはRunするものなのか? (#4)
>スタンドアローンで動作するバージョンを生成するのに手間が掛かったり

StandAloneという概念が定義不能なシステム、というのも有るかも知れませんが、それは置いといて。

乱暴にいえばこの問題は、SmartLinkの問題なのではないでしょうか?

SmartLinkというのは、たまたま今おぼえていたBorlandの用語で、
"アプリに"必要な.o(UNIX C風にいえば)のみを出来るだけ正確にライブラリ一式から抜き出す、
という仕組みのことだったと記憶しています。

いや、あれはたしか(それこそDelphiの先輩である)BorlandのPascalシリーズの用語だったな。
そしてそれは、Cなんか(^^;と違い、.oよりも更に細かい単位を扱う…同一ソースに記述された複数の関数をも
必要な分だけ個別にLinkする…ことが出来るような仕組みを指す名だった。

これを今回の話にも適用してみる。 するとSmartLinkという語は、
"アプリ"として欲しい機能のROOTを指定されると、
それから手繰れる(依存関係にある)機能だけを正確に、汎用システムの中から抽出する、
という仕組みを指すようになるのではないだろうか。

----
念のため。
その後継である肝心のDelphiは、SmartLinkが、まるで出来てません(藁
BorlandPascal ver7は、窓出るだけの単純なEXE(Win3.1用)が、たった数kという小ささを誇っていて、
たしかにSmartLinkだったのだが、これがver8のDelphiになったとたんに200k以上に膨れ上がって
のけぞったのを覚えています(^^;

Delphiが、コンパイル速度を稼ぐためにそうした(つまり「SmartLink」は重い処理である)のか、
それともVCLのような濃ゆいOOPライブラリではSmartLinkは本質的無理なのか、は
少なくともBorland製品を見る限りでは闇の中です。

-Classの中の各MethodをSmartLinkの対象にするのは難しいか?
--Omicron:デスクトップのためのC++にむけての裏返しなのではなかろうか。つまり「必要な」virtual関数がドレであるかを決めるのは困難なのでは?

-そういう意味では、Javaのような「なんでもかんでも動的Link」「.o相当物は常にClass単位の(小さな)ファイル」という戦略は、悪くない。

[[id:1175]] 2002-09-12 14:42:56


GUIをAPIとして用いるプログラミング法

http://ryujin.kuis.kyoto-u.ac.jp/ylab/yamakaku/Papers/Sig1Pro1/Sig1Pro1.html

[[id:1203]] 2002-09-17 20:27:03


文芸的プログラミングを利用したスクリプト配布

http://www.geocities.co.jp/SiliconValley-PaloAlto/2514/web.html

増井さんのを Perl5 に移植したものらしい。

>> 文芸的プログラミング

[[id:1269]] 2002-09-22 11:34:42


あらためて

Knuthの文芸的プログラミングはすげーって思う。

ドキュメント埋め込みのソースやソース埋め込みのドキュメントでなく、本物の、weaveするやつは。

# SHIMADA

[[id:1273]] 2002-09-20 23:07:24


構文解析ってめんどくさいのう

ad-hocにやるのってもうだめぽ。

lex+yaccのような処理をAwk並に簡単なスクリプトで書ける *
「スクリプト・スクリプタ」を誰か作ってくれないものか。

え? SNOBOL?*

[[id:1318]] 2002-09-27 11:43:05


SNOBOL

構文解析ってめんどくさいのう(#19)

http://www.cs.fit.edu/~dclay/cse5040/snobol.html

[[id:1320]] 2002-09-27 11:43:05


パターン+アクションを入れ子に出来る拡張Awk

構文解析ってめんどくさいのう(#19)
Title参照なものをズキューンと妄想。

とりあえず0.5秒で妄想した奴はこんな感じ。
/hoge/{
うんぬん
/fuga/{
かんぬん
}
}

入れ子だけじゃなく参照とかも出来たほうがいいのかな…

-ObjectiveAwkとか?(藁

-Awkの機能と構文解析に一般に必要な機能との差分を考える。
--行指向でなく単語指向。かつ単語の定義自体をScriptで変更できるか?
---単語指向はlexに相当する機能だろう。
---一応Awkも行の定義を変更可能だが、変更の自由度は貧弱なものである。行だからそれで済んでいる。
--パターンを再帰的に組み合わせて上位のパターンを生む。
---パターン再帰はyaccに相当する機能だろう。
---パターンの構造という概念が必要になるかな。
----それをサポートするためには、入れ子で書ける関数的(?)アプローチか、またはパターン受諾状態遷移を記述できるOOP(?)アプローチか、が必要と思われ。

「入れ子」→LL、「状態遷移」→LALRって感じ?
前者はANTLR、後者はyacc (yaccはグローバル状態使いまくりだが)
- 単純な recursive descendent parser で parse できるのは LL(1) っていうだけで,LL な状態遷移型 parser は書けるでしょう.
- LALR(1) で reentrant かつ thread safe な parser を吐ける generator っていうと lemon なんかがありますね.

[[id:1319]] 2002-09-27 17:39:03


top recent

HashedWiki version 3 beta
SHIMADA Keiki