5 ms·
Another example of a touted inelegance which I consider to actually be incredibly helpful in practice is the positional arguments part of the post where the aut
by kornish 11y ago
Another example of a touted inelegance which I consider to actually be incredibly helpful in practice is the positional arguments part of the post where the author says:
> For example, the Haskell function elem returns whether an element exists in a list. Do you call it with the list first or thing to search? There's no way to know.
Well, the type of `elem` is
(Eq a, Foldable t) => a -> t a -> Bool
So, it is - with practice - clear to see that the singular item comes first, and the item in the foldable container comes second. Perhaps this sort of Type-Driven Development, which is more of a practical mindset than language feature, isn't emphasized in the (excellent) books from which the author was learning...but it becomes an invaluable tool in Haskellers' toolboxes while trawling through package documentation later on. Many times, between the name of the function and type of arguments, one can figure out exactly what they need to pass in to achieve the desired output.
- LeonidasXIV 11y ago> Many times, between the name of the function and type of arguments, one can figure out exactly what they need to pass in to achieve the desired output. Yes of course because the parameters are usually designed with currying in mind, so the order is from most general on the left to the most specific on the right. In the case of elem, both orders are reasonable, but often times only one makes sense and then it is easy to remember.
- tome 11y agoYou seem to have missed kornish's point completely.
- kornish 11y agoI'm not quite sure how you're defining "general" and "specific", but I think I don't disagree with what you're saying. The point of my comment was more that one of the beauties of Haskell is that positional arguments are made so elegant because every positional argument is accompanied by a type. I wasn't making a statement about the order of parameters themselves, but how all parameters are typed. > In the case of elem, both orders are reasonable, but often times only one makes sense and then it is easy to remember. In some languages where callbacks taking positional arguments are idiomatic (like Javascript), untyped functions can cause a lot of problems by making it really hard to discern/remember what gets passed in where. In Haskell, there's often very little onus on the developer to remember anything at all; the type system will make sure they got the order right. Obvious exceptions are non-associative functions of the type a -> a -> a Then, one might have to check to see what goes in first and what goes in second.
- gglanzani 11y agoI always remember what elem arguments are by thinking how would I use it in infix notation. x 'elem' xs