K.Maebashi's BBS

こんにちは。みずしまです。 以前から前橋さんのページの特にプログラミング言語関係のネタをwatchして いましたが、今年になってから「プログラミング言語を作る」の 「静的型・バイトコード実行型言語を作る」編を開始されたということで、 静的型言語好きな自分としては、Diksamがどんな言語になっていくのか 楽しみにしております。 さて、本題なのですが、Diksamでは将来的に関数型の変数を扱う機能の実装を 予定されているようですが、構文に関してはまだ決定されていないようです。 案としてJava 7風に B foo(A); と書く方法と var foo:(A) B; と書く方法の2つを考えておられるようですが、どちらも関数を返す関数などの 複雑な型を書く場合にイマイチな気がします。 C(B) foo(A); //Aを受け取り、「Bを受け取りCを返す関数」を返す関数 var foo:(A) (B) C; //引数と返り値の型が区切られて無いせいで、読みにくい気がする というわけで、静的型付け関数型言語(MLとかHaskellなど)でよくあるように、 foo : int -> int; と書くのはいかがでしょう？

>こんにちは。みずしまです。 こんにちは。 はてなの方でちょっと書いたのですが、自宅PCが不調で、昨夜からついに起動もできなくなりました。今は昼飯がてらネットカフェで書いています。 というわけでしばらく反応が遅くなると思います。ご了承ください。 >案としてJava 7風に > B foo(A); Java 7で関数を代入できる変数の宣言は B(A) foo; では? http://journal.mycom.co.jp/articles/2006/08/23/java7closuer/002.html つまり、 > var foo:(A) B; この形式から、末尾のBを先頭に持ってきて、それ以外の部分をBの後ろにつないだ形式になります(と、私は解釈しています)。 > B foo(A); Diksamには関数のプロトタイプ宣言があるので、この構文はバッティングしますね。 >というわけで、静的型付け関数型言語(MLとかHaskellなど)でよくあるように、 > foo : int -> int; >と書くのはいかがでしょう？ ご提案ありがとうございます。ちょっと調べてみます。 ただDiksamは、 「floatなんか付けるつもりもないくせに浮動小数点数はdouble」 というくらいC/Javaにひよった言語ですので、Java 7風かなあ、とは思っています。 と言いつつ、「なぜかBだけ先頭」という規則が美しくないとは思っているんですけどねえ。

>>案としてJava 7風に >> B foo(A); > >Java 7で関数を代入できる変数の宣言は > >B(A) foo; > >では? >http://journal.mycom.co.jp/articles/2006/08/23/java7closuer/002.html あ、そうですね。うろ覚えで書いたので間違ってしまったようです。 >>というわけで、静的型付け関数型言語(MLとかHaskellなど)でよくあるように、 >> foo : int -> int; >>と書くのはいかがでしょう？ > >ご提案ありがとうございます。ちょっと調べてみます。 >ただDiksamは、 >「floatなんか付けるつもりもないくせに浮動小数点数はdouble」 >というくらいC/Javaにひよった言語ですので、Java 7風かなあ、とは思っています。 >と言いつつ、「なぜかBだけ先頭」という規則が美しくないとは思っているんですけどねえ。 C言語ポインタ完全制覇の記述などを見ても、後置の型宣言の方がお好みなのかな と思っていたので、ちょっと意外な気がしました。とはいえ、この程度の細かい シンタックスの違いはある意味どうでもいい話なので、C/Javaにひよるのも一つ なのかもしれません。 あと、質問なんですが、将来的にDiksamを拡張して、多相型(JavaのGenerics 相当の機能)を付け加える予定はあるでしょうか？多相型のセマンティクスは 言語によってかなりバリエーションがあり、一応俺言語を作っている者として、 前橋さんがどのようなセマンティクスが良いと考えておられるかについて興味が あります。

>C言語ポインタ完全制覇の記述などを見ても、後置の型宣言の方がお好みなのかな >と思っていたので、ちょっと意外な気がしました。 私自身も「後置の型宣言の方が好み」と思っています。 現在のDiksamは「4つ目くらいの作り直し中」で、以前のバージョンでは すべて後置にしていました。 どうもcrowbar ver.0.1で「ifの後ろの()をなくす」という文法にしたものの (これも以前のDiksamではすべてそうなっていました)、自分自身すら慣れることが できなかった、というのがトラウマになっている気もします。 本当にバリバリに使えば、すぐ慣れることなのかもしれませんけれども。 >あと、質問なんですが、将来的にDiksamを拡張して、多相型(JavaのGenerics >相当の機能)を付け加える予定はあるでしょうか？多相型のセマンティクスは >言語によってかなりバリエーションがあり、一応俺言語を作っている者として、 >前橋さんがどのようなセマンティクスが良いと考えておられるかについて興味が >あります。 以前の3つくらいのバージョンのDiksamのふたつめくらいまではtemplateを 付けようとしていました。が、結局そのあたりを作っている間に(複雑に なりすぎて)挫折してしまったわけでして。 私は今でもgeneric programmingの知識や経験が豊富なわけではありませんが、 当時はもっと知らなかったにも関わらずそんなところに手を出したら 挫折するのも当然です。 当時は、Javaのような「ポインタしかない言語」が嫌で、クラスは実体でも 宣言できるようにしようとしていましたし、そうなるとtemplateも、Javaのように コンパイラだけでごまかしきることはできなくなります。 型ごとにコード複製やむなし、という考えで作っていたように思いますが、 結局、その部分の実装まですら行き着けなかったような。

みずしまです。返事が遅くなりましてすみません。 >どうもcrowbar ver.0.1で「ifの後ろの()をなくす」という文法にしたものの >(これも以前のDiksamではすべてそうなっていました)、自分自身すら慣れることが >できなかった、というのがトラウマになっている気もします。 >本当にバリバリに使えば、すぐ慣れることなのかもしれませんけれども。 私の作った言語でも、if、whileなどの後ろの()が無い文法になっているのですが、 普段使っていないと、久しぶりに使ってみたときに、つい括弧つけちゃった という経験があります。結局、自分が普段使っている言語に合わせるのが一番 なのかなとも思います。 >以前の3つくらいのバージョンのDiksamのふたつめくらいまではtemplateを >付けようとしていました。が、結局そのあたりを作っている間に(複雑に >なりすぎて)挫折してしまったわけでして。 >私は今でもgeneric programmingの知識や経験が豊富なわけではありませんが、 >当時はもっと知らなかったにも関わらずそんなところに手を出したら >挫折するのも当然です。 templateの実装は結構複雑そうですね。かく言う自分も、Java generics相当の 機能(JVMで動作するので、仕様はJavaと互換にしたい)を俺言語に搭載しようと 思いつつ、Java genericsの型システムがかなり複雑なので、なかなか 挑めないでいます。 >当時は、Javaのような「ポインタしかない言語」が嫌で、クラスは実体でも >宣言できるようにしようとしていましたし、そうなるとtemplateも、Javaのように >コンパイラだけでごまかしきることはできなくなります。 >型ごとにコード複製やむなし、という考えで作っていたように思いますが、 >結局、その部分の実装まですら行き着けなかったような。 (C++風の)templateなら、コンパイラだけでなんとかなるのではと思ったのですが、 何か見落としがあるんでしょうか？あるいは、 > 型ごとにコード複製やむなし というのが、型ごとにコード複製すれば、コンパイラだけでなんとかなるという 意図でしょうか？

>普段使っていないと、久しぶりに使ってみたときに、つい括弧つけちゃった >という経験があります。結局、自分が普段使っている言語に合わせるのが一番 >なのかなとも思います。 それもひとつの手ですし、なまじ似てるから混乱するというのなら、 いっそ中括弧でなくendで終わる構文にするとか、根本的に変えてしまう というのもありかもしれませんね。 >>当時は、Javaのような「ポインタしかない言語」が嫌で、クラスは実体でも >>宣言できるようにしようとしていましたし、そうなるとtemplateも、Javaのように >>コンパイラだけでごまかしきることはできなくなります。 > >(C++風の)templateなら、コンパイラだけでなんとかなるのではと思ったのですが、 >何か見落としがあるんでしょうか？あるいは、 どこまでVMに実行時情報を持たせるかにもよりますが、たとえばJVMでは、 T型の変数 a, b があるとき、 Tがintのときの a = b; と、Tがdoubleのときの a = b;を同一のバイトコードでは 表現できないのでは? Javaはクラスに関する限りポインタ(参照)しかない言語ですし、 Genericsで対象にできるのは結局Objectだけなので、コンパイラだけで ごまかしきれてますけれども。 基本型は対象にしないとしても、クラスの(ポインタでなく)実体を扱えるように した場合、C++のように機械語を吐くコンパイラでは、「何バイトコピーするか」が 型ごとに違ってきます。このへんVMだと工夫のしようはありそうですが。

> クラスの(ポインタでなく)実体を扱えるようにした場合 あれ、インスタンスに対して参照だけではなく、実体に対する代入等の操作ができる ようにするんでしょうか? それはやめた方が良いような。 継承のあるクラスのインスタンスではなく、単なる構造体のようなものに対してのみ 許すなら問題ないかもしれませんけど...

>あれ、インスタンスに対して参照だけではなく、実体に対する代入等の操作ができる >ようにするんでしょうか? それはやめた方が良いような。 ええと、みずしまさんの独自言語についてはわかりませんが、 現在のDiksamについてであれば、実体に対する代入等の操作ができるように するつもりはありません。 [975]で >当時は、Javaのような「ポインタしかない言語」が嫌で、クラスは実体でも >宣言できるようにしようとしていましたし、 と書いたように、(ふたつめくらいのDiksamを作っていた)「当時は」、そういう 仕様を考えていた、ということです。 それがどれぐらい仕様上も実装上も難しいものであるか、ということを 知らなかっただけですはい。

>どこまでVMに実行時情報を持たせるかにもよりますが、たとえばJVMでは、 >T型の変数 a, b があるとき、 >Tがintのときの a = b; と、Tがdoubleのときの a = b;を同一のバイトコードでは >表現できないのでは? >Javaはクラスに関する限りポインタ(参照)しかない言語ですし、 >Genericsで対象にできるのは結局Objectだけなので、コンパイラだけで >ごまかしきれてますけれども。 はい。ただ、それは全ての型について同一のバイトコードで扱えなければならないという方針の場合の話であって、例えば、基本型は型ごとにコード複製、参照型はErasureによって同一のバイトコードに変換するなどの方針であればコンパイラだけでごまかせると思います。 >基本型は対象にしないとしても、クラスの(ポインタでなく)実体を扱えるように >した場合、C++のように機械語を吐くコンパイラでは、「何バイトコピーするか」が >型ごとに違ってきます。このへんVMだと工夫のしようはありそうですが。 確かに。ただ、ASTや中間表現の段階で実体型ごとにコードを複製しておけば、「何バイトコピーするか」などの詳細はコード生成部に任せられるのでは？

> 現在のDiksamについてであれば、実体に対する代入等の操作ができるように > するつもりはありません。 なるほど。 > それがどれぐらい仕様上も実装上も難しいものであるか、 たぶんユーザにも優しくないですよねえ。 > ＠自宅環境復活 PCは新しいのを買ったんでしょうか？ いまどきなら Core 2 Duo とか？

>はい。ただ、それは全ての型について同一のバイトコードで扱えなければならないという方針の場合の話であって、例えば、基本型は型ごとにコード複製、参照型はErasureによって同一のバイトコードに変換するなどの方針であればコンパイラだけでごまかせると思います。 それはそうです。実際C#だと、値型はコード複製、参照型は同一コードということに なっているようですし。 http://ja.wikipedia.org/wiki/C_Sharp%E3%81%A8Java%E3%81%AE%E6%AF%94%E8%BC%83 >確かに。ただ、ASTや中間表現の段階で実体型ごとにコードを複製しておけば、 >「何バイトコピーするか」などの詳細はコード生成部に任せられるのでは？ ASTや中間表現は共通で、コード複製はコード生成部で行うことになるのだと 思いますけれども、それをいつやるか、という問題がありますよね。 Javaのような実行形態を考えると、Listクラスはきっと事前にコンパイルされて いるはずですし、List<int>を使うクラスがあっちにもこっちにもあるとすると、 コンパイルの時点で複製すると悲惨なことに。

>PCは新しいのを買ったんでしょうか？ >いまどきなら Core 2 Duo とか？ はてなの方に書いてますが、こんな感じです。 http://d.hatena.ne.jp/kmaebashi/20070620#p1 http://d.hatena.ne.jp/kmaebashi/20070627 ブツ自体はこれです。Core 2 Duoです。 http://panasonic.jp/pc/products/w5a/index.html 久々にはりこみました。

>ASTや中間表現は共通で、コード複製はコード生成部で行うことになるのだと >思いますけれども、それをいつやるか、という問題がありますよね。 >Javaのような実行形態を考えると、Listクラスはきっと事前にコンパイルされて >いるはずですし、List<int>を使うクラスがあっちにもこっちにもあるとすると、 >コンパイルの時点で複製すると悲惨なことに。 分割コンパイルを行うときの問題ですか。基本型を対象とするなら個数が あらかじめ決まっているので、Listクラスのコンパイル時に List_int.class, List_long.class, ... を生成しておけば済みそうですが、実体型をユーザが宣言できる言語だと、 同じ手は使えないわけで、考えどころですね。