From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA22920; Tue, 20 Aug 2002 08:36:03 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id IAA22904 for ; Tue, 20 Aug 2002 08:36:02 +0200 (MET DST) Received: from comtv.ru (comtv.ru [217.10.32.4]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g7K6a1j03869 for ; Tue, 20 Aug 2002 08:36:01 +0200 (MET DST) Received: from [10.0.66.9] ([10.0.66.9] verified) by comtv.ru (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 4155041; Tue, 20 Aug 2002 10:36:00 +0400 Date: Tue, 20 Aug 2002 10:35:28 +0400 (MSD) From: malc X-X-Sender: malc@home.oyster.ru To: Thorsten Ohl cc: caml-list@inria.fr Subject: [Caml-list] Re: Specialization (was: Inlining across functors) In-Reply-To: <15713.27612.63106.168053@wptx47.physik.uni-wuerzburg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Tue, 20 Aug 2002, Thorsten Ohl wrote: > malc 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