www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Correct forum for discussing documentation issues?

reply "Andre Artus" <andre.artus gmail.com> writes:
What would be the correct forum to discuss a possible correction 
to the D Language specification?

I started a thread on the Learn forum asking a question regarding 
'import', it soon became apparent to me that there may be an 
error in the specification. What is the correct forum in which to 
discuss this?

For context here is the link to the aforementioned thread:

http://forum.dlang.org/post/azkqhenyzvwbbqsihvbh forum.dlang.org
Aug 03 2013
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 3 August 2013 at 10:26:53 UTC, Andre Artus wrote:
 What would be the correct forum to discuss a possible 
 correction to the D Language specification?
Do you want to discuss it, or just report it? If it looks like an error, then just report the issue to the D bug database: http://d.puremagic.com/issues/enter_bug.cgi?product=D (select the "websites" component) If you're not sure if it's an error, then you could discuss it in this forum, although it might be better just to report the bug anyway. If it's not an error then someone will just close it, hopefully explaining why it's not an error :-)
Aug 03 2013
parent reply "Andre Artus" <andre.artus gmail.com> writes:
On Saturday, 3 August 2013 at 10:31:47 UTC, Peter Alexander wrote:
 On Saturday, 3 August 2013 at 10:26:53 UTC, Andre Artus wrote:
 What would be the correct forum to discuss a possible 
 correction to the D Language specification?
Do you want to discuss it, or just report it? If it looks like an error, then just report the issue to the D bug database: http://d.puremagic.com/issues/enter_bug.cgi?product=D (select the "websites" component) If you're not sure if it's an error, then you could discuss it in this forum, although it might be better just to report the bug anyway. If it's not an error then someone will just close it, hopefully explaining why it's not an error :-)
It looks like a error to me, which may not be saying a whole lot. The "static import ImportList ;" production given in 'ImportDeclaration'[http://dlang.org/module.html#ImportDeclaration] seems redundant because it is already covered by 'AttributeSpecifier'[http://dlang.org/attribute.html#AttributeSpecifier]. I don't know whether this is: - an artefact of a previous incarnation of the language spec, - a conscious decision to redundantly document the attribute specifiers on 'import', - or that being awake for more than 24 hours is not a good time to be reading language specs. ImportDeclaration: import ImportList ; static import ImportList ; //** seems redundant Already specified in AttributeSpecifier: Attribute : Attribute DeclarationBlock Attribute: // ... ProtectionAttribute **static** // ... I'm not sure that I am explaining this properly as it seems that at least 2 different people were under the impression I was making a point quite different from the one I was trying to make. But, if you follow the grammar as it's currently written then the following should be valid D (assuming the parser correctly deals with the conflicting 'static' terminals): static { // 'static' from AttributeSpecifier static import teleport; // 'static' from ImportDeclaration } --AND-- static: // 'static' from AttributeSpecifier static import teleport; // 'static' from ImportDeclaration You could still parse the above after removing the 'static import ImportList ;' production from ImportDeclaration: it would just unambiguously go through AttributeSpecifier.
Aug 03 2013
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 3 August 2013 at 11:22:42 UTC, Andre Artus wrote:
 I'm not sure that I am explaining this properly as it seems 
 that at least 2 different people were under the impression I 
 was making a point quite different from the one I was trying to 
 make.
I understand. It seems that there are two "ways" that a static import declaration can be produced in the grammar. I'm not sure if it counts as a bug, or just a redundant production (but then, where are the redundant productions for "public import" etc.?) I'm not an expert on formal grammar specifications, so I don't know if redundant productions are okay or not. I'm also never sure where you draw the line between parsing and semantic analysis (the grammar allows "override import", is that okay?). I'm guessing you would formally say that the grammar is ambiguous at the production level, but non-ambiguous after semantic analysis. So, I think you're right, but I don't know if it's a bug or not.
Aug 03 2013
parent "Andre Artus" <andre.artus gmail.com> writes:
On Saturday, 3 August 2013 at 12:22:48 UTC, Peter Alexander wrote:
 On Saturday, 3 August 2013 at 11:22:42 UTC, Andre Artus wrote:
 I'm not sure that I am explaining this properly as it seems 
 that at least 2 different people were under the impression I 
 was making a point quite different from the one I was trying 
 to make.
I understand. It seems that there are two "ways" that a static import declaration can be produced in the grammar. I'm not sure if it counts as a bug, or just a redundant production (but then, where are the redundant productions for "public import" etc.?) I'm not an expert on formal grammar specifications, so I don't know if redundant productions are okay or not. I'm also never sure where you draw the line between parsing and semantic analysis (the grammar allows "override import", is that okay?). I'm guessing you would formally say that the grammar is ambiguous at the production level, but non-ambiguous after semantic analysis. So, I think you're right, but I don't know if it's a bug or not.
I poked around in the DMD parser's source (parse.{c|h}) which doesn't seem too difficult to follow (I take it it's handwritten, not generated). But until I step through it with a debugger or create a trace log I'm not going to be confident. As I read it the parser implements "static import" as shown in the spec (which is easier with a handwritten parser). It's not a huge problem; just that people trying to write an input file for a parser generator may run into issues around disambiguation which could be confusing if they don't understand what is going on: the repetition (in the spec) is [I believe] a reflection of an implementation detail, probably to speed up the common path. I did a search for D grammars online before ultimately embarking on my own as I could not find one that could parse any non-trivial D source. And I am yet to find one that parses the imports in all it's possible manifestations.
Aug 03 2013