/ 最近 .rdf 追記 編集 設定 本棚

脳log[20140924] Go言語をインストールした。



2014年09月24日 (水)

最終更新: 2015-01-12T01:26+0900

Go言語をインストールした。

ifが値を返さないとか条件演算子がないとか*、エラーを nilと比較することはできるけど || や && のオペランドにはならないとか、配列の最後の要素の後ろにカンマを置かずに改行するとカンマがないって理由でコンパイルエラーになるとか、ああ、この独善的融通の利かなさ、Rubyではないな googleだから Pythonがこうなのか?という感想。

 beni/lexer/javascript.go (2014-09-24, 4.9KiB)

ベースは /shjs/lang/sh_javascript.js

ミクロな感想

  • gitコマンドがなくて >go get "github.com/..." に失敗した。手コピインストール……
  • golangの regexpパッケージが re2そのままらしくて一番単純な先読みすらサポートされていないので一部のパターンを簡略化した
  • マッチング処理が行ごとではなく全文一括なので改行をまたぐケースをひとつのパターンの中に押し込んでシンプルにした
  • \wとか \sの差異を気にせずそのまま使ってる
  • インポートは lexerディレクトリ丸ごとされてるんだけど、lexer/all.goにファクトリを登録しておかないと有効にはならない
  • JavaScriptの正規表現リテラルが鬼門
  • regexp.MatchStringは文字列の全体をテストするメソッドではない
  • htmlフォーマッタに(未実装だけど)いろいろフラグがある。メソッド内で分岐するのでなく単目的一本道の処理を組み合わせてインターフェイスとフラグを満足するオブジェクトを構成したいと思った。フラグの組み合わせは膨大になる可能性があるので事前に定義したクラスとファクトリ関数は現実的でない。どういう方法があるだろうか。vptrと vtblをカスタムする? 実行時コード生成? たまらんね、他には? Scalaには何か、型付きのダックタイピングをサポートするやり方がなかった? あったとしてそれが解決策かは知らないけど、とにかく、間接レイヤーを挿入して自分でディスパッチしたりするのでなく、たとえそれがソースコード上のことに過ぎなかったとしても、入力と出力を直結して答えを出してる感じが欲しい。
  • 色分け対象となるトークンに、LiteralStringDouble、LiteralStringSingle、LiteralStringHeredocなどが、また、総称的に扱われるのであろう LiteralStringや Literalがある。lexerの方では識別できる限り詳細なトークンを指定したいであろう。では、テーマの方で本質的な差異のないトークンをまとめて同じ色に塗ることにしようか。それを判断するには言語に関する情報が必要だ。
  • 実質的にパターン最初に ^ が必須で、ポインタを1文字ずつ進めながらマッチするパターンを探していくのは
    • regexp.FindStringSubmatchメソッド呼び出しコストがかさむ
    • ^ では、与えられる部分文字列の最初を検出することができても、単語の切れ目(始まり)でない部分を除外することができない。
    • regexpパッケージのメソッド群には検索開始位置/検索終了位置を指定する引数が見当たらない。BMatch関数と同じ不備か?(20090808p03.02)。それがないと結果が変わってきたりする。re2には \K参考 も戻り読みもないけど \b(単語の切れ目)だけは影響しそう。
    • それと「FIXME: need to emit 'ch'?」と書かれている部分とが合わさって、ハイライト対象のどの部分もとりこぼしなく識別してマッチしないと、意図しないマッチが生まれたり対象の一部が(標準)出力から消えたりということが起こる。
    • マッチした位置/未試行/マッチ無しを記憶しておくのが効果的だと思う。(検索開始位置を指定できないと \b のマッチの仕方が不定だけど)

ただのデータファイルなので言語の勉強にはならないよね……。フレイバーの違いライブラリの違いに足を取られるのがわずらわしいしもどかしい。CLRと MSIL?

* つまり、if (cond) return A else return B みたいな冗長性(returnの繰り返し)と無駄な構造化を強制されるわけ。

 何かを true/falseと比較することはもちろん nullと比較することもまずしたことがない。そうする理由は、trueが falseではないすべての値であったりする Cのことや、null(それと NaN)は nullであること/ないことをテストすることはできても二つの nullが同じものであることがありえない SQLのことが念頭にあるからだ。そして、Goだからこういう書き方で OKなんだというような考え方はしない(http://vvvvvv.sakura.ne.jp/ds14050/diary/20140815.html)。信じられない仕様を強制するもんだ。

 なぜ余計な物を強制されるのか。ケツカンマは便利だからと許容されているもの(だが俺は嫌いだ)であって、強制するというならそれは削除させる方向に向かうべきものだ。

参考 [[サクラエディタふぁんくらぶ part14|http://anago.2ch.net/test/read.cgi/software/1294526851/656-663]]