Auto-fit syntax to the grammar before building
- 主要言語
- Haskell
- スター
- 1.3k
- フォーク
- 201
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
One of the advantages of block-based languages is that there are no (or few?) syntax errors. Can we get somewhere close to this in CodeWorld?
The following clip from Desmos shows how, when parentheses are unbalanced, Desmos inserts the close-parentheses that are missing in a grayed-out font, and interprets the expression as if they were already there.

If you disagree with the automatic choices, then sure, you can go type the extra parentheses where they belong. But if you leave them out, it doesn't interfere with running the program.
At one point, I'd enabled CodeMirror's feature where typing the open parenthesis automatically added a close-parenthesis to the document; that did not work very well at all! So I believe it's important that these parentheses are phantoms, which don't exist in the document, but rather are only shown in gray and added at build time. They only remain so long as they are needed to make the syntax correct, and they go away on their own when an explicit close-parenthesis is typed.
Parentheses are just one kind of syntax error Taking this further, one could imagine other tweaks that could be added on this basis to programs which are otherwise syntax errors. The rules are the same: the fix is transient, not stored in the source code, but applied on the fly before building. The changes are only made if the original code is not syntactically correct. When actual code changes are made, the on-the-fly fixes are recalculated from the new code, so anything that was applied before goes away.
コントリビューションガイド
調査の方向性
この issue にはファイル、テスト、エントリーポイントが記載されていないため、まず、コンパイル前に無効なソースを変換する可能性のあるエディター統合とビルドパスを特定します。目的とする一時的な灰色の括弧の動作を、既存のエディターおよびコンパイラーのフローと比較し、その後、レンダリング、編集後の再計算、ビルドの成功についてテストを定義します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- haskell
- 領域
- tooling
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100