www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - BNF questions and comments

reply BCS <ao pathlink.com> writes:
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.
Sep 06 2007
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
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
Sep 07 2007
next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
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.

Sep 07 2007
prev sibling parent BCS <BCS pathlink.com> writes:
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.
Sep 07 2007
prev sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
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.
 
 

Sep 07 2007
next sibling parent reply Matti Niemenmaa <see_signature for.real.address> writes:
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.
Sep 07 2007
next sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
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
Sep 07 2007
parent BCS <BCS pathlink.com> writes:
BLS wrote:
 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

What might be fun would be to have one "standard" version in EBNF and then automagically derive others like pure BNF, right recursive, or whatever.
Sep 07 2007
prev sibling parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
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
Sep 07 2007
next sibling parent Jascha Wetzel <"[firstname]" mainia.de> writes:
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.
Sep 07 2007
prev sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
Jascha, many, many thanks.
Just one question :
What is the meaning of : epsilon ?
Bjoern

Jascha Wetzel schrieb:
 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

Sep 07 2007
parent reply 0ffh <spam frankhirsch.net> writes:
BLS wrote:
 What is the meaning of : epsilon ?

Usually this means nothing, erm, "nothing" in such a context. Something like "a <- b / epsilon" is equivalent to "a <- b?". Regards, Frank
Sep 08 2007
parent Jascha Wetzel <"[firstname]" mainia.de> writes:
0ffh wrote:
 BLS wrote:
 What is the meaning of : epsilon ?

Usually this means nothing, erm, "nothing" in such a context. Something like "a <- b / epsilon" is equivalent to "a <- b?". Regards, Frank

yep, epsilon means, the production rule may produce nothing. in the seatd grammar, in most cases, non-terminals that have an epsilon rule, also have a name with suffix "Opt" for "optional". note that epsilon rules are just a convenient shortcut: EnumDeclaration -> "enum" EnumBaseTypeOpt EnumBody may be rewritten as: EnumDeclaration -> "enum" EnumBaseType EnumBody EnumDeclaration -> "enum" EnumBody
Sep 08 2007
prev sibling parent BCS <BCS pathlink.com> writes:
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.
Sep 07 2007