From: GRIFFIN,JEFFREY A
Subject: Beginner ? - What is 'uses'
Date:
Message-ID: <21436@hydra.gatech.EDU>
From: ·······@prism.gatech.EDU (GRIFFIN,JEFFREY A)
Path: prism.gatech.EDU!griffin
Newsgroups: comp.lang.lisp
Subject: Beginner ? - What is 'uses'
Distribution: world
Organization: Georgia Institute of Technology
Keywords: LISP uses beginner question
I am reading a book which has some sample LISP code in it. I am also learning
LISP. It has the following line of code in many of the sections:
(uses 'prog-name)
Is this a standard LISP function? I am using VAX LISP. Any help would be
appreciated. Thanks in advance for the help.
In article <·····@hydra.gatech.EDU> ·······@prism.gatech.EDU (GRIFFIN,JEFFREY A) writes:
>I am reading a book which has some sample LISP code in it. I am also learning
>LISP. It has the following line of code in many of the sections:
>
> (uses 'prog-name)
>
>Is this a standard LISP function? I am using VAX LISP. Any help would be
>appreciated. Thanks in advance for the help.
It's not a standard Common Lisp function. Does your book say what dialect
of Lisp it uses?
My guess is that USES is similar to Common Lisp's REQUIRE (which the ANSI
committee is not currently planning on including in the standard).
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
From: Hal Mueller
Subject: Re: Beginner ? - What is 'uses'
Date:
Message-ID: <11922@helios.TAMU.EDU>
>My guess is that USES is similar to Common Lisp's REQUIRE (which the ANSI
>committee is not currently planning on including in the standard).
What is the politically correct replacement? We're using REQUIRE
routinely; is there a better way?
--
Hal Mueller Remember that the only thing the USAF and USN have
········@orca.tamu.edu ever agreed on is that the Army shouldn't have
······@tamunix.Bitnet fixed-wing aircraft. --Mary Shafer
It seems that ANSI is just dropping the module feature. Apparently we
are all to roll our own. I quote: "XJ13 commented that the file-loading
feature of REQUIRE is not portable, and that the remaining functionality
is easily implemented by user code." (CLtLII p.277) This is true but a
little unfriendly, and invites portability problems.
Vance
In article <·····@pasteur.Berkeley.EDU> ········@fir.Berkeley.EDU (Vance Maverick) writes:
It seems that ANSI is just dropping the module feature. Apparently we
are all to roll our own. I quote: "XJ13 commented that the file-loading
feature of REQUIRE is not portable, and that the remaining functionality
is easily implemented by user code." (CLtLII p.277) This is true but a
little unfriendly, and invites portability problems.
The problem is that including REQUIRE *in the standard* enforces
portability problems. The argument goes like this:
1. The file loading feature of REQUIRE is speced to be non-portable,
"If the pathname argument is nil or is not provided, the sytem will
attempt to determine, in some system-dependent manner, which files
to load."
2. Some current implementations such as TI Explorer and Coral Common
Lisp (now Allegro Common Lisp for the Mac or some such), include
and depend heavily on powerful, useful, very system-dependent
implementations of the above. For example:
in Coral (require 'quickdraw) is the standard way to access the
Mac-specific graphics extensions.
3. A proposal to delete the second argument of REQUIRE and restrict it
to just the portable functionality was very strongly resisted by
the implementors who would be hurt by it.
4. (here is where it gets tricky) Standardizing REQUIRE including the
non-portable parts is a portability trap. Let's say you're
developing what you fondly think will be a large portable
application on an Explorer. Since REQUIRE is portable, you use it
in lots of places to ensure that your inter-module dependencies are
satisfied. It works just fine; everything you need is always
correctly loaded. Now you move your finished application to a
major stock-hardware Common Lisp (or worse, give it to someone else
to move). Everything breaks with a complex, undoumented network of
unsatisfied dependencies because REQUIRE on the Explorer not only
check to see if dependencies were satisfied, it fixed them up with
system-dependent magic. This is not a bad feature, but it *is* a
non-portable one. What fooled you was the official lie that
REQUIRE was a portable function that you could safely use in
portable code.
5. (the important part) Removing REQUIRE from the standard does not
mean that implementors must, or even should, remove it from their
implementations. It merely means that it should be described as
what it is: an implementation dependent extension. (The standard
does require that such symbols live in a package other than
COMMON-LISP. However, USER can use system-dependent packages so
authors of non-portable code shouldn't have to notice any change.)
--
dan
In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: ·······@encore.com
From: Jeff Dalton
Subject: Re: What replaces REQUIRE
Date:
Message-ID: <4133@skye.ed.ac.uk>
In article <·····················@xenna.encore.com> ·······@encore.com (Dan L. Pierson) writes:
>In article <·····@pasteur.Berkeley.EDU> ········@fir.Berkeley.EDU (Vance Maverick) writes:
> It seems that ANSI is just dropping the module feature. Apparently we
> are all to roll our own. I quote: "XJ13 commented that the file-loading
> feature of REQUIRE is not portable, and that the remaining functionality
> is easily implemented by user code." (CLtLII p.277) This is true but a
> little unfriendly, and invites portability problems.
>
>The problem is that including REQUIRE *in the standard* enforces
>portability problems. The argument goes like this:
>
>1. The file loading feature of REQUIRE is speced to be non-portable,
> "If the pathname argument is nil or is not provided, the sytem will
> attempt to determine, in some system-dependent manner, which files
> to load."
[And then: some systems actually do determine which files to load in
an interesting way. Some programmers might think that, because
REQUIRE is part of standard CL, this interesting behavior is standard
too. But it isn't. A proposal to make REQUIRE portable and thus rule
out the interesting behavior provided by some systems was resisted.
So it was decided to not make anything about REQUIRE standard and let
implementations do whatever they wanted (as an extension to std CL).]
I think this is the best explanation posted so far (thanks Dan!),
and this is not the first time the issue has come up.
On the whole, I think it probably _is_ better to take REQUIRE out
of standard CL. It was confusing to call what PROVIDE and REQUIRE
did "modules" (given what module means in languages that "have
modules", such as Modula-II), and it was far from clear that
PROVIDE and REQUIRE would fit into any good, portable system
defining and building tools that were eventually developed.
It used to be possible to write large-ish Franz Lisp programs using
something sort of like REQUIRE (called "environment") together with a
Makefile (Franz is Unix after all). In Common Lisp I eventually gave
up and wrote a simple DEFSYSTEM. Still, I think REQUIRE could be used
in that way, and the basic functionality of being able to tell if
something has already been loaded is so generally useful that I think
it's a shame not to have some standard way to do it.
Moreover, it _is_ possible to use REQUIRE portable, or at least
that's my interpretation of CLtL (and that of some other people
who have posted in the past). In CLtL II, page 278, we find:
The _pathname_ argument, if present, is a pathname or a list of
pathnames whose files are to be loaded in order, left to right.
If the _pathname_ argument is NIL or not provided, the system
will attempt to determine, in some system-dependent manner,
which files to load.
I take it that this implies that if the _pathname_ argument is
provided and is not NIL, then the system will load the specified
file(s) and NOT attempt to determine, in some system-dependent
manner, which files to load. I realize that it's possible to
argue that when something says "If X then Y. If not X then Z"
that this doesn't strictly imply that if X, then Z won't be
done; but I think such a reading would be a little perverse.
We could go on to say that _pathnames_ aren't portable, but I
don't think that's very convincing.
So, I think it's understandable that some people would think X3J13's
decision to de-standardize REQUIRE was a bit arbitrary and against
the interests of users. I think it's understandable but, as I said,
on balance I think the decision was correct. All that's lacking is
a complete explanation, which I think we now almost have.
-- Jeff
In article <·····@helios.TAMU.EDU> ········@orca.tamu.edu (Hal Mueller) writes:
>>My guess is that USES is similar to Common Lisp's REQUIRE (which the ANSI
>>committee is not currently planning on including in the standard).
>
>What is the politically correct replacement? We're using REQUIRE
>routinely; is there a better way?
REQUIRE is being removed because the behavior when the module isn't already
loaded is very implementation-dependent, so it's virtually impossible to
use it portably. Some systems treat the module name as a file name, looked
up via some implementation-dependent search path; others treat it as a
defsystem-style system name, and load the system; and others use some other
mechanism. If you supply a second argument, the pathname would be
system-dependent (actually, we have since added logical pathnames to the
language, so maybe this reason is no longer valid).
Our conclusion was that since it's not possible to use REQUIRE portably,
you might as well use an implementation-provided mechanism directly. When
current implementations are converted to be ANSI-conformant, they'll
presumably retain PROVIDE and REQUIRE in their extension packages, so
converting code should just be a matter of adding package prefixes if
necessary.
And if you're using the second argument to REQUIRE, you can easily define
it yourself as
(defun require (module pathname)
(unless (member module *modules*)
(load pathname)))
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
From: Mark Kantrowitz
Subject: Re: REQUIRE (was Re: Beginner ? - What is 'uses')
Date:
Message-ID: <11891@pt.cs.cmu.edu>
In article <·····················@Think.COM> ······@think.com (Barry Margolin) writes:
>REQUIRE is being removed because the behavior when the module isn't already
>loaded is very implementation-dependent, so it's virtually impossible to
>use it portably. Some systems treat the module name as a file name, looked
>up via some implementation-dependent search path; others treat it as a
>defsystem-style system name, and load the system; and others use some other
>mechanism. If you supply a second argument, the pathname would be
>system-dependent (actually, we have since added logical pathnames to the
>language, so maybe this reason is no longer valid).
Why didn't X3J13 decide upon some standard definition of REQUIRE's
behavior? For example, have a global variable *central-registry* which
contains the directory where modules are stored?
My impression is that lisps use REQUIRE/PROVIDE/*MODULES* for two
separate purposes:
(1) Loading in implementation dependent packages, such as
graphics code, CLOS, streams code, and the like.
(2) Providing some sort of "MAKE" facility for common lisp.
There is nothing one can do about the former, since those uses of
REQUIRE are necessarily implementation dependent. However, the latter
should not be implementation dependent, because that would interfere
with generating portable code. By throwing modules out of the
language, X3J13 has given up the chance to establish standards for
such a "MAKE" facility and thereby ensure portability of system
definitions. In heterogeneous computing environments, where one runs
different lisps on different machines, or even on the same machine,
portability of system definitions is a must.
Anyway, I've written a portable common lisp implementation of systems
and modules, which is available free via anonymous ftp from
a.gp.cs.cmu.edu in the directory /usr/mkant/Public/. (cd to the
directory in one unit, since security restrictions prevent access to
intermediate directories.) The relevant files are
defsystem.{lisp,ps,text}. The documentation is old and is currently
being revised.
--mark
In article <·····@pt.cs.cmu.edu> ·····@glinda.oz.cs.cmu.edu (Mark Kantrowitz) writes:
>Why didn't X3J13 decide upon some standard definition of REQUIRE's
>behavior? For example, have a global variable *central-registry* which
>contains the directory where modules are stored?
How would a standard global variable help? The user would still have to
use implementation- and site-dependent forms to put entries into it.
>My impression is that lisps use REQUIRE/PROVIDE/*MODULES* for two
>separate purposes:
> (1) Loading in implementation dependent packages, such as
> graphics code, CLOS, streams code, and the like.
> (2) Providing some sort of "MAKE" facility for common lisp.
>There is nothing one can do about the former, since those uses of
>REQUIRE are necessarily implementation dependent. However, the latter
>should not be implementation dependent, because that would interfere
>with generating portable code. By throwing modules out of the
>language, X3J13 has given up the chance to establish standards for
>such a "MAKE" facility and thereby ensure portability of system
>definitions.
We had already passed the point where we were willing to consider adding
new features to the language. Perhaps if there were a fully-designed fix
for REQUIRE at the time we might have been able to include it, but we
didn't want to start a new project to design the fix.
X3J13 has already added lots of new stuff the the language (CLOS,
conditions, character repertoires, pretty-printer control). I think
built-in system-building tools are going to have to wait for the next
revision of the standard. ANSI CL includes better pathname primitives,
including logical pathnames, with the goal being that it should be easier
to write portable system-building tools.
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
From: Jeff Dalton
Subject: Re: Beginner ? - What is 'uses'
Date:
Message-ID: <4095@skye.ed.ac.uk>
>I am reading a book which has some sample LISP code in it. I am also learning
>LISP. It has the following line of code in many of the sections:
>
> (uses 'prog-name)
>
>Is this a standard LISP function? I am using VAX LISP. Any help would be
>appreciated. Thanks in advance for the help.
It's not standard Lisp. I think I've seen this book, though I can't
remember for sure which one it is. (Maybe Gadzer and Mellish's book
on Natural Language?). The idea is to say that inorder to run the
things in this file (where the uses appears), you also need the things
in that other file.
-- Jeff