There is linear overhead when performing a task because the perform-task is polymorphic on the instruction constructor. Every time an instruction is performed it has to ‘try’ all the perform-task strategies which is linear in the worst case. Having transient results will make this a little bit worse. We can make it constant by using YAHM (Yet Another Hash Map) from constructor (name + arity) to perform strategy. All tasks will need to be registered into the hash map when setting up the task engine.

Submitted by Gabriël Konat on 13 July 2013 at 01:39

Another solution might be to pass the name of the perform strategy on task creation. But this would require to get from a string to the strategy to execute. I am not sure if this kind of Stratego reflection is possible in Java. I assume it is not possible in Stratego, why we need to do the task-match trick. Next question would be if the reflection is similar performant as the hash map.

You can actually pass strategies to primitives, so you can pass the perform strategy to new-task. This is similar to my idea, except that you pass the strategy at task creation multiple times, instead of once when setting up the engine. It has the advantage that is more loosely-coupled, since you don’t need to edit the setup when adding a new task kind. If you would combine this with instruction specific strategies for creating a task (e.g. new-resolvedefs, new-proplookup) you also prevent errors of passing the wrong perform strategy.

Example: <new-task(|partition)> Choice(x*) would become new-choice = new-task(perform-choice|partition).

@Guido: the Hybrid Interpreter can call strategies by name. A simple primitive may do in this case if nothing is exposed yet.