Miscellaneous-B

Below is the lastest release announcement for Tefkat. It’s a little
premature because the fixpoint implementation is incomplete, but I
needed to get an urgent memory leak plugged so I figured I may as well
release the rest since it’s mostly been tested by Kerry’s magic xforms
generating transformation.

Implementing the fixpoint stuff is quite interesting but I suspect that
the last part may be more of a challenge than I bargained on. We’ll
see. The easy part is getting it right for the transformation rules.
Let’s examine the issues:

1. Recursion: Rules can depend on themselves or each
   other recursively via tracking classes. That is, a rule that queries a
   tracking class with a LINKS clause depends on a rule that populates a
   tracking class with a LINKING clause. If there are cyclic dependencies,
   then we need a fixpoint computation. This is simple to implement – just
   re-evaluate all the rules involved until no new tracking instances are
   created.
2. Negative dependencies: If a rule contains a LINKS
   clause inside a NOT (or in the condition of an IF-THEN-ELSE clause) then
   things get interesting. Essentially, we have to delay evaluating this
   rule until all other rules that might contribute to the creation of
   tracking instances that would match this LINKS clause have been
   evaluated. To do this, we organise the rules into strata and perform
   the fixpoint computation on each rule-set in order.
3. Patterns: The above analysis needs to take into
   account dependencies between rules that occur in the context of pattern
   invocations, and the current implementation does so. However, patterns
   themselves may also be involved in negative dependencies and this is the
   current limit of the Tefkat implementation — stratification is checked,
   but not applied for pattern evaluation.

So, why is it done for rules and not for patterns? The answer lies in
the nature of the tracking class dependency. Essentially, tracking
instances correspond to cached evaluations of the rules that create them
and the semantics of Tefkat rules is an “all solutions” semantics so we
have to generate all the tracking instances that we can.

Patterns on the other hand are not things that we necessarily want to
“fully materialise”. For example, consider a pattern that captures the
concept of a path from A to B as being the existence of an edge from A
to B or an edge from A to C and a path from C to B. If the rule(s) that
call on this pattern only ever call it for a specific starting point,
then we don’t want to do the potentially large amount of work involved
in constructing the whole path relation. Worse still, it is possible
that a pattern may represent an infinite relation (for example, it may
construct instances representing paths in a cyclic graph).

What I think we need is a form of top-down evaluation strategy (with
answer caching) that still works within the framework of evaluating
rules strata-by-strata. The problem is that the arguments to a pattern
call may only be known when evaluating the strata that comes
after the strata in which the pattern must be evaluated.

Time to read up and experiement…

I'm pleased to announce a new version of Tefkat is now available that
fixes a long-standing memory leak problem in the editor.

There are also a large number of new features in this release including
a couple that are only partially complete (but will be complete in the
upcoming 2.1.0 release).

Notable new features include:

* A Tefkat Preferences pane that allows you to set workspace-wide URI
mappings so you no longer have to add them to every tefkat.xml file

* Better debugging support and also support for normal launches so you
can de-couple running your transformation(s) from the Eclipse
(auto-)build process

* The ability to constrain the order of values in multi-valued features.
  This done by specifying relative ordering and is usually put in
standalone rules that get the relevant information from tracking classes:

   RULE ordering
     WHERE tracking LINKS src=src1, tgt=tgt1, sVal=sVal1, tVal=tVal1
     AND   tracking LINKS src=src2, tgt=tgt2, sVal=sVal2, tVal=tVal2
     AND   src1 BEFORE src2 IN src.sFeature
     SET   tgt1 BEFORE tgt2 IN tgt.tFeature
   ;

* An if-then-else construct:

   RULE ITE
     FORALL Src src
     WHERE  IF src.sFeature = x THEN
              val = x
            ELSE
              val = "default"
            ENDIF
     MAKE   Tgt tgt {
              tFeature: val;
            }
   ;

* Better handling of numbers for arithmetic and comparisons

* Initial support for fixpoint evaluation of transformations
   + stratification of rules/patterns is established
   + fixpoint computations are performed for each strata but only
     with respect to rules, not patterns

* inline tracking class definitions now support attributes not just
references and also support primitive types (string, int, etc)

* The parser/editor now reports warnings for variables that only occur
once in a rule/pattern

michael