From: JP Massar
Subject: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <3e9dd2e0.15309402@netnews.attbi.com>
Is this a bug, or a feature?

> ;;; Allegro 6.2 Trial Edition
> 
> (load (translate-logical-pathname "cllib:miscprint"))
> ; Fast loading C:\Lispcode\clocc\src\cllib\miscprint.fasl
> T
> 
> (require "foo" (translate-logical-pathname "cllib:miscprint"))
> Error: #p"C:\\Lispcode\\clocc\\src\\cllib\\miscprint" does not exist,
>         cannot load
> [condition type: FILE-DOES-NOT-EXIST-ERROR]


In other words, REQUIRE is apparently not using LOAD directly on the
pathname provided.

The Hyperspec says that the list of pathnames 'is to be loaded in
order'.

Would it be excessively anal to believed that 'loaded' does not
necessarily mean
that LOAD is called on each pathname?

From: Kevin Layer
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <mksmsihyeh.fsf@*n*o*s*p*a*m*franz.com>
······@alum.mit.edu (JP Massar) writes:

> Is this a bug, or a feature?
> 
> > ;;; Allegro 6.2 Trial Edition
> > 
> > (load (translate-logical-pathname "cllib:miscprint"))
> > ; Fast loading C:\Lispcode\clocc\src\cllib\miscprint.fasl
> > T
> > 
> > (require "foo" (translate-logical-pathname "cllib:miscprint"))
> > Error: #p"C:\\Lispcode\\clocc\\src\\cllib\\miscprint" does not exist,
> >         cannot load
> > [condition type: FILE-DOES-NOT-EXIST-ERROR]
> 
> 
> In other words, REQUIRE is apparently not using LOAD directly on the
> pathname provided.

It is.  `require' uses sys:*require-search-list*, which differs from
sys:*load-search-list*:

cl-user(145): (pprint sys:*load-search-list*)

(#p"" #p(:type "fasl") #p(:type "cl") #p(:type "lisp"))
cl-user(146): (pprint sys:*require-search-list*)

((:first #p"sys:;code;.fasl" #p"sys:;private;.fasl" #p"sys:;clos;.fasl"
  #p"sys:;sys;.fasl" (:lib-bundle #p"sys:;code;.fasl")
  (:lib-bundle #p"sys:;private;.fasl") (:lib-bundle #p"sys:;clos;.fasl")
  (:lib-bundle #p"sys:;sys;.fasl"))
 #p"src:;code;.cl" #p"src:;private;.cl" #p"src:;clos;.cl" #p"src:;sys;.cl")
cl-user(147): 


The #p(:type "fasl") is what is allowing the explicit `load' to work.
I don't know, of the top of my head, why `require' doesn't have the
extra stuff on the search list.  You can do this in your .clinit.cl,
though:

(push #p(:type "fasl") sys:*require-search-list*)

and it should work.
From: JP Massar
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <3e9ddf28.18454140@netnews.attbi.com>
On 16 Apr 2003 15:26:30 -0700, Kevin Layer
<·····@*n*o*s*p*a*m*franz.com> wrote:

>······@alum.mit.edu (JP Massar) writes:
>
>> Is this a bug, or a feature?
>> 
>> > ;;; Allegro 6.2 Trial Edition
>> > 
>> > (load (translate-logical-pathname "cllib:miscprint"))
>> > ; Fast loading C:\Lispcode\clocc\src\cllib\miscprint.fasl
>> > T
>> > 
>> > (require "foo" (translate-logical-pathname "cllib:miscprint"))
>> > Error: #p"C:\\Lispcode\\clocc\\src\\cllib\\miscprint" does not exist,
>> >         cannot load
>> > [condition type: FILE-DOES-NOT-EXIST-ERROR]
>> 
>> 
>> In other words, REQUIRE is apparently not using LOAD directly on the
>> pathname provided.
>
>It is.  `require' uses sys:*require-search-list*, which differs from
>sys:*load-search-list*:

To clarify, you mean that LOAD is being called by REQUIRE with the
(Allegro-specific) :search-list keyword argument having 
a non-default value.

Hence different semantics result, even if REQUIRE is using LOAD
'directly'.

>
>cl-user(145): (pprint sys:*load-search-list*)
>
>(#p"" #p(:type "fasl") #p(:type "cl") #p(:type "lisp"))
>cl-user(146): (pprint sys:*require-search-list*)
>
>((:first #p"sys:;code;.fasl" #p"sys:;private;.fasl" #p"sys:;clos;.fasl"
>  #p"sys:;sys;.fasl" (:lib-bundle #p"sys:;code;.fasl")
>  (:lib-bundle #p"sys:;private;.fasl") (:lib-bundle #p"sys:;clos;.fasl")
>  (:lib-bundle #p"sys:;sys;.fasl"))
> #p"src:;code;.cl" #p"src:;private;.cl" #p"src:;clos;.cl" #p"src:;sys;.cl")
>cl-user(147): 
>
>
>The #p(:type "fasl") is what is allowing the explicit `load' to work.
>I don't know, of the top of my head, why `require' doesn't have the
>extra stuff on the search list.  You can do this in your .clinit.cl,
>though:
>
>(push #p(:type "fasl") sys:*require-search-list*)
>
>and it should work.

Indeed it does.  Thank you very much!

Note that the original question still stands:

Is this a bug or a feature?
From: Kevin Layer
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <mkfzoihta6.fsf@*n*o*s*p*a*m*franz.com>
······@alum.mit.edu (JP Massar) writes:

> On 16 Apr 2003 15:26:30 -0700, Kevin Layer
> <·····@*n*o*s*p*a*m*franz.com> wrote:
> 
> >······@alum.mit.edu (JP Massar) writes:
> >
> >> Is this a bug, or a feature?
> >> 
> >> > ;;; Allegro 6.2 Trial Edition
> >> > 
> >> > (load (translate-logical-pathname "cllib:miscprint"))
> >> > ; Fast loading C:\Lispcode\clocc\src\cllib\miscprint.fasl
> >> > T
> >> > 
> >> > (require "foo" (translate-logical-pathname "cllib:miscprint"))
> >> > Error: #p"C:\\Lispcode\\clocc\\src\\cllib\\miscprint" does not exist,
> >> >         cannot load
> >> > [condition type: FILE-DOES-NOT-EXIST-ERROR]
> >> 
> >> 
> >> In other words, REQUIRE is apparently not using LOAD directly on the
> >> pathname provided.
> >
> >It is.  `require' uses sys:*require-search-list*, which differs from
> >sys:*load-search-list*:
> 
> To clarify, you mean that LOAD is being called by REQUIRE with the
> (Allegro-specific) :search-list keyword argument having 
> a non-default value.

Yes.

> Hence different semantics result, even if REQUIRE is using LOAD
> 'directly'.

Yes.

> >cl-user(145): (pprint sys:*load-search-list*)
> >
> >(#p"" #p(:type "fasl") #p(:type "cl") #p(:type "lisp"))
> >cl-user(146): (pprint sys:*require-search-list*)
> >
> >((:first #p"sys:;code;.fasl" #p"sys:;private;.fasl" #p"sys:;clos;.fasl"
> >  #p"sys:;sys;.fasl" (:lib-bundle #p"sys:;code;.fasl")
> >  (:lib-bundle #p"sys:;private;.fasl") (:lib-bundle #p"sys:;clos;.fasl")
> >  (:lib-bundle #p"sys:;sys;.fasl"))
> > #p"src:;code;.cl" #p"src:;private;.cl" #p"src:;clos;.cl" #p"src:;sys;.cl")
> >cl-user(147): 
> >
> >
> >The #p(:type "fasl") is what is allowing the explicit `load' to work.
> >I don't know, of the top of my head, why `require' doesn't have the
> >extra stuff on the search list.  You can do this in your .clinit.cl,
> >though:
> >
> >(push #p(:type "fasl") sys:*require-search-list*)
> >
> >and it should work.
> 
> Indeed it does.  Thank you very much!
> 
> Note that the original question still stands:
> 
> Is this a bug or a feature?

Definitely a feature.
From: JP Massar
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <3e9dffa5.26771900@netnews.attbi.com>
On 16 Apr 2003 17:17:05 -0700, Kevin Layer
<·····@*n*o*s*p*a*m*franz.com> wrote:
 
>> 
>> Is this a bug or a feature?
>
>Definitely a feature.

So you claim that whether or not REQUIRE will load
a file by using a source or binary file type if said
file without any file type does not exist, is
implementation dependent, even though the Hyperspec
for LOAD says

"If the file specification is not complete and both a source file and
a compiled file exist which might match, then which of those files
load selects is implementation-dependent."

(That is, it seems to say LOAD will load one of those files, not
neither, at least as long as the file without a file type does not
exist. And REQUIRE calls LOAD.)

?
From: Kevin Layer
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <mk65pdu0us.fsf@*n*o*s*p*a*m*franz.com>
······@alum.mit.edu (JP Massar) writes:

> On 16 Apr 2003 17:17:05 -0700, Kevin Layer
> <·····@*n*o*s*p*a*m*franz.com> wrote:
>  
> >> 
> >> Is this a bug or a feature?
> >
> >Definitely a feature.
> 
> So you claim that whether or not REQUIRE will load
> a file by using a source or binary file type if said
> file without any file type does not exist, is
> implementation dependent, even though the Hyperspec
> for LOAD says
> 
> "If the file specification is not complete and both a source file and
> a compiled file exist which might match, then which of those files
> load selects is implementation-dependent."
> 
> (That is, it seems to say LOAD will load one of those files, not
> neither, at least as long as the file without a file type does not
> exist. And REQUIRE calls LOAD.)
> 
> ?

To explain my "definitely a feature" comment a little more:

- I'm worried about the code out there that would break if I made the
  change (to add #p(:type "fasl") to *require-search-list*).

- You can easily customize this behavior, either by adding the type to
  the require'd file or by pushing onto *require-search-list* in your
  ~/.clinit.cl.

Regarding the citation of the ANS: this is key, for me: "an
implementation-dependent mechanism will be invoked in an attempt to
load the module named module-name".  It doesn't say that `load' is
called.  Even we assume it is, which is reasonable, it doesn't say how
to map from `require' arguments to `load' arguments, so that'd be up
for interpretation by the implementation.

In other words, I don't think there is justification in the ANS for
calling this a bug.  I'll admit that if I was writing that code today,
and not in the 80's, I'd probably make it do what you want.  I'll even
file a bug report in your name for future consideration.
From: JP Massar
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <3e9f0973.49472274@netnews.attbi.com>
On 16 Apr 2003 22:52:43 -0700, Kevin Layer
<·····@*n*o*s*p*a*m*franz.com> wrote:
>  I'll even
>file a bug report in your name for future consideration.

I'm honored.

(But credit where credit is due.  Sam Steingold and the CLOCC
code base deserve at least half of the credit.)

(-:
From: Duane Rettig
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <4ptnl7f24.fsf@beta.franz.com>
······@alum.mit.edu (JP Massar) writes:

> On 16 Apr 2003 17:17:05 -0700, Kevin Layer
> <·····@*n*o*s*p*a*m*franz.com> wrote:
>  
> >> 
> >> Is this a bug or a feature?
> >
> >Definitely a feature.

Although Kevin has already answered your question and even created 
a bug report, I'd like to add my own point of view on this.

> So you claim that whether or not REQUIRE will load
> a file by using a source or binary file type if said
> file without any file type does not exist, is
> implementation dependent, even though the Hyperspec
> for LOAD says
> 
> "If the file specification is not complete and both a source file and
> a compiled file exist which might match, then which of those files
> load selects is implementation-dependent."
> 
> (That is, it seems to say LOAD will load one of those files, not
> neither, at least as long as the file without a file type does not
> exist. And REQUIRE calls LOAD.)

Our version of REQUIRE happens to call LOAD, but REQUIRE does not
call LOAD by mandate.  The paragraph you are invoking is describing
LOAD, not REQUIRE.

A better way to look at it is to take a step back and look at what the
idea is behind the spec.  The intention for REQUIRE is to load modules,
which might be a file or multiple files to PROVIDE functionality (note
the empahsis), but LOAD is intended to load files of nonspecified usage.
The mappings of modules are different than files - for example, if you
require a module foo from one file, and then require module foo from
another file, the second file will not be loaded in because foo has
already been provided.  However, if you load each file, even if they
both had the same name component, each would indeed be loaded in.  So
load and require are necessarily different.

Another difference is more along the lines of what each kind of file
is intended for; a module is intended to provide a specific set of
library functionality, and might tend to be located more centrally
than any other file.   So the way pathnames are searched/resolved
might be different as well.  It is in fact the case for Allegro CL,
where modules tend to be located in the "sys:" logical host.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: JP Massar
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <3e9eec93.42079959@netnews.attbi.com>
On 17 Apr 2003 00:34:27 -0700, Duane Rettig <·····@franz.com> wrote:

> 
>
>Our version of REQUIRE happens to call LOAD, but REQUIRE does not
>call LOAD by mandate.   
>
 
That's not obvious to me.  The Hyperspec entry for REQUIRE says

"Otherwise, an attempt is made to load an appropriate set of files as
follows:  The pathname-list argument, if non-nil, specifies a list of
pathnames to be loaded in order, from left to right. If the
pathname-list is nil, an implementation-dependent mechanism will be
invoked in an attempt to load the module named module-name;"

So the clause about "implementation-dependent" that Kevin made
reference to only applies if PATHNAME-LIST is NIL, which it is
not in the case we are talking about.

Unless the terms 'to load' and 'to be loaded' don't mean
'call the function LOAD' then it would seem to me that REQUIRE
must call LOAD by mandate.

But all this is only somewhat to the point.

The real point should be, what makes sense for REQUIRE so
that it can work portably?  

If I want to load a compiled file that represents a module,
as is being done in the CLOCC code all over the place,
how am I going to do it portably without simply specifying the base
name, as they are doing?

(The attempt to load various files of CLOCC that call REQUIRE
prompted this thread)

If they were to use COMPILE-FILE-PATHNAME to construct the
PATHNAME-LIST files given to REQUIRE that would preclude
loading of the source if the binary wasn't there.
(And Corman Lisp doesn't even use binary files).
Using the source file type would preclude loading the binary.
And using the base name, as we know, doesn't work.

The LOAD abstraction (look for a source or binary file extension
if no match on exact file specification) seems like the right one.
And given that most other implementations seem to handle REQUIRE
this way it would seem to make sense that Allegro would do so too.

for REQUIRE as well.


 
From: Duane Rettig
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <4he8wxlj6.fsf@beta.franz.com>
······@alum.mit.edu (JP Massar) writes:

> On 17 Apr 2003 00:34:27 -0700, Duane Rettig <·····@franz.com> wrote:
> 
> > 
> >
> >Our version of REQUIRE happens to call LOAD, but REQUIRE does not
> >call LOAD by mandate.   
> >
>  
> That's not obvious to me.  The Hyperspec entry for REQUIRE says
> 
> "Otherwise, an attempt is made to load an appropriate set of files as
> follows:  The pathname-list argument, if non-nil, specifies a list of
> pathnames to be loaded in order, from left to right. If the
> pathname-list is nil, an implementation-dependent mechanism will be
> invoked in an attempt to load the module named module-name;"
> 
> So the clause about "implementation-dependent" that Kevin made
> reference to only applies if PATHNAME-LIST is NIL, which it is
> not in the case we are talking about.
> 
> Unless the terms 'to load' and 'to be loaded' don't mean
> 'call the function LOAD' then it would seem to me that REQUIRE
> must call LOAD by mandate.

I was going to answer this point by point, but really, I don't want
to pick nits.  It is interesting (but entirely irrelevant) that in
both Xanalys's Hyperspec and our own ansicl spec html, the description
of LOAD starts out "load loads the file ..." and the word "loads" is
linked to the dictionary entry to load, whereas the several occurrences
of "load" and derivatives in PROVIDE's description are not linked.
Now, there could be some significance there, or (more likely) the links
were not made consistently for PROVIDE and REQUIRE because of their
waffling status in the spec (first out, then back in with modifications,
then further mods to make them more similar to CLtL1 definitions...).
I place no real importance on this, but it is interesting.

However, suppose REQUIRE must call LOAD by mandate.  If so, then,
you are hoist with your own petard: note that the second paragraph
in LOAD's description says

"If the file specification is not complete and both a source file
and a compiled file exist which might match, then which of those
files load selects is implementation-dependent."

So whether REQUIRE calls LOAD by mandate, by implementation, or not
at all, the behavior is still implementation-dependent.

> But all this is only somewhat to the point.

Precisely - let's get down to it...

> The real point should be, what makes sense for REQUIRE so
> that it can work portably?  
> 
> If I want to load a compiled file that represents a module,
> as is being done in the CLOCC code all over the place,
> how am I going to do it portably without simply specifying the base
> name, as they are doing?
> 
> (The attempt to load various files of CLOCC that call REQUIRE
> prompted this thread)
> 
> If they were to use COMPILE-FILE-PATHNAME to construct the
> PATHNAME-LIST files given to REQUIRE that would preclude
> loading of the source if the binary wasn't there.
> (And Corman Lisp doesn't even use binary files).
> Using the source file type would preclude loading the binary.
> And using the base name, as we know, doesn't work.

I don't have the previous parts of this thread handy, but I recall
that Kevin gave you a workaround (or perhaps you suggested it?)
where you can modify the *require-search-pathname* to do whatever
you want, to follow any path-following behaviors you want to
emulate.

> The LOAD abstraction (look for a source or binary file extension
> if no match on exact file specification) seems like the right one.
> And given that most other implementations seem to handle REQUIRE
> this way it would seem to make sense that Allegro would do so too.
> for REQUIRE as well.

I'm actually on vacation, but I was interested in this, and I did a
little research on it.  I found that we had actually had a much
broader *require-search-list* in 5.0.1 and earlier, and had had many
bugs due to the generality of it (the most obvious one I recall was
when a user created a file in his current directory called debug.cl
or debug.lisp, a very natural name for a file, and when that file
was compiled, suddenly our debugger didn't work for the customer,
because when the :debug module was to be loaded, what was in fact
loaded was ./debug.fasl, instead of "sys:;code;debug.*".  You can see
the transition we made to a more restrictive *require-search-list*
in the 6.0 release notes, preserved in the 6.1 docs here:

http://www.franz.com/support/documentation/6.1/doc/version-60-release-notes.htm#acl-non-back-2

Look at item #10.

Also, if my memory is failing me (guess I need a vacation...) and
no workaround was suggested, then you can look at your custom.cl file
in your distribution, where you can see the old 5.0.1 search list you
can use if you wish to get that behavior.  Or, you can modify it
yourself and get whatever behavior you want...

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Daniel Barlow
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <8765pbq45o.fsf@noetbook.telent.net>
Duane Rettig <·····@franz.com> writes:

> Now, there could be some significance there, or (more likely) the links
> were not made consistently for PROVIDE and REQUIRE because of their
> waffling status in the spec (first out, then back in with modifications,
> then further mods to make them more similar to CLtL1 definitions...).

I note also that "The functions provide and require are deprecated".
Which I think is kind of a shame, because they're a convenient way
to load optional libraries provided with the implementation: we use
them in SBCL, ACL uses them too, and I suspect so do other vendors.

Is it a bad idea to create actual uses for PROVIDE/REQUIRE, or would
they (like REMOVE-IF-NOT) probably get undeprecated (precated?)  were
there a future version of the standard?


-dan

-- 

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources 
From: Duane Rettig
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <4he8vols3.fsf@beta.franz.com>
Daniel Barlow <···@telent.net> writes:

> Duane Rettig <·····@franz.com> writes:
> 
> > Now, there could be some significance there, or (more likely) the links
> > were not made consistently for PROVIDE and REQUIRE because of their
> > waffling status in the spec (first out, then back in with modifications,
> > then further mods to make them more similar to CLtL1 definitions...).
> 
> I note also that "The functions provide and require are deprecated".
> Which I think is kind of a shame, because they're a convenient way
> to load optional libraries provided with the implementation: we use
> them in SBCL, ACL uses them too, and I suspect so do other vendors.

Maybe one or more of the X3J13 members can give us the history of
PROVIDE/REQUIRE - as I understand it; it as removed due to semantic
issues, and reinstated out of necessity.

> Is it a bad idea to create actual uses for PROVIDE/REQUIRE, or would
> they (like REMOVE-IF-NOT) probably get undeprecated (precated?)  were
> there a future version of the standard?

I think "use caution" is the way to proceed, just like the -IF-NOT
functions.  In Allegro CL, we hardly ever remove things completely,
unless there is a major conflict with the spec.  What we tend to do
is to provide the functionality in a back-compatibility package,
which can be required [sic:-] when the old functionality is needed.
But I don't think PROVIDE/REQUIRE are going to go away soon...

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Duane Rettig
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <4wuhnbz70.fsf@beta.franz.com>
Duane Rettig <·····@franz.com> writes:

> Daniel Barlow <···@telent.net> writes:
> 
> > Duane Rettig <·····@franz.com> writes:
> > 
> > > Now, there could be some significance there, or (more likely) the links
> > > were not made consistently for PROVIDE and REQUIRE because of their
> > > waffling status in the spec (first out, then back in with modifications,
> > > then further mods to make them more similar to CLtL1 definitions...).
> > 
> > I note also that "The functions provide and require are deprecated".
> > Which I think is kind of a shame, because they're a convenient way
> > to load optional libraries provided with the implementation: we use
> > them in SBCL, ACL uses them too, and I suspect so do other vendors.
> 
> Maybe one or more of the X3J13 members can give us the history of
> PROVIDE/REQUIRE - as I understand it; it as removed due to semantic
> issues, and reinstated out of necessity.

I did get private communication Friday from Kent before I left, and he
gave me permission to post the relevant part of our conversation here,
taken from a pair of exchanges:

>>  ... if I recall correctly, the confusion
>> over REQUIRE/PROVIDE came because people like it with its 2arg form
>> (because that is portable) but not with its 1arg form (because that is
>> not).  though there was some dispute about whether filenames were
>> portable, and whether maybe the 1arg form was more portable, allowing
>> the non-portable bits to be externally declared.  and there was some
>> business about its not being automatic-eval-when-eval-compile any more
>>  and so requiring more decoration and not looking good as a declaration
>>  any more.  it's a mess.

and later:

>>     Date: Fri, 18 Apr 2003 08:59:35 -0700
>>    From: Duane Rettig <·····@franz.com>
>>    ...
>>    Wasn't there also some thought about replacing it with something like
>>    a defsystem, which of course never happened?
>> 
>> Yes, though there was debate about which paradigm was best. 
>> You can get to the (failed) defsystem proposal at:
>> 
>> http://www.nhplace.com/kent/CL/

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Henrik Motakef
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <87adenh7y9.fsf@interim.henrik-motakef.de>
Daniel Barlow <···@telent.net> writes:

> I note also that "The functions provide and require are deprecated".
> Which I think is kind of a shame, because they're a convenient way
> to load optional libraries provided with the implementation: we use
> them in SBCL, ACL uses them too, and I suspect so do other vendors.
>
> Is it a bad idea to create actual uses for PROVIDE/REQUIRE, or would
> they (like REMOVE-IF-NOT) probably get undeprecated (precated?)  were
> there a future version of the standard?

A related question: Wouldn't it be sane for libraries to include a
(provide "MY-LIB") regardless of how the implementation handles
REQUIRE, so that users can at least test if it is loaded or not?

I've often seen libraries pushing themselves on *features*, but AFAIR
never on *modules*. I even seem to remember something like "#-somelib
(error "Need somelib!")", where REQUIRE would seem way more elegant.

Regards
Henrik
From: JP Massar
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <3ea029e5.50361950@netnews.attbi.com>
On 18 Apr 2003 01:22:21 -0700, Duane Rettig <·····@franz.com> wrote:
 
>
>I don't have the previous parts of this thread handy, but I recall
>that Kevin gave you a workaround (or perhaps you suggested it?)
>where you can modify the *require-search-pathname* to do whatever
>you want, to follow any path-following behaviors you want to
>emulate.

Indeed, and it works fine!  Many thanks to Kevin for such a prompt
response.  

My intent was to turn the discussion to one of making REQUIRE's
functionality portable, not complaining that there was no workaround.

 
>
>I'm actually on vacation, but I was interested in this, and I did a
>little research on it.  I found that we had actually had a much
>broader *require-search-list* in 5.0.1 

which may well explain why it didn't come up with the CLOCC code base
before.  (Since only a specialized use of that code base; not just
loading the whole shebang in, will cause the anomaly).
From: Tim Bradshaw
Subject: Re: Problem with REQUIRE in Allegro 6.2
Date: 
Message-ID: <ey33ckhvje2.fsf@cley.com>
* JP Massar wrote:

> "If the file specification is not complete and both a source file and
> a compiled file exist which might match, then which of those files
> load selects is implementation-dependent."

a file specification without a type on Unix *is* complete, since file
types are really a foreign concept to Unix.

--tim