Notices by きゅーけー (tojoqk@mastodon.tojo.tokyo), page 83

個人的に SRFI 41 の命名規則と SRFI 121 の命名規則は、前者は長くなっても理解しやすいことを優先し、後者は利用頻度の高いものに関しては名前は短かくて読みやすくするのを優先するという点で命名の仕方の思想に決定的な違いがあると思う。これには一長一短あると思うんでどちらが良いとは言えないんだけど、R7RS-large という一つの言語仕様に両方が入るのはなんというかやばいのではないかという気持ちがちょっとある。でも、片方の命名の仕方を否定してしまうのもどうかという感じがあり、そのまま受け入れざるを得ないというのも分かる……。

私がこんな風に思うくらいなんだから、たぶんもうずっと前に R7RS-large 関連のメーリングリストで既に議論がなされた後なんだろうな。

R7RS-large の SRFI を取り込んでいく感じ、SRFI によって手続きの命名規則が違うために結果としてとてもカオスな状態になりそうで怖いという気持ちがある。

Haskell とか OCaml には標準に Map があってちょっと羨ましい。R7RS large にはもう入ってるかもしれないので確認するか(そもそも最近は R7RS large の動きを追ってなかった)。

Common Lisp の界隈でよく使われる Map 的なデータ構造がどのライブラリなのかの空気感を調査した方がいいかもしれない。しかし、そもそも Common Lisp や Scheme でそんなに関数型プログラミングを意識する必要はそもそもないという話もある気もする。

Lisper は連想リストという構造を普通に採用してしまう(たぶん、これには個人差がある)あたりが、他のプログラマから見ると信じられないところかもしれない。連想リストは追加は爆速だけど、検索は遅いからな。もちろん扱うデータが多い場合は連想リストを使うことはないだろうけど少ないと分かってるなら連想リストでよくねってなる感じがする。構造がシンプルで扱うの楽だし。

ANSI Common Lisp や Scheme の標準が永続的データ構造の Map を提供していないために連想リストに流れてしまいがちなだけだと思うけど……。

たぶん、大抵の Lisper は XML を操作するときは SXML かそれに類似したS式に変換して操作をしてる(と思う)。JSON を S式 にするときは Scheme だとオブジェクトを alist にして、配列を vector にするか、オブジェクトを vector で表現して配列をリストにするかで割れている印象がある。私はオブジェクトを alist にする方がいいと思う。assoc できるし。

とくに flip とかを使い始めるともはや邪悪だと思う(Scheme の話ではない)。

ポイントフリースタイルに魅力を感じるかどうかみたいな……。Scheme の SRFI の cut とか便利なんでたまに使うけど、あれはやりすぎると却って読みにくくなる印象あり、ほどほどにするのが良いと思ってる。

個人的にはネストしているものをフラットな構造に変えられるとネストしていることが見えにくくなって分かりにくくなったと感じるんだけど、あまりこのように思う人はいない気がする。

構文が見慣れない問題、あんまり軽視してはならない気がしてきた。ネストした構造をそのまま明示的にネストされたまま見るという経験が Lisp 以外にない気がする。

Lisp 入門の壁には二段階あり、最初の壁は構文が見慣れないことで、二番目の壁は cons の外部表現が分かりにくい(特に cons からなる構造の一部をリストとして扱うという点が難関)というところだと考えている。

なんで cons cell の構造が違うだけなのに、リストのように出力されたり、ドット対のような変な点が入ったりするのかを説明するのが一番難しいと思う。

Lisp の構文よりも、ここの方が Lisp 最大の壁なんじゃなかろうかと思う。別にこれは cdr 部が nil になっているような cons cell をリストとして特別に扱っているだけなんだけど、他の普通のプログラミング言語ではそういうことをしてないんで難しいと思う。普通はリストならリストというデータ構造が提供されていて、何かを「リストと見做す」ということはやってない。

実際、Lisp について人に教えようとするとき一番詰まるポイントは cons cell とその外部表現のあたりだと感じている。lambda のあたりはもうそんな難しくないと思う。

cons cell の存在が Lisp かどうかを決定的に分けているような気がしてる。これは cons cell を定義できるかどうかではなくて、言語が cons cell を提供していて cons cell かなるリスト構造を特別視するような仕組みがあると凄く Lisp っぽいと私は感じる。

それ以外の特徴って最近の他の言語はだいたい持っている気がする。これを Lisp の特徴と見るかそれとも Lisp の負の遺産として見るかは人によって異なってくるとは思う。

Common Lisp の中から使える Coalton が Lisp かどうか考えたんだけど、私の判断としては Lisp ではないとう結論に至ったように。とはいえ、Lisp の定義ってなんなの？といわれると厳しい。私個人としては cons cell でリストを構成するような仕組みと symbol があり、かつそういったデータ構造でプログラムを自体を記述可能なようなプログラミング言語が Lisp だと思う(これだと Scheme は Lisp なのかちょっと怪しくなってくるような気がしないでもない……、Scheme は伝統的なマクロを言語仕様としては排除しているので……、あとこの考え方だと Clojure はちょっと Lisp ではなくなってしまうので Clojure が好きな人の前ではいえない)。

設定ファイルがS式で記述されているとそういうことに気づきやすいとは思う。S式で記述されているからといって、それが Lisp であるとは限らない。

設定の記述が汎用言語でなかったとしても、設定の記述をプログラムとして読めるということが一番言いたかった。これはS式であってもなくても同じ話。

Racket の面白い点としてはS式への拘りを捨てさったところにあると思う。コードの先頭に `＃lang X`(タグにならないように全角にした)って書いてあれば X 言語として Racket は読んでくれて、この X 言語は S 式でなくてもよい。X 言語の実装としては、構文解析をして Racket によって解釈可能なコードに変換するだけでよい。結局 X 言語は Racket のランタイム上で動くものになるんで、他の Racket 上で動く言語との間で手続きをインポートしたりエクスポートしたりできるんで凄い。

この記事、結果だけ書いてあって serverless.yml を Racket のコードとして解釈している件については触れてないんだな。これ、Racket の推しポイントだと思うんだけど説明なしか。

> serverless.ymlを準備する(ただし、先頭に#lang aws-lambda-serverlessと記述する必要があります）

> ただし完全な復元ではなく、Linux を GNU/Linux に置き換えています。

この一文要らないんで消すか……。

そういえば、以前 Serverless Framework の設定ファイルを Racket のプログラムとして実行可能にしたことがあるのを思いだした。たまたま、YAML のコメントが `#` だったからできた謎のテクニックなんだけど、これは結構面白いことをしたなと我ながら思う。

Serverless Frameworkを使ってRacketのプログラムをAWS Lambdaにデプロイしてみた -- TojoQKhttps://www.tojo.tokyo/serverless-framework-for-racket.html