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.
- Higher kinded types
Don't know what that is.
- Tuples (no auto-folding, real product types)
Tuples can be better, I agree.
- Built-in variants (real sum types)
std.variant works fine. Don't know how having them be built-in would
improve things.
- Currying, lazy evaluation
Already supports this.
- Fusion optimizations (e.g. list and stream fusion)
Andrei demonstrated how to do this neatly with ranges.
- Type classes
Don't know what this is.
- 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.
(e.g. unify if-then-else and : ? into a functional if-then-else)
What's the difference between ?: and functional if-then-else?
- better syntax for lambdas
The lambda syntax is as good as it's going to get without throwing out a
*lot* of syntax compatibility.
[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.
