スラッシュドット・ジャパンで私の日記が参照されたらしく、 プチ・slashdottedである。で、とんびさんから受けたコメント。
>bisonのpure-parserはlexer用にデータを渡せないので、役に立たない。
とありますが、YYPARSE_PARAMとYYLEX_PARAMを定義したのではだめですか。ていうか、これつかって、すっかりreentranthなparser作ったつもりでいたのですが。テストしないとやばいかな。
ダメじゃないです。白状すると1月14日の時点ではYYPARSE_PARAMなどについて知りませんでした。 気がついたのはProthonのソースを読んでた時ですから、 3月の後半くらいでしょうか。
唯一の難点はbisonのinfoを見ると
Macro YYPARSE_PARAM
An obsolete macro for specifying the name of a parameter that `yyparse' should accept. The use of this macro is deprecated, and is supported only for Yacc like parsers.
とあることですかね。「obsolete」と言われても、代替手段がないんですが...。
1週間、コンピュータなしの生活とか、まったく想像ができないなあ。
考えてみると、朝起きて、食事して(時にもう一度寝て)、 そこからコンピュータを開いて、後は通勤のための運転中と、 食事時と夕食後家族で過ごす時間を除いては、 ほとんど毎日コンピュータ(とインターネット)を利用していることになる。 時には深夜・早朝にいたるまで。
休日はだいぶ減るけれども、まったくコンピュータを使わない日はない。 1年365日、毎日平均だと12時間以上はコンピュータの前に向かっているような気がする。
これはもしかすると異常？
「もしかしなくても」という声が聞こえるような気がする。
先週だった息子の誕生日のカードが届いたので(わずかな割引に釣られて)昼食はレストランで。
その後、長女の自転車通学用の自転車を購入。二件目の店で娘があげていた条件全てを満たすものを見つけた。 しかし、「配送がいつになるかわからない」とのことなので、 月曜日に取りに来ることにする。後部座席をたためばうちのミニバンにも載るだろう。
今日の聖餐会のお話しのテーマは「十戒」。
旧約聖書の基本的な戒律だから、 基礎中の基礎という感じだが、改めて学んでみると奥が深い。 うちの妻を含めて3人の人がお話をした。 あ、私もちょっとだけ話したから4人か。
十戒はネガティブな表現(〜してはならない)ばかりだが、 実際にはもっとポジティブな適用が可能だとか、いろいろ。
その中で一番印象深かったのは、 大学で音楽を専攻していた宣教師の言葉。
音楽というものにはただひとつの正解はない。
正解はないけど間違った答えはある。和音など音楽理論のルールに従わない音楽は不快なものとなる。 そのルールに従った範囲内で無限の創造性が発揮できる。
戒めも制約のようにみえるかもしれないが、 それに従いつつ「自由」と「幸福」を得ることができる。
細かい表現は忘れちゃったけど(特に最後の方)、内容はこんな感じ。
制約の中での自由にこそ意味があるってのは言語デザインも同じだなあ。
夕方、末娘を連れて散歩をしていたら、 裏の家のご主人に会う。
もう引退されたこのご主人とは散歩のときにしょっちゅう会うのだが、 先日は米子出身でソフトウェア関係の仕事をしているなんて話をした。
そしたら、今日
米子で松本さんと言えば、Ruby言語を作っておられる方が松本さんとおっしゃるが。
ですって。ビンゴ。
はあ、それは私です
なんとご近所の人からそんなことを言われるようになる日が来るとは 夢にも思わなかったよ。それも「米子の松本さん」の代表格になるとは*1
なんでもBASICなどではプログラミング経験があり、 以前Rubyの本(『オブジェクト指向スクリプト言語Ruby』かな？)を買ったが、 まだ積ん読状態なのだとか。
うーむ。
*1 米子近辺は特に松本姓が多い土地なのだ
Second Annual Silicon Valley Ruby Conferenceでは、 Rubyプログラマへのリクルーティングが盛んであった、という話。
日本でもそういう傾向は見えつつあるが、 まだ、「Rubyプログラマ優遇」とか「高給保証」とか、そこまでは届いていない。
つか、そういうところまで持っていきたいものだ。 待遇改善には原資が必要である。
DATE 2007カンファレンス(EDA関連の最大のカンファレンス、EDAってなに？)で感じたこと。
システムの規模が大きくなるにつれ、挙動と性質が変化しつつあるということだと思う。 賛成する。
「Pat Eylerのブログコンテスト」、４月のテーマは「未来のRuby」。
What Changes would make Ruby a better language without making it into something that isn't Ruby?"
Rubyを「Ruby以外のもの」にすることなく、Rubyを良くするアイディアについて。
最優秀の人にはApressから好きな書籍をもらえる。
気がついたのが遅かったので(もう月末までわずかしかない)現時点でも結構集まっている。
中には明らかにRubyらしさを失うものも(optinal static typingとか)あるが、 耳を傾けるべきものも多い。が、interpreter lockなしのnative threadingとか、 気持ちはわかるが、実装は無理なんじゃないかと。
Gambit-Cのネームスペースについて。
(namespace ("f#" foo) ("b#" bar baz))
と宣言しておくと、そこから、fooはf#fooに、barはb#barになるので、 ライブラリのロード前にnamespace宣言しておく、というもの。
簡単で、ある程度効果的なのは認めるけど、なんか違和感がある。
Smalltalkの新しいオブジェクトシステム。 Squeakの「フォーク」だから「スプーン」という名前付け。うーむ。
クラスのアンロードができるため、とても小さなメモリイメージを作ることができる のが特徴だとか。実際、最少のイメージは1,337バイトだとか。小さい。
「なぜLispは違うのか」。
CやJavaの観点からLispを見ているんだと思う。 「悪い」と言ってるわけでなく、「違う」と言ってるところが重要なんだろうな。
しかし、これらの指摘の一部は実は動的言語でも共通なわけで、 それが別に問題になってないように見受けられることを考えると これらの違いの多くはさほど問題ではないということだと思う。
とすると、...やっぱり括弧か。
京セラが極端な違いはないのにやっぱり強い、そのことは素晴らしい、という話。
理想的な態度だ。 細部の細かな使い勝手の蓄積によって全体的な強さが構築できるということなのだろう。
Rubyもどこが良いのか言語化できないのに強いというのと 似た性質である....のだといいな。