[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Non-stack-copying call-with-current-continuation?

From: David Kastrup
Subject: Re: Non-stack-copying call-with-current-continuation?
Date: Sun, 04 Mar 2012 13:01:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Andy Wingo <address@hidden> writes:

> On Fri 02 Mar 2012 02:35, David Kastrup <address@hidden> writes:
>> Sure, but things like gensym and make-prompt-tag (and (list '()) for
>> creating an eq?-unique object) are artificial hygiene coming at a cost
>> in symbol table and symbol generation time rather than "lexical"
>> hygiene.
> "Hygiene" is not right the word here.  "Hygiene" applies lexically --
> statically.  You want a continuation that only works within a certain
> dynamic extent -- that's dynamic.  Unique objects are well-suited to the
> needs of dynamic problems.

The problem is not a unique object (you get one with every (list 0)
call), the problem is a unique symbol.  Of course an escape continuation
works only in a dynamic context.  But that does not mean that its
identity needs to be represented by a globally persisting symbol.  The
global symbol space is a different identity space than heap equality,
and it never gets garbage collected: the lifetime of a gensym is

> But really, your concerns are entirely misplaced.  Choose clean,
> clear, optimizable abstractions.  Call/ec is a good example.  If you
> need to implement it, do so using whatever tools are at hand.  If you
> can't implement it or it's slow, then bring these concerns forward.
> But to dismiss Noah's suggestions out of hand is inappropriate at this
> time.

I am not dismissing his suggestions.  I am saying that I find call/ec a
nicer primitive than catch/throw exactly because it does not need a name
or symbol to work but has its identity and life-time coupled to an
object rather than a symbol.

And frankly: the manual talks about prompts being composable and gives
an example which seems utterly wrong to me since it does not actually
abort a computation but rather half-finishes it.  It is unclear what
part of the computation will finish and what will complete.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]