Re: SRFI 155 Marc Nieper-Wißkirchen (30 Sep 2017 07:39 UTC)
Re: SRFI 155 Per Bothner (30 Sep 2017 16:11 UTC)
Re: SRFI 155 Marc Nieper-Wißkirchen (30 Sep 2017 16:49 UTC)
Re: SRFI 155 Per Bothner (30 Sep 2017 17:02 UTC)

Re: SRFI 155 Per Bothner 30 Sep 2017 17:01 UTC

On 09/30/2017 09:48 AM, Marc Nieper-Wißkirchen wrote:

> Per Bothner <xxxxxx@bothner.com <mailto:xxxxxx@bothner.com>> schrieb am Sa., 30. Sep. 2017 um 18:11 Uhr:
>     Normal Kawa only supports call/cc for exits/returns.  When it isn't inlined by the compiler, it is implemented
>     by throwing a special exception.  When the exception passes through a 'parameterize' the latter's exception
>     or finally handler will revert the parameter binding.
>
>
> Do you store a copy of the parameter binding hash map or do you revert the bindings one by one.

The parameter binding hash map is internal to the core Java classes, so not directly accessible,
Parameterize (or the roughly equivalent fluid-let) work by saving the current value of a ThreadLocal,
and updating it, and then evaluating the body in a try-finally.  The finally handler restores the binding.

I could of course manage my own hashmap, but that would add some extra overhead.

> The same mechanism could be used for SRFI 154, couldn't it?

I don't see how.  The problem is 'delay' can't easily make a copy of the hashmap.
Or rather: It is expensive.  You can create a new thread (like (future <expression>) does,
as that automatically copies the threaf-locals.  The 'force' just runs the thread and waits until
it finishes.  Simple - but a bit on the expensive side.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/