■

diary 研究開発 liskell

なんとなくHaskellを憶えてきたので、改めてLiskellのコードを見てみた。


理解できる！
サンプルのLiskellコードが、どういう風にHaskell風に解釈されるのか、そして、どう実行されるのかが、理解できるようになっていた。
そこで早速、Haskellを捨てて(?)、Liskellに移行すべきかどうか、ちょっとだけ検討してみた。
とりあえず、元の論文のpdfを流し読みし、LiskellのコードをEmacsのSLIMEで編集し実行している動画を見た。
(まだ実際にLiskellをインストールしたり、コードを書いたりはしてない事に注意。)


とりあえず、自分が理解した部分だけまとめてみる。

  • Haskellらしく、全ては基本的に遅延評価かつ遅延リスト。無限に続くフィボナッチ数列をlistとして定義しても、実際に参照されるまでは評価されない。
  • 元々のHaskellが前置記法と相性が良い(というか、中置記法が単なる構文糖でしかない)ので、意外とすんなり移行できるように見える。
  • Haskell由来の表記と、Lisp由来の表記が一部、衝突している。
    • Lispで「,」(コンマ)はunquoteだが、Liskellではタプル型、とか。
      • Liskellでは、「,」(コンマ)単体である場合はタプル型、すぐ後ろに空白以外の何かが続く場合はunquoteだとしている？？？
    • 他にも、car, cdr, consといった、Lisp由来の名前よりも、head, tail, :(コロン)といった、Haskell由来の名前の方が優先されているようだ、基本的には。
  • リスト生成手続きは「［］」。つまり、Lispでの「(list 1 2 3)」は、Liskellでは「(［］ 1 2 3)」。nilと混乱しそうだ。
    • そして、これを簡潔に書く為に「%(1 2 3)」(=「(［］ 1 2 3)」)というリーダーマクロ？が用意されているっぽい。
  • 動的型言語ではないので、シンボル(というか束縛)のquasiquote, unquote, unquote-splicingはあるものの、シンボル自体を扱う手続きは提供されてないっぽい？
  • defmacroが使える。
  • Haskellの「\」は当然、lambda。分かりやすい。
  • do式は無いっぽい？
    • IOは全部「>>=」や「>>」を使って記述するっぽい？
    • しかし、自分が読み飛ばしたところにdo式に関する記述があるかも知れない。
  • Haskellではデータ型、型クラス、モジュール名等は大文字始まり、束縛は小文字始まり、という制約があるっぽいが、その制約は引き継がれているのか？
    • 少なくとも、defineやdefmacroやletでは、Lispらしく「call-with-current-continuation」的な、記号をふんだんに使った束縛名が使えるっぽい。
    • しかし、Haskell互換の表記に合わせた方が分かりやすい気はする。
  • 慣れの問題かも知れないが、「=」が無いので、letとかで指定できる、パターンマッチ引数の指定が分かりづらい。
    • Haskellでは当然、既存のHaskellの構文やルールに合わせて、(おそらくは人間に理解しやすいように)記号や予約語やキーワードが選ばれてる訳で、それを別ルールのLispに持ってきた場合は微妙な事になってしまう？


さて、これはどうなのか……。
自分が見た部分から感じられたのは、これはぶっちゃけ、「HaskellをS式表記にして、ついでにdefmacro使えるようにした」というもののように思える(読み飛ばしたところに他にも美味しい部分があるかも知れないけれど)。
なので、この二点について考えれば良さそうだ。

  • HaskellをS式表記にする旨みは？
    • 自分としては、S式表記の方が好みだ。が、それは慣れによる部分が大きいだろうし、あまり一般的な優位とは言いづらいので、今回はそれは除外する。
    • 以前の考察( http://d.hatena.ne.jp/ranekov/20070923 )により、「(自分にとっての)S式の究極の利点は、コードジェネレータにあり」という結論が出ている。しかし、静的型言語のHaskellにコードジェネレータはちょっと相性が悪いように思えてならない。evalないし。
  • Haskellにマクロは必要か？
    • 全てが遅延評価なHaskellには正直、マクロはいらなさそうな気はするんだが……。


という事で、とりあえず今のところは、どうもLiskellにあまり利点を見出す事が出来なかった。
とはいえ、ものすごくニッチな方面で役に立ちそうな気もするので、Liskellが力を発揮しそうな分野のものを作りたくなった時には、Liskellを使ってみようと思う。