[Caml-list] Functors

[Caml-list] Functors

[Jon Harrop]

Could Set (and others) be implemented polymorphically by using a comparison 
function passed as an argument?

If so, what would be the implications of this approach? I think: you couldn't 
use the type checker to enforce consistent comparison functions between two 
different sets which were, say, being merged. I think you can enforce this 
using the functor approach provided the Sets came from the same functor 
"instantiation".

Functors appear to be somewhat similar to templates in C++. Does the functor 
approach produce more efficient code as it is partially specialised over the 
comparison function?

Also, can functors map to functors as well as modules? If so, code could be 
progressively specialised...

Cheers,
Jon.

-------------------
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

Re: [Caml-list] Functors

[Martin Jambon]

On Sun, 2 May 2004, Jon Harrop wrote:

> Could Set (and others) be implemented polymorphically by using a comparison
> function passed as an argument?
>
> If so, what would be the implications of this approach? I think: you couldn't
> use the type checker to enforce consistent comparison functions between two
> different sets which were, say, being merged. I think you can enforce this
> using the functor approach provided the Sets came from the same functor
> "instantiation".

With my words: I understand functors as a way to parametrize a type with a
value.
They allow you to detect inconsistencies at compile time (e.g. 2 sets
parametrized with different "compare" functions).
Without functors, as far as I know, you can only test inconsistencies at
run time (e.g. by putting all the parameters in a record an check physical
equality of the records).


> Functors appear to be somewhat similar to templates in C++. Does the functor
> approach produce more efficient code as it is partially specialised over the
> comparison function?

Unfortunately no.
Julien Signoles wrote a defunctorizer (works from the source code of the
functor):

  http://www.lri.fr/~signoles/ocamldefun/manual.html


Maybe some user manual should tell us more about when to use functors
rather than just how to use them.



Martin


-------------------
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

Re: [Caml-list] Functors

[Jon Harrop]

On Sunday 02 May 2004 11:24, Martin Jambon wrote:
> On Sun, 2 May 2004, Jon Harrop wrote:
> > Functors appear to be somewhat similar to templates in C++. Does the
> > functor approach produce more efficient code as it is partially
> > specialised over the comparison function?
>
> Unfortunately no.
> ...
>   http://www.lri.fr/~signoles/ocamldefun/manual.html

Wow, ok. So ocamldefun maps ocaml code with functors onto ocaml code without 
functors and, according to their examples, this can result in an 8 times 
performance improvement due to inlining.

This begs the question: why is this functionality not in the compiler? In 
fact, using functors with the current compiler actually reduces 
performance...

Cheers,
Jon.

-------------------
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

Re: [Caml-list] Functors

[skaller]

On Sun, 2004-05-02 at 23:34, Jon Harrop wrote:
> On Sunday 02 May 2004 11:24, Martin Jambon wrote:
> > On Sun, 2 May 2004, Jon Harrop wrote:
> > > Functors appear to be somewhat similar to templates in C++. Does the
> > > functor approach produce more efficient code as it is partially
> > > specialised over the comparison function?
> >
> > Unfortunately no.
> > ...
> >   http://www.lri.fr/~signoles/ocamldefun/manual.html
> 
> Wow, ok. So ocamldefun maps ocaml code with functors onto ocaml code without 
> functors and, according to their examples, this can result in an 8 times 
> performance improvement due to inlining.
> 
> This begs the question: why is this functionality not in the compiler? In 
> fact, using functors with the current compiler actually reduces 
> performance...

The answer is separate compilation.

When you instantiate a Set.Make .. you only have
the interface. Hard to inline without actually having
the body of the functor..

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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

Re: [Caml-list] Functors

[Jon Harrop]

On Sunday 02 May 2004 15:12, skaller wrote:
> ...
> When you instantiate a Set.Make .. you only have
> the interface. Hard to inline without actually having
> the body of the functor..

Sure, so you can't do it if you're creating a DLL for the OS to handle. But if 
you're making an executable, as I suspect most of us are, then you can do it 
(perhaps at compile-time, definitely by link-time).

Cheers,
Jon.

-------------------
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

Re: [Caml-list] Functors

[skaller]

On Mon, 2004-05-03 at 02:49, Jon Harrop wrote:
> On Sunday 02 May 2004 15:12, skaller wrote:
> > ...
> > When you instantiate a Set.Make .. you only have
> > the interface. Hard to inline without actually having
> > the body of the functor..
> 
> Sure, so you can't do it if you're creating a DLL for the OS to handle. But if 
> you're making an executable, as I suspect most of us are, then you can do it 
> (perhaps at compile-time, definitely by link-time).

Separate compilation is a tradeoff between
fast building and fast executables.

Ocaml is famous for amortising costs in a sensible
way. In the few cases the costs were critical,
they've been fixed: eg arrays of unboxed floats.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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

RE: [Caml-list] Functors

[Jacques Carette]

> Separate compilation is a tradeoff between
> fast building and fast executables.

At the speed of today's computers, choosing 'modules' as the grainyness
level to do seperate compilation seems out-dated.  Creating a way to collect
modules together (call them packages for lack of a better term) and having
seperate compilation at the level of packages instead of modules would
probably be a better tradeoff point these days.

I know of people who have their 'build' scripts concatenate all their Ocaml
source files into one large file before compiling anything; the resulting
compilation time is still very short, but the corresponding executable is
significantly faster!

Jacques

-------------------
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

RE: [Caml-list] Functors

[Alain.Frisch]

On Mon, 3 May 2004, Jacques Carette wrote:

> I know of people who have their 'build' scripts concatenate all their Ocaml
> source files into one large file before compiling anything; the resulting
> compilation time is still very short, but the corresponding executable is
> significantly faster!

Do you have an explanation for this fact ?  Given that ocamlopt can inline
function and propagate constants across compilation unit boundaries, what
kind of extra optimizations do you get with a single compilation unit ?

-- Alain

-------------------
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

RE: [Caml-list] Functors

[Jacques Carette]

> Do you have an explanation for this fact ?  Given that ocamlopt can inline
> function and propagate constants across compilation unit boundaries, what
> kind of extra optimizations do you get with a single compilation unit ?

It appears to be inlining of functions across compilation unit boundaries
that makes the difference.

Note that this is second-hand, if people really want to know details, it
would take me a couple of days to get them from the right people.

Jacques

-------------------
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

[Caml-list] Mathematica

[Jon Harrop]

I've spent the past few days trying to implement an interpreter for the 
Mathematica language. This is quite an exotic language. For example, it has a 
single type - the AST - and is "strongly typed" as a side-effect. For anyone 
who is interested, a brief description and my resulting code are on the web 
here:

http://www.chem.pwf.cam.ac.uk/~jdh30/programming/mathematica/

I'd be particularly interested to hear any constructive criticism of my coding 
style, both from the point of view of interpreter/compiler writing and also 
more general comments...

Cheers,
Jon.

-------------------
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

RE: [Caml-list] Functors

[Alain.Frisch]

On Mon, 3 May 2004, Jacques Carette wrote:

> > Do you have an explanation for this fact ?  Given that ocamlopt can inline
> > function and propagate constants across compilation unit boundaries, what
> > kind of extra optimizations do you get with a single compilation unit ?
>
> It appears to be inlining of functions across compilation unit boundaries
> that makes the difference.

Well, precisely, ocamlopt can inline accross compilation unit boundaries,
so what's the benefit of having a single compilation unit ?

> Note that this is second-hand, if people really want to know details, it
> would take me a couple of days to get them from the right people.

FWIW, I just tried to put all the .ml/.mli of a medium-sized project (18
kloc) into a single file. Observations:

- ocamlopt crashes because of a stack overflow; ocamlopt.opt works fine.
- compilation is about 3 times slower.
- there is no noticeable difference on the runtime performance.


-- Alain

-------------------
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

Re: [Caml-list] Functors

[Julien Signoles]

> Wow, ok. So ocamldefun maps ocaml code with functors onto ocaml code without
> functors and, according to their examples, this can result in an 8 times
> performance improvement due to inlining.

As far as I test ocamldefun, performance improvement is very dependent of
the application. Mainly, the defunctorized code is generally much more
efficient than the code with functors if
(1) some functions are not inlined due to functors; and
(2) these functions are called very often.
Generally, in the others case, the defunctorization do not improve
performance a lot.

> This begs the question: why is this functionality not in the compiler? In
> fact, using functors with the current compiler actually reduces
> performance...

Some SML compilers include a defunctorizer... But, in a lot of cases,
functors do not reduce performance a lot (as explained above). Morever,
static analysis tools do not generally correctly work on functorized
programs: so a source-to-source defunctorizer as ocamldefun can be used
by these tools while a defunctorizer directly included in the compiler
cannot. So i'm not sure including a defunctorizer in the compiler is a
good thing...

Cheers,
Julien Signoles
-- 
mailto:Julien.Signoles@lri.fr ; http://www.lri.fr/~signoles
"In theory, practice and theory are the same,
but in practice they are different" (Larry McVoy)

-------------------
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

Re: [Caml-list] Functors

[Jon Harrop]

On Monday 03 May 2004 17:02, Julien Signoles wrote:
> As far as I test ocamldefun, performance improvement is very dependent of
> the application. Mainly, the defunctorized code is generally much more
> efficient than the code with functors if
> (1) some functions are not inlined due to functors; and
> (2) these functions are called very often.
> Generally, in the others case, the defunctorization do not improve
> performance a lot.

Absolutely, but it can result in a huge performance increase in some cases. 
Although these cases may seem to be insignificant to most people round these 
parts, I believe they would be a make-or-break for someone considering ocaml 
for numerical work. The most obvious example would be to use functors to 
partially specialise code for a primitive vector or geometric type. When I 
did something equivalent in C++ using templates I saw a 2-3 times performance 
improvement. I think it would be a shame if people had to resort to using 
"cat" to build their ocaml source files before compiling...

> Some SML compilers include a defunctorizer... But, in a lot of cases,
> functors do not reduce performance a lot (as explained above). Morever,
> static analysis tools do not generally correctly work on functorized
> programs: so a source-to-source defunctorizer as ocamldefun can be used
> by these tools while a defunctorizer directly included in the compiler
> cannot. So i'm not sure including a defunctorizer in the compiler is a
> good thing...

I didn't mean including the defunctorizor in the compiler, just the 
functionality which it provides. Perhaps I am mistaken, but can these 
optimisations not be done after all of the analysis, as a relatively simple 
extension to the current inlining optimisations?

I was afraid that the ocamldefun example might be out of date so I wrote my 
own little version (see end). To my surprise, this example runs 15-18 times 
slower when generated via a functor! I'd be interested to hear if other 
people get similar results.

Cheers,
Jon.

module type FUNC = sig val f : int -> int -> int end
module Func : FUNC = struct let f a b = a / b end
module FuncFunc = functor (F : FUNC) -> struct let f = F.f end
module MyFunc = FuncFunc (Func)

let f1 a b = a / b

let _ =
  let t = Unix.gettimeofday () in
  for i=0 to 1000000000 do
    ignore (f1 12345 8);
  done;
  print_string ("Same compilation unit took "^(string_of_float 
((Unix.gettimeofday ()) -. t)));
  print_newline ();
  let t = Unix.gettimeofday () in
  for i=0 to 1000000000 do
    ignore (MyFunc.f 12345 8);
  done;
  print_string ("Same compilation unit took "^(string_of_float 
((Unix.gettimeofday ()) -. t)));
  print_newline ();

-------------------
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

Re: [Caml-list] Functors

[Jean-Christophe Filliatre]

Jon Harrop writes:
 > 
 > Absolutely, but it can result in a huge performance increase in some cases. 
 > Although these cases may seem to be insignificant to most people
 > round these  parts, I believe they would be a make-or-break for
 > someone considering ocaml  for numerical work. The most obvious
 > example would be to use functors to  partially specialise code for
 > a primitive vector or geometric type.  

I  have  such an  example:  I  recently  wrote Ukkonen's  suffix  tree
algorithm in a functorized way,  being generic w.r.t. the alphabet and
w.r.t. to branching data structure used in the trees.

When applied  to the particular char/string  alphabet, the performance
was quite poor  w.r.t. some C code implementing  the same algorithm. I
defunctorized manually and  got a 5 times speedup  (and the ocaml code
now runs almost as fast as  the C code, while still generic w.r.t. the
tree  data type).  The  main reason  was  that the  most often  called
function was  String.get (millions of  times) and through  the functor
argument it didn't get inlined.

-- 
Jean-Christophe Filliâtre (http://www.lri.fr/~filliatr)

-------------------
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

Re: [Caml-list] Functors

[Julien Signoles]

> > Some SML compilers include a defunctorizer... But, in a lot of cases,
> > functors do not reduce performance a lot (as explained above). Morever,
> > static analysis tools do not generally correctly work on functorized
> > programs: so a source-to-source defunctorizer as ocamldefun can be used
> > by these tools while a defunctorizer directly included in the compiler
> > cannot. So i'm not sure including a defunctorizer in the compiler is a
> > good thing...
>
> I didn't mean including the defunctorizor in the compiler, just the
> functionality which it provides.

It is what I mean too ;-). Sorry, my English is really perfectible.

Perhaps I am mistaken, but can these
> optimisations not be done after all of the analysis, as a relatively simple
> extension to the current inlining optimisations?

I'm not sure because functors add closures which are difficult to inline.

> I was afraid that the ocamldefun example might be out of date so I wrote my
> own little version (see end). To my surprise, this example runs 15-18 times
> slower when generated via a functor! I'd be interested to hear if other
> people get similar results.

I test your example. Here are my results on a PIII 700 MHz, 64Mo, using
ocamlopt.opt v3.06:

==========
without using ocamldefun:

Same compilation unit took 5.50491905212
Same compilation unit took 49.5608668327
55.000u 0.010s 0:55.07 99.8%    0+0k 0+0io 141pf+0w
==========

As you said, this example is very slow when generated via a functor.

==========
using ocamldefun:

Same compilation unit took 5.50432610512
Same compilation unit took 5.50287103653
11.010u 0.000s 0:11.01 100.0%   0+0k 0+0io 140pf+0w
==========

As you can see: no more loss of performance :-).

Thank's a lot, I keep your example: it is really interesting for me.

Cheers,
Julien Signoles

> module type FUNC = sig val f : int -> int -> int end
> module Func : FUNC = struct let f a b = a / b end
> module FuncFunc = functor (F : FUNC) -> struct let f = F.f end
> module MyFunc = FuncFunc (Func)
>
> let f1 a b = a / b
>
> let _ =
>   let t = Unix.gettimeofday () in
>   for i=0 to 1000000000 do
>     ignore (f1 12345 8);
>   done;
>   print_string ("Same compilation unit took "^(string_of_float
> ((Unix.gettimeofday ()) -. t)));
>   print_newline ();
>   let t = Unix.gettimeofday () in
>   for i=0 to 1000000000 do
>     ignore (MyFunc.f 12345 8);
>   done;
>   print_string ("Same compilation unit took "^(string_of_float
> ((Unix.gettimeofday ()) -. t)));
>   print_newline ();


-------------------
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

Re: [Caml-list] Functors

[brogoff]

On Wed, 5 May 2004, Julien Signoles wrote:
> > I didn't mean including the defunctorizor in the compiler, just the
> > functionality which it provides.
>
> It is what I mean too ;-). Sorry, my English is really perfectible.

I'm not sure I understand the difference, since there is only one
defunctorizer for OCaml, wouldn't including it in the compiler be the
easiest way to get that functionality?

In any case, the absence of a defunctorization step means that we often
have a choice between performance and a functorized programming style, which
stinks. Does ocamldefun deal with the recursive modules of 3.07?

MLton began as an SML defunctorizer if I'm not mistaken, but has evolved
into a whole program optimizing compiler. Since I usually have access to all
of the OCaml sources that I want to compile, an OCamlton is an appealing
prospect. Stephen Weeks (of the MLton team) told me he thought an OCaml front
end was doable (he mentioned that he's working or contemplating a Python front
end) but there were some interesting problems in translating some of the
newer OCaml features (recursive modules, polymorphic methods) but that he had
some ideas.

-- Brian

-------------------
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

Re: [Caml-list] Functors

[Jon Harrop]

On Wednesday 05 May 2004 21:41, brogoff@speakeasy.net wrote:
> I'm not sure I understand the difference, since there is only one
> defunctorizer for OCaml, wouldn't including it in the compiler be the
> easiest way to get that functionality?

As someone else said, using a "defunctorizer" apparently makes it impossible 
to perform some static analysis. Obviously, static analysis is a strong point 
of the language so we definitely want to keep that. I think this is an 
example of the static analysis being broken: use the core library Set functor 
to create a module implementing a set of integers, create two sets and merge 
them. If this were functorised, the integer compare could be inlined (which 
would probably result in a significant performance boost) but it would no 
longer be possible to statically check that the two sets being merged shared 
a common comparison function (which could be done statically before provided 
they were both created by our "integer set" module) because you can't compare 
functions.

So you don't want to just plug the defunctorizer into the compiler. I was 
suggesting the application of much lower-level code transformations (at 
intermediate- or assembler-representations) when possible, to in-line small 
functions slightly more aggressively. I think this would be very useful, 
probably quite easy to implement and I can't think of any downsides.

> ...

I would have thought that a bytecode->C compiler would be quite feasible and, 
perhaps, quite useful. What other compilers for ocaml are there?

Cheers,
Jon.

-------------------
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

Re: [Caml-list] Functors

[Alain.Frisch]

On Thu, 6 May 2004, Jon Harrop wrote:

> As someone else said, using a "defunctorizer" apparently makes it impossible
> to perform some static analysis.

I don't know who said that, but Julien Signoles said the opposite:

> Morever, static analysis tools do not generally correctly work on
> functorized programs: so a source-to-source defunctorizer as ocamldefun
> can be used by these tools while a defunctorizer directly included in
> the compiler cannot.

To rephrase it: since some static analysis are difficult to perform on
fonctors, it is good to have a standalone defunctorizer (not burried
into the compiler) to be used as a first pass of the analysis.

-- Alain

-------------------
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

Re: [Caml-list] Functors

[Olivier Grisel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alain.Frisch@ens.fr a écrit :
| On Thu, 6 May 2004, Jon Harrop wrote:
|>Morever, static analysis tools do not generally correctly work on
|>functorized programs: so a source-to-source defunctorizer as ocamldefun
|>can be used by these tools while a defunctorizer directly included in
|>the compiler cannot.
|
|
| To rephrase it: since some static analysis are difficult to perform on
| fonctors, it is good to have a standalone defunctorizer (not burried
| into the compiler) to be used as a first pass of the analysis.
|

Yes, but what about embedding ocamldefun as option/switch in the
compiler's command. Users could see it as another optimization option
easy enough to trigger by just adding or removing a flag in the makefile.

Those who wants to perform static analysis could use some other switch
to explicitely dump the defunctorised source code, eg :

$ ocamlopt -dump-defun foo.ml > defun_foo.ml

best
- --
Olivier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAmoNcTsBRE+WZ2SARAhTDAJ9liZz3MSVD0h0opFPTGSR8JJnyUQCgts+m
saP/ghOn3b5RRpFYIstOP+g=
=rIIi
-----END PGP SIGNATURE-----

-------------------
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

Re: [Caml-list] Functors

[Julien Signoles]

> In any case, the absence of a defunctorization step means that we often
> have a choice between performance and a functorized programming style, which
> stinks.

I don't think you have a stinking choice. My opinion is: always choose a
functorized programming style and, if this style significantly reduces
performance, then use a defunctorizer like ocamldefun. For example, see
the Jean-Christophe Filliâtre's contribution to this thread
(http://caml.inria.fr/archives/200405/msg00087.html). First, he
implements an algorithm in a functorized style. Then, he sadly remarks
poor performance due to functors. Finally, he defunctorizes and boosts
the performance.

> Does ocamldefun deal with the recursive modules of 3.07?

The current version (v1.11) of ocamldefun only works with ocaml 3.06 and
so it doesn't deal with recursive modules. A version of ocamldefun dealing
with ocaml 3.07 is on my TODO list.

> MLton began as an SML defunctorizer if I'm not mistaken, but has evolved
> into a whole program optimizing compiler.

You're not mistaken :-). See http://www.mlton.org/history.html.

Cheers,
Julien
-- 
mailto:Julien.Signoles@lri.fr ; http://www.lri.fr/~signoles
"In theory, practice and theory are the same,
but in practice they are different" (Larry McVoy)

-------------------
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

Re: [Caml-list] Functors

[brogoff]

On Thu, 6 May 2004, Julien Signoles wrote:
> > In any case, the absence of a defunctorization step means that we often
> > have a choice between performance and a functorized programming style, which
> > stinks.
>
> I don't think you have a stinking choice.

> My opinion is: always choose a
> functorized programming style and, if this style significantly reduces
> performance, then use a defunctorizer like ocamldefun. For example, see
> the Jean-Christophe Filliâtre's contribution to this thread
> (http://caml.inria.fr/archives/200405/msg00087.html).

JCF said he manually defunctorized. I'd prefer not to have to butcher my code
to achieve performance, and I'd rather have the compiler do it, if it can.
If ocamldefun can do the work, then I'd rather that there is a compiler switch
to call it transparently rather than have to add more gunk to my makefiles.
Of course, if ocamldefun can do it, modifying one of the existing build
systems to add a defunctorization pass is also an option.

> > MLton began as an SML defunctorizer if I'm not mistaken, but has evolved
> > into a whole program optimizing compiler.
>
> You're not mistaken :-). See http://www.mlton.org/history.html.

So, are you planning to evolve ocamldefun into a whole program optimizing
OCaml compiler? :-)

-- Brian

-------------------
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

Re: [Caml-list] Functors

[David Brown]

On Sun, May 02, 2004 at 06:24:15PM +0800, Martin Jambon wrote:

> With my words: I understand functors as a way to parametrize a type with a
> value.
> They allow you to detect inconsistencies at compile time (e.g. 2 sets
> parametrized with different "compare" functions).
> Without functors, as far as I know, you can only test inconsistencies at
> run time (e.g. by putting all the parameters in a record an check physical
> equality of the records).

Unless the compare function is only an argument of the set creation
routine, and the value is part of the set itself.  There might be
performance issues with an extra field, though.

Dave

-------------------
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