English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-03-04 (20:11)
From: Yoann Padioleau <padator@w...>
Subject: Re: [Caml-list] stl?
Brian Hurt <bhurt@spnz.org> writes:

>>>> Functors give
>>>> you the same capability in OCaml but they are rarely used precisely because
>>>> the functionality is not very useful.
>>> I think I disagree with this.  I think functors aren't used very much
>>> in Ocaml because:
>>  0) they are intrusive! putting code inside a functor may entail the
>> need to modify also lots of related code. That's one of the worst
>> thing for a programming feature. Your modification can not be local. I
>> hate monad for the same reason, and I like ocaml exception mechanism,
>> and using sometimes global refs for the same reason.
> No.
> Here's what you can do.  Say you had an old function:
> 	let foo x = ...
> and you want to functorize it for whatever reason.  

my point is I don't want to functorize it; I want to solve
a problem, and I am looking for the fastest way to get there.
If you start with the assumption that you want to functorize
something, then indeed you will need a functor ...

> But you have lots
> of code depending upon the old type signature that you don't want to
> change. First, you functorize foo:
> 	module Make(X: Whatever) = struct let foo x = ... end;;
> Then you include the "classic foo", like:
> 	module T = Make(struct ... old defns ... end);;
> 	include T;;
> Where ... old defns ... is all the original types and functions that
> foo used that are now provided by the functor.  So you now have a
> module that exports both a "functorized" foo and a "classic" foo, and
> all the old code continues to just work (after a recompile, natch).

My goal is not being backward compatible. Of course you can
keep your old function and define new functions ... 
My goal is to evolve code, so I want to change the behavior of 'foo',
and I want to benefit from this new behavior, 
but I want this evolution to have the less collateral effects on
the structure of the rest of the program. 

For instance I got a set of functions that were working on some 'a
stuff, and I was using somewhere a naive list as a first draft. Later
I want to optimize things, and put those 'a in a more efficient
data-structure, but if use the Map data-structure, then I will be
forced to change lots of things. Argh, damned. Well, wait, I will just
use the defunctorized interface of Hashbtl :)

Again, just imagine one second that 'a list were not present in OCaml,
and that the only way you had to make a list would be to use
a functorized interface of a List module. Would you like that ? 
(that's what we are forced to do when using Map and that's why
I always use Hashtbl instead).

> This is much the same trick you use in Haskell when adding a typeclass
> dependency to the signature of a function- so long as you provide a
> typeclass instance for the old type, the old code continues to work
> with a recompile.
> I also comment, this is also a problem C++ templates have-
> templatizing a class in C++ is also an "intrusive" change.
> Brian