Template instantiation syntax

[Nick Sabalausky]

"Dave" <Dave_member at pathlink.com> wrote in message 
news:gcr2jc$1pn4$1 at digitalmars.com...
> "Nick Sabalausky" <a at a.a> wrote in message 
> news:gcqvfr$1k6i$1 at digitalmars.com...
>> "Dave" <Dave_member at pathlink.com> wrote in message 
>> news:gcqrbr$1cg4$1 at digitalmars.com...
>>> "KennyTM~" <kennytm at gmail.com> wrote in message 
>>> news:gcqnqd$161r$1 at 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.
>

One of the motivations cited for easy parsing was pointing at C++ (and its 
template syntax in particular) as an example of a grammar being so complex 
that only major compiler vendors could realistically attempt a complete 
implementation, and even they had a rediculously hard time actually getting 
it implemented right.

Point being, there are ways in which easy parsing does translate into a win 
for the average coder (better quality compilers in a shorter time, room for 
more compiler competition). But of course you're right that designing for 
easy parsing shouldn't be taken too far (or else we'd all be flipping 
switches Altair-style).