In stratego:

some-rule: a -> b
  with
    b := <some-other-rule>a;
    b := <yet-another-rule>a

(b in rule header is a use, first line with assign to b is a definition and the last line is a use of b again.)

In relations language:

some-rule(a:A)
    a hasB b
    c hasB b
    a hasC c
  ->
    a
    b
    c

(a, b and c are defs the first time they occur in the ast left-to-right, the others are uses).

Current work-around

Make a desugaring rule that traverses the AST and wraps the defs in Definition() and the Uses in Use() constructors.

Submitted by Daco Harkes on 20 November 2014 at 10:48

It is unclear if this is still name binding. You could also argue, that both with clauses define b. In NaBL and TS we circumvent this by distinguishing variable declarations and uses syntactically (which is not ideal).

Yeah the desugaring basically does the same, making an AST-node distinguish between them.
Maybe the desugaring should be the way to go.

Well arguing that both b’s in the with clause are definitions makes code generation harder, because then you are going to do ‘is this a def or a use’ during code generation. (Since the def is just an assignment, but the use is an equality check.)

In Stratego, the second “assignment” is typically an error, since it will match against the already bound variable b. When you want to give a warning there, you need to do the same def or use analysis, which is more a data-flow analysis. For example, you could have the following in Stratego, which is fine:

foo: a -> b
with (b := <bar> a) 
   + (b := <foobar> a)

The def or use data-flow like analysis is in the desugaring rule done before name binding.
But preferably this data-flow like analysis could be dependent on name binding and name binding on this data-flow (like types on names and vice versa).

The question would then also be what would this data-flow like analysis look like.
The current solution with a desugaring is a traversal past the AST, but that requires the data-flow is through the AST from left to right.
So it should probably be more general than that.

However, data-flow usually depends on control-flow and analysis in the first place…

(posted in wrong Issue)

If one would argue that these are multiple definitions of the same variable then:

• if the second definition has a type, then it should be checked if this type is the same (and it should not get two types when queried)
• the second ‘assignment’ of the variable should be ok with having no type assigned
• and if this definition is used in a parent ast-node and is defined without a type, the parent ast-node should have access to the type defined by the first definition.

s:Student enrolledIn c
c:Course assistedBy s2
s knows s2

s, c and s2 are defined twice.
The first occurrence of s and c define their types. The second occurrence of c also specifies its type but here it should be a check.
The second occurrence of s is only a use, nothing should be checked.
For s2 it also holds that the first one defines its type and the second occurrence should check if its the same type.

If one desugars the AST to mark every first occurrence name binding is doable.

It becomes more fun if it is not necessarily the first occurrence that provides the type.

s knows s2
s:Student enrolledIn c
c:Course assistedBy s2

Now the first occurrence of s is a use and the second occurrence of s defines its type.

So when modelling this as non-unique defs some logic for how many times the type is specified needs to be described.