News for hackers. Stuff that matters.
Re:Swift Functors, Applicatives, and Monads in Pictures by chongli on Tuesday July 14, 2015 @06:13PM (#9888426)
There's more to the interfaces than merely the operators; there are laws, too. Besides that, the operators give a big advantage when sequencing operations, something you can't do with map() notation.
Re:Swift Functors, Applicatives, and Monads in Pictures by jameshart on Tuesday July 14, 2015 @07:29PM (#9888774)
When you implement an equality operator, or addition/multiplication operators on a type there are 'laws' too, but that doesn't stop it coming down to 'has an equals method'.
Re:Swift Functors, Applicatives, and Monads in Pictures by adamwk on Tuesday July 14, 2015 @06:19PM (#9888453)
Then why not have both? Applicative Functors have both `fmap` and `<$>`. `>>=` could easily be an alias of `flatMap` or `bind` or whatever.
Re:Swift Functors, Applicatives, and Monads in Pictures by chongli on Tuesday July 14, 2015 @06:26PM (#9888489)
I'm right there with you. I'm a Haskell user; I love user-definable operators.
Re:Swift Functors, Applicatives, and Monads in Pictures by lmm on Tuesday July 14, 2015 @07:18PM (#9888722)
Because code is read more than it's written; multiple ways of writing the same thing makes it easier to write but harder to read.
Re:Swift Functors, Applicatives, and Monads in Pictures by dragonwriter on Tuesday July 14, 2015 @07:26PM (#9888764)
Multiple ways of writing the same thing makes it easier to read, often, because you are more free to use the form that is more readable and intuitive in context; that's one reason why natural languages (including written languages) tend to have multiple ways of expressing the same ideas.