Origin tracking design questions

[krame505]

Lately I've been looking at the runtime and translation a bit more closely, and I've found that I have questions about a number of design points that didn't get flagged during review (or did get discussed and I can't recall the rationale.) To start:

• Having to use rtConstruct as a wrapper that just calls the constructor kind of annoying, and also pretty confusing for people who are just starting out working on runtime stuff ("wait, why can't a just write new Pnothing()?"). Why not just always generate a constructor that takes an NOriginInfo and calls the regular constructor if the nonterminal isn't tracked? And why don't we generate an rtConstruct method if there are contexts on a production?
• Why is TrackedNode an abstract class and not just an interface Tracked with a getOrigin method?
• feature/inh-types makes new into a foreign function rather than a built-in primitive. This breaks a couple of the origins tests. I don't really understand what is going on here/how this is supposed to work well enough to fix this.

@602p

[602p]

• The rtConstruct helper exists mostly to head off problems caused by Build fails without --clean meta-bug #36 by making trackedness in constructors part of the Java-level type interface, so that mismatching trackedness leads to a compile-time error instead of silent incorrect runtime behavior. We could always generate a constructor taking origins info, and then throw it away and forward to the other if we don't use it, it's a simple change. We talked about this during review and I think the consensus was complexity in the interface was preferable to silent miscompiles (now they are noisy miscompiles...) until we could deal with Build fails without --clean meta-bug #36 . As to contexts, I'm not sure why. We probably should be; I merged OT against typeclasses in a rather mechanical fashion.
• It could be an interface with getOrigin (and some other methods.) It seemed to make more sense as a subclass to me since it is a strict extension of the semantics of Node. We could change this too but I'm not sure why we would unless it's conflicting with some other wish to subclass Node.
• I'll take a look at this and talk it over with you on zoom.

[krame505]

The rtConstruct helper exists mostly to head off problems caused by #36 by making trackedness in constructors part of the Java-level type interface,

Yeah I think I recall that discussion now. However I think I'm willing to accept that if you are experimenting with --no-origins/--force-origins or changing the trackedness of an NT you should always use --clean. And recently I have become increasingly convinced of the need to try and keep the Java translation side of things from becoming too gross.

So I am proposing that we always generate 2 constructors, one with an origin info and one without, where one always calls the other (for tracked NTs, the one without an OI passes null to the one with an OI, and for untracked the one with an OI throws it away and calls the one without an OI.) Then in the runtime we can always call whichever constructor is appropriate.

It could be an interface with getOrigin (and some other methods.) It seemed to make more sense as a subclass to me since it is a strict extension of the semantics of Node. We could change this too but I'm not sure why we would unless it's conflicting with some other wish to subclass Node.

I was originally thinking adding something that subclassed Node but after further consideration I think what I was considering will require generating a new subclass for every new nonterminal class.

But I still think that it should be an interface from a more general design perspective: consider if we added another notion of trackedness with a different sort of origin info, such that a nonterminal can be tracked or untracked, as well as "extratracked" or un-extratracked. Then we have an intersection issue, as we can't be a subclass of two different abstract subclasses of Node. So conceptually I think it makes more sense for trackedness to be an interface as this is an "extra capability" of some Nodes, not a more specific sort of node.

[602p]

Sure, we can make both of these changes. I'm still of the opinion that having a 'contractual' constructor for runtime/foreign code is preferable to have a more stable "ABI", but we can do this if you want. Making Tracked an interface is a good idea I think, it just didn't get brought up during review. It also would enable us to track lists/primitives/foreign types if for some reason we wanted that. This should be a smallish diff (but runtime-changing) and I'll look at doing it soon.

[602p]

For posterity, all the changes discussed here have been made.