uguisu-dev / uguisu Goto Github PK

現行のparse::Nodeからanalyze::Nodeを生成する際のReferenceノード部分の動作:

1. Referenceノードの識別子を解決して参照先ノードを見つける。
2. Referenceノードの代わりに参照先のノードを置く

これだと変数参照の部分で文法エラーが出た場合にソースコード上とは違う位置を指すようになってしまった。
そのため、Referenceノード自体は残すように変更する。

まずはどんな方法があるかを考えていく

関連技術

• インターフェースとアップキャスト(C#など)
• Rustのトレイト

オーバーロード

fn add(x: number, y: number): number {
  return x + y;
}
fn add(x: string, y: string): string {
  return concatStr(x, y);
}
var a: number = add(1, 2);
var b: string = add("hello", " world");

• 配列のサイズは可変にする
• 要素の型は全て同じでなくても良い (要検討)

構文

var x = 5;
var = [1, x, true];

• analyze
• run

以前に型チェックを行っていて型が正しいと分かっている場合は、型チェックは不要なためスキップできると良いかも

つらくなるため

構文イメージ

if cond {

} else if cond {

} else if cond {

} else {

}

構文

a == b
a != b
a < b
a <= b
a > b
a >= b

• 変数宣言のキーワードをvarのみにする
• constは再代入不可の変数として使用されているが、将来的に定数として使用される可能性があるかもしれない

今の環境から値を取得する時に親のフレームまで見に行く必要はないため (動的束縛の仕様となっていれば必要)。

変数

構文解析の段階

変数の初期値が付いてるかどうかに関係なく全体を変数宣言として扱う。
パーサーで扱いやすいため

意味解析の段階

変数宣言に初期値が付いてる場合は、変数宣言と代入の2つのグラフノードを生成する。
→ 初期値付きと初期値無しの変数宣言を生成するようにした。

変数宣言のタイミングでは型推論を行わない。
代入のタイミングで、変数宣言に対して型推論をする。

関数

変数と同じ感じで

宣言された変数や関数の使用方法

宣言された変数や関数を使う際は、必ず参照ノードを経由して宣言ノードにアクセスする。
これはモデルとの整合性を保つための意味合いもある:

• 参照できる名前を持っているのは宣言ノードのみであるため。
• 参照は識別子を介して参照する。

Craneliftの雰囲気は何となく分かった。
これを使って全てのコードを生成することは困難な気がする。

一旦はインタプリタとしてスクリプトエンジンを構築し、言語の設計を進めていくことにする。

https://github.com/marihachi/uguisu-lang/tree/interpreter

そもそも仕様がまずいかも
機能の読み込みに、外部関数の宣言をやめる？

再現コード

fn main() {
    main = 1;
}

Node.jsみたいにC互換のライブラリを読み込めると便利かも
libloadingクレートを使えば動的ロードできる？

構想

interface Item {
  search(name: string): bool;
}

class File {
  name: string;
}

impl File : Item {
  search(name: string): bool {
    return this.name == name;
  }
}

class Directory {
  name: string;
}

impl Directory : Item {
  search(name: string): bool {
    return this.name == name;
  }
}

interface構文

• メソッドを宣言できる。

class構文

• フィールドを宣言できる。

impl構文

• classへのメソッド実装を記述できる。
• classへのinterfaceのメソッド実装を記述できる。

細かい部分

• インターフェースへの実装が見つかれば(=インポートされている)、クラスはインターフェースを実装してる扱いにする。
• インターフェースの実装の他に、クラスに同じシグネチャのメソッドが実装されてる場合がある。
  • クラスへの実装とインターフェースへの実装でメソッド実装が競合した場合の扱い
    • 同居できないで良いかも。同居できるとしたら、クラスへの実装よりもインターフェースの実装が優先される？
  • 実装が競合した時のために、インポート構文では個別にインポートできる必要がある。

案1.

use core;

fn main() {
  const x = 1;
  core.print_num(x);
  core.assert_eq(x, 1);
}

use core::print_num;
use core::assert_eq;

fn main() {
  const x = 1;
  print_num(x);
  assert_eq(x, 1);
}

https://github.com/uguisu-dev/uguisu/tree/develop

Parser (および Scanner)

状況: 実装済み

ソースコードからASTを生成するモジュール

TODO

• 連続したsuffix演算子
• comment line
• comment range
• call args
• special char (\nなど)
• assign (+=など)

Analyzer

状況: 進行中

静的解析を行うモジュール

• 型チェック
• break文が使用できる場所かどうかのチェック

TODO

• エラーメッセージを改善
• #69
• break文が使用できる場所かどうかのチェック

Runner

状況: 実装済み

ASTとその他の情報を使ってスクリプトの実行を行うモジュール (インタプリタ)

TODO

• 未定義の変数宣言
• ビルトイン関数
• 静的スコープにする

+=の形の演算子

構文

true
false
const flag = true;
fn func(x: bool) { }

今後の拡張性のため。

これまで

$ uguisu filename.ug

これから

$ uguisu run filename.ug

仕様に言語バージョンを与えて互換性を維持しやすくする。
プロジェクトで言語バージョンを指定するイメージ。

構文案

var x: Option<number> = null;

// cast interfaces
var player: Char = Char { };
var y: Option<Drawable & Position> = player;
y = null;

nullリテラルとOption<T>型の追加。
Optionを明示しない限りはnull値を許容しない。
Option<T>とするのでGeneric型(インターフェース)もサポートする方が自然？

バイナリデータを操作したい時に要りそう

• 実行時のブロックごとにフレームを追加したら、変更した変数の値が消えてしまった。
  → そもそもこの実装は間違ってた。このスタックは環境を分けるために使う。

• HIRコードの生成時に変数とシンボルの対応関係は解決済みなので、そもそも実行時はシンボルの管理をレイヤー状にする必要はないかもしれない
  → 関数コールのときは環境が別になっていてほしいから、レイヤー状にはなっていないといけない。

• 今の環境から値を取得する時に親のフレームに見に行く必要はない。