"ocaml_beginners"::[] Returning a pair (bool, maybe_value)

> > how exceptions can avoid this "performance hit of allocation" ?

>; He is just referring to the allocation "cost" of creating and storing
> the option type (and whatever else may be getting created along with
> it)... by skipping over the code entirely with the exception, this is
> avoided. Which means it will not be pressuring the runtime into a GC
> as soon - usually a good thing. ;)

Thanks Robert for the explanation,

That seems a bit difficult for me ! I see it remains a lot of work
before I begin to consider what could be the amount of load my code
impose on the GC.

Regards,

Fabrice

Messages in this topic (0) Reply (via web post) | Start a new topic

.

Thanks William !

>; > OK : Exceptions are good.
> Don't let Brian Hurt hear you say that...
I do read some other list too...

> Seriously, you should make sure exceptions are what you want to use
> when you use them, they don't behave like variants, so if you're not
> sure what you're doing they may produce unexpected results.
It would be interesting to see such an example of exception misusing
that could fall into this warning.

> and the extra atom_list function
I only wrote extra "atom_list" function to improve clarity.

> type form = Atom of char
>; | Compound of form list
>;
> let rec string_of_form = function
> | Atom a -> let a' = String.make 2 '`' in a'.[1] <- a; a'
> | Compound [] -> "()&quot;
> | Compound l -> "(&quot;^String.concat " " (List.map string_of_form l)^")"
&gt;
> let nil = Compound []
> let f1 = Atom 'a'
> let f2 = Atom 'b'
> let f3 = Compound [f1; f2; Atom '*']
>; let f4 = Compound [nil; f1; Compound [f2]; f3; Compound [f3]]
&gt;
> let _ = Printf.printf "%sn&quot; (string_of_form f4)

It doesn't do the job because pure char lists have a special print :
(() `a b ab* (ab*))
instead of :
(() `a (`b) (`a `b `*) ((`a `b `*)))

The idea is to have a language that let use strings without owning
a special type for them. So a "string" will be parsed into a char list
and any char list will be printed as a string. Language computations
do not know anything about strings.
( With my few OCaml knowledges that however increase with the valuable
advices I get on this list, I'll begin to rewrite my "didah" :
http://didah.sourceforge.net/
http://sourceforge.net/project/screenshots.php?group_id=178762
)

Regards

Fabrice

Messages in this topic (0) Reply (via web post) | Start a new topic

.

On Mon, Jun 11, 2007 at 08:33:16AM +0200, Fabrice Marchant wrote:
&gt; > > how exceptions can avoid this "performance hit of allocation" ?
>
> > He is just referring to the allocation "cost" of creating and storing
> > the option type (and whatever else may be getting created along with
> > it)... by skipping over the code entirely with the exception, this is
> > avoided. Which means it will not be pressuring the runtime into a GC
> > as soon - usually a good thing. ;)
>
> Thanks Robert for the explanation,
>
> That seems a bit difficult for me ! I see it remains a lot of work
>; before I begin to consider what could be the amount of load my code
>; impose on the GC.

I wouldn't worry about the above on ocaml_beginners ...

However it is worth noting that there is a kind of duality between
("Option") returning 'a option and ("Exception";) returning value or
throwing exception.

If you consider the standard function List.find. At the moment it
does "Exception". User code can convert it to "Option" by doing:

let r = try Some (List.find x xs) with Not_found -> None

where r will have the 'a option type.

If you imagine there was another find function called List.find_opt
which did "Option", then you could convert that to "Exception" by
doing:

let r = match List.find_opt x xs with None -> raise Not_found | Some r -> r

In both cases the conversion code is a one-liner. So it sounds like
you can just leave it up to the caller to do the conversion, right?

Not entirely.

There is some danger to using "Exception": the caller might forget to
catch the exception. This often results in the exception escaping the
program and causing the whole program to fail. In OCaml < 3.10 you
just get a cryptic message without even a stack trace, and believe me
- these are hard to debug.

With "Option" on the other hand, the caller is forced to deal with the
None case.[*]

Rich.

[*] Well, they can cheat by using Option.get from Extlib, but that's
not good programming practice.

--
Richard Jones
Red Hat

Messages in this topic (0) Reply (via web post) | Start a new topic

.

On Mon, 11 Jun 2007 10:34:05 +0100
Richard Jones < rich%40annexia.org">richannexia.org> wrote:

> On Mon, Jun 11, 2007 at 08:33:16AM +0200, Fabrice Marchant wrote:
&gt; > > > how exceptions can avoid this "performance hit of allocation" ?
> >
> > > He is just referring to the allocation "cost" of creating and storing
> > > the option type (and whatever else may be getting created along with
> > > it)... by skipping over the code entirely with the exception, this is
> > > avoided. Which means it will not be pressuring the runtime into a GC
> > > as soon - usually a good thing. ;)
> >
> > Thanks Robert for the explanation,
> >
> > That seems a bit difficult for me ! I see it remains a lot of work
>; > before I begin to consider what could be the amount of load my code
>; > impose on the GC.
>
> I wouldn't worry about the above on ocaml_beginners ...
>
> However it is worth noting that there is a kind of duality between
> ("Option") returning 'a option and ("Exception";) returning value or
> throwing exception.
>
> If you consider the standard function List.find. At the moment it
> does "Exception". User code can convert it to "Option" by doing:
&gt;
> let r = try Some (List.find x xs) with Not_found -> None
>;
> where r will have the 'a option type.
&gt;
> If you imagine there was another find function called List.find_opt
> which did "Option", then you could convert that to "Exception" by
> doing:
&gt;
> let r = match List.find_opt x xs with None -> raise Not_found | Some r -> r
>
> In both cases the conversion code is a one-liner. So it sounds like
>; you can just leave it up to the caller to do the conversion, right?
&gt;
> Not entirely.
>
> There is some danger to using "Exception": the caller might forget to
> catch the exception. This often results in the exception escaping the
> program and causing the whole program to fail. In OCaml < 3.10 you
> just get a cryptic message without even a stack trace, and believe me
> - these are hard to debug.
&gt;
> With "Option" on the other hand, the caller is forced to deal with the
> None case.[*]
>
> Rich.
&gt;
> [*] Well, they can cheat by using Option.get from Extlib, but that's
&gt; not good programming practice.
>
> --
> Richard Jones
&gt; Red Hat

Thanks Rich for your always clear explanations that cover here all I tried to understand !

Messages in this topic (0) Reply (via web post) | Start a new topic

.