Walter Bright wrote:
> Bill Baxter wrote:
>> But it's not the << and >> that make C++ templates hard to understand.
> 
> I think it does. I could never get past the visual ambiguity with less than, and with the streams, the ambiguity with >>. But that isn't the worst of it, the C++ template definition syntax sets my teeth on edge.
> 

I think C++'s template is hard to use because they don't have static if <g>

>>  Replacing that with some other character or character sequence would
>> make very little difference in how difficult they are to understand.
>> It's more the lack of a straighforward equivalent for things like
>> static if.
> 
> There are a lot of issues that needed improvement.
> 
>> Changing details like the character used for this or that can make the
>> code more or less readable though.  But that doesn't really affect how
>> difficult it is to remember how to write something.
> 
> I disagree with that assessment. There are aesthetics to architecture, fonts, web pages, cars, dance, clothes, etc. Break those aesthetics, and you've got something people just don't like, even if they cannot identify why.
> 
> Take the immutable vs invariant aesthetic. There is no technical reason to prefer one over the other. But people seem to just like immutable better.

Walter Bright wrote:
> 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.)
> 

But will be compiler accept T«x» if I directly feed it into the compiler? It's no good if what you see cannot be what you type.

(« and » can be supported with a simple replacement rule “« ↦ !(” and “» ↦ )” if they appear outside a string.)

> 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.

Nice.

Max Samukha wrote:
> On Sat, 11 Oct 2008 02:57:29 -0700, Walter Bright
> <newshound1@digitalmars.com> wrote:
> 
>> Bill Baxter wrote:
>>> But it's not the << and >> that make C++ templates hard to understand.
>> I think it does. I could never get past the visual ambiguity with less than, and with the streams, the ambiguity with >>. But that isn't the worst of it, the C++ template definition syntax sets my teeth on edge.
>>
>>>  Replacing that with some other character or character sequence would
>>> make very little difference in how difficult they are to understand.
>>> It's more the lack of a straighforward equivalent for things like
>>> static if.
>> There are a lot of issues that needed improvement.
>>
>>> Changing details like the character used for this or that can make the
>>> code more or less readable though.  But that doesn't really affect how
>>> difficult it is to remember how to write something.
>> I disagree with that assessment. There are aesthetics to architecture, fonts, web pages, cars, dance, clothes, etc. Break those aesthetics, and you've got something people just don't like, even if they cannot identify why.
>>
>> Take the immutable vs invariant aesthetic. There is no technical reason to prefer one over the other. But people seem to just like immutable better.
> 
> Wait a sec! Not everybody expressed his aesthetic feeling towards
> immutable. I don't like the double m inside immutable and prefer
> invariant :).

To put more flame in... I like the C# keywords “readonly” (meaning const now) and “const” (meaning invariant now) more. :p

On Sat, Oct 11, 2008 at 6:57 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> But it's not the << and >> that make C++ templates hard to understand.
>
> I think it does. I could never get past the visual ambiguity with less than, and with the streams, the ambiguity with >>. But that isn't the worst of it, the C++ template definition syntax sets my teeth on edge.
>
>>  Replacing that with some other character or character sequence would
>> make very little difference in how difficult they are to understand.
>> It's more the lack of a straighforward equivalent for things like
>> static if.
>
> There are a lot of issues that needed improvement.
>
>> Changing details like the character used for this or that can make the code more or less readable though.  But that doesn't really affect how difficult it is to remember how to write something.
>
> I disagree with that assessment. There are aesthetics to architecture, fonts, web pages, cars, dance, clothes, etc. Break those aesthetics, and you've got something people just don't like, even if they cannot identify why.

Ok, I don't disagree with that, but you're changing your argument. Before you said << and >> prevented you from remembering how to do things with C++ templates.  Not liking the looks of the result or finding it hard to read can be a turn-off, sure, but I don't think << and >> are what make it hard to remember how to fake a static if with C++.  That's all I was objecting to.

>
> Take the immutable vs invariant aesthetic. There is no technical reason to prefer one over the other. But people seem to just like immutable better.
>

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.

--bb

Fri, 10 Oct 2008 23:22:22 -0700,
Walter Bright wrote:
> 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.

Ok, then I think it's a matter of specifying precedence.  So that a!b!c is always a!(b!(c)) but if you want to use a!b as an alias to another one-argument template then you must write a!(b)!c.  It seems like a rare use case so it's Ok to require a bit more typing.

Jason House wrote:
> Walter Bright Wrote:
> 
>> 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.
> 
> Couple of comments/questions
> 
> The tool!lathe syntax doesn't look visually distinct enough for me. The @ syntax seems nicer on the eyes. I'm not trying to push changes. @() looks ugly to me, and having matching template syntax is desirable.
> 
> Is it ok to chain!nested!templates?  Gramatically, it's unambiguous.

One!Two!Three -- is this One!(Two!(Three)) or One!(Two)!(Three)?

You can disambiguate using the context, at least sometimes, but that adds complexity to the grammar.

struct Thing (T)
{
	static int opCall (U)() {}
}

template One (T)
{
	alias Thing!(T) One;
}

One!Thing!int thing; // variable declaration, Thing!(Thing!(int))

struct Thing (T)
{
	static int opCall (U)() {}
}

template One (T)
{
	alias Thing!(char) One;
}

int i = One!Thing!int(); // Thing!(Thing!(char))!(int).opCall

"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 '>>'.

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.
b) Easier and more natural for D newbies who've used C++ templates and/or C# / Java Generics.
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.
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>;
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>

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

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.

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.

> 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.

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

I agree.

> 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;

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.)

> 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
> 

"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>

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.

>> 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
>> 

"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 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.

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

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...

- Dave