guile-user
[Top][All Lists]
Advanced

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

Re: Hash table cursor with delimited continuations


From: Mark H Weaver
Subject: Re: Hash table cursor with delimited continuations
Date: Thu, 01 Oct 2015 22:57:09 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

address@hidden (Taylan Ulrich "Bayırlı/Kammer") writes:

> Out of interest, I tried implementing a hash table cursor using
> hash-for-each and delimited continuations:
>
>     (use-modules
>      (srfi srfi-9)
>      (ice-9 hash-table))
>
>     (define-record-type <ht-cursor>
>       (make-cursor %cont key value)
>       cursor?
>       (%cont %cursor-cont)
>       (key   cursor-key)
>       (value cursor-value))
>
>     (define ht-iter-prompt (make-prompt-tag "ht-iter"))
>
>     (define (ht-cursor ht)
>       (call-with-prompt
>        ht-iter-prompt
>        (lambda ()
>          (hash-for-each
>           (lambda (k v)
>             (abort-to-prompt ht-iter-prompt k v))
>           ht))
>        (lambda (cont k v)
>          (make-cursor cont k v))))
>
>     (define (ht-cursor-next cursor)
>       (call-with-prompt
>        ht-iter-prompt
>        (%cursor-cont cursor)
>        (lambda (cont k v)
>          (make-cursor cont k v))))
>
> (The cursor would be valid so long as the table isn't mutated.)
>
> But I hit the following problem:
>
> scheme@(guile-user)> (define ht (alist->hash-table '((a . 0) (b . 1))))
> scheme@(guile-user)> (define cursor (ht-cursor ht))
> scheme@(guile-user)> (cursor-key cursor)
> $2 = a
> scheme@(guile-user)> (set! cursor (ht-cursor-next cursor))
> ERROR: In procedure #<partial-continuation 1a24e00>:
> ERROR: Throw to key `vm-error' with args `(vm-run "Unrewindable partial
> continuation" (#<vm-continuation 1c7b270>))'.

The problem is that the partial continuation created by
'abort-to-prompt' includes a stack frame for 'hash-for-each', which is
implemented in C.  Guile does not support invoking partial continuations
that include C stack frames.  This is Andy's area, not mine, but I guess
the problem is that we don't have enough information to relocate a C
stack frame.

For now, the solution to problems like this is to avoid implementing
higher-order procedures in C, so that in practice C stack frames are
rarely found in the middle of the stack.

      Mark



reply via email to

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