WiLiKi:開発:マクロ構文
WiLiKi:WishListで上がったもののうち、いくつかは マクロ構文のデザインに関わっているので、こちらに移動する。
構文そのものに関する考察
現在のマクロ構文の背景と問題
Shiro(2004/01/13 02:50:39 PST): WiLiKi-0.5では、マクロ構文を見直すことを考えている。 互換性のために現在の $name, $$name 形式もサポートするが、将来的に フェードアウトさせるつもり。
もともと、現在のマクロ構文を導入した理由は、「特別扱いするマークアップを 増やしたくない」というものだった。構文が増えれば増えるほど、 テキストを書き込んでゆく際に気をつかわなければならないケースが増える。 double bracketはもともとページ参照に使われていたため、 既に構文であったから、そこにマクロという機構をオーバーロードする ことにしたのだ。
しかし、しばらく使ってみてこの構文に不満を抱き始めた。
- '$' で始まるページ名が作れない。 SchemeCrossReference:SchemeCrossReferenceのように、 リファレンス的に使う場合、この制限はとても不便。
- マクロ引数の構文が曖昧。現在はなんとなくスペースで区切っているが、 スペースを含む引数を渡したくなったらどうするか。何らかの余分な 構文を導入すると、ページ参照としてのdouble bracketの構文から ますます離れて行く。
- 上記とも関係するが、ページ名に空白を許さないことにした 理由のひとつは、マクロへの引数渡しであった。
- これも引数の問題だが、ネストするようなマクロ呼び出しが書けない。
- '$$include' をつい '$include' と書いてしまうようなことが結構ある。
また、機能の追加に伴って、特別扱い構文も徐々に増えてきたし、 あまりdouble bracketをオーバーロードする意味も無くなってきた気がする。
候補
最近の流れのひとつは、「プラグイン」ってやつか。 &foo(args ...) とか #foo(args ...) とか。
WiLiKi的には、S式(wiki-dev:document:プラグイン)がよさげ。 引数区切りの構文は明確だし。ただ、S式の問題は、式の終了を知る方法が 括弧の対応にしかないため、ユーザーミスで括弧が対応していない場合に エラーがみつけにくいということがある。通常はエディタ等のサポートを 当てにするのだが、ブラウザで書き込むwikiの場合はそうもいかない。
- shelarcy (2004/01/14 13:55:20 PST): マクロについてのみ S式にエラーがないかどうかチェックして、エラーがあれば Another HTML-lint のようにエラー箇所を指摘するプレビューのページに移動するというのはどうでしょうか?
- Shiro (2004/01/14 15:59:05 PST): 「マクロについてのみ」チェックを行うためには、 まずマクロの範囲を切り出す必要がありますが、制限無しのS式ではそれが問題に なるということです。(例えば、閉じ括弧がないことは最後まで読んでみないと わかりません。しかし、それまでの間に不正なS式に見えるものが入っていると、 そちらが先にエラーとしてひっかかってしまいます。) S式は1行内に書く、とか、空白行を含めてはいけない、等の縛りを設ければ、 エラー範囲を絞りこめます。
- shelarcy (2004/01/14 19:17:16 PST): ああっ、そうですね。制限なしでやろうとすると誤検出の起こらない閉じタグが必要になりますね。
- ユーザーに誤検出が起こっているかどうかが分かりさえすればいいという観点に立って、 マクロが最後どこで閉じられたか確認するモードを用意すればいいという考えもありますが……。
wiki文法はもともと行指向だし、S式も1行内ってことにしてもいいかな。 どうしても複数行で書きたければ継続行が使えるし。
インライン要素とブロック要素で構文を分ける必要はあるか? formatterが正当なhtmlを吐くことを保証したければ、分けてある方が便利。 しかし書き込む際にいちいちそれを意識するのもめんどくさそうだ。
ただ括弧が出てきたらマクロ、というのでは、地の文との区別がつけにくい。 #(expr...)も、Scheme式によく出てきてしまうから問題がある。それを言えば &(expr...)も、Cのコードを張り付けた時なんかに問題が出そうだ。
SHIMADAさん方式、つまり##(expr ...)でもいいかなあ。 一応、現在の書式とは干渉しない (olにつかう'#'は直後に空白が 必要なので、マクロを行頭から始めても判別可)。
- SHIMADA (2004/01/14 18:48:16 PST): マクロを定義するマクロ、みたいなものに走らない限り、一行のみとする制限はリーズナブルなものだと思います。
個別の要望
ネスト (引数内でのマクロ展開)
- Su: 2003/06/18 23:19:00 PDT 画像にリンクをつけることはできませんか?
[http:/hogehoge.com/hoge.html [[$img http://hogehoge.com/icon.jpg ICON]]]
が通るとうれしいのですが。- Shiro (2003/06/19 13:54:14 PDT): ふーむ。引数内でマクロ展開か。考えてみます。
キーワードへのアンカー
- 下の情報を整理するってのにかぶるし、私が機能を知らないだけかもしれないですけど。
GHG で構造体のメンバとかの解説を読みながら思いました。
キーワードとかの定義とか説明のカタログを作りたいですねぇ。
いろんなページに分散している文章の一部ずつを1つのページにまとめる。
たとえば、 [:group GHG :key cpl :content class precedence list は CLOS 用語で、クラスの継承順序を決定するもの。 :assoc cpa] みたいに書いておく。
別のまとめたいページで [[$$keylist:GHG]]とかするといろんなページに散らばった上記の一文の GHG グループのカタログ(索引)ができる。
キーワードと意味と関連する用語へのリンクがまとまる。
ソートしてリストできればさらにいいし、
一つのサイトで一つしか出来ないってのは苦しいからグループ設定はいる。
テーマ毎かな、用語のカタログ、提案のカタログ、名言のカタログ、などなどあとはサイト次第。
ページへのリンクではなくて用語(文章)の整理ってのが下と違うとこかな。
逆にカタログページのキーワード cpl から元の文脈へのリンクもできれば。(う〜ん、欲張り?)cut-sea:2003/06/06 09:23:40 PDT
- そうそう、できればさらに複数グループの指定もできれば。こっちのテーマにも入れたいし、あっちのテーマでもあるしってのを両方のカタログページにリストしたいことがあるでしょうし。cut-sea:2003/06/06 09:35:46 PDT
- Shiro (2003/06/06 13:56:46 PDT): 例えば、用語の定義箇所には [[$$indexentry cpl :group GHG :caption ...]] のようなマクロを導入して、 表示時はアンカータグへ展開。 で、[[$$keylist GHG]] では $$indexentryの検索をかける、 というふうにすれば、わりと簡単に実現できそうな気がします。
- SHIMADA (2003/06/09 21:33:45 PDT): 昔YukiWiki:GreppingInWikiに書いたんですが、検索と簡単な整形ができるような汎用の仕組みがあると色々応用が利いて 便利ですよ。:)
S式
- S-Expressionをevalできるようにするってのはどうでしょうか。
eval: (pretty-print '(lambda()...))
で清書された式に置き換わるとか。こういうのはセキュリティが問題っぽいですけど。
- cut-sea: あ〜私も思った。出来ればいいんですけど、やっぱり問題多そうですね。動作・出力に制限加えないと。
- Shiro: SHIMADAさんがやってる Tiki:Tiki/組み込みインタプリタがおもしろい。WiLiKiのマクロも こっちの方向にゆくべきかな。だとしたら構文をもう少し整理しないと。
マルチラインマクロ
- Makoto (2003/03/09 17:46:29 PST): NoteやWarningなどの定型テーブルで表示される要素の追加を希望しますがいかかでしょうか? イメージとしては、Forrestにある、青いNoteや赤いWarningです。自分で書けそうならやってみようと思いますが。
- Shiro (2003/03/09 18:21:05 PST): そういうものならマクロでやるのが良いでしょう。 現在のマクロは全部が一行に入ってなければならないという制約があるので、 複数行の引数が取れるマクロの文法を追加靴泙靴腓Δ?
- Makoto (2003/03/09 19:29:00 PST): お願いします。(本当は、自分への注意書きを後で分かりやすいように書いておきたいと思ったのが発端でした。)
- Makoto (2003/03/09 23:56:40 PST): 「現在のマクロは全部が一行に入ってなければならない」は、wiliki.scmのexpand-writer-macrosで、read-lineしてregexp-replace-all regexp line substitutionしている部分のことですね。で、特定の(\w+)に対して、macro.scmに新しい手続きを加えると。なるほど、なるほど。