Short list with things to finish for D2

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Nov 19 15:58:53 PST 2009


Justin Johansson wrote:
> Justin Johansson wrote:
>> aarti_pl wrote:
>>> Andrei Alexandrescu pisze:
>>>> aarti_pl wrote:
>>>>> aarti_pl pisze:
>>>>>> Andrei Alexandrescu pisze:
>>>>>>> 2. User-defined operators must be revamped. Fortunately Don 
>>>>>>> already put in an important piece of functionality (opDollar). 
>>>>>>> What we're looking at is a two-pronged attack motivated by Don's 
>>>>>>> proposal:
>>>>>>>
>>>>>>> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
>>>>>>>
>>>>>>> The two prongs are:
>>>>>>>
>>>>>>> * Encode operators by compile-time strings. For example, instead 
>>>>>>> of the plethora of opAdd, opMul, ..., we'd have this:
>>>>>>>
>>>>>>> T opBinary(string op)(T rhs) { ... }
>>>>>>>
>>>>>>> The string is "+", "*", etc. We need to design what happens with 
>>>>>>> read-modify-write operators like "+=" (should they be dispatch to 
>>>>>>> a different function? etc.) and also what happens with 
>>>>>>> index-and-modify operators like "[]=", "[]+=" etc. Should we go 
>>>>>>> with proxies? Absorb them in opBinary? Define another dedicated 
>>>>>>> method? etc.
>>>>>>>
>>>>>>> * Loop fusion that generalizes array-wise operations. This idea 
>>>>>>> of Walter is, I think, very good because it generalizes and 
>>>>>>> democratizes "magic". The idea is that, if you do
>>>>>>>
>>>>>>> a = b + c;
>>>>>>>
>>>>>>> and b + c does not make sense but b and c are ranges for which 
>>>>>>> a.front = b.front + c.front does make sense, to automatically add 
>>>>>>> the iteration paraphernalia.
>>>>>>>
>>>>> (..)
>>>>>>> Andrei
>>>>>>
>>>>>> I kinda like this proposal. But I would rather call template like 
>>>>>> below:
>>>>>>
>>>>>> T opInfix(string op)(T rhs) { ... }
>>>>>> T opPrefix(string op)(T rhs) { ... }
>>>>>> T opPostfix(string op)(T rhs) { ... }
>>>>>>
>>>>>> and allow user to define her own operators (though it doesn't have 
>>>>>> to be done now).
>>>>>>
>>>>>> I know that quite a few people here doesn't like to allow users to 
>>>>>> define their own operators, because it might obfuscate code. But 
>>>>>> it doesn't have to be like this. Someone here already mentioned 
>>>>>> here that it is not real problem for programs in C++. Good 
>>>>>> libraries don't abuse this functionality.
>>>>>>
>>>>>> User defined operators would allow easy definition of Domain 
>>>>>> Specific Languages in D. I was already writing about it some time 
>>>>>> ago:
>>>>>>
>>>>>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81026 
>>>>>>
>>>>>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81352 
>>>>>>
>>>>>>
>>>>>> BR
>>>>>> Marcin Kuszczak
>>>>>> (aarti_pl)
>>>>>
>>>>> Of course for opPrefix/opPostfix signatures will be different:
>>>>> T opPrefix(string op)() { ... }
>>>>> T opPostfix(string op)() { ... }
>>>>>
>>>>> Sorry for mistake.
>>>>>
>>>>> BR
>>>>> Marcin Kuszczak
>>>>> (aarti_pl)
>>>>
>>>> I think we'll solve postfix "++" without requiring the user to 
>>>> define it. Do you envision user-defined postfix operators?
>>>>
>>>> Andrei
>>>
>>> Well, maybe something like below:
>>>
>>> auto a = 2²;  //(quadratic power of 2)
>>> auto a = 5!;  //factorial of 5
>>> auto a = 2Ƴ + 3ɛ; //solving equations
>>> auto weight = 5kg; //units of measurement
>>>
>>> The point is that this covers whole scope of operators. In fact even 
>>> built-in operators could be defined using it.
>>>
>>> Postfix operator ++ can be defined using prefix operator++ just by 
>>> delegation and this can be default.
>>>
>>> Best Regards
>>> Marcin Kuszczak
>>> (aarti_pl)
>>
>> Marcin demonstrates a valid point.
>>
>> If there is going to be this feature creep, the feature should be 
>> complete with all the usual variants of operator arity and notation 
>> (i.e. prefix/postfix/infix).  Otherwise it really it's only two-thirds 
>> baked.
>>
>> -- Justin Johansson
> 
> I meant to say "Iff there is ..." as in "if and only if".
> 
> Like others, I'm not completely sold on the idea at all.  Also it's 
> probably not possible to squeeze something as long as this on to a short 
> list.
> 
> All or nothing please.

I disagree with this false choice.

http://en.wikipedia.org/wiki/False_dilemma#False_choice


Andrei



More information about the Digitalmars-d mailing list