Great! I'm convinced designing a functional language and IDE side-by-side will result in greatly improved ergonomics. The Hazel playground breaks for me (Safari), but the direction looks promising.<p>One of my own (nearly abandoned) toy projects is something similar. It's not easy — at least to me it wasn't — to design a language that is forgiving on as many aspects as possible. Both syntactically and semantically. Turning every error into a warning during development time and keep the impact as local as possible. Type errors turn into implicit holes of type bottom, just make sure the IDE is explicit about it.<p>One of the tricks I applied is to use indentation style syntax (like Haskell/Python). Now syntax errors only break one level of code. Preventing the IDE from coloring the rest of your buffer red because you still need to type out your closing parenthesis.<p>Edit: I see Hazal takes the valid-by-construction approach, which is different from be-forgiving-but-explicit. Both are approaches worth of experimentation.
I also experiment a lot with structural editing. My latest project is an editor for a lisp-like language for building small audio synth programs: <a href="http://kevinmahoney.co.uk/ocellator/" rel="nofollow">http://kevinmahoney.co.uk/ocellator/</a><p>Hazel looks fantastic - I don't think I've come across it before. I think an obstacle structural editors have to becoming more widely adopted is that they start out very general and don't immediately solve a problem that people have. You can usually build little toy programs but not much more. What I've tried to do is to focus on creating an editor for a small DSL that helps with a specific problem.
For folks interested in this sort of thing, Andrew Blinn gave a neat talk[1] pertaining to structured editing at Racketcon, which credits Cyrus’ work with Hazel.<p>[1] <a href="https://youtu.be/CnbVCNIh1NA" rel="nofollow">https://youtu.be/CnbVCNIh1NA</a>
Cool things! Good solution is ACPUL maintains holes in your code, and programs never stop or crash
Incomplete expression is reflected in only one node of the code and the whole system continues to work correctly (as architecture design)<p>Code demo:<p><a href="https://github.com/web3cryptowallet/Web3CryptoWallet" rel="nofollow">https://github.com/web3cryptowallet/Web3CryptoWallet</a><p>More info about Animation CPU:<p><a href="https://animationcpu.com/" rel="nofollow">https://animationcpu.com/</a>
> Hazel is a live functional programming environment that is able to typecheck, manipulate, and even run incomplete programs, i.e. programs with holes. There are no meaningless editor states.<p>Suppose I have an assigned variable, which later I plan to use. When I'm about to use it, but not yet did, I have a hole. Suppose before filling the hole I've realized that the current type of the variable - and assigned value - is wrong, so I want to use the correct type.<p>Can hole-oriented programming help me with that change of mind? When we use a program, using a configuration file but also allowing command-line overrides of values, we assume last-time command-line overrides have precedence over values in the configuration file. Can we consider later-time use of variable with different type overriding the previous type, which now considered to be incorrect? Of should the language catch us making a type error here?
>we hope that this will allow Hazel to function not only as a structured programming environment, but also as a structured document authoring environment!<p>This is the kind of thing I come to HN to discover! Cool ideas.