一番簡単にはパッケージ毎にincludeした一枚ファイルをつくって、パッケージ利用側でパッケージのinclude箇所に対応するパッケージの一枚ファイルを埋め込んでいく、とすると名前空間が簡単に衝突しますね…だめか…
コンパイラ側でファイル単位の名前空間の取り扱いをするつもりではあるものの、こうしておくとAOTコンパイルにしたときに個別のファイルを.oにして保管しておいてもsymbolのvisibilityを基本hidden、pubをつけたものだけdefaultにされる、というのと直接対応させられて楽なので。
実行結果こんな感じです。下部を見ると、runコマンドが実行する直前のログだと絶対パスなのですが、mimiumからのstrerrは不正確な相対パス(おそらくmimiumがおかれている/usr/local/binからの？)になっています。
https://gist.github.com/t-sin/c5ff1adc538bca0eaae09fbb6f29c3cd
https://gist.github.com/t-sin/c5ff1adc538bca0eaae09fbb6f29c3cd
よーやっと構造体の実装を終えて0.4をリリースしました。https://mimium.org/en/docs/users-guide/language-specification/grammar-rule/#type-alias
ファイルシステムの抽象化をやろうとしてmmmpm止まっちゃってたので、いったん別ブランチとしmmmpmのmasterは動くところに戻してます。
環境変数を導入するにあたって、シンタックスシュガー付きのAST->要素を減らしたASTの2段構えの構成に変えようと思ってやり始めたら永遠に終わらなくなってしまいました、、、
たとえば
+++ b/src/compiler/mimium.yy
@@ -306,9 +306,9 @@ typeargs: typeargs ',' types { $1.emplace_back(std::move($3));
$$ = std::move($1); }
| types { $$ = std::vector<types::Value>{$1};}
-structtype: LBRACE strutypeargs RBRACE { $$ = types::Struct{std::move($2)}; }
+structtype: LBRACE opt_nl strutypeargs opt_nl RBRACE { $$ = types::Struct{std::move($2)}; }
-strutypeargs : strutypeargs ',' strutypearg { $1.emplace_back(std::move($3));$$ = std::move($1); }
+strutypeargs : strutypeargs ',' opt_nl strutypearg { $1.emplace_back(std::move($3));$$ = std::move($1); }
| strutypearg {$$ = std::vector<types::Struct::Keytype>{$1}; }
strutypearg : SYMBOL TYPE_DELIM types { $$ = types::Struct::Keytype{std::move($1),std::move($3)}; }みたいな変更するとよい感じなんでしょうか。いま屋外でLLVMがなくビルドして試せないのでイメージの相談です。
音楽つくろうとしてみてたんですがパッケージマネージャについて、曲あるいは作品をパッケージとして公開したい場合にパッケージ名の被りを許したい気持ちがしますね。あるいはタイトルやジャンルによるインストールが必要なのかもしれないです。
https://github.com/t-sin/mimium-ambient-song/
https://github.com/t-sin/mimium-ambient-song/
そもそも実はstructの初期化は
hoge = {field1 = 100,field2 = 200}見たくフィールド名を明示する方が型判定の処理がしやすいので仕様変えちゃおっかなあと迷ってるとこだったりします
多忙の件、お察ししておりました。気長にやりましょうー
パッケージマネージャに関してはここ数日ちょっとアーキテクチャこうしたらいいのではと考えてることがあって、ちょっと図を作ってみました
要するに、パッケージマネージャが解決したファイルパスを返却するのではなく、読み込んだソースファイル自体を返却する方式の方が、コンパイラをファイルシステムから可能な限りagnosticな実装にできるのではないかという話なんですが(そもそものメインのファイルシステムの読み込みの時点でまあファイルシステム依存しちゃあいるのですが)。今後読み込むソースの数が増えたときに並列処理に通用するかとか、あとAoTコンパイルしたバイナリキャッシュの扱いどうすんだみたいな話もありますが。
コンパイラにファイルシステムを意識してもらうのはコンパイル以外のことをする感じになりますものね…