Re: [Caml-list] Confusing behaviour of type inference for polymorphic classes.

[Dmitri Boulytchev <dboulytchev@gmail.com>]

> Yes, it's a neat approach!  One small suggestion: in order to handle
> the case where the type you're traversing has multiple recursive
> instantations with different parameters you might consider passing the
> instance creation function in a way that allows it to be called
> polymorphically (e.g. by wrapping it in a record with a polymorphic
> field):
     Of course; this is yet another workaround to make it possible to use
that workaround :)

> There is one last thing I'm curious about.  The difficulties that
> you're avoiding with open recursion seem to arise from the
> representation of the traversal as a parameterised class with a
> monomorphic method.
     The reason is quite simple --- class parameters are used to represent
the *result* type of the transformation, not the parameters of the 
transforming
type. I simplified the example just to clarify the polymorphic class issues.
     In reality what I'm interested in is somewhat like this: for a type

     ('a, 'b, ...) t = A ... | B ... | C ...

     we generate a virtual class

     class virtual ['ta, 'tb, ..., 'inh, 'syn] t_t = object
         method virtual c_A : <explicitly polymorphic type on 'a, 'b etc.>
         method virtual c_B : <explicitly polymorphic type on 'a, 'b etc.>
         etc.
     end

     which represents some attribute transformation with inherited 
attribute type 'inh; the
type of synthesized attribute for type 'a is 'ta, for 'b is 'tb etc., 
for type ('a, 'b, ...) t
is 'syn. The methods of the class handle the individual constructors; 
the arguments for
these methods capture the transformation function as well.
     For example, for regular map we have the following bindings:

     class ['ta, 'tb, ...] map_t = object
         inherit ['ta, 'tb, ..., unit, ('ta, 'tb, ...) t] t_t
         ...
     end

     for show we have

     class show_t = object
         inherit [string, string, ..., unit, string] t_t
         ...
     end

     for, say, eval

     class eval_t = object
         inherit [int, int, ..., string -> int, int] t_t
         ...
     end

     etc.

     Under this representation we might need the single 
shallow-traversal generic function
to implement all these transformations.
     Per-constructor object encoding allows modification with less 
boilerplate code (via
inhertance); in addition if we have a polymorphic-variant type t = [ a | 
b | c ... ] then
the certain transformation for t can be constructed by regular class 
inheritance from the
implementations of the same transformation for it's counterparts.


     Best regards,
     Dmitry.

     P.S. I was'nt offended by your long message (but surprised a little 
bit ).