不完全なモジュールを許容すること

Catyの諸々の定義やプログラムは、モジュールで構成される。そのモジュールを可視化すると、疑問符（'?'）やグレーの図形が表示されることがある。

このモジュールのソースは次。

/** 

 * 不完全なモジュール 

 */

module tt in cara;
/** 型の定義は後でする（deferredで遅らせる） */

type Foo = deferred;
@[abstract]

state start :: any

links {

  root --> Root.get;

};
resource Root("*") { 

/* リソースのパターンはまだハッキリしない（ワイルドカード） 

 * って、わざとらしすぎる。Rootは "/" だろうけどね。

 */
  action get("GET")

  :: _ -> _ /* 入出力の型は明示されてない、アンダースコアでお茶を濁す */

  produces HomePage /* 生成するページはまだ定義してない */

  ; /* アクションの本体が定義されてない、書いてない */

  

};


state ViewItem for viewer :: any /* 状態の型はとりあえず何でもいい（any）とする */

links {

  /* リンク先は未定義 */

  next --> View.next;

};
// End of Module

そもそも必要な定義を書かないとか、ダミーの目印を埋めておけばいいとかが多い。そのようなテケトーなモジュールを書いても、構文エラー（セミコロンが抜けているとか）がない限りはロードされる。正常にロードされたからこそ、可視化もできるわけだ。

こういう仕様になっているのは、Catyは白紙からシステム構造を記述することを想定しているからだ。白紙から構想を書き下すとき、ボトムアップよりはトップダウンで考えることが多い。上部構造（トップ側の構造）で参照している詳細（ボトム側の構造）が未定義だとエラーするではオハナシにならない。名前や関係を先に定義して、詳細や実装は後回しになる。当然に試行錯誤もする。

そのように、何もないところからシステムを組み立ていく行為を支援するには、不完全で未定義部分が残るモジュールを認める必要がある。Catyのモジュールでは、明らかに破綻する／矛盾することを書かない限りはエラーとはしない。あるいはエラーを回避する方法（主にダミー構文）を準備している。

でも、最終的にはテキトーじゃ困る。これは、別途バリデーターとかリントツールにより解決する。これらのツールは、記述漏れや整合性をチェックして報告する。チェック用のツールの精度を上げれば、人間の不注意に起因する不完全さやリスク要因を事細かに指摘することもできる。

今見なおしてみると、アクションに対するHTTPメソッドは必ず書かなくてはならない、とか、「テケトーさに欠ける」点も残っている。よりテケトー・イイカゲンにすべく改善しようと思う。