2011/05/29
Schemeでgoto (tagbody&go)
なんか聞こえてきた
http://twitter.com/bugyo/statuses/74784105946038272
@bugyo なんで Scheme には goto がないんだ！ 何もできない！
のでやってみた。Lispの伝統にしたがい、gotoではなくgoを使う。 そしてラベルのスコープを決めるのにtagbodyを使う。
思ったより複雑になっちゃった。もうちょっと簡単にできないかな。
最初は、各ラベルをthunkにして、goはそのラベルを呼び出した後に
tagbodyからexitすればいいや、と思ってたんだけど、それだと(go loop:)
でループするような場合にgoが末尾呼び出しにならないので、ループしてるだけで
スタックを消費してしまう。
goを末尾呼び出しにするために、結局トランポリンを使った。
というかlequeさんが2年も前にやっておられたわい。(でもこれだとgoto labelのlabelの呼び出しが末尾呼び出しじゃないので、ループでスタック消費問題があるような…)
Tags: Programming, Lisp, Scheme, Gauche
2011/05/25
ピアノレッスン4回目
- 基本
- スケールは126まで上がったが左手の下降でよくこける→左手だけ練習。 スタッカートでやるといい。レガートで少し目標値より速く弾けるようになってから 両手で目標値。
- アルペジオ(triad): 今週は116までいった。スケールと同じ速度目指してがんばりましょー。
- アルペジオ(7th): 指使い、一番楽な形を当てていたんだけど、 白鍵から始まる時は5-4-3-2-1-4-3-2-...でやるべし、とのこと。 確かにこっちの方が4指の強化につながりそうだ。
- Kapustin Op40-6: 最初に弾いてみせて以来だが、"100%良くなった" と言われた。へへ。
- Kapustin Op40-2: 初めて人前で弾くとやっぱりめっさ緊張する。
- A part, 右手メロディが強いが、Kapustinは左手もおもしろいのでもっとevenにするといい
- A part 左手3つのeighthと符点がつくパターンの違いを意識
- A part 譜面に明示されてないけどダイナミクスをつけるべきところはもっとある
- B part もっとはじけちゃっていい。A partとの対照。
- ペダル全体的にもっと控えてみたら。音の雲にまぎれちゃう。Kapustinはもっと明瞭に弾いてる。
- Rachmaninoff Op23-5 は時間切れで見せられず。
Tag: Piano
2011/05/24
Paul Grahamとサンダル
Y Combinator’s Paul Graham: We’re Looking For People Like Us
コメントで、Paulが靴下にサンダルを履いてるのを突っ込んでる人たちがいてふと思い出した。
昔、ニューヨークのILCでPaul他何人かと昼飯か何か食べに出た時、 Paulは私の足元を見て「やけに立派な靴を履いてるじゃないか」と茶化したものだ。 それは私が一足だけ持っている革靴で、普段は裸足にサンダルで暮らしてるわけだが、 ニューヨークはきっと恐ろしく寒いに違いないと思ってその時は靴を履いて行ったのだ。 だがPaulの口調はまるで靴を履いたLisperが珍奇な生き物か何かであるかのようだった。
Tag: PaulGraham
2011/05/24
コードの所属
日常出会うプログラミングの問題の多くにおいては、 コードを書くこと自体は難しいことではなく、 むしろそれを後から参照できるように「適切な名前をつけて」「適切な置き場所を見つける」 ことの方がはるかに難しい。
クラスベース(メソッドがひとつのクラスに従属するタイプ) のOOPがこんだけ流行った理由のひとつは、この置き場所問題に 簡単なrule of thumbを与えたからかもしれない。そのコードが主として作用する 「もの」を見つけ、それをクラスにしてその名前空間に放り込んでしまえば良いのだ。 クラスをどう名づけるかという問題は依然として存在するものの (そしてJavaのクラス名一覧を眺めると名付け問題についてはうまく解決できていない であろうことが推し量られる)、一度クラスが決まれば場所が決まるという 安心感は大きい。
コードが2つの種類の「もの」の間に作用する場合とか、 コードが抽象的すぎて作用する「もの」を抽象的な性質でしか示せない場合とかは このrule of thumbがうまく使えない。クラスベースOOPで分類に困るケースって だいたいこんなところだと思う。
CLOSのマルチメソッドやHaskellの型クラスにはそういう困難は無いけれど、 場所問題の解決は示してくれないので、プログラマが自分で考えないとならない。 Haskellの事情はよく知らないけど、CLOSの人気が出ないのはそのへんにも 理由があるやもしれぬ。
★ ★ ★
何でこんなことを思ったかというと、長年頭の隅にひっかかってた 「場所問題」にひとつけりがついたのだ。
Unicodeのコードポイントとutf-8との変換を行うルーチンって、 これまで必要に応じて何回も書く機会があり、Gaucheに標準でつけときたいな と思ってたんだけど、どうも適切な置き場が見つけられなくて、 一から書いても10行くらいだから、結局毎回書いていた。 Gaucheの内部エンコーディングがutf-8でコンパイルされていれば コードポイントを文字にしてI/Oするだけで変換できるんだが、 「integerで表現されたコードポイントをutf-8のオクテット列に」とかその逆、 っていうのは内部エンコーディングに関係なく必要になるし、 関係なく書ける処理である。 内部エンコーディングに関わらないんで、文字や文字列の処理と 同じ場所に放り込むのは落ち着かない。入出力とも違う。 処理の作用する対象は整数だけど、数値モジュールでもない。
R6RSやR7RS draftのstring-downcaseやstring-titlecaseの
実装をしていて、これはUnicode Standard Annex #29の
Unicode Text Segmentationをちゃんと実装しないと書けないという
ことに気づいて、結局そのへんの処理がtext.unicodeというモジュールの
形を取ってきたところで、上の「コードポイントとutf-8との変換」も
ここに属する処理であることに気づいた。
内部エンコーディングにかかわらず、Unicode Standardで決められてる
何かを扱うモジュール、というわけだ。
Tags: Programming, Gauche
2011/05/18
ピアノレッスン 3回目
- 基本: スケール MM=120, アルペジオ MM=96, アルペジオ(7th) MM=72, までできるようになった。「アルペジオはスケールと同じ速度で弾けるように なりましょう」だそうなので当分アルペジオに重点を置こう。
- ラフマニノフ Op23-5 ゆっくりだがデュナーミクや多声部の表現については だんだんできるようになってきた。だが音を全部頭に入れないとつっかえる。
- Kapustinは今日はレッスンで見せる時間が無かった。 一応拍を数えながらOp40-6はだいぶスムースになってきて、 Op40-2をゆっくり数えながらさらいはじめたところ。 ラフマニノフがもうちょい速くなれば見せる時間が取れるだろう。
Tag: Piano
Comments (0)