View mode: basic / threaded / horizontal-split · Log in · Help
October 11, 2008
Re: Template instantiation syntax
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.
October 11, 2008
Re: Template instantiation syntax
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.
October 11, 2008
Re: Template instantiation syntax
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
October 11, 2008
Re: Template instantiation syntax
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
October 11, 2008
Re: Template instantiation syntax
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.
October 11, 2008
Re: Template instantiation syntax
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
October 11, 2008
Re: Template instantiation syntax
"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
October 11, 2008
Re: Template instantiation syntax
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
>
October 11, 2008
Re: Template instantiation syntax
"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
>>
October 11, 2008
Re: Template instantiation syntax
"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
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home