npm公開パッケージ

rule-with-wildcard

trie+wildcard

0.1.0 -> 普通のtrie

0.2.0 -> ワイルドカードあり

0.3.0 -> ワイルドカードに合致させない文字の指定、ワイルドカードのエスケープ

↑1.0.0までの開発はこんな感じかな

README作成用のfeature ブランチやテスト自動化用のfeature ブランチも、メインの開発とは別に一旦作成して...

全部のfeature ブランチを集約した上で1.0.0 公開かな

自動テストはjest？

類似パッケージ see also

ライセンスはMIT

eslint とかPrettier とかどうする？

参考URL

npmパッケージの公開

typescript パッケージの公開

github のブランチ

テスト自動化

eslint prettier

GDNative に関連して、typescript からオブジェクトコード生成

typescript のコンパイラを参考にする？javascript もtypescript として解釈できて、typescriptはjavascript にできるから、javascript にしてから扱ったほうが良い

node.js でやるとしてimport されているモジュールをどうする？

Node.js のソースコードを参考に作る？

Node.js はV8 エンジンを使っている。V8 エンジンはjavascript をbytecode に変換している。bytecode に変換後を考えたほうが良い？

ES3 までしかサポートしていないらしい

Node.js を参考に作る？（ネイティブ）モジュールは必要、オブジェクトコードに変換するやつ

昨日AbortController でreadfile がすぐにabort できない件について、直せないかなとnode.js のコード見ていた。

いろいろ見ていて、モジュールの定義はjavascript で書かれているっぽいことはわかった

N-API がネイティブアプリ（？）を作るのに使うモジュールかな（上のtrie はそれでも良いかも）

上のドキュメントに、v8 エンジンを埋め込んで使う人向けのドキュメントも紹介されている。

オブジェクトコード作るとして、アーキテクチャの違いとか考慮するのあれだから、LLVMにするべき？それならv8 のbytecode まで落とさずにtypescript コンパイラとかの抽象木から行くのもやっぱり有り？けれど、やはりbytecode までいったほうが構文（？）も少なくて良い？javascript の抽象木（？）からという手もある

LLVM　にするとして、Node.js のモジュールとかその他モジュールをどう組み込むかやおね。あと、共通ライブラリとしてロードできる状態である必要もあるし

参考にできそう？

LLVM について、まずはこのあたりを読むべき？

今日か昨日かその前の土日あたりにドラクエX やろうと思っていたけれど…まぁ良いかな、今のサポート仲間でもう少し経験値稼いだほうが良いかなとか考えていたかな

けれど他にやりたいこともあるし、まぁ良いかな と

前に集合論的に構築した数を使ったり、高階な（？）型推論をするプログラミング言語を作ろうかとしていたけれど

全部集合論的に表現したものは試しに作ってみても良いかも…と思ったが関数は無限集合になるからそのままでは無理かな

数は集合にして、後続関数を使うとかかな。それなら後続関数だけとか、使う関数を絞ったものにするとか？←つまり原始帰納的関数とか？

それとは別に、最近は純粋な型無しラムダ計算のプログラミング言語を作ろうと考えている

変数は使える（同じ（α変換の違いを除いて）ラムダ式を埋め込むという意味）、リテラルも使えるけれど、シンタックスシュガーのような感じで、実際はチャーチエンコーディングで構文としては本当にラムダ式だけ

Haskell のdo 記法にならって、手続き型言語っぽく書けるシンタックスシュガーも用意する（あくまでシンタックスシュガー）入出力もHaskell と同じように、最終的な評価結果である値を処理系が解釈して入出力を行う。ファイルディスクリプタ的な数値を管理してファイル入出力も考える

インタプリタは書けなくはなさそう（せっかくだからocaml を使う？）正規形があるのにβ簡約の仕方によっては止まらない場合もあるから、幅優先探索する？

と思ったが、評価順により停止したりしなかったりが変わる場合とかも考えると、単純にIRにするのは難しそう？

合流性を考えると、正規形がある場合は、どのような評価順で計算しても、そこから正規形まで簡約する方法があるはず。なので、β簡約する場所をランダムに選ぶ方法で良いかも

BFS だとメモリをけっこう消費する気がするし、インタプリタもランダムで良いかな。まずはインタプリタ作ってみよう

typescript（javascript）の非同期処理とか、実際の処理では処理系の内部にキューのようなものを持っているのだと思うし、ラムダ計算のやつをIR に落とすのも、インタプリタでやっていることをIR で表現すれば良いかな

具体的には下のような感じで落とし込む？

ラムダ式は、それに対応するデータ構造を作る命令に置き換える

変数として保持しておいたラムダ式を、コピー（α変換）してそれが使われているところへ埋め込む

β簡約を行う関数を用意する。ここでもラムダ項のコピーが必要だから、上と合わせてラムダ項のコピー（α変換含む）を行う関数を用意する。構文木を作成する際に束縛変数には数値を割り当てて、埋め込み先のラムダ項に含まれる数値より大きい数値になるように、埋め込むラムダ式の束縛変数の数値を加算する（つまりα変換）

最後に、正規形になったラムダ項を解釈する部分をIR で書く←ここが大変そう