2 ms·
> > In Haskell, sometimes this is not possible, because sometimes the type of the subexpression is constrained by something higher up in the AST. > The point i
by xenomachina 9y ago
> > In Haskell, sometimes this is not possible, because sometimes the type of the subexpression is constrained by something higher up in the AST.
> The point is that this constraint always have the exact same format.
I'm not sure how to even parse that sentence. Let me phrase as a question: when trying to understand a given piece of code, how can I determine the type of an expression when its type is someone determined by its sub-expressions (like virtually any other typed language), but sometimes is determined by what consumes it?
The way people can deal with the complex is by decomposing them into smaller parts, understanding those, and then composing that to understand the whole. It seems that in Haskell you are required to understand the whole thing at once, because you can't reliably determine the type of a sub-expression out of context.
> > What are "matched operators"?
> Those are operators that require a matching. Usually parenthesis, square brackets and braces.
And how do "matched operators" make code more brittle and harder to maintain?
I think the opposite is true: to maintain code you must first be able to read it, and what you call "matched operators" are far superior for readability compared to having to remember fixity rules. Even after 3 years of dealing with Haskell I found myself constantly misreading code because I didn't get the fixity right.
- tome 9y agoCould you please give a concrete example? The majority of Haskell expressions have what is called a "principal type". The type of such an expression is independent of its subexpressions or super- expressions.
- xenomachina 9y agoA concrete example of what?
- tome 9y agoA concrete example of an expression that you have difficulty determining the type of.
- xenomachina 9y agoIt's been a few years since I gave up on Haskell, but I remember anything involving `do` (especially containing a `return`) or `sequence` seemed to require a lot of guesswork about what type was involved. Pretty much anything where the type of a subexpression would be an overloaded type has a high potential for being confusing. Another example of what I'm talking about is the fact that even the expression "5 == 5" gives an error unless the kludgy type defaults are enabled. The fact that they felt the need to add type defaults and MR to the language is a pretty strong sign that they screwed up the usability of the type system.
- tome 9y agoHaskellers would tell you that what they appreciate about this is that you don't have to understand sequence and return! They do the "same thing" for all monads in the sense that they obey well-defined laws. "5 == 5" is a different issue, and ironically is ambiguous because it's so simple. Most practical arithmetic expressions would have some way of disambiguating the type.