View mode: basic / threaded / horizontal-split · Log in · Help
October 11, 2008
Re: Template instantiation syntax
"Dave" <Dave_member@pathlink.com> wrote in message 
news:gcr2jc$1pn4$1@digitalmars.com...
> "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.
>

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).
October 11, 2008
Re: Template instantiation syntax
Dave wrote:
> Still there may be an issue with a<b,c>d, but again that is apparently 
> solved in C#, Java  and C++0x,

In C++, this is resolved by looking 'a' up in the symbol table to see if 
it is a template or not. This means it is impossible to parse C++ 
without doing semantic analysis. Such means it is impossible to write 
*correct* C++ tools that analyze syntax, such as color syntax 
highlighting, without writing most of a full compiler.

(In cases, such as template bodies, where the compiler cannot do 
semantic analysis for parsing, the language requires the 'template' 
keyword be inserted before the 'a'..)

There are a lot of hackish ways to parse C++ 95% correctly, and these 
are often used in editors. But none of them do it 100% unless they are 
backed by a full C++ compiler.

C++ pays a high price for the < >, and still fails to get the job done 
correctly.

I don't know specifically how Java and C# do it, but their generics are 
not true templates, they are only types, and so can only appear in very 
restricted circumstances.
October 11, 2008
Re: Template instantiation syntax
"Walter Bright" <newshound1@digitalmars.com> wrote in message 
news:gcr67e$20a4$1@digitalmars.com...
> Dave wrote:
>> Still there may be an issue with a<b,c>d, but again that is apparently 
>> solved in C#, Java  and C++0x,
>
> In C++, this is resolved by looking 'a' up in the symbol table to see if 
> it is a template or not. This means it is impossible to parse C++ without 
> doing semantic analysis. Such means it is impossible to write *correct* 
> C++ tools that analyze syntax, such as color syntax highlighting, without 
> writing most of a full compiler.
>
> (In cases, such as template bodies, where the compiler cannot do semantic 
> analysis for parsing, the language requires the 'template' keyword be 
> inserted before the 'a'..)
>
> There are a lot of hackish ways to parse C++ 95% correctly, and these are 
> often used in editors. But none of them do it 100% unless they are backed 
> by a full C++ compiler.
>
> C++ pays a high price for the < >, and still fails to get the job done 
> correctly.
>
> I don't know specifically how Java and C# do it, but their generics are 
> not true templates, they are only types, and so can only appear in very 
> restricted circumstances.

*Extremely* restricted in the case of C# (*cough* No IArithmetic or operator 
constraints *cough*). Although that is really a separate issue... Sorry, pet 
peeve. ;)
October 11, 2008
Re: Template instantiation syntax
Nick Sabalausky wrote:
> 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). 

Easy parsing doesn't always just mean "easier to implement". Other 
advantages of a context-free grammar are faster IDEs/smart editors tools 
(since they don't need to keep symbol caches while parsing) and faster 
compile times. I think a context-free grammar is a big win all-around.
October 11, 2008
Re: Template instantiation syntax
Robert Fraser:
> I think a context-free grammar is a big win all-around.

Such things have some disadvantages too, like not allowing (?) a syntax like, for example:
foreach (i, x in something) {...}

Instead of the current more error-prone:
foreach (i, x; something) {...}

Bye,
bearophile
October 11, 2008
Re: Template instantiation syntax
bearophile wrote:
> Robert Fraser:
>> I think a context-free grammar is a big win all-around.
> 
> Such things have some disadvantages too, like not allowing (?) a syntax like, for example:
> foreach (i, x in something) {...}
> 
> Instead of the current more error-prone:
> foreach (i, x; something) {...}

Both can be done with a CFG.

Andrei
October 11, 2008
Re: Template instantiation syntax
Andrei Alexandrescu:
> bearophile wrote:
> > foreach (i, x in something) {...}
> > Instead of the current more error-prone:
> > foreach (i, x; something) {...}
> 
> Both can be done with a CFG.

Recently I have explained here why the syntax (i, x; something) is error prone, and other people have told me that they agree that sometimes that syntax leads to bugs like (i, x, something) (and the error message isn't much clear).

I have received an answer, maybe from Walter, that syntax (i, x in something) can't be accepted because "in" is already taken to tell the key presence inside an associative array (while not being yet usable to scan for presence of items into a normal array), so it "can't" be used inside the foreach syntax too...

So probably it's not a problem of grammar, but of successive stages of the compilation. The net result for the programmer is the same, this time the D compiler is rigid and doesn't allow for a more readable/less error-prone syntax.

Bye,
bearophile
October 11, 2008
Re: Template instantiation syntax
It's more appropriate to commend you for this initiative. Maybe some better 
syntax will come out of it and until then it will make the code easier on 
your eyes (and who knows how many others). The opposition smacks more of 
"syntactic conservatism" than anything else. . - Hm, what other interesting 
kinds of syntactic transformation might one do. - More use of unicode 
symbols for one thing.

In fact the days of "one language one syntax" is about to come to an end it 
would appear. This is witnessed by the massive hype surrounding 
domain-specific languages atm - perhaps spun off by Intentional Programming 
where demonstrations show radically different presentations for the same 
underlying abstract syntax.

In the XML world we see binary XML Information Set (Infoset) formalisations 
where the abstract syntax remains more or less invariant but the 
serialization syntax changes drastically. The added bonus here being, 
amongst others, that no human will be able to write this syntax by hand, 
meaning instantiations will be machine-verified - no human err, except those 
programmed into the editors, object models and serializers. Of course 
oppinions on the pros and cons of this vary much.

- Bent

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> skrev i meddelelsen 
news:gcr17d$1n25$1@digitalmars.com...
> Dave wrote:
[...]
>> 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 12, 2008
Re: Template instantiation syntax
Bent Rasmussen:
>More use of unicode symbols for one thing.<

That's a very large jump for D, and I don't know if it will ever do it. But some languages have already done such scary jump, look at Fortress. Fortress code can be written both in unicode and ASCII, the ASCII code looks longer:

http://en.wikipedia.org/wiki/Fortress_(programming_language)
http://research.sun.com/projects/plrg/PLDITutorialSlides9Jun2006.pdf

I am sure D may learn some things from Fortress, but I think adding just one or two unicode symbols to D isn't good. If you want to accept unicode, then you want more. 

Bye,
bearophile
October 12, 2008
Re: Template instantiation syntax
On Sun, Oct 12, 2008 at 12:44 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> Robert Fraser:
>> I think a context-free grammar is a big win all-around.
>
> Such things have some disadvantages too, like not allowing (?) a syntax like, for example:
> foreach (i, x in something) {...}
>
> Instead of the current more error-prone:
> foreach (i, x; something) {...}

It's not "error-prone", it's "you're not used to it."  You very
commonly fall into the fallacy that if you think something's
bad/confusing/not what you're used to, then _everyone_ must think that
way and therefore it _must_ change.  Sorry, that's not the way it
works.  I haven't mistyped a foreach loop, ever.  Deal with it.
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home