[plt-scheme] symbols redefined in SRFIs

> Now, how is mzscheme reverse! different from SRFI-1 reverse! ? I see no 
> inherent reasons for two different versions. Do you? SRFI-1 doesn't 
> mandate the usage of its reference implementation, in case you want to 
> mention "native vs. Scheme".


Hi Dan,

The "problem" that seems to be the root of this is name collision --- as 
soon as we have two modules that share the same exported names, we hit 
this problem.  If you use the module import mentioned earlier in the 
thread, you can avoid this problem.

http://list.cs.brown.edu/pipermail/plt-scheme/2005-January/007611.html


So, if you just use that, then is there still an issue here for you?  If 
that module path looks totally ugly, you can always limit the ugliness to 
a single file in your personal project directory:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(module srfi-1 mzscheme
   (require (lib "list.ss" "srfi" "1"))
   (provide (all-from (lib "list.ss" "srfi" "1"))))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

I agree, I can't remember this at all either.  But that's what this 
"srfi-1" module is meant to do, to hide the ugliness.  "srfi-1" here is a 
module that just re-exports all the stuff from that module.


After you have this, as long as this "srfi-1" module file is in the same 
directory as your other sources, you can do a relative import:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(module another-module mzscheme
   (require "srfi-1.ss")   ;; a "relative" path import that looks for
                           ;; srfi-1.ss in the same path as
                           ;; another-module.
   ;; ...
)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

and never need to worry about using the ugly module path import again. 
It's your code, so you get to decide.


When you mention that the current design is a poor design, are you saying 
that the functionality of the design sucks, or are you just talking about 
syntax?  If you're talking about syntax, sure, I think it's a bit ugly 
too, but that's something that's fixable.

But if you're talking about functionality, though, that's different! 
There's a reason for the functionality in:

     (require (lib "list.ss" "1" "srfi"))

The "lib" portion of this says that this is an "absolute" library import, 
one where the module must be looked up from the standard set of library 
collections.  In this case, it's looking through the "1" subcollection 
within the "srfi" collection, corresponding to the path 
"$PLT_HOME/collects/srfi/1/list.ss".  If you want a relative import --- 
importing a module relative to the current path --- use the other form 
without the LIB syntax:

     (require "some-other-module.ss")


That distinction is crucial!  In contrast: the Python community didn't 
make this distinction for module lookup, and this caused enormous amounts 
of pain (and still does).  i.e. 
http://mail.python.org/pipermail/tutor/2003-May/022705.html.  Try 
listening to a new Python programmer why their program dealing with random 
numbers didn't work, and one of the frequent responses is: "Did you call 
your program itself 'random.py'?"  Sounds like a random thing, but it's 
the most frequent cause for this kind of error I've seen!  Not 
differentiating between relative and absolute module import paths is a 
terrible mistake, and I'll be so happy when PEP 328 goes into effect by 
default.


So I appreciate that mzscheme's module system doesn't make this particular 
design error.  Still, it's not perfect.  Jacob Matthews pointed out the 
other common snafu that happens with mzscheme's module system:

http://keepworkingworkerbee.blogspot.com/2006/05/package-interfaces.html

and I agree with him: I'm not happy that it adopted the other standard 
problem --- using ML's equivalent of "open module" as the default for 
importing names --- but that's an argument for another day.  *grin*


Best of wishes!