October 05, 2008
Andrei Alexandrescu wrote:
> Alexander Pánek 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.
>>>
>>> I didn't have much beef with other oddities unique to D. For example, I found no problem accommodating binary "~" and I was wondering what makes "!" different. I was just looking at a page full of templates and it looked like crap.
>>>
>>> One morning I woke up with the sudden realization of what the problem was: the shouting.
>>>
>>> In C, "!" is used as a unary operator. That may seem odd at first, but it nevers follows a word so it's tenuous to associate it with the natural language "!". In D, binary "!" _always_ follows a word, a name, something coming from natural language. So the conotation with exclamation jumps at you.
>>>
>>> That's why I find the choice of "!" poor. I believe it can impede to some extent acquisition of templates by newcomers, and conversely I believe that using .() can make templates more palatable. I tried using ".()" in my code and in only a couple of days it looked and felt way better to me. Based on that experience, I suggest that "!()" is dropped in favor of ".()" for template instantiation for D2.
>>>
>>> Sean's argument that "The exclamation mark signifies an assertion of sorts" is exactly where I'd want templates not to be: they should be blended in, not a hiccup from normal code. Serious effort has been, and still is, made in D to avoid shell-shocking people about use of templates, and I think ".()" would be a good step in that direction.
>>
>> Sean has a point. Templates are not runtime constructs. So a clear distinction between instantiating a function with a given type and just calling a function that has fixed argument types and a fixed return type  is necessary.
> 
> Why? This sounds objective, so you better back it up. Au contraire, I see absolutely, but absolutely no need for a distinction. If it weren't for syntactic difficulties, to me using straight parentheses for template instantiation would have been the perfect choice. (How many times did you just forget the "!"? I know I often do. Why? Because most of the time it's not even needed.)
> 
>> The exclamation mark gives us this clear distinction and has served well in terms of readability for me, especially because it jumps out — not because it’s an exclamation mark, thus having a meaning in natural language, but rather just because of its form. A straight vertical line with a dot underneath it. That just works perfectly well as seperator between identifier/type and type argument.
> 
> I believe the clear distinction is not only unnecessary, but undesirable. We should actively fight against it.

IMHO — I forgot that before, so that’s why it might have sounded a bit too objective —, the clear distinction is important to keep the code self-documenting. It might not be so important in terms of freestanding templated functions that might even be simple enough that the argument types can be infered, but as soon as something heavily alters the way the code and the binary looks like afterwards (CTFE, multiple templated class/struct/function instantiates, string mixins created by CTFE functions, etc.), it (again, in my truly subjective opinion) deserves to be marked as such.

I see this distinction as feature, not as flaw.
October 05, 2008
Alexander Pánek wrote:
> Andrei Alexandrescu wrote:
>> Alexander Pánek 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.
>>>>
>>>> I didn't have much beef with other oddities unique to D. For example, I found no problem accommodating binary "~" and I was wondering what makes "!" different. I was just looking at a page full of templates and it looked like crap.
>>>>
>>>> One morning I woke up with the sudden realization of what the problem was: the shouting.
>>>>
>>>> In C, "!" is used as a unary operator. That may seem odd at first, but it nevers follows a word so it's tenuous to associate it with the natural language "!". In D, binary "!" _always_ follows a word, a name, something coming from natural language. So the conotation with exclamation jumps at you.
>>>>
>>>> That's why I find the choice of "!" poor. I believe it can impede to some extent acquisition of templates by newcomers, and conversely I believe that using .() can make templates more palatable. I tried using ".()" in my code and in only a couple of days it looked and felt way better to me. Based on that experience, I suggest that "!()" is dropped in favor of ".()" for template instantiation for D2.
>>>>
>>>> Sean's argument that "The exclamation mark signifies an assertion of sorts" is exactly where I'd want templates not to be: they should be blended in, not a hiccup from normal code. Serious effort has been, and still is, made in D to avoid shell-shocking people about use of templates, and I think ".()" would be a good step in that direction.
>>>
>>> Sean has a point. Templates are not runtime constructs. So a clear distinction between instantiating a function with a given type and just calling a function that has fixed argument types and a fixed return type  is necessary.
>>
>> Why? This sounds objective, so you better back it up. Au contraire, I see absolutely, but absolutely no need for a distinction. If it weren't for syntactic difficulties, to me using straight parentheses for template instantiation would have been the perfect choice. (How many times did you just forget the "!"? I know I often do. Why? Because most of the time it's not even needed.)
>>
>>> The exclamation mark gives us this clear distinction and has served well in terms of readability for me, especially because it jumps out — not because it’s an exclamation mark, thus having a meaning in natural language, but rather just because of its form. A straight vertical line with a dot underneath it. That just works perfectly well as seperator between identifier/type and type argument.
>>
>> I believe the clear distinction is not only unnecessary, but undesirable. We should actively fight against it.
> 
> IMHO — I forgot that before, so that’s why it might have sounded a bit too objective —, the clear distinction is important to keep the code self-documenting. It might not be so important in terms of freestanding templated functions that might even be simple enough that the argument types can be infered, but as soon as something heavily alters the way the code and the binary looks like afterwards (CTFE, multiple templated class/struct/function instantiates, string mixins created by CTFE functions, etc.), it (again, in my truly subjective opinion) deserves to be marked as such.
> 
> I see this distinction as feature, not as flaw.

I don't understand this argument. For one thing, argument type deduction for template functions is not simple at all and we're glad that it's taken care of.

Andrei
October 05, 2008
Graham St Jack wrote:
> I prefer your suggestion of ufloat/udouble/ureal to Positive, and I
> would definitely use these. I already use unsigned integer types a
> LOT, even more than signed ones.
> 
> Have you thought how (and if) auto-casting would work?

I did, and it would work. The problem is there's no precedent for it.

double x;
...
auto y = sqrt(x);

That will do a runtime check and throw if x is negative. That's unprecedented for an implicit cast, so I was thinking of defining a
universal "unsigned" template function that does the check:

auto y = sqrt(unsigned(x));

> As far as template instantiation goes, my feeling is that the "." is
> too easily confused with method invocation. I know you are trying to
> make them look more similar, but for we mere mortals that don't do
> much template programming, we need something that stand out more.
> Something less alarming than "!" would be ok, so long as there was
> ONLY ONE way.

I agree that in the end there should be only one man standing. And the reference to mere mortals makes me think we should bring the mountain to them instead of them to the mountain. I know, lame metaphor.


Andrei
October 05, 2008
superdan wrote:
> Andrei Alexandrescu Wrote:
> 
>> dsimcha wrote:
>>> == Quote from Andrei Alexandrescu
>>> (SeeWebsiteForEmail@erdani.org)'s article
>>>> 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. I didn't have much
>>>> beef with other oddities unique to D. For example, I found no
>>>> problem accommodating binary "~" and I was wondering what makes
>>>>  "!" different. I was just looking at a page full of templates
>>>> and it looked like crap. One morning I woke up with the sudden
>>>> realization of what the problem was: the shouting. In C, "!" is
>>>> used as a unary operator. That may seem odd at first, but it
>>>> nevers follows a word so it's tenuous to associate it with the natural language "!". In D, binary "!" _always_ follows a word,
>>>> a name, something coming from natural language. So the
>>>> conotation with exclamation jumps at you. That's why I find the
>>>> choice of "!" poor. I believe it can impede to some extent
>>>> acquisition of templates by newcomers, and conversely I believe
>>>> that using .() can make templates more palatable. I tried using
>>>>  ".()" in my code and in only a couple of days it looked and
>>>> felt way better to me. Based on that experience, I suggest that
>>>> "!()" is dropped in favor of ".()" for template instantiation
>>>> for D2. Sean's argument that "The exclamation mark signifies an
>>>> assertion of sorts" is exactly where I'd want templates not to
>>>> be: they should be blended in, not a hiccup from normal code.
>>>> Serious effort has been, and still is, made in D to avoid
>>>> shell-shocking people about use of templates, and I think ".()"
>>>> would be a good step in that direction. Andrei
>>> Personally, I think that ".()" looks a little too much like a
>>> normal function/method call.  The "!()" syntax looks just
>>> different enough to make it easy to keep straight in my head that
>>> stuff with the "!" is a compile-time construct and stuff without
>>> it can be evaluated at runtime.
>> I'm arguing we _should_ make template code look like "normal" code,
>>  whatever "normal" is :o). We _should_ strive for "quiet"
>> templates.
>> 
>> You know what annoys the living heebiejeebies out of me? Nested
>> template instantiations.
>> 
>> This!(That!(TheOther!(crap)))
>> 
>> I have a ton + change of those. In superdan's words: intercourse
>> that.
>> 
>> 
>> Andrei
> 
> im a bit drunk. but im much obliged since my name was mentioned n
> all.
> 
> ! pisses me off too. i have an opinion. walter looked at unary ops
> that can be binary ops. first tilde. pulled tat off. ten he wanted
> the template thing. only 1 left was !. so he put that at work. right
> walt? now i never like ! because of nother reason. i always forget to
> put it. and yes it's not needed. i look @ code its unambig. then wtf
> do i need that crap !
> 
> anyhoo would be great if ! goes away. to hell with it. need to try
> asdad.(asdasd) to see how it feels. and yeah they all jump andreis
> neck whever he posts any. or walts. its funny. hold them guns folks.
> can i delete this later i wonder.

I guess this still counts as a vote! No? :o)

Andrei
October 05, 2008
"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>> "Walter Bright" wrote
>>> Steven Schveighoffer wrote:
>>>> It's very alarming to me that something like this just has no problem getting in the language without community feedback.
>>> It's there at the moment so we can look at it and see if we like it. I know Andrei likes it. Anyhow, this is the opportunity for community feedback.
>>
>> Well, here is my feedback.
>>
>> First, I hate it when D has two ways of doing something.  For example, C style array declarations, or function pointers.  But those have good reasons.  We want the new style because it's unambiguous and context-free, but we want the old style to allow easy porting of C code.
>
> I agree that D should not gratuitously define two ways of doing something.
>
>> But this change has no qualities I can see except that Andrei thinks it looks better (at least, that's the only reason he's given).
>
> Believes, not thinks :o).

yes, of course, my bad.

>
>> There are not compatibility issues with C or some other language, it's just a new syntax that looks different.  Are there problems with the original !()?  Please give a reason for this addition besides asthetics, and then we can discuss the merits.  Or if the community overwhelmingly loves this new syntax, I guess that's a good reason.  Otherwise, I think it should be rejected on the simple principle of not fixing things that aren't broken.
>
> There are no objective differences, only the subjective arguments I brought based on linguistic conotations of "!". And actually I didn't come up with that argument - it literally came to me. Word followed by exclamation mark. Our brains are wired to interpret that as an exclamation. If it's frequent enough in code, it becomes really jarring.

For what it's worth, I never had a 'jarring' experience with the ! syntax. It reads perfectly fine to me, and I actually like it.

> The one way to figure whether you'd aesthetically like something or not is to try it on some code. Unfortunately, that's not yet possible until the next release (Walter was kind enough to send me an alpha for a test drive). So my only request is kindly please hold off judgment until you can play with the notation and see how you feel.

Firstly, I won't be playing with it unless it's released for D1 (which I doubt), and secondly, I don't think it's worth the effort to have something like this changed for minor annoyance.  Since it's completely engrained on our brains already and we get along fine with !, there should have to be a really good reason to change it.  'looking better' doesn't strike me as a really good reason, especially when it is subjective (and especially when I disagree with the opinion).  This seems like a bicycle shed issue to me.

Please note, I'm not arguing for ! because of some technical reason, I probably would have been fine with ., but since it's already !, I think we should keep it that way unless a good technical reason comes up.  The reasons you have put forth don't make it worth it in my mind.

If this change is implemented, Walter is going to have a hard time arguing that it's not worth changing invariant to immutable...

-Steve


October 05, 2008
Andrei Alexandrescu wrote:
> Alexander Pánek 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.
>>>
>>> I didn't have much beef with other oddities unique to D. For example, I found no problem accommodating binary "~" and I was wondering what makes "!" different. I was just looking at a page full of templates and it looked like crap.
>>>
>>> One morning I woke up with the sudden realization of what the problem was: the shouting.
>>>
>>> In C, "!" is used as a unary operator. That may seem odd at first, but it nevers follows a word so it's tenuous to associate it with the natural language "!". In D, binary "!" _always_ follows a word, a name, something coming from natural language. So the conotation with exclamation jumps at you.
>>>
>>> That's why I find the choice of "!" poor. I believe it can impede to some extent acquisition of templates by newcomers, and conversely I believe that using .() can make templates more palatable. I tried using ".()" in my code and in only a couple of days it looked and felt way better to me. Based on that experience, I suggest that "!()" is dropped in favor of ".()" for template instantiation for D2.
>>>
>>> Sean's argument that "The exclamation mark signifies an assertion of sorts" is exactly where I'd want templates not to be: they should be blended in, not a hiccup from normal code. Serious effort has been, and still is, made in D to avoid shell-shocking people about use of templates, and I think ".()" would be a good step in that direction.
>>
>> Sean has a point. Templates are not runtime constructs. So a clear distinction between instantiating a function with a given type and just calling a function that has fixed argument types and a fixed return type  is necessary.
> 
> Why? This sounds objective, so you better back it up.

I like being able to distinguish between the function signature and the parameter list and to tell at a glance what's actually happening.  Since the dot already has a function in this context, I don't think it should be given another.  Also, if we get the option to override opDot, things could get really weird if it's also a template signifier.

>> The exclamation mark gives us this clear distinction and has served well in terms of readability for me, especially because it jumps out — not because it’s an exclamation mark, thus having a meaning in natural language, but rather just because of its form. A straight vertical line with a dot underneath it. That just works perfectly well as seperator between identifier/type and type argument.
> 
> I believe the clear distinction is not only unnecessary, but undesirable. We should actively fight against it.

Why is it undesirable?  I like the idea of static parameters as described at the conference last year, but I don't think that has any bearing on this particular issue.


Sean
October 05, 2008
Andrei Alexandrescu wrote:
> Steven Schveighoffer wrote:
>> "Walter Bright" wrote
>>> Steven Schveighoffer wrote:
>>>> It's very alarming to me that something like this just has no problem getting in the language without community feedback.
>>> It's there at the moment so we can look at it and see if we like it. I know Andrei likes it. Anyhow, this is the opportunity for community feedback.
>>
>> Well, here is my feedback.
>>
>> First, I hate it when D has two ways of doing something.  For example, C style array declarations, or function pointers.  But those have good reasons.  We want the new style because it's unambiguous and context-free, but we want the old style to allow easy porting of C code.
> 
> I agree that D should not gratuitously define two ways of doing something.
> 
>> But this change has no qualities I can see except that Andrei thinks it looks better (at least, that's the only reason he's given).
> 
> Believes, not thinks :o).
> 
>> There are not compatibility issues with C or some other language, it's just a new syntax that looks different.  Are there problems with the original !()?  Please give a reason for this addition besides asthetics, and then we can discuss the merits.  Or if the community overwhelmingly loves this new syntax, I guess that's a good reason.  Otherwise, I think it should be rejected on the simple principle of not fixing things that aren't broken.
> 
> There are no objective differences, only the subjective arguments I brought based on linguistic conotations of "!". And actually I didn't come up with that argument - it literally came to me. Word followed by exclamation mark. Our brains are wired to interpret that as an exclamation. If it's frequent enough in code, it becomes really jarring.

I like the use of '!' specifically for its linguistic connotation.  It communicates to me that what's happening isn't normal run-time stuff.

> The one way to figure whether you'd aesthetically like something or not is to try it on some code. Unfortunately, that's not yet possible until the next release (Walter was kind enough to send me an alpha for a test drive). So my only request is kindly please hold off judgment until you can play with the notation and see how you feel.

Will do.  It's easy enough to search-replace '!' with '.'


Sean
October 05, 2008
Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>> Steven Schveighoffer wrote:
>>> "Walter Bright" wrote
>>>> Steven Schveighoffer wrote:
>>>>> It's very alarming to me that something like this just has no problem getting in the language without community feedback.
>>>> It's there at the moment so we can look at it and see if we like it. I know Andrei likes it. Anyhow, this is the opportunity for community feedback.
>>> Well, here is my feedback.
>>>
>>> First, I hate it when D has two ways of doing something.  For example, C style array declarations, or function pointers.  But those have good reasons.  We want the new style because it's unambiguous and context-free, but we want the old style to allow easy porting of C code.
>> I agree that D should not gratuitously define two ways of doing something.
>>
>>> But this change has no qualities I can see except that Andrei thinks it looks better (at least, that's the only reason he's given).
>> Believes, not thinks :o).
> 
> yes, of course, my bad.
> 
>>> There are not compatibility issues with C or some other language, it's just a new syntax that looks different.  Are there problems with the original !()?  Please give a reason for this addition besides asthetics, and then we can discuss the merits.  Or if the community overwhelmingly loves this new syntax, I guess that's a good reason.  Otherwise, I think it should be rejected on the simple principle of not fixing things that aren't broken.
>> There are no objective differences, only the subjective arguments I brought based on linguistic conotations of "!". And actually I didn't come up with that argument - it literally came to me. Word followed by exclamation mark. Our brains are wired to interpret that as an exclamation. If it's frequent enough in code, it becomes really jarring.
> 
> For what it's worth, I never had a 'jarring' experience with the ! syntax. It reads perfectly fine to me, and I actually like it.
> 
>> The one way to figure whether you'd aesthetically like something or not is to try it on some code. Unfortunately, that's not yet possible until the next release (Walter was kind enough to send me an alpha for a test drive). So my only request is kindly please hold off judgment until you can play with the notation and see how you feel.
> 
> Firstly, I won't be playing with it unless it's released for D1 (which I doubt), and secondly, I don't think it's worth the effort to have something like this changed for minor annoyance.  Since it's completely engrained on our brains already and we get along fine with !, there should have to be a really good reason to change it.  'looking better' doesn't strike me as a really good reason, especially when it is subjective (and especially when I disagree with the opinion).  This seems like a bicycle shed issue to me.

hehe... how about we swap '!' for '.' and in exchange we get to use something other than 'enum' for manifest constants ;-)


Sean
October 05, 2008
Andrei Alexandrescu wrote:
> Hello,
> 
> 
> (Background: Walter has kindly allowed ".()" as an alternative to the ugly "!()" for template argument specifications.)
> 
> Just a quick question - I am feeling an increasing desire to add a template called Positive to std.typecons. Then Positive.(real) would restrict its values to only positive real numbers etc.
> 
> The implementation would accept conversion from its base type, e.g. Positive.(real) can be constructed from a real. The constructor enforces dynamically the condition. Also, Positive.(real) accepts implicit conversion to real (no checking necessary).
> 
> There are many places in which Positive can be useful, most notably specifications of interfaces. For example:
> 
> Positive.(real) sqrt(Positive.(real) x);
> 
> These specifications are also efficient because checking for positivity is done outside sqrt; if you had a Positive.(real) to start with, there is no cascading checking necessary so there's one test less to do.
> 
> However, there is also the risk that Positive has the same fate the many SafeInt implementation have had in C++: many defined them, nobody used them. What do you think? If you had Positive in std and felt like crunching some numbers, would you use it?
> 
> In order to get things really started, there's already been an exchange with Walter on the matter. His reply was (I haven't asked for permission, but I'm pretty sure he'd agree making it public):
> 
> ==============
> Honestly, I wouldn't use it. I'd rather have an in contract for sqrt that asserts the argument is positive. Also, this opens the door to Negative, NegativeOrZero, ZeroOrInfinity, Odd, Even, Prime, SixOrFifteen, etc.
> ==============
> 
> My answer to that was:
> 
> ==============
> About contracts: Let me explain how I think that's inferior to Positive in two ways.
> 
> 1. Enough functions are defined on positive numbers only, to justify factoring that contract out of the functions themselves.
> 
> 2. The efficiency perk is that when using several such functions together, there's only one check; once in Positive-land, no more checks are necessary.
> 
> About proliferation of types: I don't think that follows at all. Math found positive numbers special enough to dedicate them a special notation (|R with subscript "+"). There's also a special notation for nonzero real numbers (|R with superscript "*"). There is no special notation for any of the sets you mentioned. That is bound to mean something.
> ==============
> 
> I'm interesting in further arguments. This feature is a numbers issue (pun not intended), meaning it will be any good only if enough people find it useful enough to actually use it in their own code and libraries, therefore building momentum behind it.
> 
> 
> Andrei

As others have mentioned.

Why a second class form of range restriction?  Why not a first class implementation like ADA's with ranges and subranges as specific typedefs?  I know it would be more work for the compiler writer to implement (if it can't be done in templates) however I prefer more generic solutions then having many once-off solutions that crudely fit together.

Being able to simply pick a type that is within the range needed would save having to write contracts and static contracts all over the place. 
 It also a great form of documentation.  I would find that useful, particularly when working with algorithms that traverse arrays in specific sequences such as spacial data structures but need to maintain certain constraints.

-Joel
October 05, 2008
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 "!(".

- - -

The ".(" syntax makes me think more of something like this:

	void func(T, alias methodOfT, A...)(T obj, A args)
	{
		obj.(methodOfT)(args);
	}

which I which I could do. If methodOfT was a string, I suppose I could use string mixins, but it pushes diagnostics about misnamed methods further in the template and requires adding quotes to the template parameter when instanciating.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

1 2 3 4 5 6 7 8 9 10 11 12 13 14
Top | Discussion index | About this forum | D home