Nate Foster
It would not be too hard to extend `p4pp` to handle full-blown macros... I just figured I would add that when appropriate (and maybe also update the spec).
That's a great point.
Just want to chime in to say that all of this is great! Relying on the C preprocessor was a mistake. In the long run, it'd be great to do...
The specification doesn't really commit to what the compiler may or may not do when it comes to inferring type arguments given as `_`. I understand the intuition behind wanting...
By the way, I think `p4c` is wrong to accept the version with the `_` on the `f` method, because it rejects this program. ``` extern E { E(); void...
Just to make sure I understand: the idea is to use `p4testgen` as a _concrete_ interpreter? Then we can run tests natively without having to start up a separate software...
Oh, I see. Yes, a simple, fixed instance of `p4testgen` could make a lot of sense.
Haven't studied the feature carefully, but to avoid backend chaos, can we write a front-or-midend pass that eliminates these local type definitions?
Petr4 accepts this program. I haven't done a formal proof, but I don't believe allowing an extern to take an arguments of its own type is dangerous from a non-termination...
In fact, `p4test` accepts this variant... ``` extern Bar { Bar(); void m2(T x); } control C() { Bar() b; apply { b.m2(b); } } ``` H/T @rcgoodfellow for coming...