October 11, 2008
Dave wrote:
> "KennyTM~" <kennytm@gmail.com> wrote in message news:gcqnqd$161r$1@digitalmars.com...
>> Dave wrote:
>>>
>>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:gcogl4$28ui$1@digitalmars.com...
>>>> We seem to have reached a dead end on finding a significantly better alternative than foo!(bar).
>>>>
>>>> All is not lost, though. Andrei is working on an emacs module that will parse D code and replace foo!(bar) with foo«bar» for display only when the editor is in D mode, the underlying text will still be foo!(bar). (This doesn't affect D at all, only its display in Emacs.)
>>>>
>>>> Also, we're going to try using ! for single argument syntax, as in:
>>>>
>>>> foo!bar  is same as   foo!(bar)
>>>> foo!10   is same as   foo!(10)
>>>>
>>>> etc. 0 arguments or more than 1 argument or arguments that are more than one token long will still require !( ). We'll see how that works. I think it looks rather nice.
>>>
>>> I don't like it because it is not consistent and therefore could make things ugly and even harder to comprehend where clarity is needed most --  in a file full of mixed length template instantiations. It reeks of total hack to me, and I think this is opening a huge can of worms regarding the a!b!c issue. Inconsistency and things that smack of potential "corner case" are never good.
>>>
>>
>> You can always use !(...); the current proposal is backward-compat.
>>
> 
> But the problem I have with it is some poor sucker maintaining someone else's code who uses the new syntax, maybe even inconsistently in the same module.
> 
>> I wonder why no one complains “3 - 4 - 5” brings a huge can of worm. The problem of ! as I see is that it is not associative (a!(b!c) != (a!b)!c), so we can just define an associativity preference just like the - (left-assoc) and = (right-assoc) operators.
>>
> 
> Good point, except that would mean yet more rules to remember when the current !() syntax makes it clear. This whole thing will just make D templates harder to learn, understand, use and maintain.
> 
>>> I hadn't seen this mentioned lately; C#, Java and now C++0x are able to work around the '> >' issue and allow '>>'.
>>>
>>> a) It works for C++0x so it can be made to work for D using the same rules. I also assume that C# and Java compilers use the same methods as C++0x to work around the ambiguities with the right-shift operator.
>>
>> The argument against T<x> from the start is that it is more difficult to parse. It is not impossible, it is just difficult. You can blame Walter for being lazy.
>>
> 
> Lazy doesn't mean to Walter what it means to the rest of us... To Walter, "lazy" is another way of saying for "I don't agree and I'd rather just do something else" <g>
> 

lol.

> I just saw a post where Walter says he hates the angle brackets and that syntax matters. I agree that syntax does matter, and apparently many developers and other language designers don't have a problem with the "<>" syntax. So maybe Walter needs to bite the bullet and D should just use it. Maybe D is bucking a trend here where it shouldn't.
> 
>>> b) Easier and more natural for D newbies who've used C++ templates and/or C# / Java Generics.
>>
>> I agree.
>>
> 
> This is probably the biggest issue since D has to win mindshare or else what is the point of this or any other discussion.
> 
>>> c) There can be no D code where ">>" instead of "> >" breaks existing code like C++98 vs C++0x.
>>> d) There wouldn't be the "I hate it because it's not C++ enough" first impression for templates.
>>
>> I don't know if there's anyone arguing this, and I'm OK with !(...).
>>
>>> e) Less typing compared to current.
>>
>> Even less using the new a!b syntax.
>>
>>> f) Could make definition and instantiation consistent as well:
>>> class C<T> {T val;}
>>> auto c = new C<int>;
>>
>> This is an irrelevant design issue. D can be engineered to support
>>
>> class C!T {
>>   T val;
>> }
>> auto c = new C!int;
>>
> 
> Even more inconsistency and duplication <g>
> 
>> as well I believe, but the current implementation uses class C(T) instead. (BTW, you've left out the “template <typename T>” line before the class C<T> statement.)
>>
> 
> I don't understand... I was talking about just replacing () and !() with the <> that C++, C# and Java use, not changing anything else regarding D template syntax.
> 

I thought you argued

class C(T) { T val; }
auto c = new C!(int);

is inconsistent because in definition you used (...) but in usage you used !(...) ?

>>> g) I'm sure the same workaround could be used for D's UShr operator '>>>'.
>>> h) Andrei will like it better because it's closer to chevrons <g>
>>
>> Me too «g»
>>
>>>
>>> Also, as long as I'm thinking out of the box here, for D2 how about considering using a different group of symbols for bitwise shift (if for some reason the ambiguity issue is too large to work around)?
>>>
>>> Before you yell "Sacralidge!" and roll your eyes, consider that out of about 100K lines of D code in phobos, 381 have "<<|>>" and  1711 have "!(.*)". Also, '>>>' is only used 25 times in phobos and could be replaced with '>>' and a cast where it is used.
>>>
>>> Perhaps ~> (shr), ~< (shl), ~>> (ushr), ~<= (shlAssign) and ~>= (shrAssign)?
>>>
>>> Just a thought.
>>>
>>> Still there may be an issue with a<b,c>d, but again that is apparently solved in C#, Java  and C++0x, and I didn't find any of that used in phobos. I think the way they solved this in C# at least was to disallow the comma operator between conditional predicates, which I don't see as a huge issue.
>>>
>>> - Dave
>>>
> 
October 11, 2008
On 2008-10-11 02:22:22 -0400, Walter Bright <newshound1@digitalmars.com> said:

> Sergey Gromov wrote:
>> so that even a!b!c!(x,y) works as a!(b!(c!(x,y))), but a!(b)!(c) is not accepted.
> 
> I don't think it's a good idea to say that a!(b)!(c) is never allowed. It intuitively means that a!(b) is aliased to another template.

There is a couple of those in the D/Objective-C bridge. Basically, a few function templates are defined like this:

	template invoke(ReturnType, char[] methodName)
	{
		ReturnType invoke(Args...)(Args args)
		{
			// call the method while wrapping all elements as necessary
		}
	}

It's generally used like this:

	invoke!(void, "setColor")(color);

The nested-template trick avoids having to write all the function's arguments types since for the inner template, arguments are deduced from the function call. But if you want to be explicit about the argument types, you can do a chained template:

	invoke!(void, "setColor")!(NSColor)(color);

Isn't that a funny line? Now, how readable is this one:

	invoke!(void, "setColor")!NSColor(color);

?

- - -

I'd like it very much if templates such as these could work with only one argument list, such as:

	invoke(void, "setColor", color);

It makes this example simpler to read, because now you don't have to bother about all the technicalities of what is a template parameter and what is a runtime parameter. It could probably simplify the definition too. Here is what I have in mind for the function declaration:

	ReturnType invoke(typename ReturnType, static char[] methodName, auto(Args...) args)
	{
		...
	}

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

October 11, 2008
"Dave" <Dave_member@pathlink.com> wrote in message news:gcqrbr$1cg4$1@digitalmars.com...
> "KennyTM~" <kennytm@gmail.com> wrote in message news:gcqnqd$161r$1@digitalmars.com...
>> Dave wrote:
>>> a) It works for C++0x so it can be made to work for D using the same rules. I also assume that C# and Java compilers use the same methods as C++0x to work around the ambiguities with the right-shift operator.
>>
>> The argument against T<x> from the start is that it is more difficult to parse. It is not impossible, it is just difficult. You can blame Walter for being lazy.
>>
>
> Lazy doesn't mean to Walter what it means to the rest of us... To Walter, "lazy" is another way of saying for "I don't agree and I'd rather just do something else" <g>
>
> I just saw a post where Walter says he hates the angle brackets and that syntax matters. I agree that syntax does matter, and apparently many developers and other language designers don't have a problem with the "<>" syntax. So maybe Walter needs to bite the bullet and D should just use it. Maybe D is bucking a trend here where it shouldn't.
>

One of the original guiding principles of D is that it be easy to parse. There were a number of valid reasons for this, not just lazyness.

Plus, I'm no compiler expert, but I think I rememebr hearing somewhere that overloadng <> to be usable for both comparisons and grouping would require non-context-free grammar. That would be a major increase in D's parsing complexity. C++ grammer is definately not context-free, that's why it can get away with it. Not sure about C# or Java, but I've been under the impression those aren't context-free either.

>>> b) Easier and more natural for D newbies who've used C++ templates and/or C# / Java Generics.
>>
>> I agree.
>>
>
> This is probably the biggest issue since D has to win mindshare or else what is the point of this or any other discussion.
>

I consider this a non-issue. D is a different language, it's expected that certain things are going to be different. Otherwise it would be the same damn language. I had used C++ templates before I came across D, and my entire thought on it was just "Ok, C++ uses <>, and D uses !()". Done. It's no more of an issue than switching between Java's "{}" and ";" and VB.NET's "X...end X" and "newline".

D needs to win mindshare, sure, but there are better ways to do that than advertising a popular bikeshed color.


October 11, 2008
Bill Baxter wrote:
> But people don't say they have to copy&paste code because the word
> "invariant" blocks their brains from remembering how to write the
> code.  If there's something hard to remember about how to write such
> code, changing the word from "invariant" to "immutable" isn't going to
> change that.  That's all I'm tryin' to say.

Ok.
October 11, 2008
Dave wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:gcogl4$28ui$1@digitalmars.com...
>> We seem to have reached a dead end on finding a significantly better alternative than foo!(bar).
>>
>> All is not lost, though. Andrei is working on an emacs module that will parse D code and replace foo!(bar) with foo«bar» for display only when the editor is in D mode, the underlying text will still be foo!(bar). (This doesn't affect D at all, only its display in Emacs.)
>>
> 
> So, we have one of the most prolific, important and published D template library developers using chevrons where someone opening that with any other editor would see foo!(bar) or perhaps foo!bar. And this is all encouraged by the primary language architect. Nuts!

I think there's some misunderstanding here. What exactly seems to be the problem?

> I can also see this causing issues with continuity of style, where some particular arrangement of code would look readable with chevrons and not !(), or vice-versa.

I think that's a very tenuous claim to make. One wouldn't write code such that it looks a certain way, but rather that it does certain things.

> When Andrei writes his articles and books, which would he use in the text?

The standard notation. The fact that I'd be using whatever editor embellishments is irrelevant, and in fact I find it a bit bizarre that you even care about that. Is my use of syntax coloring an issue as well?

> I mean Andrei can setup emacs anyway he wants, but this also smacks of something being "blessed" by the language designer.
> 
> More lunacy! <g>
> 
> Let's all take a deep breath any think this through a little longer...

A deep breath is sure what I needed after reading your post.


Andrei

October 11, 2008
Dave wrote:
> 
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:gcogl4$28ui$1@digitalmars.com...
>> We seem to have reached a dead end on finding a significantly better alternative than foo!(bar).
>>
>> All is not lost, though. Andrei is working on an emacs module that will parse D code and replace foo!(bar) with foo«bar» for display only when the editor is in D mode, the underlying text will still be foo!(bar). (This doesn't affect D at all, only its display in Emacs.)
>>
>> Also, we're going to try using ! for single argument syntax, as in:
>>
>> foo!bar  is same as   foo!(bar)
>> foo!10   is same as   foo!(10)
>>
>> etc. 0 arguments or more than 1 argument or arguments that are more than one token long will still require !( ). We'll see how that works. I think it looks rather nice.
> 
> I don't like it because it is not consistent and therefore could make things ugly and even harder to comprehend where clarity is needed most -- in a file full of mixed length template instantiations. It reeks of total hack to me, and I think this is opening a huge can of worms regarding the a!b!c issue. Inconsistency and things that smack of potential "corner case" are never good.
> 
> I hadn't seen this mentioned lately; C#, Java and now C++0x are able to work around the '> >' issue and allow '>>'.

It doesn't quite deserve much mentioning. C++ has had at best a Pyrrhic
victory with accommodating ">>" (the cost was a keyword, a special
syntax, and a few special syntax cases). Java's templates are
emasculated to begin with, and ">>" makes sure they won't easily become
more powerful.

> a) It works for C++0x so it can be made to work for D using the same rules. I also assume that C# and Java compilers use the same methods as C++0x to work around the ambiguities with the right-shift operator.

The methods are very different and that is because Java/C# generics are
less powerful.

> b) Easier and more natural for D newbies who've used C++ templates and/or C# / Java Generics.

Does the C++ construct

a.template foo<b>(c);

strike you as particularly natural? Do you know when you need to use it
and when not? In all honesty, did you ever know it exists?

> c) There can be no D code where ">>" instead of "> >" breaks existing code like C++98 vs C++0x.

That is incorrect.

> d) There wouldn't be the "I hate it because it's not C++ enough" first impression for templates.

I think the exclamation "it's not C++ enough" usually comes with a sigh
of relief.

> e) Less typing compared to current.
> f) Could make definition and instantiation consistent as well:
> class C<T> {T val;}
> auto c = new C<int>;

That comes bundled with making writing of a D parser essentially impossible.

> g) I'm sure the same workaround could be used for D's UShr operator '>>>'.

No. That will only make things another order of magnitude harder.

> h) Andrei will like it better because it's closer to chevrons <g>

Chevrons are not ">". They do pair.

> Also, as long as I'm thinking out of the box here, for D2 how about considering using a different group of symbols for bitwise shift (if for some reason the ambiguity issue is too large to work around)?

It would also need to use a different symbol for less-than and
greater-than. But Fortran's .LT. and .GT. don't seem that enticing.

> Before you yell "Sacralidge!" and roll your eyes, consider that out of about 100K lines of D code in phobos, 381 have "<<|>>" and  1711 have "!(.*)". Also, '>>>' is only used 25 times in phobos and could be replaced with '>>' and a cast where it is used.

I agree that '>>>' should go. The compiler can simply use the type of
the operand to disambiguate signed vs. unsigned shift. I'm glad you
reminded me to remind Walter of that.

> Perhaps ~> (shr), ~< (shl), ~>> (ushr), ~<= (shlAssign) and ~>= (shrAssign)?

I like the shr :o).

> Just a thought.
> 
> Still there may be an issue with a<b,c>d, but again that is apparently solved in C#, Java  and C++0x, and I didn't find any of that used in phobos. I think the way they solved this in C# at least was to disallow the comma operator between conditional predicates, which I don't see as a huge issue.

I think you'll find it very instructive to familiarize yourself with the
ways C++, Java, and C# accommodate use of <> as brackets.


Andrei

October 11, 2008
Andrei Alexandrescu:
> I think the exclamation "it's not C++ enough" usually comes with a sigh of relief.

Quote of the week, thanks for the laugh :-)


> > Perhaps ~> (shr), ~< (shl), ~>> (ushr), ~<= (shlAssign) and ~>= (shrAssign)?
> 
> I like the shr :o).

You know that Pascal/ObjectPascal use shr and shl as operators:

x := x shl 10;

But they don't have a syntax for the shlAssign/shrAssign.

Bye,
bearophile
October 11, 2008
"Nick Sabalausky" <a@a.a> wrote in message news:gcqvfr$1k6i$1@digitalmars.com...
> "Dave" <Dave_member@pathlink.com> wrote in message news:gcqrbr$1cg4$1@digitalmars.com...
>> "KennyTM~" <kennytm@gmail.com> wrote in message news:gcqnqd$161r$1@digitalmars.com...
>>> Dave wrote:
>>>> a) It works for C++0x so it can be made to work for D using the same rules. I also assume that C# and Java compilers use the same methods as C++0x to work around the ambiguities with the right-shift operator.
>>>
>>> The argument against T<x> from the start is that it is more difficult to parse. It is not impossible, it is just difficult. You can blame Walter for being lazy.
>>>
>>
>> Lazy doesn't mean to Walter what it means to the rest of us... To Walter, "lazy" is another way of saying for "I don't agree and I'd rather just do something else" <g>
>>
>> I just saw a post where Walter says he hates the angle brackets and that syntax matters. I agree that syntax does matter, and apparently many developers and other language designers don't have a problem with the "<>" syntax. So maybe Walter needs to bite the bullet and D should just use it. Maybe D is bucking a trend here where it shouldn't.
>>
>
> One of the original guiding principles of D is that it be easy to parse. There were a number of valid reasons for this, not just lazyness.
>
> Plus, I'm no compiler expert, but I think I rememebr hearing somewhere that overloadng <> to be usable for both comparisons and grouping would require non-context-free grammar. That would be a major increase in D's parsing complexity. C++ grammer is definately not context-free, that's why it can get away with it. Not sure about C# or Java, but I've been under the impression those aren't context-free either.
>

I can see your point and to a point I think it is a valid concern.

But, most users could care less about that stuff IMO. Abstraction from what a compiler does is why we use higher-level languages in the first place <g>

I'd argue that it's more important to have demand for a language than to make it easy on the compiler writers and language designers but I agree there has to be a balance.

>>>> b) Easier and more natural for D newbies who've used C++ templates and/or C# / Java Generics.
>>>
>>> I agree.
>>>
>>
>> This is probably the biggest issue since D has to win mindshare or else what is the point of this or any other discussion.
>>
>
> I consider this a non-issue. D is a different language, it's expected that certain things are going to be different. Otherwise it would be the same damn language. I had used C++ templates before I came across D, and my entire thought on it was just "Ok, C++ uses <>, and D uses !()". Done. It's

I agree; in an earlier post I questioned any need for deviating from the current syntax. But if the concensus is that a change is needed, all I'm arguing is that it should be towards other popular C-lineage language conventions rather than further from them. There are plenty of other even more important differences (even for just templates) that make D a better language, and easier to build a compiler for, for that matter.

> no more of an issue than switching between Java's "{}" and ";" and VB.NET's "X...end X" and "newline".
>
> D needs to win mindshare, sure, but there are better ways to do that than advertising a popular bikeshed color.

For D, I see template syntax as closer to the nuclear plant than to the bikeshed in the scheme of things. Although by the amount of discussion this topic has generated, I can see your point <g>

October 11, 2008
KennyTM~ wrote:
>> I hadn't seen this mentioned lately; C#, Java and now C++0x are able to work around the '> >' issue and allow '>>'.
>>
>> a) It works for C++0x so it can be made to work for D using the same rules. I also assume that C# and Java compilers use the same methods as C++0x to work around the ambiguities with the right-shift operator.

I sympathize, because I actually prefer the Foo<Bar> syntax for template declarations.

But it's not a question of it being *harder* to parse, or Walter being "lazy". The only way to resolve the ambiguity in the parser would be to do semantic analysis during the lexical phase.

I've worked with a few open-source Java parsers, and ">>" is always recognized as a right-shift operator during tokenization. But then, if the statement doesn't make any sense, the semantic analyzer can rewrite the token stream. (I don't know how Sun does it, but I imagine it's something like that.)

As much as I like the angle-bracket template syntax, I think it's a good choice to get rid of that ambiguity.

One of the best parts of the D language design is that it's lexically unambiguous, so tokenization, syntactic analysis, and semantic analysis can be completely separate from one another.

--benji
October 11, 2008
"Benji Smith" <dlanguage@benjismith.net> wrote in message news:gcr39f$1qrm$1@digitalmars.com...
> KennyTM~ wrote:
>>> I hadn't seen this mentioned lately; C#, Java and now C++0x are able to work around the '> >' issue and allow '>>'.
>>>
>>> a) It works for C++0x so it can be made to work for D using the same rules. I also assume that C# and Java compilers use the same methods as C++0x to work around the ambiguities with the right-shift operator.
>
> I sympathize, because I actually prefer the Foo<Bar> syntax for template declarations.
>

That's the biggest reason I mentioned it, because others may prefer it and because people were discussing other alternatives that I didn't like at all.

Personally I don't have any problem with the !(), and really don't see any reason to change it, at all, including the new shortened foo!bar.

> But it's not a question of it being *harder* to parse, or Walter being "lazy". The only way to resolve the ambiguity in the parser would be to do semantic analysis during the lexical phase.
>
> I've worked with a few open-source Java parsers, and ">>" is always recognized as a right-shift operator during tokenization. But then, if the statement doesn't make any sense, the semantic analyzer can rewrite the token stream. (I don't know how Sun does it, but I imagine it's something like that.)
>
> As much as I like the angle-bracket template syntax, I think it's a good choice to get rid of that ambiguity.
>

My thoughts exactly when I first read: http://www.digitalmars.com/d/2.0/templates-revisited.html

> One of the best parts of the D language design is that it's lexically unambiguous, so tokenization, syntactic analysis, and semantic analysis can be completely separate from one another.
>
> --benji