Grafting Functional Support on Top of an Imperative Language

Jarrod qwerty at ytre.wq
Fri Apr 4 22:14:01 PDT 2008


On Fri, 04 Apr 2008 14:46:26 -0700, Walter Bright wrote:

> Andrei Alexandrescu's talk just given at ACCU:
> 
> http://www.digitalmars.com/d/2.0/accu-functional.pdf

I'm going to get grilled for this post.

D is a great imperative language.
D is a terrible functional language.

This might sound harsh, but it's true. Functional languages need a lot of 
special features to be what they are. They need to have statements that 
work as expressions, unique data structures like chained lists, the 
ability to heavily compress statements so as to prevent using temporary 
values that us imperative programmers do enjoy so very much. Some 
functional languages (in fact, arguably the 'cleanest' functional 
languages like forth and joy) require the use of a special 'stack' to 
manage data.
D does not have these features, and unless you want to completely change 
what D is, D cannot have these features.

Now, I'm all for the non-breaking things that functional languages have 
graced us: map, filter and range, tail recursion optimization, even 
simple forms of 'pure' functions are nice as well.
But this whole const and pure thing is looking pretty ugly. 
Imperative programmers use const/invariant datasets as a contract; a way 
to set out guidelines for how their data should be used. Functional 
languages take it a step further and force all data to be immutable, 
making it a rule, not a guideline to use immutable data.
The meaning of const changes between these two paradigms, and I think 
it's going to cause a lot of problems within D when they mix, especially 
when functional languages keep all this immutable stuff conveniently 
hidden away inside lists and stacks that the programmer doesn't have to 
worry about.

I guess what I'm trying to say is functional languages are good at what 
they do because they are functional languages. D is not a functional 
language, and as such trying to use it as one is probably just going to 
end up painful. If you want D to work like a functional language, turn it 
into a functional language Walter. Force all data to be immutable by 
default, all functions to be pure unless they prove otherwise, add native 
support for lists and tuples and add a bunch of list manipulation 
functions..
Heck, why not make a functional dialect of D? Call it "D flat" and have 
it compile alongside D or something. No need to mix the two.

The current imperative/OO style of D is brilliant, fun to use, flexible 
and just packed with lovely features. Please don't go killing it on me by 
trying to make it an ugly jack of all trades.



More information about the Digitalmars-d mailing list