
Hazel: A live functional programming environment featuring typed holes - erwan
http://hazel.org/
======
sfvisser
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.

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.

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.

Edit: I see Hazal takes the valid-by-construction approach, which is different
from be-forgiving-but-explicit. Both are approaches worth of experimentation.

~~~
xixixao
My take on designing a language and an IDE together (2015).

Repo: [https://github.com/xixixao/Shem](https://github.com/xixixao/Shem)
Playground: [http://xixixao.github.io/Golem](http://xixixao.github.io/Golem)
Talk:
[https://www.youtube.com/watch?v=HnZipJOan54](https://www.youtube.com/watch?v=HnZipJOan54)

------
kpmah
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:
[http://kevinmahoney.co.uk/ocellator/](http://kevinmahoney.co.uk/ocellator/)

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.

~~~
prezjordan
Phenomenal work, this is really fun to play around with

------
loosetypes
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.

[1] [https://youtu.be/CnbVCNIh1NA](https://youtu.be/CnbVCNIh1NA)

~~~
cyrus_
Andrew is actually joining our group, FP Lab, as a PhD student this fall and
will be contributing to Hazel amongst other things. :-)

------
ellis0n
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)

Code demo:

[https://github.com/web3cryptowallet/Web3CryptoWallet](https://github.com/web3cryptowallet/Web3CryptoWallet)

More info about Animation CPU:

[https://animationcpu.com/](https://animationcpu.com/)

------
avmich
> 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.

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.

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?

~~~
willtim
> should the language catch us making a type error here?

With a statically typed language, the choice is up to you. Every statically
typed language is just a "dynamically typed" language with the ability to
statically assign types. For example, you can type the variable as an "Int" or
for more runtime flexibility, a "Variant" (if using C++).

~~~
avmich
The question here is that a type inference can assign type to a hole but may
get confused if user insists on an incompatible type.

int q // q is considered a hole of int type

q <\- // but we're typing "hello" there

Practicalities ask for the situation to be considered a problem - not of
incorrectly plugged hole (when into "int" place you're putting "string"
value), but of incorrectly previously stated type (it's the original "int q"
which is wrong, should have been "string q").

------
lambdatronics
>we hope that this will allow Hazel to function not only as a structured
programming environment, but also as a structured document authoring
environment!

This is the kind of thing I come to HN to discover! Cool ideas.

------
philip142au
Idris has typed holes, how is this an improvement on Idris?

~~~
dwohnitmok
Indeed many languages have holes. Hazel is different by bundling an IDE with
the language that only allows for direct and valid manipulations on an AST.

You aren't writing code in a text file, but rather in a very constrained
graphical environment.

The bet they're making is that in return for giving up this flexibility you
hopefully get powerful refactoring and code analysis capabilities.

