Is D a cult?

[retard]

Sun, 07 Mar 2010 11:17:46 -0800, Walter Bright wrote:

> retard wrote:
>> Let's see what features I had in mind:
>> 
>> - Algrebraic data types
> 
> std.variant covers this.
> 
>> - Pattern matching (extension to enum/string/integer accepting switch)
> 
> Andrei and Sean have shown how to do that nicely with existing language
> features.

Really? I'd really like to see how this is done. Especially the nested 
matching of algebraic constructs, e.g.

my_list match {
  case 1 :: 2 :: 3 :: tail => 123 :: tail
}

in D:

if (list.getElemAt(0) == 1 &&
    list.getElemAt(1) == 2 &&
    list.getElemAt(2) == 3) {
  return list.new(123).append(list.range(3, list.length));
}

>> - Currying, lazy evaluation
> 
> Already supports this.

I should have mentioned this

http://enfranchisedmind.com/blog/posts/post-functional-scala/

That guy argues that even Scala isn't really functional since it doesn't 
encourage point-free programming with ugly and verbose partial 
application & currying. Indeed, both Scala and D support lazy evaluation 
in various contexts.

> 
>> - Fusion optimizations (e.g. list and stream fusion)
> 
> Andrei demonstrated how to do this neatly with ranges.

I really doubt he optimizes those since it requires serious compile time 
graph rewriting - possible with e.g. expression templates, though.

> 
>> - Type classes
> 
> Don't know what this is.

This is a bit related to the discussion about collection properties some 
time ago. And c++0x concept maps..

> 
>> - basic control constructs are expressions, not statements
> 
> Perhaps, but I still think it's necessary for D do be a { } Algol-style
> language. Nevertheless, I've demonstrated how this can be simply done
> using existing features.

Having functional core constructs often helps in writing immutable 
functional code. Instead of first declaring a mutable variable and then 
assigning it a value later, with functional constructs you can 
immediately assign the result without requiring a mutable temporary 
state, e.g.

int a = null;

switch(b) {
  case foo: a = something;
  ...
  default: a = something_else;
}

vs

const immutable int a = switch(b) {
  case foo: something;
  ...
  default: something_else;
}

The problem with mutability here is that after the assignment the mutable 
state doesn't automatically change.

> 
>>(e.g. unify if-then-else and : ? into a functional if-then-else)
> 
> What's the difference between ?: and functional if-then-else?

Nothing. But you don't need both constructs. ?: should be the default as 
it is more general. I'd like to know why the return value should be 
discarded in the more common case. I know there's C/C++/Java 
compatibility arguments, but the original decision was somewhat flawed. 
I've worked in companies where the review process disallows the use of ?: 
because it makes the code look amateurish or 'hacky'.

> 
>> - better syntax for lambdas
> 
> The lambda syntax is as good as it's going to get without throwing out a
> *lot* of syntax compatibility.

Some other C/C++ based languages like C# seem to have done otherwise. The 
lambda in C# returns an expression like the ternary ?: in D so you don't 
need an explicit 'return'. The -> and => symbols are not used in D so I 
suppose it wouldn't be a big problem to extend the syntax with an 
expression returning lambda. After all, everything else is already there.

>> [1] if immutability is considered functional [2] if type inference is
>> considered functional
> 
> Several of your points are not, to my mind, fundamental issues of
> functional programming. To me, the foundations of FP are immutability,
> purity, and closures, which got a lot of attention. Most of your points
> are already supported by D, although not quite as conveniently as in
> many other languages.

There's the idealistic pure core in functional languages. Unfortunately 
no one really likes it because it's not that good for building practical 
programs. The features I mentioned above can be implemented with simple 
lambda expressions. The whole idea in many new functional language 
features is that they are straightforward to rewrite into lambdas.

It's perfectly clear to me that no matter what you do, D won't become a 
functional language because the core runs on an imperative Turing 
machine. But the functional constructs can help building more readable 
and reliable code. That's why C# and Scala got those features..