[Caml-list] Proposal: extend try to handle success

[Caml-list] Proposal: extend try to handle success

[Jeremy Yallop]

The recent thread about the representation of options highlighted a
shortcoming in the "try" construct: there isn't a convenient way to
express code that should run when the body of the "try" doesn't raise
an exception.

I'd like to propose extending OCaml with a design once suggested by
Christophe Raffalli which elegantly handles this case.  The details,
along with an implementation that you can try out, are in the
following blog post:

    http://ocamllabs.github.io/compiler-hacking/2014/02/04/handler-case.html

Feedback welcome!

Jeremy

Re: [Caml-list] Proposal: extend try to handle success

[Simon Cruanes]

[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]

Le Tue, 04 Feb 2014, Jeremy Yallop a écrit :

> The recent thread about the representation of options highlighted a
> shortcoming in the "try" construct: there isn't a convenient way to
> express code that should run when the body of the "try" doesn't raise
> an exception.
> 
> I'd like to propose extending OCaml with a design once suggested by
> Christophe Raffalli which elegantly handles this case.  The details,
> along with an implementation that you can try out, are in the
> following blog post:
> 
>     http://ocamllabs.github.io/compiler-hacking/2014/02/04/handler-case.html
> 
> Feedback welcome!

This is very nice and detailed, but I'm not sure to follow how this is
supposed to help in some cases you mention. Namely, the

match (try Some (foo) with End_of_foo -> None) with
    | Some x -> a
    | None -> b

transformation is used to preserve tail-call. Would the new

try foo with
    | End_of_foo -> b
    | val x -> a

present the same behavior w.r.t tail-call? If the answer is yes, then I
find it very interesting :)

-- 
Simon

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [Caml-list] Proposal: extend try to handle success

[Jeremy Yallop]

On 4 February 2014 17:14, Simon Cruanes <simon.cruanes.2007@m4x.org> wrote:
> Le Tue, 04 Feb 2014, Jeremy Yallop a écrit :
>> I'd like to propose extending OCaml with a design once suggested by
>> Christophe Raffalli which elegantly handles this case.  The details,
>> along with an implementation that you can try out, are in the
>> following blog post:
>>
>>     http://ocamllabs.github.io/compiler-hacking/2014/02/04/handler-case.html
>>
>> Feedback welcome!
>
> This is very nice and detailed, but I'm not sure to follow how this is
> supposed to help in some cases you mention. Namely, the
>
> match (try Some (foo) with End_of_foo -> None) with
>     | Some x -> a
>     | None -> b
>
> transformation is used to preserve tail-call. Would the new
>
> try foo with
>     | End_of_foo -> b
>     | val x -> a
>
> present the same behavior w.r.t tail-call?

Yes, 'a' is in tail position in both snippets.

> If the answer is yes, then I find it very interesting :)

Re: [Caml-list] Proposal: extend try to handle success

[Gabriel Scherer]

This proposal lifts my only (and surprisingly blocking) reservation
with "let-try", namely the fact that I have no idea which of "let-try
<decl> in <expr> with <handler>" or "let-try <decl> with <handler> in
<expr>" is the right syntax in the general case. With this proposal,
value-return-handlers and exception-handlers can be ordered at will by
the user.

(Thank you for mentioning the relation to the effect-handler work. I
distinctly remember having the realization that this syntax would
solve our problem in a discussion with you, Sam Lindley and Ohad
Kammar after their HOPE talk in Copenhagen. Could this research
improve OCaml as a... side-effect?)


On Tue, Feb 4, 2014 at 7:09 PM, Jeremy Yallop <yallop@gmail.com> wrote:
> On 4 February 2014 17:14, Simon Cruanes <simon.cruanes.2007@m4x.org> wrote:
>> Le Tue, 04 Feb 2014, Jeremy Yallop a écrit :
>>> I'd like to propose extending OCaml with a design once suggested by
>>> Christophe Raffalli which elegantly handles this case.  The details,
>>> along with an implementation that you can try out, are in the
>>> following blog post:
>>>
>>>     http://ocamllabs.github.io/compiler-hacking/2014/02/04/handler-case.html
>>>
>>> Feedback welcome!
>>
>> This is very nice and detailed, but I'm not sure to follow how this is
>> supposed to help in some cases you mention. Namely, the
>>
>> match (try Some (foo) with End_of_foo -> None) with
>>     | Some x -> a
>>     | None -> b
>>
>> transformation is used to preserve tail-call. Would the new
>>
>> try foo with
>>     | End_of_foo -> b
>>     | val x -> a
>>
>> present the same behavior w.r.t tail-call?
>
> Yes, 'a' is in tail position in both snippets.
>
>> If the answer is yes, then I find it very interesting :)
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Proposal: extend try to handle success

[Markus Mottl]

Nice!  I've always hated the "option"-workaround required to maintain
tail-recursion with exception handlers.  The required syntax change
seems quite benign, too, and the feature might improve performance a
bit, assuming the code generator has a special case for it rather than
internally rewriting the code to use the "option"-workaround.  Doesn't
sound difficult to do either.

Regards,
Markus

On Tue, Feb 4, 2014 at 12:00 PM, Jeremy Yallop <yallop@gmail.com> wrote:
> The recent thread about the representation of options highlighted a
> shortcoming in the "try" construct: there isn't a convenient way to
> express code that should run when the body of the "try" doesn't raise
> an exception.
>
> I'd like to propose extending OCaml with a design once suggested by
> Christophe Raffalli which elegantly handles this case.  The details,
> along with an implementation that you can try out, are in the
> following blog post:
>
>     http://ocamllabs.github.io/compiler-hacking/2014/02/04/handler-case.html
>
> Feedback welcome!
>
> Jeremy
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs



-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com

Re: [Caml-list] Proposal: extend try to handle success

[Markus Mottl]

Btw., I also agree with the postscript on the symmetric extension to
"match".  I think it would improve code clarity if developers could
use "try" to indicate that they expect an exception as a means of
control flow, whereas "exception"-branches in "match" clauses would be
more suitable for truly exceptional (as in "error") conditions.

On Tue, Feb 4, 2014 at 2:18 PM, Markus Mottl <markus.mottl@gmail.com> wrote:
> Nice!  I've always hated the "option"-workaround required to maintain
> tail-recursion with exception handlers.  The required syntax change
> seems quite benign, too, and the feature might improve performance a
> bit, assuming the code generator has a special case for it rather than
> internally rewriting the code to use the "option"-workaround.  Doesn't
> sound difficult to do either.
>
> Regards,
> Markus
>
> On Tue, Feb 4, 2014 at 12:00 PM, Jeremy Yallop <yallop@gmail.com> wrote:
>> The recent thread about the representation of options highlighted a
>> shortcoming in the "try" construct: there isn't a convenient way to
>> express code that should run when the body of the "try" doesn't raise
>> an exception.
>>
>> I'd like to propose extending OCaml with a design once suggested by
>> Christophe Raffalli which elegantly handles this case.  The details,
>> along with an implementation that you can try out, are in the
>> following blog post:
>>
>>     http://ocamllabs.github.io/compiler-hacking/2014/02/04/handler-case.html
>>
>> Feedback welcome!
>>
>> Jeremy
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>
>
> --
> Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com



-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com

Re: [Caml-list] Proposal: extend try to handle success

[Yaron Minsky]

On Tue, Feb 4, 2014 at 2:29 PM, Markus Mottl <markus.mottl@gmail.com> wrote:
> Btw., I also agree with the postscript on the symmetric extension to
> "match".  I think it would improve code clarity if developers could
> use "try" to indicate that they expect an exception as a means of
> control flow, whereas "exception"-branches in "match" clauses would be
> more suitable for truly exceptional (as in "error") conditions.

I very much agree!  I find the symmetry between try and match to be
quite elegant.  Overall, this seems like a great proposal.

y


> On Tue, Feb 4, 2014 at 2:18 PM, Markus Mottl <markus.mottl@gmail.com> wrote:
>> Nice!  I've always hated the "option"-workaround required to maintain
>> tail-recursion with exception handlers.  The required syntax change
>> seems quite benign, too, and the feature might improve performance a
>> bit, assuming the code generator has a special case for it rather than
>> internally rewriting the code to use the "option"-workaround.  Doesn't
>> sound difficult to do either.
>>
>> Regards,
>> Markus
>>
>> On Tue, Feb 4, 2014 at 12:00 PM, Jeremy Yallop <yallop@gmail.com> wrote:
>>> The recent thread about the representation of options highlighted a
>>> shortcoming in the "try" construct: there isn't a convenient way to
>>> express code that should run when the body of the "try" doesn't raise
>>> an exception.
>>>
>>> I'd like to propose extending OCaml with a design once suggested by
>>> Christophe Raffalli which elegantly handles this case.  The details,
>>> along with an implementation that you can try out, are in the
>>> following blog post:
>>>
>>>     http://ocamllabs.github.io/compiler-hacking/2014/02/04/handler-case.html
>>>
>>> Feedback welcome!
>>>
>>> Jeremy
>>>
>>> --
>>> Caml-list mailing list.  Subscription management and archives:
>>> https://sympa.inria.fr/sympa/arc/caml-list
>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>>
>>
>> --
>> Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com
>
>
>
> --
> Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Proposal: extend try to handle success

[Jesper Louis Andersen]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

On Tue, Feb 4, 2014 at 8:42 PM, Yaron Minsky <yminsky@janestreet.com> wrote:

> I very much agree!  I find the symmetry between try and match to be
> quite elegant.  Overall, this seems like a great proposal.
>

Erlang has had a construction like this for some years now.

try Expr of
  Pat1 -> Clause1;
  Par2 -> Clause2;
  ...
catch
  Class:Error ->
    ...
end

Of notable semantics, the exception only reaches over the scope of Expr and
not over ClauseN. In practice, I have used it quite often in Erlang-code.


-- 
J.

[-- Attachment #2: Type: text/html, Size: 1272 bytes --]

Re: [Caml-list] Proposal: extend try to handle success

[Goswin von Brederlow]

On Tue, Feb 04, 2014 at 05:00:45PM +0000, Jeremy Yallop wrote:
> The recent thread about the representation of options highlighted a
> shortcoming in the "try" construct: there isn't a convenient way to
> express code that should run when the body of the "try" doesn't raise
> an exception.

In python one can write:

    try:
        x = 1
    except Exception:
        x = 2
    else:
        x = 3
    finally:
        x = 4

The "else:" block is executed when no exception is thrown and the
"finally:" block is executed in both cases.

The "finally:" block is always executed even if an exception is thrown
that isn't caught. It is the same as adding another try block around
it, catching any exception, exectuing the block and then rethrowing
the execption.

    try:
        try:
            "0"[5] = 'x'
        finally:
            print("finally")
    except Exception as exn:
        print("Got \"{0}\"".format(exn))

gives:

finally
Got "'str' object does not support item assignment"

I guess in ocaml one would write:

    type ('a, 'b) either = Success of 'a | Failure of 'b

    let res = try Success (f x) with End_of_stream as exn -> Failure exn in
    let res =
        try
            match res with
            | Failure exn -> Printf.printf "failed\n"
            | Success x -> Printf.printf "success\n"
        with exn -> Failure exn
    in
    Printf.printf "finally\n";
    match res with
    | Failure exn -> raise exn
    | Success x -> x

Could a "finally:" be added to the try syntax in some way?
 
> I'd like to propose extending OCaml with a design once suggested by
> Christophe Raffalli which elegantly handles this case.  The details,
> along with an implementation that you can try out, are in the
> following blog post:
> 
>     http://ocamllabs.github.io/compiler-hacking/2014/02/04/handler-case.html
> 
> Feedback welcome!
> 
> Jeremy

Examples from the blog:

Exceptions can be wrapped in option types to preserve tail
recursiveness:

let rec iter_stream f s =
  match (try Some (MyStream.get s) with End_of_stream -> None) with
  | None -> ()
  | Some (x, s') ->
      f x;
      iter_stream f s'

The proposed syntax would add a new keyword to match against the
result of the try block if it throws no exception:

let rec iter_stream f s =
  try MyStream.get s
  with
  | End_of_stream -> ()
  | val (x, s') ->
      f x;
      iter_stream f s'

Isn't that the same as this?

exception Success of (char * MyStream.t)
let rec iter_stream f s =
  try raise (Success (MyStream.get s))
  with
  | End_of_stream -> ()
  | Success (x, s') ->
      f x;
      iter_stream f s'

And what does this do?

let f1 x =
  try None
  with
  | Empty -> ()
  | val Some x -> x
  | val _ -> 1

let f2 x =
  try raise Not_found
  with
  | Empty -> ()
  | val Some x -> x
  | val _ -> 1

let f3 x =
  try raise Not_found
  with
  | Empty -> ()
  | val Some x -> x
  | _ -> 1

let f4 x =
  try None
  with
  | Empty -> ()
  | val Some x -> x
  | _ -> 1

My guesses:
- f1 returns 1
- f2 throws Not_found
- f3 returns 1
- f4 returns 1

How do you match any exception but not a successfull value?

let f5 x =
  try None
  with
  | Empty -> ()
  | val x -> x
  | _ -> 1

Or does "_" only match exceptions and "val _" any value?

MfG
	Goswin

Re: [Caml-list] Proposal: extend try to handle success

[Ben Millwood]

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

On 6 February 2014 10:58, Goswin von Brederlow <goswin-v-b@web.de> wrote:

> How do you match any exception but not a successfull value?
>
> let f5 x =
>   try None
>   with
>   | Empty -> ()
>   | val x -> x
>   | _ -> 1
>
> Or does "_" only match exceptions and "val _" any value?
>

Interesting.

So, I would assume that the behaviour of _ would be unchanged, so it would
match any exception and no value in a try and any value and no exception in
a match.

The way I justify this is that "val x" or "exception x" aren't really
patterns, but rather "x" is a pattern and val/exception are part of the
try/match syntax. For example, "val (val x)" would presumably be a parse
error. As such, "_" isn't a more general pattern than "val _", because
they're different kinds of thing.

This makes me wonder if the current syntax is misleadingly uniform. Perhaps
value and exception cases ought to be more clearly separated, e.g.

try (...)
with val
| Some x -> (...)
| None -> (...)
with exception
| Not_found -> (...)

[-- Attachment #2: Type: text/html, Size: 1703 bytes --]

Re: [Caml-list] Proposal: extend try to handle success

[Goswin von Brederlow]

On Thu, Feb 06, 2014 at 11:10:21AM +0000, Ben Millwood wrote:
> On 6 February 2014 10:58, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> 
> > How do you match any exception but not a successfull value?
> >
> > let f5 x =
> >   try None
> >   with
> >   | Empty -> ()
> >   | val x -> x
> >   | _ -> 1
> >
> > Or does "_" only match exceptions and "val _" any value?
> >
> 
> Interesting.
> 
> So, I would assume that the behaviour of _ would be unchanged, so it would
> match any exception and no value in a try and any value and no exception in
> a match.
> 
> The way I justify this is that "val x" or "exception x" aren't really
> patterns, but rather "x" is a pattern and val/exception are part of the
> try/match syntax. For example, "val (val x)" would presumably be a parse
> error. As such, "_" isn't a more general pattern than "val _", because
> they're different kinds of thing.
> 
> This makes me wonder if the current syntax is misleadingly uniform. Perhaps
> value and exception cases ought to be more clearly separated, e.g.
> 
> try (...)
> with val
> | Some x -> (...)
> | None -> (...)
> with exception
> | Not_found -> (...)

That would break every existing source using exceptions. Unless the
exception in "with exception" is only required when using "with val".
Maybe "with val" should better be a single keyword like

    try (...)
    val
    | Some x -> (...)
    | None -> (...)
    with
    | Not_found -> (...)

MfG
	Goswin

Re: [Caml-list] Proposal: extend try to handle success

[Ben Millwood]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

On 10 February 2014 08:47, Goswin von Brederlow <goswin-v-b@web.de> wrote:

> On Thu, Feb 06, 2014 at 11:10:21AM +0000, Ben Millwood wrote:
> > try (...)
> > with val
> > | Some x -> (...)
> > | None -> (...)
> > with exception
> > | Not_found -> (...)
>
> That would break every existing source using exceptions. Unless the
> exception in "with exception" is only required when using "with val".
>

Sure, make "exception" optional here, and correspondingly "val" optional in
match. Or your idea, that works too.

[-- Attachment #2: Type: text/html, Size: 990 bytes --]

Re: [Caml-list] Proposal: extend try to handle success

[Alain Frisch]

Other people seem to prefer a syntax which would allow (maybe in the 
future) sharing exceptional and non-exceptional cases in the same clause.

In order to keep the discussion in one place, could you (Goswin and Ben, 
in particular) summarize your proposal on the corresponding Mantis ticket?

http://caml.inria.fr/mantis/view.php?id=6318


Thanks!


Alain

Re: [Caml-list] Proposal: extend try to handle success

[Jeremy Yallop]

On 6 February 2014 10:58, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> Examples from the blog:
[...]
> let rec iter_stream f s =
>   try MyStream.get s
>   with
>   | End_of_stream -> ()
>   | val (x, s') ->
>       f x;
>       iter_stream f s'
>
> Isn't that the same as this?
>
> exception Success of (char * MyStream.t)
> let rec iter_stream f s =
>   try raise (Success (MyStream.get s))
>   with
>   | End_of_stream -> ()
>   | Success (x, s') ->
>       f x;
>       iter_stream f s'

Yes, it's essentially the same if your streams are monomorphic.
However, if MyStream.t has a type parameter then you'll need something
more like this:

  let rec iter_stream : type a. (a -> unit) -> a MyStream.t -> unit =
    fun f s ->
      let module M = struct exception Success of (a * a MyStream.t) end in
      try raise (M.Success (MyStream.get s)) with
      | End_of_stream -> ()
      | M.Success (x, s') ->
        f x;
        iter_stream f s'

The code becomes quite cluttered with irrelevant details, but things
can get even worse.  In some cases there's no way to write down the
type of the expression at all, which makes defining the exception
rather tricky.

> And what does this do?
>
> let f1 x =
>   try None
>   with
>   | Empty -> ()
>   | val Some x -> x
>   | val _ -> 1
>
> let f2 x =
>   try raise Not_found
>   with
>   | Empty -> ()
>   | val Some x -> x
>   | val _ -> 1
>
> let f3 x =
>   try raise Not_found
>   with
>   | Empty -> ()
>   | val Some x -> x
>   | _ -> 1
>
> let f4 x =
>   try None
>   with
>   | Empty -> ()
>   | val Some x -> x
>   | _ -> 1
>
> My guesses:
> - f1 returns 1
> - f2 throws Not_found
> - f3 returns 1
> - f4 returns 1

Change '()' to '0' and your first three guesses are correct.  The last
function behaves as follows:

   # #use "f4.ml";;
   File "f4.ml", line 2, characters 2-63:
   Warning 8: this pattern-matching is not exhaustive.
   Here is an example of a value that is not matched:
   None
   val f4 : 'a -> int = <fun>
   # f4 ();;
   Exception: Match_failure ("f4.ml", 2, 2).

> Or does "_" only match exceptions and "val _" any value?

Right.  The behaviour of '_' is unchanged: it matches any exception.
The pattern 'val _' matches any value.