continuation curiosity -- for entertainment purposes only

continuation curiosity -- for entertainment purposes only

[Stephen Compall]

While writing up an <ahem> interesting example for using call/cc, I
ran into this curiosity.  Expressions at the top level are not
considered a single program flow.  Observe:

Here is the original source for `ccgrep.scm', including lots of
debugging messages:

;; begin ccgrep.scm
(use-modules (ice-9 rdelim) (srfi srfi-13))

(define debug-message
  (lambda args (for-each display args) (newline)))

(define next-match #f)
(display
 (let lp ((line (read-line)))
   (debug-message "called: " line)
   (if (eof-object? line)
       (begin (set! next-match #f) "")
     (if (string-contains line "bash")
         (or (call-with-current-continuation
              (lambda (nm)
                (debug-message "captured continuation")
                (set! next-match nm)
                (string-append line "\n")))
             (lp (read-line)))
       (lp (read-line))))))

(debug-message "value of continuation saver: " next-match)
(and next-match (next-match (begin
                              (debug-message "calling continuation")
                              #f)))
(debug-message "quitting")
;; end ccgrep.scm

I piped /etc/passwd to it, and here is the output (with some
unimportant lines taken out):

[sirian@localhost guile]$ guile -s ccgrep.scm < /etc/passwd
called: root:x:0:0:root:/root:/bin/bash
captured continuation
root:x:0:0:root:/root:/bin/bash
value of continuation saver: #<continuation 406 @ 80a4678>
calling continuation
called: bin:x:1:1:bin:/bin:
called: daemon:x:2:2:daemon:/sbin:
<snip>
called: gopher:x:13:30:gopher:/usr/lib/gopher-data:
called: postgres:x:40:41:PostgreSQL Server:/var/lib/pgsql:/bin/bash
captured continuation
postgres:x:40:41:PostgreSQL Server:/var/lib/pgsql:/bin/bash
quitting

Imagine my surprise when it failed to consider the top-level
expressions that report on next-match and run it if it's there as part
of the flow, and skipped to what it hadn't executed --- the "quitting"
message.

So I reworked it as a function created and called in one step:

;; repeat previous setup
((lambda ()
   (define next-match #f)
   (display
    (let lp ((line (read-line)))
      (debug-message "called: " line)
      (if (eof-object? line)
          (begin (set! next-match #f) "")
        (if (string-contains line "bash")
            (or (call-with-current-continuation
                 (lambda (nm)
                   (debug-message "captured continuation")
                   (set! next-match nm)
                   (string-append line "\n")))
                (lp (read-line)))
          (lp (read-line))))))

   (debug-message "value of continuation saver: " next-match)
   (and next-match (next-match (begin
                                 (debug-message "calling continuation")
                                 #f)))
   (debug-message "quitting")))
;; end of ccgrep.scm

...and it worked exactly as I expected it to, as a simple grep
proof-of-concept that displays all lines containing "bash".

I haven't tried using a simple let in place of my one-shot function.

--
Stephen Compall or s11 or sirian

A plumber is needed, the network drain is clogged


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: continuation curiosity -- for entertainment purposes only

[Kevin Ryde]

Stephen Compall <s11@member.fsf.org> writes:
>
> Imagine my surprise when it failed to consider the top-level
> expressions that report on next-match and run it if it's there as part
> of the flow, and skipped to what it hadn't executed --- the "quitting"
> message.

Is that because what's captured is a read-eval loop perhaps?
(Ie. expressions are read and evaluated one at a time, rather than an
eval of the whole file in one go.)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

goops: bug or not?

[Anders Vinjar]

A question about inheritance of getters/setters and overwriting
and such.  The following sequence hits an error (guile v. 1.6):

  (define-class <super-1> (<object>)
    (sl1 #:init-form 10 #:getter slot))

  (define-class <super-2> (<super-1>)
    (sl2 #:init-form 100 #:accessor slot))

  (define-class <sub-1> (<super-1>)
    (sl3 #:init-form 'hey #:getter subslot))

  (slot (make <sub-1>))

- claiming theres no applicable method for 'slot in the last
call.

However,

  (compute-slots (class-of (make <sub-1>)))

returns:

  ((sl1 #:init-form 10 #:init-thunk #<procedure #f ()> #:getter #<<generic> slot (3)>)
   (sl3 #:init-form (quote hei) #:init-thunk #<procedure #f ()> #:getter #<<generic> subslot (1)>))

- indicating there is a generic function 'slot (with 3 methods?) to
access the inherited slot.

But:

  (describe slot)

- lists only the two methods for <super-1> and <super-2>

If i leave out the definition of 'slot as an accessor - in
<super-1> - things work as expected with regards to <sub-1>.

Is this a bug?  If not, how is a way to access the inherited slot
by the method specified together with the slot?

Anders Vinjar


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: goops: bug or not?

[Anders Vinjar]

    AV> If i leave out the definition of 'slot as an accessor -
    AV> in <super-1> - things work as expected with regards to
    AV> <sub-1>.

Sorry, this should have read: "... the definition of 'slot as an
accessor - in <super-2>..."


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user