On Mon, 2011-05-09 at 23:56 +0200, Andy Wingo wrote:
> On Mon 09 May 2011 20:34, Jeronimo Pellegrini <j_p@aleph0.info> writes:
>
> > A minimalistic language would have continuations but not exceptions
>
> Bad example, IMO; can you even implement exceptions robustly in terms of
> continuations?  As long as your program itself does not use
> continuations, right?

Although continuations and exceptions have a common underlying principle
(non-local control transfer), they are used differently by programmers.
They have different idioms, and I think that the idiom of control
transfer is wrong for exceptions. I consider exceptions more closely
related to simple type dispatch.

When optimizing type dispatch, it is not uncommon to think of a function
as having several "entry points.¨  That is, you can issue an
assembly-language JMP to  different addresses for, say, integer addition
as opposed to inexact addition as opposed to mixed addition or addition
using runtime type tags that you couldn't statically analyze.

The same optimization can be applied to function returns.  When the
function is finished, it may return to a different point, depending on
whether it is returning an integer, or a float, etc.  This saves
type dispatch at the return site, just as the optimization on the call
can save type dispatch in the function. (I can write a white paper on
how a compiler keeps track of different call/return points for a
potentially unbounded number of type signatures, if anybody's
interested).

The interesting part of the "multiple return point" view of the world
is that even in non-tail-recursive functions, some return types can be
optimized away as tail calls.  This happens because the continuation
that handles, say, integers, may be in a different function than the
continuation that handles, say, floats.

Now, here is my point with this.  The programmer's model of "exceptions"
more closely resembles returning a value of an error type, and doing
implicit type dispatch at the return sites, than it resembles a
deliberate non-local transfer of control. In the "multiple return
points" view of the world, the return of a value of type "error" results
in a tail call directly to the handler, because the intervening call
frames do nothing with the value before dispatching back to their own
callers.

Exceptions, IMO, should be regarded and modeled as a species of type
dispatch on return, not as a species of control flow alteration. I
know, type dispatch *is* control flow alteration, but it's a particular
paradigm or idiom of it that doesn't much intersect with more
"interesting" uses of continuations.

				Bear

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports