under LinkageType what (from a lexical standpoint) are C, C++, D, etc?

===
under  Conditional Compilation:

ConditionalDeclaration:
   Condition : Declarations

Condition:
   StaticIfCondition

StaticIfCondition:
   static if ( AssignExpression )

allowing this:

static if(0==0) : int i;

Is this supposed to work? If so what for?

===
BaseClassList under NewExpression uses a lowercase for the L in list where an upper case is used where it is defined.

===
What about with:

ClassTemplateDeclaration:
   class Identifier ( TemplateParameterList ) [SuperClass {, InterfaceClass }] ClassBody

why isn't BaseClassList used?

this as far as I can tell BaseClassList doesn't require a comma (but dmd doesn't let you drop it) and the above grammar requires a base class before interfaces (and DMD doesn't require this)

===
CatchParameter ExpressionList
FunctionParameterList
ModuleAliasIdentifier
TemplateIdentifier
Tuple
IntegerExpression (in iasm.html)

===
are not defined

ClassTemplateDeclaration
FunctionTemplateDeclaration
ConditionalDeclaration
TemplateMixin
TemplateDeclaration
StaticAssert

are never used

===
LabelledStatement is misspelled in it's definition

===
The format of the bnf section is not consistent. Off hand:
-many productions are missing the :
-in most cases operators are unquote but in a few they are
-opt is used in a few cases but general omitted in favor of other choices
-grouping is used in 1 or 2 cases but again is generally not used.
-in two(?) places the "empty" production is used.

this all comes from extracting the grammar from the docs. I would like to be able to automate this but having these discrepancies requires that I do it by hand.

BCS wrote:
> under LinkageType what (from a lexical standpoint) are C, C++, D, etc?
> 

An identifier, an identifier and the ++ operator, and an identifier, respectively. This implies that "extern(C ++)" is legal. As with many things, the spec simply does not say anything about this.

> ===
> under  Conditional Compilation:
> 
> ConditionalDeclaration:
>    Condition : Declarations
> 
> Condition:
>    StaticIfCondition
> 
> StaticIfCondition:
>    static if ( AssignExpression )
> 
> allowing this:
> 
> static if(0==0) : int i;
> 
> Is this supposed to work? If so what for?
> 

Condition also has the VersionCondition and the DebugCondition in it. It is analogous to saying "private:". The block created in this way holds until the end of the enclosing block.

> ===
> The format of the bnf section is not consistent. Off hand:
> -many productions are missing the :
> -in most cases operators are unquote but in a few they are
> -opt is used in a few cases but general omitted in favor of other choices
> -grouping is used in 1 or 2 cases but again is generally not used.
> -in two(?) places the "empty" production is used.
> 
> this all comes from extracting the grammar from the docs. I would like to be able to automate this but having these discrepancies requires that I do it by hand.
> 

I once wrote a D parser in Python, by hand, using the pyparsing library, so I'm fairly familiar with the spec's grammar's shortcomings. Nevermind about the resulting parser, it was basically useless. But the /process/ of creating the parser was quite informative. Suffice to say that, yes, the spec has quite a lot of holes.

The ultimate guide to the grammar is the DMD front-end source code, parse.h and parse.c. (Not to mention lexer.h and lexer.c.) If you compare the source to the grammar, it is obvious that the grammar was created after the fact. In the cases you've listed -- many of which I also listed on the newsgroup, back when I made my parser -- it is obvious that it was not created with an overly sharp eye to detail. (If you look around for that old thread of mine, I even had lists of what the grammar should look like for the missing cases, and where the unused cases should appear.)

I mentioned this to Walter at one point at the conference. He knew the grammar had issues, but it's simply not a high priority for him. However, I suspect that if someone sent him a diff with the various documentation fixes, that he might use it.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

What you say is very true. That's why I dropped the ANTLR implementation of the parser for Descent and ported DMD's front-end.

Kirk McDonald wrote:
> BCS wrote:
>> under LinkageType what (from a lexical standpoint) are C, C++, D, etc?
>>
> 
> An identifier, an identifier and the ++ operator, and an identifier, respectively. This implies that "extern(C ++)" is legal. As with many things, the spec simply does not say anything about this.
> 
>> ===
>> under  Conditional Compilation:
>>
>> ConditionalDeclaration:
>>    Condition : Declarations
>>
>> Condition:
>>    StaticIfCondition
>>
>> StaticIfCondition:
>>    static if ( AssignExpression )
>>
>> allowing this:
>>
>> static if(0==0) : int i;
>>
>> Is this supposed to work? If so what for?
>>
> 
> Condition also has the VersionCondition and the DebugCondition in it. It is analogous to saying "private:". The block created in this way holds until the end of the enclosing block.
> 
>> ===
>> The format of the bnf section is not consistent. Off hand:
>> -many productions are missing the :
>> -in most cases operators are unquote but in a few they are
>> -opt is used in a few cases but general omitted in favor of other choices
>> -grouping is used in 1 or 2 cases but again is generally not used.
>> -in two(?) places the "empty" production is used.
>>
>> this all comes from extracting the grammar from the docs. I would like to be able to automate this but having these discrepancies requires that I do it by hand.
>>
> 
> I once wrote a D parser in Python, by hand, using the pyparsing library, so I'm fairly familiar with the spec's grammar's shortcomings. Nevermind about the resulting parser, it was basically useless. But the /process/ of creating the parser was quite informative. Suffice to say that, yes, the spec has quite a lot of holes.
> 
> The ultimate guide to the grammar is the DMD front-end source code, parse.h and parse.c. (Not to mention lexer.h and lexer.c.) If you compare the source to the grammar, it is obvious that the grammar was created after the fact. In the cases you've listed -- many of which I also listed on the newsgroup, back when I made my parser -- it is obvious that it was not created with an overly sharp eye to detail. (If you look around for that old thread of mine, I even had lists of what the grammar should look like for the missing cases, and where the unused cases should appear.)
> 
> I mentioned this to Walter at one point at the conference. He knew the grammar had issues, but it's simply not a high priority for him. However, I suspect that if someone sent him a diff with the various documentation fixes, that he might use it.
> 

Yep. Porting Walter's language/grammar description into EBNF is a challenge. You may have recognized that I am working on Netbeans IDE support for D/MiniD... in order to establish code folding I have to create an NBS Schliemann file which is (mostly) similar to EBNF.
Instead of {}  I have to use ()*, in fact a few minor things.
Probabely we can exchange some information ?

Bjoern


BCS schrieb:
> under LinkageType what (from a lexical standpoint) are C, C++, D, etc?
> 
> ===
> under  Conditional Compilation:
> 
> ConditionalDeclaration:
>    Condition : Declarations
> 
> Condition:
>    StaticIfCondition
> 
> StaticIfCondition:
>    static if ( AssignExpression )
> 
> allowing this:
> 
> static if(0==0) : int i;
> 
> Is this supposed to work? If so what for?
> 
> ===
> BaseClassList under NewExpression uses a lowercase for the L in list where an upper case is used where it is defined.
> 
> ===
> What about with:
> 
> ClassTemplateDeclaration:
>    class Identifier ( TemplateParameterList ) [SuperClass {, InterfaceClass }] ClassBody
> 
> why isn't BaseClassList used?
> 
> this as far as I can tell BaseClassList doesn't require a comma (but dmd doesn't let you drop it) and the above grammar requires a base class before interfaces (and DMD doesn't require this)
> 
> ===
> CatchParameter ExpressionList
> FunctionParameterList
> ModuleAliasIdentifier
> TemplateIdentifier
> Tuple
> IntegerExpression (in iasm.html)
> 
> ===
> are not defined
> 
> ClassTemplateDeclaration
> FunctionTemplateDeclaration
> ConditionalDeclaration
> TemplateMixin
> TemplateDeclaration
> StaticAssert
> 
> are never used
> 
> ===
> LabelledStatement is misspelled in it's definition
> 
> ===
> The format of the bnf section is not consistent. Off hand:
> -many productions are missing the :
> -in most cases operators are unquote but in a few they are
> -opt is used in a few cases but general omitted in favor of other choices
> -grouping is used in 1 or 2 cases but again is generally not used.
> -in two(?) places the "empty" production is used.
> 
> this all comes from extracting the grammar from the docs. I would like to be able to automate this but having these discrepancies requires that I do it by hand.
> 
> 

BLS wrote:
> Yep. Porting Walter's language/grammar description into EBNF is a challenge. You may have recognized that I am working on Netbeans IDE support for D/MiniD... in order to establish code folding I have to create an NBS Schliemann file which is (mostly) similar to EBNF. Instead of {}  I have to use ()*, in fact a few minor things. Probabely we can exchange some information ?

A lot of people appear to be working on something which needs to parse D.

It might be an idea to set up a page on Wiki4D called "CorrectCompleteDGrammar" or something, writing a complete EBNF (or using Walter's syntax, which is also fine) for D which is actually correct.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Formerly deewiant.

Matti Niemenmaa schrieb:
> BLS wrote:
>> Yep. Porting Walter's language/grammar description into EBNF is a
>> challenge. You may have recognized that I am working on Netbeans IDE
>> support for D/MiniD... in order to establish code folding I have to
>> create an NBS Schliemann file which is (mostly) similar to EBNF.
>> Instead of {}  I have to use ()*, in fact a few minor things.
>> Probabely we can exchange some information ?
> 
> A lot of people appear to be working on something which needs to parse D.
> 
> It might be an idea to set up a page on Wiki4D called "CorrectCompleteDGrammar"
> or something, writing a complete EBNF (or using Walter's syntax, which is also
> fine) for D which is actually correct.
> 

I like this idea.

// Using this EBNF grammar  ???
S = ModuleDeclaration {Statement} ";" .
ModuleDeclaration = "module" identifier {"." identifier} ";" .
 and so on ...

/* It will make live easier, when we have  a least our "Standard" EBNF defination.
*/
Bjoern

Matti Niemenmaa wrote:
> BLS wrote:
>> Yep. Porting Walter's language/grammar description into EBNF is a
>> challenge. You may have recognized that I am working on Netbeans IDE
>> support for D/MiniD... in order to establish code folding I have to
>> create an NBS Schliemann file which is (mostly) similar to EBNF.
>> Instead of {}  I have to use ()*, in fact a few minor things.
>> Probabely we can exchange some information ?
> 
> A lot of people appear to be working on something which needs to parse D.
> 
> It might be an idea to set up a page on Wiki4D called "CorrectCompleteDGrammar"
> or something, writing a complete EBNF (or using Walter's syntax, which is also
> fine) for D which is actually correct.
> 

i exported the current of the D grammar that i use for SEATD:
http://seatd.mainia.de/grammar.html
http://seatd.mainia.de/grammar.xml

Jascha Wetzel wrote:
> i exported the current of the D grammar that i use for SEATD:

"the current version"

the quoted terminals are regular expressions, hence the backslashes.

BLS wrote:
> Yep. Porting Walter's language/grammar description into EBNF is a challenge. You may have recognized that I am working on Netbeans IDE support for D/MiniD... in order to establish code folding I have to create an NBS Schliemann file which is (mostly) similar to EBNF.
> Instead of {}  I have to use ()*, in fact a few minor things.

Well for the most part Walter used BNF not EBNF which is good considering I can't use (). OTOH it's all left recursive and I can't use that. (More munging me thinks<G>)

> Probabely we can exchange some information ?
> 
> Bjoern
> 
> 

At this point all I have is basically cope/pasted out of the docs. I'll send you the text if you want but I don't think it will be of much use yet.

Kirk McDonald wrote:
>
> I mentioned this to Walter at one point at the conference. He knew the grammar had issues, but it's simply not a high priority for him. However, I suspect that if someone sent him a diff with the various documentation fixes, that he might use it.
> 

Is there an up to date version of the ddoc sources available? It would be better to make patches against that than the html.