Thread overview | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
September 07, 2007 BNF questions and comments | ||||
---|---|---|---|---|
| ||||
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. |
September 07, 2007 Re: BNF questions and comments | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | 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 |
September 07, 2007 Re: BNF questions and comments | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kirk McDonald | 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.
>
|
September 07, 2007 Re: BNF questions and comments | ||||
---|---|---|---|---|
| ||||
Posted in reply to BCS | 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.
>
>
|
September 07, 2007 Re: BNF questions and comments | ||||
---|---|---|---|---|
| ||||
Posted in reply to BLS | 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. |
September 07, 2007 Re: BNF questions and comments | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matti Niemenmaa | 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
|
September 07, 2007 Re: BNF questions and comments | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matti Niemenmaa | 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 |
September 07, 2007 Re: BNF questions and comments | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jascha Wetzel | 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.
|
September 07, 2007 Re: BNF questions and comments | ||||
---|---|---|---|---|
| ||||
Posted in reply to BLS | 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. |
September 07, 2007 Re: BNF questions and comments | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kirk McDonald | 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.
|
Copyright © 1999-2021 by the D Language Foundation