todo

**************************
* 次にやること           *
**************************

* Parser.papillon のリファクタリング
	まずは module の export list をちゃんと parse してみようかな。
		以下参照

	import Hoge.Hage(Some(..), hage)
	をちゃんとパースし、[Import] とし、そこから Text.Papillon を消すようにする
	import list の要素は以下のようになると思う
		name, Name, Name(Name, name), Name(..), (+++)
	まとめると
		var / typ "(" names? ")" / "(" op ")"
		names = (var / typ) (, (var / typ))*
	上記で全てのパターンを網羅しているだろうか?
	また import 自体にも以下のパターンがあるだろう
		import Hage.Hoge
		import Hage.Hoge(...)
		import Hage.Hoge hiding (...)
		import qualified Hage.Hoge
		import qualified Hage.Hoge as H
		import "package-name" Hoge.Hoge
	まとめると以下の感じか。
		"import" strLit? "qualified"? name ("as" name)? "hiding"?
			importList?

* hscodelines を -rtsopts をつけて compile するようにしてみようかな

* 'c'+ をより拡張する
	Char 以外の token でも使えるようにしたい。
	つまり [Pat]+ という感じにすれば良いと思う

* ('\n' / '\t') とできるようにする

* import Text.Papillon を消すわけだが
	今は単純な import 文しか消せない
	ちゃんと消そうと思ったら import 文をちゃんと parse しなくちゃならない

* { ... } や [ ... ] 等のなかで do が使えるか試すこと
	まずは、do { ...; ...; ... } を試す。空 (つまり ;;) も許す。
	その後必要そうなら、あるいは時間があれば、あるいは、そのうち、
	offside rule も使えるようにする。

* { ... } や [ ... ] 内での case や if
	とくに case の offside rule がめんどくさいかも

* { ... } や [ ... ] 内での let ... in ...

* homepage に example をのせる
	はじめは簡単な例から徐々に難しい例へと

* simple な example source file を作成する

* cabal の description をもうすこしましにする

**************************
* parser の表記/機能関係 *
**************************

* \n や \t と stringE の関係について調べる
	ppr の問題なのかもしれない

* escapeC について
	\n, \t 以外の特殊文字についても考慮する

* 非終端記号に大文字で始まるものも許すようにしようかな
	これは prefix をつけることで可能と思われる
	camel, snake, raw の指定とからめて

* 引き算ができるようにする
	今の仕様だと n - s が n (negate s) になってしまう

* '(' のあとに space を許す

* some <- hage / boke; のような表記で U+2190 も使えるようにしようかな(面白いから)

* str :: Either (String, String) (Either (String, String) ()) がパースエラーになる
	上記を解決すること

* offside rule
	do に関するもの
	case に関するもの
	他に必要なところはあるかな?

* op の前後に space を許す

* [] の内側に space を許す

* parse error をつかまえる表記をつけたい
	たとえば、_:parseError とすると parse error が match するような感じ
	catchError を使ってできそうな気がするが ...
	あるいは monad の内側をえぐるとか
	無理そうならやめるけど。

	まずは token を Maybe token に拡張する。
	そして、error が生じた場所に Nothing を入れる。
	そして、それを catch できるようにする。
	ただこれをすると error message がわかりづらくなるな。

	monad の内側をえぐるやりかたがいいのかな。

* 上でやりたいことは、
	let x = 3 in x で、'in' が生じた際に error を起こし、
	その error を '}' と解釈するようなときに必要だ。
	これは別のやりかたでできるだろうか?
	LALR(1) ではなく PEG ならば別に問題ない気もする。
	let { x = 3 } in x
	無読先読みが可能なので、以下でできるように思う

	defs = def defs /
	letExp = "let" defs "in" exp

	で普通にできる気もするが ...
	
* !hoge のようにすると error となる。

* ('c' / 'd') について
	これは便利ではあるがまぎらわしくもある。
	考える必要がある。

* class SourceList について
	たとえば名前を class Token にする。
	そして、listToken を自動で定義することを考える。

* source [Token] のような表記が出来るようにする

* !x:[True] が動くことを確認する

* monad, source, prefix を順不同とする

* Foo.Bar.Baz や Hoge.Fuga.piyo を扱えるようにする
	lex レベルではすでに対応しているので、あとは、
	mkName (concatMap (++ ".") m ++ t)
	mkName (concatMap (++ ".") m ++ v)
	のようにすれば良いだけだ。

* '\xab' "\123\12345" のような表記を可能にしよう

* floating literal を使えるようにする
	その他 literal を増やす

**************************
*  warning 関係          *
**************************

* `Pattern matches are overlapped' warning を何とかする
	reify を使い、Pat -> Q (Pat, Bool) とする。
	IO 内では reify が使えないので、th :: Bool が必要になる。
	とすると、monad: Reader Bool とする必要がある。

	これも branch を切ったほうが良い
	しかし Parser.hs で使えないのでどうするべきか考える必要がある。

* Control.Monad.Error が重複しないようにする
	それから、同じ module を import しないようにすること。
	import する変数がどうなっているかがわからないとけっこうめんどくさい。
	import 文をちゃんと parsing する必要があるが、どの cost-performance を
	考える必要がある(主に code の複雑化について)

**************************
*  エラーメッセージ関係  *
**************************

* ParseError を表示する関数を TH で作成できないか考える
	問題はすべての型が Show であるわけではないというところだ。
	すべての型が Show である場合にのみ使える関数を TH で作ってもいいが ...
	いずれにしてもいろいろと考察すること

* peMessage で入手できる message について
	もっとちゃんとした英語にできるだろうか

* ParseError のそれぞれの項目を入手する関数の名前について見直す
	cabal haddock をして、それぞれを確認、また、並び順についても

* showReading をコード生成できるかな
	Show a => についてならできそうな気がするけど ...
	でも、全部が Show a であることを確認するのが無理かな?
	無理かも

* showParseErrorS を作っておこうかな?
	ただ、default な英語のメッセージを用意することには抵抗があるな
	無理かも

**************************
*  リファクタリング関係  *
**************************

* "char" を決め打ちにしているが、変数で置くようにする

* PapillonCore について
	同じ引数群を多くの関数で引き回している
	また、それらの引数の多くは一度値が決まると変わらない
	ひとつの型、またはタプルにまとめて、ReaderT を使ったらどうか

* plain style をどうするか
	全部消してしまうというのもひとつの手だ。
	あまり使い道が無いような気もする。

* 関数等の名前について
	つけるものを指定できるようにする
	指定がなければ何もつけないという感じ
	指定があればそれぞれの名前にそれがつく
	また parse にもそれをつけてしまおう
	それと行く行くは camel case 用のオプションをつけて、
	myParse とかそういうふうにできるようにしよう。
	自動で一番先頭を大文字にする。
	先頭の case だけ違うものについてはとりあえずは自己責任で。
	camel, snake, none から選べるようにするってのはありだな。

	derivsChars と derivsPosition は
	先々では camel, snake, none の値によって変えることにしようかな
	derivs_chars と derivs_position, derivschars と derivsposition のように

	Derivs も同様にする。ただし prefix の一文字目を大文字化する

	ParseError のフィールド名
	peCode, peMessage, peComment, peReadings, peDerivs, pePosition について
	snake や raw のときには、それぞれ
	pe_code, pe_message, pe_comment, pe_readings, pe_derivs, pe_position
	pecode, pemessage, pecomment, pereadings, pederivs, peposition の
	ようにする
	また prefix ももちろんつけることになるだろう

* papillon command は何も取らなければ filter とする。
	また、papillon [Input] や papillon [Input] -o [Output] の形も使う。
	そのうちに papillon -h や papillon --help も。
	より使いやすく GetOpt を使ってみるのもいいかもしれない。
* Text/Papillon/Parser.hs を git から外す
	これは papillon 自体がある程度安定してから、となるだろう。
* Parser.peg を token を使って書き直す
* ParseError の型をどうするか
	できたら型を公開しなくてもすむような形にしたいが
	つまり、型の構築子と reader だけを公開するという形にしたい

* data ParseError の型構築子を公開しないようにする
	data ParseError = ParseError ... を TH で書き、
	それは Papillon.hs にはりつけるのと、コードの変換時に追加するのとで使う。
	そして Papillon.hs からは ParseError は ParseError(..) とはしない
	作るときは makeParseError を使い、
	それぞれの field を入取するときも専用の関数を使う
	とりあえずはフィールド名を使っておけば良いと思う

* 上記は今の作りだと実行できない
	つまり、ParseError は Main で定義されているのでアクセス制限ができない
	mkParseError を作り、それを使うというのは未だにいい考えだが、
	上記ができないということで魅力は半減する

* ParseError は th が True のときには、Papillon からの export でもいいが...
	今のままでもいいし、どっちのほうがいいかな

* 今は Main 内でのみ使っているが、それ以外の module で使ったときに、
	未使用の warning が出ると思う
	それに対処すること

	pePositionS
	他の pe... もそうだが、module 内で使わない場合に warning が出てしまう
	あとで考えよう

* papillonStr について
	関数名について考える
	また、ByteString や Text も扱うかどうかについても考えること
	これを Papillon から export する必要はないのかもしれない
	とすると、module 構造を変える必要があるな

* 型で表限されないいろいろな制限について
	実際のところ、できるだけ、ありえない型の値が無いようにしたほうが良いのだ
	しかし、たとえば Maybe Char を使うよりも [Char] を使ったほうが、
	後々、++ でつなげるのが楽といった例外もある。
	そこらへんのトレードオフについても考える必要がある。
	今回の場合は例えば {} のあるものと無いものをまぜられないことや、
	{} のあるものの Definition は Maybe TypeQ を Nothing に出来ないこと等
	がある。

* SyntaxTree のリファクタリング
	Definition の Maybe TypeQ が Nothing になるのは PlainSelection のときのみ
		よって、PlainSelection と Selection とを分けて、
		Definition のところでまとめてもいいが、
		しかし、Selection は ReadFrom の FromSelection で使われているので、
		分けないほうが良いと考えることもできる。
		どうするか。

* Traversable の sequence を使えるところがある
	definitionQ の fromMaybe を使っているところ

* 生成されるコードをもっとすっきりさせられるかどうか考える
	今は、
	somexx_xx = runStateT someyy_yy d
	someyy_yy = do ...
	のような感じだが、これを
	somexx_xx = flip runStateT d $ do ...
	のような感じにしてしまったらどうだろうか
	ただ、そうするとコードのネストが深くなって見にくくなるということもある
	今のままのほうが良いのかもしれない

* PapillonCore のリファクタリング
	check のリファクタリング
		Just (p, pc) と Nothing の前半部分は統合できるだろう
		つまり関数の頭で match させずに case 文を使うということ
		必要とする変数の違いによって、なかなか難しいところがあるな

		Some s とのマッチングの際には以下のコードが必要となる。
			case ret of
				Some _ -> return ()
				_ -> throwError ...
			let Some s = ret
		もしも Some s が他の構築子を持たないのであればこうなる。
			let Some s = ret

		afterCheck の名前の変更
			もしくは、check へうめこんで消すか

	Pat を (Pat, Bool) とし、全てを網羅している pattern は (p, True) とする
	これは parse の段階でやってしまおうかな

* SyntaxTree.hs
	名前を変更する

* Parser.papillon
	pragmaStr を String ではなく [Word] としよう
		そして最終的な成果物は [String] とすれば良いと思うが、
		そのまま [Word] でもいいかな。
		つまり String よりは、より構造を持っているので。
		と思ったが pragma の種類に何があるのかわからないので難しいかも。

	予約語 monad と source を lex (word) で扱うようにする
		しかし、そうすると monad や source を変数として使えなくなる。
		これはもったいないかもしれないな。


* import を list にする
	そうすれば import Text.Papillon や import "..." Control.Monad.Error 等を
	消すのが簡単になるだろう
	その場合の型は
	data Import =
		Import { package :: String, name :: [String], vars :: [ImportVars] }
	data ImportVars = Var String | Type String [String] のような感じになるかな

******************************
*  機能面における細かい修正  *
******************************

* {-# LANGUAGE ... #-} がないときにはそれを追加する
* source の見直し
	今の文法だと、source: SomeSource\n のようになっているが
	今後より複雑な文法を許容した場合において ';' で区切ったほうが良いかもしれない
* papillonStr' 等を String 以外も取れるようにする
	StringLike とかかな

* papillon は getOpt を使うようにしよう

* Papillon.hs を上書きから守る
	また Papillon.hs が存在していたら、中身をチェックし同じならそのまま、
	異なっていたら error 終了することにしよう。

* papillon の commandline argument について
	papillon hoge.papillon だったら、同じ directory に constant な source を置く。
	papillon Hoge.papillon だったら、同じ directory に
	papillon src/Hoge.papillon だったら、src/Papillon.hs に。
	また、明示的に dir を指定した場合、つまり、
	papillon src/Hoge.papillon dist のようにした場合には、
	dist 以下に、module の directory 構造を作成し、
	存在する場合にはそのまま、そこに Papillon.hs を置く。
	とりあえず、最後の version だけを作った。

* char と position について
	conflict については2つの道がある
	まずは prefix をつけるということ
	もうひとつは chars と position の名前を上書きできるようにすること

**************************
*  ドキュメント関係      *
**************************

* とりあえず簡単なチュートリアルを書いてみよう

* cabal haddock について
	説明も入れてみようかな
	haddock の書式について調べる必要があるな

* homepage 関係
	sakura VPS に papillon を install すれば、
	インタラクティブなページが作れるかな

**************************
*  パッケージ/開発関係   *
**************************

* ~/local/portage/dev-haskell/papillon/ ディレクトリを整理
	古いバージョンは消してしまおう

* 機能追加やバグの修正など、些細な修正以外は branch を作ることにする
	作業用の branch を作り、問題が無ければ、master に marge して
	branch を消すという作業習慣をつけよう

**************************
*  後々やること          *
**************************

* 出来上がったコードを hlint で refactoring
* unicode への対応
* たとえば (Node l t):tree で warning が出ないようにする
	つまり、もしもそのパターンが反駁不可であるならば、
	_ -> ... を取らないようにする
	とりあえずは VarP と WildP のみを含むものを check しよう
	ひとつしか constructor を持たない物もそれらと同様に扱う必要がある
	これにはおそらく reify が必要になるので後々することにしよう
	これは th が True のときだけ reify を見るということで実現可能だろう

**************************
* 目を通して消す         *
**************************

* 以下をやるのだが、次は module Hoge (...) where の ... の部分を分けよう。
	中を ',' で separate すれば良いし、逆は intercalate ",\n\t" をすれば良い。
	まずは、とりあえず、parser の方だけでやり、
	すぐに "(\n\t" ++ intercalate ",\n\t" some ++ ") where\n" をしてしまおう
	parser のなかで '(', ')' の対応を見て行く必要があるかもしれない。
	'(', ')', ',' 以外の文字の並び str とその 3 つが出てくれば良いのだろう。
	str を ',' で区切ったものを strs とすると、ひとつの要素は、
	str ('(' strs ')')? または '(' str ')' となり、これを ',' で
	区切ったものが全体となる。最後の ',' はあっても良い

	それとも (...) 内を String としてそのまま出すか、
	あるいはもっとちゃんとパースするか。
	パースする必要は無いよな。
	いじる必要が無いわけだから。
	(...) の ... の部分だけを出してもいいし、
	あるいは今のままでもいいかもしれない。
	')' _:spaces 'w' 'h' 'e' 'r' 'e' を認識させようかな。

* papillonFile の返り値をきれいにする
	(String, [String], [String], [String], String, DecsQ, String, Bool)
	といった感じにしようかな。内訳はそれぞれ、
	(pragma, moduleName, exportList, imports, preD, decs, postD, needApp)
	といった感じ。
	imports と preD は分けなくてもいいかもしれない。
	そうすると
	(String, [String], [String], String, DecsQ, String, Bool)

	プラグマ、モジュール名、エクスポートリスト、インポートリストが必要だ。
	([Pragma], ModuleName, [Export], [Import], String, DecsQ, String, Bool)
	といった感じか。

	data Pragma = LanguagePragma [String] | OtherPragma String
	type ModuleName = [String]
	data Export
		= ExportV String | ExportT String (Maybe [String])
		| ExportM ModuleName
	data Import = Import String Bool ModuleName (Maybe String) Bool
		(Maybe ImportList)

	上記はちょっとやりすぎ感がある。
	([Pragma], ModuleName, String, String, DecsQ, String, Bool) でいい気もする。

**************************
* 左再帰について         *
**************************

* position を (Integer, pos) のようにしよう

* catchError で DirectLeftRecursion を catch して ParseError を
	わかりやすいメッセージをつけて返せるようにしよう。

* ParseError を返す、dummy の grow を定義し、そこからメッセージを返すようにする。
	catchError をつけて、
	if isDirectLeftRecursion e then grow else throwError e
	のようにしよう

* grow の中身を作る。
	呼び出しのほうでは、grow rule (\x d -> d { hoge = x }) (Left pe)
	のような感じ。
	grow の関数自体は複雑

* 直接左再帰のみに対応することにする
	grow 関数を定義する
	runStateT rule d { hoge = Left LR } のような感じにする
	... `catchError` \e -> case e of
		LR -> grow rule (\x d -> d { hoge = x `runStateT d })
			(throwError Fail)
		_ -> throwError Fail
	のような形にする
	grow 関数はどうしようかな
	とりあえず、parse = ... where のなかで定義するようにしよう
	まずは、ParseError = ... | DirectLeftRecursion のようにしようかな
	そして、some :: Char = c:some { c } のような rule を評価して、
	Left DirectLeftRecursion error が返るようにしよう。
	そのあと、catchError で DirectLeftRecursion を catch して ParseError を
	わかりやすいメッセージをつけて返せるようにしよう。
	ParseError を返す、dummy の grow を定義し、そこからメッセージを返す
	ようにする。
	grow の中身を作る。

* 左再帰の解決はどうしようかな
	pappy はこれにひどく時間がかかっていた
	解決するかどうかを switching できるようにする
	また O 記法でどのくらいになるか調べる

	するとしたら、とりあえず直接左再帰だな。
	間接左再帰まで対応しようとすると大変そうだ。

	もっと直接的な方法を使おう。
	同じルールで同じ入力を検出した場合にどう動くか。
	ルールと入力のペアも Derivs に入れておく?

**************************
* plain style について   *
**************************

* 問題が発生
	value <- [0-9]+ / '(' expr ')';
	expr <- value;
	のような表現では、expr の型が定まらないため無限ループになってしまう

* plain style について
	plain style の一番の問題点としては、再帰的な定義が使えないこと。
	次に問題なのはひとつしか選択肢が無くても Either X () のようになって
	しまうこと。

* 一番下のパーサとして [a-zA-Z] のような表現ができるようにしよう
	lower <- [a-z];
	lowers <- [a-z]+;
	のような感じにできたらいい。

	StateT char >>= \c -> unless (c `elem` cs) (throwError ...)

* plain style で &, ! を使えるようにする <- refactoring が必要だろう
* plain style で	"hoge" と、'h' を使えるようにする
* ';' を省略できるようにすれば、PEG をそのまま読み込める。

* import Applicative の読み込み条件に PlainExpressionHs の有無も入れる。
	あるいは、いっそ warning は無視することにして、import Control.Applicative
	は無条件で入れてしまうというのもありかもな。

* 今は、<*> を export しているが、他の方法が無いか考えること