Positive

[Bruce Adams]

On Sun, 05 Oct 2008 15:12:13 +0100, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Bruce Adams wrote:
>> On Sun, 05 Oct 2008 03:35:57 +0100, Andrei Alexandrescu  
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> Hello,
>>>
>>>
>>> (Background: Walter has kindly allowed ".()" as an alternative to the  
>>> ugly "!()" for template argument specifications.)
>>>
>> I can't believe you posted this to this newsgroup expecting the bit  
>> about the positive
>> template to be the focus of attention. As soon as I saw it, I  
>> anticipated the usual
>> 'enflamed discussion'. Didn't you? or was that part of the plan?
>> Anyway, I am glad some people did eventually get back to your main  
>> question.
>
> I didn't expect that much hubbub.
>
I guess you don't paint bike sheds very often then :)

>
>> Going back to the sqrt example. Do you propose to change the library  
>> declaration to
>>   NonNegative!(numberType) sqrt( NonNegative!(numberType) X,  
>> NonNegative!(numberType) Y);
>>  Presumably changes like this are the real reason you want more  
>> feedback?
>
> Yah. But what is the second argument for?
>
Its to remind me that I'm half asleep and should check what I write more  
thoroughly. :)

>> Internal temporaries would be checked at compile time (when initialised  
>> to a compile time constant value)
>> so there would be no added cost to implementing sqrt only using it with  
>> values that might
>> be negative.
>
> That can't be done in the current language, sigh.
>
It can't? That surprises me. Doesn't CTFE apply to:

Positive!(int) x = 1;


>> If my understanding is correct you are proposing this mainly because  
>> unlike contracts,
>> templates are checked by the compiler at compile time.
>> I suspect that is the real problem. I and others have previously tried  
>> to argue for compile
>> time checkable contracts.
>> Another advantage of compile time contracts is that you can design and  
>> test arbitrary new
>> categories of type without having to add new type specifiers to the  
>> language. I'm thinking about
>> const and pure here. Though pure would require functions to have  
>> visible compile time attributes
>> (as opposed to the purely invisible ones which must exist internally)  
>> which is another kettle of fish.
>
> I'd love compile-time-checked contracts, but they're simply not doable  
> with current compiler technology.
>
> Andrei

I disagree. I'm not saying its easy but it could be done. We would have to  
start
with something relatively simple and work our way up but it could be done.
Compiler's already do all kinds of clever analyses behind the scenes but  
each one
is often hard coded. I suspect the main difficulty is giving users too  
much rope
by which to hang themselves, or rather hang the compiler trying to prove  
something
it doesn't realise it can't. Marrying declarative / constraint based  
programming
at compile time is creeping in via templates. I wish it was less well  
hidden.

Regards,

Bruce.