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 that are small enough to still be able to reason about. But maybe I am totally mising the point of typed holes!
Hazel: A live functional programming environment featuring typed holes
51–60 of 88 posts
Re: Hazel: A live functional programming environment featuring typed holes
#52Haskell has type holes. There are plugins that give you code actions to complete them, split case, etc. I love type holes. Agda has them too and they're more powerful there: https://agda.readthedocs.io/en/latest/language/lexical-struc...
For me Idris has best type holes.
[1] - https://www.manning.com/books/type-driven-development-with-i...
Re: Hazel: A live functional programming environment featuring typed holes
#53This is semi-related to one of the killer features of Eclipse that never really made it into any large-scale systems: the ability to run incomplete or broken code. The Eclipse Compiler for Java had a special feature that it could generate bytecode for nearly any file, including those that were utterly broken. It would mostly work, and you could incrementally work on unit tests alongside the code being developed. It w…
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.
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 (Free f a) (bound at holes.hs:29:8)
g :: a -> Free f b (bound at holes.hs:29:14)
In the first argument of `Free', namely `_'
Very useful for working your way out of a situation where the specific incantation to get to the right type isn't obvious.Examples from [0].
Re: Hazel: A live functional programming environment featuring typed holes
#54This is semi-related to one of the killer features of Eclipse that never really made it into any large-scale systems: the ability to run incomplete or broken code. The Eclipse Compiler for Java had a special feature that it could generate bytecode for nearly any file, including those that were utterly broken. It would mostly work, and you could incrementally work on unit tests alongside the code being developed. It w…
Haskell has something like this with -fdefer-type-errors: https://downloads.haskell.org/ghc/latest/docs/users_guide/ex... $ cat foo.hs something = to be done x = x + 1 wat = x "¯\\_(ツ)_/¯" main = print "hi" $ ghc --make -O foo -fdefer-type-errors && echo sucesfuly compoiled && ./foo [1 of 1] Compiling Main ( foo.hs, foo.o ) foo.hs:2:13: warning: [-Wdeferred-out-of-scope-variables] Variable not in scope: to :: t1 -> t…
Typed holes (but not the defer- option) have been enabled by default for some time now. They're an immediate go-to when scratching my head over types. I prefer them to the type error output, not only because they give better suggestions, but also because they can be named (_a, _conversionFunction, etc).
Re: Hazel: A live functional programming environment featuring typed holes
#55This is semi-related to one of the killer features of Eclipse that never really made it into any large-scale systems: the ability to run incomplete or broken code. The Eclipse Compiler for Java had a special feature that it could generate bytecode for nearly any file, including those that were utterly broken. It would mostly work, and you could incrementally work on unit tests alongside the code being developed. It w…
Isn’t this possible with any untyped language? It does sound like a good feature though - very few languages have opt-out type checking. This is much better than opt-in IMO.
Re: Hazel: A live functional programming environment featuring typed holes
#56happy 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…
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?
Re: Hazel: A live functional programming environment featuring typed holes
#57happy 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…
Congrats, this seems fun and neat! 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?
Re: Hazel: A live functional programming environment featuring typed holes
#58Earlier 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 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.
Re: Hazel: A live functional programming environment featuring typed holes
#59Not 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…
Re: Hazel: A live functional programming environment featuring typed holes
#60This is semi-related to one of the killer features of Eclipse that never really made it into any large-scale systems: the ability to run incomplete or broken code. The Eclipse Compiler for Java had a special feature that it could generate bytecode for nearly any file, including those that were utterly broken. It would mostly work, and you could incrementally work on unit tests alongside the code being developed. It w…