Browse thread
How to do this properly with OCaml?
-
Thomas Fischbacher
- Christophe Dehlinger
- Berke Durak
- Michel Quercia
- Eric Cooper
-
Michael Alexander Hamburg
-
Xavier Leroy
- Berke Durak
- Michael Alexander Hamburg
- Thomas Fischbacher
- Alex Baretta
- skaller
- Thomas Fischbacher
-
Xavier Leroy
[
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: | Brian Hurt <bhurt@s...> |
| Subject: | Re: [Caml-list] How to do this properly with OCaml? |
On Mon, 25 Jul 2005, skaller wrote: > On Sun, 2005-07-24 at 12:14 -0700, Stephane Glondu wrote: >> On Sunday 24 July 2005 11:48, skaller wrote: >>>> I strongly disagree. Look at source code of buffer.ml: no Obj.magic. >>>> What do you mean by "efficiently"? >>> >>> Buffer only works for characters. >> >> You can make it work for any datatype by using an 'a array option instead >> of a string. > > That fails to be 'efficient'. Would you use > > char array option > > instead of the existing Buffer??? The problem is that there is no one perfect structure. bool array is incredibly inefficient- it's much better to use a bitfield. Etc. As for having a dynamic (resizable) array as a standard library, I think I disagree with this idea. A standard applicative tree-based array, maybe. But a dynamic array, like a mutable doubly linked list, encourages imperitive programming- when I think imperitive programming should be *discouraged*. There are reasons, and time, when imperitive programming is necessary. But I think they are few and far between- much rarer than people suppose. But imperitive semantics impose implicit coupling- when you pass a mutable data structure to a subroutine there is an implicit contract between the caller and callee- either to modify in a known way or to not modify the value at all. This increases coupling and leads to maintainance problems. Brian