> > How about the transformation from Chapter 7 of [1] (by Philip Wadler)?
> > It should be similar to the `pseudo code':
> > 
> > type expr = ...;;
> > type patt = ...;;
> > type qualifier = Gen of patt * expr | Filt of expr;;
> > type compr = (expr * qualifier list);;
> > let rec expr = function
> >  | ...
> >  | (e, qs) -> transform [] (e, qs)
> >  | ...
> > and transform l = function
> >  | (e, []) -> expr e :: expr l
> >  | (e, Filt f :: qs) -> if expr f then transform l (e, qs) else expr l
> >  | (e, Gen (p, l1) :: qs) ->
> >   let rec h = function
> >    | [] -> expr l
> >    | u :: us -> (function p -> transform (h us) (e, qs) | _ -> h us) u
> >   in h (expr l1)
> > ;;
> > 
> > (* where h, u, us are fresh variables not occurring in e, l1, l, or qs *)
> > 
> > Sorry I'm not yet familiar with camlp4 grammar extensions, but of course
> > above code would make use of them otherwise.
> 
> Yes this approach can be integrated with a camlp4 extension.
> 
> > It is stated in [1] that the resulting code is optimal in that it
> > performs the minimum number of cons operations.
> 
> Nice.
> 
> > And I did ignore the hint that fresh variables make things
> > complicated :).
> 
> Yes it can...
> 
> Best regards,
> 
> -- 
> Nicolas Pouillard aka Ertai
> 
I deduce that there is no standard way of introducing
`fresh' (w.r.t. the abstract syntax tree) variables
within a camlp4 syntax extension? Wouldn't that be nice? =)

Has anybody every implemented a solution to that problem?

cheers

christian