Where is the function declaration in the language specification?
I'm trying to parse a simple "void main() {}" with Pegged, but I
can't figure our which declarations contain the function
declaration. I tried with Pegged's example D grammar, but it's
unwilling to parse said program.

From http://dlang.org/declaration.html#Parameter
Parameter:
InOutopt BasicType Declarator
InOutopt BasicType Declarator ...
InOutopt BasicType Declarator = DefaultInitializerExpression
InOutopt Type
InOutopt Type ...
How do I add a declarator to a parameter like "char * format"? I
altered the language specification to add a "InOutopt Type
Declarator", but is there another way? The specification overall
is really good, but I've found a few missing things elsewhere,
and I'm wondering if it really is missing or I'm missing the
point. :P I can't see any way to add a parameter name to
something of type Type.

From http://dlang.org/declaration.html#Parameter
Parameter:
InOutopt BasicType Declarator
InOutopt BasicType Declarator ...
InOutopt BasicType Declarator = DefaultInitializerExpression
InOutopt Type
InOutopt Type ...
How do I add a declarator to a parameter like "char * format"? I altered the
language specification to add a "InOutopt Type Declarator", but is there
another way? The specification overall is really good, but I've found a few
missing things elsewhere, and I'm wondering if it really is missing or I'm
missing the point. :P I can't see any way to add a parameter name to
something of type Type.

I'll consider that as a D grammar question, and not a Pegged-specific
question, since Pegged just uses a copy of the D site grammar :-)
As to this specific question, my answer is halas: I don't know. I find
parts of the D grammar a bit complicated for my taste (with 200
different rules, it's the most complicated programming language
grammar I know of). I'll let some grammar specialist answers there
(there are a few around these parts). I know some people have a
cleaned-up, alternate grammar, but I can't remember the link.

I'll consider that as a D grammar question, and not a
Pegged-specific
question, since Pegged just uses a copy of the D site grammar
:-)

Thank you regardless. I'll be sure to submit some issues once
we're a bit further down the road. Error handling is what has
displeased me the most so far, with only a single test case ever
displaying something useful. I'm not sure what the solution
should be though, perhaps the matches that munched the most
tokens before failing?
Also, it should be possible to detect non-munching cycles aka.
left recursion without too much extra compile time. It's funny
because it's fine on compile time, but instant death at runtime.
I'll post some of that once we're further.
On Wednesday, 25 December 2013 at 22:28:06 UTC, Timon Gehr wrote:

The following is a parse tree for char* format:
snip

Oooh, I missed that. I didn't think it possible one would dissect
it like that. In my mind it would make more sense to keep char
and * together, since it's a type of its own. Interesting. And
weird.

I consider the grammar specification (as well as some details
of what is valid syntax) to be quite inelegant, unnecessarily
repetitive and inconvenient for parser generators, but I am not
sure if a clean-up would be welcome.

I'm not sure. I haven't imported too much yet, but the only thing
I've had to work around was left recursion in some arithmetic
expressions (add and mul I believe). It's complicated for sure,
but the language specification has survived nearly intact. My
only past experience is the toy language Tiger made for education
and stories I've been told of "normal" language specifications
being really awful. So some copy paste is nice for a change.
I'd still like a look at a "clean" grammar if anyone has one
around.

I'll consider that as a D grammar question, and not a Pegged-specific
question, since Pegged just uses a copy of the D site grammar :-)

Thank you regardless. I'll be sure to submit some issues once we're a bit
further down the road. Error handling is what has displeased me the most so
far, with only a single test case ever displaying something useful. I'm not
sure what the solution should be though, perhaps the matches that munched
the most tokens before failing?

Error reporting in parser generator is a bit more difficult than for
hand-made parsers.
And moving around the info necessary to make a good report already
slows the parser by a factor of two.
As for what it the best report, I thought Pegged already provided the
rule that went farther?

Also, it should be possible to detect non-munching cycles aka. left
recursion without too much extra compile time. It's funny because it's fine
on compile time, but instant death at runtime. I'll post some of that once
we're further.

Yeah. I have a branch somewhere where I have many introspection
algorithms implemented (left recursion, rule reachability, null-rule
detection...). My goal is then to run them on request and block the
compilation when something is wrong.
The code is many months old already, I did not have the time to merge
it completely.See:
https://github.com/PhilippeSigaud/Pegged/blob/master/pegged/dev/introspection.d
I'd have to test it anew, with a new DMD.

On Wednesday, 25 December 2013 at 22:28:06 UTC, Timon Gehr wrote:A>

The following is a parse tree for char* format:
snip

Oooh, I missed that. I didn't think it possible one would dissect it like
that. In my mind it would make more sense to keep char and * together, since
it's a type of its own. Interesting. And weird.

Yeah, it took me a long time to understand that (I now remember).
Maybe it's because D evolved from C/C++ and it inherited some strange
quirks. The resulting language is clean enough (char* is a type), but
the grammar is sometimes weird.

From http://dlang.org/declaration.html#Parameter
Parameter:
InOutopt BasicType Declarator
InOutopt BasicType Declarator ...
InOutopt BasicType Declarator = DefaultInitializerExpression
InOutopt Type
InOutopt Type ...
How do I add a declarator to a parameter like "char * format"? I altered
the language specification to add a "InOutopt Type Declarator", but is
there another way? The specification overall is really good, but I've
found a few missing things elsewhere, and I'm wondering if it really is
missing or I'm missing the point. :P I can't see any way to add a
parameter name to something of type Type.