AST traversal functions (was: SML->OCaml)

[Martin Jambon <martin_jambon@emailuser.net>]

On Tue, 8 Mar 2005, Andreas Rossberg wrote:

> In fact, it would be much more complicated. First, identifier status is
> scoped. Constructors are frequently defined locally. In particular, this may
> happen implicitly through the use of "open". To derive the required
> information you hence needed to perform a complete binding analysis,
> including modules and signatures.
>
> Then, SML actually allows constructor status to be withdrawn from an
> identifier. For example, the following program is valid:
>
>   signature S = sig type t val x : t end
>   structure A : S = struct datatype t = x end
>
> There are few programs that make use of this possibility, but I expect them
> to coincide with those that violate the usual case conventions in the first
> place. An SML-to-OCaml translator had to go to quite some length to
> translate such programs.
>
> In summary, to deal with constructor status correctly (not to mention stuff
> like datatype replication, local, records, user-defined fixity, etc.) you
> basically need half an SML frontend. It seems out of scope for a Camlp4 hack
> to be more than a simple approximation.

Yes, but I believe there should be a convenient way at least to reuse the
syntax tree produced by the current converter, and convert the incorrect
uppercase/lowercase identifiers.
It just requires a good root-to-leaves substitution function which does
not ask us to match explicitely every kind of node of a given type (which
is extremely repetitive and error-prone, even with quotations). I already
thought of doing this (actually automatically deriving such a higher-order
function from the type definition of the AST: Pcaml.expr and friends).

Example:

let X = 1 in fun x -> X

We should be able to specify that
  let $patt$ = $e1$ in $e2$

adds the binding to the current environment for converting expr.
And by default, everything is just "traversed".
For instance, the case $e1$ + $e2$ which is itself an expression should
not be explicitely unconstructed/substituted/reconstructed, that would be
done automatically.
This would let us focus only on the specific cases such as "open",
"let ... in", "fun ...", "let ..." (or "val ..."), simple identifiers and
module-related issues.


Martin