まじかんと雑記

キャストについて - Java Solution のトピックに 30 を超える返答が。二日足らずで 5 ページ目に達したのは珍しい。確かに配列の型の扱いは初心者が嵌りやすいところだ。問題を複雑にしている要素を列挙すると、

• 配列はそれ自身がオブジェクトであること。(配列の各要素は配列オブジェクトのフィールドのようなものである)
• Object[] ary = new String[3]; のようにアップキャストが可能であること。それでいて String[] クラスは Object[] クラスの子クラスではない。
• コンパイル時の型と実行時の型を区別しなければならないこと。

なんにせよ、普通のオブジェクトの型に関する理解がなおざりなまま配列の型が理解できるはずがない。一連のやり取りを見る限り OZ さんは自分の理解度に対して手を広げすぎだと思う。

それにしても、Java にしろ C# にしろ配列の型がジェネリックでないのが残念なところ。もともとジェネリックがなかったところに後からジェネリックを導入したらこうなるのも仕方がないか。

理想としては、Object[] ary = new String[3]; のようなキャストはできず、コンパイルの段階でエラーになるのが望ましい。それは List<Object> list = new List<String>(); が不可なのと同じことだ。つまり Object[] というのは意味合いとしては Array<Object> と扱われるべきなのだ。

こうしておけば ary[0] = new Object(); で ArrayStoreException/ArrayTypeMismatchException が出るなどというのも解決できる。こういう型のチェックは実行時ではなくコンパイル時に済ましておくべきなのだ。

#Calc の取扱説明書を執筆中。プログラムの方は一応できているので、一通り書けたらベータ版として公開したい。

div/span不要論を読んで思ったことをいくつか

• 文章の題名はdiv/span不要論となっているが、内容はむしろ class 不要論に近いこと
• もし span 要素をなくしたら次のような場合に困らないか、ということ。例えば、<p lang="ja">ドイツ語で <span lang="de">Wald</span> といえば森のことだが……</p>のような場合。

• class属性を用いて、其れにCSSを指定する事で、<p class="warning">で囲まれた部分が警告である事を分り易くする事は出来る。例えば赤い字にすれば何と無く警告の様な感じになるだろう。

  然し、其れは飽く迄も人間が分る事で、UAが分る事ではない。

  赤い字が警告を表していると読み取ることができるのは確かに人間だけだが、それならば改行によって段落が区切られていると読み取ることができるのも人間だけではないのか。

  どうせ機械は文章の意味を理解できないのだから、機械に文章を扱わせるという観点から見れば、<p> でも <div class="paragraph"> でも本質的に違いはない。ただ汎用性の観点から言うと、前者の方が汎用性がある。P 要素は段落を表すものだと仕様書で定められているが、DIV 要素に class="paragraph" なる属性を付加しても段落を表すとは定められていない。<p> が段落を表すというのはこの世に存在する全ての HTML 文書に通用するが、<div class="paragraph"> が段落を表すというのはそうではない。つまり問題は class 属性には汎用性がないということ。別に class 属性で要素の意味を明示できないということはないし、意味を表すのが要素そのものなのか属性なのかというのもどうでもいいことだ。

  汎用性の観点からいえば、class 属性は確かに全く役に立たない。でも特定の HTML 文書が特定のスタイルシートと組合わされる場合はどうなのか。特定のスクリプトプログラムによって処理される場合はどうなのか。特定のユーザエージェントによって処理される場合はどうなのか。Class 属性を使うと文書の汎用性が失われるなどということはないし、別に俺は汎用性のないものが絶対に存在してはならないとも思わないので、class 属性が不要だとは思わない。

#Calc で計算モードや丸め方の設定をする GUI も一通りできたので、明日にでもプロトタイプを完成できそうだが、説明書を全然書いていないのですぐには公開できそうにない。(プロトタイプゆえに説明書なしという手もあるが……)

リセットコマンドは、コマンドを実行するための新たなオブジェクトを導入することで一応解決した。

これで #Script 言語 (暫定版) の機能を全部実装できたので、明日からは #Calc の GUI の実装を始める。といっても、丸め条件の変更などをユーザーが行えるようにするだけだが。

何とか三月中には #Calc のプロトタイプを公開完成できそうだ。

クリック音がしない「サイレントマウス」が発売になったんだってさ。今頃やっと出たかという感じ。一々かちかちいわないマウスなんて、十年以上前にできていてもよさそうなものなのに、いまだに全然見かけないからメーカーは一体何をやっているのかといつも不思議でしょうがなかった。音がしないマウスなんて誰でも思いつきそうなものだし、需要も結構あるだろうに。

残すはリセットコマンドだけなんだけど、そのリセットコマンドを実際にどう実行させるかまだ考えあぐねてる。リセットコマンドは基底実行コンテクストを作り直すコマンドなので、実行コンテクスト側からコマンドを呼び出す今のやり方だとどうやっても不可能。コマンドの実行方法を大きく変えないといけないので、どういう風にしようか考えてる。

といったところで、明日からちょっと帰省するので開発はしばらくお休み。

リセットコマンドを除いて全ての文とコマンドを実装した。リセットコマンドを実装したら #Script 言語の全ての機能を一通り実装し終えたことになるので、その後は #Calc のユーザーインタフェースに取り掛かる予定。

.NET Framework のクラスライブラリでたまたま System.Web.Configuration.BrowserCapabilitiesFactory なるクラスを見つけた。このメソッドの多さは半端じゃない……。UA の種類に応じてメソッドがずらーっと並んでる。Docomof504iProcessBrowsers なんていうのもあるな。

ほとんど毎日欠かさずにプレーしている「Windows 3D Pinball - Space Cadet」。今日はとても調子がよく、休憩を挟んで 3 時間近くにわたってプレーし続け、ずっと夢だった一億点を遂に突破した。あまりに嬉しかったので記念写真も撮ってしまった。

しかしそれでも川上英思氏の五億点を超える記録には遠く及ばない……。

今日も文の構文解析の実装。今日までの進捗状況は……

ブロック

空文

式文

変数宣言文

Print 文

If 文

While 文

済

Do-while 文

For 文

Break 文

Continue 文

復帰文

コマンド

まだこれから

ということで、大体半分くらいかな。

今日からは構文解析の続き。文の解析は式の解析よりも複雑で面倒なので、それなりに時間は掛かるだろう。

構文解析の実装に取り掛かる前に、実行結果を表すデータの扱いを厳密化しようと思ってコードの大幅な書換えを始めた……けど、やっぱりやめにした。ジェネリック型を使えばスクリプト内部の get-reference-value 操作の前後の状態を型によって区別できると思ったんだけど、別のところで辻褄が合わなくなるんだった。

何というか、C# のジェネリックは Java のジェネリックよりも機能が劣る、ということを改めて実感したよ。(C# のジェネリックにはできて Java のジェネリックにはできないことももちろんあるけどね) (→ジェネリック: Java vs C#)

#Script 仕様書の新しい草稿版を出した (草稿版 2) んだけど、細かいミスがあったので急遽修正して再び新しい版 (草稿版 3) を出すことに。仕様書に合わせて複素数計算のプログラムも一通り実装した。よって、明日からは構文解析の残りの実装に取り掛かる。

それにしても、今の仕様書は原始実数型の計算の定義が曖昧すぎるなぁ。構文解析の実装が終わったら一通り仕様書に準拠したことになるので、その後 仕様書の強化に移ろう。

今日は #Script/#Calc はお休みにして、mfind をちょっと改造。/M オプションで複数行にまたがる検索を可能にした。

それにしても、「mfind」って google で検索すると一発で出てくるのに Yahoo! Japan だと全然別の検索ソフトが出てくるな……。

検索処理コマンド mfind

UNIX/LINUXの"find"コマンドがMS-DOS環境でも使いたいと思いたち、必要としていた機能のみ抜粋して作成しました。

もう一つの mfind もコマンドライン用検索ツールか。ファイル名検索とファイル内文字列検索の違いはあるけど、やっぱりちょっと紛らわしいかな。一応 mfind の名前を決めたときは他に mfind と名の付くものがないか調べたつもりだったんだけどなぁ。

とりあえず駆動部分の実装は一通り終わった。複素数の計算を除いては。

複素数の計算を実装するには、やはり仕様書をもっと詳しくする必要がある。加減算はともかく、複素数は乗算・除算が実数とは桁違いに複雑なので、厳密に定義しておかないといけない。ということで、今後の計画は

1. 仕様書の改訂
2. 複素数計算の実装 (冪乗計算を除く)
3. 構文解析の実装

実数・複素数の冪乗計算は他の計算とは天地の差があるほど複雑なので、こいつの実装は構文解析の実装よりも更にはるか先になるだろう。というか、冪乗計算には指数関数・対数関数が必要なので、指数対数を実装しないことにはどうにもならない。

教えて! goo でワードで自動的に段落になるのをやめたいという質問を見掛けた。ワードのオートコレクト機能を停止したいという類のこういう質問はよく見かけるんだけど、本当にオートコレクト機能を停止させればそれで万事 OK なのか。

昨日も今日も駆動部分の実装の続き。明日にも一通りの機能を実装し終えられそうだ。

とりあえず今は 1 + 2 * (3 + 4) と入れると 15 と表示できるようにはなった。もちろん二重や三重の括弧も大丈夫。さすがに無限に括弧を入れ子にすることはできないけど (試してみたら五百重強が限界だった)。

とりあえずあさってまでに駆動部分の実装とテストを終えて文の構文解析のほうに取り掛かれるようにできたらいいなあ。

何かココログのサーバーのメンテナンスがあって、その後もいろいろトラブってて結局一日以上ブログが更新できなくなってたらしい。

状況報告ブログのコメント欄ではサポートが悪いだの何だのと大勢のユーザが喧々囂々としてたけど、もう少し静かにできないものなのかねぇ。まあ確かにせっかく状況報告のためにブログを作ったんだから一時間に一回ぐらいは更新して欲しかった気はするが。

一部の有料版ユーザは金返せとか何とか言ってたけど、ココログプラス・プロが有料なのは単にココログベーシックよりも多くの機能が提供されるからであって、別に有料版は無料版よりよいサポートが受けられるなどという契約はなかったはず。これくらいのトラブルでお詫びとして料金が割引になるなどということはないだろうな。そもそも月々千円足らずで手厚いサポートを期待する方が馬鹿だと思うけど。

まあ、他のブログサービスと比べると、ココログはサービスが悪いという気がしなくもないが……。

昨日に引き続き駆動部分の実装。まだまだ先は長い。

ところでいきなり C# の話になるけど、デリゲートには SerializableAttribute を付けるべきなのだろうか? .NET Framework のクラスライブラリのデリゲートは Serializable なものとそうでないものが混在してて、いまいち区別が解らない。とりあえず、デリゲートは全部 Serializable にすることにした。

文の構文解析はおとつい書いたように後回しにして、今日からスクリプトの駆動部分の実装に移る。仕様書を見れば分かるようにかなり込み入っているので一週間ぐらいは掛かりそうだ。焦ると自分でも訳分からん状態になるからここはゆっくりやっていくつもり。

昨日に引き続き今日も式の解析の実装。一応一通りできたということにしておく。(まだどっかに変なバグが残ってるかもしれないけど、一通りチェックしたので大丈夫……だろう。)

構文解析は、再帰下降という方法で行っている。というか、人間が自分の手で構文解析プログラムを書くなら、事実上 再帰下降法しか選択肢はない。もっとも、純粋な再帰下降法だと #Script の構文を解析するのは無理なので、一トークン分の先読みを行いながら解析している。

トークン解析の部分はとりあえず完成した。ので、構文解析に取り掛かる。仕様書にも書いたように、#Script の構文は大まかにいうと式のレベルと文のレベルがある。(そもそも式と文の概念はほとんどのプログラミング言語にあるけど。) とりあえず式の解析プログラムを今書いてるけど、文の解析はかなり後回しにするつもり。まずは一通りの数式を解釈・計算できるようにしたいからね。

鋭意開発中の #Calc は、基本的な数値計算に関するプログラムはもうできていて、今は入力した数式を解釈するプログラムを書いてる。数式の解釈は「トークン解析(字句解析)」と「構文解析」の二つに大きく分かれる。トークン解析のプログラムは大体できていて、仕上げの段階。 スクリーンショットは字句解析の結果を出力させているもの。

間違った数式を入れたときに出すエラーメッセージをいかに解りやすくするかというところがプログラマの腕の見せ所だけど、これがなかなか難しい。「数式が間違っています」だけで済ますこともできるけど、ユーザーにとってはこれだけだとあまり親切ぢゃない。

とりあえず、このブログにはまじかんとで公開しているアプリケーションやスクリプトのことなんかを主に書いていきますよっと。

まじかんとは自分のメインのサイトだけど、細かい記事を頻繁に公開するにはブログの方が便利だろう、ということで。