DIP 1019--Named Arguments Lite--Community Review Round 2

[Timon Gehr]

On 10.06.19 20:28, Patrick Schluter wrote:
> On Sunday, 9 June 2019 at 21:01:35 UTC, Jonathan Marler wrote:
>> On Sunday, 9 June 2019 at 19:43:54 UTC, Andrei Alexandrescu wrote:
>>> On 6/9/19 7:27 AM, aliak wrote:
>>>> With reorderable, as Walter pointed out, what't the order 
>>>> (parameter-wise or argument-wise).
>>>
>>> Lexical order of course.
>>
>> Lexical order of the definition or the caller?
>>
>> So far we have 1 for the caller and 1 for the definition. Both seem to 
>> think their choice is the obviously correct one :)
>>
>>   > Patrick Schluter:
>>   > They are in the order of declaration of the function...There's no 
>> reason to evaluate it any other order as the code generation requires 
>> that the caller populates the registers/stack in the order the 
>> function expects.
>>
>>   > Paul Backus:
>>   > Personally, I think the obviously-correct choice is to evaluate 
>> them in lexical order (i.e., order of the call).
> 
> That's probably a bottom up vs top down perception of things. When you 
> learned the stuff at the assembly/object level you tend to see the 
> things in cpu perspective, and there you tend to see the call convention 

With C compilers, where order of evaluation is arbitrary, usually you 
will see compilers using /reverse/ order.

> for what it is pushing register in a specific order.

This does not really make a lot of sense. Why would there be a preferred 
order to push registers that influences preferred order of arguments? 
The actual point is that for /some subset/ of the arguments (those that 
are actually pushed onto the stack instead of passed in registers), the 
calling convention will specify in which order they have to end up on 
the stack. But there is no rule that says you have to evaluate 
side-effects of arguments in the order they will end up on the stack!

> If you came from the high level application level where the machine 
> implementation is nothing more than a detail, you tend to don't care 
> about the hoops the compiler/implementation has to go through to realize 
> the abstraction the language presents (best example is the set types in 
> Pascal where the elegance of 'if c in [a..z]' was loved by programmers, 
> but resulted in an incredibly complex code).
> ...

I.e., some old Pascal compiler sucked.

> This said, the lexical order is after all the more abstract one and the 
> complexity of it is imo manageable by the compiler so there's nothing 
> that should preclude it, even if in my mental model that is closer to 
> the implementation, would see callee order first.
> 

A good programmer understands multiple levels of abstraction at the same 
time, and evaluating in order of formal parameters is not actually 
"closer to the implementation". Furthermore, you can always change the 
evaluation order by defining some temporaries, if you think some other 
order will allow the compiler to do a better job using the limited 
available static information.