Re: shift and reset, plus "while"

Re: shift and reset, plus "while"

[Wolfgang J Moeller]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4643 bytes --]

Hi,

co-routine linkage problem solved!

All it takes, is taking care that each [full] continuation
seen by one co-routine are equivalent, so it doesn't matter
which one gets saved and restored. No continuation-barrier
or dynamic-wind required!

While not obvious at first glance, doing so is easy enough -
at least by "imperative" programming throughout. I believe that
now my co-routine linkage works for prompt-based reset/shift
just the same as for call/cc-based reset/shift.

===

My pet peeve: (while).

First a compiler bug (in V2.0.0),
plus mis-behaviour after a stack overflow:

| moeller@linux3-$ guile2 --no-auto-compile
| using readline (~/.guile) ...
| GNU Guile 2.0.0
| Copyright (C) 1995-2011 Free Software Foundation, Inc.
|
| Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
| This program is free software, and you are welcome to redistribute it
| under certain conditions; type `,show c' for details.
|
| Enter `,help' for help.
| scheme@(guile-user)> (display (while #f 1))
| <unnamed port>:0:0: In procedure #<procedure 887aa60 at <current input>:1:0 ()>:
| <unnamed port>:0:0: Throw to key `vm-error' with args `(vm-run "VM: Stack overflow" ())'.
|
| Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
| scheme@(guile-user) [1]>
| scheme@(guile-user) [1]> (display (while #f 1))
| Segmentation fault
| moeller@linux3-$

You can
	(define (f) (display (while #f 1)))
which also gets the code wrong, and ,disassemble ...

Btw,
	(define (f) (while #f 1))
	(display (f))
does work (--> #<unspecified>), as does
	(while #f 1)
at top level.

===

Second, this is how I'd like to "improve" (while)
as currently provided by ice-9/boot.scm :

(a) to always have a well-defined result
(b) to allow for (break arg ...)
(c) to only take a single (call-with-prompt)
(d) to correct a buglet that currently transforms the non-operator `continue'
    into a function of arbitrarily many (as opposed to zero) arguments.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; {while} with `continue' and `break'.
;;
;;; wjm: Will the inliner eventually remove the prompt at compile-time
;;;      if it finds that neither `continue' nor `break' are used?
;;; NB. The optimization, as announced in ice-9/boot.scm, doesn't work out yet.
;;
;; returns:
;;	#f		on normal termination	- sort-of compatible to GUILE
;;						  which returns #<unspecified>
;;	#t		on (break)		- compatible
;;	(values v ...)	on (break v ...)	- compatible extension
;;
(define-syntax while
  (lambda (x)
    (syntax-case x ()
      ((while cond . body)
       #`(let ((tag (make-prompt-tag "while")))
	   (let lp ()
	     (call-with-prompt
	      tag
	      ;;
	      (lambda ()
		;;
		(define-syntax #,(datum->syntax #'while 'break)
		  (lambda (x)
		    (syntax-case x ()
		      ((_ . vals)
		       #'(abort-to-prompt tag #f . vals))
		      (_
		       #'(lambda vals
			   (apply abort-to-prompt tag #f vals))))))
		;;
		(define-syntax #,(datum->syntax #'while 'continue)
		  (lambda (x)
		    (syntax-case x ()
		      ((_)
		       #'(abort-to-prompt tag #t))
		      ((_ . args)
		       (syntax-violation 'continue "too many arguments" x))
		      (_
		       #'(lambda ()
			   (abort-to-prompt tag #t))))))
		;;
		(do ()
		    ((not cond) #f)
		  . body))
	      ;;
	      (lambda (k cont? . vals)
		(if cont?
		    (lp)
		    (or (null? vals)
			(apply values vals)))))))))))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

NB. "body ..." (etc.) replaced by ". body" so my LISP-based Scheme can read it too.

As of V2.0.0, the modified macro runs into the same problems
as the built-in (while) shown above.

Feel free to select the modifications you like!

===

Just a hint: (GPLed) CLISP's compiler is written in LISP
and in my experience perfectly succeeds at removing all
redundant branches. Maybe something to look at?


Schöne Grüße,

Dr. Wolfgang J. Möller                   <moeller@gwdg.de>
Arbeitsgruppe IT-Infrastruktur         Tel. +49 551 201-1516
----------------------------------------------------- G W D G ----
Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen
Am Fassberg 11, 37077 Göttingen
E-Mail: gwdg@gwdg.de                   Tel.:   +49 (0)551 201-1510
URL:    http://www.gwdg.de             Fax:    +49 (0)551 201-2150
Geschäftsführer:            Prof. Dr. Oswald Haan, Dr. Paul Suren
Aufsichtsratsvorsitzender:  Prof. Dr. Christian Griesinger
Sitz der Gesellschaft:      Göttingen
Registergericht:            Göttingen  Handelsregister-Nr. B 598
------------------------------------------------------------------

Re: shift and reset, plus "while"

[Andy Wingo]

Hi Wolfgang,

Another in a series of asynchronous replies :)  Copying guile-devel for
comments on the extensions to `while'.

On Mon 04 Apr 2011 15:05, Wolfgang J Moeller <wjm@heenes.com> writes:

> | GNU Guile 2.0.0
> | scheme@(guile-user)> (display (while #f 1))
> | <unnamed port>:0:0: In procedure #<procedure 887aa60 at <current input>:1:0 ()>:
> | <unnamed port>:0:0: Throw to key `vm-error' with args `(vm-run "VM: Stack overflow" ())'.

This is the same compiler bug as before, which is fixed in stable-2.0.
We'll push out a release Real Soon Now (TM).

> I'd like to "improve" (while) as currently provided by ice-9/boot.scm
>
> (a) to always have a well-defined result

This is a good idea; it allows `while' to be an expression, not just a
statement.

> (b) to allow for (break arg ...)

Also a good idea.

Tricky, though; your comments indicate that you would want (break) to
return #t, instead of zero values.

> (c) to only take a single (call-with-prompt)

Why?  It's true that the optimizer doesn't live up to its name yet, but
it should be trivial to elide one or the other if the prompt tag is only
referenced by the <prompt> form.

> (d) to correct a buglet that currently transforms the non-operator `continue'
>     into a function of arbitrarily many (as opposed to zero)
>     arguments.

I have not seen this bug.  Do you have code that can reproduce it with
stable-2.0 ?

> Just a hint: (GPLed) CLISP's compiler is written in LISP and in my
> experience perfectly succeeds at removing all redundant
> branches. Maybe something to look at?

No doubt, it would be instructive!

Andy
-- 
http://wingolog.org/

Re: [shift and reset, plus] "while"

[Wolfgang J Moeller]

On Wed, 13 Apr 2011, Andy Wingo wrote:

>[...]
> > I'd like to "improve" (while) as currently provided by ice-9/boot.scm
> >
> > (a) to always have a well-defined result
>
> This is a good idea; it allows `while' to be an expression, not just a
> statement.
>
> > (b) to allow for (break arg ...)
>
> Also a good idea.
>
> Tricky, though; your comments indicate that you would want (break) to
> return #t, instead of zero values.

Does anyone like to _test_ for zero values? Not me.
As regards the REPL, you still can (break (if #f #f)).

Alternative: return zero values on "normal termination",
instead of #<unspecified>, so the REPL keeps quiet then,
as it did before. Not as handy, but at least well-defined.

I don't remember if GUILE V1.6 had the return values of #f and #t,
or if they were my own invention ... IIRC it did have (break arg)
with a single argument. Anyway, #t is compatible with V2.0.0 .

Not exactly tricky - see my code's prompt handler.

> > (c) to only take a single (call-with-prompt)
>
> Why?  It's true that the optimizer doesn't live up to its name yet, but
> it should be trivial to elide one or the other if the prompt tag is only
> referenced by the <prompt> form.

Just for simplification of the macro - it's plain overkill to create two prompts.
Nothing to do with the optimizer per se; my note only relates to the fact that
the (promised) optimization ought to work just as well with the single prompt.

> > (d) to correct a buglet that currently transforms the non-operator `continue'
> >     into a function of arbitrarily many (as opposed to zero)
> >     arguments.
>
> I have not seen this bug.  Do you have code that can reproduce it with
> stable-2.0 ?

No code - it's a buglet w/o much consequence - from ice-9/boot-9.scm :

[...]
;;; {While}
[...]
(define-syntax while
  [...]
  (define-syntax #,(datum->syntax #'while 'continue)
    (lambda (x)
      (syntax-case x ()
	((_)
	 #'(abort-to-prompt continue-tag))
	((_ . args)		; <<<<< wjm: no argumenta allowed - OK
	 (syntax-violation 'continue "too many arguments" x))
	(_
	 #'(lambda args		; <<<<< wjm: arguments allowed - WHY??
	     (apply abort-to-prompt continue-tag args))))))
  [...])

Stand-alone fix:

	((_ . args)		; no arguments allowed
	 (syntax-violation 'continue "too many arguments" x))
	(_
	 #'(lambda ()		; also, zero arguments
	     (abort-to-prompt continue-tag)))))


Best regards,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/

Re: shift and reset, plus "while"

[Mark H Weaver]

Wolfgang J Moeller <wjm@heenes.com> writes:
> (d) to correct a buglet that currently transforms the non-operator `continue'
>     into a function of arbitrarily many (as opposed to zero) arguments.

I fixed this on the stable-2.0 branch a while back, in commit
ddf134cfec0d82ea9f39ddd69948c08feecb9576.

     Mark

Re: [shift and reset, plus] "while"

[Andy Wingo]

On Wed 13 Apr 2011 16:56, Wolfgang J Moeller <wjm@heenes.com> writes:

> On Wed, 13 Apr 2011, Andy Wingo wrote:
>
>>[...]
>> > I'd like to "improve" (while) as currently provided by ice-9/boot.scm
>> >
>> > (a) to always have a well-defined result
>>
>> This is a good idea; it allows `while' to be an expression, not just a
>> statement.
>>
>> > (b) to allow for (break arg ...)
>>
>> Also a good idea.
>>
>> Tricky, though; your comments indicate that you would want (break) to
>> return #t, instead of zero values.
>
> Does anyone like to _test_ for zero values? Not me.
> As regards the REPL, you still can (break (if #f #f)).
>
> Alternative: return zero values on "normal termination",
> instead of #<unspecified>, so the REPL keeps quiet then,
> as it did before. Not as handy, but at least well-defined.
>
> I don't remember if GUILE V1.6 had the return values of #f and #t,
> or if they were my own invention ... IIRC it did have (break arg)
> with a single argument. Anyway, #t is compatible with V2.0.0 .

From Guile 1.6:

    (defmacro while (cond . body)
      `(letrec ((continue (lambda () (or (not ,cond) (begin (begin ,@ body) (continue)))))
                (break (lambda val (apply throw 'break val))))
         (catch 'break
    	    (lambda () (continue))
    	    (lambda v (cadr v)))))

It did indeed happen to return #t on a normal termination, and have
(break ARG).  It has lots of other bugs though.  I would prefer (break)
to return zero values, and (while #f 1) as well, but that is
incompatible with 2.0.  Bummer.

> Not exactly tricky - see my code's prompt handler.

I didn't mean in terms of code; I meant in terms of documentation,
interface, expectations, etc...

>> > (d) to correct a buglet that currently transforms the non-operator `continue'
>> >     into a function of arbitrarily many (as opposed to zero)
>> >     arguments.

I hadn't seen this one because Mark Weaver fixed it a few weeks ago, in
ddf134cfec0d82ea9f39ddd69948c08feecb9576.

Cheers,

Andy
-- 
http://wingolog.org/

Re: [shift and reset, plus] "while"

[Wolfgang J Moeller]

On Wed, 13 Apr 2011, Andy Wingo wrote:

>[...]
> >From Guile 1.6:
>[...]
> It did indeed happen to return #t on a normal termination, and have
> (break ARG).  It has lots of other bugs though.  I would prefer (break)
> to return zero values, and (while #f 1) as well, but that is
> incompatible with 2.0.  Bummer.

OK, that explains why I have an old & lengthy program that does use
(break arg), and why I had to keep my macro compatible.

Last resort: Once we do allow for argument(s) to (break),

   (while #t ... (break x) ... (break y) ...)

allows for full functionality, plus returning all well-defined results,
without necessarily requiring well-defined (or even different) results
from (break) and (while #f).

Only that this construct might better be called "loop/return" ...

Given the situation at V2.0.0, with the only results being
#<unspecified> and #t (plus compiler error!), and [at least]
V1.8.5 returning nothing but #<unspecified>, I find it hard
to believe that (break) ==> #t had found an application yet.

Or maybe someone can come up with a pretty formulation
of a newly invented "do-until/break/continue" combo ...

> > Not exactly tricky - see my code's prompt handler.
>
> I didn't mean in terms of code; I meant in terms of documentation,
> interface, expectations, etc...

Indeed. I'd like to say thanks to the authors of the new/improved GUILE manual.
Real good. E.g. finally, a description of "syntax-case" that I'd understand
(as opposed to R6RS ;-)!

Best regards,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/

Re: shift and reset, plus "while"

[Andy Wingo]

On Mon 04 Apr 2011 15:05, Wolfgang J Moeller <wjm@heenes.com> writes:

> (a) to always have a well-defined result
> (b) to allow for (break arg ...)

I have implemented this in stable-2.0.  It did not make it into 2.0.1
however.  Incidentally it should be compatible with the old 1.6 `while'.

Cheers,

Andy
-- 
http://wingolog.org/

Re: [shift and reset, plus] "while"

[Andy Wingo]

On Wed 13 Apr 2011 19:31, Wolfgang J Moeller <wjm@heenes.com> writes:

> Last resort: Once we do allow for argument(s) to (break),
>
>    (while #t ... (break x) ... (break y) ...)

If I understand you right, this is more like a coroutine, which could
use an orthogonal form:

(define-syntax with-yield
  (lambda (x)
    (syntax-case x ()
      ((_ yield exp exp* ...) (identifier? #'yield)
       #'(let ((tag (make-prompt-tag)))
           (define (handler k . args)
             (define (resume . args)
               (call-with-prompt tag
                 (lambda () (apply k args))
                 handler))
             (apply values resume args))

           (call-with-prompt
            tag
            (lambda ()
              (let-syntax ((yield (syntax-rules ()
                                    ((_ arg (... ...))
                                     (abort-to-prompt tag arg (... ...))))))
                exp exp* ...))
           handler))))))

Then you can

  (with-yield yield
    (while #t ... (yield) ...))

Regards,

Andy
-- 
http://wingolog.org/

Re: shift and reset, plus "while"

[Wolfgang J Moeller]

Hi Andy,

>[...]
> On Mon 04 Apr 2011 15:05, Wolfgang J Moeller <wjm@heenes.com> writes:
>
> > (a) to always have a well-defined result
> > (b) to allow for (break arg ...)
>
> I have implemented this in stable-2.0.  It did not make it into 2.0.1
> however.  Incidentally it should be compatible with the old 1.6 `while'.

Great. Thanks!

No more reason to consider my "last resort":

> On Wed, 13 Apr 2011, Andy Wingo wrote:
> >[...]
> > >From Guile 1.6:
> >[...]
> > It did indeed happen to return #t on a normal termination, and have
> > (break ARG).  It has lots of other bugs though.  I would prefer (break)
> > to return zero values, and (while #f 1) as well, but that is
> > incompatible with 2.0.  Bummer.
>
> OK, that explains why I have an old & lengthy program that does use
> (break arg), and why I had to keep my macro compatible.
>
> Last resort: Once we do allow for argument(s) to (break),
>
>    (while #t ... (break x) ... (break y) ...)
>
> allows for full functionality, plus returning all well-defined results,
> without necessarily requiring well-defined (or even different) results
> from (break) and (while #f).
>
> Only that this construct might better be called "loop/return" ...

Sorry, this was meant as a loop that would _only_ be terminated
[conditionally] by (BREAK arg . optargs) forms [at various places].

I had proposed this, so - for compatibility - both of the other forms
	 (while #f ... )
and 	 (break) w/o arguments within (while ...)
could return whatever values you'd like (including #<unspecified>).

Maybe you just did implement point (a) above this way ...

===

>[...]
> (define-syntax with-yield
>   (lambda (x)
>     (syntax-case x ()
>       ((_ yield exp exp* ...) (identifier? #'yield)
>        #'(let ((tag (make-prompt-tag)))
>            (define (handler k . args)
>              (define (resume . args)
>                (call-with-prompt tag
>                  (lambda () (apply k args))
>                  handler))
>              (apply values resume args))
>
>            (call-with-prompt
>             tag
>             (lambda ()
>               (let-syntax ((yield (syntax-rules ()
>                                     ((_ arg (... ...))
>                                      (abort-to-prompt tag arg (... ...))))))
>                 exp exp* ...))
>            handler))))))
>
> Then you can
>
>   (with-yield yield
>     (while #t ... (yield) ...))

While not asked for, great macro anyway ;-)

I eventually got to try it out and check if it's "call/cc-compatible"
[remember my (solved) problem to have general reset/shift-based co-routines?].

===

Next going to play with 2.0.1 !


Best regards,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/

{debug,read,readline,print}-{set!,disable,enable}

[Wolfgang J Moeller]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1399 bytes --]

Hi,

to a first approximation, these are just documentation errors
(GUILE 2.0.1 and likely all prior versions):

According to the HTML manual:

— Scheme Procedure: debug-enable option-name
— Scheme Procedure: debug-disable option-name
— Scheme Procedure: debug-set! option-name value

— Scheme Procedure: print-set! option-name value

— Scheme Procedure: read-enable option-name
— Scheme Procedure: read-disable option-name
— Scheme Procedure: read-set! option-name value

In fact, {debug,print,read}-set! are macros that want "option-name" to be a literal symbol,
while {debug,read}-{en,dis}able are procedures indeed (apparently taking multiple arguments)
that want the "option-name"[s] to be quoted symbol[s].

Given this state of affairs, the docu ought to indicate at least
some kind of difference between the macros and procedures ...

Ch. 7.8.2 ("Readline Options") isn't affected the same way, however it doesn't
mention readline-enable, although the procedure index says so; on the other hand
that page has a reference to (no longer existing) "evaluator" options.

Just saying ;-)


[Noticed while looking for something like V1 (debug-disable 'debug) that might speed up execution.]


Best regards,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/

Re: {debug,read,readline,print}-{set!,disable,enable}

[Andy Wingo]

On Fri 29 Apr 2011 14:12, Wolfgang J Moeller <wjm@heenes.com> writes:

> In fact, {debug,print,read}-set! are macros that want "option-name" to
> be a literal symbol, while {debug,read}-{en,dis}able are procedures
> indeed (apparently taking multiple arguments) that want the
> "option-name"[s] to be quoted symbol[s].

Indeed; nasty, but it's what we've got.  Fixed the docs.

> [Noticed while looking for something like V1 (debug-disable 'debug)
> that might speed up execution.]

It's spelled `--no-debug'; see "Invoking Guile".

  `--debug'
       Start with the debugging virtual machine engine.  Using the
       debugging VM will enable support for VM hooks, which are needed
       for tracing, breakpoints, and accurate call counts when profiling.
       The debugging VM is slower than the regular VM, though, by about
       10 percent.  *Note VM Hooks::, for more information.

       By default, the debugging VM engine is only used when entering an
       interactive session.  When executing a script with `-s' or `-c',
       the normal, faster VM is used by default.

  `--no-debug'
       Do not use the debugging VM engine, even when entering an
       interactive session.

Also note that git is about 10-20% faster than 2.0.1.

Andy
-- 
http://wingolog.org/

Re: {debug,read,readline,print}-{set!,disable,enable}, etc.

[Wolfgang J Moeller]

Hi,

On Fri, 20 May 2011, Andy Wingo wrote:
> On Fri 29 Apr 2011 14:12, Wolfgang J Moeller <wjm@heenes.com> writes:
> > In fact, {debug,print,read}-set! are macros that want "option-name" to
> > be a literal symbol, while {debug,read}-{en,dis}able are procedures
> > indeed (apparently taking multiple arguments) that want the
> > "option-name"[s] to be quoted symbol[s].
>
> Indeed; nasty, but it's what we've got.  Fixed the docs.

Thanks.

> > [Noticed while looking for something like V1 (debug-disable 'debug)
> > that might speed up execution.]
>
> It's spelled `--no-debug'; see "Invoking Guile".
>[...]

Oops - didn't notice before at all. Thanks. Only a minor speed-up, indeed.

Invocation options ... you don't think "scheme-shell", do you?

As regards (primitive-load) - it's only after our discussion that I realized
that without file-compilation GUILE seems to always (slowly) interprete the
LOADed code. Makes me ask for LISP's (LOAD ... :COMPILING T) [independent of
invocation-time settings] again ... (maybe via compiling to /dev/null ?)

Any provision for C-style #if ... #include ... (of, say, macros
required by the subsequent code)? (LOAD) gets evaluated too late;
(INCLUDE) of definitions isn't allowed within (IF); (EVAL) again
comes too late.
(I did notice your major changes to "psyntax", but so far
I don't see how they'd help me. No problems with them either ;-)

Otherwise, no problems with 2.0.1. Except for a tidbit ...

"Compiler error message not properly decoded", as in

| moeller@louix-$ guile2 -q
| GNU Guile 2.0.1
|[...]
| scheme@(guile-user)> (load "zwp.scm")
| ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
| ;;;       or pass the --no-auto-compile argument to disable.
| ;;; compiling /home/moeller/scm/zwp.scm
| ;;; WARNING: compilation of /home/moeller/scm/zwp.scm failed:
| ;;; key syntax-error, throw_args (#f "definition in expression context" #f #t dummy3)
| scheme@(guile-user)>

where "zwp.scm" is the "prelude" snippet that I sent you on April 2.
Pretty sure it didn't look like this in 2.0.0.

Thanks again, best regards,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/

Re: {debug,read,readline,print}-{set!,disable,enable}, etc.

[Andy Wingo]

Hi Wolfgang,

On Sun 22 May 2011 13:53, Wolfgang J Moeller <wjm@heenes.com> writes:

> As regards (primitive-load) - it's only after our discussion that I realized
> that without file-compilation GUILE seems to always (slowly) interprete the
> LOADed code. Makes me ask for LISP's (LOAD ... :COMPILING T) [independent of
> invocation-time settings] again ... (maybe via compiling to /dev/null ?)

There is read-and-compile, from system base compile...

> Any provision for C-style #if ... #include ... (of, say, macros
> required by the subsequent code)? (LOAD) gets evaluated too late;
> (INCLUDE) of definitions isn't allowed within (IF); (EVAL) again
> comes too late.
> (I did notice your major changes to "psyntax", but so far
> I don't see how they'd help me. No problems with them either ;-)

There is `eval-when', which you can use to build the exact thing you
need.  See "Eval When" in the manual.  In the Guile context we encourage
the use of modules.

> Otherwise, no problems with 2.0.1. Except for a tidbit ...
>
> "Compiler error message not properly decoded", as in
>
> | moeller@louix-$ guile2 -q
> | GNU Guile 2.0.1
> |[...]
> | scheme@(guile-user)> (load "zwp.scm")
> | ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
> | ;;;       or pass the --no-auto-compile argument to disable.
> | ;;; compiling /home/moeller/scm/zwp.scm
> | ;;; WARNING: compilation of /home/moeller/scm/zwp.scm failed:
> | ;;; key syntax-error, throw_args (#f "definition in expression context" #f #t dummy3)
> | scheme@(guile-user)>
>
> where "zwp.scm" is the "prelude" snippet that I sent you on April 2.
> Pretty sure it didn't look like this in 2.0.0.

It might have.  But fixed, in any case :-)

Cheers,

Andy
-- 
http://wingolog.org/