var a = new A();
var b = a.someReference;

or in the relations language

a:A
a someReference b

These need local type inference. Which requires not defining the type on the definition site in NaBL, but at a later time.
I believe this is not supported in the current NaBL/TS implementation.

Is support for local type inference a feature we can expect in the (near) future?

(Note: I’m not sure whether this belongs in the NaBL or TS project.)

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

Local type inference is already supported. Its not entirely clear what you are referring to in your example, but if it is about the type of a and b, you can have a rule like this:

VarDec(v, e): defines Variable v of type t where e has type t

Local type inference is indeed supported, iff every occurrence is type inference.

var a = new A(); //defines var a with type of expression
B b = new B(); //defines var b with type B & give error if expression is wrong type (or the other way around)

To do this in NaBL and TS a syntactic difference for both lines of code is required.

Example in my language Def() and DefByRel() distinguish the two cases:

// define node with its type from type annotation // a:A
Node(NaBLHelp(v, Def()), EntityRef(t), a):
	defines Variable v
		of type t
		
// define node with its type from relation // b somerelation a
Edge(e, Node(NaBLHelp(v, DefByRel()), none, a)):
	defines Variable v
		of type t
		where e has type t

//and in TS the check
Edge(e, n) :-
where e : e-ty
	and n : n-ty
	and e-ty == n-ty else error $[Type mismatch: expected [e-ty] got [n-ty] in Edge] on n

The question is if this is possible without syntax distinction.

(Note: these syntax/AST distinctions explode, there is already a 3rd one for Use() (NaBL/120) and these are done in pre-NaBL desugaring.)

There seems to be a natural syntactic difference between var a and B b which can be used in a match, can’t it?

Another approach would be to have two TS rules assigning a type to the whole definition. One for the var case, one for the explicit type case. You could use that type in the NaBL rule

t@...: defines Foo f of type ty where t has type ty

Syntatic difference is Node(name,type,attrs) vs Node(name,None(),attrs) concretely id{attrs} or id:Type{attrs} these are normalized by default. The type is only required if there is no type from a relation or a previous use of the variable, and if the type is supplied while it has already a type then it is used to check if it’s correct.

Assigning a type to the whole definition, and then referring to it from within the definition (ast-wise) or referring to it at the whole definition will not work: NaBL and TS tasks only flow upwards along the ast.
Either Edge must be part of node to use its type for typing Node, instead of Node being part of the Edge.

(The ast is already completely structured along the needs of NaBL and TS. e.g. Edge(TsHelp(Node, relation), Node) instead of Edge(Node, relation, Node) to hang the type of relation on TsHelp.)

I see, this is a more complex issue, since you have the term defining the name embedded in a bigger AST which yields the type.