This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.
Source for wiki ModuleFactoringCowan version 3
author
cowan
comment
ipnr
74.68.112.189
name
ModuleFactoringCowan
readonly
0
text
Here's my counterproposal to ModuleFactoringShinn, with rationales:
* Move `(scheme io)` back to the base.
* It provides string-ports and the shared function of all ports, and there is no reason why all Schemes shouldn't provide these. Note that `(scheme io)` was never actually proposed or voted on, and its presence in the first draft is an error by the editors.
* Failing this, I prefer the name `(scheme ports)` from ModuleFactoringMedernach to `(scheme io)`, since by themselves these routines don't actually provide input to or output from the program.
* Don't provide an umbrella module for I/O.
* Files, reading Scheme objects, and writing Scheme objects are orthogonal. Demanding that your implementation provide all of them as a matter of course, across the whole range of Schemes, doesn't make much sense. We already have a ticket allowing Schemes to pre-import whichever modules they want in the REPL.
* Leave `interaction-environment` in the `(scheme repl)` module.
* Alex wants to move this to `(scheme eval)`, but the essence of `(scheme repl)` is that it provides not only evaluation of expressions, but a mutable global environment. There is no reason why a Scheme can't provide the first without the second.
* Leave `case-lambda` in the base module.
* It captures a useful pattern and can be optimized by a slick compiler or by hand.
* Move `(scheme multiple-values)` back to the base.
* Multiple values are easy to hack an implementation for (lists, or a list wrapped in a record if you insist), and at least `exact-integer-sqrt` depends on them. Alex wants to move this procedure to a separate module so it can depend on `(scheme multiple-values)`, but I think that's [http://dictionary.reference.com/browse/pelion piling Pelion on Ossa].
* Rename `(scheme unicode)` to `(scheme char)`.
* Alex and I agree on this one. The essence of this module is that it does things which, on a full-Unicode system, require a big table. Making it a module means that you can have full Unicode without the big table unless specific code requires it.
* Move `char-alphabetic?`, `char-numeric?`, `char-upper-case?`, `char-lower-case?` and `char-whitespace?` to `(scheme char)`.
* Alex and I agree on this one; not doing it in the first place was an oversight on my part.
* Move the normalization procedures to `(scheme char normalization)`.
* I still prefer to keep the names of WG1 modules simple, but okay, fine.
== Not part of the proposal ==
Alex says that depending on discussion, he would consider moving
the following out of the core:
* `syntax-rules`
* `define-record-type`
* blob procedures
* `string-ref` and `string-set!` (but possibly he means `string-set!` and `string-fill`?)
The first three are IMO important parts of Scheme and cheap to provide directly on all reasonable systems. There is no reason why all Schemes can't support them, which I consider the most important factor in moving things to modules. It doesn't make sense for all Schemes to provide inexact arithmetic (which is mostly about having floating-point instructions available) or files, so they belong in modules.
I am no fan of mutable strings, but reluctantly I conclude that programs depend on them and we can't get rid of them, so all Schemes might as well provide them. Hence no module.
time
2011-06-21 01:49:47
version
3