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.

Never mind, found it. I searched for parameters and found it in http://dlang.org/declaration.html#DeclaratorSuffix
Thanks. :3

On Wednesday, December 25, 2013,  <&quot;Casper Færgemand\&quot; & lt;shorttail@hotmail.com&gt;&quot;@puremagic.com> wrote:
> Never mind, found it. I searched for parameters and found it in
http://dlang.org/declaration.html#DeclaratorSuffix
> Thanks. :3

I had a lot of problems with function declarations when testing the example D grammar.  If you find any mistake in the provided D grammar, could you push it as an issue in Pegged?

On Wednesday, 25 December 2013 at 08:34:27 UTC, Philippe Sigaud wrote:
> On Wednesday, December 25, 2013,  <&quot;Casper Færgemand\&quot; &
> lt;shorttail@hotmail.com&gt;&quot;@puremagic.com> wrote:
>> Never mind, found it. I searched for parameters and found it in
> http://dlang.org/declaration.html#DeclaratorSuffix
>> Thanks. :3
>
> I had a lot of problems with function declarations when testing the example
> D grammar.  If you find any mistake in the provided D grammar, could you
> push it as an issue in Pegged?

Yes, certainly.

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.

On Wed, Dec 25, 2013 at 4:57 PM,  <"Casper Færgemand\" <shorttail@hotmail.com>"@puremagic.com> wrote:
> 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.

On 12/25/2013 04:57 PM, "Casper Færgemand" <shorttail@hotmail.com>" wrote:
>  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.

The following is a parse tree for char* format:

          Parameter
         /    |    \
        /     |     \
       /      |      \
      /   BasicType   \
 InOut_opt    |        \
          BasicTypeX   Declarator
              |       /   |      \
            'char'   / Identifier \
                    /     |       DeclaratorSuffixes_opt
                   /   'format'
                  /
           BasicType2Opt
                /
          BasicType2
              /
            '*'

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.

On Wednesday, 25 December 2013 at 21:23:23 UTC, Philippe Sigaud wrote:
> 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.

On Thu, Dec 26, 2013 at 1:16 AM,  <"Casper Færgemand\" <shorttail@hotmail.com>"@puremagic.com> wrote:
> On Wednesday, 25 December 2013 at 21:23:23 UTC, Philippe Sigaud wrote:
>>
>> 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.