News for hackers. Stuff that matters.
Re:Hindley-Milner Type Inference (2012) by GregarianChild on Friday July 10, 2020 @04:05PM (#23795792)
Why not let the computer do the work? My programming flow in Ocaml has always been:

(1) Hack until I've got something stable. Note: at the start of coding I typically don't quite know what the right abstractions are, so a lot of code (and associated types) are in constant flux.

(2) Once program is stable, wrap it in a module, let the compiler work out all types and put them in as module interface.

That gives me the best of all possible worlds: type annotations at abstraction boundaries but you don't have to type them out. Writing out explicit types inhibits fast change. I wish the languages I'm using at the moment (Scala, Rust, C++) allowed a flow like that. Alas, full type inference stops being possible with more expressive typing systems.

Re:Hindley-Milner Type Inference (2012) by MaxBarraclough on Friday July 10, 2020 @06:53PM (#23797531)
> Why not let the computer do the work?

Because a program's types can serve as part of its documentation.

Re:Hindley-Milner Type Inference (2012) by hombre_fatal on Friday July 10, 2020 @08:40PM (#23798309)
The other benefit of top-level/function annotations is that they ensure that your mental model of the code is consistent with what the code actually does.

So many times I will accidentally return 42 or Result<Result<42>> when I mean to return Result<42>. With annotations, my error is instantly obvious. Otherwise I accidentally have a function that returns Result<Result<number>> and it may lead to a very weird error message when I use `foo().map(_ + 100)` somewhere else.

That's letting the computer doing more work, not less of it. Relying too much on inference can bow back into the human doing more of the work to figure out what the types actually are in a given spot.

Re:Hindley-Milner Type Inference (2012) by lmm on Friday July 10, 2020 @11:01PM (#23799096)
Sometimes an IDE hover can be the best of both worlds - the information is there when you want it (and guaranteed to be accurate since it's using the language compiler's own type inference), but not taking up space when you don't want it.
Re:Hindley-Milner Type Inference (2012) by eru on Saturday July 11, 2020 @12:26AM (#23799496)
That helps, but it's orthogonal to adding type annotations.

The computer can only tell you what types your code _has_ (from inference), but not what type it _should_ have based on your intentions. Type inference can only complain when your code contradicts with itself (on a type level), but can't tell you when it contradicts with your intentions.

If you don't write out your intentions, you'd have to hover over everything to see if the inferred types differ from your expectations.

IDE hover types and collapsible type annotations (and alternatively also collapsible implementation) are still useful as a way to declutter your UI when reading code.

Re:Hindley-Milner Type Inference (2012) by mathgladiator on Friday July 10, 2020 @07:29PM (#23797828)
This is under-appreciated, and as I have aged I have discovered that I prefer the verbosity over brevity. Namely, when mentoring more junior engineers who can barely write code at all.
Re:Hindley-Milner Type Inference (2012) by mrmr1993 on Saturday July 11, 2020 @12:18AM (#23799440)
It doesn't always make sense to plan the types ahead of time; letting the compiler do the work while you code and then creating a nice interface after is a reasonable way to work.
Re:Hindley-Milner Type Inference (2012) by chrisseaton on Friday July 10, 2020 @04:11PM (#23795861)
> let the compiler work out all types and put them in as module interface ... type annotations at abstraction boundaries

Right - that's not global type inference. It's intra-module type-inference.

Re:Hindley-Milner Type Inference (2012) by GregarianChild on Friday July 10, 2020 @04:18PM (#23795958)
I don't understand this objection. OCaml does full program inference. I just prefer to wrap things into modules from time to time. That's a pragmatic choice I make, not a restriction on type-inference.

Aside, when I decide to change where I put module boundaries, full program inference helps too: I just throw away the old module definitions, draw different boundaries and re-run inference.

Re:Hindley-Milner Type Inference (2012) by chrisseaton on Friday July 10, 2020 @04:21PM (#23795988)
I'm not objecting to anything. This is how I thought most people used inference in OCaml.
Re:Hindley-Milner Type Inference (2012) by amw-zero on Friday July 10, 2020 @07:09PM (#23797671)
You do need to write the types for records though.
Re:Hindley-Milner Type Inference (2012) by NOGDP on Friday July 10, 2020 @11:23PM (#23799199)
Is there anything specific that you find Rust is missing in this regard?
Re:Hindley-Milner Type Inference (2012) by eru on Saturday July 11, 2020 @12:27AM (#23799500)
I think Rust deliberately limits type inference to information available in a single function?
Re:Hindley-Milner Type Inference (2012) by steveklabnik on Saturday July 11, 2020 @12:15PM (#23803227)
Yes.