and here's me speaking last week about using typed holes and the hazel language server to help provide code context for LLM code completion: https://www.youtube.com/watch?v=-DYe8Fi78sg&t=12707s
and here's me speaking last week about using typed holes and the hazel language server to help provide code context for LLM code completion: https://www.youtube.com/watch?v=-DYe8Fi78sg&t=12707s
As in, is this “just” a less boilerplate-heavy version of that, or is it more capable?
Here are some of the biggest questions I have:
Do you have any plans to bring editor gaps to languages other than Hazel?
Why is the Hazel editor first a text editor? E.g. it seems 100% happy to let a single poorly judged keystroke create an unbalanced brace or quote pair when it has much more semantically correct options for the next state it could generate...
P.S. Feel free to come check out BABLR: https://github.com/bablr-lang/, https://discord.gg/NfMNyYN6cX
For example in VSCode if I type ( the editor inserts () -- it's actually not a text edit in the sense that the code I produced doesn't map 1:1 to the keys I pressed. No, what actually happened there was already a semantic edit. It was quick and efficient. One keypress. Having a busted document is a worse experience than that, and having a document which is in a sort-of-busted-ghost-mode is also a worse, less semantic experience than I already have. Why would I want either of those experiences for myself or others?
in general though i have mixed feeling about making structured editing more text-like; the above is just about trying to patch a hole in existing structured editors, which doesn't in-itself improve on text. i think we can do better than that; we're exploring more radical directions in a separate project. but i do think it is interesting to see how close to regular text entry we can stay while always maintaining a well-formed (though incomplete) parse state which we can use to constantly run type-checking and evaluation.
the current model partially succeeds in the above, but at some significant usability cost, including the fact the the backpack obscures what the actual underlying parse state is. the ghost model i'm describing can basically be thought of a generalization of the vscode parentheses insertion you describe; it just works for every multi-delimiter form (eg when you insert 'let' you get ghosts '=' and 'in', with appropriate holes inserted). the utility is (A) the same as an incremental parser in a language server (you get semantic feedback in every state), but because of the ghost/hole insertions it's crystal clear what the parse state is that you're getting feedback from. but yeah the current version doesn't live up to that standard
Recovering from bad parses is the state of the art in the industry right now, but it suffers from the "garbage in garbage out" problem because the user's intent is lost. In point of fact it is never captured in the first place! When you say that typing `let` ghosts out should all that other stuff, that's based on pure assumption. The state of the editor would look just the same if the user was part way through typing out the word `letter` which they intended to use as an identifier. No technology in the world can make things right after the user's intent has been lost.
The real way forward, the direction nobody is looking, is how to make tools that are more like musical instruments. An instrument doesn't guess at your intention and then aim to please you, but rather it amplifies the importance of each decision and impulse that go into playing it, making the player more expressive then they could have been otherwise.
But small question related to https://hazel.org/build/dev/, given
> Non-empty holes are the red boxes around type errors
... why is the case statement in the list example red-boxed?
Because that case is non-exhaustive. It will match a list with 0, 1, or 2 elements, but the last arm matches a list with exactly 2 elements, not 2 or more, so as soon as you get to 3 or more elements, there’s no code to execute.