Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
ANSI says that PROVIDE and REQUIRE take string designator arguments.
A string designator is coerced to a string using STRING, and
comparison of SDs is done using STRING=.
However, the current implementation of REQUIRE calls
MODULE-PROVIDE-CONTRIB, which computes the pathname by downcasing
strings obtained from symbols, but not from literal strings. So
(REQUIRE "ASDF") loses, yet (REQUIRE "asdf") wins.
(MODULE-PROVIDE-CONTRIB signals an error on handle character string
(require "ASDF") != (require "asdf") == (require 'asdf)
(require #\a) => error
Attached is an (untested) patch which I hope helps.
From: Antonio Martinez <tonyms@te...> - 2003-05-16 11:02:18
> I'm inclined to believe that the current treatment is suboptimal.
> I'm not completely convinced that I understand what the correct thing
> to do is in all circumstances; I have a suspicion that it would
> involve trusting the pathname implementation to do the right thing in
> the presence of :CASE :COMMON. Since I think that's probably a
> disaster, could I have comments on the following patch, please? Tony,
> I want to know if this solves your particular problem; [...]
If it's okay, I'll report later on today, because I haven't got a CVS
tree handy at present. But it looks (modulo other possible bugs) like
it fixes the problem I tripped on.
Silly nitpicks: in REQUIRE, if the module is already provided, we can
simply return NIL. Perhaps:
(if (member (string module-name) *modules* :test #'string=)
(let ((saved-modules ...))
With the current REQUIRE return value, you don't need the T return
value I added to MODULE-PROVIDE-CONTRIB to avoid propagating PROVIDE's
unspecified return value, since REQUIRE no longer propagates it to