7.6.1 Incompatibilities with the R6RS

There are some incompatibilities between Guile and the R6RS. Some of them are intentional, some of them are bugs, and some are simply unimplemented features. Please let the Guile developers know if you find one that is not on this list.

• The R6RS specifies many situations in which a conforming implementation must signal a specific error. Guile doesn’t really care about that too much—if a correct R6RS program would not hit that error, we don’t bother checking for it.
• Multiple library forms in one file are not yet supported. This is because the expansion of library sets the current module, but does not restore it. This is a bug.
• R6RS unicode escapes within strings are disabled by default, because they conflict with Guile’s already-existing escapes. The same is the case for R6RS treatment of escaped newlines in strings.

  R6RS behavior can be turned on via a reader option. See section String Read Syntax, for more information.

• A set! to a variable transformer may only expand to an expression, not a definition—even if the original set! expression was in definition context.
• Instead of using the algorithm detailed in chapter 10 of the R6RS, expansion of toplevel forms happens sequentially.

  For example, while the expansion of the following set of toplevel definitions does the correct thing:

  (begin
   (define even?
     (lambda (x)
       (or (= x 0) (odd? (- x 1)))))
   (define-syntax odd?
     (syntax-rules ()
       ((odd? x) (not (even? x)))))
   (even? 10))
  ⇒ #t
  

  The same definitions outside of the begin wrapper do not:

  (define even?
    (lambda (x)
      (or (= x 0) (odd? (- x 1)))))
  (define-syntax odd?
    (syntax-rules ()
      ((odd? x) (not (even? x)))))
  (even? 10)
  <unnamed port>:4:18: In procedure even?:
  <unnamed port>:4:18: Wrong type to apply: #<syntax-transformer odd?>
  

  This is because when expanding the right-hand-side of even?, the reference to odd? is not yet marked as a syntax transformer, so it is assumed to be a function.

  This bug will only affect top-level programs, not code in library forms. Fixing it for toplevel forms seems doable, but tricky to implement in a backward-compatible way. Suggestions and/or patches would be appreciated.

• The (rnrs io ports) module is incomplete. Work is ongoing to fix this.
• Guile does not prevent use of textual I/O procedures on binary ports. More generally, it does not make a sharp distinction between binary and textual ports (see section binary-port?).

This document was generated on April 20, 2013 using texi2html 5.0.