This page is part of the web mail archives of SRFI discuss from before July 7th, 2015. The new archives for SRFI discuss contain all messages, not just those from before July 7th, 2015.
>>>>> "Alex" == Alex Shinn <foof@synthcode.com> writes: Alex> Many examples were given of these numbers being awkward in programming, Alex> requiring lookups, being cryptic if feature comparisons of Schemes, and Alex> also of scaring off newbies and outsiders to Scheme. An actual excerpt Alex> from the start of one of my modules: Alex> (use srfi-1) Alex> (use srfi-2) Alex> (use srfi-11) Alex> (use srfi-13) Alex> (use srfi-14) Alex> does this really not seem like a problem to people? Sure. But, as has been pointed out on comp.lang.scheme, SRFIs aren't modules. They aren't libraries. They are documents. Here's an excerpt from the start of one of my modules: (require (lib "list.ss" "srfi" "1")) (require (lib "string.ss" "srfi" "13")) Neither the former nor the latter is mandated by the SRFI process as a whole. Now of course, I can see that people want to turn some SRFI documents into libraries in the context of one or the other library/package/module system. And of course, I can see that they'd like to use symbolic names there. The main problem with assigning these symbolic names to the SRFI documents, rather than the libraries, is that there's likely to be duplicate candidates for names, even if there aren't many now. Enforcing a qualified naming scheme to avoid this makes the symbolic names much less useful and creates much the same problems as with the srfi-n names. I haven't seen any proposal that addresses this problem in any adequate matter, and I'm personally reluctant to endorse one that doesn't. Now, symbolic names have their place in a fixed library collection proposal, akin to the Standard ML basis or the Haskell library report. There's no problem with having such a proposal: write one up and submit it as a SRFI. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla