I have a question about something I saw in uffi's ASD file. It starts
out with these forms:
(defpackage #:uffi-system (:use #:asdf #:cl))
(in-package #:uffi-system)
Why is "#:" being used here? It took me a while to figure out that
this works, even though for instance the two occurences of
"#:uffi-system" are distinct symbols. It's because defpackage and
in-package are only interested in the symbol's name, right? But why
not just use keyword symbols?
Thanks in advance for enlightenment.
Dan Muller wrote:
>
> I have a question about something I saw in uffi's ASD file. It starts
> out with these forms:
>
> (defpackage #:uffi-system (:use #:asdf #:cl))
> (in-package #:uffi-system)
>
> Why is "#:" being used here? It took me a while to figure out that
> this works, even though for instance the two occurences of
> "#:uffi-system" are distinct symbols. It's because defpackage and
> in-package are only interested in the symbol's name, right? But why
> not just use keyword symbols?
>
> Thanks in advance for enlightenment.
The #: reader macro causes the reader not to intern the symbol. The ":"
reader macro is an alias for "keyword:". When the function in question only
uses the name of the symbol, there's no significant different between the
two methods that I know of.
I seem to remember something about Cormon Common Lisp not being standard in
some way that that can be worked around using the #: syntax instead of the
keyword syntax.
Chris Capel
Dan Muller <·········@sneakemail.com> wrote in message news:<····················@newssvr31.news.prodigy.com>...
> I have a question about something I saw in uffi's ASD file. It starts
> out with these forms:
>
> (defpackage #:uffi-system (:use #:asdf #:cl))
> (in-package #:uffi-system)
>
> Why is "#:" being used here? It took me a while to figure out that
> this works, even though for instance the two occurences of
> "#:uffi-system" are distinct symbols. It's because defpackage and
> in-package are only interested in the symbol's name, right? But why
> not just use keyword symbols?
>
> Thanks in advance for enlightenment.
Why not just use strings?
(defpackage "UFFI-SYSTEM" (:use "ASDF" "CL"))
This has been the preferred way to write package declarations
for a long time. It also makes clear, that the symbol names are
upper case internally (and don't depend on what kind of reader mode
you are using to process the declaration)!
Why not keyword symbols? Then you would pollute the keyword package
with arbitrary symbols.
Why are some people using #:foo ?
- no package gets 'polluted' (filled with symbols that aren't needed
in that package)?
- the reader can read these symbols with either uppercase (the
default) and/or lowercase preferred. Franz has some mode where all
symbols are lowercase by default. According to ANSI CL, all symbols
have UPPERCASE names by default. So by writing #:foo, you can read the
package definition in Franz' special lowercase mode too (something,
which I think is bad anyway).
I think #:foo is BAD style. It still generates intermediate unused
symbols (though not interned in a package). I also don't want to
support the Franz lowercase mode and suffer by seeing this ugly
notation, even though I never need it anywhere.
······@corporate-world.lisp.de (Rainer Joswig) writes:
> Dan Muller <·········@sneakemail.com> wrote in message news:<····················@newssvr31.news.prodigy.com>...
> > I have a question about something I saw in uffi's ASD file. It starts
> > out with these forms:
> >
> > (defpackage #:uffi-system (:use #:asdf #:cl))
> > (in-package #:uffi-system)
> >
> > Why is "#:" being used here? It took me a while to figure out that
> > this works, even though for instance the two occurences of
> > "#:uffi-system" are distinct symbols. It's because defpackage and
> > in-package are only interested in the symbol's name, right? But why
> > not just use keyword symbols?
> >
> > Thanks in advance for enlightenment.
>
> Why not just use strings?
>
> (defpackage "UFFI-SYSTEM" (:use "ASDF" "CL"))
>
> This has been the preferred way to write package declarations
> for a long time.
This is a subjective argument. The Ansi Spec gives two examples in
the defpackage description, one with strings and one with various
symbols, so using strings is clearly not the preferred way by the
spec. Another similar subjective argument is whether to write code
as
(defun foo ...
or as
(DEFUN foo ...
or as
(defun FOO ...
All are allowed and portable in Ansi Common Lisp, but if you were to
make a statement that one style is preferred over the others, you
would draw arguments (likely from people who prefer the other styles).
> It also makes clear, that the symbol names are
> upper case internally
But symbol names aren't uppercase internally. They are whatever case
they were interned as. As Kent Pitman always argues, Common Lisp is
a case sensitive language; it is only the reader, in its default
readtable-case of :upcase, which folds what it reads into uppercase
symbols, and _only_ if the symbol names aren't escaped.
> (and don't depend on what kind of reader mode
> you are using to process the declaration)!
Yes, this is absolutely true.
> Why not keyword symbols? Then you would pollute the keyword package
> with arbitrary symbols.
This is true, but only half so; I demonstrated elsewhere in this
thread that it only need be the compiling environment's namespace
which gets polluted, not the lisp which loads pre-compiled forms.
> Why are some people using #:foo ?
> - no package gets 'polluted' (filled with symbols that aren't needed
> in that package)?
True.
> - the reader can read these symbols with either uppercase (the
> default) and/or lowercase preferred.
True, but only under default readtable-case. Since the standard
CL symbols are in fact uppercase, it would not work to do something
such as (:import #:car #:cdr) when readtable-case is :downcase.
(Or, at least, it wouldn't do what might be obviously intended).
> Franz has some mode where all
> symbols are lowercase by default. According to ANSI CL, all symbols
> have UPPERCASE names by default. So by writing #:foo, you can read the
> package definition in Franz' special lowercase mode too (something,
> which I think is bad anyway).
Franz's case sensitive mode is not Ansi, but has little to do with
the argument anyway. It is true that this mode benefits from the
normative usage of #: or : style, but so in fact do both :upcase and
:downcase readtable-cases in Ansi lisps.
> I think #:foo is BAD style.
I can't personally make a judgement call on what style I think is bad.
Of the three styles, however, :foo, #:foo, and "FOO", I personally
prefer them in that order; :foo is easiest to type, and "FOO" is at
least as hard to type as #:foo. But if in fact you want to match the
internal case of the symbol, why not type (:export FOO) instead of
(:export "FOO")? The former is _much_ easier to type than the latter.
[This is, of course, a specious argument, since that style only has
no negatives when used in :export clauses, or in other clauses where
the symbol is expected to exist already or in the future]
> It still generates intermediate unused
> symbols (though not interned in a package). I also don't want to
> support the Franz lowercase mode and suffer by seeing this ugly
> notation, even though I never need it anywhere.
Fortunately, Franz doesn't have the responsibility of dictating to
you what style you use. You're free to use whatever style you want
to use that is allowed by the spec, and your code should be portable
to any Ansi-conforming Common Lisp.
--
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
Why ANSI is not defined with default reader to :preserve and all cl symbols
defined in downcase ?
You will still write your programs the same way except for ones dealing with
case-sensitive extensions like C or Java interfaces.
Perhaps there's an easy way to do that ? an option somewhere to change to
:preserve before loading cl files ?
Christophe Turle.
"Christophe Turle" <······@nospam.com> writes:
> Why ANSI is not defined with default reader to :preserve and all cl symbols
> defined in downcase ?
>
> You will still write your programs the same way except for ones dealing with
> case-sensitive extensions like C or Java interfaces.
>
> Perhaps there's an easy way to do that ? an option somewhere to change to
> :preserve before loading cl files ?
You can use :PRESERVE before loading only YOUR Common-Lisp files!
It's defined as it is because "old" code is UPPER CASE, or RaNdOm cAsE.
Try to load any program from cmu-ai-rep for example.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
"Pascal Bourguignon" <····@mouse-potato.com> a �crit dans le message de
···················@thalassa.informatimago.com...
> "Christophe Turle" <······@nospam.com> writes:
>
> > Why ANSI is not defined with default reader to :preserve and all cl
symbols
> > defined in downcase ?
> >
> > You will still write your programs the same way except for ones dealing
with
> > case-sensitive extensions like C or Java interfaces.
> >
> > Perhaps there's an easy way to do that ? an option somewhere to change
to
> > :preserve before loading cl files ?
>
> You can use :PRESERVE before loading only YOUR Common-Lisp files!
>
> It's defined as it is because "old" code is UPPER CASE, or RaNdOm cAsE.
> Try to load any program from cmu-ai-rep for example.
And why not an option for the command :
cmucl -preserve ...
clisp -preserve ...
Just in case you don't want to use "old" code.
Or we can translate the old code : upper to lower doesn't seem to be an over
difficult task ?
Christophe Turle.
"Christophe Turle" <······@nospam.com> writes:
> Or we can translate the old code : upper to lower doesn't seem to be an over
> difficult task ?
(with-open-file (original "original-file" :direction :input)
(with-open-file (translated "translated-file" :direction :output)
(loop for form = (read original nil original)
until (eq form original)
do (pprint form translated))))
:)
Okay, it doesn't preserve comments or spacing, so you'd really want to
do something more clever in a real situation.
Actually, what's really needed is a form like IN-PACKAGE that allows the
specification of the READTABLE-CASE used for a given file. That would
be the simplest addition to the standard that would help in dealing with
various readtable cases in source code.
--
Thomas A. Russ, USC/Information Sciences Institute
> (with-open-file (original "original-file" :direction :input)
> (with-open-file (translated "translated-file" :direction :output)
> (loop for form = (read original nil original)
> until (eq form original)
> do (pprint form translated))))
>
> :)
Like almost any automated solution, this fails to handle stuff like:
(intern (format nil "G~S" n) pkg)
I suspect that a purely mechanical translation provably could never
handle all these cases, but that's just a suspicion.
joelh
--
Joel Ray Holveck - ·····@piquan.org
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
Joel Ray Holveck <·····@piquan.org> writes:
> Like almost any automated solution, this fails to handle stuff like:
> (intern (format nil "G~S" n) pkg)
>
> I suspect that a purely mechanical translation provably could never
> handle all these cases, but that's just a suspicion.
I would support this conjecture.
--
Thomas A. Russ, USC/Information Sciences Institute
······@corporate-world.lisp.de (Rainer Joswig) writes:
>
> Why not just use strings?
>
> (defpackage "UFFI-SYSTEM" (:use "ASDF" "CL"))
> I think #:foo is BAD style. It still generates intermediate unused
> symbols (though not interned in a package). I also don't want to
> support the Franz lowercase mode and suffer by seeing this ugly
> notation, even though I never need it anywhere.
Well, I've never used Franz's lisp but I write those definitions as
(defpackage :uffi-system
(:use :asdf :common-lisp)
(:export #:symbol-1 #:symbol-2 ....))
not for any portability reason, but just because the lower
caseness of it strikes me as less ugly then the upper case,
and the extra #: seems no worse than those ugly "DOUBLE QUOTES".
Also, not the inconsistency in being willing to intern as keywords
the names of the packages, but not the names of the exported
symbols (in the wrong package). Does that make me schizophrenic? :-)
Must be a matter of what you get used to...
Dan Muller <·········@sneakemail.com> writes:
> I have a question about something I saw in uffi's ASD file. It starts
> out with these forms:
>
> (defpackage #:uffi-system (:use #:asdf #:cl))
> (in-package #:uffi-system)
>
> Why is "#:" being used here? It took me a while to figure out that
> this works, even though for instance the two occurences of
> "#:uffi-system" are distinct symbols. It's because defpackage and
> in-package are only interested in the symbol's name, right?
Yes.
> But why not just use keyword symbols?
Because some folks are paranoid about wasting memory by interning
needless symbols in the keyword package (but don't want to use strings
because of the case issue when running in Allegro's "modern mode"
Lisp.) Which may or may not be a good reason. But that's the reason.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Hi Peter Seibel,
>> But why not just use keyword symbols?
>
> Because some folks are paranoid about wasting memory by interning
> needless symbols in the keyword package (but don't want to use strings
> because of the case issue when running in Allegro's "modern mode" Lisp.)
> Which may or may not be a good reason. But that's the reason.
I think it's more likely that the desire to avoid interning the keyword
arises from the propensity of Common Lisp programmers to want to do the
right thing rather than submit to a worse is better world. I believe few
care about the bytes allocated to interning a symbol (thats a practical
matter and the community has practically no aversion to multi-megabyte
virtual machines).
Interning a keyword for use as a string designator is a hack. Using an
uninterned symbol has a better conceptual foundation. Use of the #: reader
macro instead of a keyword may not even be rational (and I say this as
someone who uses the #: notation).
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> Interning a keyword for use as a string designator is a hack.
Not really. The CLHS makes no distinction between interned and
uninterned symbols, or if interned, what their package names are,
in its definition of the term "string designator". A character can
even be used as a string designator!
> Using an uninterned symbol has a better conceptual foundation.
Perhaps so, but because the spec allows it, it becomes a matter
of personal style only.
> Use of the #: reader macro instead of a keyword may not even be
> rational (and I say this as someone who uses the #: notation).
So we come full circle...
--
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
Hi Duane Rettig,
>> Interning a keyword for use as a string designator is a hack.
>
> Not really. The CLHS makes no distinction between interned and
> uninterned symbols, or if interned, what their package names are, in its
> definition of the term "string designator". A character can even be
> used as a string designator!
It's an unclean workaround not because it's a perfectly legitimate string
designator but because it generates unwanted state. A character can be
garbage collected after it has fulfilled its role as a string designator.
A keyword can't.
>> Using an uninterned symbol has a better conceptual foundation.
>
> Perhaps so, but because the spec allows it, it becomes a matter of
> personal style only.
The keyword generates irrelevant but detectable state long after it has
fulfilled its purpose. Because there are no practical consequences for
choosing to use a keyword or an uninterned symbol I agree it is a matter
of personal style only.
>> Use of the #: reader macro instead of a keyword may not even be
>> rational (and I say this as someone who uses the #: notation).
>
> So we come full circle...
Indeed!
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> Hi Duane Rettig,
>
> >> Interning a keyword for use as a string designator is a hack.
> >
> > Not really. The CLHS makes no distinction between interned and
> > uninterned symbols, or if interned, what their package names are, in its
> > definition of the term "string designator". A character can even be
> > used as a string designator!
>
> It's an unclean workaround not because it's a perfectly legitimate string
> designator but because it generates unwanted state. A character can be
> garbage collected after it has fulfilled its role as a string designator.
> A keyword can't.
Correct, to an extent, but see my answer to Vassil elsewhere in this
thread about how this can be mitigated.
> >> Using an uninterned symbol has a better conceptual foundation.
> >
> > Perhaps so, but because the spec allows it, it becomes a matter of
> > personal style only.
>
> The keyword generates irrelevant but detectable state long after it has
> fulfilled its purpose. Because there are no practical consequences for
> choosing to use a keyword or an uninterned symbol I agree it is a matter
> of personal style only.
And there are some who prefer the keyword style over #: style, because
it is "less ugly" (i.e. it has less syntax). I personally prefer
the keyword style purely because it is less typing. But as an
implementor, I of course support both styles.
> >> Use of the #: reader macro instead of a keyword may not even be
> >> rational (and I say this as someone who uses the #: notation).
> >
> > So we come full circle...
>
> Indeed!
>
> Regards,
> Adam
--
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
In article <······························@consulting.net.nz>,
Adam Warner <······@consulting.net.nz> wrote:
> Hi Duane Rettig,
>
> >> Interning a keyword for use as a string designator is a hack.
> >
> > Not really. The CLHS makes no distinction between interned and
> > uninterned symbols, or if interned, what their package names are, in its
> > definition of the term "string designator". A character can even be
> > used as a string designator!
>
> It's an unclean workaround not because it's a perfectly legitimate string
> designator but because it generates unwanted state. A character can be
> garbage collected after it has fulfilled its role as a string designator.
> A keyword can't.
The state is only generated at compile time. The macro should extra the
symbol name at expansion time, so there shouldn't be anything left over
when the file is loaded.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Hello,
Adam Warner <······@consulting.net.nz> writes:
> The keyword generates irrelevant but detectable state long after it has
> fulfilled its purpose. Because there are no practical consequences for
> choosing to use a keyword or an uninterned symbol
Using keywords for package names allows easy completion in IN-PACKAGE.
--
Regards,
Alexey Dejneka
"Alas, the spheres of truth are less transparent than those of
illusion." -- L.E.J. Brouwer
Thanks to everyone for the replies, much appreciated. I especially
found the explanation of how the lifetimes of the keywords, when
passed by these macros, interact with compile-time and run-time to be
surprising (but comprehensible) and interesting.
There's certainly a lot of room for "style" in Lisp. :) I think I'll
stick with interned keywords for my own stuff. If CormanLisp really
has a problem with this, well, I hope the problem gets fixed some day
soon along with a few other deficiencies which keep me from using
it. (Which is a pity, because it's otherwise a good match for some of
my objectives.)
Adam Warner <······@consulting.net.nz> writes:
> [...]
> I think it's more likely that the desire to avoid interning the keyword
> arises from the propensity of Common Lisp programmers to want to do the
> right thing rather than submit to a worse is better world. I believe few
> care about the bytes allocated to interning a symbol (thats a practical
> matter and the community has practically no aversion to multi-megabyte
> virtual machines).
While I agree that saving memory rarely (if ever) plays a role here,
I think that it is not just the abstract desire to do the right
thing, but also the rather practical avoidance of polluting a
namespace. I should think it is not uncommon for people to look at a
list of symbols (such as produced by APROPOS) and wonder where the
heck a symbol came from and should they be concerned about it...
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Vassil Nikolov <········@poboxes.com> writes:
> Adam Warner <······@consulting.net.nz> writes:
>
> > [...]
> > I think it's more likely that the desire to avoid interning the keyword
> > arises from the propensity of Common Lisp programmers to want to do the
> > right thing rather than submit to a worse is better world. I believe few
> > care about the bytes allocated to interning a symbol (thats a practical
> > matter and the community has practically no aversion to multi-megabyte
> > virtual machines).
>
>
> While I agree that saving memory rarely (if ever) plays a role here,
> I think that it is not just the abstract desire to do the right
> thing, but also the rather practical avoidance of polluting a
> namespace. I should think it is not uncommon for people to look at a
> list of symbols (such as produced by APROPOS) and wonder where the
> heck a symbol came from and should they be concerned about it...
I think that's true, and Allegro CL has for quite a while supported the
use of keywords in defpackage forms without polluting the runtime namespace
(though the compiler's namespace is polluted, which makes it moot if
the compiling lisp happens to be the runtime lisp).
Here is an example of two different lisps, where the namespace of
the second is not polluted by compilation of keywords in the defpackage
form in the first. I've used version 7.0 beta here, because it is
a little more friendly in its treatment of apropos and lack of in-package
forms in files:
First lisp:
CL-USER(1): (shell "cat foo.cl")
(defpackage :foo
(:export :bar :bas :bam))
0
CL-USER(2): (compile-file "foo.cl")
;;; Compiling file foo.cl
;;; Writing fasl file foo.fasl
;;; Fasl write complete
#p"foo.fasl"
NIL
NIL
CL-USER(3):
Second lisp:
CL-USER(1): (load "foo.fasl")
; Fast loading /tmp_mnt/net/gemini/home/duane/foo.fasl
T
CL-USER(2): (do-external-symbols (s :foo) (print s))
FOO:BAR
FOO:BAM
NIL
CL-USER(3): (apropos "bar")
EXCL::SHARP-VERTICAL-BAR [function] (STREAM CHR ARG)
FOO:BAR
CL-USER(4): (apropos "bam")
FOO:BAM
CL-USER(5):
Note that no keywords were sacrificed to perform this experiment.
--
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
"Steven E. Harris" <···@panix.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > (defpackage :foo
> > (:export :bar :bas :bam))
>
> ^^^^
> [...]
>
> > CL-USER(2): (do-external-symbols (s :foo) (print s))
> >
> > FOO:BAR
> > FOO:BAM
> > NIL
>
> What happened to poor FOO:BAS?
Oops. Good catch.
Here's what happened: I had originally created the defpackage
form with the :bas in it, but when I went to do an apropos on
"bas", it showed me a couple of hundred symbols with "BAS" in it,
including words that had "BASE" or "BASIC", etc. So I editited
out the :bas from the source file, but forgot to save the source
before performing the run. But when I discovered this, I mis-edited
the result I was working up, only replacing the
second-lisp-invocation's run and forgetting that the first's was
also different. Sorry about that.
--
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 2004-09-30 12:51, in article ·············@franz.com, "Duane Rettig"
<·····@franz.com> wrote:
> "Steven E. Harris" <···@panix.com> writes:
>
>> Duane Rettig <·····@franz.com> writes:
>>
>>> (defpackage :foo
>>> (:export :bar :bas :bam))
>>
>> ^^^^
>> [...]
>>
>>> CL-USER(2): (do-external-symbols (s :foo) (print s))
>>>
>>> FOO:BAR
>>> FOO:BAM
>>> NIL
>>
>> What happened to poor FOO:BAS?
>
> Oops. Good catch.
>
> Here's what happened: I had originally created the defpackage
> form with the :bas in it, but when I went to do an apropos on
> "bas", it showed me a couple of hundred symbols with "BAS" in it,
> including words that had "BASE" or "BASIC", etc. So I editited
> out the :bas from the source file, but forgot to save the source
> before performing the run. But when I discovered this, I mis-edited
> the result I was working up, only replacing the
> second-lisp-invocation's run and forgetting that the first's was
> also different. Sorry about that.
In other words, you :exported :bas before you didn't :export :bas.
And, in attempting to clarify the situation, you neglected to completely
clarify the situation because it was late at night (aka 13:00 PST) and you
were tired.
Or something like that.
:-)
--jon
Jon Boone <········@comcast.net> writes:
> On 2004-09-30 12:51, in article ·············@franz.com, "Duane Rettig"
> <·····@franz.com> wrote:
>
> > "Steven E. Harris" <···@panix.com> writes:
> >
> >> Duane Rettig <·····@franz.com> writes:
> >>
> >>> (defpackage :foo
> >>> (:export :bar :bas :bam))
> >>
> >> ^^^^
> >> [...]
> >>
> >>> CL-USER(2): (do-external-symbols (s :foo) (print s))
> >>>
> >>> FOO:BAR
> >>> FOO:BAM
> >>> NIL
> >>
> >> What happened to poor FOO:BAS?
> >
> > Oops. Good catch.
> >
> > Here's what happened: I had originally created the defpackage
> > form with the :bas in it, but when I went to do an apropos on
> > "bas", it showed me a couple of hundred symbols with "BAS" in it,
> > including words that had "BASE" or "BASIC", etc. So I editited
> > out the :bas from the source file, but forgot to save the source
> > before performing the run. But when I discovered this, I mis-edited
> > the result I was working up, only replacing the
> > second-lisp-invocation's run and forgetting that the first's was
> > also different. Sorry about that.
>
> In other words, you :exported :bas before you didn't :export :bas.
>
> And, in attempting to clarify the situation, you neglected to completely
> clarify the situation because it was late at night (aka 13:00 PST) and you
> were tired.
>
> Or something like that.
>
> :-)
Yep
:-(
--
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
Jon Boone <········@comcast.net> writes:
> [...]
> late at night (aka 13:00 PST)
Wouldn't that hour rather be the time of the siesta?
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
On 2004-10-01 01:12, in article ··············@janus.vassil.nikolov.names,
"Vassil Nikolov" <········@poboxes.com> wrote:
> Jon Boone <········@comcast.net> writes:
>
>> [...]
>> late at night (aka 13:00 PST)
>
> Wouldn't that hour rather be the time of the siesta?
>
> ---Vassil.
Sorry for the incomplete cultural reference.
It's a political joke relevant to the US elections.
--jon
Duane Rettig <·····@franz.com> writes:
> [...]
> if the compiling lisp happens to be the runtime lisp
On a tangent (off an interesting example), an association I made was
with IBM's VM operating system: I imagined several Lisp VMs running
side by side and communicating with each other (well, perhaps not
with virtual punches or readers...), some of them doing compilations
and some of them being "runtime VMs". Now, if you asked me how that
was different from running several Lisp processes in, say, Unix, and
having them communicate via shared memory or sockets or whatever, I
wouldn't be able to say, but it feels different (well, it might just
be the time of the morning, or just the fact that VM feels so
different from Unix...).
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
Hi Dan Muller,
> I have a question about something I saw in uffi's ASD file. It starts
> out with these forms:
>
> (defpackage #:uffi-system (:use #:asdf #:cl))
> (in-package #:uffi-system)
>
> Why is "#:" being used here? It took me a while to figure out that
> this works, even though for instance the two occurences of
> "#:uffi-system" are distinct symbols. It's because defpackage and
> in-package are only interested in the symbol's name, right? But why
> not just use keyword symbols?
>
> Thanks in advance for enlightenment.
The root of the issue is the reader interning symbols in uppercase by
default (in order to potentially match the uppercase symbols interned in
the COMMON-LISP package). Its legacy is a tension between interoperability
with the ANSI default and those who want to use a case preserving Lisp
where symbols in a |common-lisp| package are all interned in lowercase.
In order to improve interoperability (and reduce the costs of migration)
many people avoid defining packages using a string. (defpackage
"UFFI-SYSTEM" ...) would only effectively work on ANSI systems and
(defpackage "uffi-system" ...) would only effectively work with a
case-preserving reader. If a keyword is used as a package designator then
a default ANSI reader will intern the symbol name in uppercase while a
case preserving reader will intern the symbol in the provided case
(lowercase).
This has one blight: You've "cluttered" the keyword package with an extra
symbol. This can be avoided if the symbol is not actually interned (it is
only being used as a string designator). Hence the yucky looking #:
notation.
Regards,
Adam