Constants for tree node names

[philippesigaud]

Constants for tree node names

[PhilippeSigaud]

Do you mean 'enum', opposed to a simple string?

Because the parse node already have a 'name' field holding the name used in the grammar. When parsing at CT, the name is a CT value, which I use to generate code. At RT, it's obviously a RT value.

[alexrp]

Hm, name was probably a bad idea. Let's call it nodeName or so...

The thing is this: Suppose I have a parse tree node node. I now want to figure out what it is:

switch (node.name)
{
    case "Foo":
        // ...
    case "Bar":
        // ...
}

The problem here is that using plain strings leads to maintenance horror. If you later on refactor the grammar such that the names of nodes change, the above code will silently break. So, if I were able to do:

switch (node.name)
{
    case Foo.nodeName:
        // ...
    case Bar.nodeName:
        // ...
}

I would now get a compile-time error if these nodes have changed their name.

Does that make sense?

[PhilippeSigaud]

Yes, that makes perfect sense. A name at parser level, not at node level, OK.

And it goes in the right direction for error messages too: I want to easily get the name of the failed rule.

Hmm, I can do that. I could also create an enum storing the names used in a grammar, so as to allow using static switch. I'd have to read static switch again, but that seems a good bet.

[alexrp]

Yeah, an enum would probably not be a bad idea either. Full coverage ensured by the compiler is always a good thing. You're probably referring to final switch though?

[PhilippeSigaud]

Yes, final switch.

enum GrammarNames {FooName, BarName, BazName}

void switcher()
{
    GrammarNames gn = GrammarNames.BazName;

    final switch(gn)
    {
        case GrammarNames.FooName:
            writeln("Foo");
            break;
        case GrammarNames.BarName:
            writeln("Bar");
            break;
        case GrammarNames.BazName:
            writeln("Baz");
            break;
    }
}

[alexrp]

That would be great. But this gives rise to another issue: Should Pegged allow the user to give a prefix that gets prepended to all public symbols?

[PhilippeSigaud]

I intend to make named grammars. Anonymous grammars would get the name of their first rule, since it tends to be the start rule.

Please see [[Four Levels]] on the wiki for what I plan to do.

[alexrp]

I just had a (probably crazy) idea.

Since there is no need for inheritance in the parse tree, would it maybe be possible to generate distinct node types for each rule? Or something like that? Then the type system could be helpful too.

[PhilippeSigaud]

Since there is no need for inheritance in the parse tree, would it maybe be possible to generate distinct node types for each rule? Or something like that? Then the type system could be helpful too.

It'd be possible to generate different types, linked specifically to
the rules (in fact, rules themselves are already different types
linked to the rules).

But, children would be difficult. Let me see, since I played with the
idea at another time (an ancestor of Pegged were everything was a
struct). That means constructing a statically typed tree, and it
wasn't that easy to iterate on it, or to change its structure.

Other parsers do that: sequences naturally become tuples, * and +
gives rise to arrays. It's choices ( / ) that are difficult: they need
to be algebraics.

A <- B C
B <- D / E

gives rise to:

struct A {
    string match;
    Pos begin, end;
    TypeTuple!(B,C) children;
}

struct B {
    string match;
    Pos begin, end;
    Algebraic!(D,E) children;
}

And that's a PITA to deal with it: you need to test every time whether
B's child is a D or an E.
Fact is, D is ill-equipped right now to deal with algebraic datatypes:
no deconstruction trough pattern-matching.

It's a case were I'm not sure the type system is up to it. I'd be glad
to be told otherwise, though.

[alexrp]

If std.variant.Algebraic() is good enough to represent the tree, then you can use a trick I implemented in MCI: https://github.com/lycus/mci/blob/master/src/mci/core/common.d#L92

Usage goes like this: https://github.com/lycus/mci/blob/master/src/mci/optimizer/ssa/folding.d#L48

[PhilippeSigaud]

On Tue, Mar 13, 2012 at 23:59, Alex Rønne Petersen
[email protected]
wrote:

If std.variant.Algebraic() is good enough to represent the tree, then you can use a trick I implemented in MCI: https://github.com/lycus/mci/blob/master/src/mci/core/common.d#L92

Usage goes like this: https://github.com/lycus/mci/blob/master/src/mci/optimizer/ssa/folding.d#L48

Ah, you're right. Mice trick, with the => syntax it's quite readable.
I did something like this 1-2 years ago, statically typed:

http://svn.dsource.org/projects/dranges/trunk/dranges/docs/patternmatch.html

I'll look into MCI and (ahem) read my own code on pattern-matching again.

But the main question remains: what would adding static types add? I
mean, it's not as if the parser could construct bad trees.

[Going unlinked for the next 3-4 days right now, don't be surprised if
I don't answer back]

[alexrp]

I can't think of any immediate value, honestly. It was just a thought in case people ended up finding a case where type safety might be a good thing to have.

[PhilippeSigaud]

Hey, I just thought about this:

struct Node(string RuleName)
{ ... }

That way, Node!"Expr" and Node!"Decl" are different types. No need to generate truly different types and people can easily extend the types.

[alexrp]

Sounds good to me, as long as I get an error when the rule name is invalid.

[PhilippeSigaud]

For now, each parser (not parse tree node) has a .name field, a string holding it's name. A Lit!("abc") has for name "Lit!(abc)" and so on.

It's not perfect though, as sequences and choices only give a partial view on their children, to avoid infinite loop in recursive rules names. I'll look for a way to give names only 1-level deep.