Typical examples are checks for nested traversals, explicit returns in traversals and ForEach loops, and type checks for return expressions.

Submitted by Guido Wachsmuth on 24 January 2014 at 11:06

How would you express these as name definitions and resolutions? I think this is a data-flow/control-flow problem and should not be solved with name binding.

You add a definition at the context and scope this definition. You can then check by checking for duplicate definitions. Eelco, Gabriël and I agreed on it, that these things should be realised w/o additional traversals. I will forward the mails to you.

Yes, please do. Yes, this makes sense for the nesting of Traversals. In fact we should already be able to do this (each traversed variable has a property to indicate so).

But explicit return is a problem of control flow. It should be resolved using the same technique as figuring out that return statements are missing or that code is unreachable.

I gave it a first shot for traversals and ForEach, and it works. However, the change breaks other test cases, where I do not see how I could have caused this.

Solution in NaBL:

Traversal(travkind, var, iter@IterSource(QualifiedCall(exp, range, _)), entry, filter, navigator, forward, reverse):
...
implicitly defines Context Traversal() in filter, navigator, forward, reverse

Task-based constraint:

nabl-constraint(|lang, ctx, uri*):
  Traversal(n, _, _, _, _, _, _, _) -> <fail>
  where
    uri       := <lookup-uri(|uri*)> NablNsContext()
  ; scope*    := [uri|<nabl-uri-all-lexical-scopes> uri]
  ; traversal := <nabl-resolve-task(|ctx, NablNsContext(), Traversal(), [])> scope*
  ; <task-create-error-on-success(|ctx, traversal, "Nesting of DFS/BFS traversals is not permitted")> n

That’s quite an elegant solution. At the HEAD of fix/update-to-spx-nightly (i.e. commit 7a3f76e) all tests are passing.

At the head of refactor/typing-in-ts, my changes break tests such as “Procedure must have a return statement on all possible control flows” in dataflow.spt.