On 29-04-2012 01:41, Peter Alexander wrote:
On Saturday, 28 April 2012 at 23:29:35 UTC, bearophile wrote:
Peter Alexander:
f(x) ---> x.f() is not progress in language design.
I used to think the same. But Haskell offers "." and $ to chain
functions and remove parentheses, F# has the |> pipe operator. In D
UCFS is almost equally useful to turn nesting of function calls in a
more readable chain. In functional-style code this makes a lot of
difference, turning:
foo(bar(copy(baz(a), spam(b))))
Into:
baz(a).copy(b.spam()).bar().foo()
When I see 3+ nested parentheses I find it hard to read the
expression. While a chain is easy to read.
What D does and what Haskell does are very different things. D has (at
least) two types of functions: free functions and member functions. UFCS
makes free functions look like member functions. In Haskell, $ just
gives you a way of re-ordering precedence -- it doesn't hide anything.
This matters because UFCS in D is deceitful. It makes you think the free
function is a member function when it is not.
struct Foo { void bar() {} }
void baz(Foo f) {}
Foo f;
f.bar(); // ok
f.baz(); // ok, looks like baz is a member function
auto pbar = &Foo.bar; // ok
auto pbaz = &Foo.baz; // error!
IMO, D would be better with Haskell's function calling syntax (of
course, this would require many, many other syntactical changes).
But in D the main purpose of "pure" is not as optimization tool, but
more as a tool to enforce a better coding style, that makes code
understanding (and testing simpler), and helps avoid some bugs, coming
from using variables from outer scopes.
True, but I'm quite happy to write pure functions without the static
checking. I do not believe that the safety provided by the static checks
outweighs the development cost of ensuring you have the correct
qualifiers everywhere.
In my experience, pure is only hard to use in D due to the runtime and
standard library not being properly annotated. I don't think anything is
wrong with the language feature itself.
--
- Alex
