David Teller a écrit :
> 
>  I'm currently working on static analysis of JavaScript 2. For this, I
> need to keep lots of informations in each node of my AST, including
> things such as line/column (for better error messages), unique
> identifier (for storing inferred information), etc. As things progress,
> I fear that the number of such informations is growing prohibitive and
> very much getting into the way of pattern-matching.

I don't see why a lot of information in AST nodes is getting into the 
way of pattern-matching. When decorating ASTs, you basically replace a 
type definition such as

type t =
   | A
   | B of b
   | C of string * t * t
   | D of t list

by two mutual recursive types

type t =
   { node : t_node;
     ... a lot of information here, in other fields ... }

and t_node =
   | A
   | B of b
   | C of string * t * t
   | D of t list

As you can see, this is a purely local modification: three lines were 
inserted (between "type t" and "=").

As for pattern-matching, this is exactly the same: the modification is 
only local. Indeed, your recursive function over type t, which was 
looking like

let rec f = function
   | A -> ...
   | B b > ...
   | C (s, t1, t2) -> ... (f t1) ... (f t2) ...
   | D l -> ...

is turned into

let rec f t =
   f_node t.node

and f_node = function
   | A -> ...
   | B b > ...
   | C (s, t1, t2) -> ... (f t1) ... (f t2) ...
   | D l -> ...

Again we only inserted new lines between "let rec f" and "= function".

I agree that nested pattern-matching is slightly different, though. But 
as already said by somebody else, you can match against field node only, 
which looks like

   | C (s, {node=A}, {node=D l}) -> ...

I don't see that as really intrusive.

Hope this helps,
--
Jean-Christophe