Clay language

[Andrei Alexandrescu]

On 12/30/10 1:17 PM, Steven Schveighoffer wrote:
> On Thu, 30 Dec 2010 12:52:32 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 12/30/10 11:08 AM, Steven Schveighoffer wrote:
>>> I'd have to see how it works. I also thought the new operator
>>> overloading scheme was reasonable -- until I tried to use it.
>>
>> You mean until you tried to use it /once/.
>>
>>> Note this is even more bloated because you generate one function per
>>> pair of types used in concatenation, vs. one function per class defined.
>>
>> That function is inlined and vanishes out of existence. I wish one day
>> we'd characterize this bloating issue more precisely. Right now
>> anything generic has the "bloated!!" alarm stuck to it indiscriminately.
>
> Functions inline out of existence during runtime, but the function
> itself remains resident in the compiled binary.

Doesn't have to!

> I don't know that it's an important aspect to keep it in there or not, I
> just know it's kept. There are a whole slew of improvements we can make
> in this regard, but I'm not sure they are possible, because I'm not a
> compiler writer.

Please take my word for it: this is a solved problem.

> One such nuisance in particular is the proliferation of types when you
> use something like isInputRange. That invariably is *only* used at
> compile time, yet the type and its typeinfo are injected into the binary.
>
>>> I mean bloated because you are generating template functions that just
>>> forward to other functions. Those functions are compiled in and take up
>>> space, even if they are inlined out.
>>
>> I think we can safely leave this matter to compiler technology.
>
> I hope that can be done. D already suffers from the 'hey what gives, how
> come hello world is 1MB?!!' syndrome.

More like 600KB, but yah :o). Note that the size of the executable is 
caused by other issues, compared to which the concerns at hand are puny.

[snip]
>>> So I'd say, while my example is not proof that this is a disaster, I
>>> think it shows the change in operator overloading cannot yet be declared
>>> a success. One good example does not prove anything just like one bad
>>> example does not prove anything.
>>
>> Many good examples do prove a ton though. Just off the top of my head:
>>
>> - complex numbers
>>
>> - checked integers
>>
>> - checked floating point numbers
>>
>> - ranged/constrained numbers
>>
>> - big int
>>
>> - big float
>>
>> - matrices and vectors
>>
>> - dimensional analysis (SI units)
>>
>> - rational numbers
>>
>> - fixed-point numbers

One more:

- Variant types

>> If I agree with something is that opCat is an oddity here as it
>> doesn't usually group with others. Probably it would have helped if
>> opCat would have been left named (just like opEquals or opCmp) but
>> then uniformity has its advantages too. I don't think it's a disaster
>> one way or another, but I do understand how opCat in particular is
>> annoying to your case.
>
> Probably the most common operator overload in D is opEquals, luckily
> that is not a template (even though it sadly does not work with
> interfaces yet).
>
> It seems that operator overloads are in categories. There are the
> numeric overloads, which I agree are generally overloaded in groups.
> When I defined cursors to be more like C++ iterators in dcollections
> instead of small ranges, I used the ++ and -- overloads, which you
> typically define together.
>
> When designing the mixin that allows you to define various operator
> overloads, I think it would be hugely beneficial to take into account
> these groupings and make the mixins modular.

That's a valuable insight! Introspection can help a lot, e.g. you can 
synthesize opAdd from opAddAssign (or vice versa) etc.

>>> I haven't had that experience. This is just me talking. Maybe others
>>> believe it is good.
>>>
>>> I agree that the flexibility is good, I really think it should have that
>>> kind of flexibility. Especially when we start talking about the whole
>>> opAddAssign mess that was in D1. It also allows making wrapper types
>>> easier.
>>>
>>> The problem with flexibility is that it comes with complexity. Most
>>> programmers looking to understand how to overload operators in D are
>>> going to be daunted by having to use both templates and template
>>> constraints, and possibly mixins.
>>
>> Most programmers looking to understand how to overload operators in D
>> will need to bundle them (see the common case argument above) and will
>> go with the TDPL examples, which are clear, short, simple, and useful.
>
> The code itself is simple, it's the "how does x + y match up with this
> template thingy" which is the problem I think. We've already had several
> posts on d.learn ask how operator overloads work even after reading TDPL.

I'm not worried about this most at all as I think (unintentionally) 
things have fallen in the right place: operator overloading is an 
advanced, specialized topic. I believe the set of users who are 
sophisticated enough to sit down and start overloading operators at 
large, yet at the same time are beginners enough to not grasp the notion 
of a generic function in D (which is much simpler than in other 
languages) may as well be not empty, but is small enough to not cater for.

>> Saw that. I have a suspicion that we'll see a solid solution from you
>> soon!
>
> Alas, no solution is possible without templates being allowed in
> interfaces :( But yes, I plan to use this technique as soon as it's
> possible.

I voted for it now, too. As I always use all of my 10 votes, I had asked 
on the Phobos list to increase that limit, but was thoroughly shredded 
into little pieces.


Andrei