Hacker News Reader

Comment by skybrian | Hacker News Reader

That's how it works, but I'll point out that just because you can leave out type declarations in a Hindley-Milner language doesn't mean you should.

Compilers are good at deducing types from a function's implementation, but humans will find them easier to understand if they know what the function's inputs and outputs are supposed to be before attempting to figure out how the implementation does it. Error messages will be better, too.

View on HN

On the other hand, from my limited experience in F# (but I guess OCaml would be similar) I found that, when you let the type inference algorithm do its thing, it can help you realize that your function is more general than you thought. For instance, you write a function for lists of strings and in the end it can actually work on any list.

Maybe it's trivial, but I found it helped me thinking about refactoring/reusing my code in contexts I didn't expect.

You can still annotate the expression with the general type once you know what that type is. :)

Is it that hard to figure out that your method is generic?

And what is this “end” you speak of? You don’t know what next year’s requirements are.

Don’t confuse the implementation with the contract. That’s a variant of duck typing. If you need to do stringy things to the data later don’t advertise genericity. People will start using your function and then you’ll have to make a new method because they own the contract now.

> If you need to do stringy things to the data later don’t advertise genericity. [...] People will start using your function and then you’ll have to make a new method because they own the contract now.

I agree that my point doesn't really apply to functions that are part of some kind of API.

Still, type inference is not duck typing: the former happens at compile time, unlike the latter.

> Is it that hard to figure out that your method is generic?

Well, it is not if you decide it to be generic from the start. What I was saying is that sometimes you start with "concrete" implementation, but the type inference helps you thinking about refactoring it to maximize reuse. Something like "hmmm, right now this method has signature 'a -> int -> 'b... I wonder if I can turn it into 'a -> ('b -> 'c) -> 'c and remove this other method that looks pretty similar..."

My experience is that people who think that never worked with a language where inference is principal and complete (aka, "good") and/or have poor editor support.

In languages that are still reasonably close to HM and that have decent editor tooling, like OCaml, leaving the type out in the implementation is the common practice. You only write them down in the external API (along with the documentation).

There is an experimental phase where you really don’t know. Hygiene indicates you should codify the types after you’ve sorted out the real constraints.

Got me thinking. Are there tools out there that solidify "auto"s into their types? Type inference is fast but what if I want to eventually lock it down and prevent accidental changes in type by adding a decimal or whatnot.

An IDE could do it, but the risk for local variables seems smaller compared to the confusion when someone accidentally changes the input or output of a function.

The Jetbrains IDEs let you do this pretty easily, at least for Python and Scala (and presumably for Java & Typescript.)

In my mind, this is a bit of an "experimentation smell". It means you're experimenting backwards because you are uncertain of the domain in which you are operating. It's something I've learned to notice as a symptom that I'm flailing around in confusion, and that I need to step back and understand the problem better.

Clarify the domain so that you know the types of everything up front, and your work is more than halved.

I find that writing some code is often the best way to clarify the domain and figure out the types.

>Clarify the domain

Could typing out code be a good way to clarify the domain for some people, and/or some of the time?

Except that in my experience you never really understand the problem or domain until you try to build the software.

"Write one to throw away" and all that.

I definitely agree with this. Too often while learning Scala I’ve found myself scratching my head at some piece of code and wondering how to modify it because the typing system is inferring something I don’t expect it to.

Along with that, the compiler is going to do less work too. That means faster compilation and better programmer experience with the language.

How is it less work for the compiler? It still needs to figure out the return type to make sure it matches.

Type inference algorithms generally have two operations, verification and inference. Verification is faster and more complete (i.e. never misses an existing suitable type) than inference because it works from the biggest assumption that is a (hopefully) suitable type for given expression. Hindley-Milner combined with Algorithm W is really brilliant because it makes inference as performant as verification as the constraint solver is integrated in the inference process, but it does not work for all type systems; inference continues to be inferior when H-M is not applicable as is.

Or put another way: Compilers are good att figuring out what a function _can_ do. But humans need to specify what it _should_ do.

Types aren’t always the right tool for that though. It would be interesting to see what could be done by integrating testing and typing, letting one inform the other.

An interesting middle ground here is when the editor can annotate the function signature's types for you, with code lens type features. Of course this only works for people who happen to be in such an editor.

Another issue I ran into recently was you can add a new type to your program, and break existing code. Where the type inference was able to deduce the type, and your new type appears to also be compatible, and now things don't compile and it is very mysterious why not!

There can be some interesting big wins by leaving types off when possible though, like super easy refactoring. Just start passing ints to a big chain of functions and you are done. No need to change the signature of a big chain of functions.

Reply on news.ycombinator.com