Among the features that cannot be missed in a transformation language
(and sorry if that's too obvious) I mention:
* a data structure pattern language
(something between patterns used in Prolog and some functional languages
and XPath)
* and rules that are selected via these patterns (with a certain number of
default behavior to make useful things easier).
For example, an identity transformation may look like
tr_rule id($obj ~~ Any) { tr_apply($kid) for $kid ($obj.children) }
and it could be changed to an almost identity by inserting
a rule that changed the string "foo" to "bar".
tr_rule quasi_id($obj ~~ Any) { tr_apply($kid) for $kid ($obj.children) }
tr_rule quasi_id($obj ~~ "foo") { "bar" }
More complex patterns should be able to give names to structure parts
which may be used in the body of the rule. Something similar to what
Prolog does.
tr_rule some_trans( $obj ~~ [ $a ~~ Hash, $b ~~ { 'k' => $vk } ] ) {
[ { 'y' => $vk, $a } ]
}
The rules must know how to walk each kind of structure: array, hash,
object, whatever and build new ones.
My 0.00000002 cents.
Adriano Ferreira.
On 9/28/06, Allison Randal <[EMAIL PROTECTED]> wrote:
I need a volunteer write up the requirements for a mini transformation
language to use in the compiler tools. You wouldn't have to write up the
specification for the language, just what features we need. This will
help us plan what it's going to take to get from here to there, and give
us a way to measure when the spec/implementation can be called "done".
It's essentially a matter of spending some time with me and Patrick on
the phone and solidifying the ideas on paper, together with any
perspectives or experience you add to the mix.
Allison
