google / google/codeworld

Auto-fit syntax to the grammar before building

オープン
#890 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
discussion
主要言語
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.

![9772171e-ff49-44db-bac7-557738d97222](https://user-images.githubusercontent.com/544744/55412831-204ca680-5536-11e9-80ae-fe6283d42e93.gif)

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

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。