アカウント名:
パスワード:
まさか識別子のうち辞書に載ってるもののユニーク数を数えてるだけだったりしないよな?
それにかなり近いです。プログラミング言語の文脈等はほとんど考慮されていません。
1. 関数定義をトークン分け。2. トークン列を抽象トークン列に変換。3. 抽象トークン列からトークンの順序構造を取り除いて、抽象語彙集合を作る。4. それぞれの関数定義の抽象語彙集合の部分集合のうち、全ての関数定義で部分抽象語彙集合が異なっていて、最も大きさが小さくなる様に取る(最小部分中小語彙集合)。5. 抽象語彙集合と最小部分中小語彙集合の大きさの比が冗長度を表していると考えられる。
> プログラミング言語の文脈等はほとんど考慮されていません。
考慮されていないというより、考慮しなくて良いほうが、構文解析も言語仕様もシンプルになるので、意識的に文脈に依存しない文法を採用しているのだと思います。
趣味レベルの知識ですが、大抵のプログラミング言語は、LR法 [wikipedia.org]をベースとした構文解析を使っており、Javaも基本的にはそうだと考えています。
LR法は、文脈自由文法 [wikipedia.org]に属する方式です。情報工学の世界では、文脈自由文法と文脈依存文法 [wikipedia.org]とかがあります。
パーザーを作るにあたって、識別子が前後関係に依存する場合、先読みや 2-pass の解析が必要になったりするなど、バリデーションを含めた実装と言語仕様が複雑になる傾向があります。処理が複雑になると、構文解析の速度も遅くなります。
そのため、文脈依存文法は避けられる傾向があります。また、言語仕様としても、文脈によって記法が違うと学習コストも高くなるので、シンプルな文法を追求して、覚えやすくどの文脈でも同じルールに……とすると自然に文脈自由文法(LR法ベース)になっていくのだと思います。
今どきはハードウェアの力でゴリ押しして、文脈依存文法どころかパースにチューリング機械が必要な言語を設計することも珍しくない(HTML5とか)。
Javaのストーリーから離れて、遠いところに来ましたね。
まずはやってみました、ってことでいうと、なかなか面白い試みだと思いますし、最終的には プログラミング言語だって、背景知識を持った文脈解釈器に、クエリ言語で命令するぐらいのものになるはずで、例えば
「この前のアレの中で一番いい評判だったの100個出して平均も出しといて。出来上がったら教えて」
てな具合に自然言語に近いものになるはずだから、今はイマイチでも いずれいい指標になるかも、ですね。
解釈器に過度な期待をしなければ、今でもselect foo,avg(foo) from bar order by reputation desc limit 100くらいのことは普通にできる。
int number = 1192;のintは自然言語的には不要でしょう。誰が見ても1192が整数であることは明白なのでわざわざ説明する必要はない。
プログラミング言語でも言語によっては不要だし。(静的型付けでないとか型推論があるとか)
最近は1192年とは教わらないんですよ(違う)。
実際には、1185年に頼朝が全国に守護・地頭の設置(事実上徴税・司法権を得た)のと、1192年に征夷大将軍に任命された(正式に朝廷の統帥権から独立した兵権を確立した)と両方を教わります。「鎌倉幕府の成立年」というのをはっきりとは示さない形です。
「プログラミング言語で使われてる単語は少なく、表現に使っている文字数が過剰」ってことだったら、入力支援に改善の余地があるな。つまりIntelliSenseか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
5%って (スコア:0)
まさか識別子のうち辞書に載ってるもののユニーク数を数えてるだけだったりしないよな?
Re:5%って (スコア:2, 参考になる)
それにかなり近いです。
プログラミング言語の文脈等はほとんど考慮されていません。
1. 関数定義をトークン分け。
2. トークン列を抽象トークン列に変換。
3. 抽象トークン列からトークンの順序構造を取り除いて、抽象語彙集合を作る。
4. それぞれの関数定義の抽象語彙集合の部分集合のうち、全ての関数定義で部分抽象語彙集合が異なっていて、最も大きさが小さくなる様に取る(最小部分中小語彙集合)。
5. 抽象語彙集合と最小部分中小語彙集合の大きさの比が冗長度を表していると考えられる。
Re:5%って (スコア:1)
> プログラミング言語の文脈等はほとんど考慮されていません。
考慮されていないというより、考慮しなくて良いほうが、
構文解析も言語仕様もシンプルになるので、意識的に文脈に依存しない文法を採用しているのだと思います。
趣味レベルの知識ですが、大抵のプログラミング言語は、LR法 [wikipedia.org]をベースとした構文解析を使っており、Javaも基本的にはそうだと考えています。
LR法は、文脈自由文法 [wikipedia.org]に属する方式です。
情報工学の世界では、文脈自由文法と文脈依存文法 [wikipedia.org]とかがあります。
パーザーを作るにあたって、識別子が前後関係に依存する場合、
先読みや 2-pass の解析が必要になったりするなど、バリデーションを含めた実装と言語仕様が
複雑になる傾向があります。処理が複雑になると、構文解析の速度も遅くなります。
そのため、文脈依存文法は避けられる傾向があります。
また、言語仕様としても、文脈によって記法が違うと学習コストも高くなるので、
シンプルな文法を追求して、覚えやすくどの文脈でも同じルールに……とすると自然に
文脈自由文法(LR法ベース)になっていくのだと思います。
Re: (スコア:0)
今どきはハードウェアの力でゴリ押しして、文脈依存文法どころかパースにチューリング機械が必要な言語を設計することも珍しくない(HTML5とか)。
Re: (スコア:0)
Javaのストーリーから離れて、遠いところに来ましたね。
Re: (スコア:0)
まずはやってみました、ってことでいうと、なかなか面白い試みだと思いますし、
最終的には プログラミング言語だって、
背景知識を持った文脈解釈器に、クエリ言語で命令するぐらいのものになるはずで、
例えば
「この前のアレの中で一番いい評判だったの100個出して平均も出しといて。出来上がったら教えて」
てな具合に自然言語に近いものになるはずだから、
今はイマイチでも いずれいい指標になるかも、ですね。
Re:5%って (スコア:1)
解釈器に過度な期待をしなければ、今でも
select foo,avg(foo) from bar order by reputation desc limit 100
くらいのことは普通にできる。
Re: (スコア:0)
int number = 1192;のintは自然言語的には不要でしょう。
誰が見ても1192が整数であることは明白なのでわざわざ説明する必要はない。
Re: (スコア:0)
プログラミング言語でも言語によっては不要だし。(静的型付けでないとか型推論があるとか)
Re: (スコア:0)
最近は1192年とは教わらないんですよ(違う)。
Re:5%って (スコア:1)
実際には、1185年に頼朝が全国に守護・地頭の設置(事実上徴税・司法権を得た)のと、1192年に征夷大将軍に任命された(正式に朝廷の統帥権から独立した兵権を確立した)と両方を教わります。
「鎌倉幕府の成立年」というのをはっきりとは示さない形です。
Re: (スコア:0)
「プログラミング言語で使われてる単語は少なく、表現に使っている文字数が過剰」ってことだったら、入力支援に改善の余地があるな。
つまりIntelliSenseか。