Re: PORT problem

[JP M. <ma...@al...>]

>
> > > >
> > > > #+(and :excl (or :allegro-v4.0 :allegro-v4.1
> > > >                   :allegro-v5.0.1 :allegro-v6.0 :allegro-v6.2))
>
>does the appended patch help?

Is the patched file in CVS?  It would probably be easier for me
just to download it.

I'm not running on Unix and I don't have an automatic patch-applier
mechanism that I am aware of.

> > ;;; 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]
>
>I think that the semantics of require is pretty much this:
>
>(defun require (module &optional path)
>   (or (find module *modules* :test #'string=)
>       (load (or path module))))

No, I don't think so.  I don't think that

"If the pathname-list is nil, an implementation-dependent mechanism
will be invoked in an attempt to load the module named module-name;"

implies that LOAD should be called on MODULE if PATH is NIL as you show in
your code.  The implementation is free, presumably, to look up MODULE
in some table and get an actual path, or use some other algorithm.

(Also, PATH can be a list, but that's a detail)

Be that as it may, the question we are concerned about is does REQUIRE
require that LOAD be called directly on the paths in PATH, or is it allowed
to use some lower-level load-type function that just attempts to load the
exact file specified by PATH, as Allegro is apparently doing?

>there are plenty of bells and whistles, but I think that the ACL
>behavior is buggy.
>
>I suggest that you raise this issue on c.l.l.

I have done so.  See the post entitled 'Problem with REQUIRE...'