kiyoka::* kiyoka [img] オープンソース系好奇心先行型プログラマ。関数型プログラミングにハマりぎみ。

kiyoka — 27 Jul 2009 14:39:35 +0000

kiyoka [img]  オープンソース系好奇心先行型プログラマ。関数型プログラミングにハマりぎみ。
 English page is here kiyokaE
[img]      (似顔絵イラストメーカーで作りました)
 
ブログはこちら !kiyoka.blog
 [img] 
 
プロジェクト
- Sumibi ( 新感覚日本語入力メソッド )
    
- OldType ( OldTypeのためのWikiシステム。GaucheベースのWikiClone )
    [img] 
- R@eply.org ( iモードメール専用Webリーダー )
    
- Predoc ( 軽量ドキュメントフォーマット )
    
- TzWatch ( Lingr用の時刻表示アプリ )
    
- Oneliner ( Emacs shell mode )
- Cmmi (configure ; make ; make install)
- Sxmlcnv (SXML <-> XML)
- WhatsNewプロジェクト (WebSite 変更箇所表示プログラム)
- Sewnn (Simple eWnn Client)
- Emulin (Javaで記述したLinux Emulator)
 
ドキュメント
- OldType.プレゼン資料.GaucheNight2008
    [img]  [img]  [img]  [img]  [img]  [img]  [img]  [img]  [img] 
- 世界の果てから漢字変換 Sumibiの開発 2006(jus関西での講演資料)
    
- Jcodeを使おう (Kansai.pmでの講演資料)
- perl.TMTOWTDIの謎を探る
    [img] [img] 
- Emacsカスタマイズ入門 (LILO LMSでの講演資料) /『PDF版』
- 軽量ドキュメントフォーマットPredocの紹介(LILO LMSでの講演資料)
 
日記など
- !kiyoka.blog
- kiyoka at WiLiKi (WiLiKi上に書かせてもらっているページ)
 
プロフィール
- 西山 清香 (Kiyoka Nishiyama)
- email:kiyoka at sumibi.org ( at を @ に読みかえて下さい )
- mixiID: kiyoka
- hatenaID: id:kiyokap
- github.com: kiyoka's Profile - GitHub
 
その他
- 猫: kiyoka.ささみ
    [img] 
 
よく出没するチャットルーム等
- [lingr]

OldType::オールドタイプのためのWikiシステム。GaucheベースのWikiClone。

kiyoka — 17 Nov 2008 11:35:54 +0000

オールドタイプのためのWikiシステム。GaucheベースのWikiClone。
UNIXのミニマリズムをWikiに応用したもの。CodeReposで開発中。
 
[img] 
 
特徴
- Subversionでコンテンツを管理する。
- 大量の更新はSubversionで、少量の更新はWebから行う。
- プラグインの開発が簡単に行なえる。
 
目次
- OldType
- OldType.書式
- OldType.書式サンプル
- OldType.開発の経緯
- OldType.デザインメモ
- OldType.アイデア集
- OldType.バッチ処理プラグイン
- OldType.バッチ
- OldType.パーサ
- OldType.Webから更新
- OldType.アカウント管理
- OldType.セットアップ
- OldType.案の検討
- OldType.連携できそうな外部ツール
- OldType.TODO
- OldType.DONE
- OldType.リリースノート
- OldType.プレゼン資料.GaucheNight2008
- oldtype-mode
- oldtype-mode.インストール
- oldtype-mode.基本操作
- oldtype-mode.応用
 
会議室
- OldType.会議室.2008年.1

OldType.プレゼン資料.GaucheNight2008::GaucheNight 2008でのライトニングトークのプレゼン資料です。

kiyoka — 10 Mar 2008 11:52:20 +0000

GaucheNight 2008でのライトニングトークのプレゼン資料です。
2分30秒でこのスライドを使って、残りOldTypeサイトを使ってコンテンツ更新のデモをしました。
当日見れなかった方のために、雰囲気を感じられる様に紙芝居にしてみました。
 
- 表紙
[img]  オールドタイプ向けWikiエンジンを紹介します！
- テーマ
[img]  テーマはこれ
- 定義の確認
[img]  オールドタイプの定義はこれ。こんなイベントに来る人はたぶんみんなオールドタイプだよね。
- これまでのWikiの問題1
[img] 
- これまでのWikiの問題2
[img] 
- オールドタイプの定理を使え
[img]  オールドタイプにはオールドタイプなりの冴えたやり方があるんじゃないか？
- 結論1
[img]  そうだ、バックエンドDBのSubversionを直接編集すればいい
- 結論2
[img]  そして開発したのがこれ。OldType。
- デモ
[img]  それではデモやりまーす。
- 最後に
気にいった人はアカウントを取ろう。
# OldTypeサイト.アカウント申請方法
# OldTypeサイト.Subversionで更新

perl.TMTOWTDIの謎を探る::TMTOWTDIの謎を探る(調査報告：単純さと複雑さの関係とは？)

kiyoka — 17 Jul 2008 14:59:57 +0000

TMTOWTDIの謎を探る(調査報告：単純さと複雑さの関係とは？)
 
 この資料は、オリジナルは2002/05/10にkiyokaが書いた文章で、OldTypeに移してリンク切れ等をメンテナンスしたものです。
 オリジナル:TMTOWTDIの謎を探る(調査報告：単純さと複雑さの関係とは？)
 kiyokaはこの少し後にPerlに影響を受けた処理系Gaucheと出会い、Gaucheをメインに使っています。
 
イントロダクション : 調べようと思ったきっかけ
-  Perlって他のコンピュータ言語よりもなんか複雑じゃない？
個人的にはC言語よりもスラスラ書けるようになるまでの時間が長かったように思う。
- それは、Perlの言語設計の哲学と関係があるんじゃないか？
そういえば TMTOWTDIと関係がありそうだ。調べるてみるとやっぱり関係ありそうだということになった。
- TMTOWTDIというPerlのスローガンの本質が世間で理解されているんだろうか？
(少なくとも僕は、調べるまで本質を知らなかった。)
- 調べて、自分なりの結果を発表してみよう。
違うと思った方は、つっこみお願いします。
 
結論 : スローガンTMTOWTDIの本質って？
皆さん、TMTOWTDIがThere's more than one way to do itの略だということは御存知だと思います。「やり方はひとつではない」というスローガンです。
Perlの世界ではcoolとされている哲学をスローガンとして掲げたものです。
 
シンプルなほうが良いんじゃないの？
Q.でもなぜ？やりかたが少ない方がシンプルで良いんじゃないの？
- A.それが違うようなのです。
Perlの設計者のLarry Wallは言語はいろんな対象をシンプルに記述するためには言語をある程度の複雑を持っている必要があると信じています。
次のような文章を見つけました(オープンソースソフトウェアという書籍からの引用です「努力、忍耐、謙遜」の章)
 「我々がよく知っていることだが、現実とは乱雑な状態を指す。実際、人類の
 言語が複雑なのは、それが現実を扱わざるを得ないためである。」
(略)
 「そしてPerlは、それを可能にさせてくれる新しいツールなのである。私が英
 語を使って現実を単純化できるのは、英語が乱雑な言語だからである。英語は
 乱雑だからこそ、我われが現実と呼ぶ、これまた複雑な世界をうまく描写する
 ことができる。同じように、Perlも(できるだけ精密なやり方で) 乱雑になる
 ように設計されている。」
なるほど、スローガンTMTOWTDIの本質はここにあったんですね。
解説 : 僕なりにかみくだいてみました
「さっきの例え話はわかったけど、もうちょっと説明してよ。」という方のために次のようなグラフを作ってみました。
得意分野を扱った場合
まず、それぞれの言語が得意とする分野の問題を記述した場合。これは、言語の設計者が意図した使い方の範囲に収まった問題とも言えるよね？
[img] 
 
この場合、どの言語もたいして複雑にならないということは分かるよね？
だって、それぞれの言語は最初は、ある特定の問題を記述するために設計したはずだから。
 
現実を扱った場合
それぞれの言語が得意かどうかにかかわらず、その言語でいろんな問題を記述しなければならない場合。つまり現実に対処しなければならない場合ね。
これは、言語の設計者が想定していた範囲を大きく超える問題を扱った場合とも言えるね？
例えば、tclやBASICで文字列のパターンマッチングやリスト処理やデータフォーマット変換なんかをやろうと思ったらキツいのは想像できるよね？
でもそれをやらないといけない状況が発生したと仮定すると？
[img] 
 
なんとなく理解していただけましたか？
Perlのコードを日々書いている方は、Perlがどんな問題を扱うにしてもそこそこの許容範囲のコードで解決できることは経験的に知っているはずです。それって cool ですよね？
また、母国語(日本語) ならもっと、扱える範囲が広いことも知っているはずです。身近な例で言うとマイクロソフトなんかは強力な「それは仕様です」というコードを持っていますからね。これは Perlでは書けないですが、母国語ならシンプルに書け、扱う範囲の大きさもかなり広いです。(極端な例かもしれませんが...)
母国語は真の言語だけれどもPerlもなかなか良い線いっているんじゃないかな？
 
まとめ : TMTOWTDIはカッコいい
TMOTOWTDIのスローガンはなんとなくカッコいいと思っていたけど、これでカッコよさの意味がわかってきました。
Rubyにもこの哲学は引きつがれているので、Rubyも同じ考えかたが通用するのはうれしいですね。
TMOTOWTDIはカッコいいんです。自信を持ってカッコ良さを自慢しましょう。
 
参考資料
書籍等の資料
- 書籍名: Perlプログラミング第3刷
 著者:Larry Wall and Randal L. Schwartz
 訳者:近藤嘉雪
-- 「はじめに」iiiから引用
 「そして、ある操作を行なう方法がただ１つだけ存在すべきだと信じるミニマ
 リストにとっては、Perlはまるで悪夢のように冗長で派生的であると感じられ
 るかもしれない。ともかく、UNIXのミニマリズム的なツールボックス哲学の枠
 から大きく踏み出すことによって、Perlは小規模から中規模の仕事に最適なツー
 ルとなり、再びツールボックスにしっくると収まるようになった。Perlは、新
 しいツールを作り出す工具職人の作業台であるということができるだろう。」
(略)
 多くの面で単純である反面、Perlが奥の深い言語であるのもまた事実であり、
 学ぶべきことは山ほどある。Perlの全能力を自分のものにするためにはかなり
 の時間がかかる。」
-- P12から引用
 「いずれにせよ、あなたの好きなように書けばよい。もしあなたがＣ言語に通
 じていて、その上でPerlを学ぼうというのなら、あなたの書き方はシェルスク
 リプトやBASICやRPG IIから入った人とは違っていることだろう。それでいい
 のだ --- 他人があなたと同じ書き方をすると期待してはいけない。Perlには
 *正しい*書き方というものは存在しない。Perlは、多様性に関してきわめて寛
 容な言語である。(Perlのスローガンを思い出そう) --- Perl の世界では、ま
 あまあ読めて、ボスにクビにされないうちに仕事を片づけられるものが*正し
 い*プログラムなのである。」
 
ネット上の資料
- 以下ラリー・ウォールの章「努力、忍耐、謙遜」からの引用
 我々がよく知っていることだが、現実とは乱雑な状態を指す。実際、人類の言
 語が複雑なのは、それが現実を扱わざるを得ないためである。我々はみな、な
 んとかして現実に対処しなければならない。そこで、物事を単純化して考える
 のだが、単純化しすぎることがよくある。コピュータ言語の設計者の多くは、
 言語を単純化しすぎて、この世の複雑なところの面倒をすべてプログラマに押
 し付けている。実は、あなたの脳はPerlをプログラミングするようにできてい
 るのである。私はたったいま英語を使って現実を単純化しようとしているが、
 人は誰でも複雑なことを単純にしたいという強い要求を持っている。そして
 Perlは、それを可能にさせてくれる新しいツールなのである。私が英語を使っ
 て現実を単純化できるのは、英語が乱雑な言語だからである。英語は乱雑だか
 らこそ、我われが現実と呼ぶ、これまた複雑な世界をうまく描写することがで
 きる。同じように、Perlも(できるだけ精密なやり方で)乱雑になるように設計
 されている。 Perlのカルチャーでは、ほとんど何も禁止されていない。この
 世はすでに禁止事項であるれている。
 
- Rubyのまつもとさんのセッションの記録より
(本資料はリンク切れで探しきれませんでした。Wikipediaには、下記のような文章はもうありません。まつもとさんの昔の定義だと思われます)
Ruby哲学
## UNIX主義
## 簡単なことは簡単に、難しいことは可能に
## やり方はいろいろある
 
- 真・コンピュータ用語辞典
以下引用
 てぃむとぅでぃTMTOWTDI
 【法則・真理】There's More Than One Way To Do It.
  - 「それのやり方は色々ある」と、Perlで使われるスローガン。
  - 多くの場合、この法則を当てはめる事が出来る。が、メーリングリストな
    どで質問はしたものの、「自分の『「期待する回答』が一つだけ、ポコっ
    と出てくる事」を期待して待っている人間にとっては酷な事。
  - つまり、「複数の選択肢からの制約・状態に応じた最善策の判断」を否定
    し、新たな価値観を取り入れる余地も気も無く、伝承に基づいた価値観を
    唯一の拠り所とする事で、自己の存在を保っている人間には、永遠に理解
    できないものであろうもの。
 
- 英語がわかるスクリプト言語『レボル』 | WIRED VISION
以下、上記URLから引用
 Perlの作者、ラリー・ウォール氏は、レボルを、役に立つことを実行する「ま
 た他のやり方」だとみている。「私は、選択肢が多いことはいいことだと言っ
 ている。Perlのスローガンは、それをやるには他のやり方もある、というもの
 だ。レボルが役立つものにはレボルで、Perlが役立つものにはPerl でという
 具合に使われると素晴らしい。どうすれば両者が連係できるか、調べてみたい」
 と言う。
 
- Natural Language Principles in Perl (ja)
Perlの設計哲学が書かれています。さすが言語学者の視点です。
 
コメントお願いします。
[comment]

!kiyoka.blog::kiyoka日記。OldType、Sumibi.org、日々の出来事など。

oldtype — 15 Mar 2010 11:23:53 +0000

kiyoka日記。OldType、Sumibi.org、日々の出来事など。
最新10件!kiyoka.blog   過去記事一覧!kiyoka.blog.list
[img]  
 [feedmeter] このブログを書いている人: 西山 清香(kiyoka) [img] 
                           (似顔絵イラストメーカーで作りました)
 
 
kiyoka.2010_03_15[Life] 週3日のプログラミング
月水金と子供を保育所に預けている間、リハビリも兼ねてカフェでプログラミングしている。
 
1日4時間程度使えるので、思いのほか進捗がよろしい。
しかし、オレ言語みたいな 浮世離れしたプログラミングしていていいのかなぁ。とは思うけど。
リハビリにしては不必要に技術レベルが高いのに、実用からは外れているという…
どこかで実用に近いプログラミング演習にも合流予定なのではあるが…
 
comment please => kiyoka.2010_03_15
 
 
kiyoka.2010_03_06[Nendo] named letをmacroで実装した
私がRubyで書いているLisp方言、 Nendoについて。
 
これまで、Nendoではlet等の予約語はマクロを束縛すると正しく展開できない実装だったが、ついに予約語と同名の変数にマクロを束縛しても動作するようにした。
そうすることで、例えば named let をmacroで定義できるようになった。
;; named letのサポート
(define let
  (macro lst
    (if (symbol? (car lst))
        ;; named let
        `(letrec ((,(first lst)
                   (lambda ,(map
                             (lambda (x)
                               (first x))
                             (second lst))
                     ,(third lst))))
           (,(first lst)
            ,@(map
               (lambda (x)
                 (second x))
               (second lst))))
           
        ;; don't touch
        `(let ,@lst))))
 
なぜこれをできるようにしたかというと、処理系全体のソースコードがコンパクトになる方向を目指しているためだ。
一般的にS式のmacroはソースコード規模を圧縮する方向に作用するため、Rubyで実装するコアはシンプルな構文のみに抑え、Lispのmacroを多用して構文を拡張した方が有利になるからだ。
Rubyではコード圧縮に限界がある。
 
Rubyで『named letの機能を持たない基本的なlet』と『letrec』に対応するコード生成機能が有れば、named letをNendoのmacroで記述できる。
例えば、下記のnamed letのサンプルコードは上のマクロで解決できる。
 
 展開前
(let1 total 0
  (let loop ((cnt 10))
    (if (< 0 cnt)
        (begin
          (set! total (+ total cnt))
          (loop (- cnt 1)))))
  total)
 
 展開後
(let ((total 0))
  (letrec
      ((loop (lambda (cnt)
               (if (< 0 cnt)
                   (begin (set! total (+ total cnt))
                          (loop (- cnt 1)))))))
    (loop 10))
  total)
 
 実行結果
55
 
恥を晒すと、本当はSchemeのdefine-syntax相当をサポートしてそれで定義するのがまっとうな方法かも知れないが、まだそこまで自分の力量が足りていないというのが正直なところ。
しかし、これまで実際にLisp処理系を実装するのは本当に勉強になると実感した。
やればやるほど、Lispの奥深さが少しづつ感じ取れる様になった。(オマケとしてRubyにも詳しくなったし…)
Lisp系言語を本当に習得したいという人は一度は自分のLisp処理系を実装してみることをおすすめするぞ。
 
comment please => kiyoka.2010_03_06
 
 
kiyoka.2010_03_02[Nendo] set!の実装につまづく(3) =>解決
私がRubyで書いているLisp方言、 Nendoについて。
 
先日の記事 (kiyoka.2010_02_22『set!の実装につまづく(2)』)の続き。
 
問題のバグを修正し、各々のset!に対応するRubyコードを正常に出力できるようになった。
shiroさんのコメントにあったように、LispのコードをRubyに変換する処理において、サブフォームに再起して行く際にローカル変数のリストを渡していく方法で簡単に実装できた。
set!の第一引数の変数名がローカル変数リストにヒットすればRubyのローカル変数を使用し、ヒットしなければRubyのインスタンス変数(Lispのグローバル変数の代替品)を使う実装にした。
このバグ修正をする前作業として、インデント付きのRubyコード生成を生成するようにしたので見やすくなった。
そのままコードを貼りつけて解説する。
 
-- グローバル変数の更新
Nendo:
(define a-global-var 1)
(set! a-global-var 10)
生成コード(Ruby):
  @_a_global_var = 
    1
  @_a_global_var = 
    10
 
-- ローカル変数の更新
Nendo:
(let ((a-local-var 2))
  a-local-var)
生成コード(Ruby):
  begin
    ___lambda = lambda { |_a_local_var| 
        begin
            _a_local_var
          rescue => __e ; __e.set_backtrace( ["(stdin):126"] + __e.backtrace ) ; raise __e
        end
    } ; ___lambda.call(
        2
               )
  end
 
-- グローバル変数とローカル変数の混在
Nendo:
(define a-global-var 1)
(let ((a-local-var 3))
  (set! a-global-var 20)
  (set! a-local-var 4))
生成コード(Ruby):
  @_a_global_var = 
    1

  begin
    ___lambda = lambda { |_a_local_var| 
        @_a_global_var = 
          20
        _a_local_var = 
          4
    } ; ___lambda.call(
        3
               )
  end
 
明日は、内部defineをletrecに変換するコンパイルフェーズをNendo自身で書いてみよう。
 
ところで、実際にSchemeの仕様書を読みながら実装してみると、Schemeの仕様があまり何も規定していない実装自由度の高い仕様であることが分かる。
なので、どのような用途を狙うかによって、処理系ごとの規模の振れ幅は大きいだろうなと思う。
例えば、小さなフットプリントを狙うのか、処理系のソースコード規模最小限を狙うのか、高速な処理系を狙うのかなどで全く違った実装になる。
Schemeの処理系の数が余りにも多いのも頷ける。(tinyschemeとかchibischime、GaucheとかMoshとか色々ある)
 
comment please => kiyoka.2010_03_02
 
 
kiyoka.2010_02_27[Nendo] letrecを実装した
私がRubyで書いているLisp方言、 Nendoについて。
 
やっとletrecを実装した。1時間半位で実装できた。変換処理はRubyで実装している。
SchemeのR5RS仕様書に内部defineはletrecに変換可能と書いてあるので、Nendoも同じ仕様で実装しよう。
やっぱりリスト処理はRubyよりも、Lisp系言語の方が書きやすいので、そのコンパイルフェーズはNendo自身で書きたい。
もっとよく考えていけば、Nendo自身で書ける部分も増えそうだけど、鶏が先か卵が先かというような、複雑な依存関係が増えそうな危険な香りもするのでちょっとずつリファクタリングする方が良いかな？
 
ちなみに、もしやと思ってGauche 0.9のcompile.scmを見てみたら、Gaucheも内部defineはletrecに変換しているようだ。
やっぱり、早めに内部defineは消しておき、letrec 1本に収束させた方が綺麗だからだと思う。
 
comment please => kiyoka.2010_02_27
 
 
kiyoka.2010_02_22[Nendo] set!の実装につまづく(2)
私がRubyで書いているLisp方言、 Nendoについて。
 
先日の記事(kiyoka.2010_02_21『set!の実装につまづく』)の続き。
shiroさんのコメントで間違いを御指摘いただいたのと、問題点がうまく記述できていなかったため、もううちど原点に戻って整理しよう。
 
Nendoの設計方針
# クロージャのレキシカルスコープ等の管理はRuby処理系まかせにする
NendoではLispコードを等価なRubyコードにトランスレートすることで、クロージャのローカル変数(=レキシカル変数)のスコープ管理を全てRuby本体の機能にまかせることにする方針。自分で書くよりも、コード量が削減できるし、Ruby VMの最適化の恩恵にも浴することができるのではないかというのが狙い。
(クロージャのレキシカル変数がちゃんと動くようになったのはRuby 1.9.1からです。昔のRubyでは挙動が違うことに注意)
 
# Rubyのインスタンス変数とローカル変数の両方を使う
Schemeのグローバル変数に相当するものをRubyのインスタンス変数 (Rubyでの表記は@var) に割当て、Schemeのローカル変数に相当するものを、Rubyのローカル変数 (Rubyでの表記はvar)に割りあてる方式でやることにした。
当初、Schemeのグローバル変数の機能もRubyのローカル変数だけで代用できるのではと思ったが、Rubyのローカル変数はRubyのコード実行時に割当てが決まるのではなく、Rubyコードのコンパイル時点で割当てわれてしまうため、コンパイル時に未定義の変数は永遠に未定義のままとなる。
これでは、トップレベル関数の相互呼出ができないとか、replでトップレベル関数の差し替えなどもできないという問題がある。
[実験コード]
  1  #!/usr/local/bin/ruby
     
     #
     # Rubyのローカル変数に割当てたクロージャは、pre-definedでないと呼出せない。
     #
     def test1
       proc1 = lambda {
         p "proc1(1)"
       }
       proc2 = lambda { # <--- entry point
         p "proc2(1)"
         proc1.call()
         p "proc2(2)"
 14      proc3.call()
         p "proc2(3)"
       }
       proc3 = lambda {
         p "proc3(1)"
       }
       
       proc2.call()
     end
     
     test1()
 
[実行結果]
14行目でproc3が未定義になる。(NameError例外)
"proc2(1)"
"proc1(1)"
"proc2(2)"
local_variable_test2.rb:14:in `block in test1': undefined local variable or method `proc3' for main:Object (NameError)
        from local_variable_test2.rb:21:in `call'
        from local_variable_test2.rb:21:in `test1'
        from local_variable_test2.rb:24:in `'
 
補足として、test1()メソッドの入口でproc3 = nilとしておくと、上のエラーは回避できるが、Lispのrepl上では未来にユーザーがどのような変数を使うかは神のみぞ知るなので、ここでは使えない。
 
set!の実装方法
set!の代入対象の変数がローカル変数か、グローバル変数か、はたまた未定義かを生成後のRubyコードで動的に判断させる方法を最初に試したが、ダメだった。
例えば、(set! a 2) をRubyに変換したイメージを下記に示す。これではうまくいかない。
      begin
        if defined?(a) == "local-variable"
  3       _a = 2     # local variable
        elsif self.instance_variables.include?(:@_a)
  5       @_a = 2   # global variable
        else
          raise NameError
        end    
      rescue => __e
        raise __e
      end
 
前回の記事 (kiyoka.2010_02_21『set!の実装につまづく』) でも書いたように、Rubyのローカル変数の代入は非常に特殊で、if false then  a = 2  end の様に例え実行されなくても、それ以降は ローカル変数 a が『宣言』されたことになってしまう。(前回の記事で『ブロック内のどこかに代入が記述されただけで(実行されなくても)、ローカル変数が宣言されたことになってしまう。』と書いたのは私の勘違いでした…すみません)
 
例えば、上の実装イメージでset!が連続で記述されたら1回目と2回目の set! の挙動が変わってしまうだろう。(たぶん、1回目はグローバル変数を更新し、2回目は新しく宣言したローカル変数を更新する挙動になるだろう)
(define a 100)
(set! a 2)
(set! a 3)
 
下記の実験コードで試してみよう。
[実験コード]
      #/usr/local/bin/ruby
      
      def local_variable_test
        func1 = lambda {||
          print "  ---- (1) ----\n" 
          begin
            print "a               : " ; p a
          rescue NameError
            puts "NameError(1)"
          end
          print "defined?(a)     : " ; p defined?(a)
          print "local_variables : " ; p local_variables
 13       if false
 14         a = 1     # assign
 15       end
      
          print "  ---- (2) ----\n" 
          begin
            print "a               : " ; p a
          rescue NameError
            puts "NameError(2)"
          end
          print "defined?(a)     : " ; p defined?(a)
          print "local_variables : " ; p local_variables
          if false
            a = 1     # assign
          end
        }
      
        func1.call()
      end
      
      local_variable_test()
 
[実行結果]
bash$ ruby local_variable_test.rb
  ---- (1) ----
a               : NameError(1)
defined?(a)     : nil
local_variables : [:a, :func1]
  ---- (2) ----
a               : nil
defined?(a)     : "local-variable"
local_variables : [:a, :func1]
 
func1の ---- (1) ---- と ---- (2) ---- 部分は同じコードの繰返しなのに、13,14,15行目の実行されない代入が登場するとそれ以降ローカル変数a はNameErrorにならない。
Rubyの仕様ではローカル変数が宣言されるとnilが代入される様だ。(今回の問題には関係ないけど、local_variablesメソッドの出力結果が defined?(a)の結果と対応していないのが変だが、それは気にしないでおこう。Rubyのバグかな？)
 
まとめ
このように、たとえ実行されない代入文でも宣言となる仕様では、set!に対応するコードをRubyで動的に切りかえる事はできない。
よって、前回の記事でも書いた様に、LispからRubyへの変換時にその時点での対応するRubyコードに切りかえて出力しないといけない。
 
今回のset!対応は生成Rubyコードを人間に見やすくインデントするリファクタリングをやった後にやろう。
 
comment please => kiyoka.2010_02_22
 
 
kiyoka.2010_02_21[Nendo] set!の実装につまづく
私がRubyで書いているLisp方言、 Nendoについて。
 
ちょっと作業する時間があったので、set!をSchemeの仕様に近づける修正にトライした。
つまづいたので備忘録として記事にしておく。
 
 
方針
方針としては、Schemeのグローバル変数に相当するものをRubyのインスタンス変数 (Rubyでの表記は@var) に割当て、Schemeのローカル変数に相当するものを、Rubyのローカル変数 (Rubyでの表記はvar)に割りあてる方式でやることにした。
 
LispからRubyへのトランスレートにおいて次の様なコードを吐く様にした。
(以下は原理を簡単にする為に、実際にNendo処理系が出力するコードを簡略化してある。一応動く)
 
- トランスレート前のLispコード
(define a 100)
(let ((a 1))
  (set! a 2))
 
- トランスレート後のRubyコード
    #/usr/local/bin/ruby
    
    @_a = 100
    lambda {|a|
      begin
  6     if defined?(a) == "local-variable"
          puts "(1)"
  8       a = 2     # local variable
        elsif self.instance_variables.include?(:@_a)
           puts "(2)"
 11        @_a = 2   # global variable
        else
          raise NameError
        end    
      rescue => __e
        raise __e
      end
 18   p local_variables
    }.call(1)
実行結果
ruby localvar_test.rb 
(1)
[:a, :__e]
 
どこがダメか
上記のコードでは11行目が実行されるかと思いきや8行目のほうが実行される。
ローカル変数 a が8行目で宣言されてしまうので、6行目の判定は定義済となってしまうのだ。
Rubyのローカル変数の代入は非常に特殊で、ブロック内のどこかに代入が記述されただけで(実行されなくても)、ローカル変数が宣言されたことになってしまう。
 
 変数と定数 - Rubyリファレンスマニュアルの引用
   宣言は、例え実行されなくても宣言とみなされます。
   v = 1 if false # 代入は行われないが宣言は有効
   p defined?(v)  # => "local-variable"
   p v            # => nil
 
手ぬきの代償
NendoではLispコードを等価なRubyコードにトランスレートすることで、クロージャが持つローカル変数のスコープ管理などを全てRuby本体の機能にまかせるという前提だったのだが、上記のやりかたでは十分でないということになる。
Schemeのset!と等価なローカル変数の代入を実装するためには、そのローカル変数が定義済かどうかの判定を生成されたRubyコード自身にやらせるのでは遅すぎるということだ。
 
対策
Rubyへトランスレートする前のLispコード(S式)の段階でレキシカルスコープの解析を行い、それぞれのset!が出現した場所でそのローカル変数が定義済かどうかを判定して、各set!に対応するコードを動的に切りかえる。
多分これで実現できるだろう。
 
感想
Rubyのローカル変数の代入と宣言の仕様は、なかなか微妙な仕様だと思う。
Schemeが define(定義) と set!(代入)の役割をはっきり分離しているのに対して、Rubyはそこを分かちがたく統合してしまっている。
そこには、Rubyなりの設計方針でそうなっているのだとは思うが、Schemeと比べるとスッキリしないなあ。
Rubyの『驚き最小の法則』というのを昔聞いたことがあるが、今回のは個人的にちょっと驚いた。
というか、せめて宣言と代入を分離する手段も用意しておいてほしかったぞ。
 
 参考: yugui wiki - 『初めてのRuby』余った切れ端
 yuguiさんの見解が書かれているページを見つけた。
 
  初期値 (6章余り)
  Column: 初期値
 (略)
  Ruby文法は妥協と折衷、損益判断により構成されています。Ruby文法がなぜ
  Aであるかを調べると、いつも「Bにするだけの価値があるか」という点が浮
  かび上がってきます。変数は基本的に代入による初期化を必須にする方針の
  一方で、インスタンス変数とグローバル変数についてはアクセス可能なコー
  ド範囲が広すぎて初期化を強制するには弊害が大きすぎたのだと考えられま
  す。
 
----< shiro >----
rubyの仕様はまだよく理解できてないですが、このコードに限ればdefined?(a)がlocal-variableになるのはlambda式の仮引数が|a|になってるからじゃないでしょうか。試しに lambda {|z| ...} に変えてみたら11行目の方が実行されました。
仮引数が|a|なのは (let ((a 1)) ...) だから、ということなら、8行目の方が実行されるのが正しいですよね。

ただまあ、Schemeコードを処理する時に変数がローカルかグローバルかを判定するのはごく簡単なので (サブフォームに再帰してゆく時にローカルの変数リストを渡して行くだけ)、そうしてしまった方がうんと楽だとは思います。あと、その時点でset!に対応するコードを切り替えるのは、「動的」とは言わないと思います。コードそのものの実行時じゃないから。
----< kiyoka >----
shiroさん、コメントありがとうございます。
ご指摘の通り、上記の実験に致命的な間違いがありました。
この記事での問題点の記述も微妙にずれております。
再度、問題点を整理して次の記事にしてみます。
ただ、解決方法はshiroさんのコメントのように、サブフォームにローカル変数のリストを渡す方法でいけると思います。
また、Rubyコード生成時にset!のコードに対応するRubyコードに切り替えるのは、どちらかというと「動的」でなくて「静的」ですかね。

comment please => kiyoka.2010_02_21
 
 
kiyoka.2010_02_20[本] プログラミングClojureを読む(その2)
   プログラミングClojure: Stuart Halloway, 川合史朗
[目次]
- 第1章 Getting Started
- 第2章 Clojureひとめぐり
- 第3章 ClojureからJavaを使う
- 第4章 シーケンスを使ったデータの統合
- 第5章 関数型プログラミング
- 第6章 並行プログラム
- 第7章 マクロ
- 第8章 マルチメソッド
- 第9章 現場のClojure
やっと、最後まで読めた。
じっくり読むために、1歳半の子ををいろんな施設にあづけている時間に読んだので、それにかかった金額は1万円くらいか。
それに比べると、本の購入金額なんてあって無いようなもんだな…
独身とか学生の方々は時間のある今のうちにいろいろ好きなことをしておく事をオススメする。
 
それはさておき、感想を。
ClojureはJVMと心中することで本気のプロジェクトにも使えるLispだと感じた。
SchemeやCommon Lispに慣れている人からすると、quoteやquasiquoteの記号が違っていたり、再帰のコーディングには気を付けないといけなかったりでちょっと勝手が違う所も有るだろうけど、やはりS色とマクロが揃っているので、本質部分はLispだ。
全体を通してClojureのデザインのうまい所は、参照透過な部分とそうでないコード(副作用を持つコード)を意識して分離できる仕組を全部そろえている所だと思う。
さほど意識しなくても純粋な部分を明確に意識して保護できる。(Haskellが純粋関数型言語ならClojureは高純度関数型言語か)
それを達成するために、処理系にはSTMやMVCCが組込まれていたり、データ構造の隅々までシーケンスで包みこんであったり、かなりの力が入っている。
やっぱり処理系がここまでしてくれれば、関数型プログラミングのメリットが十二分に発揮できるし、安心して関数型プログラミングができそうだ。
一般的にこの手のマイナー言語だが重要な書籍は原書(英語)でしか読めないところを、重要な本を日本語に翻訳して下さったshiroさんに感謝。
 
comment please => kiyoka.2010_02_20
 
 
kiyoka.2010_02_07[育児][Life] 育児と生活と
自分の時間がなかなか取れなくてキビシイ状態が続いています…
 
現在息子のR君は1歳6ヶ月になった。
あまりにも活発で部屋中動きまわるので、一緒にいるときは目が離せない。
R君が起きている間は四六時中一緒にいるので、何もできないのがツライ。
 
育児漫画とか描いていらっしゃるママはどうやって漫画を描いているんだろう。オジオバがいるとか、なんか絶対カラクリがあるに違いないぞ。勝間和代とか、もう絶対信じない。
それとも子供が一人で遊んでくれる性質なんだろうなあ。そうだといいなあ。
 
うちの場合は、朝、公園に行って疲れるまで遊んでいないと昼寝せずグズるので必ず朝は公園に外出。朝2時間くらい。
昼寝は約1時間から2時間くらいする。(この間にネットやメールの返事をまとめてする)
そのあと、家の中を走り回ったりしているが、私がパソコンを開くと飛んできて、キーボードを触らせてくれといわれる。
iPod touchでブログや産経新聞を見ようとすると、飛んできてiPod touchに入っている電車(プラレール)のビデオを見せろといわれる。
この時点で、ネットに繋がる情報機器は全てアウト。
しょうがないので、夕方までLEGOとかのおもちゃで一緒に遊ぶ。
夕方が来ると、R君が退屈しはじめるので、子ども番組を2時間くらいつけっぱなしにしている。
お風呂に入れて、R君が寝るのがやっとの9時くらいかな。
夜10時になるとこっちもクタクタで11時くらいには寝たりする。
 
もう、ニュースなど外部の情報を仕入れる時間が圧倒的に少ないのだ。
どうすれば良いのかよくわからんが、色々な事を諦めることにした。
まず、テレビニュースはワールドビジネスサテライトを1.3倍速で、興味のある所だけを10分程度見る。ほかは全部10倍速くらいでテロップだけチラ見する。
ドラマなどの番組は見ない。『坂の上の雲』をずっとレコーダーに置いていたけど6話まで一度も見ずにバッサリ削除した。
TwitterはWebインタフェースから時々開いてチラ見する。
RSSリーダーに溜まっているブログは、夜中に目が覚め、となりで寝ているR君が起きてなければiPod touchで読む。
 
幸いなことに、紙の本を読んでいる間はR君からの干渉は若干手薄で、逃げきれる程度なので、カンフーの様にうまく防御しながら本を読むことにしておりまする。
あっ、R君が起きたのでこれにて！
 
----< tamagawa >----
どーも、お久しぶりです。いろいろ大変ですね。うちも15～10年くらい前はそんな感じだったか･･･今は今でまたいろいろありますが。子どもの小学校の学級崩壊とかさ(^^;
実はですね、訳本だしたんです。いります？ http://www.oreilly.co.jp/books/9784873114392/
送り先教えてもらえれば、1冊送りますぜ。
   Hadoop: Tom White, 玉川 竜司, 兼田 聖士
----< kiyoka >----
tamagawaさん、コメントありがとうございます。
なかなか育児をフルタイムでやれるのは今だけと思って耐えております。

訳本の完成おめでとうございます。さっそく１冊頂きます。
amazonのリンクも上に貼っておきました。
(送り先の件はメールにて)

----< kiyoka >----
tamagawaさん、献本ありがとうございます。本日届きました！
仕事では使わないかもしれませんが、アーキテクチャなど興味がありますので、じっくり読ませて頂きます。

----< tamagawa >----
私もclojure本、買って読み始めました。おもしろそうだなあ。
Hadoopと合わせて使っている人がいるみたいで、確かに相性が良さそうな気がします。いっちょ勉強してみるかなあ。
   プログラミングClojure: Stuart Halloway, 川合史朗
----< kiyoka >----
clojure本、いいですよね。仕事でclojure使えないかなぁ。
Hadoop本のほうは、あれから少しずつですが、読み進めています。そのうちブログに記事を書きます。

comment please => kiyoka.2010_02_07
 
 
kiyoka.2010_02_03[本] プログラミングClojureを読む(その1)
   プログラミングClojure: Stuart Halloway, 川合史朗
[目次]
- 第1章 Getting Started
- 第2章 Clojureひとめぐり
- 第3章 ClojureからJavaを使う
- 第4章 シーケンスを使ったデータの統合
- 第5章 関数型プログラミング
- 第6章 並行プログラム
- 第7章 マクロ
- 第8章 マルチメソッド
- 第9章 現場のClojure
 
第4章の途中を読んでいる所。
Nendoではどうするかなーと考えながら読んでいるので時間が掛かる。
特に、第3章で出てくるClojureからJavaへのアクセス構文については、Nendoでかなり参考にさせてもらっている。
本書を読みながら、改めて感じたことは、ClojureからJavaへのアクセスする構文のパターンが多すぎて複雑な気がする。
Nendoではあまりパターンを増やさず、一度チュートリアルを読めば覚えられる程度にとどめようと思った。
 
また読み進んだら、再度感想を書きます。
 
comment please => kiyoka.2010_02_03
 
 
kiyoka.2010_01_26[Sumibi][KVS] key-valueストアを使ったSumibiのリライト(アイデア段階)
   Software Design ( ソフトウェアデザイン ) 2010年 02月号 <雑誌>
 
今日、本屋で見つけて買ってきた。
特集記事の『key-valueストア講座』を読んでいて、Sumibiをkey-valueストアを利用したシステムに書き直したくなってきた。
もちろん、現行のSumibiのアルゴリズムをそのまま再実装するわけではなくて、並行してSumibiの問題点を修正しながらリライトするという意味だ。
 
- 個人的に問題だと思っているところ(普段SumibiはEmacsから常用している)
## レスポンスが悪い
Ctrl-Jを押してから変換結果が返ってくるまで平均して1秒以上かかる
 
## 文章の入力中はアルファベットしか画面に表示されない為、自分のタイプミスが見つけにくい
例えば『日本語を変換する』という文章を入力する場合は、変換するまでは次の様なローマ字のみの画面になる。
 nihongo wo nyuuryoku suru [ここでCtrl-Jを押すと変換実行] 
例えば、上記の nihongo の部分を nihango と入力しても簡単に間違いに気づけない。変換してから間違いに気づく。
実は、ニホンゴをニハンゴと打ち間違えているのだけど、ローマ字だとわかりにくいでしょう？
 
## オフラインでは使えない
sumibi.org経由で変換するので当然といえば当然。
 
データ構造をどのような形にすれば良いかはボンヤリとしかイメージできていないが、key-valueストアにはあらかじめ計算リソースを大量に使っていろんな統計情報を集計済みにしておく必要が有りそう。
現行のSumibiは、統計情報からの尤度の計算をMySQLの力技で毎回計算させているので、そのあたりを見直せば問題のレスポンスは改善するだろう。
ただ、パーソナライズの方法(個人辞書の扱い)をどうやるかという問題は日本語変換エンジンを開発している人はみんな悩んでいる問題で、私も全く解決案を思いついていない。
 
タイプミスについては、むしろタイプミスを許容して曖昧検索する方が良いかなと思っている。
オフラインでは使えないという問題は、目をつぶろう。NetBookが売れる時代なんだし。そっち方向には突き進んでよいだろう。
ボンヤリ考えている機能を実現しようと思うと、辞書は現行のSumibi辞書の2GByte程度では済まないだろうから、誰もローカルにはインストールしたくないだろう。
 
※注意: 実際に開発するかどうかは分かりません。KVSの勉強がてら個別のアイデアの実装と評価だけはやるかも知れません。いつになるかな…
 
comment please => kiyoka.2010_01_26

kiyoka.ささみ::* kiyokaん家のネコ

kiyoka — 24 Sep 2008 11:29:48 +0000

kiyokaん家のネコ
『ささみ』といいます。よろしく。
sasami - a photoset on Flickrで公開している写真を使っています。
 
- テレビを見るささみ
 
 
- まどろみ状態のささみ
 
 
- 予防接種をした日のささみ。ぐったり。
 
 
- あおむけで寝るささみ。ぼんやり。
 
 
- ブラッシングしてもらうささみ。 
 
 
- 手のアップ