http://www.digitalmars.com/d/2.0/declaration.html

So, cut down:

Decl
    BasicType Declarators ;

BasicType
    int
    ...

BasicType2
    *
    [] and co
    function Parameters

Parameter
    Declarator
    ...

Declarator
    BasicType2 Identifier DeclaratorSuffixes (the suffixes are [] [assignexpr] [type] and a template parameter list)


So given all that, I can't see how this:

int function(int, int) a;

can be parsed with that grammar.

Additionally, Declarator requires identifier, so wouldn't that make this:

int function(* a, [] b) c;

a valid Decl according to that grammar. I think this is seriously incorrect, but I would be open to correction! :D

Yeah, it's wrong. (close reads of parse.c are much more useful than reading the spec. heh.) A peek in my grammar and...

Parameter:
   ...
   BasicType Declarator
   BasicType Declarator = AssignExpression
   BasicType Declarator ...
   Type
   Type ...

I probably should have filed bug reports back when I was going through the grammar. Oh well.

On 08/06/10 16:00, Ellery Newcomer wrote:
>
>
> Yeah, it's wrong. (close reads of parse.c are much more useful than
> reading the spec. heh.) A peek in my grammar and...
>
> Parameter:
> ...
> BasicType Declarator
> BasicType Declarator = AssignExpression
> BasicType Declarator ...
> Type
> Type ...
>
> I probably should have filed bug reports back when I was going through
> the grammar. Oh well.

Hmm. On the same page, Declarator has an identifier in it. Which means I still couldn't parse

int function(int, int)

with it, no?

On 06/07/2010 11:06 PM, Bernard Helyer wrote:
> On 08/06/10 16:00, Ellery Newcomer wrote:
>>
>>
>> Yeah, it's wrong. (close reads of parse.c are much more useful than
>> reading the spec. heh.) A peek in my grammar and...
>>
>> Parameter:
>> ...
>> BasicType Declarator
>> BasicType Declarator = AssignExpression
>> BasicType Declarator ...
>> Type
>> Type ...
>>
>> I probably should have filed bug reports back when I was going through
>> the grammar. Oh well.
>
> Hmm. On the same page, Declarator has an identifier in it. Which means I
> still couldn't parse
>
> int function(int, int)
>
> with it, no?

Eh?

Parameter |= Type |= BasicType Declarator2 |= int Declarator2 |= int

wait, are you talking about the params inside the function type, or the whole thing as a param? I'm pretty sure it works either way.

On 08/06/10 17:19, Ellery Newcomer wrote:
> On 06/07/2010 11:06 PM, Bernard Helyer wrote:
>> On 08/06/10 16:00, Ellery Newcomer wrote:
>>>
>>>
>>> Yeah, it's wrong. (close reads of parse.c are much more useful than
>>> reading the spec. heh.) A peek in my grammar and...
>>>
>>> Parameter:
>>> ...
>>> BasicType Declarator
>>> BasicType Declarator = AssignExpression
>>> BasicType Declarator ...
>>> Type
>>> Type ...
>>>
>>> I probably should have filed bug reports back when I was going through
>>> the grammar. Oh well.
>>
>> Hmm. On the same page, Declarator has an identifier in it. Which means I
>> still couldn't parse
>>
>> int function(int, int)
>>
>> with it, no?
>
> Eh?
>
> Parameter |= Type |= BasicType Declarator2 |= int Declarator2 |= int
>
> wait, are you talking about the params inside the function type, or the
> whole thing as a param? I'm pretty sure it works either way.

Parameter doesn't resolve to Type, not that I can see...

On 06/08/2010 12:30 AM, Bernard Helyer wrote:
> On 08/06/10 17:19, Ellery Newcomer wrote:
>> On 06/07/2010 11:06 PM, Bernard Helyer wrote:
>>> On 08/06/10 16:00, Ellery Newcomer wrote:
>>>>
>>>>
>>>> Yeah, it's wrong. (close reads of parse.c are much more useful than
>>>> reading the spec. heh.) A peek in my grammar and...
>>>>
>>>> Parameter:
>>>> ...
>>>> BasicType Declarator
>>>> BasicType Declarator = AssignExpression
>>>> BasicType Declarator ...
>>>> Type
>>>> Type ...
>>>>
>>>> I probably should have filed bug reports back when I was going through
>>>> the grammar. Oh well.
>>>
>>> Hmm. On the same page, Declarator has an identifier in it. Which means I
>>> still couldn't parse
>>>
>>> int function(int, int)
>>>
>>> with it, no?
>>
>> Eh?
>>
>> Parameter |= Type |= BasicType Declarator2 |= int Declarator2 |= int
>>
>> wait, are you talking about the params inside the function type, or the
>> whole thing as a param? I'm pretty sure it works either way.
>
> Parameter doesn't resolve to Type, not that I can see...

According to whom?

Right now we have two semi-official definitions of the D grammar; the docs (that are wrong) and the parser source (that is effectively unreadable by most people). I would like to propose a solution to this problem: eliminate one of them and derive it from the other.

I know this will be hard to do but it can be done incrementally with each step making improvements over the last.

The first thing to do is put all of the description of the grammar in the docs into one place. If the literal text of each production is replace with a macro reference then the definitions of these macros can be put into a single file and expanded everywhere.
The incremental improvement here is that having the grammar in one place by it's self will make it easier to check.

From here there are several things that can be done:

- copy the grammar rule macros into the parser source where they will stay more up to date.
- write a tool to generate the rules from the parser source.
- write a tool to generate the parser source from the rules.

I'd be willing to do that first step if I got any (semi)official indication that it would be used.

-- 
... <IXOYE><

On Sun, 13 Jun 2010 20:15:46 +0000, BCS wrote:

> The first thing to do is put all of the description of the grammar in the docs into one place.

If we are at it, it would be good to enhance visual representation of docs by generate syntax diagram, similarly as on http://www.json.org/ it not only helps to learn and understand grammar, but also lowers the barrier to just looking at it. When I first saw this kind of diagrams on JSON site, it made good impression on me.

Tool used for this is. http://dotnet.jku.at/applications/Visualizer/

Another important point is - having it visually really help find and enhance specs.

This tools accepts EBNF syntax that is specified on the page. D syntax is specified in BNF, and uses different syntax, but (E)BNF is so simple, it should be possible to adjust different syntaxes just using regex (I think/ hope).

If there is interest in such diagrams, and there is one file syntax file, I would be willing to make changes to this tool (C#) to be able to batch- generate these images. (It would be also a good idea to look at first if BNF diagrams look good, and if EBNF isn't necessary.)

Hello Michal,

> On Sun, 13 Jun 2010 20:15:46 +0000, BCS wrote:
> 
>> The first thing to do is put all of the description of the grammar in
>> the docs into one place.
>> 
> If we are at it, it would be good to enhance visual representation of
> docs by generate syntax diagram, similarly as on http://www.json.org/
> it not only helps to learn and understand grammar, but also lowers the
> barrier to just looking at it. When I first saw this kind of diagrams
> on JSON site, it made good impression on me.
> 
[...]

Nice idea. (But I'd put them in a different set of cross linked pages.)

> If there is interest in such diagrams, and there is one file syntax
> file, I would be willing to make changes to this tool (C#) to be able
> to batch- generate these images. (It would be also a good idea to look
> at first if BNF diagrams look good, and if EBNF isn't necessary.)

You might not need to change the tool. If the grammar macros are done with some thought, you might be able to make them render it to whatever that tool already take as input.

> 
-- 
... <IXOYE><

Hello BCS,

> I'd be willing to do that first step if I got any (semi)official
> indication that it would be used.

does anyone know where the SVN repo with the source for the docs is?

-- 
... <IXOYE><