Re: [Ocaml-lib-devel] Exceptions and Complexity

[fva <fv...@ts...>]

Nicolas Cannasse wrote:

>Hi,
>
>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 :
>
>try
>    let h = List.hd l in
>    < do something with it >
>with
>    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?

Regards,

        Fran Valverde