Re: undefined (asdf:system-license on clisp+cywgin

Marco Antoniotti <marcoxa@xxxxxxxxx> writes:

On Mar 14, 4:49 pm, Duane Rettig <du...@xxxxxxxxx> wrote:
Marco Antoniotti <marc...@xxxxxxxxx> writes:
On Mar 14, 10:07 am, Mirko.Vuko...@xxxxxxxxx wrote:
Hi,

I am trying to load nlisp on my clisp+cygwin insallation, and it is
breaking on the undefined function asdf:system-license.

(It -- the nlisp package -- is loading flawlessly on linux+sbcl)

I looked in asdf.lisp, and I see that system-license is an exported
function, but I don't see it defined anywhere.  Same with a few
others, like unix-dso for example.

I am further puzzled by the hash marks in the package definition:
(defpackage #:asdf
  (:export #:defsystem #:oos #:operate #:find-system #:run-shell-
command
           #:system-definition-pathname #:find-component ; miscellaneous
           #:hyperdocumentation #:hyperdoc

I guess that I am missing something, but what?

thank you,

Mirko

They are a unaesthetic consequence of the introduction of case
sensitivity in the reader by Franz Allegro.

No, they're not.

Defpackage accepts "string designators" in various places, which
allows for strings, symbols (for their names), and even single
characters.

True, but using symbols in the current package is conflict prone and
using keyword is something I refrain from (incidentally, a *lot* of
people just use keywords when they could use a regular symbol; witness
some of the HTML libraries out there).

You make my point for me perfectly. Whether a user wants to use :foo
or 'foo or #:foo, or whether he wants to shout "FOO" and exclude case
sensitive lisp modes (not only Franz and Clisp "modern" mode lisps,
but also some readtable case modes as well) is really a personal
preference. Only one of these options is exclusionary, though, and
since you brought up the aesthetic nature of the option in question,
consider the aesthetics of shouting in source code: even many critics
of case-sensitivity will refrain from writing all caps in source code,
and will bend over backwards to suggest ways to allow writing source
without having to sit on the shift key (or to turn the caps-lock on) a
la readtable invert or preserve case-modes. Again, it's all a matter
of taste.

It is true that defpackage forms operate better in
Franz's case-sensitive lisp when the string designators are symbols,
but that is not the reason why the hash marks are there; the form
could just as easily have been:

(defpackage :asdf
  (:export :defsystem :oos :operate :find-system ...

So now let's talk about the _real_ reason why the hash marks are
there:  The hash-mark versions of the symbols are not interned, but
the ones without hash-marks are.  This means that when the compiling
lisp compiles the file and loads it as well, your lisp is left with
a whole lot of keywords interned that would not have had to be there,
like :defsystem, :oos, :operate, etc.  This is in _addition_ to the
actual symbols that were being exported: 'asdf:defsystem, 'asdf:oos,
etc.  On the other hand, the uninterned symbols are quietly gc'd away,
and your lisp environment is kept clean.

We have discussed this before. It is true that ACL and most
implementations do not have this "symbol leak" feature/bug. But,
AFAIR, it is not mandated by the standard.

No, it is not mandated, but it is certainly suggested:

"The macroexpansion of defpackage could usefully canonicalize the
names into strings, so that even if a source file has random symbols
in the defpackage form, the compiled file would only contain strings."

Of course, this is not itself a sugestion that the macroexpansion turn
the string designators into other string designators, but since it is
only a suggestion, an implememtation is free to take that leap.

Mitigating this, on the other hand, is the fact that many CL
implementations do not save the original forms in compiled code, so
the keywords are treated _as_ _if_ they had been uninterned symbols.
So if it is your habit to compile files and then load them into
various lisps (other than the compiling lisp), or in other words if
you tend to compile a system with a compiling lisp and then build it
by loading up the fasl files, your building lisp will not get
contaminated with the keywords, and you can go ahead and use the
keyword form instead.

This is all fine of course, but then again, using plain strings in
DEFPACKAGE is, IMHO, safer for ANSI coding.

Safer? Why safer? Did you really mean to use this word? In fact,
with the availability of readtable-case in a standard ansi lisp, I
would think that strings are actually _less_ safe than symbols,
because with any symbols the defpackage form would tend to match
whatever readtable-case translation you might have in effect, whereas
with strings, you must _know_ what the current readtable-case is.

PS. Of course, the choice of making ANSI CL case-boggling (for lack
of a better adjective :) ) has always been one of those unexplained
mysteries of the universe. :)

Remember, as Kent has explained many times before, that ANSI CL is in
fact a case-sensitive system; it just happens to have a reader which
is by default (not case-insensitive, but) case-folding, and a printer
which supports those folding options.

--
Duane Rettig duane@xxxxxxxxx Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
.

Relevant Pages

  • Re: undefined (asdf:system-license on clisp+cywgin
    ... Sometime I shout strings and sometimes ... Franz's case-sensitive lisp when the string designators are symbols, ...  This means that when the compiling ... whatever readtable-case translation you might have in effect, ...
    (comp.lang.lisp)
  • Re: `Standalone Executables
    ... the details of compiling, loading, and running Lisp. ... from the shell prompt, make a directory to keep super-frob ... instructions on the webpage are literal instructions. ...
    (comp.lang.lisp)
  • Re: best environment for learning Lisp?
    ... Just type in your Lisp prompt: ... ; compiling ... have figured out how to compile, load, and run a script in SLIME. ... sort of programming too, as you have found out, but you are missing out ...
    (comp.lang.lisp)
  • Re: undefined (asdf:system-license on clisp+cywgin
    ... people just use keywords when they could use a regular symbol; ... Franz's case-sensitive lisp when the string designators are symbols, ...  This means that when the compiling ...
    (comp.lang.lisp)
  • Re: Homoiconicism
    ... of the data types supported by the language. ... I don't understand why the case of characters and strings is ... Lisp source code can be thought of as being represented by ...
    (comp.lang.lisp)