Short list with things to finish for D2

[Bill Baxter]

On Thu, Nov 19, 2009 at 12:47 PM, Leandro Lucarella <llucax at gmail.com> wrote:
> Andrei Alexandrescu, el 18 de noviembre a las 20:33 me escribiste:
>> Leandro Lucarella wrote:
>> >grauzone, el 19 de noviembre a las 03:47 me escribiste:
>> >>Does the current proposal make things simpler at all? All you're
>> >>doing is to enable the programmer to "fix" the clumsy semantics by
>> >>throwing lots of CTFE onto the problem. Why not generate the
>> >>operator functions with CTFE in the first place...
>> >
>> >I was about to say that, the solution is a hack. I could understand a hack
>> >if there were no other way to do it, but you can generate the code for the
>> >opXxx using CTFE/string mixins already: we already have a hackish
>> >solution. I don't think adding a new hack would be nice (specially when it
>> >will be a big change).
>> >
>> >Maybe a not-so-hackish solution can be found when AST macros get
>> >implemented.
>>
>> I am thinking that representing operators by their exact token
>> representation is a principled approach because it allows for
>> unambiguous mapping, testing with if and static if, and also allows
>> saving source code by using only one string mixin. It would take
>> more than just a statement that it's hackish to convince me it's
>> hackish. I currently don't see the hackishness of the approach, and
>> I consider it a vast improvement over the current state of affairs.
>>
>> I'd be grateful if you argued your point further and hopefully
>> suggested an approach that is better. I want us to move fast with
>> this. So it's just the right time to contribute.
>
> What I found hackish about it is that the code is a string manipulation
> mess. You can already do a string manipulation mess to programatically
> implement all the operator overloading.

This is true, but if you leave it entirely up to the programmer and
string mixins, the mess is much more messy.
You're going to end up with code like this:

mixin(genBinaryOp("+", q{MyType}, q{MyType rhs}, q{
    return this.impl + rhs.impl;
}));


instead of this:
MyType opBinary(string op : "+")(MyType rhs)  {
    return this.impl + rhs.impl;
}

I would have a hard time defending the former as the recommended D style.
But the latter is not so bad.  It looks like a regular template
declaration, and code is code, not a string.


> About the ideal solution, I don't have it. I just have the impression that
> AST macros can help here, but it's been ages since they were postponed to
> D3 and I don't have any idea of what they would look like, so I can't
> propose a solution now.

Yeh, I think macros are the best solution.  If we have macros then the
declarations could look like

genBinaryOp(+, MyType, MyType rhs,
        return this.impl + rhs.impl;
)

And with definable syntax, it could maybe become
MyType opBinary "+" (MyType rhs) {
   return this.impl + rhs.impl;
}

If we had such a macro then the macro could handle mapping symbols
("+") to names ("opAdd").

Some sort of Nemerle-ish definition of such a macro:

macro opBinary(op, ret, args, code)
syntax {
     $ret opBinary $op ($args) { $code }
}
{
    auto opFuncName = operatorNameForSymbol(op);
    <| $ret $opFuncName ($args) { $code } |>
}

I think definable syntax is probably a long way off for DMD.
But the rest of it has a direct translation in terms of a CTFE string
processing function.
All the args are actually 'string' just not declared as such.
<| ... |>  is basically just a call to a big string manipulation
function that replaces $var with whatever value the string var has.
And there's an implicit 'return' of that string.

--bb