October 11, 2008
"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
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
"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
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
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
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
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
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
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
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.