字句解析時のエラー - Scala で TAPLを勉強しつつ LLVM コンパイラを作る日記

エラーコード

1000 unterminated string constant starting at error1000.d(2)
     %s(%d)から始まる文字列定数が終了していません。
1001 invalid UTF-8 sequence
     UTF-8ではない文字が現れました。
1002 unterminated /* */ comment
     コメントが終了していません
1003 unterminated character constant
     文字定数が終了していません。
1004 Hex digit expected, not 'g'
     'g'ではない、16進数があるはずです

d言語のエラーをいろいろ出して番号を振ってみました。
字句解析中のエラーは基本的に正規表現にマッチしなかった場合に文字列が残ってしまってたら、その文字から予想されるエラーを出力するとよいようです。

"ではじまって、EOFに行ってしまったがゆえに、エラーなら、ただSyntax Errorとか出力するのではなくて
文字列定数が終わってません的エラーを出すとよいみたい。

あとは、エラーは例外で飛ばしたほうが良いのか、それとも溜め込むといいのかとかあると思うのですけど、
１つだけエラー出力して終わるなら例外投げてOKで、複数のエラーを出したい場合はベクターに溜め込んで飛ばして処理進めて復帰を試みる
パニックモード的なことをするといいんでしょう。でも、文字列が終わらなかったーって場合はどうしようもないし、UTF-8シーケンスでないよー
ってときは、それなりにあるか。

ま、そんなかんじ。ってあきらめるな俺。

えーと、UTF-8シーケンスに関しては読み飛ばしてくとそれなりになんとかなるかもと。

あと、シーケンスがなかったら、エラー的なトークン返してやって、カッコの終わりがないよ、;がないよ、とか出すのは悪いことではないかなと。
;はなくてもよいことにしようと考えているので出さないつもりですけど。;はマルチステートメント用ってことでいいとおもうので。
マルチステートメント用でもなくて、必要なときに入れればOKが一番短く書けるはずだし。

というようなことをあとでまとめてきれいに書こう。あと、式の構文解析中のことと、インタプリタの場合は実行時エラーについても書く。でも、最近作ってみてた言語には文字列とか入ってないよというのもあって、文字列も入れて、数値も浮動小数点オンリーだけではなくーってやって、とかやると大変だやりたくないと嫌な気分になるとモチベーション下がるのでこつこつ書いてあとで最適化する。コメントも入れる必要あるよなと。#とかどうするといいのよ？ほんとのところ？/++/のネスとコメントはどうなのよ？/**/がネストできればいいのかもしれないし、なんも変わり無しでもいいのかもしれない。うーん。それより、コメントが前置演算子となるか、後置演算子となって、構文木内に入ることのほうが重要なのではという気がしています。ブロック前置コメントとブロック後置コメント、前置１行コメントと後置１行コメントがあると式にコメントも含まれて良いなと。QTあたりが参考になるんだよなと。

あとは、リードマクロ的なものは速度的に落ちそうなのと複雑になるのでやらないほうがよい。toStringとかserializeの仲間なんだろうけども、演算子の優先順位に即して()をつけたりして出力を変えたりする。また、CONSはドット対だけで出力できるところをあるルールに則っていればドット記法を使わないで出力するといったこともやりたいのでその辺をかんがえる。どうしてやりたいのかというと、プログラムの操作をデータとしてパターンマッチングして行った後出力したいからだ。プログラムを生成したあとのソースは実行できないと意味ないし、カッコだらけでは困る。

それで、仕様をみてこれを見て実装すればよいだけという状態のものがあるとよい。で、その仕様どおりのソースが複数あるといいよなと。リファレンス実装ってやつなのかな？

ということを考えつつ、作り方を書くことも同時に考えるとわけがわからなくなるのでした。そのつど、エラー処理についても考えて対応すればいいのだろうけど、苦手なんだよなぁっと。そこが最大の弱点なので、（最近は体力ないのも弱点になってるけど、英語できないとか、日本語だめとかもっとあるな）とにかくエラーを克服するのだ。で、なんだっけ？えーと、そのつど、エラー処理も考えるようにしていきましょう。インクリメンタルエラー処理と。そのときは時間が掛かるけど、あとで考えるとそれ以上に何倍の時間をとられるので、プロトタイプ作成時ならいいけど、ちゃんとしたプログラムを書くときはエラー処理は先に考えないといいプログラムがつくれないっと。エラー処理を楽しくやればいいのだーっということだわな。エラー処理は可能性の収束である。いろいろ考えが広がったあとに、それなりの正常論理を考え、そのあとエラー処理をして纏め上げるというのではなくて、正常論理を考えつつエラー処理も考えつつ順番に立ち止まることなく考えればよいはずなのだ。でもまぁ、とにかく苦手なところは辛いのでやりたくないから、苦手意識をなくすことが大切だ。

カッコの実装はめんどくさいだけなのでいいけど、エラー処理は自信ないんだよなぁ。完璧！って思えない。。。そのためのテストコードなんだろうけど。
あと、クォートをどうするか、、、。識別子とシンボルで終わりにしていいのか？そのへんも一度決めてみないといけない。そのためのフォーマットを作らないといけない。結論にいたるまでの考えをまとめておきたい。しんどい。。。ふー。

と、やりたいことはあるけど、うまく出来ない僕はなんて能力がないんだろうと思うわけでした。
うーむ、しかしエラーの一覧見ても不安感がよぎるなぁ。完璧な実装を作って自信を持たないと駄目だな。
四則演算の完璧な実装を作る練習するか。。。そうすれば、慣れて自信を持てる。

ということで、だらだらと、考えてきましたが、四則演算の完璧な実装を１００回くらいやって自信をつけようと思います。
１００ｘ１０分で２００分くらいかな。最初は偉く時間かかるかもしれないけど。あとからは５分とかになるだろうし。うんそうしよう。