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
On Mar 14, 10:07 am, ·············@gmail.com 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.
You better use them or use strings instead.
Cheers
--
Marco
Marco Antoniotti <·······@gmail.com> writes:
> On Mar 14, 10:07�am, ·············@gmail.com 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. 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.
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.
--
Duane Rettig ·····@franz.com 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
On Mar 14, 4:49 pm, Duane Rettig <·····@franz.com> wrote:
> Marco Antoniotti <·······@gmail.com> writes:
> > On Mar 14, 10:07 am, ·············@gmail.com 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).
> 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.
> 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.
Cheers
--
Marco
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. :)
Marco Antoniotti <·······@gmail.com> writes:
> On Mar 14, 4:49�pm, Duane Rettig <·····@franz.com> wrote:
>> Marco Antoniotti <·······@gmail.com> writes:
>> > On Mar 14, 10:07�am, ·············@gmail.com 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 ·····@franz.com 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
On Mar 14, 8:50 pm, Duane Rettig <·····@franz.com> wrote:
> Marco Antoniotti <·······@gmail.com> writes:
> > On Mar 14, 4:49 pm, Duane Rettig <·····@franz.com> wrote:
> >> Marco Antoniotti <·······@gmail.com> writes:
> >> > On Mar 14, 10:07 am, ·············@gmail.com 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.
I have not set up my mind yet. Sometime I shout strings and sometimes
I hash the uninterned symbols. I found both alternatives not so nice.
> >> 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.
Maybe the word "safer" is incorrect. And you are right. When you use
strings in DEFPACKAGE forms you'd better have control and knowledge of
the readtable.
>
> > 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.
None of which was forward looking when defined (and no: I don't buy
the argument that a standard should only crystallize what is there)
and very very counterintuitive to handle. The proof being Allegro
ANSI-incompatible Modern mode. Bottom line: I like more and more my
characterization of CL being 'case-boggling' :)
Cheers
--
Marco
Marco Antoniotti <·······@gmail.com> writes:
> On Mar 14, 8:50�pm, Duane Rettig <·····@franz.com> wrote:
>> 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.
>
> I have not set up my mind yet. Sometime I shout strings and sometimes
> I hash the uninterned symbols. I found both alternatives not so nice.
Yes, taste can sometimes be driven by negatives :-)
>> > 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.
>
> None of which was forward looking when defined (and no: I don't buy
> the argument that a standard should only crystallize what is there)
> and very very counterintuitive to handle. The proof being Allegro
> ANSI-incompatible Modern mode. Bottom line: I like more and more my
> characterization of CL being 'case-boggling' :)
Well, Franz's case sensitivity mode in Allegro CL was created long
before Ansi CL - it came from a long tradition in Franz Lisp (a
very popular lisp that was different from Allegro CL, and for which
the company was named). That lisp had a mostly MACLisp flavor, but was
housed in a BSD Unix environment, which was mostly case-sensitive (I
say "was" because now Apple have a filesystem on Freebsd that is
"case-preserving", which means that when you create a file it takes on
the case originally assigned to its name, but searches on the filename
are truly case insensitive). Anyway, coming from a background where
we considered the wysiwyg approach to be more esthetic, and having
a fairly large customer base which also liked working in that mode, we
pushed hard for our point of view on the committee, but we didn't have
enough clout and we lost. So we continued to maintain two different
lisps (in reality, they are the same lisp but they can only be in one
mode at a time), and we simply make both modes available as the
customer sees fit. For those people who find the non-ansi version
distaseful, no problem: just use the ansi version...
--
Duane Rettig ·····@franz.com 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
On Mar 15, 8:49 am, Duane Rettig <·····@franz.com> wrote:
> Marco Antoniotti <·······@gmail.com> writes:
> > On Mar 14, 8:50 pm, Duane Rettig <·····@franz.com> wrote:
> >> 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.
>
> > I have not set up my mind yet. Sometime I shout strings and sometimes
> > I hash the uninterned symbols. I found both alternatives not so nice.
>
> Yes, taste can sometimes be driven by negatives :-)
>
> >> > 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.
>
> > None of which was forward looking when defined (and no: I don't buy
> > the argument that a standard should only crystallize what is there)
> > and very very counterintuitive to handle. The proof being Allegro
> > ANSI-incompatible Modern mode. Bottom line: I like more and more my
> > characterization of CL being 'case-boggling' :)
>
> Well, Franz's case sensitivity mode in Allegro CL was created long
> before Ansi CL - it came from a long tradition in Franz Lisp (a
> very popular lisp that was different from Allegro CL, and for which
> the company was named). That lisp had a mostly MACLisp flavor, but was
> housed in a BSD Unix environment, which was mostly case-sensitive
I know. I was able to use it on BSD and even on a port to VMS. :)
> (I
> say "was" because now Apple have a filesystem on Freebsd that is
> "case-preserving", which means that when you create a file it takes on
> the case originally assigned to its name, but searches on the filename
> are truly case insensitive). Anyway, coming from a background where
> we considered the wysiwyg approach to be more esthetic, and having
> a fairly large customer base which also liked working in that mode, we
> pushed hard for our point of view on the committee, but we didn't have
> enough clout and we lost. So we continued to maintain two different
> lisps (in reality, they are the same lisp but they can only be in one
> mode at a time), and we simply make both modes available as the
> customer sees fit. For those people who find the non-ansi version
> distaseful, no problem: just use the ansi version...
I find Modern mode very appealing, but I try to stick to ANSI. It is
one unfortunate twist of history that Franz did not have enough clout
at the time of ANSI CL.
Cheers
--
Marco
Duane Rettig <·····@franz.com> writes:
> 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."
Is there an interesting reason why ACL does this canonicalization for
DEFPACKAGE but not IN-PACKAGE?
Zach
Zach Beane <····@xach.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
>> 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."
>
> Is there an interesting reason why ACL does this canonicalization for
> DEFPACKAGE but not IN-PACKAGE?
Well, in-package has only one argument, so I assume you mean that.
Actually, defpackage makes an exception for the name argument; if the
name is a symbol but _not_ a keyword, it will perform the
canonicalization, but if it is a keyword, it leaves it as a keyword.
I think the reason why the name argument is less complete is due to
the law of diminishing returns; if one defpackage form has 3000
symbols, all of which would have had keywords that got stored in
addition to the symbols which were being imported or exported, then
that seems like a worthwhile optimization to make. But each of a
defpackage form and an in-package form has only one name argument, so
the optimization doesn't buy much for each, compared to the many
symbols that get operated on elsewhere in the defpackage form.
--
Duane Rettig ·····@franz.com 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
Duane Rettig <·····@franz.com> writes:
> But each of a defpackage form and an in-package form has only one
> name argument, so the optimization doesn't buy much for each,
> compared to the many symbols that get operated on elsewhere in the
> defpackage form.
I mean more in the sense of breaking when loading FASLs. If a source
file has (IN-PACKAGE FOO) and the file is compiled in ACL with
*PACKAGE* as UNRELATED-PACKAGE-BAR, the resulting FASL file will
reference a symbol in a package that might not exist when the fasl is
loaded in the future. Converting the in-package argument earlier
avoids the problem.
Zach
Zach Beane <····@xach.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
>> But each of a defpackage form and an in-package form has only one
>> name argument, so the optimization doesn't buy much for each,
>> compared to the many symbols that get operated on elsewhere in the
>> defpackage form.
>
> I mean more in the sense of breaking when loading FASLs. If a source
> file has (IN-PACKAGE FOO) and the file is compiled in ACL with
> *PACKAGE* as UNRELATED-PACKAGE-BAR, the resulting FASL file will
> reference a symbol in a package that might not exist when the fasl is
> loaded in the future. Converting the in-package argument earlier
> avoids the problem.
I'm not following you here. Can you give an example?
--
Duane Rettig ·····@franz.com 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
Duane Rettig <·····@franz.com> writes:
>> I mean more in the sense of breaking when loading FASLs. If a source
>> file has (IN-PACKAGE FOO) and the file is compiled in ACL with
>> *PACKAGE* as UNRELATED-PACKAGE-BAR, the resulting FASL file will
>> reference a symbol in a package that might not exist when the fasl is
>> loaded in the future. Converting the in-package argument earlier
>> avoids the problem.
>
> I'm not following you here. Can you give an example?
Here are three files that illustrate the problem:
;;; a.lisp
(defpackage a
(:use cl))
(in-package a)
(defun a () 'a)
;;; b.lisp
(defpackage b
(:use cl))
(in-package b)
(compile-file "a")
;;; c.lisp
(defpackage c
(:use cl))
(in-package c)
(delete-package "B")
(load "a")
Then:
(load "a")
(load "b")
(load "c")
You'll get an error about the B package not existing. If ACL's
IN-PACKAGE did the same useful string-canonicalization that DEFPACKAGE
does, there would be no error.
This is a short, contrived example, but I'm not just picking nits. I
used to get this error all the time when using CL-PDF in SBCL, since
symbols from random-seeming packages would linger into the fasls and
cause load-time problems. I persuaded the SBCL folks to apply a patch
that stringifies IN-PACKAGE's argument, so I don't think about it much
any more. http://xach.livejournal.com/75442.html is something I wrote
on the topic at the time.
Zach
Zach Beane <····@xach.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
>>> I mean more in the sense of breaking when loading FASLs. If a source
>>> file has (IN-PACKAGE FOO) and the file is compiled in ACL with
>>> *PACKAGE* as UNRELATED-PACKAGE-BAR, the resulting FASL file will
>>> reference a symbol in a package that might not exist when the fasl is
>>> loaded in the future. Converting the in-package argument earlier
>>> avoids the problem.
>>
>> I'm not following you here. Can you give an example?
>
> Here are three files that illustrate the problem:
[elided: example showing symbol being used for its name but unable to
be built because its package is deleted]
> You'll get an error about the B package not existing. If ACL's
> IN-PACKAGE did the same useful string-canonicalization that DEFPACKAGE
> does, there would be no error.
>
> This is a short, contrived example, but I'm not just picking nits. I
> used to get this error all the time when using CL-PDF in SBCL, since
> symbols from random-seeming packages would linger into the fasls and
> cause load-time problems. I persuaded the SBCL folks to apply a patch
> that stringifies IN-PACKAGE's argument, so I don't think about it much
> any more. http://xach.livejournal.com/75442.html is something I wrote
> on the topic at the time.
OK, I see, now; it doesn't have anything to do with case. It's a good
example, and I can't think of any reason why the change shouldn't be
made.
--
Duane Rettig ·····@franz.com 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
On Mar 14, 11:49 am, Duane Rettig <·····@franz.com> wrote:
> Marco Antoniotti <·······@gmail.com> writes:
> > On Mar 14, 10:07 am, ·············@gmail.com 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. 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.
>
(I was rash in my previous reply to Marco). But still confused. I
thought symbols are interned in a package. So, how can there be extra
symbols to delete?
By that I mean, that if
(in-package :foo)
I define some symbols, they are in that foo's namespace. Where does
the other copy (the one that the #-mark labels for deletion) live?
Mirko
On Mar 14, 6:11 am, Marco Antoniotti <·······@gmail.com> wrote:
> On Mar 14, 10:07 am, ·············@gmail.com 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.
>
> You better use them or use strings instead.
>
> Cheers
> --
> Marco
So, are you saying that the hash marks imply upper-case? I seem to
recall something like that. I'll go back to PCL.
My second question had to do about "missing" definitions of some
exported symbols in asdf -- they are declared as exported, but I could
not find the definitions in the file? As I noted, the package loads
fine in sbcl under unix. So the "missing" refers to my lack of
comprehension. Any pointers?
Thanks,
Mirko
On Mar 14, 1:19 pm, ·············@gmail.com wrote:
> On Mar 14, 6:11 am, Marco Antoniotti <·······@gmail.com> wrote:
>
>
>
>
>
> > On Mar 14, 10:07 am, ·············@gmail.com 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.
>
> > You better use them or use strings instead.
>
> > Cheers
> > --
> > Marco
>
> So, are you saying that the hash marks imply upper-case? I seem to
> recall something like that. I'll go back to PCL.
The #: notation implies that the next token is converted to an
uninterned symbol. The name is converted to a string, and then a
symbol is manufactured (as if by a call to MAKE-SYMBOL) with that
name. The symbol is not entered into any package, i.e. remains
uninterned.
The upper casing is a consequence of how the token is turned into the
string that becomes the symbol's name. This is controlled by a state
flag in the current *readtable*. The reader can preserve case, fold to
upper case, or fold to lower case.
If either folding behavior is in effect (upper or lower), the
consequence is that the notations Foo and fOO denote the same symbol.
The actual name may be "foo" or "FOO". If preserving behavior is
ineffect, they denote different symbols, named "Foo" and "fOO".
The case behavior doesn't depend on the hash or the colon. In
defpackage, you can equally well use keyword symbols, or ordinary
symbols: (defpackage asdf ...). The symbols are exploited strictly for
their names, not for their identity as symbols.
Kaz Kylheku <········@gmail.com> wrote:
+---------------
| The upper casing is a consequence of how the token is turned into the
| string that becomes the symbol's name. This is controlled by a state
| flag in the current *readtable*. The reader can preserve case, fold to
| upper case, or fold to lower case.
+---------------
Or :INVERT, in which event mixed-case (e.g., CamelCase) symbols
are *not* case-inverted:
> (setf (readtable-case *readtable*) :invert)
:invert
> (mapcar #'symbol-name '(foobar FOOBAR FooBar))
("FOOBAR" "foobar" "FooBar")
>
This is IMHO often the most convenient of the non-default
READTABLE-CASE values to use, especially when trying to use
the Lisp reader on data containing mixed-case symbols.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Mar 14, 2:07 am, ·············@gmail.com wrote:
> Hi,
>
> I am trying to load nlisp on my clisp+cygwin insallation, and it is
> breaking on the undefined function asdf:system-license.
ANSI Common Lisp doesn't define any such function, and CLISP doesn't
come with ASDF.
So if you are trying to load some ASDF-dependent project, and you
haven't installed ASDF yourself, you're basically at the mercy of the
package maintainers who put your Lisp system together.
The version of ASDF may simply be too old.
> (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.
Did you look at the latest asdf.lisp at http://www.cliki.net/asdf?
The one I'm looking at defines SYSTEM-LICENSE as an accessor of the
SYSTEM class. So there is indeed function called SYSTEM-LICENSE.
Digging through the file's CVS revisions reveals a funny history. The
class accessor was added a long time ago, together with the class. It
goes back as far as revision 1.22 back in 2002. But the accessor was
called licenCe, not licenSe. The symbol was not exported. An export
symbol was later added, in July 2003, revision 1.76. However, the
export symbol was spelled licenSe. And so this created the situation
that asdf:license was exported but not defined anywhere. The problem
was corrected in revision 1.99, which ensured that both spellings are
exported symbols and both are accessors of the same slot in the SYSTEM
class. That was on June 10, 2006.
So you are probably working with an ASDF that is older than June 2006,
but newer than July 2003.
Same with a few
> others, like unix-dso for example.
That observation is true of the latest ASDF also; it exports a symbol
called UNIX-DSO, but doesn't introduce any binding for it anywhere.
This isn't necessarily a problem, but it suggests that there have may
been such as symbol in past revisions of the file which was deleted,
but the occurence in DEFPACKAGE was forgotten.
> I am further puzzled by the hash marks in the package definition:
> (defpackage #:asdf
These are uninterned symbols. In DEFPACKAGE, package names and symbol
names may be denoted by strings or symbols. The symbols are not used
for their symbolic value, but only for their string names. It doesn't
matter whether you write (defpackage #:asdf) or (defpackage :asdf) or
(defpackage "ASDF") or even (defpackage asdf).
When uninterned symbols are used, they become garbage after serving
their purpose, whereas other symbols like keywords remain interned.
Some people worry about the keywords surviving into compiled code,
producing unnecessary interning at load time.
On Mar 14, 4:45 pm, Kaz Kylheku <········@gmail.com> wrote:
> On Mar 14, 2:07 am, ·············@gmail.com wrote:
>
> > Hi,
>
> > I am trying to load nlisp on my clisp+cygwin insallation, and it is
> > breaking on the undefined function asdf:system-license.
>
> ANSI Common Lisp doesn't define any such function, and CLISP doesn't
> come with ASDF.
>
> So if you are trying to load some ASDF-dependent project, and you
> haven't installed ASDF yourself, you're basically at the mercy of the
> package maintainers who put your Lisp system together.
>
> The version of ASDF may simply be too old.
>
> > (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.
>
> Did you look at the latest asdf.lisp athttp://www.cliki.net/asdf?
>
> The one I'm looking at defines SYSTEM-LICENSE as an accessor of the
> SYSTEM class. So there is indeed function called SYSTEM-LICENSE.
>
> Digging through the file's CVS revisions reveals a funny history. The
> class accessor was added a long time ago, together with the class. It
> goes back as far as revision 1.22 back in 2002. But the accessor was
> called licenCe, not licenSe. The symbol was not exported. An export
> symbol was later added, in July 2003, revision 1.76. However, the
> export symbol was spelled licenSe. And so this created the situation
> that asdf:license was exported but not defined anywhere. The problem
> was corrected in revision 1.99, which ensured that both spellings are
> exported symbols and both are accessors of the same slot in the SYSTEM
> class. That was on June 10, 2006.
>
> So you are probably working with an ASDF that is older than June 2006,
> but newer than July 2003.
>
> Same with a few
>
> > others, like unix-dso for example.
>
> That observation is true of the latest ASDF also; it exports a symbol
> called UNIX-DSO, but doesn't introduce any binding for it anywhere.
> This isn't necessarily a problem, but it suggests that there have may
> been such as symbol in past revisions of the file which was deleted,
> but the occurence in DEFPACKAGE was forgotten.
>
> > I am further puzzled by the hash marks in the package definition:
> > (defpackage #:asdf
>
> These are uninterned symbols. In DEFPACKAGE, package names and symbol
> names may be denoted by strings or symbols. The symbols are not used
> for their symbolic value, but only for their string names. It doesn't
> matter whether you write (defpackage #:asdf) or (defpackage :asdf) or
> (defpackage "ASDF") or even (defpackage asdf).
>
> When uninterned symbols are used, they become garbage after serving
> their purpose, whereas other symbols like keywords remain interned.
> Some people worry about the keywords surviving into compiled code,
> producing unnecessary interning at load time.
Thank you.
I thought that I downloaded the latest asdf for my clisp. I will
compare it with the sbcl distribution.
Mirko
On Mar 15, 5:47 pm, ·············@gmail.com wrote:
> On Mar 14, 4:45 pm, Kaz Kylheku <········@gmail.com> wrote:
>
>
>
> > On Mar 14, 2:07 am, ·············@gmail.com wrote:
>
> > > Hi,
>
> > > I am trying to load nlisp on my clisp+cygwin insallation, and it is
> > > breaking on the undefined function asdf:system-license.
>
> > ANSI Common Lisp doesn't define any such function, and CLISP doesn't
> > come with ASDF.
>
> > So if you are trying to load some ASDF-dependent project, and you
> > haven't installed ASDF yourself, you're basically at the mercy of the
> > package maintainers who put your Lisp system together.
>
> > The version of ASDF may simply be too old.
>
> > > (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.
>
> > Did you look at the latest asdf.lisp athttp://www.cliki.net/asdf?
>
> > The one I'm looking at defines SYSTEM-LICENSE as an accessor of the
> > SYSTEM class. So there is indeed function called SYSTEM-LICENSE.
>
> > Digging through the file's CVS revisions reveals a funny history. The
> > class accessor was added a long time ago, together with the class. It
> > goes back as far as revision 1.22 back in 2002. But the accessor was
> > called licenCe, not licenSe. The symbol was not exported. An export
> > symbol was later added, in July 2003, revision 1.76. However, the
> > export symbol was spelled licenSe. And so this created the situation
> > that asdf:license was exported but not defined anywhere. The problem
> > was corrected in revision 1.99, which ensured that both spellings are
> > exported symbols and both are accessors of the same slot in the SYSTEM
> > class. That was on June 10, 2006.
>
> > So you are probably working with an ASDF that is older than June 2006,
> > but newer than July 2003.
>
> > Same with a few
>
> > > others, like unix-dso for example.
>
> > That observation is true of the latest ASDF also; it exports a symbol
> > called UNIX-DSO, but doesn't introduce any binding for it anywhere.
> > This isn't necessarily a problem, but it suggests that there have may
> > been such as symbol in past revisions of the file which was deleted,
> > but the occurence in DEFPACKAGE was forgotten.
>
> > > I am further puzzled by the hash marks in the package definition:
> > > (defpackage #:asdf
>
> > These are uninterned symbols. In DEFPACKAGE, package names and symbol
> > names may be denoted by strings or symbols. The symbols are not used
> > for their symbolic value, but only for their string names. It doesn't
> > matter whether you write (defpackage #:asdf) or (defpackage :asdf) or
> > (defpackage "ASDF") or even (defpackage asdf).
>
> > When uninterned symbols are used, they become garbage after serving
> > their purpose, whereas other symbols like keywords remain interned.
> > Some people worry about the keywords surviving into compiled code,
> > producing unnecessary interning at load time.
>
> Thank you.
>
> I thought that I downloaded the latest asdf for my clisp. I will
> compare it with the sbcl distribution.
>
> Mirko
You were right. I was using an outdated asdf. Not sure where it came
from.
Thanks,
Mirko