I am new to CL and I am still in the process of setting up a working
environment (on GNU/Linux with SBCL and Smile).
To my surprise I read in the Hyperspec:
The functions provide and require are deprecated.
So how am I supposed to require a lisp library? My expectation was
that I set up the load-path (whatever the equivalent, if any, might
be -- I have not investigated yet), install some lisp libaries that
might be useful into the proper places and put an according
`(require LIBRARY)' at the top of files on which I am working, if
necessary.
If this expectation is basically right, what functions am I supposed
to use if `require' and `provide' are deprecated? If this expectation
happens to be wrong, what is the typical way to use lisp libraries in
lisp programs?
Oliver
--
14 Pluviôse an 212 de la Révolution
Liberté, Egalité, Fraternité!
Oliver Scholz <··········@gmx.de> writes:
> I am new to CL and I am still in the process of setting up a working
> environment (on GNU/Linux with SBCL and Smile).
>
> To my surprise I read in the Hyperspec:
>
> The functions provide and require are deprecated.
>
> So how am I supposed to require a lisp library?
Do you mean a Lisp library like CLX, a large system external to the
system you're working on? Or do you mean inter-file dependancies
within the system you're working on. If the former, it's reasonable
to say (require :clx) (require :foo) at the top of the build script
for your system. If you mean the latter, you're supposed to be using
a system-construction facility (eg, ASDF -- http://www.cliki.net/asdf).
> My expectation was
> that I set up the load-path (whatever the equivalent, if any, might
> be -- I have not investigated yet), install some lisp libaries that
> might be useful into the proper places and put an according
> `(require LIBRARY)' at the top of files on which I am working, if
> necessary.
>
> If this expectation is basically right, what functions am I supposed
> to use if `require' and `provide' are deprecated? If this expectation
> happens to be wrong, what is the typical way to use lisp libraries in
> lisp programs?
This will work, but the REQUIRE/PROVIDE architecture isn't very well
defined by the standard (where does REQUIRE look? doesn't say), and it
doesn't provide a terribly sophisticated distinction between
compile-time and runtime dependencies. Try looking at one of the
defsystem systems.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Oliver Scholz <··········@gmx.de> writes:
>
>> I am new to CL and I am still in the process of setting up a working
>> environment (on GNU/Linux with SBCL and Smile).
>>
>> To my surprise I read in the Hyperspec:
>>
>> The functions provide and require are deprecated.
>>
>> So how am I supposed to require a lisp library?
>
> Do you mean a Lisp library like CLX, a large system external to the
> system you're working on? Or do you mean inter-file dependancies
> within the system you're working on.
Hmm, I am not sure into what category the packages that I have in
mind fit. I was thinking of small add-on libraries like the ones in
the CLOCC or, right now, xmls, a small XML parsing library.
I.e. nothing so large and -- as I understand it -- quasi-standard
as CLX; but still libraries that I might use for several
independent projects. (I don't think I am going to write something
big enough to require several files for quite a while.)
> If the former, it's reasonable to say (require :clx) (require :foo)
> at the top of the build script for your system. If you mean the
> latter, you're supposed to be using a system-construction facility
> (eg, ASDF -- http://www.cliki.net/asdf).
Thanks, I'll do that. Does that mean that I interpreted the spec a bit
too strong? I read "deprecated" as meaning: "this is obsolete, don't
use it!"
But maybe it is still good style to use `require' in some limited
cases, if portability is not an issue? I am thinking about small,
throw-away code that I am going to write.
Oliver
--
15 Pluviôse an 212 de la Révolution
Liberté, Egalité, Fraternité!
Oliver Scholz <··········@gmx.de> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Oliver Scholz <··········@gmx.de> writes:
> >
> >> I am new to CL and I am still in the process of setting up a working
> >> environment (on GNU/Linux with SBCL and Smile).
> >>
> >> To my surprise I read in the Hyperspec:
> >>
> >> The functions provide and require are deprecated.
> >>
> >> So how am I supposed to require a lisp library?
> >
> > Do you mean a Lisp library like CLX, a large system external to the
> > system you're working on? Or do you mean inter-file dependancies
> > within the system you're working on.
>
> Hmm, I am not sure into what category the packages that I have in
> mind fit. I was thinking of small add-on libraries like the ones in
> the CLOCC or, right now, xmls, a small XML parsing library.
> I.e. nothing so large and -- as I understand it -- quasi-standard
> as CLX; but still libraries that I might use for several
> independent projects. (I don't think I am going to write something
> big enough to require several files for quite a while.)
Those fall into the category where it's reasonable to use REQUIRE,
IMO, especially since you're using SBCL, where it's really invoking
ASDF.
> > If the former, it's reasonable to say (require :clx) (require :foo)
> > at the top of the build script for your system. If you mean the
> > latter, you're supposed to be using a system-construction facility
> > (eg, ASDF -- http://www.cliki.net/asdf).
>
> Thanks, I'll do that. Does that mean that I interpreted the spec a bit
> too strong? I read "deprecated" as meaning: "this is obsolete, don't
> use it!"
I think so. Asking was the right response, tho, "hey this looks
useful, why's it depricated?" If/when there's a next standard,
REQUIRE might very well be gone, but that doesn't mean you can't use
it as a convenience in the meantime (just don't make it integral to
your system's correct functioning). REMOVE-IF-NOT (also deprecated),
on the other hand, isn't going anywhere. If it did, everyone would
use their own implementations, probably slightly divergent, and would
generally create the mess that CL was supposed to avoid.
> But maybe it is still good style to use `require' in some limited
> cases, if portability is not an issue? I am thinking about small,
> throw-away code that I am going to write.
In that case, and in the case of one- or maybe two-file systems, I'd
say yes. If you don't need a defsystem to construct your system, it's
silly to use one *just* for external dependencies (unless you want to
make it work with asdf-install). Portably, you can depend on REQUIRE
ensuring that some module is listed in *MODULES*, and if not, invoking
some magic or other to try to load it. So if you told someone, "this
file depends on CLX, cl-xml, and cl-foo", it's reasonable to put
REQUIRE lines for all of those at the top.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Oliver Scholz <··········@gmx.de> wrote in message news:<··············@ID-87814.user.dfncis.de>...
> I am new to CL and I am still in the process of setting up a working
> environment (on GNU/Linux with SBCL and Smile).
>
> To my surprise I read in the Hyperspec:
>
> The functions provide and require are deprecated.
>
> So how am I supposed to require a lisp library? My expectation was
> that I set up the load-path (whatever the equivalent, if any, might
> be -- I have not investigated yet),
That's the kicker -- they never standardized the load path part, so
there's no *portable* way to tell require where to look.
> install some lisp libaries that
> might be useful into the proper places and put an according
> `(require LIBRARY)' at the top of files on which I am working, if
> necessary.
>
> If this expectation is basically right, what functions am I supposed
> to use if `require' and `provide' are deprecated? If this expectation
> happens to be wrong, what is the typical way to use lisp libraries in
> lisp programs?
Most common is to use some form of DEFSYSTEM which is similar to
"make" in spirit. Many Lisp's provide one, or you can get the one in
CLOCC (the Common Lisp Open Code Collection). It's not standardized,
and there are several variants, so be careful.
There's a tutorial on defsystem at
http://www.henrik-motakef.de/defsystem.html
Personally, I find require/provide much simpler for beginners and wish
a standardized method for specifying load paths had been developed.
Such is life.
Oliver Scholz <··········@gmx.de> writes:
> So how am I supposed to require a lisp library? My expectation was
> that I set up the load-path (whatever the equivalent, if any, might
> be -- I have not investigated yet), install some lisp libaries that
> might be useful into the proper places and put an according
> `(require LIBRARY)' at the top of files on which I am working, if
> necessary.
Indeed, in SBCL you do exactly that.
The problem with REQUIRE/PROVIDE in general is that there is nothing
like Elisp's load-path in CL, and their behaviour is
implementation-dependent. People generally use libraries like
mk:defsystem or ASDF (see the cliki for more information) to load (and
compile etc.) libraries, which work consistently for lots of
implementations. With them, you typically get your library as a bunch
of source files and a "system definition" file, which is similar to a
Makefile. You can then put this file in some place where the library
will find it and load the library and its dependencies.
Another difference to the Emacs way is that you wouldn't put the
REQUIRE forms in the source files that use the libraries directly, but
in the system definition. A sample system definition could look like
(defsystem my-app
:depends-on ("some-library" "and-another-one")
:components ((:file "foo")
(:file "bar" :depends-on ("foo"))))
SBCL can use ASDF for the REQUIRE function. For example, to load the
library once the system definition is in the proper place, you can say
(require 'asdf)
(require 'my-app)
and that's it. It also comes with asdf-install which downloads and
installs libraries for you, similar to Perl's CPAN shell.
(ASDF and asdf-install also work for other Lisps, but then you'd have
to use `(asdf:operate 'asdf:load-op :my-app)' instead of REQUIRE.)
Henrik Motakef <············@henrik-motakef.de> writes:
[...]
> The problem with REQUIRE/PROVIDE in general is that there is nothing
> like Elisp's load-path in CL, and their behaviour is
> implementation-dependent. People generally use libraries like
> mk:defsystem or ASDF (see the cliki for more information) to load (and
> compile etc.) libraries, which work consistently for lots of
> implementations. With them, you typically get your library as a bunch
> of source files and a "system definition" file, which is similar to a
> Makefile. You can then put this file in some place where the library
> will find it and load the library and its dependencies.
Thank you very much. That should get me going. After adjusting
asdf:*central-repository* I was able to load the packages that I
wanted with `require' at the SBCL prompt now. That should do for now
for the kind of throw-away code that I intent to write.
That asdf not only loads but also compiles the files when necessary is
very, very nifty!
Many thanks to the others also.
Oliver
--
14 Pluviôse an 212 de la Révolution
Liberté, Egalité, Fraternité!
Oliver Scholz <··········@gmx.de> writes:
> I am new to CL and I am still in the process of setting up a working
> environment (on GNU/Linux with SBCL and Smile).
>
> To my surprise I read in the Hyperspec:
>
> The functions provide and require are deprecated.
>
> So how am I supposed to require a lisp library? My expectation was
> that I set up the load-path (whatever the equivalent, if any, might
> be -- I have not investigated yet), install some lisp libaries that
> might be useful into the proper places and put an according
> `(require LIBRARY)' at the top of files on which I am working, if
> necessary.
>
> If this expectation is basically right, what functions am I supposed
> to use if `require' and `provide' are deprecated? If this expectation
> happens to be wrong, what is the typical way to use lisp libraries in
> lisp programs?
What I do:
- define a bunch of logical path name translations.
- use LOAD.
- for some complicated "libraries" that need special processing for
loading, I've got loaders lisp files.
For example:
(DEFMACRO SCONC (&REST ARGS) `(CONCATENATE 'STRING ,@ARGS))
(DEFMACRO DEF-LP-TRANS (HOST PATH &OPTIONAL SUBPATH)
(SETQ SUBPATH (OR SUBPATH ""))
`(SETF (LOGICAL-PATHNAME-TRANSLATIONS ,HOST)
(LIST
(LIST "**;*" (SCONC ,PATH ,SUBPATH "**/*"))
(LIST "**;*.*" (SCONC ,PATH ,SUBPATH "**/*.*"))
(LIST "**;*.*.*" (SCONC ,PATH ,SUBPATH "**/*.*.*"))
)));;DEF-LP-TRANS
(DEFCONSTANT +SHARE-LISP+ "/local/share/lisp/")
(DEF-LP-TRANS "CMU-AI" +SHARE-LISP+ "ai/")
(DEF-LP-TRANS "CLOCC" +SHARE-LISP+ "clocc/")
(DEF-LP-TRANS "CL-PDF" +SHARE-LISP+ "cl-pdf/")
(DEF-LP-TRANS "PSEUDO" +SHARE-LISP+ "pseudo/")
(DEF-LP-TRANS "CCLAN" +SHARE-LISP+ "cclan/")
;; Use (LOAD "LOADER:CCLAN.LISP") to load cclan.
(DEF-LP-TRANS "UFFI" +SHARE-LISP+ "uffi-1.2.15/")
;; Use (LOAD "LOADER:UFFI.LISP") to load uffi
(DEFCONSTANT +PJB-COMM+ "/home/pascal/src/common/")
(DEFCONSTANT +PJB-LISP+ "/home/pascal/src/lisp/")
(DEF-LP-TRANS "HOME" "/home/pascal/" "")
(DEF-LP-TRANS "LOADER" +PJB-LISP+ "loaders/")
(DEF-LP-TRANS "NORVIG" +PJB-LISP+ "norvig/")
In addition, I manage my packages with a mapping between the package
name and a logical pathname translation in logical host "PACKAGES":
(COM.INFORMATIMAGO.COMMON-LISP.PACKAGE:ADD-TRANSLATIONS
(LIST "**;*" (SCONC +SHARE-LISP+ "packages/**/*"))
(LIST "**;*.*" (SCONC +SHARE-LISP+ "packages/**/*.*"))
(LIST "**;*.*.*" (SCONC +SHARE-LISP+ "packages/**/*.*.*"))
)
Then:
(COM.INFORMATIMAGO.COMMON-LISP.PACKAGE:LOAD-PACKAGE
"COM.INFORMATIMAGO.COMMON-LISP.POSIX.ED")
(COM.INFORMATIMAGO.COMMON-LISP.POSIX.ED:ED)
Or I load directly a file:
(LOAD "PACKAGES:NET;SOURCEFORGE;GARNET;RUNDEMO.LISP")
Perhaps you're asking, for from the source of a package. Here I've
have a DEFINE-PACKAGE macro that encapsulate DEFPACKAGE, IN-PACKAGE,
and LOAD:
;; (DEFINE-PACKAGE COM.INFORMATIMAGO.COMMON-LISP.EXAMPLE
;; (:NICKNAMES NAME1 NAM2) ; use (:USE pack :AS nick) in client rather!
;; (:DOCUMENTATION "BLAH BLAH")
;; (:USE COMMON-LISP)
;; (:FROM COM.INFORMATIMAGO.COMMON-LISP.LIST :IMPORT :ALL)
;; (:FROM COM.INFORMATIMAGO.COMMON-LISP.STRING :IMPORT SYM1 SYM2 SYM3)
;; (:USE COM.INFORMATIMAGO.COMMON-LISP.UTILITY :AS UTIL)
;; (:USE COM.INFORMATIMAGO.COMMON-LISP.DICTIONARY)
;; (:EXPORT EXP1 EXP2 EXP3))
- Symbols are converted to string early,
- Nicknames are not generally specified in the DEFINE-PACKAGE, but
when the package is loaded (:USE clause). (There's still a problem
with current implementation in that two clients using the same
nickname for a different package collide)
- Note how the example DEFINE-PACKAGE documents the use of the
COM.INFORMATIMAGO.COMMON-LISP.DICTIONARY package. in 99% of the
packages, this could be known only by parsing the whole package
sources. Granted, in perhaps 1% of the packages, they will try to
use dynamically other packages, not know at compilation time. But
for normal packages, this :USE declaration (along with the other
:FROM declarations) allow to build a dependency graph (makefile) and
to load automatically the needed packages (defsystem), all at once.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> (DEFMACRO SCONC (&REST ARGS) `(CONCATENATE 'STRING ,@ARGS))
> (DEFMACRO DEF-LP-TRANS (HOST PATH &OPTIONAL SUBPATH)
> (SETQ SUBPATH (OR SUBPATH ""))
> `(SETF (LOGICAL-PATHNAME-TRANSLATIONS ,HOST)
> (LIST
> (LIST "**;*" (SCONC ,PATH ,SUBPATH "**/*"))
> (LIST "**;*.*" (SCONC ,PATH ,SUBPATH "**/*.*"))
> (LIST "**;*.*.*" (SCONC ,PATH ,SUBPATH "**/*.*.*"))
> )));;DEF-LP-TRANS
Don't do this. It is fragile, being critically dependent on the
namestring parsing algorithm of the implementations (and indeed being
dependent on that being the same between implementations).
Instead, you can use actual pathnames, with the added bonus that they
stand a chance of being "portable", being vaguely standardized.
(make-pathname :name :wild :type :wild :version :wild
:directory (left-as-an-exercise))
is your friend.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>
> > (DEFMACRO SCONC (&REST ARGS) `(CONCATENATE 'STRING ,@ARGS))
> > (DEFMACRO DEF-LP-TRANS (HOST PATH &OPTIONAL SUBPATH)
> > (SETQ SUBPATH (OR SUBPATH ""))
> > `(SETF (LOGICAL-PATHNAME-TRANSLATIONS ,HOST)
> > (LIST
> > (LIST "**;*" (SCONC ,PATH ,SUBPATH "**/*"))
> > (LIST "**;*.*" (SCONC ,PATH ,SUBPATH "**/*.*"))
> > (LIST "**;*.*.*" (SCONC ,PATH ,SUBPATH "**/*.*.*"))
> > )));;DEF-LP-TRANS
>
> Don't do this. It is fragile, being critically dependent on the
> namestring parsing algorithm of the implementations (and indeed being
> dependent on that being the same between implementations).
>
> Instead, you can use actual pathnames, with the added bonus that they
> stand a chance of being "portable", being vaguely standardized.
> (make-pathname :name :wild :type :wild :version :wild
> :directory (left-as-an-exercise))
> is your friend.
Ok.
(DEFMACRO DEF-LP-TRANS (HOST PATH &OPTIONAL SUBPATH)
(SETQ SUBPATH (OR SUBPATH ""))
(let ((directory (append (pathname-directory path)
(cdr (pathname-directory subpath)))))
`(SETF (LOGICAL-PATHNAME-TRANSLATIONS ,HOST)
(LIST
(LIST "**;*" (make-pathname :directory directory
:name :wild))
(LIST "**;*.*" (make-pathname :directory directory
:name :wild :type :wild))
(LIST "**;*.*.*" (make-pathname :directory directory
:name :wild :type :wild
:version :wild)) )))
);;DEF-LP-TRANS
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
Christophe Rhodes <·····@cam.ac.uk> writes:
> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>
>> (DEFMACRO SCONC (&REST ARGS) `(CONCATENATE 'STRING ,@ARGS))
>> (DEFMACRO DEF-LP-TRANS (HOST PATH &OPTIONAL SUBPATH)
>> (SETQ SUBPATH (OR SUBPATH ""))
>> `(SETF (LOGICAL-PATHNAME-TRANSLATIONS ,HOST)
>> (LIST
>> (LIST "**;*" (SCONC ,PATH ,SUBPATH "**/*"))
>> (LIST "**;*.*" (SCONC ,PATH ,SUBPATH "**/*.*"))
>> (LIST "**;*.*.*" (SCONC ,PATH ,SUBPATH "**/*.*.*"))
>> )));;DEF-LP-TRANS
>
> Don't do this. It is fragile, being critically dependent on the
> namestring parsing algorithm of the implementations (and indeed being
> dependent on that being the same between implementations).
>
> Instead, you can use actual pathnames, with the added bonus that they
> stand a chance of being "portable", being vaguely standardized.
> (make-pathname :name :wild :type :wild :version :wild
> :directory (left-as-an-exercise))
I have to admit that both pathnames and logical pathnames do confuse
me a little bit. In order to actually get some exercise, I have
written the code below into my .sbclrc now. The idea is to add all
directories containing a file with the extension .asd to
asdf:*central-repository*. But I somehow have the feeling that the way
I try to deal with pathnames, files, directories is a little bit
awkward, to say the least. Care to enlighten me how pathnames are
supposed to be used?
;; -*- mode: lisp -*-
(declaim (optimize (speed 0) (safety 3)))
(defconstant my-local-asdf-dir
(make-pathname
:directory '(:absolute "home" "egoge" ".sbcl" "systems")))
;; (I have not read the chapters about the package system yet.)
(defun my-directory-p (pathname)
"Return non-nil, if PATHNAME is a directory."
(declare (type pathname pathname))
(not (pathname-name pathname)))
(defun my-directory-files (directory)
"Return the files in DIRECTORY."
(declare (type pathname directory))
(directory (merge-pathnames
(make-pathname :name :wild :type :wild :version :wild)
directory)))
(defun my-directory-contains-type-p (dpathname type)
"Return non-nil, if DPATHNAME contains a file of TYPE."
(declare (type pathname dpathname)
(type string type))
(assert (my-directory-p dpathname))
(find-if (lambda (file)
(string= (pathname-type file)
type))
(my-directory-files dpathname)))
(defun my-list-dir-tree (dir)
"Return every subdirectory below directory DIR."
(declare (type pathname dir))
(labels ((list-dirs (dir open result)
(let ((subdirs
(loop for f in (my-directory-files dir)
when (my-directory-p f)
collect f)))
(cond
(subdirs (list-dirs (car subdirs)
(append (cdr subdirs)
open)
(nconc subdirs
result)))
(open (list-dirs (car open)
(cdr open)
result))
(t result)))))
(list-dirs dir nil nil)))
;;; asdf
(require 'asdf)
;; Setting up the load-path for asdf.
(setq asdf:*central-registry*
(nconc (loop for d in (my-list-dir-tree my-local-asdf-dir)
when (my-directory-contains-type-p d "asd")
collect d)
asdf:*central-registry*))
Oliver
--
15 Pluviôse an 212 de la Révolution
Liberté, Egalité, Fraternité!