Clay language

[Steven Schveighoffer]

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.

>> Also, let's not forget, templates can't be used in
>> interfaces, which means no operator overloading in interfaces.
>
> Interfaces allow final methods which should help.

operator overloads *must* be templates, and templates aren't allowed, so  
final methods don't help here.  Actually, final methods can't forward  
covariance either, so we have issues there.  I think we need a general  
solution to the covariance problem.  I also have filed a separate bug on  
covariance not being forwarded by alias.

>
>> Related bug:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=4174
>
> That should be what the doctor prescribed. I updated the report and  
> assigned it to Walter.

I saw, thanks.

-Steve