Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
100 lines (66 sloc) 2.54 KB
.. _2.5.5-migration-guide:

Spoofax 2.5.5 Migration Guide

A few changes in Statix need migration for specs written for older versions.

Statix

A few features in Statix were not well-defined and removed until a better way to support them is found. Therefore, the following changes may require you to make small modifications to a specification:

  1. Functional constraints can only have a single output.
  2. Regular expression and label order must be direct parameters to queries.
  3. Namespace based query short-hands require
    • a literal occurrence as argument, and
    • an explicit resolution policy entry.

Functional constraint outputs

Functional constraints previously were allowed to have multiple output arguments, such as:

f : T * T -> T * T`

This was sometimes indistinguishable from types with a single tuple output, such as:

f : T * T -> (T * T)`

From now on, functional constraints can only have a single output. Constraints with multiple outputs need to be rewritten to return a tuple instead.

Query parameters

Queries would accept arbitrary predicates for the label regular expression and label order. For example, a query could be written as:

query filter myWf and true
      min myOrd and false
      in s |-> _

with

myWf(ls) :- pathMatch[P*](ls).

myOrd(l1,l2) :- pathLt[$ < P](l1,l2).

This is not possible anymore, instead the regular expression and label order must be direct parameters of the query. The query above should be directly written as:

query filter P* and true
      min $ < P and false
      in s |-> _

The following syntax is still accepted, but deprecated:

query filter pathMatch[P*] and true
      min pathLt[$ < P] and false
      in s |-> _

Namespace-based resolution shorthands

The requirements for namespace-based resolution shorthands have become stricter.

First, if they are used, ther emust be an explicit resolution policy for the namespace. For example, using a constraints such as:

Var{x@-} in s |-> _
type of Var{x@-} in s |-> _

requires in the signature at least:

signature
  name-resolution
    resolve Var

A full resolution policy with regular expression and label order looks like this:

signature
  name-resolution
    resolve Var filter P* min $ < P

Second, the namespace-based constraints require an occurrence literal. The following does not work anymore:

d == Var{x@-},
d in s |-> _

The occurrence has to be repeated in the constraints, as:

Var{x@-} in s |-> _
You can’t perform that action at this time.