Many thanks to all those who answered my query about the lucid start-up
file. The conclusion was that Lucid looks for a file called lisp-init.lisp.
My next question is this: how can I access the definition of an
interpreted function? In KCl #'foo results in (lambda-block foo ...)
which I can then treat as a list. But in Lucid I get #<intrepreted-function
FOO ... (and then its address)>, which can't be treated as a list. How do
I make the sharp-sign go away? I don't want it, and I don't see what it's
supposed to be doing except cluttering up the definition and preventing
it from being pretty-printed.
I would like to note here, for future lisp developers, the following. I am
not a lisp developer, merely one of that apparently very small set of people
who use lisp as their preferred language. I've always found that looking
at the source code is essential to understanding how a lisp works. Because
Lucid has a theory about trade-secrets I find that they've succeeded in
producing something that amounts to a vast unpenetrable program. Their manual
costs several hundreds of dollars and we have two copies in this university
which are no allowed to circulate. Lucid has no online documentation, and
APROPOS is generally the only way that I have of guessing what a function
might be called, or what arguments it takes, and even then I usually have
to rely on guesswork or intuition.
I feel that lisp ought to be wide enough open so that I can see exactly
what functions like DEFUN are doing, how the information is stored, etc.
I really resent the lucid black-box approach. Lucid is anything but lucid.
Franz is lucid. KCl is lucid. Lucid is opaque.
From: Rick Wojcik
Subject: Re: Another Lucid Question
Date:
Message-ID: <6882@bcsaic.UUCP>
In article <····@phoenix.Princeton.EDU> ·····@phoenix.Princeton.EDU (Eliot Handelman) writes:
>My next question is this: how can I access the definition of an
>interpreted function? In KCl #'foo results in (lambda-block foo ...)
>which I can then treat as a list. But in Lucid I get #<intrepreted-function
>FOO ... (and then its address)>, which can't be treated as a list. How do
>I make the sharp-sign go away? I don't want it, and I don't see what it's
>supposed to be doing except cluttering up the definition and preventing
>it from being pretty-printed.
>
Try (grindef <function>). It's a macro, so you don't have to quote the
function name. Two of us just wasted about half an hour trying to track
this information down earlier today. You would think that it would be
referenced in the manual's index under 'function' somewhere. But Nooooo!!
That would be too easy. The method we used to track down this information
was to chance upon a colleague who happened to remember it. The manual
only tells you about functions that retrieve the useless #<interpreted-function
form. We have found that Lucid's documentation is most useful when you
already know the information that you are trying to look up. ;-)
--
Rick Wojcik csnet: ·······@boeing.com
uucp: uw-beaver!ssc-vax!bcsaic!rwojcik
address: P.O. Box 24346, MS 7L-64, Seattle, WA 98124-0346
phone: 206-865-3844
In article <····@bcsaic.UUCP> ·······@bcsaic.UUCP (Rick Wojcik) writes:
>>My next question is this: how can I access the definition of an
>>interpreted function? [...]
>Try (grindef <function>).
Just as I thought ... someone forsaw the need for this.
>was to chance upon a colleague who happened to remember it. The manual
>only tells you about functions that retrieve the useless #<interpreted-function
>form. We have found that Lucid's documentation is most useful when you
>already know the information that you are trying to look up. ;-)
I once spent the better part of a day trying to find the Lucid documentation
of a function that was reporting an error in connection with the foreign-
function loader (something pertaining to discsave, or whatever it's called) --
it was undocumented. I think this raises a couple of questions concerning
the question of standards, packages and documentation. What Steele describes
is essentially the USER package, which is what standard lisp documentation tends
to describe. It turns out that there are an inordinate number of procedures
in SYSTEM (or in lucid, LUCID) that you might like to know about, but which
remain undocumented because they're "hidden," that is, belong to some package
other than USER. Presumably this should not affect anybody's code who keeps
to the Steele set, or at least it argues for compatibility.
But if you're not necessarily concerned with compatibilty -- and I know that
this is a moot point, and some people will frown upon this -- if you just
*happen* to be writing LISP, I think it makes tremendous sense to use the
particular lisp you have available to its full extent, without bothering
to rewrite macros that actually exist in SI but which were excluded from
Steele, and hence which are never disclosed. But these examples from Lucid
are particularly annoying.
I just want to make a practical suggestion to lisp documenters: I think
it makes sense to indicate the existence of EVERYTHING available in the lisp,
in EVERY package, regardless whether or not it's felt that the user has
the right to use these things are not. And considering the volume and expense
of the Lucid doc, I can't see why this was not done. Counterarguments?
- Eliot
In article <····@phoenix.Princeton.EDU> ·····@phoenix.Princeton.EDU
(Eliot Handelman) writes:
>I just want to make a practical suggestion to lisp documenters: I think
>it makes sense to indicate the existence of EVERYTHING available in the lisp,
>in EVERY package, regardless whether or not it's felt that the user has
>the right to use these things are not. And considering the volume and expense
>of the Lucid doc, I can't see why this was not done. Counterarguments?
Anything they tell you about the internals is one more thing they
can't change easily in the next release; it's also one more thing they
have to support in the current release. (The internal stuff may work
the way that they're using it, but it may not work the way that you
want to use it.)
-andy
UUCP: {arpa gateways, decwrl, uunet, rutgers}!polya.stanford.edu!andy
ARPA: ····@polya.stanford.edu
(415) 329-1718/723-3088 home/cubicle
From: Will Clinger
Subject: exposing the implementation (was Re: Another Lucid Question)
Date:
Message-ID: <2912@tekcrl.CRL.TEK.COM>
In article <····@phoenix.Princeton.EDU> ·····@phoenix.Princeton.EDU (Eliot Handelman) writes:
>I just want to make a practical suggestion to lisp documenters: I think
>it makes sense to indicate the existence of EVERYTHING available in the lisp,
>in EVERY package, regardless whether or not it's felt that the user has
>the right to use these things are not. And considering the volume and expense
>of the Lucid doc, I can't see why this was not done. Counterarguments?
People who use procedures and variables that are intended to be private to
an implementation might get a little upset if the feature they rely upon
in Lisp version 7.14 disappears in version 7.15. The documentation could
say of such features that they should not be relied upon and that anyone
who uses them is crazy, but some people would still interpret the fact
that they are documented at all as an implied warranty of stability. Any
system that documented such features would be inviting the wrath of its
users.
It also costs a lot of money to generate pretty, polished documentation
that can be distributed to users. For system internals, that money would
be better spent on ugly, rough, but more complete internal documentation.
The customer would ultimately benefit from greater reliability and more
timely enhancements.
All things considered, it seems to me that users are much better off when
they don't know anything about ephemeral system internals. The fact that
they can easily learn about undocumented system quirks by browsing the
package system is just one more sign that the package system is not a
satisfactory solution for programming-in-the-large.
William Clinger
Semantic Microsystems, Inc.
From: Ritchey Ruff
Subject: Re: exposing the implementation (was Re: Another Lucid Question)
Date:
Message-ID: <5947@orstcs.CS.ORST.EDU>
In article <····@tekcrl.CRL.TEK.COM> ·····@tekchips.CRL.TEK.COM (Will Clinger) writes:
>In article <····@phoenix.Princeton.EDU> ·····@phoenix.Princeton.EDU (Eliot Handelman) writes:
>>[...] I think
>>it makes sense to indicate the existence of EVERYTHING available in the lisp,
>>in EVERY package, regardless whether or not it's felt that the user has
>>the right to use these things are not. [...]
>[...]
>All things considered, it seems to me that users are much better off when
>they don't know anything about ephemeral system internals. [...]
a flame, then lucidity ( ;-) follow.
***flame on***
*IF* a full *layered* interface were provided and fully documented
for SYSTEM: (et al, just as it is for USER: now via CLtL) then
I would have no gripes, but when you *can't* do things easily
(or at all) until you grope around in the packages to find out
how to talk to the underlying OS in a particular way, or have to
use the foreign function interface and write you own system interface
code, or call the hotline and ask then get told "your not suppose to
do that!" ; that's when I think the mentality as expressed by Will Clinger
gripes me. "Oh, you don't *WANT* to know about those nasty
things, just tell us what the problem is and we will fix it, or
give you a workaround, or tell you how to do it right, or..."
It gives the company lots of chance to make money from supporting
products, because without a hotline to cry for help you are
in deep yogart many times...
***flame off***
sorry, but I've been hacking common lisp's with poorly documented
features (and sometimes the lack of documentation allows a company
to claim a bug as a feature---it wasn't documented to act in any
given way, so we *claim* it's working right!). I agree with Will
that the "typical enduser" should not be privy to this level of
detail, but as a developer/researcher I *NEED* to be---if I want
to be able to do what I want to at all and have it look nice (and
give people who see it good feelings about XYZ's version of CL---
wow, look what they did using *that* version of CL). Developers
and researchers often need MUCH more detailed info then the typical
*end user* (hmmm, anyone *EVER* ment a typical enduser???).
sorry again to flame, but you pressed my button ;-)
--ritchey ruff ········@cs.orst.edu -or- ...!tektronix!orstcs!ruffwork