K.Maebashi's BBS

>BF-BASIC…前フリで「逆にいま BASIC 回帰もありなんだな」とか妙に納得しちゃったんですがすぽぽーんでコーヒー吹きました どうもです。ウケたようで何よりです。 いまさらですが、BF-BASIC'nは日付を見ればわかるように2006年のエイプリルフールに書いたものです。 ところで、前フリ部分は、私にとってはあれはあれで一面の本音ではあります(ぼそっ)。

BF-BASIC…前フリで「逆にいま BASIC 回帰もありなんだな」とか妙に納得しちゃったんですがすぽぽーんでコーヒー吹きましたBF で気づくべきだったのだな

>>コードが美しく、短く、分かりやすいです。 > >うーん、ざっと見ただけですが、なんか効率悪いパーサのような… > 許容範囲のコードかなぁー

>つんつんが時々 訪れている「紫藤さんのページ」のPython関数電卓です。 >http://www.shido.info/py/python_calc.html 情報ありがとうございます。 「Perl, Python, Rubyの比較」 http://www.shido.info/py/python1.html は以前に読んだことがあるのですが、その方のページだったんですね。 >コードが美しく、短く、分かりやすいです。 うーん、ざっと見ただけですが、なんか効率悪いパーサのような…

つんつんが時々 訪れている「紫藤さんのページ」のPython関数電卓です。 http://www.shido.info/py/python_calc.html コードが美しく、短く、分かりやすいです。 （つんつんの関数電卓は、引退しました。） 「紫藤さんのページ」には、scheme の関数電卓もあります。 http://www.shido.info/lisp/scheme_calc.html

>>あ、それすごく面白そうです。何度か書いてますが、私自身車輪の再発明が趣味ですし。 > >私も全く同様なのですが、どうも肩身が狭いですね。 >サイトが稼動し始めたらお知らせします。 や、よろしくお願いします。 エディタとかメーラとか、普段使っているツールは、プログラマにとってもっとも自作 したくなる道具であるはずで、だったらプログラミング言語は最優先のはずではないか、 とも思うのですが。 前提からして間違っているのかなあ… # かくいう私自身、クライアントアプリとしてのメーラを書いたことはないですが # (Webメーラなら書いたことある) >解説とか研修を行なうときは「無駄を省いた自作コース」を提供するのが強力であることが多いと思います。 その意味で、以前書いたように「本当の基礎からのWebアプリケーション入門―― Webサーバを作ってみよう」というのを考えてはいるのですが、Diksamができるまでは お預けです。ていうか私自身読みたいネタなので、誰か書いてくれないかしらん。

>>「車輪の再発明工場(仮称)」なんていうサイトを立ち上げようとしている私としては、 > >あ、それすごく面白そうです。何度か書いてますが、私自身車輪の再発明が趣味ですし。 私も全く同様なのですが、どうも肩身が狭いですね。 サイトが稼動し始めたらお知らせします。 > 言語処理系だけでなく、普段使っている何かを自作するというのは、それを理解する > 一番の方法でもありますし(時間はかかるので効率は悪いですが…)。 そうですよね。何にもない状態から発明した人よりははるかに短時間で作れるわけですから、 解説とか研修を行なうときは「無駄を省いた自作コース」を提供するのが強力であることが多いと思います。 # 「何でも自作してみないと本当に分かった気がしないのは、損なのか得なのか？？」と悩んじゃうことはありますが(^^;)

>「車輪の再発明工場(仮称)」なんていうサイトを立ち上げようとしている私としては、 あ、それすごく面白そうです。何度か書いてますが、私自身車輪の再発明が趣味ですし。 言語処理系だけでなく、普段使っている何かを自作するというのは、それを理解する 一番の方法でもありますし(時間はかかるので効率は悪いですが…)。 >素朴な疑問なんですが、(ぱ)さん自身は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 相当の機能)を付け加える予定はあるでしょうか？多相型のセマンティクスは 言語によってかなりバリエーションがあり、一応俺言語を作っている者として、 前橋さんがどのようなセマンティクスが良いと考えておられるかについて興味が あります。