Nicolas Cannasse wrote:
>I've read all the comments about MutableList modules, and several important
>points have been raised.
>Thanks to all people who have replied !
>- yes, MList was intended as a additionnal module
>- of course, for end users, a fully documented module will be released
>- in the documentation, we can put some note about implementation, saying
>that MList.t = list ref ( this clarify most of the questions )
IMHO this is like an invitation to tinkering! X)
(This paragraph is rather like (*my*) "philosophy of using modules to
implement ADTs", and *not* my view of how should things that go into the
extlib be packaged). IMO, the whole purpose of making signatures
evident, then characterising structures in terms of the complexity of
the operations/functions, is to make the data abstract yet let users
have a feeling about their performance... Telling the core of the
implementation (the main data type for the ADT) is adding information
that is *not needed* to use the type, and I would *vote against* it. (It
is very handy, though if the user wants to improve the code... In which
case he will probably go down to the source itself, however).
>- yes using labels for "copy" make sense
>- map_list : ('a -> 'b) -> 'a t -> 'b list is approved
>- shuffle simply do shuffle the list in-place. ( that's a random sort, so it
>is O(n²) )
>About Complexity, I think this has of course be part of the documentation :
>- copy and copy-list are O(1)
>- length is O(n)
>- set and remove_at_index are O(n)
OK. About all the above.
>About Exceptions, let me disagree with the current standard library model.
>Of couse, for many functions not-so-much-used a Failure "msg" is a very good
>way of raising an exception. But when you're using data structures such as
>lists, catching an exception is a very common way of handling different
>cases, so exception cannot be seen anymore as an error message, but as a
>possible kind of return value, so has to have a named constructor.
>most of the time when using the stdlib I end up using pattern matching to
>catch only one kind of failure :
> let h = List.hd l in
> < do something with it >
> Failure "hd" ->
> < handle it >
>Imagine that List.find would raise Failure "find" instead of Not_found...
>That wouldn't be nice... Why ? because we catch Not_found many times, that's
>why a separate constructor has been created. I don't really interstand
>caml-team Failure usage in the stdlib because it's so "old-style" and
>"weakly-typed" ( you can for example make a syntax error in the error
>message... ). For me, Failure exceptions are the one which are designed to
>be raised up to the toplevel... and printed. When you have an exception
>which is worth catching, you have to define a constructor. And several
>constructors are making your code much easier to debug.
I entirely agree with you... Yet my concern is that because the code we
include in the ext-lib uses *a different* convention for the semantics
attached to the use of extensions, the OCaml team may have a harder
time when deciding whether to include them or not in the stdlib. But
then, maybe we can "suggest" them what a nice thing would be to start
including more meaningful exceptions into the stdlib!
BTW, if I were an active OCaml implementor, I'd be "eavesdropping" into
this list so see how things went around here... So although the list's
recipients are "non-disclosed", and I don't remember any of them
answering to the list, I guess they are in fact following the progress
of this thing just in case... Can I "cry to the void" and ask if anybody
from the implementor's list is around just to be aware of it?