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

[Mafi]

On Monday, 6 August 2012 at 19:45:17 UTC, deadalnix wrote:
> Le 06/08/2012 21:07, Mafi a écrit :
>>> No dereferencing is done in the compiled code anyway. BTW, an 
>>> «
>>> address of » operation is done on the type mentioned above.
>>>
>>
>> I don't get what you are saying here. For me there's an 
>> inherent
>> difference between a fuction and a function pointer. You 
>> shouldn't try
>> to conflate them in a system language in my opinion.
>>
>
> On any hardware, a function call will boil down to set up stuff 
> on the stack and branching, jumping, calling or whatever on the 
> ADDRESS of the function's code.
>
> In other term, what is generated always involve the function's 
> instruction address. If you dereference that address, you get 
> instructions, but that hardly something useful to have at 
> higher levels because you can"t do anything with it anyway.
>

It's the same with an int on the stack, isn't it (literally on 
the stack; not optimized into a register). To access it, one has 
to dereference its address but you wouldn't like conflating int 
and int*.
The difference is between the address being a constant (maybe 
relative to the stack) and being totally unknown. In my opinion 
this is a big difference, also for functions.

...
>
> Well D also advertise itself as OO and functional. Obviously, 
> decision will have to be made. Because if no design decision is 
> made, you ends up like it is now : micro decision are made when 
> coding, and no overall is followed.
>
>>>> I don't like authorative formal specs. It means most things 
>>>> are set in
>>>> stone and you have to write a new spec every once in a while 
>>>> which slows
>>>> down development of awesome language features.
>>>>
>>>
>>> This isn't about awesome language features. This is about 
>>> function
>>> calls ! The most basic feature ever.
>>>
>>> BTW, not stabilized feature shouldn't appear in what we call 
>>> stable
>>> release . . . They should be provided testing versions of the 
>>> compiler
>>> so they can be tortured and refined to the point everything 
>>> make sense.
>>
>> This isn't about versioning schemes either! But there have 
>> been long
>> discussions recently and at least some things will change with 
>> the
>> development after 2.060 afaik.
>>
>
> Yes, that was a digression. When stating that UFCS don't 
> integrate nicely with other features, this showed the need for 
> incubation of feature, and as recent discussions have been made 
> on versioning, I made a bridge.