Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hazel: A live functional programming environment featuring typed holes

hazel.org

Post reply on HN
Print view View original

61–70 of 88 posts

Re: Hazel: A live functional programming environment featuring typed holes

#61

Post by School-Cotton »

TwentyPosts wrote: post #58
Joker_vD wrote: post #37

Earlier quoted context omitted.

func TestWhatever(t *testing.T) { // ...lots of code _, _, _, _, _, _, _ = resp3, resp4, fooBefore, subFoo, bar2, barNew, zap2 } Like, I get it, it's a good feature, it caught quite a lot of typos in my code but can I please get an option to turn this checking off e.g. in unit tests? I just want to yank some APIs, look at their behaviour, and tinker a bit with the data.

All of this could've been prevented if Go just had two ways to compile. Debug and release. The go devs decided against this since they didn't want to build a highly optimizing (read: slow) compiler, but that is missing the point of developer ergonomics.

It could be prevented in an even simpler way: emitting warnings.

Most people nowadays ban building with warnings in CI and allow them during local development. But “CI” was barely a thing when go was developed so they just banned them completely. And now they are probably too stubborn to change.

Re: Hazel: A live functional programming environment featuring typed holes

#62

Post by mrkeen »

jlkuester7 wrote: post #51

Not sure if I have just spent too much time in the JS/TS world and so I have forgotten the pain in this area in proper compiled languages, but to me it seems like needing "typed holes" smells like maybe there is some abstraction missing in your codebase. I prefer to have code layered in a way that my inflection points happen across well defined interfaces. Then I can make changes one layer at a time in increments tha…

> maybe there is some abstraction missing

A hole is the answer to this question. You ask the compiler "what abstraction is missing?" and it tells you.

Re: Hazel: A live functional programming environment featuring typed holes

#63

Post by School-Cotton »

Joker_vD wrote: post #37
diegs wrote: post #28

Earlier quoted context omitted.

And then you have Go, which won't even let you compile code with an unused variable...

func TestWhatever(t *testing.T) { // ...lots of code _, _, _, _, _, _, _ = resp3, resp4, fooBefore, subFoo, bar2, barNew, zap2 } Like, I get it, it's a good feature, it caught quite a lot of typos in my code but can I please get an option to turn this checking off e.g. in unit tests? I just want to yank some APIs, look at their behaviour, and tinker a bit with the data.

The good news is if you use Nix or Guix it’s relatively easy to hack your local build of the compiler to demote the unused variables hard error to just a warning.

Re: Hazel: A live functional programming environment featuring typed holes

#64

Post by jimbokun »

argiopetech wrote: post #53
spockz wrote: post #45

Earlier quoted context omitted.

Agda (2) has a similar feature called holes. Very similar to Haskell’s `nothing` and Scala’s `???`. The difference is that because of the dependently typedness the compiler can sometimes even fill in the code for you based on symbols in scope.

Haskell has also had typed holes for several major versions now. Any underscore or name beginning with an underscore (to include values and types, unsure about kinds) gets an informative error message describing the type of the name, e.g.: Found hole `_' with type f (Free f b) and relevant bindings, if applicable: Relevant bindings include >>= :: Free f a -> (a -> Free f b) -> Free f b (bound at holes.hs:28:3) f :: f…

Could this be used to build an editor for Haskell like the one for Hazel?

Re: Hazel: A live functional programming environment featuring typed holes

#67

Post by arthurbrown »

imglorp wrote: post #65

Interesting syntax: all the "let" bindings end with "in", eg let comparison = (0 == 0, 0 1, 1 >= 1) in Anyone know why "in" keyword?

this is the syntax for variable binding in ocaml.

Hazel appears to be written in ocaml and mentions being "ml-like" on the site

Re: Hazel: A live functional programming environment featuring typed holes

#68

Post by disconcision »

conartist6 wrote: post #50
disconcision wrote: post #19

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%3... and here's me speaking last week about using typed holes and the hazel language server to help provide code co…

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

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

Re: Hazel: A live functional programming environment featuring typed holes

#69

Post by dietr1ch »

LandR wrote: post #42
dietr1ch wrote: post #35

Earlier quoted context omitted.

Brady has a presentation about Idris where he shows Type-Driven development (where you write code that could typecheck with some holes and you get the compiler to help you figure out the missing types for your "whatever/something" untyped variables) https://youtu.be/X36ye-1x_HQ?t=5m15s

This is awesome, but I find that syntax so hard to follow, but that's just me being unfamiliar with it I guess.

It happens, but all syntax families eventually become familiar, even on LISP you eventually stop worrying about the parentheses as you learn how to grok the code.

Re: Hazel: A live functional programming environment featuring typed holes

#70

Post by politician »

Joker_vD wrote: post #37
diegs wrote: post #28

Earlier quoted context omitted.

And then you have Go, which won't even let you compile code with an unused variable...

func TestWhatever(t *testing.T) { // ...lots of code _, _, _, _, _, _, _ = resp3, resp4, fooBefore, subFoo, bar2, barNew, zap2 } Like, I get it, it's a good feature, it caught quite a lot of typos in my code but can I please get an option to turn this checking off e.g. in unit tests? I just want to yank some APIs, look at their behaviour, and tinker a bit with the data.

This example isn't particularly good code. If you've got "lots of code" that names a bunch of variables (e.g. using ':=') that are never referenced AND you have a good reason not to do so (which I doubt: given this context it looks like an incomplete test), then predeclare these 'excess' variables:

   func TestWhatever(t *testing.T) {
        var resp3, resp4, fooBefore, subFoo, bar2, barNew, zap2 theirType

        // ...lots of code
   }
Alternatively, use '_' where they are being defined:

   // instead of
   resp2, err := doit()

   // use
   _, err := doit()
If, and given this context it's likely, you're checking these errors with asserts, then either change the name of the error variable, predeclare the err name (`var err error`), or split it into multiple tests instead of one giant spaghetti super test.

That said, in a code review, at a minimum, I would probably ask that these variables be checked for nil/default which would completely eliminate this problem.

Post reply on HN