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

deadalnix deadalnix at gmail.com
Mon Aug 6 12:33:53 PDT 2012


Le 06/08/2012 20:15, Timon Gehr a écrit :
>> To me, the first big failure of D to implement functional style is to
>> not have first class functions.
>
> Last time I checked, D still had closures. The 'first big failure of D
> to implement functional style' is the lack of most of the other
> features traditionally encountered in functional languages.
>

I mentioned first class function. Functions are not first class, you 
have to go throw & .

> Actually it is just that function declarations don't introduce symbols
> that are bound to values of the first class type.
>
> Try enum foo = (){};
>

That is what I mean when I say that function are not first class.

>
> &a.foo could be disallowed if foo is bound by UFCS.
>

It wouldn't be more consistent and would limit expressiveness.

> The formalisation can formalise the behaviour in a compatible or mostly
> compatible way. eg:
>
> a symbol that refers to a function (template) declaration can appear in
> some distinct contexts:
>
> 1. its address is taken
> 2. it is called
> 3. it is assigned to
> 4. none of the above
>
> In case 1:
> - If the function was looked up by UFCS, then this is the problematic
> case. Eg. just error out.
> - the address of expression will evaluate to a function pointer
> if the function is static and to a suitable delegate otherwise.
>
> In case 2:
> - Call.
>
> In case 3:
> - Call with the assigned expression.
>
> In case 4:
> - Rewrite to a call without parameters.
>
> Why would this be hard to implement?
>

Well it isn't straightforward, add @property into that and it become 
quite scary, now try to keep up with dmd that introduce changes into 
that process every release or so and you'll get my point.

>> Reading the @property thread, it seems that most people want to keep
>> dmd's current behavior. Because code rely on it. This make sense, but if
>> dmd's implement is the only goal, it means that other compiler are only
>> to be reverse engineering dmd's behavior, and are guaranteed to lag
>> behind. Considering this, I seriously wonder if it make sense to even
>> try to follow dmd's behavior and decide whatever seems the right one
>> when writing a D compiler, which will result in community split, or no
>> alternative compiler produced for D.
>>
>
> I think this is blown out of proportion.
>

As you say :

>
> That is inevitable if there is only one front end implementation and no
> formal specification.

The function call mess is one aspect.


More information about the Digitalmars-d mailing list