K.Maebashi's BBS

>「車輪の再発明工場(仮称)」なんていうサイトを立ち上げようとしている私としては、 あ、それすごく面白そうです。何度か書いてますが、私自身車輪の再発明が趣味ですし。 言語処理系だけでなく、普段使っている何かを自作するというのは、それを理解する 一番の方法でもありますし(時間はかかるので効率は悪いですが…)。 >素朴な疑問なんですが、(ぱ)さん自身はCrowbarやDiksamを普段どれくらい使われているのでしょうか？ これはもう正直なところを言ってしまうと、ほぼまったく使っていません。 Diksamなんか現状でprint()しか組み込み関数がないので実用になりませんし、 crowbarならAWK程度の役には立ちそうですが、そもそもAWKとかPerlとかRubyとかの 言語でさくっとテキスト処理、という機会も、今の私にはあまりないですし。

久々にお邪魔します。 >まあ、あの文章が面白いのだとすればそれは別に私の手柄ではなく、 >「プログラミング言語を作る」という行為自体が非常に面白いためなんだろうと >思いますが。 ># でも、同意してくれる人はあまり多くない気がします。残念ながら。 「(ぱ)さんの手柄ではない」という点は同意しませんが、 「言語を作るという行為自体が面白い」という点は同意します(そんなに少数なんですかね？)。 「車輪の再発明工場(仮称)」なんていうサイトを立ち上げようとしている私としては、 「面白そうだからやってみる。それだけ」というノリに共感を覚えてしまうんですが(^^;) 素朴な疑問なんですが、(ぱ)さん自身はCrowbarやDiksamを普段どれくらい使われているのでしょうか？

はじめまして。おほめいただきありがとうございます。 まあ、あの文章が面白いのだとすればそれは別に私の手柄ではなく、 「プログラミング言語を作る」という行為自体が非常に面白いためなんだろうと 思いますが。 # でも、同意してくれる人はあまり多くない気がします。残念ながら。 >「プログラミング言語を作る」を体裁を整えて本にしてください。 >５０００円未満なら買います。 えー、どうなるかはわかりませんが、精進いたします。

>あれ、Cにはありますよ。少なくともC89では既にありました。 ありゃ、本当だ。Cの構文規則は何度も見ているしパーサを書いたことも複数回あるし、 知らなかったはずはないのですがなぜか「ない」と思い込んでいたようです。 >Java は知りません。:) ありました。 http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.15.3 毎度のことながらご指摘ありがとうございます。 嘘を書きましてすみませんでした。

「プログラミング言語を作る」を体裁を整えて本にしてください。 ５０００円未満なら買います。

> CでもJavaでも単項の+演算子は用意されていませんよね あれ、Cにはありますよ。少なくともC89では既にありました。 Java は知りません。:)

　再投稿ありがとうございます。 　電卓の大親分であるはずのPCが目の前にあるのに電卓叩いてたり、あろうことか電卓内蔵のマウスパッドなんかが普通に商品の1ジャンルを占めていたりする現状を見るにつけ、こういう(bcのような)電卓には価値があると思います。 　私はすぐにyaccを使ってしまいますが、つんつんさんのは手書きの再帰下降パーサですね。RubyならRaccという手もあるかと思いますが。 >bc では、+1+1+1 がエラーで、-1-1-1 が成功します。 >動作が変です。 　これは実際そのとおりだと思いますが、CでもJavaでも(ついでに言うとcrowbarでもDiksamでも)単項の+演算子は用意されていませんよね(Rubyにはあるようですが)。 　単項+演算子を付けるのは容易なはずなのに付けてないのは、crowbarやDiksamについて言えば単にCをまねたからなのですが、冗長な表現を嫌ったという理由もあるのかもしれません。

bc では、+1+1+1 がエラーで、-1-1-1 が成功します。 動作が変です。 ruby　スクリプト：正規表現が厳密に合っていないのですが 電卓として機能します。 'q' で終了です。 試してください。 　 http://www.otc.ne.jp/~mugenkai/keisan.rb tntn@otc.ne.jp

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

>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 久々にはりこみました。

>はい。ただ、それは全ての型について同一のバイトコードで扱えなければならないという方針の場合の話であって、例えば、基本型は型ごとにコード複製、参照型は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>を使うクラスがあっちにもこっちにもあるとすると、 コンパイルの時点で複製すると悲惨なことに。

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

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

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

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

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

みずしまです。返事が遅くなりましてすみません。 >どうも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なら、コンパイラだけでなんとかなるのではと思ったのですが、 何か見落としがあるんでしょうか？あるいは、 > 型ごとにコード複製やむなし というのが、型ごとにコード複製すれば、コンパイラだけでなんとかなるという 意図でしょうか？

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

>>案として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 相当の機能)を付け加える予定はあるでしょうか？多相型のセマンティクスは 言語によってかなりバリエーションがあり、一応俺言語を作っている者として、 前橋さんがどのようなセマンティクスが良いと考えておられるかについて興味が あります。

>こんにちは。みずしまです。 こんにちは。 はてなの方でちょっと書いたのですが、自宅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だけ先頭」という規則が美しくないとは思っているんですけどねえ。

こんにちは。みずしまです。 以前から前橋さんのページの特にプログラミング言語関係のネタを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; と書くのはいかがでしょう？

えー、補足で一応書いておくと、 これが私の書いたものに対する正当な批判のつもりなら、 ・そもそもどの文章についてなのか。 ・そこで使われている「バカ」の具体例 くらい出さなきゃ話にならんでしょう。 まあ、こんな書き捨て野郎には何も期待してませんけど。

なんなんすかね、これ。 匿名書き捨て野郎の相手をするほどヒマではないので放置しときますが。

何かアレだな 文章に頻繁に出てくる「バカ」ってのがウザい 人をバカにする文章を書くことで優越感に浸れるのかもしれないけど 読んでる方は不快なだけだから。

ページ直すのが面倒なので今年はこっちでやります。 3/22より例によって断酒しています。 今回の期間はゴールデンウイーク開始まで。 ・飲み会では飲んでもいい。 ・それ以外でどうしても飲んじゃった場合には、その旨をここで報告する。 というふたつの例外条件はいつものとおり。 年度の変わり目は飲み会が多いので、そのへんを狙うのがコツ(ぉぃ)