Per Bothner scripsit: > I'm uncertain about export-all. Kawa by default does this if there is > no module-export or export form. (Binding defined by define-private > are excepted.) It might be useful to have an 'except' option if this > is added.
I've changed it to take a list of identifiers not to be exported. > The optimization options have a 80's feel to them. Not surprising, as they come from Common Lisp. > I'm not sure how useful they'd be to Kawa. Maybe debuggability to > control whether to force better exceptions, as an example. I think speed and safety are important in general, though on the JVM you pretty much always get safety and speed is out of your control. :-) > The Numeric tower specifications seem rather ad hoc, and I suspect will > see limited use. `Exactness-preserving` means you have bignums. But I agree they are probably obsolete given the R7RS numeric tower vote. They are meant to cause complaints if the corresponding features don't exist. I have removed `numeric-tower` in favor of `error`, which signals an error (possibly uncatchable) when the library is first examined. It's meant to be used within `cond-expand`. > The Types features might be useful. However, it's a big can of worms. It is. I'm removing it as a proposal and making it an issue. > I would prefer the provide syntax to be: > (provide 'feature-identifier) > for historic compatibility. I understand the motivation. However, the inside of an R7RS library (other than within a `begin` declaration) is not Scheme, so quoting an identifier would suggest that a variable is also possible, which it isn't; there can be no variables there. -- John Cowan http://www.ccil.org/~cowan [email protected] Winter: MIT, / Keio, INRIA, / Issue lots of Drafts. So much more to understand! / Might simplicity return? (A "tanka", or extended haiku) _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
