Version française
Home     About     Download     Resources     Contact us    
Browse thread
stl?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Brian Hurt <bhurt@s...>
Subject: Re: [Caml-list] stl?


On Wed, 4 Mar 2009, Yoann Padioleau wrote:

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

Especially in the realm of data structure libraries (like the STL), I 
really question the utility of this.  Data structures vary wildly in the 
performance characteristics of their various operations.  For example, 
accessing a arbitrary element of a map is O(log N), doing so in a list is 
O(N).  But accessing the first element of a map is O(log N) in a map, but 
O(1) in a list.  So if I write my algorithm to always only need the first 
element of the sequence, but never need an arbitrary element, then 
replacing a list with a map is a real bad idea- and I don't need to 
perform actual comparisons to tell this.

Where this does come up is when what you're really doing is refactoring 
code.  Say I originally thought that I was only going to need the first 
element, but it turns out that I'm doing a lot more arbitrary accesses 
than original thought.  In this case, however, you're not just swapping 
this data structure out for that one, you're also changing more or less 
large chunks of the code to reflect the new assumptions.

Ocaml's huge advantage here then is not functors, or objects, or even type 
variables- it's just strong static typing.  This allows you to change 
things and just see where things break.

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

Humorously enough, I'm doing exactly this.  In a bunch of code I'm playing 
with, I've implemented an NeList module- nothing fancy, just a few dozen 
lines of code and the basic list operations, only the lists can not be 
empty.  They always have to contain at least one element.

But seriously, you hate functors that much?  The overhead of doing:

module StringMap = Map.Make(String);;

is so high to you, that you simply don't do it?

Mind if I ask why?

Brian