John C wrote:
> "Walter Bright" <newshound@digitalmars.com>
>> "John C" <johnch_atms@hotmail.com>
>>> "Sean Kelly" <sean@f4.ca>
>>>> <dihdcb$bb$1@digitaldaemon.com>, Tomás A. Rossi
>>>> 
>>>>> Does anyone like the template syntax Foo!(T) ? I think it's better than C++ angular bracket syntax, but it's still a little ugly.
>>>> 
>>>> Overall, I think it's fairly intuitive in that it mimics function call syntax. And it's better than <>, as nested tempate terminators (ie. >>) cause problems.
>>> 
>>> Surely it's problematic only in terms of parsers being unable to distinquish between the termination of a template definition and
>>> a right-shift operator.
>> 
>> There's also distinguishing between a less than and greater than operator.
>> 
>>> C# and Java both overcame this,
>> 
>> I disagree, since both support only very limited template forms.
>> 
>>> and C++0x will probably remove the requirement for a space between the brackets.
>> 
>> <> will always have parsing problems, and although one might be able to shift around where the seams show, it's still there. For example:
>> 
>> a < b > * p;
>> 
>> Is it: (a<b>) * (p) or: (a < b) > (*p) ?
> 
> But in the templated form, b would have to be a type, not a variable (VC++ doesn't find it ambiguous). I guess this isn't evaluated in the
>  parsing phase, but does everything have to be valid to the parser?
> 
> I'm not dissing D's syntax at all. I just wanted to point out that C++'s syntax isn't evil.
> 
>> !() has no parsing ambiguities.

I think the current syntax is good enougn.

In article <diqgpb$1qje$1@digitaldaemon.com>, John C says...
>
>"Walter Bright" <newshound@digitalmars.com> wrote in message news:dip1m0$i50$2@digitaldaemon.com...
>>
>> <> will always have parsing problems, and although one might be able to shift around where the seams show, it's still there. For example:
>>
>>    a < b > * p;
>>
>> Is it:
>>    (a<b>) * (p)
>> or:
>>    (a < b) > (*p)
>> ?
>
>But in the templated form, b would have to be a type, not a variable (VC++ doesn't find it ambiguous). I guess this isn't evaluated in the parsing phase, but does everything have to be valid to the parser?

A type or an integral constant.  Though a must be a type, so there is that.  But as one of Walter's primary goals for D was to produce a language that's very easy to parse, why introduce syntax that has known ambiguities?

>I'm not dissing D's syntax at all. I just wanted to point out that C++'s syntax isn't evil.

True enough.


Sean

"John C" <johnch_atms@hotmail.com> wrote in message news:diqgpb$1qje$1@digitaldaemon.com...
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:dip1m0$i50$2@digitaldaemon.com...
> > <> will always have parsing problems, and although one might be able to shift around where the seams show, it's still there. For example:
> >
> >    a < b > * p;
> >
> > Is it:
> >    (a<b>) * (p)
> > or:
> >    (a < b) > (*p)
> > ?
>
> But in the templated form, b would have to be a type, not a variable (VC++ doesn't find it ambiguous). I guess this isn't evaluated in the parsing phase, but does everything have to be valid to the parser?

One major goal of D is to be able to parse the code without needing to consult the symbol table. This makes for both a dramatic simplification of the compiler, and it enables easy creation of third party tools that need to be able to parse the code.

Furthermore, b can be a variable in C++ if it is a value parameter.

> I'm not dissing D's syntax at all. I just wanted to point out that C++'s syntax isn't evil.

Evil or not, the parsing problems of C++ templates are one reason why it has taken many years for any conforming C++ compilers to appear, and the general lack of 3rd party tools that can correctly parse C++. These concerns were brought up when <> was selected, and the concerns were dismissed. All the predicted downsides of <> have come to pass.

There is nothing inherently superior to <>, it doesn't even look good - consider an expression using a mix of iostreams, templates, shift operators, and less/greater than. It's unreadable. I can't see a good reason to repeat the mistake.

You´re right about not to make the same mistake. As you said, <> has so much problems and though I like !() better, it´s a shame because it's not a perfect and beautiful syntax either. But I guess it's all about tastes and I understand you had not much of a choice. If there were more symbols we could use to write our programs, that would be bliss.

Regards
Tom

PS: Sorry for my English, I am a Spanish speaker (from Argentina)... though I do
my best :)

In article <dirh1o$2k4d$2@digitaldaemon.com>, Walter Bright says...
>
>
>"John C" <johnch_atms@hotmail.com> wrote in message news:diqgpb$1qje$1@digitaldaemon.com...
>> "Walter Bright" <newshound@digitalmars.com> wrote in message news:dip1m0$i50$2@digitaldaemon.com...
>> > <> will always have parsing problems, and although one might be able to shift around where the seams show, it's still there. For example:
>> >
>> >    a < b > * p;
>> >
>> > Is it:
>> >    (a<b>) * (p)
>> > or:
>> >    (a < b) > (*p)
>> > ?
>>
>> But in the templated form, b would have to be a type, not a variable (VC++ doesn't find it ambiguous). I guess this isn't evaluated in the parsing phase, but does everything have to be valid to the parser?
>
>One major goal of D is to be able to parse the code without needing to consult the symbol table. This makes for both a dramatic simplification of the compiler, and it enables easy creation of third party tools that need to be able to parse the code.
>
>Furthermore, b can be a variable in C++ if it is a value parameter.
>
>> I'm not dissing D's syntax at all. I just wanted to point out that C++'s syntax isn't evil.
>
>Evil or not, the parsing problems of C++ templates are one reason why it has taken many years for any conforming C++ compilers to appear, and the general lack of 3rd party tools that can correctly parse C++. These concerns were brought up when <> was selected, and the concerns were dismissed. All the predicted downsides of <> have come to pass.
>
>There is nothing inherently superior to <>, it doesn't even look good - consider an expression using a mix of iostreams, templates, shift operators, and less/greater than. It's unreadable. I can't see a good reason to repeat the mistake.
>
>

Tomás A. Rossi