1. R7RS Tasks
    1. General structure
    2. Todo
    3. Classification of changes
    4. Changes that are likely to be implemented in the core system
      1. 2.1. Identifiers
      2. 4.2.2. Binding constructs
      3. 4.2.5. Delayed evaluation
      4. 4.3.2. Pattern language (syntax-rules)
      5. 6.3. Booleans
      6. 6.6. Characters
      7. 6.7. Strings
      8. 6.8. Vectors
      9. 6.9. Bytevectors
      10. 6.13.3. Output
      11. Appendix B
    5. Implementations in the r7rs egg that override core functionality
      1. 4.1.7. Inclusion
      2. 4.2.1. Conditionals
      3. 4.2.6 Dynamic bindings
      4. 5.2. Import declarations
      5. 5.3.3. Multiple-value definitions
      6. 5.5. Record-type definitions
      7. 5.6.1. Library syntax
      8. 5.7 The REPL
      9. 6.1. Equivalence predicates
      10. 6.4. Pairs and lists
      11. 6.7. Strings
      12. 6.8. Vectors
      13. 6.10. Control features
      14. 6.11. Exceptions
      15. 6.12. Environments and evaluation
      16. 6.13.1. Ports
      17. 6.13.3. Output
      18. 6.14. System interface

R7RS Tasks

(first draft, by felix)

comments by John Cowan marked with JC:

General structure

I currently assume that R7RS support will be provided by an egg and a minimal set of core enhancements for performance-sensitive functionality or features that would require extensive customization of existing code.

R7RS library names (lists) can be mapped to module names by concatenating the constituents of a library name, separated by "." (dot), for example:

 (foo bar baz)   ->   foo.bar.baz

The egg needs to provide a compile-time layer for the expansions of library forms and import-resolution in addition to a full set of standard libraries. Using the r7rs egg (for example with require-extension) will automatically load and import all r7rs standard libraries into the toplevel environment. On the other hand R7RS modules defined with "define-library" will have initially only import, which will be needed to expand imports (strictly speaking, the initial module environment should be empty, but this is how the module system currently works).

There is probably no way around including the full numeric tower - providing a mode with a restricted set of numeric types would complicate the R7RS support quite considerably. The numbers egg is likely to need some enhancements (equal[=]? with handling of circular data, see below).

Full type-declarations for all exports should be provided, both for error checking and performance. It would also be worthwhile to identify small inlinable R7RS primitives and generate ".inline" files for all standard libraries, if candidates for global inlining exist.

Some R7RS primitives are partially or completely provided by SRFI-1 and SRFI-13, but I think it would be better to implement them directly, to make them as efficient as possible. The existing code is in many cases not tuned to the implementation and makes assumptions about Scheme code performance that may have been valid 30 years ago but aren't anymore nowadays.


Outstanding tasks:

Nice to haves:

The egg also needs a more comprehensive test suite.

Classification of changes

Trivial or straightforward changes
Changes that are difficult or work-intensive
Changes that break backwards-compatibility
Needs to be clarified

Changes that are likely to be implemented in the core system

2.1. Identifiers


(test '(mooh qux blah foo BAR)
           "#!fold-case mooh QUX blah #!no-fold-case foo BAR" read-file)))

;; #!(no-)fold-case "affect the reading of subsequent data *from the same port*"
(test '(foo bar downcased UPCASED)
           "#!fold-case foo BAR" read-file)
           "downcased UPCASED" read-file)))

From what I can see, this means a flag needs to be added to the *port*, so that repeated invocations of READ can communicate this to eachother.

4.2.2. Binding constructs

4.2.5. Delayed evaluation

4.3.2. Pattern language (syntax-rules)

6.3. Booleans

(BTW, I find these depressing. Is it really so difficult for newcomers to learn #t and #f?)

JC: The theory is that #t and #f are too easily mistaken for each other by a human reader. I don't find it so, but apparently others do.

ZB: I would also suggest #one and #ell to prevent further ambiguity. Repeat recursively for #ell as needed.

AS: ZB: Actually, programmers I know fairly universally avoid using single lowercase "l" as a variable name for precisely that reason.

6.6. Characters

6.7. Strings

6.8. Vectors

(My heart bleeds)

6.9. Bytevectors

6.13.3. Output

Appendix B

Implementations in the r7rs egg that override core functionality

4.1.7. Inclusion

4.2.1. Conditionals

4.2.6 Dynamic bindings

5.2. Import declarations

5.3.3. Multiple-value definitions

By having letrec* semantics for internal definitions, this implementation of define-values by Alex Shinn is sufficient for handling toplevel and local multiple-value definitions (special handling in lambda-body expansion is not necessary anymore):

(define-syntax define-values
  (syntax-rules ()
    ((_ (var  ...) expr)
     (define-values-sub () (var ...) () expr))
    ((_ . else)
     (syntax-error "malformed define-values" (define-values . else)))

(define-syntax define-values-sub
  (syntax-rules ()
    ((_ (tmp ...) (last-var) (var ...) expr)
     ;; place the last var at the start of the list
     (define-values-sub (tmp1 tmp ...) () (last-var var ...) expr))
    ((_ (last-tmp tmp ...) () (last-var var ...) expr)
     (begin (define var #f) ... ;(undefined)
            (define last-var
              (receive (tmp ... last-tmp) expr
                (set! var tmp) ...
    ((_ (tmp ...) (v v2 ...) (var ...) expr)
     (define-values-sub (tmp ... tmp1) (v2 ...) (var ... v) expr))

5.5. Record-type definitions

5.6.1. Library syntax

5.7 The REPL

6.1. Equivalence predicates

6.4. Pairs and lists

6.7. Strings

6.8. Vectors

6.10. Control features

6.11. Exceptions

6.12. Environments and evaluation

6.13.1. Ports

6.13.3. Output

6.14. System interface