View mode: basic / threaded / horizontal-split · Log in · Help
October 05, 2008
Re: shouting versus dotting
On Sun, 05 Oct 2008 09:41:28 -0500, Andrei Alexandrescu wrote:


> I'd want to give it a try. How do others feel about Template{arguments}?

Not too shabby at all, really.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
October 05, 2008
Re: shouting versus dotting
Lars Ivar Igesund wrote:
> Gregor Richards wrote:
> 
>> downs wrote:
>>> Andrei Alexandrescu wrote:
>>>> The problem I see with "!" as a template instantiation is not technical.
>>>> I write a fair amount of templated code and over years the "!" did not
>>>> grow on me at all. I was time and again consoled by Walter than one day
>>>> that will happen, but it never did. I also realized that Walter didn't
>>>> see a problem with it because he writes only little template code.
>>>>
>>> FWIW: I write large volumes of template code and I like the ! just fine.
>>>
>> Don't take this endorsement lightly. When downs says he writes large
>> volumes of template code, he means volumes in the literary sense: You
>> could fill a fairly-large bookshelf with his tomes of template code.
> 
> I'm sure you mean not so large tomes, but with very long lines?
> 

That's why you need the bookshelf.

It's not so much the length of the tomes, it's the width :)
October 05, 2008
Re: shouting versus dotting
Michel Fortin, el  5 de octubre a las 03:53 me escribiste:
> On 2008-10-05 01:14:17 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
> 
> >I don't favor "." any more than the next guy, but I am glad there is awareness of how unfit a choice "!" is. If you have any ideas, please post them! Ah! I! 
> >Exclaimed! Again!
> 
> Hum, I don't think we have much choice, it'll have to be something in this lot:
> 
> 	Positive!(real)(joke);
> 	Positive.(real)(joke);
> 	Positive#(real)(joke);
> 	Positive@(real)(joke);
> 	Positive&(real)(joke);
> 	Positive`(real)(joke);
> 	Positive´(real)(joke);
> 	Positive^(real)(joke);
> 	Positive¨(real)(joke);
> 	Positive\(real)(joke);
> 
> Anything else I forgot?
> 
> Or we could use special delimiter characters:
> 
> 	Positive<real>(joke);
> 	Positive“real”(joke);
> 	Positive«real»(joke);
> 	Positive#real@(joke);
> 
> Each having its own problem though.
> 
> My preference still goes to "!(".

I think this is exactly the point. ".(" don't look that much better than
"!(" (if better at all), so why should a new syntax variation should be
introduced to the language with that small (and arguable) benefit?

"enum" as the way to declare manifest constants were much more ugly than
"!(", and most of the people were against it. I don't see why ".(" should
be introduced.

And if it's introduced, you'll have to read a lot of "!(" anyways, is not
that you will be solving any problems, because all D1-ported code (and
code of people who like "!(" better) will use it instead of ".(" (unless
"!(" stops working, in which case it's really dumb to make D1 incompatible
with D2 for this such a small aesthetic issue). So you'll just make things
whorse.

-1 for ".("


PS: I wont use Positive!() either ;)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Es mas posible, que un elefante maneje un cero km a que un camello
habite un departamento de un ambiente.
	-- Peperino Pómoro
October 05, 2008
Re: shouting versus dotting
Andrei Alexandrescu, el  5 de octubre a las 09:41 me escribiste:
> I'd want to give it a try. How do others feel about Template{arguments}?

I feel is unnecessary to change the template instantiation syntax.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
"CIRILO" Y "SIRACUSA" DE "SEÑORITA MAESTRA": UNO MUERTO Y OTRO PRESO
	-- Crónica TV
October 05, 2008
Re: Positive
Reply to Andrei,

> Hello,
> 
> (Background: Walter has kindly allowed ".()" as an alternative to the
> ugly "!()" for template argument specifications.)
> 


Just adding more gas to the fire... Please, Oh Please NO!!!

I think the runtime/compiletime distinction is important, sort of for the 
same reason that cast(T) is used (make things stand out, but Re '!' not as 
a bad thing).
October 05, 2008
Re: shouting versus dotting
Andrei Alexandrescu wrote:
> I prefer the colon too, if ambiguity with ?: can be taken care of.

There's also an ambiguity with statement labels:

  L1: (*foo)();
October 05, 2008
Re: shouting versus dotting
Leandro Lucarella wrote:
> Michel Fortin, el  5 de octubre a las 03:53 me escribiste:
>> On 2008-10-05 01:14:17 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
>>
>>> I don't favor "." any more than the next guy, but I am glad there is awareness of how unfit a choice "!" is. If you have any ideas, please post them! Ah! I! 
>>> Exclaimed! Again!
>> Hum, I don't think we have much choice, it'll have to be something in this lot:
>>
>> 	Positive!(real)(joke);
>> 	Positive.(real)(joke);
>> 	Positive#(real)(joke);
>> 	Positive@(real)(joke);
>> 	Positive&(real)(joke);
>> 	Positive`(real)(joke);
>> 	Positive´(real)(joke);
>> 	Positive^(real)(joke);
>> 	Positive¨(real)(joke);
>> 	Positive\(real)(joke);
>>
>> Anything else I forgot?
>>
>> Or we could use special delimiter characters:
>>
>> 	Positive<real>(joke);
>> 	Positive“real”(joke);
>> 	Positive«real»(joke);
>> 	Positive#real@(joke);
>>
>> Each having its own problem though.
>>
>> My preference still goes to "!(".
> 
> I think this is exactly the point. ".(" don't look that much better than
> "!(" (if better at all), so why should a new syntax variation should be
> introduced to the language with that small (and arguable) benefit?

I think it's reasonable to say that The Sad Pirate won't make it. I hope 
a different fate awaits for unparenthesized instantiations.

> "enum" as the way to declare manifest constants were much more ugly than
> "!(", and most of the people were against it. I don't see why ".(" should
> be introduced.

Ugly or not, enumerated symbols were manifest constants to begin with. 
That's kinda hard to argue against because it's a sheer fact.

> And if it's introduced, you'll have to read a lot of "!(" anyways, is not
> that you will be solving any problems, because all D1-ported code (and
> code of people who like "!(" better) will use it instead of ".(" (unless
> "!(" stops working, in which case it's really dumb to make D1 incompatible
> with D2 for this such a small aesthetic issue). So you'll just make things
> whorse.
> 
> -1 for ".("
> 
> 
> PS: I wont use Positive!() either ;)

Would you use Bounded? It takes a type, a minimum, and a maximum.


Andrei
October 05, 2008
Re: Positive
BCS wrote:
> Reply to Andrei,
> 
>> Hello,
>>
>> (Background: Walter has kindly allowed ".()" as an alternative to the
>> ugly "!()" for template argument specifications.)
>>
> 
> 
> Just adding more gas to the fire... Please, Oh Please NO!!!
> 
> I think the runtime/compiletime distinction is important, sort of for 
> the same reason that cast(T) is used (make things stand out, but Re '!' 
> not as a bad thing).

This has been discussed. Implicit function template instantiation and 
compile-time function evaluation have been successful partly because 
they unify the run-time and the compile-time realms.

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

> Bruce Adams wrote:
>> On Sun, 05 Oct 2008 03:35:57 +0100, Andrei Alexandrescu  
>> <SeeWebsiteForEmail@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.
October 05, 2008
Re: Positive
Reply to Andrei,

> BCS wrote:
> 
>> Reply to Andrei,
>> 
>>> Hello,
>>> 
>>> (Background: Walter has kindly allowed ".()" as an alternative to
>>> the ugly "!()" for template argument specifications.)
>>> 
>> Just adding more gas to the fire... Please, Oh Please NO!!!
>> 
>> I think the runtime/compiletime distinction is important, sort of for
>> the same reason that cast(T) is used (make things stand out, but Re
>> '!' not as a bad thing).
>> 
> This has been discussed. Implicit function template instantiation and
> compile-time function evaluation have been successful partly because
> they unify the run-time and the compile-time realms.
> 
> Andrei
> 

Yes they are good because they unify the implementation of RT&CT but that's 
not what I'm referring to. What I am liking is the disjunction between the 
use of them. I want to be able to look at a block of code and see at a glance 
that it will collapse to nothing in the executable or get put in as code 
to get executed.
10 11 12 13 14 15 16 17 18
Top | Discussion index | About this forum | D home