eliot@phoenix.Princeton.EDU (Eliot Handelman) (08/04/88)
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.
rwojcik@bcsaic.UUCP (Rick Wojcik) (08/05/88)
In article <3384@phoenix.Princeton.EDU> eliot@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: rwojcik@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
eliot@phoenix.Princeton.EDU (Eliot Handelman) (08/07/88)
In article <6882@bcsaic.UUCP> rwojcik@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
andy@cayuga.Stanford.EDU (Andy Freeman) (08/07/88)
In article <3424@phoenix.Princeton.EDU> eliot@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: andy@polya.stanford.edu (415) 329-1718/723-3088 home/cubicle