Hacker News Reader

Comment by kerkeslager | Hacker News Reader

I've never liked this "feature".

What if you forget, not in quotes, to give the second argument? Why on earth would you want to get a type error in a completely different part of the code because you got a function instead of an integer? Wouldn't it be desirable to have the compiler just tell you that you forgot the second argument where you forgot the second argument?

Is it really valuable to be able to do:

    p = add 1

...instead of:

    inc = (\x -> add 1 x)

...or, heaven forbid:

    inc x = add 1 x

...?

I mean, I get the idea, they're following the lambda calculus, but this is one of the things that should have been dropped when they started to expand the lambda calculus to a general purpose programming language.

View on HN

> What if you forget, not in quotes, to give the second argument?

I will get a type error and it will take me 2-3 seconds to figure out what it is about.

> Why on earth would you want to get a type error in a completely different part of the code because you got a function instead of an integer?

Why would it be in a completely different part of the code? At most it would be 2 lines away, but usually on the same line.

> I will get a type error and it will take me 2-3 seconds to figure out what it is about.

You should really screen capture yourself coding sometime. On a large codebase you're lucky if the compiler even runs in 10 seconds.

> Why would it be in a completely different part of the code? At most it would be 2 lines away, but usually on the same line.

Because possibly you return the partial assuming it's a number, and try to use it somewhere else, possibly even in another file.

> Because possibly you return the partial assuming it's a number, and try to use it somewhere else, possibly even in another file.

Sorry, I must've been more explicit instead of implying certain usage patterns. What I meant here is that I have a hard time imagining this happening because I would start working on a function by writing its type signature. Unless my types check out, I won't be able to mark this function as "done" and jump to another part of code. So the situation "you return the partial assuming it's a number" simply can not happen, that's exactly what type checking is for. By the time I use it in another place, it has to already have been type checked.

Sure, but that usage pattern is not without cost. You're basically eschewing relying on type inference across function boundaries.

I think writing out type signatures is The Right Way, but it does take time, and The Right Way doesn't always happen on complicated projects with close deadlines.

You don't have to use type inference everywhere.

But I don't think this is a problem in practice for whatever reason. Haskell does have a lot of "big scary type error, wtf" type problems, but not from currying. Or at least it did have when I last used it 5 years ago, it may have improved in the compiler error message front.

Also it is better than JS anyway (low bar):

    >  function add(a,b) {return a + b}; add(1);

    <- NaN

Reply on news.ycombinator.com