Comment on Making Map Operations Implicit in ProgrammingComments−DanWaterworth12yHow many times will Monads be reinvented? name.trim.filter{ _.length != 0 }.toUpperCase becomes: name >>= (return . trim) >>= (guard . ((/= 0) . length)) >>= (return . toUpperCase) I've purposefully used >>= and return instead of fmap to show that '.' above is almost >>=.EDIT: I've just noticed a type error in the use of guard, but you get the idea.−farginayOP12yI think the big thing is to make the case for one and the case for many look exactly the same in the language. Is that nicer to look at with do-notation?−DanWaterworth12yWith do notation, it becomes: do n <- name let trimmed = trim n guard (length trimmed /= 0) return (toUpperCase trimmed)−farginayOP12yWouldn't it be nice if it was just: toUpperCase . guard (\x -> length x /= 0) . trim I think that is how it would be if it was part of the language.−DanWaterworth12yI like my code to do what it says. You can pretty much do that in Haskell. If you allow me to add a definition first: mfilter' :: MonadPlus m => (a -> Bool) -> a -> m a mfilter' f = mfilter f . return Then it's just: toUpperCase <=< mfilter' (\x -> length x /= 0) . trim Which is pretty close. No need to change the language.
Comments
How many times will Monads be reinvented?
becomes: I've purposefully used >>= and return instead of fmap to show that '.' above is almost >>=.EDIT: I've just noticed a type error in the use of guard, but you get the idea.
I think the big thing is to make the case for one and the case for many look exactly the same in the language. Is that nicer to look at with do-notation?
With do notation, it becomes:
Wouldn't it be nice if it was just:
I think that is how it would be if it was part of the language.I like my code to do what it says. You can pretty much do that in Haskell. If you allow me to add a definition first:
Then it's just: Which is pretty close. No need to change the language.