On Saturday, 9 July 2016 at 22:20:22 UTC, Timon Gehr wrote:
On 09.07.2016 06:39, Andrew Godfrey wrote:
On Friday, 8 July 2016 at 21:23:24 UTC, Timon Gehr wrote:
On 08.07.2016 04:25, Andrew Godfrey wrote:
Another example is "return" used for monads in eg Haskell -
even if it
only has one meaning in Haskell, it is too mixed up with a
different
meaning in other common languages. D's "static if" - which
is a killer
feature if I ignore the keyword - gives me a similar feeling
(though
it's much less egregious than "return" in monads).
'return' in Haskell is perfectly fine.
This (long) talk does a good job of explaining the problem
with using
the name 'return' in monads.
https://www.infoq.com/presentations/functional-pros-cons#downloadPdf
...
The reason you linked to this (long) talk instead of a more
digestible source is that the presenter manages to bring across
his flawed argumentation in a way that is charismatic enough to
fool a biased audience.
It's a reasonable name. 'return' creates a computation that
returns the given value. This is a different corner in language
design space, why should C constrain Haskell's design in any
way?
Others have said it shorter.
Thanks for providing the links to that material.
I took this example because it crosses
languages. Of course we can't avoid clashing with other
languages, there
are only so many keywords to use. But there's definitely a
principle
here worth considering, that is if you care about D adoption.
...
I was complaining about the cheap shot at Haskell. This has
become way too fashionable.
Sorry I chose such a charged example. It's not a cheap shot in my
case, I have waded through a number of "monad tutorials" and
criticisms of monad tutorials, and that talk summed up my
experience. But I really can't claim that monads would be easy to
learn if they used better naming.
Easier maybe, but they could still be difficult.
Actually maybe Haskell is more relevant as an example to talk
about "overreaching features" - like Haskell's lazy evaluation.
In D, GC, auto-decode, and dynamic arrays have overreached IMO.
But I'm hard pressed to think of something to write in a
long-term vision about that. (E.g. I like how Phobos is adopting
ranges. Wouldn't want to slow that down. But maybe we're blind to
the downsides!) So... you're right, I have no useful suggestions
to make after beating on Haskell. :)
