Browse thread
stl?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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