Skip to content

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 String Read Syntax, for more information.

  • Guile does not yet support Unicode escapes in symbols, such as H\x65;llo (the same as Hello), or \x3BB; (the same as λ).

  • 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:

    emacs-lisp
    (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:

    emacs-lisp
    (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, or vice versa. All ports in Guile support both binary and textual I/O. See Encoding, for full details.

  • Guile’s implementation of equal? may fail to terminate when applied to arguments containing cycles.

Guile exposes a procedure in the root module to choose R6RS defaults over Guile’s historical defaults.

Scheme Procedure: install-r6rs!

Alter Guile’s default settings to better conform to the R6RS.

While Guile’s defaults may evolve over time, the current changes that this procedure imposes are to add .sls and .guile.sls to the set of supported %load-extensions, to better support R6RS conventions. See Load Paths. Also, enable R6RS unicode escapes in strings; see the discussion above.

Finally, note that the --r6rs command-line argument will call install-r6rs! before calling user code. R6RS users probably want to pass this argument to their Guile.