direct application of a parser type via a typedef is rejected inside another parser

[apinski-cavium]

I had assumed the following is valid code:

parser p() {
    state start {
        transition accept;
    }
}

typedef p tt;

parser p1() {
    state start {
        //p.apply();
        tt.apply();
        transition accept;
    }
}

as typedef here should just make an alias of the parser type.

[apinski-cavium]

Maybe a related issue is instantiation using a typedef does not work either:

parser p() {
    state start {
        transition accept;
    }
}

typedef p tt;

parser p1() {
    state start {
        tt() y;
        y();
        transition accept;
    }
}

Hmm, are typedef identifiers not being treated as typenames correctly?

[mihaibudiu]

The spec is not very clear, but p is not really a type, it is a parser. The type of a parser is actually given by the "prototype", so the type of p is actually parser p() - without a body. I think that the spec should reject these typedefs because of this reason. We should discuss this in the LDWG.

[apinski-cavium]

So there is no way to have two names for a parser/control then? What about extern?

[mihaibudiu]

No, you can't. It is actually useful because the compiler knows that there is no aliasing: each "object" has a single name at any point during execution, so you cannot modify 'a' if you refer to 'b' (i.e., in an expression that does not have references to 'a'). I did propose elsewhere an 'alias' statement that would introduce a new name for an existing declaration, which would in some sense generalize 'typedef', but I am not sure it's such a great idea.

[apinski-cavium]

The problem I have with parser not being a type but some fuzzy type/decl, is the whole grammer of the language is wrong then. typeName "." APPLY Does not work at all since in my example p wouldn't be a type and then typeName won't match. The same thing is true of instantiations too: typeRef "(" argumentList ")" name ";" ...