[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
eternal.
> 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
- Non-stack-copying call-with-current-continuation?, David Kastrup, 2012/03/01
- Re: Non-stack-copying call-with-current-continuation?, Noah Lavine, 2012/03/01
- Re: Non-stack-copying call-with-current-continuation?, David Kastrup, 2012/03/01
- Re: Non-stack-copying call-with-current-continuation?, Noah Lavine, 2012/03/01
- Re: Non-stack-copying call-with-current-continuation?, David Kastrup, 2012/03/01
- Re: Non-stack-copying call-with-current-continuation?, Noah Lavine, 2012/03/01
- Re: Non-stack-copying call-with-current-continuation?, David Kastrup, 2012/03/02
- Re: Non-stack-copying call-with-current-continuation?, Andreas Rottmann, 2012/03/03
- Re: Non-stack-copying call-with-current-continuation?, Andreas Rottmann, 2012/03/03
- Re: Non-stack-copying call-with-current-continuation?, Andy Wingo, 2012/03/03
- Re: Non-stack-copying call-with-current-continuation?,
David Kastrup <=
- Re: Non-stack-copying call-with-current-continuation?, Andy Wingo, 2012/03/04
- Re: Non-stack-copying call-with-current-continuation?, David Kastrup, 2012/03/04
- Re: Non-stack-copying call-with-current-continuation?, Andy Wingo, 2012/03/04
- Re: Non-stack-copying call-with-current-continuation?, Mark H Weaver, 2012/03/04
- Re: Non-stack-copying call-with-current-continuation?, David Kastrup, 2012/03/04
- Re: Non-stack-copying call-with-current-continuation?, Mark H Weaver, 2012/03/04
- Re: Non-stack-copying call-with-current-continuation?, David Kastrup, 2012/03/04
Re: Non-stack-copying call-with-current-continuation?, Nala Ginrut, 2012/03/01
Re: Non-stack-copying call-with-current-continuation?, Andy Wingo, 2012/03/03