aiscript
aiscript copied to clipboard
AiScript Nextに盛り込む変更点を考える
AiScript Nextをリリースする時に破壊的変更をまとめてしちゃおうプロジェクト。
専用ブランチを用意してそこに追加していく方が良いかも ブランチ作りました → aiscript-next
これも含めたほうが良いという変更点があれば教えてください このissueは目次として使うので各問題に対するディスカッションは個別のissueを立てて行ってください
解決方法が定まらない問題や時間のかかる問題は今後の課題とし、このリストからは除外することがあります
やること?
- [x] #144
- PR #413
- PR #415
- [x] #359
- PR #360
- [x] #381
- PR #360
- [x] #402
- PR #432
- [ ] #405
- [x] #407
- PR #421
- [ ] #412
- [ ] #455
- PR #456
空白・改行による区切りの再検討もそうですかね?
個別にissue立てます
Json:parseがエラー型を返すようになったのでいつかJson:parsableを廃止しようと思っていたのですが、このタイミングでいいですかね?
残すと問題ありますか?
Json:parsableでチェックしてからJson:parseすると単純に考えて倍の時間がかかるので非推奨にしたいんですよね
非推奨にしても残すと使い続ける人がいると思うので出来れば消したいです。
廃止するならチェックにif Core:type(v)!='error' ...と書くのは少しくどいのでエラー用の構文/演算子/関数等あると便利だと思います。
構文案
catch(v) {...}
// if Core:type(v)=='error' {...}に同等
投げてないものをcatchするのは少し変な気がします。
成功と失敗で別々に処理できる方がいいのと成功時が先に来る方が分かりやすいかとif Core:is_ok(v) {} else {}
??、?.等もあると良い?
ついでに標準ライブラリ等でnullを返している所を全部errorにしてしまうのもいいかもしれません
if Core:type(v)!='error' ...とif Core:is_ok(v) ...だと書きやすさがあまり変わらないような…?
??、?.は私も欲しいですね
ついでに標準ライブラリ等でnullを返している所を全部errorにしてしまうのもいいかもしれません
これをやる前にnullとerrorの使い分けを考えておきたいです。やろうと思えばnullをerrorに統合出来るくらいには境目が曖昧なので
大雑把に考えると値の存在を期待しているかどうかで分けられると思います。
Json:parseが返すnullは正常値なのでResult型で言うところのOk(null)とError()のような。
let a = {v: 1}
<: a.w
と書いたとして、wにデフォルト値としてnullが設定されてると考えるならnull、そもそも存在しないwにアクセスすべきでないならerror。
#403 #404 個別issue立てました。
名前空間名の再考もしたほうがいいかもしれません。
主にCore:とUtil:の違いがわかりにくいという問題があります。
四則演算などをCore系関数呼び出しの糖衣構文とするのはパフォーマンス的にやめたいみたいな話があったと思います。 直接Nodeを作って、インタプリタで処理する これも含めますかね
これは構文に影響はないのでいつでも良いかも
ブランチ作ったので、ここにマージしていこう aiscript-next
#403 #404 ってNextじゃないといけないですか。破壊的変更ありますかね
https://github.com/syuilo/aiscript/issues/403 https://github.com/syuilo/aiscript/issues/404 ってNextじゃないといけないですか。破壊的変更ありますかね
(isが用語化する点を除き)ほぼ無いと思います。Nextじゃなくても良さそう
@marihachi とりあえずここに書きますが、新パーサーのバグ報告です。
//のコメントがある行の末尾の改行が無視されてしまうようです。
例えば
<: 'hoge' // comment
<: 'huga'
のようなスクリプトで
Multiple statements cannot be placed on a single line. (Line 2, Column 1)
のようなエラーが出ます。
ありがとうございます 修正しますね
関数同士の比較を行えると便利そう? #527
結構あとから提案しちゃったけどどうかしら
@marihachi 新パーサーのバグ報告です。
[hoge//
//
]
のように配列リテラル内で//が改行を挟んで2つ続くとunexpected token: NewLine (Line 2, Column 3)のエラーになるようです。
改行トークンが2つ並んでしまっている可能性?
配列リテラル内で改行って2つ並べられましたっけ
コメント行のコメント部分はスペースと同じ扱いで、最後の改行はそのまま改行として解釈されます
つまり、
a//abc[改行]
は
a[スペース][改行]
と同じ扱いです。
この仕様を変えると他で不都合がありそうなので、 変えるなら配列リテラル側ですかね
配列リテラル内で改行って2つ並べられましたっけ
あー本当だ
[
]
単に2連改行しただけでもエラー出ますね
配列以外にもオブジェクトや括弧でもなるみたいですね 改行をセパレータ代わりに使ったり、長いコメントを書く場合にまる1行以上使いたい場合があるので2連(以上)改行は許容したいです
- 配列リテラルの
[の後および]の前には0個以上の改行を配置する - オブジェクトリテラルの
{の後および}の前には0個以上の改行を配置する - ~~グループ式の
(の後および)の前には0個以上の改行を配置する~~ - 配列リテラルで1つ以上の連続した改行をセパレータとして使用できる
- オブジェクトリテラルで1つ以上の連続した改行をセパレータとして使用できる
この感じで変更してみます
やっぱり、グループ式内の改行は式内でバックスラッシュを使うと改行できる仕様とぶつかるのでやめておきます
バックスラッシュの処理も今うまく機能していないので、改善が必要そうです