Procedural Constraints and Goals MVP Proposal

[JoelCourtney]

Elevator Pitch

Goals and constraints essentially just implement a very basic interface, either SimulationResults -> List<Violation> for constraints or SimulationResults -> List<Conflict> for goals. The current eDSLs restrict these implementations to only use a small set of predefined operations. We try to make the operations general and robust, but so far they have not been satisfactory, and there’s not much reason to suspect that any specific set of operations would be “enough” (short of Turing completeness). Rather than maintain an endlessly growing list of operations, each one of which is surprisingly expensive for us to implement, we ought to have a system where the author can implement the interface with any algorithm - it might be daunting to learn, but that’s better than waiting for us to implement and release an operation that would otherwise be trivial if they could just write the code themselves.

MVP checklist

• Provide one library to constraint / goal authors (a single library for both uses):
  • Profiles: discrete, real, boolean
  • Windows: if we have the opportunity to do it over, I’d separate Windows from boolean profiles. Since the refactor to allow gaps, we’ve seen too many cases where gaps shouldn’t have been allowed, and too many ways that the “Windows = Boolean Profile” interpretation has been misleading.
  • Spans: unchanged
  • Violations: why not just use spans? They can already have activity associations.
  • Intervals, Segments, and Durations: the same as we have now, but exposed to the user
  • Conflicts: same as we have now, +/- a bit of name-bikeshedding because I think its a little unclear. (Actions?)
  • Activity Templates / Expressions: would benefit from being simplified and cleaned up, but could be used as-is for MVP.
  • SimulationResults: unchanged
• API endpoint for uploading a jar containing multiple constraints/goals, associated to either model or plan.
• During constraint or goal evaluation, load and scan through the jar for either constraints or goals, use reflection to instantiate them.
• Wrapper classes to convert to the existing system (temporary):
  • Convert procedural constraints to Expression<Violation>
  • Convert procedural goal to the existing Goal type
    • Convert temporalContext to Interval bounds: there is no applyWhen in procedure-land, because that configuration is internal to the goal
    • Ignore global scheduling conditions (for now)
    • Ignore partial satisfaction: internal configuration
• For goals, lock them in to either min or max priority (I don’t know which)

Interface design

We would need to provide a library for authors to use, and I expect it could be much smaller than the current packages. We wouldn’t need to provide/maintain an extra API, an AST and parsers, and all the tests that go with them.

Important bit: One of the major motivating factors (from my perspective) is ease of maintenance. When we need to change the procedural constraints/scheduling packages, it’ll be (no exaggeration) an order of magnitude easier than changing the eDSLs. If we try to directly reuse the existing data structures (profiles, windows, conflicts) without immediately deprecating the eDSLs, we will lose the main benefit of this effort. So for that reason I think we should implement a new package that can be changed independently of the eDSLs (which incidentally I’ve already mostly done for constraints, in my old lazy profile PR).

The skeleton of a constraint or goal would be pretty simple:

// constraints

// imports
record MyConstraint implements Constraint {
	@Override
	public List<Spans> evaluate(final SimulationResults simResults) {
		throw Todo();
	}
}

// goals

// imports
record MyGoal implements Goal {
	@Override
	public List<Conflict> evaluate(final SimulationResults simResults) {
		throw Todo();
	}
}

This is an MVP, so there is no evaluation bounds. It is assumed to be the simulation results bounds, but more control could be added in later (i.e. adding a second Interval bounds argument).

Also, the constraint returns Spans, because it’s basically the same data structure. This is a pretty good concrete example of the motivations for the whole idea too: currently if you convert a boolean profile to Spans, the true segments become the spans, which is the opposite of what you’d want for a Constraint. This could be worked around by a .not(), but for example lets assume that didn't exist:

1. It would be trivially easy (five minutes) for us to change the intoSpans method to configure which segments turn into Spans, but doing the same task in the eDSL would take half to all of a day of dedicated work and need to be planned in a sprint.
2. Even if we didn’t have five minutes to spare, users could just do it anyway by building the Spans themselves! They wouldn’t need to wait for us!

Keep in mind that procedural goals and constraints have access to the data they operate on. They don’t need to represent their operations in an AST for later evaluation. So we wouldn’t need to keep control flow operations like ForEachActivity in the interface: Java is the interface, and we wouldn’t use it if it didn’t already have for loops :).

Future Work

Procedural constraints’ ease of use would be pretty much on par with the eDSL out of the box, because the eDSL interface methods typically represent a single operation mirrored exactly from the backend. Procedural goals are a different story. The general algorithm of a goal can be broken down into a few steps though, and we could provide shortcuts for common patterns.

• When do you want activities, and how many?
  • These patterns are what profiles / windows / spans are for, and are already not encapsulated by eDSL goals.
  • The entire purpose of Spans-based scheduling is to enable (in the eDSL) all the expressivity of profiles / windows / spans for this part of the process that we can muster - because procedural scheduling wasn’t on the table. Spans-based scheduling will be an unnecessary and unattractive option to users if procedural scheduling is the alternative. As long as procedural scheduling is on the roadmap - which it ought to be - spans-based scheduling is waste of effort. It is a bodge.
• Which existing activities count toward satisfaction?
  • This is just a filter applied to activities that occur at the desired times. It could be made easier with a set of activity filter presets (i.e. referencing defaults or templates, literal values, or more general predicates applied to specific arguments) that could be chained together in a builder pattern.
• What activities should be created for the rest?
  • Like above, this could be made easier with a set of activity creation presets (i.e. defaults/templates, literals, or more general constructors based on instantiation time for specific arguments) that could be chained together in a builder pattern.
  • Partial satisfaction could be configured at this level, internally by the goal.

But just to reiterate one last time - none of this future work expands the capabilities of procedural goals. All of the above would be possible in the MVP, and future work would only focus on making it simpler.