AiScript Nextに盛り込む変更点を考える

[marihachi]

AiScript Nextをリリースする時に破壊的変更をまとめてしちゃおうプロジェクト。

専用ブランチを用意してそこに追加していく方が良いかも
ブランチ作りました → aiscript-next

これも含めたほうが良いという変更点があれば教えてください
このissueは目次として使うので各問題に対するディスカッションは個別のissueを立てて行ってください

解決方法が定まらない問題や時間のかかる問題は今後の課題とし、このリストからは除外することがあります

やること？

• エラーが発生した時にソースコードの行番号・列番号を表示できるように #144
  • PR 文法エラーに位置情報を追加 #413
  • PR ランタイムエラーの位置を表示 #415
• AiScriptのパーサーを再帰下降のLLパーサーとして書き直す？ #359
  • PR enhance: 再帰下降LLパーサーの実装 #360
• match式の仕様を見直したい #381
  • PR enhance: 再帰下降LLパーサーの実装 #360
• スペースや改行による区切りをやめる？ #402
  • PR 区切り文字の変更 #432
• 名前空間名の再考 #405
• 今後キーワードとして使う可能性のある識別子は予約語として登録する #407
  • PR 予約語のバリデーション変更 #421
• 各構文で改行できる箇所の見直し #412
• AiScriptNext 構文ドキュメントを更新 #455
  • PR Next用にドキュメントを修正 #456

[FineArchs]

空白・改行による区切りの再検討もそうですかね？

[marihachi]

個別にissue立てます

[FineArchs]

Json:parseがエラー型を返すようになったのでいつかJson:parsableを廃止しようと思っていたのですが、このタイミングでいいですかね？

[salano-ym]

残すと問題ありますか？

[FineArchs]

Json:parsableでチェックしてからJson:parseすると単純に考えて倍の時間がかかるので非推奨にしたいんですよね
非推奨にしても残すと使い続ける人がいると思うので出来れば消したいです。

[salano-ym]

廃止するならチェックにif Core:type(v)!='error' ...と書くのは少しくどいのでエラー用の構文/演算子/関数等あると便利だと思います。

[FineArchs]

構文案

catch(v) {...}
// if Core:type(v)=='error' {...}に同等

[salano-ym]

投げてないものをcatchするのは少し変な気がします。
成功と失敗で別々に処理できる方がいいのと成功時が先に来る方が分かりやすいかとif Core:is_ok(v) {} else {}
??、?.等もあると良い？

ついでに標準ライブラリ等でnullを返している所を全部errorにしてしまうのもいいかもしれません

[FineArchs]

if Core:type(v)!='error' ...とif Core:is_ok(v) ...だと書きやすさがあまり変わらないような…？
??、?.は私も欲しいですね

ついでに標準ライブラリ等でnullを返している所を全部errorにしてしまうのもいいかもしれません

これをやる前にnullとerrorの使い分けを考えておきたいです。やろうと思えばnullをerrorに統合出来るくらいには境目が曖昧なので

[salano-ym]

大雑把に考えると値の存在を期待しているかどうかで分けられると思います。
Json:parseが返すnullは正常値なのでResult型で言うところのOk(null)とError()のような。

let a = {v: 1}
<: a.w

と書いたとして、wにデフォルト値としてnullが設定されてると考えるならnull、そもそも存在しないwにアクセスすべきでないならerror。

[FineArchs]

#403 #404
個別issue立てました。

[FineArchs]

名前空間名の再考もしたほうがいいかもしれません。
主にCore:とUtil:の違いがわかりにくいという問題があります。

[marihachi]

ブランチ作ったので、ここにマージしていこう
aiscript-next

[marihachi]

#403 #404 ってNextじゃないといけないですか。破壊的変更ありますかね

[FineArchs]

#403 #404 ってNextじゃないといけないですか。破壊的変更ありますかね

（isが用語化する点を除き）ほぼ無いと思います。Nextじゃなくても良さそう

[FineArchs]

@marihachi とりあえずここに書きますが、新パーサーのバグ報告です。
//のコメントがある行の末尾の改行が無視されてしまうようです。
例えば

<: 'hoge' // comment
<: 'huga'

のようなスクリプトで

Multiple statements cannot be placed on a single line. (Line 2, Column 1)

のようなエラーが出ます。

[marihachi]

ありがとうございます
修正しますね

[ikasoba]

関数同士の比較を行えると便利そう？ #527

結構あとから提案しちゃったけどどうかしら

[FineArchs]

@marihachi 新パーサーのバグ報告です。

[hoge//
//
]

のように配列リテラル内で//が改行を挟んで２つ続くとunexpected token: NewLine (Line 2, Column 3)のエラーになるようです。

[FineArchs]

改行トークンが２つ並んでしまっている可能性？

[marihachi]

配列リテラル内で改行って2つ並べられましたっけ

[marihachi]

コメント行のコメント部分はスペースと同じ扱いで、最後の改行はそのまま改行として解釈されます

つまり、
a//abc[改行]
は
a[スペース][改行]
と同じ扱いです。

この仕様を変えると他で不都合がありそうなので、
変えるなら配列リテラル側ですかね

[FineArchs]

配列リテラル内で改行って2つ並べられましたっけ

あー本当だ

[

]

単に２連改行しただけでもエラー出ますね

[FineArchs]

配列以外にもオブジェクトや括弧でもなるみたいですね
改行をセパレータ代わりに使ったり、長いコメントを書く場合にまる１行以上使いたい場合があるので２連（以上）改行は許容したいです

[marihachi]

• 配列リテラルの[の後および]の前には0個以上の改行を配置する
• オブジェクトリテラルの{の後および}の前には0個以上の改行を配置する
• グループ式の(の後および)の前には0個以上の改行を配置する
• 配列リテラルで1つ以上の連続した改行をセパレータとして使用できる
• オブジェクトリテラルで1つ以上の連続した改行をセパレータとして使用できる

この感じで変更してみます

[marihachi]

やっぱり、グループ式内の改行は式内でバックスラッシュを使うと改行できる仕様とぶつかるのでやめておきます

[marihachi]

バックスラッシュの処理も今うまく機能していないので、改善が必要そうです