「やっぱりパスタの会」でパスタを食べて来た報告

やっぱりパスタの会と言う名のcaty説明会に出席してきました。主催のid:m-hiyamaさんとckuwataさんはお疲れ様でした！

catyスクリプトがライトさを目指しているのとは裏腹に、ガチガチの圏論の理論背景を持っているところがさすがはid:m-hiyamaさんと言った感じで、とても面白くお話を伺えました。

ただ、公開されているプロトタイプでは動かないコマンドとかもあったので、最新の成果をバンバン公開して欲しいなあとちょっと思いました。

以下、ちょっとしたまとめです。

• きっかけはid:kentaro714さんに聞いた一般的な業務フロー
  • 「デザイナが好きにHTMLを作って、後から開発側が動くようにナントカする」
  • そうじゃなくて、デザイナが指導権を持って作って、プログラマへ足りないものを頼んで欲しい。
  • デザイナの職域を広げたい

• catyの特徴
  • デザイナーが使うことを想定した簡単な言語処理系
  • 関数定義やループ、変数や算術演算等は不可
  • データへのタグ付けによる分岐
  • コマンドをUNIXパイプ風に組み合わせる
  • プログラマが、ユーザ定義コマンドを追加できる
  • データは全て(拡張)JSON*1で表現
  • 厳密な型チェック、型推論
    • あいまいなものは動作させない
  • ユーザ定義コマンドの型は、プログラマが定義する
  • テンプレートも型を持つので、誤ったデータが流れ込むことはない
  • 取り替え可能なテンプレート構文
    • デフォルトはsmarty互換

• catyのコマンドの型
  • stringやintegerのような型の他に、any、_T(総称型)、neverがある
  • anyは、全ての型。_Tは型変数
  • neverは戻り値がないこと。voidとも違い、エラー(ボトム)
  • 例えばlengthコマンドはany->integerでも_T->integerでも同じに感じるが、_Tの方が存在する全てのlength関数を現す*2ので正確

• 意見など
  • 要件が定義できないと、catyコマンドをプログラマに発注できない。デザイナーには荷が重いかも
  • 拡張JSONの仕様を公開すれば、UNIXパイプなコマンドでも対応するものが作られそう
  • catyを、JSON RPCのサーバサイドでのJSONの生成に使えないだろうか

それでは、BPStudyの本編をオタノシミに！

10/29 追記

パスタはおいしかったです。

*1:haskell風のマルチライン文字列とか、カンマ位置の仕様を緩くしたりとか

*2:_Tがanyの場合も含むので、anyより大きい