[Caml-list] assertions or exceptions?

[Caml-list] assertions or exceptions?

[Radu Grigore]

Hello,

First of all let me warn you that I am a beginner when it comes to
OCaml: I have experience in programming with other languages (C++), I
have read about OCaml, but I have only written about 1000 lines of
OCaml code, and only two "programs" were actually useful.

The purpose of this mail is to gather opinions on when should
assertions be used and when exceptions should be used.

I have noticed that the standard libraries use exceptions heavily.
This feels strange to me because I prefer to use assertions whenever
possible.

There are other libraries, notably Java API and .NET class library,
that use exceptions liberaly. But they don't bother me that much
because they try to give you the option of not relying on them
throwing exceptions. Whenever possible they provide functions that
check parameters and return a boolean. In [6] an example is given:
"whenever a FileNotFind exception might be thrown by method A, there
should be a method B that checks for this and returns a boolean".
However in OCaml I don't know how to tell if I've reached the end of a
file without using exceptions.

But why is a boolean better than an exception? Because it makes code
simpler. Exceptions can be left uncaught and this is a potential cause
for a combinatorial explosion of the number of possible "execution
paths" (tricky notion in a functional language, I know. For example
Herb Sutter in [5] identifies 23 execution paths in a 4-line C++
program because of exceptions! This kind of complexity makes it hard
to reason about the correctness of a program and is one of the reasons
that made Dijkstra say goto is generally a bad idea [2]. This doesn't
mean that it is _always_ a bad idea.

There is an OCaml programming guidelines document [3] that say that
_assertions_ (not exceptions -- my note) should be used to check
preconditions. There is also a tutorial on assertions from Sun [1]
that finally gives some hints on when to use assertions and when
exceptions: assertions should be used for preconditions of private
methods and other internal invariants (including postconditions),
while exceptions should be used only for checking preconditions of
non-private methods. But I think the reason given for using exceptions
is weak: we need to honor a contract that includes exceptions. So, we
need to use exceptions because we said at some point in time that we
will use exceptions. Not a very good argument. What's more Herb Sutter
argues here [4] that a contract that includes exceptions is actually
not that good in practice.

So, now a few questions:
1. Is my impression that OCaml standard library is abusing exceptions correct?
2. Is it safe to assume that exceptions complicate functional programs
as much as they complicate imperative ones?
3. Is it possible to avoid using exceptions and read a text file
line-by-line until EOF?
4. When do you use assertions and when do you use exceptions?

regards,
 radu

[1] http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
[2] http://www.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/EWD117.html
[3] http://pauillac.inria.fr/caml/FAQ/pgl-eng.html
[4] http://www.gotw.ca/gotw/082.htm
[5] http://www.gotw.ca/gotw/020.htm
[6] http://tinyurl.com/2opdo

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] assertions or exceptions?

[Richard Jones]

On Thu, Jul 15, 2004 at 11:03:24AM +0300, Radu Grigore wrote:
> So, now a few questions:
> 1. Is my impression that OCaml standard library is abusing
> exceptions correct?

There's always a conflict between raising a Not_found exception and
returning an 'a option result.  Example (from mod_caml).  Should the
function which returns the hostname field from the request_rec
structure be prototyped as:

Apache.Request.hostname : Apache.Request.t -> string
  # could throw Not_found if the C string is NULL.

or:

Apache.Request.hostname : Apache.Request.t -> string option
  # returns Some string, or None if the C string is NULL

In fact, I chose the former (throwing Not_found exception)
consistently throughout mod_caml.

The reason is that returning 'a option forces you to deal with the
'None' case every time you use (eg). Apache.Request.hostname.  But in
many cases, the underlying C fields being NULL is an internal error
for which we are not prepared, and the only sensible thing to do then
is not to force people to deal with it locally, but to throw an
exception which causes the whole script/program to fail.

However in some cases the right thing to do would be to return 'a
option, precisely *because* you require the programmer to deal with
the error locally.

> 2. Is it safe to assume that exceptions complicate functional
> programs as much as they complicate imperative ones?

Perhaps in theory, but in practice they work just fine.

> 3. Is it possible to avoid using exceptions and read a text file
> line-by-line until EOF?

There are functions in ExtLib to do this, I think.  If not then you
should write a function like 'input_all_lines' or 'iter_over_lines f'
once, put it into a small local library, and use it every time.  No
point reinventing wheels each time.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
'There is a joke about American engineers and French engineers. The
American team brings a prototype to the French team. The French team's
response is: "Well, it works fine in practice; but how will it hold up
in theory?"'

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] assertions or exceptions?

[Daniel Andor]

> > 3. Is it possible to avoid using exceptions and read a text file
> > line-by-line until EOF?
>
> There are functions in ExtLib to do this, I think. 

http://ocaml-lib.sourceforge.net/doc/Std.html

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] assertions or exceptions?

[Jon Harrop]

> There are other libraries, notably Java API and .NET class library,
> that use exceptions liberaly...

OCaml and the programming styles when used in OCaml are quite different to 
those of Java and most .NET languages (F# being a notable exception ;-). In 
OCaml, you often write in a functional style, when performing many similar 
operations this naturally lends itself to recursive functions. When running, 
a deeply recursed function may suddenly find a shortcut to the correct 
answer. Exceptions provide an ideal means to escape such deep recursions. The 
alternative, e.g. using polymorphic options, are typically considerably less 
efficient, either in terms of speed of execution or in terms of extra source 
code.

This is particularly true in the context of polymorphic higher-order 
functions, as the following example (hopefully!) shows.

> But why is a boolean better than an exception? Because it makes code
> simpler.

Convert the following code (which finds the product of a bunch of integers) 
into an equivalent which avoids exceptions but retains the efficiency of 
being able to bail earlier, upon encountering a zero:

exception Zero

let prod fold l =
  try fold (fun a e -> if e=0 then raise Zero else a*e) 1 l
  with Zero -> 0

> Exceptions can be left uncaught and this is a potential cause 
> for a combinatorial explosion of the number of possible "execution
> paths"...

I would say it was poor style to allow the possible number of execution paths 
to explode.

> 1. Is my impression that OCaml standard library is abusing exceptions
> correct?

No, it is based upon valid arguments for imperative languages which are not 
applicable here.

> 2. Is it safe to assume that exceptions complicate functional 
> programs as much as they complicate imperative ones?

As the above example shows, exceptions can be used to simplify code.

> 3. Is it possible to avoid using exceptions and read a text file
> line-by-line until EOF?

Yes (see other people's posts).

> 4. When do you use assertions and when do you use exceptions?

I use assertions to perform sanity checks. I use exceptions in two separate 
sitations: firstly to handle exceptional circumstances, secondly to provide 
an escape route from computations.

Cheers,
Jon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] assertions or exceptions?

[Radu Grigore]

On Thu, 15 Jul 2004 11:18:26 +0100, Richard Jones <rich@annexia.org> wrote:
> [...]  But in
> many cases, the underlying C fields being NULL is an internal error
> for which we are not prepared, and the only sensible thing to do then
> is not to force people to deal with it locally, but to throw an
> exception which causes the whole script/program to fail.

You say that the only sensible thing to do is for the program to fail.
But that's what assertions (not exceptions) are for. So why don't you
assert when the C string is NULL? I see couple of reasons: (1) without
knowing the client code you can't be sure it's an internal error and
(2) you want to give the client a chance to fail gracefully (ie. save
any state that might be useful to the user, inform the user, etc.).

The first reason does not hold for internal/private functions, ie.
those functions that have clients which are under your control. Would
you use an assertion for such a function? Or you never use assertions?

Note that in your example there is always a third choice (the one
advocated by .NET class library design guidelines): do what you do but
also provide a function

   Request.valid_hostname : Request.t -> bool

You might argue that the end result is the same for the client. With
your solution a client that does not expect a failure does not write a
try block, while one that knows it's OK to fail from time to time will
use a try block. The problem is that you force the client to use an
exception in circumstances that are _not_ exceptional from his point
of view. So giving him the option of saying "if valid_hostname then I
don't expect this to fail" is a plus. See:

http://blogs.msdn.com/cyrusn/archive/2004/06/16/156865.aspx

for another discussion along these lines.

BTW, I think that the solution you have chosen in this case is the
right one. I'm just trying to find some guidelines, which work most of
the time, of when to use an exception versus an assertion. The best
I've found so far is the advice from Sun to use exceptions for
checking preconditions of public methods and assertions everywhere
else. I'd go one step further and say that exceptions should be used
only in the public interface of a component (which is not the same as
a class -- especially for a language like OCaml :) ).

You said nothing about assertions. You don't use them?

> > 3. Is it possible to avoid using exceptions and read a text file
> > line-by-line until EOF?
> 
> There are functions in ExtLib to do this, I think.  If not then you
> should write a function like 'input_all_lines' or 'iter_over_lines f'
> once, put it into a small local library, and use it every time.  No
> point reinventing wheels each time.

Ok, so I can hide the usage of the exception. It doesn't make me feel
much better. It feels more like redesigning the interface of the
standard library. (but it's a good idea nonetheless).

regards,
 radu

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] assertions or exceptions?

[Richard Jones]

On Thu, Jul 15, 2004 at 03:49:19PM +0300, Radu Grigore wrote:
> Note that in your example there is always a third choice (the one
> advocated by .NET class library design guidelines): do what you do but
> also provide a function
> 
>    Request.valid_hostname : Request.t -> bool

I feel I might be responding to a troll here.  It seems to me to be a
little obvious that you haven't done much programming OCaml, or else
you wouldn't be asking this question.  There's an ocaml-beginners list
if you'd like to find out more about developing with OCaml.
Nevertheless ...

let valid_hostname r =
  try ignore (Request.hostname r); true with Not_found -> false

Or, if Request.hostname had been defined the other way, then:

let valid_hostname r =
   match Request.hostname r with None -> false | Some _ -> true

In practice you'd never actually write the "valid_hostname" function
explicitly, because it's so trivial to inline the code when you need
it.

> Ok, so I can hide the usage of the exception. It doesn't make me feel
> much better. It feels more like redesigning the interface of the
> standard library. (but it's a good idea nonetheless).

I happen to think that the End_of_file stuff in stdlib *is* quite
clunky.  However since my main usage of files is "open file; read
entire contents into list of lines; close file", or "open file; write
this list of lines; close file", and I now have my own functions which
do both those operations in a single call, it doesn't bother me much.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles,
RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] assertions or exceptions?

[Radu Grigore]

On Thu, 15 Jul 2004 13:35:22 +0100, Jon Harrop
<postmaster@jdh30.plus.com> wrote:

> [...] In
> OCaml, you often write in a functional style, when performing many similar
> operations this naturally lends itself to recursive functions. When running,
> a deeply recursed function may suddenly find a shortcut to the correct
> answer. Exceptions provide an ideal means to escape such deep recursions. 

This is an interesting idea. I'll try to spot such situations while coding!

> Convert the following code (which finds the product of a bunch of integers)
> into an equivalent which avoids exceptions but retains the efficiency of
> being able to bail earlier, upon encountering a zero:
> 
> exception Zero
> 
> let prod fold l =
>   try fold (fun a e -> if e=0 then raise Zero else a*e) 1 l
>   with Zero -> 0;;

All I can do is this:

let rec prod_fold a l = match a, l with
  | 0, _ -> 0
  | a, [] -> a
  | a, h :: t -> prod_fold (a * h) t

Differences between these are:
1. Yours makes an exception visible to other functions that do not use it
2. Yours is 80 non-ws characters long, mine is 71 characters long; so
they are comparable.
3. Mine is less flexible: it does not allow plugging in a fold
function. However I don't see where such a thing would be useful. An
example?
4. I assert that mine is easier to understand. (at least for me :) )
One reason is that it doesn't use exceptions: only a simple recursive
function.
5. I see no reason why performance would be significantly different.

> > Exceptions can be left uncaught and this is a potential cause
> > for a combinatorial explosion of the number of possible "execution
> > paths"...
> 
> I would say it was poor style to allow the possible number of execution paths
> to explode.

You can use goto and keep the number of execution paths from exploding
too. This doesn't mean that it is not a dangerous tool and that you
should be careful while using it. The same applies to exceptions.

> As the above example shows, exceptions can be used to simplify code.

I'm not convinced.

> > 3. Is it possible to avoid using exceptions and read a text file
> > line-by-line until EOF?
> 
> Yes (see other people's posts).

Those solutions are:
 1. use another library
 2. provide your own workaround (by redesigning the interface)
I fail to see how this vindicates the design of the standard library.

> > 4. When do you use assertions and when do you use exceptions?
> 
> I use assertions to perform sanity checks.

You mean internal invariants? That is, including postconditions but
not preconditions?

> I use exceptions in two separate
> sitations: firstly to handle exceptional circumstances,

Tautologies do not contain a lot of information ;-) When is something
exceptional? When it shouldn't happen but you know what to do if it
does happen? If you remove the "but you know what to do.." part then
you are better of using an assertion.

> secondly to provide an escape route from computations.

As I said, this is an interesting idea but I really need to see it in
practice in order to understand it.

regards, 
 radu

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] assertions or exceptions?

[Radu Grigore]

On Thu, 15 Jul 2004 14:33:59 +0100, Richard Jones <rich@annexia.org> wrote:

> let valid_hostname r =
>   try ignore (Request.hostname r); true with Not_found -> false

Maybe Request.hostname is a bad example. In general you can provide a
query that is more efficient than actually trying to do it. The
example to which I linked in the previous email was about an OpenFile
method that can throw FileNotFound paired with FileExists that returns
a boolean. I'd bet FileExists is not implemented in terms of OpenFile.

I'll stop here since I'm a troll :-P

regards,
 radu

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] assertions or exceptions?

[Jon Harrop]

> Differences between these are:

Mine is generic over all data structures which provide a fold function or can 
have a fold function implemented over them. Yours only works on the humble 
list. ;-)

Cheers,
Jon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] assertions or exceptions?

[Radu Grigore]

On Thu, 15 Jul 2004 15:33:05 +0100, Jon Harrop
<postmaster@jdh30.plus.com> wrote:

> > Differences between these are:
> 
> Mine is generic over all data structures which provide a fold function or can
> have a fold function implemented over them. Yours only works on the humble
> list. ;-)

That's why I said "all I can do is.." and not "here is a better
solution" :) Yours is clearly better. I think that one of the
important characteristics of your code is that it uses exceptions in a
localized way that makes it hard to introduce bugs: Zero is used only
in two lines. For this reason I think it would have been better if you
could have declared the exception Zero in the scope of the function
prod. I wouldn't want the fold function to catch it!

Another characteristic is the one you already pointed out to: you can
alter the behaviour of a higher order function in a way that simple
functions (ie. without exceptions) do not provide. This is why I can't
think of any generic solution to your puzzle that doesn't use
exceptions (without imposing additional restrictions on the fold
function, such as using int option instead of int -- which is
inefficient and ugly).

This is the kind of patterns I was looking for when I wrote the
original message. Thanks again. It seems however that my style that
was meant to be provoking by slightly playing the devil's advocate was
considered insulting by some members of the list. I apologize.

regards,
 radu

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Unboxing options, was RE: assertions or exceptions?

[Brian Hurt]

One of the problems with returning error conditions instead of throwing 
exceptions is the cost of boxing a 'a option.  I'd like to advocate for 
the idea of unboxing 'a options.

The idea works like this: None, rather than being represented internally 
as an integer value, would instead be an invalid pointer- either the NULL 
pointer or a pointer to a specially allocated object in a memory space 
that is never collected.  But the key idea is that None is a value that 
can never be a valid variable value.  Once that is the case, we don't need 
to box Some 'a, we can unbox it.

I can see two disadvantages with this proposal.  The first is that it 
breaks backwards compatibility.  Code compiled to work the new way won't 
work with code compiled to work the old way.  C code would have to be 
changed (although the difference would be pretty easy to manage with some 
preprocessor work).  The second problem is that Some(None) isn't 
representable- that'd just be None.

Thoughts?

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] assertions or exceptions?

[skaller]

On Thu, 2004-07-15 at 23:45, Radu Grigore wrote:

> Those solutions are:
>  1. use another library
>  2. provide your own workaround (by redesigning the interface)
> I fail to see how this vindicates the design of the standard library.

I believe there is a good argument for using exceptions
in the standard library. It goes like this:

There are situation where a function call can fail.
Perhaps here an exception is not as good as a sum type.

But there are other situations where it can be proven
a function call cannot fail. In these circumstances,
using exceptions leads to simpler and more efficient
code: the downside is you have to manually maintain
the proof that an exception can't be thrown in the
face of the changes software always goes through.

In balance, it is probably fairly arbitrary which
mechanism to present the client.

Ocaml is reasonably consistent though, and that
is probably what matters most. 

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[John Hughes]

I'd like to suggest that this isn't really a problem. 
The key is the idea of "exception", which is that it's
an *exception* to what ordinarily happens. The same goes
for errors -- they should be exceptional. As such, making the
code associated with these things more efficient (as opposed
to more readable, maintainable, whatever else) should be WAAAY
down on your priority list. 

--John Hughes 

> -----Original Message-----
> From: owner-caml-list@pauillac.inria.fr 
> [mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of Brian Hurt
> Sent: Thursday, July 15, 2004 5:38 PM
> To: Ocaml Mailing List
> Subject: [Caml-list] Unboxing options, was RE: assertions or 
> exceptions?
> 
> 
> One of the problems with returning error conditions instead 
> of throwing exceptions is the cost of boxing a 'a option.  
> I'd like to advocate for the idea of unboxing 'a options.
> 
> The idea works like this: None, rather than being represented 
> internally as an integer value, would instead be an invalid 
> pointer- either the NULL pointer or a pointer to a specially 
> allocated object in a memory space that is never collected.  
> But the key idea is that None is a value that can never be a 
> valid variable value.  Once that is the case, we don't need 
> to box Some 'a, we can unbox it.
> 
> I can see two disadvantages with this proposal.  The first is 
> that it breaks backwards compatibility.  Code compiled to 
> work the new way won't work with code compiled to work the 
> old way.  C code would have to be changed (although the 
> difference would be pretty easy to manage with some 
> preprocessor work).  The second problem is that Some(None) isn't
> representable- that'd just be None.
> 
> Thoughts?
> 
> --
> "Usenet is like a herd of performing elephants with diarrhea 
> -- massive, difficult to redirect, awe-inspiring, 
> entertaining, and a source of mind-boggling amounts of 
> excrement when you least expect it."
>                                 - Gene Spafford Brian
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: 
> http://caml.inria.fr Bug reports: 
> http://caml.inria.fr/bin/caml-bugs FAQ: 
> http://caml.inria.fr/FAQ/ Beginner's list: 
> http://groups.yahoo.com/group/ocaml_beginners
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[Brian Hurt]

On Thu, 15 Jul 2004, John Hughes wrote:

> I'd like to suggest that this isn't really a problem. 
> The key is the idea of "exception", which is that it's
> an *exception* to what ordinarily happens. The same goes
> for errors -- they should be exceptional. As such, making the
> code associated with these things more efficient (as opposed
> to more readable, maintainable, whatever else) should be WAAAY
> down on your priority list. 

There are a lot of places where the question isn't exceptions vr.s
options, where options are the only choice (optional arguments, for one).  
And some times exceptions are less exceptional than they might otherwise
be- when you're reading all the lines from a file, hitting the end of file
sooner or later is expected.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[John Prevost]

On Thu, 15 Jul 2004 10:38:14 -0500 (CDT), Brian Hurt <bhurt@spnz.org> wrote:
> One of the problems with returning error conditions instead of throwing
> exceptions is the cost of boxing a 'a option.  I'd like to advocate for
> the idea of unboxing 'a options.

This has been discussed before.  The essential problem is this:

Currently:

type 'a option is not the same as type 'a option option
Some Some 1 is not the same as Some 1
Some None is not the same as None

With unboxed options:

type 'a option is the same as type 'a option option
Some Some 1 is identical to Some 1
Some None is identical to None

John.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[Radu Grigore]

On Thu, 15 Jul 2004 13:20:00 -0400, John Prevost <j.prevost@gmail.com> wrote:

> This has been discussed before.  The essential problem is this:
> 
> Currently:
> type 'a option is not the same as type 'a option option [...]
> 
> With unboxed options:
> type 'a option is the same as type 'a option option [...]

Heh.. This is an inconsistency in the current C# 2.0 spec :) (see
nullable types) By inconsistency I mean that it is not clear what is
the intended behaviour.

regards,
 radu

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[John Carr]

> > One of the problems with returning error conditions instead of throwing
> > exceptions is the cost of boxing a 'a option.  I'd like to advocate for
> > the idea of unboxing 'a options.
> 
> This has been discussed before.  The essential problem is this:
> 
> Currently:
> 
> type 'a option is not the same as type 'a option option
> Some Some 1 is not the same as Some 1
> Some None is not the same as None
> 
> With unboxed options:
> 
> type 'a option is the same as type 'a option option
> Some Some 1 is identical to Some 1
> Some None is identical to None

So use true 0 as opposed to the integer 0 internally represented as 1
to mean "None".  This adds some complexity but may be worth the effort
as options are common.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[Brian Hurt]

On Thu, 15 Jul 2004, John Carr wrote:

> > type 'a option is the same as type 'a option option
> > Some Some 1 is identical to Some 1
> > Some None is identical to None
> 
> So use true 0 as opposed to the integer 0 internally represented as 1
> to mean "None".  This adds some complexity but may be worth the effort
> as options are common.

What's the representation of Some(None) then?  The Some() goes away, and 
the containing value is unboxed- it turns out to be the same as just None.  
There is no way to differentiate Some(Some(Some(Some(None)))) from None.

Which I mentioned in my original post.

I can see three ways around this.  First, just change the behavior, 
probably adding a switch into the compiler to issue a warning whenever it 
sees a type of the form 'a option option.  This would be under the 
assumption that very little code actually does options of options (I don't 
think I've seen any- not to say it doesn't exist, just to say it's not 
common).  Second possibility, have the compiler detect when it's doing an 
option of an option, and forcibly insert boxing at that point.  Third 
possibility: create a new type, 'a nullable, that has this as the defined 
behavior.

I've seen designs contort themselves in an attempt to avoid the overhead 
of boxing options- starting with enums in ExtLib.  This is an overhead 
which doesn't have to exist, and we should at least consider eliminating 
it.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[John Carr]

[None represented internally as 0]

> What's the representation of Some(None) then?  The Some() goes away, and 
> the containing value is unboxed- it turns out to be the same as just None.  
> There is no way to differentiate Some(Some(Some(Some(None)))) from None.

There is also no way to distinguish 0 from None in the current
system.  OCaml relies on type information to determine the meaning
of a value.

Is there valid code (no Obj.magic) that cares that (Some None) and
(None) are both represented by the same bit pattern?

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[John Prevost]

On Thu, 15 Jul 2004 15:56:19 -0400, John Carr <jfc@mit.edu> wrote:
> > type 'a option is the same as type 'a option option
> > Some Some 1 is identical to Some 1
> > Some None is identical to None
> 
> So use true 0 as opposed to the integer 0 internally represented as 1
> to mean "None".  This adds some complexity but may be worth the effort
> as options are common.

That doesn't actually help.  How do you distinguish the value Some
None from None?  Are you suggesting Some None would be integer 0, and
None would be pointer NULL?  Then what about an int option option
option?  Yes, it's a little silly, but it's a reasonable concern.

I agree that having options be supported unboxed would be kind of
nice, but I'm not sure it's worth the effort involved.

Just did some searching around and managed to find the old discussion
that I was involved in: 
http://pauillac.inria.fr/caml/caml-list/1834.html  I don't see a clear
"no" in the discussion there.  But perhaps browsing around that thread
can show you a bit about this can of worms.

John.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[John Prevost]

On Thu, 15 Jul 2004 16:49:49 -0400, John Carr <jfc@mit.edu> wrote:
> Is there valid code (no Obj.magic) that cares that (Some None) and
> (None) are both represented by the same bit pattern?

module A =
  struct
    type t = string option
    let default = ref ""
    let set_default x = default := x
    let get_default = !default
    let create x = Some x
    let create_default () = None
    let get_value = function Some x -> x | None -> !default
  end : sig
    type t
    val set_default : string -> unit
    val get_default : unit -> string
    val create : string -> t
    val create_default : unit -> t
    val get_value : t -> string
  end

(* this comes from somewhere else... perhaps it reads a configuration
   file, and uses None if the value isn't available, and Some
(A.get_default ()) if
   it's a specific value meaning "the current default value". *)
val get_attribute : string -> A.t option

...
    match get_attribute "pants" with
      | Some x -> (* called when the value was in the file *)
      | None -> (* called when either the value wasn't in the file
*or* it's the default,
                   represented as Some None *)

In this case, the user of the module A doesn't even know that type t
is represented using an option type underneath--the user just knows
that the value could either be the default
value or a specific value.  The writer of A could of course choose to
make his own special type:

type t = Default | Value of string

But it's rather silly to say that "if you think someone might put your
type into an option, you should probably make your own different type
which is identical to option but doesn't do magic behind the scenes."

John.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[Karl Zilles]

John Carr wrote:

> [None represented internally as 0]
> 
> 
>>What's the representation of Some(None) then?  The Some() goes away, and 
>>the containing value is unboxed- it turns out to be the same as just None.  
>>There is no way to differentiate Some(Some(Some(Some(None)))) from None.
> 
> 
> There is also no way to distinguish 0 from None in the current
> system.  OCaml relies on type information to determine the meaning
> of a value.

0 and None are different types.  There is no need to distinguish them.

> 
> Is there valid code (no Obj.magic) that cares that (Some None) and
> (None) are both represented by the same bit pattern?

(Some None) and (None) are both the same type: a' option option

Valid code:

match x with
| Some a -> printf "Some!"
| None -> printf "None!"

(Some None) should print Some!, (None) should print None!, but since the 
bit patterns are now the same...



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[skaller]

On Fri, 2004-07-16 at 03:20, John Prevost wrote:
> On Thu, 15 Jul 2004 10:38:14 -0500 (CDT), Brian Hurt <bhurt@spnz.org> wrote:
> > One of the problems with returning error conditions instead of throwing
> > exceptions is the cost of boxing a 'a option.  I'd like to advocate for
> > the idea of unboxing 'a options.
> 
> This has been discussed before.  The essential problem is this:
> 
> Currently:
> 
> type 'a option is not the same as type 'a option option
> Some Some 1 is not the same as Some 1
> Some None is not the same as None
> 
> With unboxed options:
> 
> type 'a option is the same as type 'a option option
> Some Some 1 is identical to Some 1
> Some None is identical to None

This is wrong. The representation being suggested is:

None -> NULL
Some 'a -> pointer to 'a

Clearly this represntation is faithful and nothing
more than an interpretation of the corresponding C 
concept.

Some Some 1 is obviously distinct from Some 1 as reqiuired:
pointer to pointer to 1 is distinct from pointer to 1.
Some None is a pointer to NULL, which is distinct from 
None which is just NULL.

Perhaps this won't work with the Ocaml runtime but
there is no problem with the typing.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[Brian Hurt]

On Thu, 15 Jul 2004, John Carr wrote:

> There is also no way to distinguish 0 from None in the current
> system.  OCaml relies on type information to determine the meaning
> of a value.

Yes, but in Some(0), the 0 is boxed (because of the Some)- so Some(0) is 
different from None.  I trust the type checker to make sure I can't have 0 
and None in the same variable, just like I trust the type checker to make 
sure I can't have 0 and false in the same variable.

> 
> Is there valid code (no Obj.magic) that cares that (Some None) and
> (None) are both represented by the same bit pattern?

let foo = function
    | None -> 0
    | Some(None) -> 1
    | Some(Some(_)) -> 2
;;

Now, wether you would actually see code like that in the "real world" is a 
different argument.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[Brian Hurt]

On 16 Jul 2004, skaller wrote:

> This is wrong. The representation being suggested is:
> 
> None -> NULL
> Some 'a -> pointer to 'a

No.  Actually, I was suggesting:

None -> NULL
Some 'a -> 'a

which does have this problem.  None isn't the problem- it's a constant in 
both cases.  The problem is the Some case- Some(1) needs to allocate a 
word of memory to hold the 1 in.

By the way, ignore my suggestion that the Ocaml compiler stick in a layer 
of referencing.  You can have a 'a option option without the compiler 
knowing that it's an option option- consider the following bit of code:

let unwrap = function
    | None -> invalid_arg "unwrap"
    | Some x -> x
;;

Or:

let pick deflt = function
    | None -> deflt
    | Some x -> x
;;

Having both boxed and unboxed options would make these functions 
impossible to compile.

So the two options are:

1) Change the existing behavior (possibly with a warning)

2) Introduce a new type

Which actually means I'm leaning towards the new type option.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[skaller]

On Fri, 2004-07-16 at 07:17, skaller wrote:

I should rephrase this:

> This is wrong. The representation being suggested is:
> 
> None -> NULL
> Some 'a -> pointer to 'a
> 
> Clearly this represntation is faithful and nothing
> more than an interpretation of the corresponding C 
> concept.
> 
> Some Some 1 is obviously distinct from Some 1 as reqiuired:
> pointer to pointer to 1 is distinct from pointer to 1.
> Some None is a pointer to NULL, which is distinct from 
> None which is just NULL.

What I'm saying is that the idea is not unboxing,
but untagging. Some 'a isn't a pointer to an 'a heap
value, but a pointer to a CAML_VALUE which is a pointer
to a heap value 'a. I don't see how the GC could
support this in Ocaml, since Some 'a isn't a CAML_VALUE
since it points to a box, not a heap object -- 
but in Felix it would work because the GC uses 
RTTI to locate pointers.

So the idea is fine, but won't work with Ocaml GC.
There's be no saving dereferencing a Some value here.
The saving would be that simply loading the value
into a register would set a condition code in the
processor, avoiding any need to check the value
of a tag word.

Ugg .. sorry for the confusion :(

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[skaller]

On Fri, 2004-07-16 at 07:35, Brian Hurt wrote:
> On 16 Jul 2004, skaller wrote:
> 
> > This is wrong. The representation being suggested is:
> > 
> > None -> NULL
> > Some 'a -> pointer to 'a
> 
> No.  Actually, I was suggesting:
> 
> None -> NULL
> Some 'a -> 'a

Ok .. sorry



-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[Jacques GARRIGUE]

From: John Prevost <j.prevost@gmail.com>

> On Thu, 15 Jul 2004 10:38:14 -0500 (CDT), Brian Hurt <bhurt@spnz.org> wrote:
> > One of the problems with returning error conditions instead of throwing
> > exceptions is the cost of boxing a 'a option.  I'd like to advocate for
> > the idea of unboxing 'a options.
> 
> This has been discussed before.  The essential problem is this:
> 
> Currently:
> 
> type 'a option is not the same as type 'a option option
> Some Some 1 is not the same as Some 1
> Some None is not the same as None
> 
> With unboxed options:
> 
> type 'a option is the same as type 'a option option
> Some Some 1 is identical to Some 1
> Some None is identical to None

I answer before the discussion goes hairy (it already has.)

We know perfectly how to unbox options. This is described for instance
in my paper with Jun Furuse on optional arguments.
  http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/rims-1041.html

The idea is just to reserve a sufficiently large memory area to
represent every needed (Some (Some ...(Some None) ...)).
You don't even need to access this area (it might not be physically
mapped.)
Then all values of type (t option) are represented either by a pointer
to this area, or by the wrapped value itself (if it is not an option.)

I believe Xavier implemented this trick once, but this has some small
cost for both wrapping and unwrapping (you must check whether the
value is a pointer to this area), so that there is no clear
advantage compared to allocating a block for each Some. Keep in mind
that most options are short-lived, so they will be allocated in the
young generation, and disappear with the next GC. Such a pattern has a
very low cost: just check the allocation limit once in a while. And of
course there is no cost for the None case.

Conclusion: this is not worth bothering about, and optional
implemented in the current way are efficient enough, thank you.

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[John Prevost]

On Fri, 16 Jul 2004 09:35:17 +0900 (JST), Jacques GARRIGUE
<garrigue@kurims.kyoto-u.ac.jp> wrote:
> The idea is just to reserve a sufficiently large memory area to
> represent every needed (Some (Some ...(Some None) ...)).

Apologies for keeping the conversation going, but since I just thought of this:

Caml's internal pointers are at minimum 4-byte aligned.  What about
using the other "safe" set of trailing bits, "10", to mark options? 
i.e.:

None = ...0010 (2)
Some None =  ...0110 (6)
Some Some None = ...1010 (10)
Some Some Some None = ...1110 (14)

and so on?  This would remove the need to use a special memory area
(or check that area) for wrapping and unwrapping.  There'd still be a
cost, but I would think it should be smaller than the cost you
describe?

That said, I also don't think this is a critical issue.

John.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[Jacques GARRIGUE]

From: John Prevost <j.prevost@gmail.com>

> Apologies for keeping the conversation going, but since I just thought of this:
> 
> Caml's internal pointers are at minimum 4-byte aligned.  What about
> using the other "safe" set of trailing bits, "10", to mark options? 
> i.e.:
> 
> None = ...0010 (2)
> Some None =  ...0110 (6)
> Some Some None = ...1010 (10)
> Some Some Some None = ...1110 (14)
> 
> and so on?  This would remove the need to use a special memory area
> (or check that area) for wrapping and unwrapping.  There'd still be a
> cost, but I would think it should be smaller than the cost you
> describe?
> 
> That said, I also don't think this is a critical issue.

Now that you tell it, Xavier's idea (and implementation) was actually
along this line.
The trouble is that it doesn't change the cost: you just do an and on
the lower bits rather than on the higher ones.
Might be worth retrying some day, as hardware is changing, but I don't
expect any real change.

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[Xavier Leroy]

> > The idea is just to reserve a sufficiently large memory area to
> > represent every needed (Some (Some ...(Some None) ...)).
> 
> Apologies for keeping the conversation going, but since I just
> thought of this:
> Caml's internal pointers are at minimum 4-byte aligned.  What about
> using the other "safe" set of trailing bits, "10", to mark options? 
> i.e.:
> None = ...0010 (2)
> Some None =  ...0110 (6)

This is very tempting indeed, but the Caml heap compactor already uses 
the ...10 encoding to temporarily mark some data during compaction.

As Jacques said, we've toyed with the idea of encoding option types
specially for quite a while, and even prototyped it at some point, but
never got convinced that it was really important to do so.

Someone asked whether "option option" types occur in "real life".
One occurrence was sighted in the sources of an old version of Coq.
I haven't checked if it is still there.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] assertions or exceptions?

[Aleksey Nogin]

On 15.07.2004 06:58, Radu Grigore wrote:

>>let valid_hostname r =
>>  try ignore (Request.hostname r); true with Not_found -> false
> 
> 
> Maybe Request.hostname is a bad example. In general you can provide a
> query that is more efficient than actually trying to do it. The
> example to which I linked in the previous email was about an OpenFile
> method that can throw FileNotFound paired with FileExists that returns
> a boolean. I'd bet FileExists is not implemented in terms of OpenFile.

Actually your FileExists/OpenFile case is a perfect example of why you 
need exceptions anyway - even if you test a file with FileExists, by the 
time you invoke OpenFile, the file might be already gone! So unless you 
want to open yourself to race conditions, the only safe way is to go 
ahead and use OpenFile, catching any exceptions it could raise.

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] assertions or exceptions?

[John Prevost]

> Actually your FileExists/OpenFile case is a perfect example of
> why you need exceptions anyway - even if you test a file with
> FileExists, by the time you invoke OpenFile, the file might be
> already gone! So unless you want to open yourself to race
> conditions, the only safe way is to go ahead and use OpenFile,
> catching any exceptions it could raise.

That's definitely a good example of a place where exceptions are
needed.  My general rule of thumb is "If it's a normal expected
result, it should not be an exception.  If it's an actual failure
mode, it should be an exception."  An example of one place in the
OCaml standard libraries where I get irked is with various container
data-structures where searching for an item raises "Not_found" when
the item is not in the structure.  From my point of view, not finding
something is very much expected behavior.

On the other side, I do understand why using exceptions for this case
might be desirable for the implementation.  And on the super
double-plus good side, it's not like making wrapper functions to
switch from one choice to the other is difficult.  In fact, with one
wrapper you can convert almost all Not_found type exceptions in the
standard library to options:

val find_wrap : ('a -> 'b -> 'c) -> 'a -> 'b -> 'c option
let find_wrap f a b =
  try Some (f a b) with Not_found -> None

Not all "search" type functions in the standard library take arguments
in the same order, but pretty much all of them take two arguments: the
data structure to search in, and something describing what to find. 
So the above ought to work for all three of List.assoc ('a -> ('a *
'b) list -> 'b), List.find (('a -> bool) -> 'a list -> 'a), and
Hashtbl.find (('a, 'b) Hashtbl.t -> 'a -> 'b).

John.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] assertions or exceptions?

[David MENTRE]

John Prevost <j.prevost@gmail.com> writes:

> An example of one place in the OCaml standard libraries where I get
> irked is with various container data-structures where searching for an
> item raises "Not_found" when the item is not in the structure.  From
> my point of view, not finding something is very much expected
> behavior.

Please notice that in that very specific case you have the "mem"
function (e.g. Hashtbl.mem) that gives you the opportunity to check for
the element if you expect it missing.

Yours,
d.
-- 
 David Mentré <dmentre@linux-france.org>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unboxing options, was RE: assertions or exceptions?

[Damien Doligez]

On Jul 16, 2004, at 18:40, Xavier Leroy wrote:

>>> The idea is just to reserve a sufficiently large memory area to
>>> represent every needed (Some (Some ...(Some None) ...)).
>>
>> Caml's internal pointers are at minimum 4-byte aligned.  What about
>> using the other "safe" set of trailing bits, "10", to mark options?
>> i.e.:
>> None = ...0010 (2)
>> Some None =  ...0110 (6)
>
> This is very tempting indeed, but the Caml heap compactor already uses
> the ...10 encoding to temporarily mark some data during compaction.

Unless I am badly mistaken, the compactor already has to deal with
such values (as out-of-heap pointers) and has no problem with them.

However, this is almost the same as Jacques' description, because
you still have to make sure that these special values point to some
area of memory where nothing will ever be allocated.

Finally, Jacques was not quite right in asserting that most options
are short-lived.  This is only true if you don't use "option" in your
main long-lived data structure.  Most seasoned OCaml programmers know
it, and sometimes it leads to rather contorted data structures.

> As Jacques said, we've toyed with the idea of encoding option types
> specially for quite a while, and even prototyped it at some point, but
> never got convinced that it was really important to do so.

It is still bothering me, at least.

-- Damien

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners