Clay language

[Steven Schveighoffer]

On Wed, 29 Dec 2010 16:14:11 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 12/29/10 2:58 PM, Steven Schveighoffer wrote:
>> On Wed, 29 Dec 2010 15:38:27 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> On 12/29/10 2:10 PM, Steven Schveighoffer wrote:
>>>> On Wed, 29 Dec 2010 14:42:53 -0500, Andrei Alexandrescu
>>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>>
>>>>> On 12/27/10 6:55 PM, Andrei Alexandrescu wrote:
>>>>>> On 12/27/10 12:35 PM, bearophile wrote:
>>>>>>> Through Reddit I have found a link to some information about the  
>>>>>>> Clay
>>>>>>> language, it wants to be (or it will be) a C++-class language, but
>>>>>>> it's not tied to C syntax. It shares several semantic similarities
>>>>>>> with D too. It looks like a cute language:
>>>>>>> https://github.com/jckarter/clay/wiki/
>>>>>> [snip]
>>>>>>
>>>>>> FWIW I just posted a response to a question asking for a comparison
>>>>>> between Clay and D2.
>>>>>>
>>>>>> http://www.reddit.com/r/programming/comments/es2jx/clay_programming_language_wiki/
>>>>>>
>>>>>>
>>>>>
>>>>> That thread is shaping up more and more interesting because it's
>>>>> turning into a discussion of generic programming at large.
>>>>
>>>> I wanted to address your post in the reddit discussion regarding the
>>>> issue of operator overloads not being virtual:
>>>>
>>>> "This non-issue has been discussed in the D newsgroup. You can  
>>>> implement
>>>> virtuals on top of non-virtuals efficiently, but not vice versa."
>>>>
>>>> I've found some very real problems with that, when implementing  
>>>> operator
>>>> overloads in dcollections. It's forced me to use the (yet to be
>>>> deprecated) opXXX forms. Specifically, you cannot use covariance with
>>>> templated functions without repeating the entire implementation in the
>>>> derived class.
>>>
>>> Glad you're bringing that up. Could you please post an example that
>>> summarizes the issue?
>>
>> With D1:
>>
>> interface List
>> {
>> List opCat(List other);
>> }
>>
>> class LinkList : List
>> {
>> LinkList opCat(List other) {...}
>> }
>>
>> With D2:
>>
>> interface List
>> {
>> List doCat(List other); // implement this in derived class
>> List opBinary(string op)(List other) if (op == "~")
>> { return doCat(other); }
>> }
>>
>> class LinkList : List
>> {
>> LinkList doCat(List other) {...}
>> }
>>
>> // usage;
>>
>> LinkList ll = new LinkList(1, 2, 3);
>> ll = ll ~ ll; // works with D1, fails on D2, "can't assign List to
>> LinkList"
>>
>> Solution is to restate opBinary in all dervied classes with *exact same
>> code* but different return type. I find this solution unacceptable.
>
> I understand, thanks for taking the time to share. The solution to this  
> matter as I see it is integrated with another topic - usually you want  
> to define groups of operators, which means you'd want to define an  
> entire translation layer from static operators to overridable ones.
>
> Here's the code I suggest along those lines. I used a named function  
> instead of a template to avoid 4174:
>
> template translateOperators()
> {
>      auto ohPeeCat(List other) { return doCat(other); }
> }
>
> interface List
> {
>      List doCat(List other); // implement this in derived class
> }
>
> class LinkList : List
> {
>      LinkList doCat(List other) { return this; }
>      mixin translateOperators!();
> }
>
> void main(string[] args)
> {
>      LinkList ll = new LinkList;
>      ll = ll.ohPeeCat(ll);
> }
>
> The translateOperators template would generally define a battery of  
> operators depending on e.g. whether appropriate implementations are  
> found in the host class (in this case LinkList).

I'm assuming you meant this (once the bug is fixed):

template translateOperators()
{
    auto opBinary(string op)(List other) {return doCat(other);} if (op ==  
"~")
}

and adding this mixin to the interface?

I find this solution extremely convoluted, not to mention bloated, and how  
do the docs work?  It's like we're going back to C macros!  This operator  
overloading scheme is way more trouble than the original.

The thing I find ironic is that with the original operator overloading  
scheme, the issue was that for types that define multiple operator  
overloads in a similar fashion, forcing you to repeat boilerplate code.   
The solution to it was a mixin similar to what you are suggesting.  Except  
now, even mundane and common operator overloads require verbose template  
definitions (possibly with mixins), and it's the uncommon case that  
benefits.  So really, we haven't made any progress (mixins are still  
required, except now they will be more common).  I think this is one area  
where D has gotten decidedly worse.  I mean, just look at the difference  
above between defining the opcat operator in D1 and your mixin solution!

As a compromise, can we work on a way to forward covariance, or to have  
the compiler reevaluate the template in more derived types?

-Steve