Hacker News Reader

Comment by runeks | Hacker News Reader

Is a difference in a default option really enough for a language to take the place of another? And if it's not just a change in a default option, but the removal of laziness, we lose something, which will make the choice less obvious.

I think it's more likely that, if dependent types prove really useful, Haskell will adopt these, and people will adapt their code, rather than port everything to a new language.

As far as I can see, Idris is too much like Haskell to take its place. Porting thousands of libraries to a new language is a huge effort, so a huge advantage is required, which I don't see Idris offering.

View on HN

A System F type system can't be replaced by a dependent type system without affecting existing code. There is no way to turn the libraries in Haskell into libraries in dependently-typed Haskell without "porting them to a new language" and all the work that entails.

This is 100% false. The Calculus of Constructions is a superset of System F. You may be thinking of the fact that if you want your type system to be sound when interpreted as a logic, then termination must be guaranteed (which would break backwards compatibility). Dependent types and totality are often found together, but are in actuality orthogonal features.

>And if it's not just a change in a default option, but the removal of laziness, we lose something, which will make the choice less obvious.

What would we exactly lose?

>As far as I can see, Idris is too much like Haskell to take its place. Porting thousands of libraries to a new language is a huge effort, so a huge advantage is required, which I don't see Idris offering.

That is true, though. Perhaps Rust is the safer bet, even if it lacks many nice things. The sum is probably quite a lot better still.

> What would we exactly lose?

We'd lose composability and clearer code. This[1] section of the Haskell Wiki contains a good example.

In short, with something like this:

    any :: (a -> Bool) -> [a] -> Bool
    any f lst = or boolLst
      where boolLst = map f lst

the compiler can produce reasonably optimal code, because it doesn't have to convert the entire [a] to a [Bool], because of lazy evaluation -- when or encounters the first True, the map f lst expression stops being evaluated because of lazy evaluation.

[1] https://wiki.haskell.org/Non-strict_semantics#Why.3F

I don't know Idris so this syntax is probably wrong, but by reading the docs for a short while, this would be

any : (a -> Bool) -> Lazy List a -> Bool

... which would make it as performant and clearer than Haskell's any, since the laziness is explicit.

Someone with actual Idris experience might tell if it actually would work like this :) I guess we'd have to make sure that the used or function is also lazy.

I was commenting on what the effects would be from removing laziness. I'm not experienced enough in Haskell to know whether making strictness the default option would make sense, although I've seen a quote from Simon Peyton Jones saying he'd do that if he could start over.

Out of curiosity, would you know whether there exists sufficient strictness pragmas in Haskell to translate your example Idris (pseudo) code into Haskell? I often hear about performance/memory usage pitfalls with Haskell laziness, so it'd be really nice if Haskell were able to emulate Idris in this regards, by enabling enough LANGUAGE pragmas to require explicitly annotating types if laziness is desired.

Reply on news.ycombinator.com