On Tue, 20 Aug 2002, Thorsten Ohl wrote:

> malc  <malc@pulsesoft.com> writes:
> 
> > With http://algol.prosalg.no/~malc/code/patches/specfun.tar.gz 
> > (patch against 3.04) you will get this instead:
> > 
> > *** Linearized code                                                             
> > Opt_f2_72:                                                                      
> >   A/11[%ecx] := [env/10[%ecx] + 12]                                             
> >   A/12[%ecx] := [A/11[%ecx]]                                                    
> >   tailcall "Opt_f_62" R/0[%eax]                                                 
> >   R/1[%ebx]                                                                     
> >   R/2[%ecx]   
> 
> Neat!
> 
> > What will be specialized: frist order non-curried functors
> 
> Unfortunately, the cases where my code would benefit most are all
> curried and or higher-order functors.  E.g., I have beauties like
> 
>     module Tagged (Tagger : Tagger) (PT : Tuple.Poly)
> 	(Stat : Stat_Maker) (T : Topology.T with type 'a children = 'a PT.t)
> 	(P : Momentum.T) (M : Model.T) =
>       struct 
> 	...
>       end
> 
> where the signature Momentum.T can be implemented by simple bitmask
> operations and since it is used _very_ often, specialization would
> help a great deal.  The situation for symoblic algebra is similar.

If i remember correctly curried functors werent implemented because they 
cant be mapped neatly into current code, with hacks here and there it was 
possible, but i wanted to create half-decent and semi-readable code. Maybe 
there are other obstacles as well, it's been a while.

> 
> I guess that the major obstacle for generalizing your approach to
> specialization is in preventing code bloat.  Or am I wrong?

More than code bloat(which is tunable in case of my patch) lack of 
interest on part of Inria team has much bigger impact.

> 
> Fine-grained control for specialization (like your syntax extension)
> at the point of functor application would be very useful.  The above
> code could probably gain a constant factor larger than 10, if I could
> specialize curried and higher-order functors. [At crunch time, I can
> do this by hand of course, but--also for educational reasons--it would
> be nice to let the compiler take care of this.]

There's one thing i should mention, im not a type teorist, lambda calculus 
expert and so on. Specialization like it is implemented(simple rewriting 
of functor argument in functor body with some care to preserve typing) is
what SML/NJ does as well. Then again, types that specfun produces are a 
bit off w.r.t vanilla Caml (they used to be 1:1 but, then one bump was 
noticed and they stoped to be). I belive that if Jacques or Xavier or 
anyone else on the team was interested in this feature it could have been 
added in a matter of days, alas, they dont, and there is little that can 
be done.

-- 
mailto:malc@pulsesoft.com

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners