ocaml-lib-devel

[Ocaml-lib-devel] Exceptions and Complexity

[Nicolas C. <war...@fr...>]

Hi,

I've read all the comments about MutableList modules, and several importa=
nt
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 =3D list ref ( this clarify most of the questions )
- 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=B2) )

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)

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 g=
ood
way of raising an exception. But when you're using data structures such a=
s
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 =3D 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, tha=
t'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 t=
o
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.

Nicolas Cannasse

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

[Michal M. <mal...@pl...>]

On Thu, Feb 27, 2003 at 12:06:27PM +0900, 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 )

So maybe you could extend Stack module? New module with overlapping
functionality probably isn't going to be added to OCaml stdlib.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

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

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

[Nicolas C. <war...@fr...>]

> 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!

As said before, I doubt that the extlib will be one day integrated into the
OCaml Stdlib... so I would prefer to have the "le's create another StdLib
with more functions" as goal for the ExtLib.

> 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?

There is, there is.
Maxence, although not a member of the "Great Ocaml Fathers", is working at
INRIA and as been writting several great tools, ocamldoc among all (
although I dislike the usage of classes :-P )

Nicolas Cannasse