2015/09/06

Schemeから可変長引数を引き算したら

https://twitter.com/___yuni/status/640394172407656448

@___yuni: 割りと前から言ってる気がするけどschemeから可変長引数削除したらいろんなことがめっちゃ綺麗になるから削除したい…

Alice: 賛成さんせー。プログラムをメタに扱うときに可変長引数があると色々面倒なのよね。

Bob: うーん、そうしたら不定長コンテナのコンストラクタはどうなるのさ。 (list 1 2 3) とか (vector 1 2 3 4) って書けるのは listやvectorが可変長引数を取れるからだよね。

Alice: そんなの '(1 2 3) とか '#(1 2 3 4) でいいじゃない。

Bob: いやクオートしたら全体がリテラルになっちゃうよ。中で変数展開したいとき どうするのさ。(list x (+ x 1)) と '(x (+ x 1)) じゃ 意味が違うでしょう。

Alice: ふっふっふ。私たちにはquasiquoteがあるのよ。中で展開したければこう書けるわ。

(define x 10)

`(,x ,(+ x 1))  => (10 11)
`#(,x ,(+ x 1)) => #(10 11)

Bob: 不定長なのはリストとベクタだけじゃないよ。u8vectorとかどうするのさ。 `#u8(,x ,(+ x 1)) とは書けないんだよ。だってそれはリーダの定義により (quasiquote #u8((unquote x) (unquote (+ x 1)))) と等価だけど、 リテラル #u8 の要素には数値しかありえないんだから。readの時点で エラーになっちゃう。

Alice: そもそもリテラルとコンストラクタを分ける意味ってあるのかしら。 #u8(1 2 3) ならリテラルデータだし、 #u8(x (+ x 11)) なら実行時に計算してu8vectorを返す式ってことにできないかな。 いやxが定数だってコンパイル時に分かるんなら計算してリテラルにしちゃっても良いんだけど。 つまりプログラマがわざわざ意識して使い分ける必要なくない? それで良いなら、 リスト以外についてはコンストラクタをどうするかって悩む必要ないわよね。 リストについてはquasiquoteで解決と。

Bob: それは綺麗な設計だけど、Schemeのようにmutableなデータがある場合は うまくいかないよ。'#(1 2 3) は変更不可なリテラルだけど (vector 1 2 3) は後でvector-set!されるかもしれない。 この二つを区別できる必要がある。

Alice: だめか… 仕切り直して、不定長コンストラクタ用の専用構文をひとつ 作るってのはどう? 例えばHaskellみたいに[1 2 3] がリストコンストラクタなの。 (let1 x 10 [x (+ x 1)]) => (10 11) って するわけよ。リストさえ構築できれば、他のデータ型はコンストラクタがリストを取るように すればいいだけよね。こんなふうに。

(->vector [1 2 3]) => #(1 2 3)
(->u8vector [1 2 3]) => #u8(1 2 3)

Bob: その場合、'[x (+ x 1)] は何になるんだよ。

Alice: クオートされてるんだから [x (+ x 1)] でしょう?

Bob: いやREPLに打ち込んだら確かにそう返ってくるかもしれないけどさ、 その[...]って、具体的にはどういうオブジェクトなのさ。リストじゃないよね。 (list? '[x (+ x 1)] => #t にしちゃったら (list? '(x (+ x 1)) と区別できないし。

Alice: うーん…

Bob: それに、プログラム的に[...]になるような構造を生成したい時は どうする? 例えばリスト(a b c d)を受け取って [(a b) (c d)]というプログラム片を生成したい、とかさ。 マクロ書く時にこういうこと良くあるよね。

Alice: そうねえ、そもそも [...]と (...) と二種類あるのが 良くないんだとしたら? もういっそのこと [...]をリストってことにしちゃいましょうよ。

(car [1 2 3]) => 1
(cdr [1 2 3]) => [2 3]
(cons 1 [2 3]) => [1 2 3]

ほら、なんか良さげ。 []の中は評価されるけど全体をクオートすればリストリテラルってことにもできる。

(define x 10)
[x (+ x 1) 'x]  => [10 11 x]
'[x (+ x 1) 'x] => [x (+ x 1) 'x]

Bob: えーと、それじゃ '(car [1 2 3])は何になるの? [1 2 3]をリストにしたなら、'(car ...) はリストじゃないよね。じゃあ何?

Alice: ぐぬぬ。じゃ、じゃあ(...)はリストのままでいいわ。 [...]をベクタってことにしましょう。さっきと逆に、リストのコンストラクタが ベクタを取ることにするの。

(vector? [1 2 3])  => #t
(->list [1 2 3]) => (1 2 3)
(->u8vector [1 2 3]) => #u8(1 2 3)

Bob: まあ機能しなくはないけど、不定長リストの構築にいちいち(->list [...])って 書かなきゃいけない、ってのはなんだか面倒だねえ。REPLでmapを試すのにもいちいち こう書くってことだろう。

(map (^a (+ a 1)) (->list [1 2 3]))

Alice: mapがベクタも取れるようにすればいいわ。 ベクタだけじゃなくて不定長のコンテナはぜんぶ統一して使えるようにすれば。 そういうコンテナの最初の要素を取るfirstと残りの要素のコンテナを返す restをオーバーロードしておけば後はそれで全部書けるでしょう。

Bob: そういう言語知ってるよ。Clojureっていうんだ。

Claude: (まあそのClojureでさえ)(不定長引数は捨ててないけれどね)

(Lisp系言語は(同図象性によって)プログラムはメタレベルでデータとなる)(それは(本質的に)不定長のリストだ)(プログラムの構築を(メタレベルの)プログラムで行おうとすると、不定長リストの構築は避けて通れない。)

(回避方法は色々考えられるけど、どこかで辻褄合わせが必要になるんだよね)

Tags: Programming, Scheme

2015/08/26

"The Martian", "Revival"

最近読んで当たりだった小説2編。

Andy Weir: The Martian この秋に映画公開だけどその前に原作読んどこうと思って。 読み始めたら止まらなくなったうえ、読後に勢いで2度読みまでした。 サバイバルのための作業の見積りの計算部分など、映画だと多分流されちゃうから 味わい尽くすには小説を先に読んで正解だったかな。

主要登場人物がみんな(ある意味)ナードなのが素晴らしい。 宇宙とか他の惑星といった容赦ない環境では、まずその敵対的な 物理法則に合わせないことには手も足も出ないわけで、 根性とか感情とか気合では問題は解決しない。 話が出来る前提に立つまでに膨大な理詰めが 必要で、そこがナードの活躍しどころだから。前提が出た上でどの選択肢を 選ぶべきかってところでは人情が絡んで来るんだけど、その議論が出来る資格を 持ってるのはそこまでの議論を追ってきてかつ実際に手を下せる当事者だけで、 そこに外野の政治的な思惑とかが入る余地がないっていうのも、ナード心をくすぐる設定だ。

最初から最後までずーっと面白いんだけど、SOL196でのWatneyのミス (ドリルのやつ) は似たようなことをやらかした思い出が蘇って胃が痛んだ (もちろん自分のは生死に関わるような話じゃなかったけど。後から、あ、あの時のアレが… って気づいてジワッと冷や汗が出るイヤな感じが何とも)

Stephen King: Revival 安定の老境キング。超自然的な部分をspecial kind of electricityでさらりと 済ませちゃうのがThe Martianと対照的だけど、身に余る力へのアクセスを得てしまった 人間の行動と、弱さで身を持ち崩してしまった人間の贖罪についてはリアル。 ストーリーの骨子はそれほど複雑でないのに読ませる力のある文章や伏線の張り方が 相変わらずうまい。

アンタゴニスト(Jacobs)の真の目的は何だろう、それを知りたい、というのが 読み進める一つのドライブになってるんだけど、それが判明してから 振り返ると最初から答えが出てるんだよね。 うわぁやられたって感じだ。 キングのベストとは言えないけれど、Constant Readerなら読んで損なし。

Tag: 本

2015/08/09

ssh秘密鍵更新メモ

Firefoxのゼロデイでssh秘密鍵が盗まれた可能性があるってことで、 念のため秘密鍵を新しくしたのでメモ。

• ログイン必要なサーバのsshdでパスワード認証を許可しとく(新旧二つの鍵を一時的に併用する方が安全かもしれない)
• 新しい鍵ペアをssh-keygen -t rsa -b 4096 -C "shiro@..." で作成。
• cat .ssh/id_rsa.pub | ssh $server 'cat >> .ssh/authorized_keys' (この時だけパスワード認証)
• ssh $server (ここからは公開鍵認証)してauthorized_keysを編集、古い公開鍵を消す。
• 公開鍵を登録したサービスの更新
  • github
  • sourceforge

こんなもんかと思ってたら、自サーバのgitサービスを忘れてた。これは gitoliteを使ってるんだけど、 ユーザの公開鍵を更新するにはgitolite-admin/keydirを編集してpushするという ワークフローなんだが、自分の鍵を変えちゃった後ではpushできない。 (アカウント自体はgitユーザのものでそもそもシステムレベルでパスワード認証不可にしてる。 普段はgitolite-adminをpushすれば~git/.ssh/authorized_keysが自動更新される 仕組み。) 安直に sudo vi ~git/.ssh/authorized_keysで 自分の公開鍵情報を書き換えてからpushしたけど、本来は新旧二つの鍵を持ってる時点で 更新しとくべきだった。

ところで本筋とは関係ないんだけど、「秘密鍵」「公開鍵」の読み方、 最初に大学で教わった時に「ひみつけん」「こうかいけん」って聞いたような覚えがかすかに あるんだけど(わざわざ「ここでの鍵はけんと読む」って先生が注釈してたような記憶まで)、 ぐぐっても「昔はこう読むこともあった」という話さえ全然出てこない。 1989～1990年頃なんだけど、少なくとも一部でそう読む文化があったのか、 それとも自分が夢でも見ていたのか(講義中に夢を見ていた、という可能性も少なくはない)、 はっきりしなくてもやもやしてる。

Tags: Computer, ssh

2015/06/07

集中の制御

昨日、Aloha International Piano Competition, Amateur Divisonで演奏した。

• Stravinsky, Prokofiev, Ginastera - at AIPF 2015

参加者5人中ではあるけれど、もう1人の参加者とタイでfirst placeを頂いて、今日のwinners' concertでもStravinskyを弾かせてもらった。 しかし子供のコンクール入賞者はめちゃ上手いなあ。

★　★　★

1月の演奏会で、芝居の時の心理状態とピアノ演奏時の心理状態について関連を見つけた。

• Waldstein

  「芝居の時はあがらないのに演奏であがるのはなぜか」というのが ここ3～4年くらい考えていたテーマのひとつなんだけど、 今回また新たな知見が得られた。ような気がする。

  舞台に立っている時の心理状態に、「入る」というのがある。 芝居が作り出す「場」に浸かっている状態。 [...]

  演奏でも、音楽に「入る」状態があるようだ[...]

  人前での演奏で上がりまくるというのは、うまく音楽に「入る」ことができずに、 テクニカルなことを全て頭で制御しようとして、処理能力がパンクしているって ことかもしれないと思った。

以前は、練習では平気なのに、本番になるとself consciousになって、出す音出す音これでいいのかとかああミスったとか次は何だっけとか頭がぐるぐるしてしまっていた。これは確かに、まだ芝居の経験が浅かった頃に舞台で感じたのと似ている。

で、前回、音楽に「入る」感じがわかったので、今回は芝居の時に集中するやり方を応用してみた。具体的に音楽に「入る」状態自体は芝居に「入る」状態とは色々違うのだけれど、一度「入った」状態を知って目的地がわかれば、(1)始める前に入りやすい状態へ準備しておく、(2)入ったら抜けないようにする、という部分は芝居と共通のはず。

で、どうやらうまくいったようだ。というのは、演奏中に「あ、今のとこああすれば良かった」と思った記憶が全く無いので。これは以前書いたフィードフォワードモードになってたということだ。

間違えたことはその場では意識するんだけど、そこから次をどうするかしか考えてなかった。なので終わってみるとどういう演奏をしたのかおぼろげにしか覚えていない。技術的な反省点については録音しておけば後で振り返られるのでこれで良いのかな。 芝居でも、本番での表現をよく覚えてないってことがわりとある。「昨日のあの場面のあれがすごかった」とか言われても、どうだったのか思い出せない。でも身体が覚えてるはずなので、また「入る」状態になれば何とかなる。演奏もそういうものなのかもしれない。

もう何回か、人前での演奏で試して確認してみよう。

Tag: Piano

2015/06/06

退屈なプログラミング

• プログラミングが退屈だ

  最近、プログラミングが退屈に感じる。もはやルーチンと言っても差し支えないとまで思うこともある。プログラミングというと一般的には創造的な活動だと思われているが、実際のところその大部分は定型的な作業であり、多少頭を使うというだけである。

こんな感じですかね。

(追記2015/06/08 10:04:36 UTC): 「役に立つが金にならずおもしろくもないプログラム」が大きいのはなぜ、という疑問を複数目にして気づいたんだけど、この図は「これまで書いてきたプログラム」じゃなくて、「これから書き得るプログラム」で考えてた。つまり潜在的な需要みたいなものを反映してる。

ちょっとコードを書けば誰かがすごく助かるっていう場面はよくある。その誰かに喜んでもらえるというメリットはあるものの、要するプログラミングそのものは単純でつまらない。しかも単純もしくはニッチすぎて金を取れるほどではない。私の感覚ではそういう潜在的なプログラミング需要って膨大にある。うまく共通項を括り出せさえすれば、プログラミングのスケールメリットが効いて金になり得るし、売り物のプログラムのほとんどは実際そういうものだと思う。でもそうできるのは役に立つプログラミングのほんの一部でしかない。

Tag: Programming