Hacker News Reader

Comment by jpe90 | Hacker News Reader

I remember wondering why "return" is in the Monad class when you can just use "pure" from Applicative, and why (<>) and "mapped" both exist, so it's cool to read the historical explanations here.

They are all logical, but will unfortunately add to the burden of new learners who read books and guides that contain obsolete references. I know a lot of the material I learned with will be confusing when examples start spitting out compile errors. I didn't see if there are efforts to account for this with some custom error messages that notify you why the obsolete code no longer works and suggests how to fix it, but I think that would be helpful.

Edit: It looks like that concern was already raised and addressed, glad to see it.

View on HN

If you are interested in "Haskell, but with a nicer standard library", Idris 2 might actually be an interesting choice. The Idris 2 prelude very much feels like a cleaned-up version of the Haskell prelude, and all the fancy dependent and quantitative type stuff is mostly "opt-in".

For example, in Idris 2, the `[ foo | x <- bar ]` syntax is not just a "list comprehension", but a "monad comprehension", and `map` is not specialized for lists but it is actually what `fmap` is in Haskell. There is also other interesting shorthand syntax like `!foo` which is equivalent to something like `do x <- foo ; x`.

The fact that it compiles to Chez Scheme and has a fairly easy-to-use FFI is even nicer.

Would I deploy it in production yet? No. But the language is trying to be fundamentally practical and user-friendly while still being dependently- and quantitatively-typed. And in my opinion, it's succeeding so far! It also has a language server, so you can get advanced interactive editing features in pretty much any code editor that supports LSP.

Oh, and there's no `return` in Idris 2, only `pure` :)

Your description of a monad comprehension in Idris reminds me of computation expressions in F#[1]. Looks like I have one more programming language to dive into!

[1] https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

A closer analogue is probably do-notation, which comprehensions are syntactic sugar for. Comprehensions can be terser for simple expressions, but for anything longer, do notation is generally more readable.

Isn’t haskell’s list comprehension can be used for monad comprehensions as well with a language extension? I remember using that once.

I want to like Idris - as a language it does so much right - but I still feel a little burnt. A few years ago were exciting times; Idris 1 had hit 1.0 and was humming along nicely, there was excellent tooling available, & Type-Driven Development with Idris had been published - a real printed book about practical coding with dependent types! Could reliable software be far behind? Would I maybe get to develop somewhere that took software engineering seriously in my lifetime?

And then, with the possibility of success on the horizon, the Idris folk(s) got distracted by the QTT hype and decided to abandon ship so they could start on Idris 2. And, like, don't get me wrong - the QTT stuff is cool, and I'm a Rust fan in part because getting to encode linearity in your types is a real superpower - but it's so depressing that the world of practical dependent types feels just as far away now as it did ten years ago, after getting so excited about it five years ago. And it underscores what might be a bigger problem: at the end of the day - and by the Idris FAQ's own admission - Idris is a research project into practical dependent types, and Edwin Brady is an academic. Which means that when he gets interested in some other area of research, he's free to just...do that instead, or start over on Idris n+1, and leave Idris 1, 2, 3 ... n to wither.

GHC has monad comprehensions with an extension, {-# LANGUAGE: MonadComprehensions #-}

GHC has an enormous amount of machinery to infer types and check equality automatically. I wonder if Idris has anywhere near that much. Automatic inference is why Haskell resisted dependent types until quite recently, though there were already some cases that it couldn't do automatically.

As for pure vs return, that's because the typeclass system was rearranged pretty recently. Before that, Monad instances weren't necessarily also Applicative. "return" was kind of cool in that you could write what looked like imperative subroutines that returned values.

!foo in Idris sounds like foo >>= whatever or whatever =<< foo in Haskell.

> GHC has an enormous amount of machinery to infer types

Idris 2 has more or less no type inference at all. I think maybe type inference for dependent types isn't decidable, or something like that?

But I know that they are interested in adding inference to Idris 2 in certain cases that can be proven to work correctly.

It's definitely a deficiency in the Idris user experience vs the Haskell user experience.

> !foo in Idris sounds like foo >>= whatever or whatever =<< foo in Haskell.

Idris has >>= as well. But see here for a nice demo of ! and other "do"-related syntax: https://idris2.readthedocs.io/en/latest/tutorial/interfaces....

Yep, type checking clearly can't be decidable, since the type system is turing complete.

Imo inference is a bit overrated anyway. I find annotations to be very useful.

There's a series of steps here:

- "Static type annotations are too verbose, dynamic languages allow you to avoid the ceremony." - "But Hindler Milner type systems can infer the types, so you usually don't have to write the type annotations!" - "Writing type annotations is useful anyway, because it serves as valuable documentation, makes reasoning about the program easier, and results in more useful type errors."

Thinking about it more now, there's another step: - "If you have good type inference, you can use editor tooling (eg the LSP) to automatically insert the type signatures for you!"

Top level type annotations in Haskell are very helpful, but with no type inference, you would also have to annotate every intermediate term in the program, which would be intolerable. Remember that the programs are essentially typed lambda calculus, so every term must have a type. Normally you let the compiler figure out all or almost all of the types.

Part of the usefulness of top level annotations in Haskell is that if your program has a type error, inference can fail in multiple ways. I.e. the unification algorithm might assign type T to your function F and chug along happily until it runs into a conflict in some unrelated part of the program, then throw an unhelpful error message in the case where T wasn't the type that you intended for F. By annotating F with the type you really want, you get an error message that does a better job pinpointing the problem.

This is less of an issue in ML, since ML's type system is less general than Haskell's, so the inference algorithm can't go as crazy, and you usually get good error messages even without annotations.

Yeah, I definitely wouldn't want to argue against having type inference at all. I agree that you don't want to annotate every single local definition (although I'd probably lean towards annotating more often than most).

I'm more saying that I'm fine with type system features that break global inference, as long as there's still local inference that's usually good enough in practice.

Right, but local inference is also complicated. So the question is how much of it Idris manages to do without manual annotations. It's not even limited to local definitions with names. If you fully annotate "a=b+2" you get something like "a:int = a:int +:(int->int->int) 2:int". The compiler makes an expression tree and every node in the tree has to get an annotation, either from the source text (i.e. manually) or through inference.

One of the most important lessons learned by the Haskell community is that we shouldn't worry about whether complete type inference is possible. We should worry about whether type inference can be maintained in the easy cases, while falling back to explicit annotation for the hard cases. All of rank-n types, GADTs, type families, even basic type classes, break complete type inference. The solution has always been to document the limitations, draw as clear a line in the sand as possible, and then go on and introduce those features. This doesn't affect the usability of the language.

What does affect the usability of the language is when (a) the line in the sand isn't very clear from an end-user point of view [see simplified subsumption in GHC 9, for example], or (b) the line is on the wrong side of simple features [see monomorphic local bindings, for example].

I guess what I'm saying is that Idris having minimal type inference is kind of terrible, and the excuse that it's not decidable for dependent types is a flimsy one.

There are many things I like about Idris 2. I think I'll be more inclined to take it seriously as a practical language once it has the equivalent of Hackage, hoogle, and cabal. Right now I can't even read the standard library docs, I have to browse the github source. And I have no idea how I'd go about depending on a package. I'm sure I could figure it out, but I assume at this stage it's fairly tedious.

The return/pure distinction is due to history, I believe. The Monad typeclass was defined before the Applicative typeclass.

Part of the fun of being a research language is that you don't know everything up-front!

Monad and Functor were first, if I remember correctly Applicative made its debut when Parsec became popular. For a long time, the hierarchy was »Functor ===> Applicative, Monad is independent«.

We made Applicative a superclass of Monad around 2015, and since then return has been a historical artifact (with a dangerously misleading name).

ty for this history! I write haskell at work but with an honestly middling understanding of the category theory that goes into what typeclasses are supersets of other typeclasses. Mostly because we use an overly verbose version of Prelude. So it's wild to me that these mathy bits were not always set in stone!

Reply on news.ycombinator.com