[disconcision]

there are approaches to ensure you always or almost always have syntactic validity, e.g. structured editing or error correcting parsing, though of course it's true that the more permissive the system is the more tortured some of the syntactic 'corrections' must be in extreme cases. the approach we're taking with http://hazel.org (which we approximate but don't fully succeed at yet) is: allow normal-ish typing, always correct the code enough to be ran/typechecked, but insert placeholders/decorations to telegraph the parse structure that we're using in case of errors or incompleteness.

[conartist6]

Hazel has embedding gaps but they are language and editor specific.

BABLR takes Hazel's idea and takes it about 18 steps further, potentially making embedding gaps a feature of every editor and programming language.

As long as solutions don't have a way to scale economically they'll be academic, but BABLR makes this not academic anymore.

[disconcision]

interesting!! is BABLR yours? is there a page that talks about your error-correcting/embedding-gaps approach? couldn't immediate find one in the docs. btw new version of tylr (hazel's core editing engine) is multi-language from the ground up, with a javascript grammar underway; new version is not yet online though

[conartist6]

It is! Our approach to error correcting is not to error correct. We instead help the user be highly effective while passing through incomplete states but not invalid ones.

Gaps are present in the embedded code representation, e.g. if · is a gap we would represent the result of parsing `console.log(·)` using a "gap tag" (written `<//>`) in a CSTML document that will look like this: https://gist.github.com/conartist6/75dc969b685bbf69c9fa9800c...

[mackeye]

i saw hazel mentioned forever ago in an eecs 203 lecture and it sent me on a multi-year fp/type theory rabbit hole :) thanks for your work on it!