軽量マークアップ言語 karas の構文設計

Post on 07-Jul-2015

1.451 Views

Category:

Technology

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

軽量マークアップ言語 KARAS の構文設計の根拠を紹介します。 KARAS がどういう意図でデザインされているのか、既存の軽量マークアップ言語がどのような問題を抱えているのか、例を交えて紹介しています。

TRANSCRIPT

軽量マークアップ言語 KARAS の構文設計

- KARAS の構文が優れている理由 -

Web : http://lightweightmarkuplanguage.com

Twitter : @XJINE

E-mail : xjinesproject@gmail.com

初版 2014.05.26 - 最終更新 2014.05.26

このスライドの内容

KARAS の構文設計の根拠を簡単に紹介します。 こ

れらは他の言語と比較して KARAS を選択するべき理

由でもあります。

公式ページ には、このスライドで紹介しない設計理念や、実装根拠が掲載さ

れています。

直感的な記号

直感的な記号

軽量マークアップ言語は人間がその目で読み書きする。

“言語” である以上、学習も必要になる。

したがって、より簡単で直感的な構文が良い。 ※当たり前ですが

KARAS の構文は記号の見た目から出力内容が想像

できるものが多い。

例 : 斜体になる構文の比較

KARAS は斜体として出力されることが明らかである。

過去にリリースされた他の軽量マークアップ言語にも KARAS と同じように直感

的な記号を採用したものはいくつかある。

* Markdown *‘’ Media Wiki ‘’// KARAS //

その他の KARAS の構文

** 太字 ** ,, 下付き ,,

__ 下線 __ “”引用””

%% 打消し %% @@ 出典 @@

‘’上付き’’ $$ 入力 $$

出典は cite 要素、入力は kbd 要素。 出典は今日の @ の利用方法を考えれば言うまでもな

く、入力は UNIX / LINUX のターミナルを参考にしている。

記号を2つ以上使う理由

記号を2つ以上使う理由

KARAS のインラインの構文は記号を2つ以上並べる。

多くの言語が記号1つであるが、これにも理由がある。

* Markdown ** Textlie ** AsciiDoc *** KARAS **

記号が2つ以上だと良いこと

• 記号が出てくる度にエスケープしなくて良い。 * 記号や、’ 記

号、数学記号などは特に、文章を書いているうちに多く現れる。

• エディタなどでハイライトされないプレーンテキストでは、複数の

記号が並んでいた方が、構文であることが目視でハッキリわかる。

冗長性の指摘について

記号を2つ以上並べることを前提にした構文は冗長だ、という指

摘があるかもしれない。しかし次の2つで反論する。

• 構文にしない記号をエスケープする頻度を考えてどうか。

• 同じ記号(キー)を連続入力するので、負担は小さい。

利益と比較すれば、それほど大きな問題にはならない。

空白文字は構文にしない

空白文字は構文にしない

KARAS は空白文字を利用する構文がない。プレーン

テキストでの利用を前提とするなら、空白文字は構文と

して使うべきではない。可読性が低い。

例 : 空白を使うリスト

リストをネストするとき、空白を使うタイプの構文は、

空白の数を数える必要がある。空白の数は数え難い。

また、その数だけ空白を入力する必要もある。

* List・・・・ * List・・・・・・・・ * List

例 : 空白を使う改行

改行に空白を使うタイプの構文は、単に見にくい。折り

返されてるのか、改行されているのか分からない。

Tomorrow is・another day.

Tomorrow is another day.

異なる構文から同じ出力をしない

異なる構文から同じ出力をしない

いくつかの軽量マークアップ言語は異なる構文から、同じ

出力結果が得られる。柔軟ではあるが問題もある。

# Type1

Type2===============

===============Type3===============

入出力が1対でない構文の問題

• 単純に、学習コストが上がる。複数の構文を知る必

要が出てくる。ドキュメントも肥大化する。

• 複数のユーザが異なる方法で記述すると混乱する。

• どちらを採用するべきか、衝突し、混乱する。

• その構文が何を意味するのか、理解できない場合がある。

拡張方法は定義されるべき

拡張方法は定義されるべき

• Markdown などの言語は、機能や構文を拡張する

方法が定義されていないため、様々な環境で方言が

現れている。

• どれが方言で、どれが方言でないか分からなくなる。

ユーザはそのシステムで、ある方言が使えるかどうか、

分からなくなる。

拡張は構文として用意する

拡張された機能であることはユーザに明示されるべきで

ある。 KARAS では拡張構文を利用して、それが拡張

であることを明示している。

実装レベルで好き勝手に構文を追加できるような拡張方法の提供は、確かに

便利ではあるが、先と同じ問題を引き起こしてしまう。

[[ 拡張名 :: この間は拡張されたテキストであると分かる ]]

終わりに

終わりに

KARAS には、理由・根拠のない構文、機能は一切含まれ

ていません。すべてに理由があります。公式のページ にはより

多くの情報を掲載しています。

例 : Footnote の構文がないのは何故か

: 改行を自動で削除しないのは何故か

Web : http://lightweightmarkuplanguage.com

Twitter : @XJINE

E-mail : xjinesproject@gmail.com

初版 2014.05.26 - 最終更新 2014.05.26

top related