Currently generic programming over the application of dynamic rules is not possible. All application code is generated by the stratego compiler. It would be useful to let the compiler generate code for the evaluation of a dynamic rule.

Sorry, dutch:

bravo Misschien is het aardig om een generieke ‘apply-…’ te maken voor een dynamische regel. Zodat als je via de API een rule opvraagt, je hem ook kan toepassen.
bravo Je kan dan generieke operaties gaan implementeren op dynamische regels
EyE met opvragen bedoel je de get-rule-pointer?
bravo ik denk het ja, ik weet niet precies wat die strategien opleveren (type aanduidingen zouden wel nuttig zijn in de API)
bravo ik bedoel de aanduiding van 1 gedefinieerde dynamische regel in ieder geval
EyE nou die lookup returnt een tuple (closures,key,tbl)
EyE misschien bedoel jij dan de idtag van een rule?
EyE en die is ook niet meer helemaal uniek… (vroeger wel, dat eerste element in de Defined(“h_0”, bnd1, bnd2, ..)
bravo ik heb geen idee wat ik bedoel, maar dit kan nooit lastig zijn in ieder geval ;) . Desnoods met support in de lifter.
bravo waarom ik dat toepassen noem: je kan nu namelijk wel generiek programmeren over dynamische regels, maar niet over de toepassing ervan. Dat gebeurt allemaal in de lifter. De lifter moet eigenlijk ook tools genereren om generieke applicatie mogelijk te maken, een soort reflectie ondersteuning dus.
EyE ja, ic. in feite dus een eval voor dynrulecalls
bravo yepz

Submitted on 23 May 2004 at 10:11

STR-96, visser:
I don’t think this is a good idea. I made an attempt to make a parameterized version of the dynamic rule merge operations intersect and union. It turns out that it only makes sense to inspect dynamic rules by applying them since the information in the closure should not be exposed to programmers; we’d get the same kind of problems as with the hand coded intersections in the old dynamic rules. So unless there is a something sensible that can be done here, that can’t be done with the current operations (apply, once-, bagof-) I vote to close this issue.

STR-96, martin:
Well, the bigbagof is an example of an operation that cannot be expressed without changing the compiler.

A key requirement for the generic application of dynamic rewrite rules is to hide the internal representation. I’m not sure if this will be possible, but on the other hand I see no reason why this could me impossible.

So, the application should not inspect the dynamic rule representation, but instead request sets of possibly applicable dynamic rules. The API should not actually apply them: this is done in the user-code (probably a library). The dynamic rules API could provide some higher level strategies for such queries.

btw … while writing this comment, I’m remembered of our discussion of last week on compile-time Stratego generation and transformation in code defined by the user (innermost optimization).

Maybe that is the real solution. It’s interesting to see the trade-off between genericity and code generation in this problem. Maybe, genericity is not the way to go in this case.

STR-96, martin:
I finally agree that we don’t want this.