[r6rs] underscore is not a pattern variable and can appear any number of times
The following R6RS program: (import (rnrs)) (define-syntax ciao (lambda (stx) (syntax-case stx () ((_ _) "ciao\n" (display (ciao 1)) fails with: ;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-autocompile argument to disable. ;;; compiling proof.sps ;;; WARNING: compilation of proof.sps failed: ;;; key syntax-error, throw_args (macroexpand "~a: ~a in ~a" (syntax-case "duplicate pattern variable" (_ _)) #f) Backtrace: In ice-9/boot-9.scm: 170: 17 [catch #t # ...] In unknown file: ?: 16 [catch-closure] In ice-9/boot-9.scm: 62: 15 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 389: 14 [eval # #] In ice-9/boot-9.scm: 1858: 13 [save-module-excursion #] 1149: 12 [load "proof.sps" #f] 1051: 11 [%start-stack load-stack ...] 1056: 10 [#] In unknown file: ?: 9 [primitive-load "proof.sps"] In ice-9/eval.scm: 458: 8 [# (define-syntax ciao #)] In ice-9/psyntax.scm: 1195: 7 [chi-top (define-syntax ciao (lambda # #)) () ((top)) ...] 1572: 6 [chi-simple-lambda (lambda (stx) (syntax-case stx () ...)) () ...] 1462: 5 [parse (((# #) . #(syntax-object # # #))) () () () () () ()] In unknown file: ?: 4 [map # ((# . #))] In ice-9/psyntax.scm: 2410: 3 [# # # () ...] In unknown file: ?: 2 [scm-error syntax-error macroexpand ...] In ice-9/boot-9.scm: 115: 1 [# syntax-error ...] In unknown file: ?: 0 [catch-closure syntax-error macroexpand ...] ERROR: In procedure macroexpand: ERROR: syntax-case: duplicate pattern variable in (_ _) on a i686-pc-linux-gnu when using commit 8d10ccae79ff46f0ebea92ba36acfaebafba8d86. The underscore is an auxiliary syntax, not a pattern variable; so it can appear any number of times in a patter and match any subform of the input form. -- Marco Maggi
[r6rs] probably bad syntax expansion
The following R6RS program: (import (rnrs)) (define (%general-string-append . args) (let-values (((port getter) (open-string-output-port))) (let loop ((args args)) (if (null? args) (getter) (let ((thing (car args))) (display (if (identifier? (car args)) (identifier->string (car args)) (car args)) port) (loop (cdr args))) (define-syntax identifier->string (syntax-rules () ((_ ?identifier) (symbol->string (syntax->datum ?identifier) (define (identifier-prefix prefix identifier) (datum->syntax identifier (string->symbol (%general-string-append prefix identifier (identifier-prefix "make-" #'salut) fails with: Backtrace: In ice-9/boot-9.scm: 170: 10 [catch #t # ...] In unknown file: ?: 9 [catch-closure] In ice-9/boot-9.scm: 62: 8 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 389: 7 [eval # #] In ice-9/boot-9.scm: 1858: 6 [save-module-excursion #] 1148: 5 [load "proof.sps" #f] In unknown file: ?: 4 [load-compiled/vm "/home/marco/.cache/guile/ccache/2.0-0.R-LE-4/home/marco/var/tmp/proof.sps.go"] In proof.sps: 23: 3 [identifier-prefix "make-" #(syntax-object salut ((top)) ...)] 12: 2 [%general-string-append "make-" #(syntax-object salut ((top)) ...)] In ice-9/boot-9.scm: 115: 1 [# wrong-type-arg ...] In unknown file: ?: 0 [catch-closure wrong-type-arg "vm-debug-engine" ...] ERROR: In procedure vm-debug-engine: ERROR: Wrong type to apply: #string> on ai686-pc-linux-gnu using commit 8d10ccae79ff46f0ebea92ba36acfaebafba8d86; I get the same error when precompiling and when not precompiling. If I try to reduce the programs to simpler forms (for example simplifying %GENERAL-STRING-APPEND) the error goes away. The program works fine with other R6RS implementations. -- Marco Maggi
Re: [r6rs] probably bad syntax expansion
"Marco Maggi" wrote: > The following R6RS program: Sorry for the self reply; the problem goes away defining IDENTIFIER->STRING before its usage. I can understand this, but it is not R6RS behaviour. Maybe just documenting it as incompatibility is fine. -- Marco Maggi
[r6rs] #\x0 is a perfectly valid character datum representation
The following R6RS program: (import (rnrs)) #\x0 fails with: ;;; note: source file proof.sps ;;; newer than compiled /home/marco/.cache/guile/ccache/2.0-0.R-LE-4/home/marco/var/tmp/proof.sps.go Backtrace: In ice-9/boot-9.scm: 170: 10 [catch #t # ...] In unknown file: ?: 9 [catch-closure] In ice-9/boot-9.scm: 62: 8 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 389: 7 [eval # #] In ice-9/boot-9.scm: 1858: 6 [save-module-excursion #] 1149: 5 [load "proof.sps" #f] 1051: 4 [%start-stack load-stack ...] 1056: 3 [#] In unknown file: ?: 2 [primitive-load "proof.sps"] In ice-9/boot-9.scm: 115: 1 [# read-error ...] In unknown file: ?: 0 [catch-closure read-error "scm_lreadr" ...] ERROR: In procedure scm_lreadr: ERROR: proof.sps:5:5: unknown character name x0 on ai686-pc-linux-gnu using commit 8d10ccae79ff46f0ebea92ba36acfaebafba8d86. It looks like the hex notation for characters is not recognised by the reader. -- Marco Maggi
Re: [r6rs] probably bad syntax expansion
"Marco Maggi" wrote: > Sorry for the self reply; the problem goes away defining > IDENTIFIER->STRING before its usage. I can understand > this, but it is not R6RS behaviour.Maybe just > documenting it as incompatibility is fine. I take it back. It imposes an order on definitions which can cause problems in complex libraries (like mine). -- Marco Maggi
Re: [r6rs] #\x0 is a perfectly valid character datum representation
On Mon 21 Jun 2010 10:12, Marco Maggi writes: > #\x0 Add (read-enable 'r6rs-hex-escapes) to your guile init file. Mike: is there a more sensible default than the one we have? Thanks, Andy -- http://wingolog.org/
Re: [r6rs] underscore is not a pattern variable and can appear any number of times
On Mon 21 Jun 2010 09:35, Marco Maggi writes: > (syntax-case stx () > ((_ _) Fixed in master, thanks for the report. It is an incompatible change in R6RS, but I think it's for the better. Ciao, A -- http://wingolog.org/
Re: [r6rs] probably bad syntax expansion
Hello, On Mon 21 Jun 2010 09:59, Marco Maggi writes: > (define A ) > (define-syntax B <>) > (A) I have abbreviated your illuminating example. I don't really know what to think of it, except to say that for top-level programs Guile implements "REPL semantics". It would seem that both for toplevel programs and for libraries -- because Guile expands the `library' form to toplevel definitions -- that these REPL semantics do diverge from lexically-nested semantics. It's the difference between: (let () (define even? (lambda (x) (or (= x 0) (odd? (- x 1) (define-syntax odd? (syntax-rules () ((odd? x) (not (even? x) (even? 10)) => #t and (begin (define even? (lambda (x) (or (= x 0) (odd? (- x 1) (define-syntax odd? (syntax-rules () ((odd? x) (not (even? x) (even? 10)) ERROR: In procedure vm-debug-engine: ERROR: Wrong type to apply: # It is unfortunate for users that expect R6RS semantics for toplevel and library definitions. I would be happy to accept a well-reasoned patch to letrec-compile the first forms from a file that prove to be definitions, though we cannot remove support for mixed definitions and expressions at the toplevel. However, I don't have the motivation to work on this in the foreseeable future. Thank you for the report, though, and I will document the incompatibility. Andy -- http://wingolog.org/
Re: [r6rs] #\x0 is a perfectly valid character datum representation
> From: Andy Wingo wi...@pobox.com >> #\x0 > Add (read-enable 'r6rs-hex-escapes) to your > guile init file. > Mike: is there a more sensible default than the one we > have? The idea behind not enabling it by default is because the r6rs *string* escapes are not backwards compatible with the hex escapes used with Guile 1.8.x. "Hello \x57orld" vs "Hello \x57;orld" There is no perfect way to have both Guile 1.8.x and r6rs *string* hex escapes at the same time. You could hack something together, but, there would be corner cases where it might be invalid. That's why it was made a reader option. But, r6rs hex *character* escapes and Guile 1.8.x octal character escapes could logically coexist without confusion. But, it might be confusing to have r6rs hex character escapes that work by default while r6rs string escapes don't work by default. Thanks, Mike
Re: [r6rs] #\x0 is a perfectly valid character datum representation
Hi Mike, Thanks for the explanation :-) On Mon 21 Jun 2010 22:27, Mike Gran writes: > r6rs hex *character* escapes and Guile 1.8.x octal character escapes > could logically coexist without confusion. Let's do that. Shall you, or shall I? > But, it might be confusing to have r6rs hex character escapes > that work by default while r6rs string escapes don't work by > default. Well, we'll document this then, and perhaps revisit this in a couple years. Andy -- http://wingolog.org/
Re: [r6rs] #\x0 is a perfectly valid character datum representation
> From: Andy Wingo wi...@pobox.com > Hi Mike, > Thanks for the explanation :-) >> r6rs hex *character* escapes and Guile 1.8.x octal >> character escapes could logically coexist without confusion. > Let's do that. Shall you, or shall I? It would happen more quickly if you did it. You'd just have to remove the SCM_R6RS_ESCAPES_P from the following line of scm_read_character() in read.c 969 if (cp == 'x' && (charname_len > 1) && SCM_R6RS_ESCAPES_P) Thanks, Mike
