3 ms·

happy to answer hazel questions; ive been working on hazel as cyrus' phd student for the last four years, and am currently working on moldable projectional inte

happy to answer hazel questions; ive been working on hazel as cyrus' phd student for the last four years, and am currently working on moldable projectional interfaces for live programming in hazel. here are some of the things ive added to hazel: https://github.com/hazelgrove/hazel/pulls?q=is%3Apr+author%3Adisconcision https://github.com/hazelgrove/hazel/pulls?q=is%3Apr+author%3... 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 https://www.youtube.com/watch?v=-DYe8Fi78sg&t=12707s

jakewins 2y ago
This is probably naive but: How does this differ from something like “declare a type, implement it with methods that all throw NotImplementedException”? As in, is this “just” a less boilerplate-heavy version of that, or is it more capable?
- 7h3kk1d 2y ago
  You can play with it at https://hazel.org/build/dev/ https://hazel.org/build/dev/ but programs don't "crash" when they're incomplete so "1 + 5 + ?" will evaluate to "6 + ?" in the editor. So your program can evaluate as far as possible with the holes. If you're using Java and throw NotImplementedException you lose all context to what did work.
riffraff 2y ago
Congrats, this seems fun and neat! But small question related to https://hazel.org/build/dev/ 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?
- nrabulinski 2y ago
  (Haven’t worked with hazel and I couldn’t find much in the documentation so this may be wrong) 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.
- 7h3kk1d 2y ago
  If you put the cursor on it you'll see an error message at the bottom. In this case the case expression is inexhaustive because it's only handling lists of size 0, 1, and 2.
conartist6 2y ago
Nice to make your acquaintance! I've spent the last four years working on similar tech, though I'm not affiliated with any school or company. I've gone over to the Hazel implementation many times for inspiration and just to check in on the progress. 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://github.com/bablr-lang/, https://discord.gg/NfMNyYN6cX https://discord.gg/NfMNyYN6cX
- disconcision 2y ago
  good questions! both will be addressed soon with david moon's new tylr version (tylr being the underlying syntactic engine for hazel). the new tylr is designed to take a grammar as a parameter; we have a javascript grammar and a partial rust grammar, and are planning editor integrations. the new model also eschews the backpack (the yellow thing that contains matching delimiters) in lieu of inserting missing delimiters as 'ghosts' in a way that always shows the exact parse that the semantics engine is using, but also doesn't prevent typing normally. the current backpack solution is the result of trying to balance natural text editing with mandated syntactic correctness and it definitely has proved to have some rough edges... more on the new system soon
  - conartist6 2y ago
    The homepage assures me that Hazel's mission is to take semantic editing and ensure that the core of the experience is text editing in the most literal sense, for example by allowing you to make selections that cross-cut the tree. I just don't understand why!!! Both the current UX and the proposed UX are less useful and less semantic than the editing tools I already use. 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?

jakewins 2y ago

This is probably naive but: How does this differ from something like “declare a type, implement it with methods that all throw NotImplementedException”? As in, is this “just” a less boilerplate-heavy version of that, or is it more capable?

7h3kk1d 2y ago
You can play with it at https://hazel.org/build/dev/ https://hazel.org/build/dev/ but programs don't "crash" when they're incomplete so "1 + 5 + ?" will evaluate to "6 + ?" in the editor. So your program can evaluate as far as possible with the holes. If you're using Java and throw NotImplementedException you lose all context to what did work.

riffraff 2y ago

Congrats, this seems fun and neat! But small question related to https://hazel.org/build/dev/ 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?

nrabulinski 2y ago
(Haven’t worked with hazel and I couldn’t find much in the documentation so this may be wrong) 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.
7h3kk1d 2y ago
If you put the cursor on it you'll see an error message at the bottom. In this case the case expression is inexhaustive because it's only handling lists of size 0, 1, and 2.

conartist6 2y ago

Nice to make your acquaintance! I've spent the last four years working on similar tech, though I'm not affiliated with any school or company. I've gone over to the Hazel implementation many times for inspiration and just to check in on the progress. 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://github.com/bablr-lang/, https://discord.gg/NfMNyYN6cX https://discord.gg/NfMNyYN6cX

disconcision 2y ago
good questions! both will be addressed soon with david moon's new tylr version (tylr being the underlying syntactic engine for hazel). the new tylr is designed to take a grammar as a parameter; we have a javascript grammar and a partial rust grammar, and are planning editor integrations. the new model also eschews the backpack (the yellow thing that contains matching delimiters) in lieu of inserting missing delimiters as 'ghosts' in a way that always shows the exact parse that the semantics engine is using, but also doesn't prevent typing normally. the current backpack solution is the result of trying to balance natural text editing with mandated syntactic correctness and it definitely has proved to have some rough edges... more on the new system soon
- conartist6 2y ago
  The homepage assures me that Hazel's mission is to take semantic editing and ensure that the core of the experience is text editing in the most literal sense, for example by allowing you to make selections that cross-cut the tree. I just don't understand why!!! Both the current UX and the proposed UX are less useful and less semantic than the editing tools I already use. 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?