caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: kirillkh <kirillkh@gmail.com>
To: oleg@pobox.com
Cc: caml-list@inria.fr
Subject: Re: Locally-polymorphic exceptions [was: folding over a file]
Date: Wed, 3 Oct 2007 13:27:48 +0200	[thread overview]
Message-ID: <e2d02be30710030427j20592efbjcfc495cf5ab3b747@mail.gmail.com> (raw)
In-Reply-To: <20071003083529.40DA2A99F@Adric.metnet.fnmoc.navy.mil>

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

Hi Oleg,

This looks excellent! I am especially delighted with the fact you don't have
to declare this single-use exception in the global scope anymore.
Could you be more specific regarding the continuations' performance impact?
Would it matter in practice? Would you recommend using this function in a
general-purpose library instead of the imperative-style implementation that
was suggested?

Also, is there a good manual on delimited continuations for a beginner with
minimum of external references? I have tried to read your papers, but it's
hard to advance because some of the complex stuff is explained elsewhere.

-Kirill

2007/10/3, oleg@pobox.com <oleg@pobox.com>:
>
>
> kirillkh wrote
> > Is there a way to instantiate an exception with a value of unspecified
> type
> > and then do explicit casting on catch?
>
> Surprisingly, the answer in many (or all?) cases is yes. The answer is
> definitely yes in the case when we need to define an exception local
> to a polymorphic function. Incidentally, SML permits declarations of
> such local exceptions whose type is tied to that of the host
> polymorphic function. That feature has been used to implement
> delimited continuations. Perhaps unsurprisingly, delimited
> continuations can be used to implement such locally-polymorphic
> exceptions.
>
> The recent thread gave a good motivation for locally polymorphic
> exceptions: writing a library function fold_file. The following code
> has been proposed.
>
> > exception Done of 'a
> >
> >  let fold_file (file: in_channel)
> >               (read_func: in_channel->'a)
> >               (elem_func: 'a->'b->'b)
> >               (seed: 'b) =
> >   let rec loop prev_val =
> >     let input =
> >       try read_func file
> >       with End_of_file -> raise (Done prev_val)
> >     in
> >       let combined_val = elem_func input prev_val in
> >       loop combined_val
> >   in
> >     try loop seed with Done x -> x
>
> Alas, the compiler does not accept the exception declaration, because
> the declaration says that the exception should carry a value of all
> types. There is no value that belongs to all types (and if it were, it
> wouldn't be useful). But we don't actually need the value of all
> types. We need the value of our Done exception to have the same type
> as the result of the polymorphic function fold_file. We should have
> declared the exception Done _inside_ fold_file. And that can be done:
> Delimcc.prompt is precisely this type of `local exceptions'.
>
> So, we can implement fold_file, by slightly adjusting the above code:
>
> let fold_file (file: in_channel)
>               (read_func: in_channel->'a)
>               (elem_func: 'a->'b->'b)
>               (seed: 'b) =
>   let result = new_prompt () in (* here is our local exn declaration *)
>   let rec loop prev_val =
>      let input =
>        try read_func file
>        with End_of_file -> abort result prev_val
>      in
>        let combined_val = elem_func input prev_val in
>        loop combined_val
>    in
>      push_prompt result (fun () -> loop seed)
> ;;
>
> (*
> val fold_file :
>   in_channel -> (in_channel -> 'a) -> ('a -> 'b -> 'b) -> 'b -> 'b = <fun>
> *)
>
> let line_count filename =
>    let f = open_in filename in
>    let counter _ count = count + 1 in
>    fold_file f input_line counter 0;;
>
> (*
> val line_count : string -> int = <fun>
> *)
>
> let test = line_count "/etc/motd";;
> (*
> val test : int = 24
> *)
>
>
> The analogy between exceptions and delimited continuations is
> profound: in fact, delimited continuations are implemented in terms of
> exceptions. Abort is truly raise. Well, observationally. The current
> delimcc library tried to follow Dybvig, Sabry and Peyton-Jones
> interface -- which, being minimalistic, did not include abort as a
> primitive. We have to implement abort in terms of take_subcont, which
> is wasteful as we save the captured continuation for no good
> reason. Internally, the library does have an abort primitive, and it
> indeed works in the same way as raise.
>
>

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

  reply	other threads:[~2007-10-03 11:28 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-03  8:35 oleg
2007-10-03 11:27 ` kirillkh [this message]
2007-10-03 11:48   ` [Caml-list] " Daniel de Rauglaudre
2007-10-03 12:19     ` kirillkh
2007-10-03 12:32       ` Daniel de Rauglaudre
2007-10-03 14:34         ` kirillkh
2007-10-03 20:39   ` Christophe Raffalli
2007-10-03 22:50     ` Unsoundness is essential skaller
2007-10-03 23:13       ` [Caml-list] " Jacques Carette
2007-10-04  1:24         ` skaller
2007-10-04 11:26           ` David Allsopp
2007-10-04 12:45             ` Vincent Hanquez
2007-10-04 15:07               ` skaller
2007-10-03 23:13       ` Vincent Aravantinos
2007-10-04  1:49         ` skaller
2007-10-03 23:28       ` Joshua D. Guttman
2007-10-04  1:52         ` skaller
2007-10-04  2:35           ` Brian Hurt
2007-10-04  7:46           ` Christophe Raffalli
2007-10-04  8:56             ` Arnaud Spiwack
2007-10-04 14:49               ` skaller
2007-10-04 15:00                 ` Harrison, John R
2007-10-04 15:29                 ` Andrej Bauer
2007-10-04 16:25                   ` skaller
2007-10-04 18:17                     ` Arnaud Spiwack
2007-10-04 20:54                       ` skaller
2007-10-04 22:24                         ` Arnaud Spiwack
2007-10-04 16:37                   ` skaller
2007-10-04 18:59                     ` Christophe Raffalli
2007-10-04 15:04               ` Andrej Bauer
2007-10-04 15:57                 ` Christophe Raffalli
2007-10-04 16:03                 ` skaller
2007-10-04 20:02                   ` Ken Rose
2007-10-04 21:00                     ` skaller
2007-10-04 15:31       ` Lukasz Stafiniak
2007-10-04 17:56       ` rossberg
2007-10-04 19:56         ` skaller
2007-10-04 21:07           ` rossberg
2007-10-04 22:23             ` skaller
2007-10-05  2:48               ` Bárður Árantsson
2007-10-04  2:16   ` Locally-polymorphic exceptions [was: folding over a file] oleg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e2d02be30710030427j20592efbjcfc495cf5ab3b747@mail.gmail.com \
    --to=kirillkh@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=oleg@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).