Functional programming in D and some reflexion on the () optionality.

[Era Scarecrow]

On Tuesday, 7 August 2012 at 15:14:09 UTC, Dejan Lekic wrote:
> You do not seriously expect D to copy exactly how Haskel (or 
> any other similar declarative langauge) treat functions? Does 
> it really have to be an exact copy? I am not trying to defend D 
> language designer(s) here, just trying to say that D should 
> have own style, if there is sense behind it, it does not 
> necessarily have to conform 100% to any paradigm.
>
> The main reason for me to start using D 10 years ago was the 
> obvious PRAGMATIC design of the language. I did not start using 
> it because of (possible) functional orientation. Actually, I 
> would probably turn my back on D if I saw it promotes 
> declarative style more than imperative.
>
> I think the current mix of both worlds is the best direction 
> for D.

  I'm not arguing, but going to give my two or three cents on the 
matter; I can't recall if someone already mentioned all this.

  Other than 0-1 arguments being allowed to operate with or 
without parentheses, functionally is there any real reason to 
disallow or force it? Aside from variables being unable to use 
()'s there seems to be no real difference otherwise. In some 
respects that's a good thing, but you can also take a built-in 
type and seamlessly replace it with functions or properties 
depending on the needs; The only difference is certain options 
(like .init or .min/.max) no longer are accessible.

  D can be a terse language, and building up from other language's 
mistakes and faults to make something newer, more robust, more 
useful. So what if there  might be 3 different ways to call 
something, that doesn't make any one of them wrong compared to 
another. One way of calling it may be simpler or better than 
another, and having parentheses unnecessarily (be it property or 
otherwise) seems silly.

  assuming definition: string strip(string input);

  string x = "something";
  auto y1 = x.strip;
  auto y2 = x.strip();
  auto y3 = strip(x);

  All do the same thing. Since strip isn't a property, more 
restrictive may prevent y1 from working. But if you want to chain 
commands, the ()'s just seem ugly and don't help much. So what if 
it's a function?

  assuming definition: string replace(string input, string from, 
string to);

  auto y1 = x.strip.replace("from", "to");
  auto y2 = x.strip().replace("from", "to");
  auto y3 = strip(x).replace("from", "to"));
  auto y4 = replace(x.strip, "from", "to"));
  auto y5 = replace(x.strip(), "from", "to"));

  If replace was a template, perhaps:

  assuming definition: string replace(string from)(string input, 
string to);

  auto y1 = x.strip.replace!"from"("to");
  auto y2 = x.strip().replace!"from"("to");
  auto y3 = strip(x.replace!"from"("to"));
  auto y4 = replace!"from"(x.strip, "to"));
  auto y5 = replace!"from"(x.strip(), "to"));

  In the lower two cases #2 seems the ugliest since () only tells 
us it's a function but we already sort of know that with the 
chaining. If properties are enforced with only one calling 
convention, then only #1 or #2 will work at any given time, maybe 
not even y3. #1 seems the simplest to follow during chaining in 
this case. #4 & #5 can be followed fairly easily, but seems more 
verbose than needed.

  Expressiveness is important, and if it feels most natural 
writing a certain way, or easier to follow then it should be 
allowed (assuming it has no impact on performance or language 
structure).

  I guess at this point, I'd almost suggest leaving it as it is; 
Open for the programmer, but a switch to make it more strict for 
say libraries, or where there's a potential for it to be a 
variable in some cases and something else (static if's for types).