Andreas Davour wrote:
> I usually type (DEFPACKAGE "MY-PACKAGE" ...) but I have often seen
> another style, like this (DEFPACKAGE #:MY-PACKAGE ...)
> I don't know why one should be better than the other one.
You don't have to capitalize symbols:
(defpackage #:my-package ...)
but you do have to capitalize the string:
(defpackage "MY-PACKAGE" ...)
unless you want to keep using the string or escape the package's
name every time you use it, to prevent it from being upcased:
(defpackage "my-package" ...)
...
(in-package "my-package")
or
(in-package :|my-package|)
but not
(in-package :my-package)
=> The name "MY-PACKAGE" does not designate any package.
> BTW, I've often wondered why the last sentence has been a rallying cry
> just for perl when it so clearly applies to Lisp as well. I think it's
> a strength.
It's nice, but Lisp has more important features. I don't think
bragging about TMTOWTDI is helpful. c.f. the TOOWTDI reaction
in Python.
--
Dan
www.prairienet.org/~dsb/
Dan Bensen wrote:
> Andreas Davour wrote:
>> I usually type (DEFPACKAGE "MY-PACKAGE" ...) but I have often seen
>> another style, like this (DEFPACKAGE #:MY-PACKAGE ...)
>> I don't know why one should be better than the other one.
>
> You don't have to capitalize symbols:
> (defpackage #:my-package ...)
>
> but you do have to capitalize the string:
> (defpackage "MY-PACKAGE" ...)
>
> unless you want to keep using the string or escape the package's
> name every time you use it, to prevent it from being upcased:
>
> (defpackage "my-package" ...)
> ...
> (in-package "my-package")
> or
> (in-package :|my-package|)
> but not
> (in-package :my-package)
> => The name "MY-PACKAGE" does not designate any package.
Some background information is important: By default, Common Lisp turns
package names and symbol names into upper case while reading, so for
example, foo:bar becames FOO:BAR internally.
However, it's possible to change that behavior in the readtable (a set
of parameters that configures the reader/parser). (defpackage
"MY-PACKAGE" ...) assumes the default behavior of Common Lisp, but may
break when the readtable settings are changed. (defpackage :my-package
...) is more robust in that regard, because the readtable settings are
used in the latter version as well to determine the package name.
#:my-package is just nitpicking. :my-package gives you a symbol in the
keyword package, but #:my-package indicates that you are actually not
really interested in the symbol itself, but only in the string that it
designates. #:my-package generates an uninterned symbol, that will,
among other things, typically be garbage collected. For interned
symbols, there is no guarantee that they are garbage collected (although
that's possible as well).
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Dan Bensen wrote:
> > Andreas Davour wrote:
> >> I usually type (DEFPACKAGE "MY-PACKAGE" ...) but I have often seen
> >> another style, like this (DEFPACKAGE #:MY-PACKAGE ...)
> >> I don't know why one should be better than the other one.
> >
> > You don't have to capitalize symbols:
> > (defpackage #:my-package ...)
> >
> > but you do have to capitalize the string:
> > (defpackage "MY-PACKAGE" ...)
> >
> > unless you want to keep using the string or escape the package's
> > name every time you use it, to prevent it from being upcased:
> >
> > (defpackage "my-package" ...)
> > ...
> > (in-package "my-package")
> > or
> > (in-package :|my-package|)
> > but not
> > (in-package :my-package)
> > => The name "MY-PACKAGE" does not designate any package.
>
> Some background information is important: By default, Common Lisp turns
> package names and symbol names into upper case while reading, so for
> example, foo:bar becames FOO:BAR internally.
With one exception: Those almost-Common-Lisps that
have all symbols in lower case and have a case sensitive
and case preserving reader. This is non-standard and I would
not use it. Several people advocate the use of #:my-package
and #:my-symbol because it is then possible to
use one DEFPACKAGE declaration source code for Common Lisp
and for not-really-Common-Lisp (aka 'Modern Mode', ...).
IMHO this is |wrong| and should be |AVOIDED|.
>
> However, it's possible to change that behavior in the readtable (a set
> of parameters that configures the reader/parser). (defpackage
> "MY-PACKAGE" ...) assumes the default behavior of Common Lisp, but may
> break when the readtable settings are changed. (defpackage :my-package
> ...) is more robust in that regard, because the readtable settings are
> used in the latter version as well to determine the package name.
>
> #:my-package is just nitpicking. :my-package gives you a symbol in the
> keyword package, but #:my-package indicates that you are actually not
> really interested in the symbol itself, but only in the string that it
> designates. #:my-package generates an uninterned symbol, that will,
> among other things, typically be garbage collected. For interned
> symbols, there is no guarantee that they are garbage collected (although
> that's possible as well).
>
> Pascal
--
http://lispm.dyndns.org/
Rainer Joswig <······@lisp.de> writes:
>> Some background information is important: By default, Common Lisp turns
>> package names and symbol names into upper case while reading, so for
>> example, foo:bar becames FOO:BAR internally.
>
> With one exception: Those almost-Common-Lisps that
> have all symbols in lower case and have a case sensitive
> and case preserving reader. This is non-standard and I would
> not use it. Several people advocate the use of #:my-package
> and #:my-symbol because it is then possible to
> use one DEFPACKAGE declaration source code for Common Lisp
> and for not-really-Common-Lisp (aka 'Modern Mode', ...).
> IMHO this is |wrong| and should be |AVOIDED|.
Wait a minute! What did you say those people advocated? The use of more
than one kind of DEFPACKAGE depending on the version of CL?
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
In article <···············@Psilocybe.Update.UU.SE>,
Andreas Davour <·······@updateLIKE.uu.HELLse> wrote:
> Rainer Joswig <······@lisp.de> writes:
>
> >> Some background information is important: By default, Common Lisp turns
> >> package names and symbol names into upper case while reading, so for
> >> example, foo:bar becames FOO:BAR internally.
> >
> > With one exception: Those almost-Common-Lisps that
> > have all symbols in lower case and have a case sensitive
> > and case preserving reader. This is non-standard and I would
> > not use it. Several people advocate the use of #:my-package
> > and #:my-symbol because it is then possible to
> > use one DEFPACKAGE declaration source code for Common Lisp
> > and for not-really-Common-Lisp (aka 'Modern Mode', ...).
> > IMHO this is |wrong| and should be |AVOIDED|.
>
> Wait a minute! What did you say those people advocated? The use of more
> than one kind of DEFPACKAGE depending on the version of CL?
>
> /andreas
No no.
See for a recent example here:
http://metabang.com/unclogit/?p=222
Gary wants to use mOdErN mOdE 'Common Lisp', but also
normal ANSI Common Lisp mode.
I think both (mOdErN mOdE 'Common Lisp' and the wish
to use it ;-) ) is wrong. (Asbestos is on...)
If Google is your friend, the you may be able to find some loooooong
Usenet posts of Erik Naggum explaining it. ;-)
--
http://lispm.dyndns.org/
Rainer Joswig <······@lisp.de> writes:
> In article <···············@Psilocybe.Update.UU.SE>,
> Andreas Davour <·······@updateLIKE.uu.HELLse> wrote:
>
>> Rainer Joswig <······@lisp.de> writes:
>>
>> >> Some background information is important: By default, Common Lisp turns
>> >> package names and symbol names into upper case while reading, so for
>> >> example, foo:bar becames FOO:BAR internally.
>> >
>> > With one exception: Those almost-Common-Lisps that
>> > have all symbols in lower case and have a case sensitive
>> > and case preserving reader. This is non-standard and I would
>> > not use it. Several people advocate the use of #:my-package
>> > and #:my-symbol because it is then possible to
>> > use one DEFPACKAGE declaration source code for Common Lisp
>> > and for not-really-Common-Lisp (aka 'Modern Mode', ...).
>> > IMHO this is |wrong| and should be |AVOIDED|.
>>
>> Wait a minute! What did you say those people advocated? The use of more
>> than one kind of DEFPACKAGE depending on the version of CL?
>>
>
> No no.
>
> See for a recent example here:
> http://metabang.com/unclogit/?p=222
>
> Gary wants to use mOdErN mOdE 'Common Lisp', but also
> normal ANSI Common Lisp mode.
>
> I think both (mOdErN mOdE 'Common Lisp' and the wish
> to use it ;-) ) is wrong. (Asbestos is on...)
>
> If Google is your friend, the you may be able to find some loooooong
> Usenet posts of Erik Naggum explaining it. ;-)
When Erik got his steam up he could be fairly longwinded yes. :-)
Ok, now I see what you mean. I think the robustness of #: compared to
all upper case sounds good, but I see no point in being "modern" just
for the sake of it.
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
From: Edi Weitz
Subject: Re: A Question about DEFPACKAGE syntax
Date:
Message-ID: <uabnun9dh.fsf@agharta.de>
On Fri, 28 Dec 2007 11:21:58 +0100, Rainer Joswig <······@lisp.de> wrote:
> With one exception: Those almost-Common-Lisps that have all symbols
> in lower case and have a case sensitive and case preserving
> reader. This is non-standard and I would not use it. Several people
> advocate the use of #:my-package and #:my-symbol because it is then
> possible to use one DEFPACKAGE declaration source code for Common
> Lisp and for not-really-Common-Lisp (aka 'Modern Mode', ...). IMHO
> this is |wrong| and should be |AVOIDED|.
As this started with a "newbie" question, I'd like to add my two
cents. (Disclaimer: I've never used a "modern mode" Lisp and I have
to intention to use one.)
Firstly, the two variants
(defpackage "FOO"
(:export "QUUX"))
and
(defpackage :foo
(:export :quux))
are both legal ANSI Common Lisp and every CL implementation should
understand them. However, the first version is harder to type and
looks clumsy and old-fashioned. Granted, the second reason is
subjective and maybe that's just my bad taste, but you can't argue
that it's easier to type :foo than to type "FOO".
So, if I read someone's Lisp code and I see something like
(defpackage "FOO"
(:export "QUUX"))
then I usually think that the author doesn't know about the :foo
variant, or that for some strange reason he LIKES UPPERCASE LETTERS,
/or/ that he has a political agenda and explicitely wants to exclude
users of "modern mode" from his code. Whatever the reason is, I don't
see why this should be recommended to newcomers.
As for using #:foo instead of :foo to avoid cluttering up the keyword
package, I used to care but don't do that anymore. Nowadays, I mostly
use :foo simply because it is one character less to type and because
it looks better IMHO.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
wrote:
> On Fri, 28 Dec 2007 11:21:58 +0100, Rainer Joswig <······@lisp.de> wrote:
>
> > With one exception: Those almost-Common-Lisps that have all symbols
> > in lower case and have a case sensitive and case preserving
> > reader. This is non-standard and I would not use it. Several people
> > advocate the use of #:my-package and #:my-symbol because it is then
> > possible to use one DEFPACKAGE declaration source code for Common
> > Lisp and for not-really-Common-Lisp (aka 'Modern Mode', ...). IMHO
> > this is |wrong| and should be |AVOIDED|.
>
> As this started with a "newbie" question, I'd like to add my two
> cents.
This is how it is always. Somebody asks a simple question and
then this is the start of a long thread... ;-)
> (Disclaimer: I've never used a "modern mode" Lisp and I have
> to intention to use one.)
>
> Firstly, the two variants
>
> (defpackage "FOO"
> (:export "QUUX"))
>
> and
>
> (defpackage :foo
> (:export :quux))
>
> are both legal ANSI Common Lisp and every CL implementation should
> understand them. However, the first version is harder to type and
> looks clumsy and old-fashioned. Granted, the second reason is
> subjective and maybe that's just my bad taste, but you can't argue
> that it's easier to type :foo than to type "FOO".
>
> So, if I read someone's Lisp code and I see something like
>
> (defpackage "FOO"
> (:export "QUUX"))
>
> then I usually think that the author doesn't know about the :foo
> variant, or that for some strange reason he LIKES UPPERCASE LETTERS,
> /or/ that he has a political agenda and explicitely wants to exclude
> users of "modern mode" from his code. Whatever the reason is, I don't
> see why this should be recommended to newcomers.
My 'technical' reasons:
* "FOO" does not create superficial symbols in the keyword package
* "FOO" stands out in text. It is easy to spot.
* "FOO" is robust against read-table changes. "FOO" stays uppercase.
:foo might be interned as lowercase.
I like to be more precise than with :foo .
Sometimes I mean lower or mixed case.
Then I also write "Foo" or "foo".
* Since some of the DEFPACKAGE forms get created and processed
by other (editor) tools, the tools generate/use the precise case
by writing/reading the symbol and package names as strings.
For example there are editor commands that down- or upcase
Lisp code (not just text, but takes care of strings, symbols,
comments, etc. ). I use stuff like that and want certain things
not to be downcased or upcased.
* Most Lisp functions print package and symbol names in uppercase.
Should I downcase and 'keywordify' them if I generate code?
In Lisp code is often not written but generated. I try to
be a bit in line with what the machinery uses and creates.
Hey, I could be using a lowercase, case-significant Algol
syntax, But I'm not. Not because Lisp is easier to type.
But because Lisp is easier to process.
More cultural:
* many tools (inspector, debugger, pretty printer, grinder, ...)
will show uppercase symbols and uppercase symbol names.
So my textual representation does not look different.
:foo is just an illusion. Once the form is read it is no longer
there. The symbol / package name is looking differently
internally when inspected.
* Angst: PACKAGE stuff is a horror. Many who have tried to
use or maintain complex package hierarchies should
have had problems with name clashes, weird import errors,
locked packages, etc. - thus I try to code as defensively
as possible when it comes to packages.
>
> As for using #:foo instead of :foo to avoid cluttering up the keyword
> package, I used to care but don't do that anymore. Nowadays, I mostly
> use :foo simply because it is one character less to type and because
> it looks better IMHO.
That's a matter of taste. For :keywords are something special.
They are unique identifiers, possibly associated with a value.
If I see them 'misused' for other purposes - for example
to denote package names and symbol names - it hurts my eyes.
>
> Edi.
--
http://lispm.dyndns.org/
Rainer Joswig <······@lisp.de> writes:
>
> * "FOO" does not create superficial symbols in the keyword package
Neither does #:foo, no?
> * "FOO" stands out in text. It is easy to spot.
M-. foo works better for finding foo anyway...
> * "FOO" is robust against read-table changes. "FOO" stays uppercase.
> :foo might be interned as lowercase.
That's an interesting definition of 'robust,' since presumably if one
_does_ fiddle with the readtable then one _wants_ read-in code to Do the
Right Thing.
> * Most Lisp functions print package and symbol names in uppercase.
> Should I downcase and 'keywordify' them if I generate code?
(setf *print-case* :downcase)
This is the most absolutely wonderful thing in the world, making Lisp
look sane and intelligent (as opposed to all-caps, which is a work of
the devil) IMHO.
> * many tools (inspector, debugger, pretty printer, grinder, ...)
> will show uppercase symbols and uppercase symbol names.
See above. The only place I see ugly, perverse capital letters is in
SBCL error messages, which impolitely ignore *print-case*.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Does anyone think the feddle gummint could tie a knot in a piece of string in
less than five years, for less than a billion dollars? --John Derbyshire
[I was going to stay out of this, but since no-one has mentioned it yet...]
Robert Uhl <·········@NOSPAMgmail.com> wrote:
+---------------
| Rainer Joswig <······@lisp.de> writes:
| > * "FOO" is robust against read-table changes. "FOO" stays uppercase.
| > :foo might be interned as lowercase.
|
| That's an interesting definition of 'robust,' since presumably if one
| _does_ fiddle with the readtable then one _wants_ read-in code to Do the
| Right Thing.
+---------------
To me, other than the default :UPCASE the only variant of READTABLE-CASE
that "Does The Right Thing" [for some definition of "Right"] is
:INVERT, which takes stuff the way we normally code it in Lisp and
uppercases it so that <<car>> is still (find-symbol "CAR") so the
code doesn't break... but *also* preserves the case of CamelCase
symbols, which can be very useful when reading a bunch of externally-
generated files. My favorite example is EDIF [".edif" or ".EDN"]
electronics design file format, which is basically just one huge
S-expr [often megabytes!] with case-sensitive symbols.
+---------------
| > * Most Lisp functions print package and symbol names in uppercase.
| > Should I downcase and 'keywordify' them if I generate code?
|
| (setf *print-case* :downcase)
|
| This is the most absolutely wonderful thing in the world, making Lisp
| look sane and intelligent (as opposed to all-caps, which is a work of
| the devil) IMHO.
+---------------
No, no, no! (setf (readtable-case *readtable*) :invert) is better! ;-}
The printer looks at *both* READTABLE-CASE and *PRINT-CASE* and
"Does The Right Thing" when the former is :INVERT and the latter
is :UPCASE, namely, re-inverts on printing. So your Lisp still
looks "sane and intelligent" but doesn't lose any information
due to case-folding:
> (setf (readtable-case *readtable*) :invert)
:invert
> (list 'foo 'BAR 'Baz 'CamelCase)
(foo BAR Baz CamelCase)
> (mapcar #'symbol-name *)
("FOO" "bar" "Baz" "CamelCase")
>
+---------------
| > * many tools (inspector, debugger, pretty printer, grinder, ...)
| > will show uppercase symbols and uppercase symbol names.
|
| See above. The only place I see ugly, perverse capital letters is in
| SBCL error messages, which impolitely ignore *print-case*.
+---------------
CMUCL, at least, "Does The Right Thing" [by your definition]
when READTABLE-CASE is :INVERT and *PRINT-CASE* is :UPCASE,
namely, still re-inverts the case during error messages.
So try leaving *PRINT-CASE* alone [that is, in the default :UPCASE],
and see how READTABLE-CASE :INVERT works for you...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> To me, other than the default :UPCASE the only variant of READTABLE-CASE
> that "Does The Right Thing" [for some definition of "Right"] is
> :INVERT, which takes stuff the way we normally code it in Lisp and
> uppercases it so that <<car>> is still (find-symbol "CAR") so the
> code doesn't break... but *also* preserves the case of CamelCase
> symbols, which can be very useful when reading a bunch of externally-
> generated files. My favorite example is EDIF [".edif" or ".EDN"]
> electronics design file format, which is basically just one huge
> S-expr [often megabytes!] with case-sensitive symbols.
Oooh, so that's what it does. I was wondering what on Earth made the
CL designers include such an oddball case mode. Now it finally makes
sense.
Cheers,
Maciej
From: Richard M Kreuter
Subject: Re: A Question about DEFPACKAGE syntax
Date:
Message-ID: <87ir2h461q.fsf@progn.net>
····@rpw3.org (Rob Warnock) writes:
> Robert Uhl <·········@NOSPAMgmail.com> wrote:
> +---------------
> | > * Most Lisp functions print package and symbol names in uppercase.
> | > Should I downcase and 'keywordify' them if I generate code?
> |
> | (setf *print-case* :downcase)
> |
> | This is the most absolutely wonderful thing in the world, making Lisp
> | look sane and intelligent (as opposed to all-caps, which is a work of
> | the devil) IMHO.
> +---------------
>
> No, no, no! (setf (readtable-case *readtable*) :invert) is better! ;-}
> The printer looks at *both* READTABLE-CASE and *PRINT-CASE* and
> "Does The Right Thing" when the former is :INVERT and the latter
> is :UPCASE, namely, re-inverts on printing. So your Lisp still
> looks "sane and intelligent" but doesn't lose any information
> due to case-folding:
>
> > (setf (readtable-case *readtable*) :invert)
>
> :invert
> > (list 'foo 'BAR 'Baz 'CamelCase)
>
> (foo BAR Baz CamelCase)
> > (mapcar #'symbol-name *)
>
> ("FOO" "bar" "Baz" "CamelCase")
It's also worth spelling out that because the :INVERT readtable-case
is information-preserving, :INVERT plus the concept of "customary
case" for an external system is sufficient for interaction with all
systems outside Lisp, using the same rules as for common case in
pathname components: when translating tokens for an external system,
an all-uppercase symbol denotes a token in customary case, an
all-lowercase symbol denotes a token in anticustomary case, and a
mixed-case symbol denotes its symbol-name. Given these rules, you can
embed anything in CL source text and reliably externalize it into
strings with the appropriate case for any external system. For
example,
(setf (readtable-case *readtable*) :invert)
(defun externalize (string-designator customary-case)
(setf string-designator (string string-designator))
(let ((customary-case-transform (ecase customary-case
(:lower #'string-downcase)
(:upper #'string-upcase)))
(anticustomary-case-transform (ecase customary-case
(:lower #'string-upcase)
(:upper #'string-downcase))))
(cond ((every (lambda (char)
(if (alpha-char-p char) (upper-case-p char) t))
string-designator)
(funcall customary-case-transform string-designator))
((every (lambda (char)
(if (alpha-char-p char) (lower-case-p char) t))
string-designator)
(funcall anticustomary-case-transform string-designator))
(t string-designator))))
(defun java-out (expression &optional (stream *standard-output*))
(format stream "~{~A.~A(·@{~A~^, ~})~}"
(mapcar #'(lambda (thing)
(etypecase thing
(symbol (externalize thing :lower))
(list (with-output-to-string (o)
(java-out thing o)))
(string (format nil "~S" thing))
#| Other types can be printed for Java here. |#))
expression)))
(java-out '(object method))
-| object.method()
(java-out '(object someMethod))
-| object.someMethod()
(java-out '(object someMethod anotherObject SOME_CONSTANT))
-| object.someMethod(anotherObject, SOME_CONSTANT)
Not only does this let you write an external system's tokens WYSIWYG,
it also lets you use lower-case source code to denote upper-case
tokens in an external system. For example, suppose you need to
generate SGML with all-uppercase generic identifiers and attribute
identifiers:
(defun pprint-sgml (stream expression &optional colon atsign)
(declare (ignore colon atsign))
(etypecase expression
(string (write-string expression stream))
(null ())
((cons string)
(write-string (car expression) stream)
(pprint-sgml stream (cdr expression)))
((cons symbol)
(destructuring-bind (gi (&rest attribute-values) &rest content)
expression
;; The ~S in the following isn't right, but it's beside the point.
(format stream "<~A~{~^ ~A=~S~}>····················@*</~A>"
(externalize gi :upper)
(loop for (attribute value) on attribute-values by #'cddr
collect (externalize attribute :upper)
collect value)
content)))))
(defun sgml-out (expression &optional (stream *standard-output*))
(pprint-sgml stream expression))
(sgml-out '(p () "foo"))
-| <P>foo</P>
(sgml-out '(body () (para (color "green") "foo")))
-| <BODY><PARA COLOR="green">foo</PARA></BODY>
Since it's necessary to write code to turn S-expressions into an
external system's syntax anyway, it's no significant burden to handle
external systems' tokens' case this way.
--
RmK
Rainer Joswig <······@lisp.de> writes:
> In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
> wrote:
>
>> On Fri, 28 Dec 2007 11:21:58 +0100, Rainer Joswig <······@lisp.de> wrote:
>>
>> > With one exception: Those almost-Common-Lisps that have all symbols
>> > in lower case and have a case sensitive and case preserving
>> > reader. This is non-standard and I would not use it. Several people
>> > advocate the use of #:my-package and #:my-symbol because it is then
>> > possible to use one DEFPACKAGE declaration source code for Common
>> > Lisp and for not-really-Common-Lisp (aka 'Modern Mode', ...). IMHO
>> > this is |wrong| and should be |AVOIDED|.
>>
>> As this started with a "newbie" question, I'd like to add my two
>> cents.
>
> This is how it is always. Somebody asks a simple question and
> then this is the start of a long thread... ;-)
[good stuff snipped]
Thanks for the detailed explanations from you both, Rainer and Edi!
It's always interesting not only to know how the CLHS says, but how
people think and prefer to code. I think I have some ideas to build my
own position on now. I lean towards a Rainer-ian position right now. :-)
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
In article <···············@Psilocybe.Update.UU.SE>,
Andreas Davour <·······@updateLIKE.uu.HELLse> wrote:
> Rainer Joswig <······@lisp.de> writes:
>
> > In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
> > wrote:
> >
> >> On Fri, 28 Dec 2007 11:21:58 +0100, Rainer Joswig <······@lisp.de> wrote:
> >>
> >> > With one exception: Those almost-Common-Lisps that have all symbols
> >> > in lower case and have a case sensitive and case preserving
> >> > reader. This is non-standard and I would not use it. Several people
> >> > advocate the use of #:my-package and #:my-symbol because it is then
> >> > possible to use one DEFPACKAGE declaration source code for Common
> >> > Lisp and for not-really-Common-Lisp (aka 'Modern Mode', ...). IMHO
> >> > this is |wrong| and should be |AVOIDED|.
> >>
> >> As this started with a "newbie" question, I'd like to add my two
> >> cents.
> >
> > This is how it is always. Somebody asks a simple question and
> > then this is the start of a long thread... ;-)
> [good stuff snipped]
>
> Thanks for the detailed explanations from you both, Rainer and Edi!
> It's always interesting not only to know how the CLHS says, but how
> people think and prefer to code. I think I have some ideas to build my
> own position on now. I lean towards a Rainer-ian position right now. :-)
So we have 'two'.
>
> /andreas
--
http://lispm.dyndns.org/
I honestly don't understand what you're trying to say and/or achieve.
I looked at your list of reasons several times, and each and every one
you give is a reason NOT to use strings.
On Dec 28, 5:57 pm, Rainer Joswig <······@lisp.de> wrote:
> > > With one exception: Those almost-Common-Lisps that have all symbols
> > > in lower case and have a case sensitive and case preserving
> > > reader. This is non-standard and I would not use it. Several people
> > > advocate the use of #:my-package and #:my-symbol because it is then
> > > possible to use one DEFPACKAGE declaration source code for Common
> > > Lisp and for not-really-Common-Lisp (aka 'Modern Mode', ...). IMHO
> > > this is |wrong| and should be |AVOIDED|.
You never give reasons for that. Why exactly should it be avoided? Why
is it wrong? Apart from ACL lying about the reader case, which was (I
assume it got fixed since 6.1) obviously very wrong, there's
absolutely nothing wrong on principle with using modern mode. It's not
the default, but is a perfectly reasonable model to follow, one I'd
personally choose were I designing CL from scratch, without the
compatibility needs[1], and I'd like to draw your attention to the
fact that the ANSI standard *explicitly* gives you facilities to
accommodate for that. It seems to me that this is a case of "I think
it's wrong because I don't think it's right" argument.
> > (Disclaimer: I've never used a "modern mode" Lisp and I have
> > to intention to use one.)
>
> > Firstly, the two variants
>
> > (defpackage "FOO"
> > (:export "QUUX"))
>
> > and
>
> > (defpackage :foo
> > (:export :quux))
>
> > are both legal ANSI Common Lisp and every CL implementation should
> > understand them. However, the first version is harder to type and
> > looks clumsy and old-fashioned. Granted, the second reason is
> > subjective and maybe that's just my bad taste, but you can't argue
> > that it's easier to type :foo than to type "FOO".
>
> > So, if I read someone's Lisp code and I see something like
>
> > (defpackage "FOO"
> > (:export "QUUX"))
>
> > then I usually think that the author doesn't know about the :foo
> > variant, or that for some strange reason he LIKES UPPERCASE LETTERS,
> > /or/ that he has a political agenda and explicitely wants to exclude
> > users of "modern mode" from his code. Whatever the reason is, I don't
> > see why this should be recommended to newcomers.
>
> My 'technical' reasons:
>
> * "FOO" does not create superficial symbols in the keyword package
This is probably the most technically valid of all your arguments, but
you can still get that behaviour with #:foo, and it's *still* easier
to type than "FOO", plus it has all the advantages of normal :foo.
Still, not creating those extra few symbols in the KEYWORD package is
just not worth the bother.
> * "FOO" stands out in text. It is easy to spot.
NOT IF THE WHOLE ENVIRONMENT INSISTS ON YELLING AT YOU, THEN IT
DOESN'T STAND OUT SO MUCH ANYMORE. Besides, why do you need them to
stand out? #:foo stands out just as much, and when exactly do you need
your string designators to be specially visible? If it's inside the
DEFPACKAGE form, then you already know what to expect, and "FOO" is
actually harder to read than :foo, since it requires more work to map
mentally to what you use in the code (which is foo, not FOO, unless
you're some crazy '80s leftover :).
> * "FOO" is robust against read-table changes. "FOO" stays uppercase.
> :foo might be interned as lowercase.
Excuse me, WHAT? It's absolutely non-robust. You ensure that the code
will break for everyone who has different read-table settings than
you. Calling it "robust" is a bad joke. And anyway, why on Earth do
you care how your symbols are interned?
> I like to be more precise than with :foo .
:|foo| if you really need it, but you don't unless you're doing
something odd, like, say, mapping XML tags (which are defined to be
case-sensitive) to symbols. That kind of care for "precision" strikes
me as something only micro-optimisation obsessed Real Programmers do,
that ends up screwing up everyone who isn't using exactly the same
setup as they are, including themselves a few years later. Do you also
rely on register overflow to optimise out loop checks in your code?
> Sometimes I mean lower or mixed case.
> Then I also write "Foo" or "foo".
You mean lowercase why exactly? If you want to have a case-preserving
symbol, you write |foo|. If you want an actual string, then obviously
you use a string, but then the discussion is irrelevant. If you want a
string designator intended to represent a symbol, then either is fine,
but IMHO :|foo| makes it clearer you mean symbols. And as I said, the
times when you really need case-preserving symbols is exceedingly
rare, screwing up everyone just to accommodate for some special case
that almost never happens and can be served just fine using other
means is again something an obsessive old fart would do.
> * Since some of the DEFPACKAGE forms get created and processed
> by other (editor) tools, the tools generate/use the precise case
> by writing/reading the symbol and package names as strings.
>
> For example there are editor commands that down- or upcase
> Lisp code (not just text, but takes care of strings, symbols,
> comments, etc. ). I use stuff like that and want certain things
> not to be downcased or upcased.
And your symbols are to be excluded why exactly? Either you don't use
a case-preserving read-table, in which case you achieved nothing but
inconsistency in the code, or you do, and you just screwed yourself
over. There's just no win scenario.
> * Most Lisp functions print package and symbol names in uppercase.
> Should I downcase and 'keywordify' them if I generate code?
Huh? I don't understand. They print following the read-table, which is
always The Right Thing to do.
> In Lisp code is often not written but generated. I try to
> be a bit in line with what the machinery uses and creates.
> Hey, I could be using a lowercase, case-significant Algol
> syntax, But I'm not. Not because Lisp is easier to type.
>
> But because Lisp is easier to process.
>
> More cultural:
>
> * many tools (inspector, debugger, pretty printer, grinder, ...)
> will show uppercase symbols and uppercase symbol names.
> So my textual representation does not look different.
> :foo is just an illusion. Once the form is read it is no longer
> there. The symbol / package name is looking differently
> internally when inspected.
That is complete bullshit. Your symbols, being, well, symbols, will be
subject to exactly the same rules and will get upcased like everyone
else. And you can tweak *print-case*, too. And do you write (DEFUN MY-
FUNCTION (FOO BAR) ...) too, just because the reader will internally
upcase it?
> * Angst: PACKAGE stuff is a horror. Many who have tried to
> use or maintain complex package hierarchies should
> have had problems with name clashes, weird import errors,
> locked packages, etc. - thus I try to code as defensively
> as possible when it comes to packages.
And your definition of "defensive coding" includes "write things in a
way that breaks on a slightest change to the environment, deliberately
fucking things up for everyone else, even though there exist
mechanisms that will just work in the face of changes"? That's an
interesting definition you have there.
> > As for using #:foo instead of :foo to avoid cluttering up the keyword
> > package, I used to care but don't do that anymore. Nowadays, I mostly
> > use :foo simply because it is one character less to type and because
> > it looks better IMHO.
>
> That's a matter of taste. For :keywords are something special.
> They are unique identifiers, possibly associated with a value.
Excuse me, where can I get some of the stuff you're smoking?
"Interning a symbol in the KEYWORD package has three automatic
effects:
1. It causes the symbol to become bound to itself.
2. It causes the symbol to become an external symbol of the KEYWORD
package.
3. It causes the symbol to become a constant variable."
CLHS 10.2, section "Type KEYWORD", http://www.lisp.org/HyperSpec/Body/typ_keyword.html
Keywords are explicitly designed so that they *can't* have a value
associated (other than themselves). They are designed to stand for
their name and name only. They explicitly have no interesting meaning
on their own, only the name[2] they symbolise carries any
significance.
> If I see them 'misused' for other purposes - for example
> to denote package names and symbol names - it hurts my eyes.
Misused? You mean things that carry no meaning besides their name used
to name things is "misuse"? What special mission from God do they have
then?
Cheers,
Maciej
[1] Though the default upcasing behaviour gives us a nice way to refer
to
language concepts, as opposed to English words, such as LENGTH vs.
length.
[2] Actually, not name, but their identity, which is the whole reason
to have
the :foo shorthand syntax for keyword:foo. But the end effect is
that it
gives you a perfectly unambigous name to refer to.
Pascal Costanza <··@p-cos.net> writes:
> Some background information is important: By default, Common Lisp
> turns package names and symbol names into upper case while reading, so
> for example, foo:bar becames FOO:BAR internally.
>
> However, it's possible to change that behavior in the readtable (a set
> of parameters that configures the reader/parser). (defpackage
> "MY-PACKAGE" ...) assumes the default behavior of Common Lisp, but may
> break when the readtable settings are changed. (defpackage :my-package
> ...) is more robust in that regard, because the readtable settings are
> used in the latter version as well to determine the package name.
Interesting. That's a good reason to use the keyword syntax I
guess. More robust code is a good thing. But, who often is the readtable
changed?
> #:my-package is just nitpicking. :my-package gives you a symbol in the
> keyword package, but #:my-package indicates that you are actually not
> really interested in the symbol itself, but only in the string that it
> designates. #:my-package generates an uninterned symbol, that will,
> among other things, typically be garbage collected. For interned
> symbols, there is no guarantee that they are garbage collected
> (although that's possible as well).
Sounds like the #: and # syntax isn't that different
then. Implementation dependant like so often else, I guess.
Thanks.
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Andreas Davour wrote:
> Sounds like the #: and # syntax isn't that different
> then. Implementation dependant like so often else, I guess.
Where did you see a #foo syntax with no colon? The standard forms
are :foo and #:foo, and AFAIK they're not implementation dependent.
:foo creates an interned symbol in the keyword package, and #:foo
creates an uninterned symbol, i.e. it's not registered in any package,
so I think it gets GC'd as soon as you're done with it.
--
Dan
www.prairienet.org/~dsb/
Dan Bensen <··········@cyberspace.net> writes:
> Andreas Davour wrote:
>> Sounds like the #: and # syntax isn't that different
>> then. Implementation dependant like so often else, I guess.
>
> Where did you see a #foo syntax with no colon? The standard forms
> are :foo and #:foo, and AFAIK they're not implementation dependent.
> :foo creates an interned symbol in the keyword package, and #:foo
> creates an uninterned symbol, i.e. it's not registered in any package,
> so I think it gets GC'd as soon as you're done with it.
You cut out what I was refering to, which makes my paragraph a bit hard
to understand. I was refering to the fact that both *could* cause GC but
only one was garanteed to do it.
The '#foo' syntax with no colon was a writing error on my part, I meant
"the #: and : syntax isn't that different". Sorry for the confusion, but
I'm used to the FOO syntax and thus didn't notice.
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Pascal Costanza wrote:
> #:my-package generates an uninterned symbol, that will,
> among other things, typically be garbage collected. For interned
> symbols, there is no guarantee that they are garbage collected (although
> that's possible as well).
I didn't want to let this go by without a quibble or two. It is
_guaranteed_ that an interned symbol will _not_ be deleted, unless
perhaps if the interning package(s) are themselves deleted. It is
possible to test portably for the presence of a symbol in a package
(e.g. with find-symbol), so an implementation cannot gratuitously
unintern symbols that appear to be otherwise unused.
The space occupied by symbols used to be a great concern back in the
days of MACLISP, when machines were small. Merely mentioning
a keyword symbol causes that symbol to remain in the heap indefinitely.
This used to be even of a consideration in the early days of CL when
machines were measured by a few MB. It's less of an issue today.
On Jan 3, 9:42 pm, "Steven M. Haflich" <····@alum.mit.edu> wrote:
> Pascal Costanza wrote:
> > #:my-package generates an uninterned symbol, that will,
> > among other things, typically be garbage collected. For interned
> > symbols, there is no guarantee that they are garbage collected (although
> > that's possible as well).
>
> I didn't want to let this go by without a quibble or two. It is
> _guaranteed_ that an interned symbol will _not_ be deleted, unless
> perhaps if the interning package(s) are themselves deleted. It is
> possible to test portably for the presence of a symbol in a package
> (e.g. with find-symbol), so an implementation cannot gratuitously
> unintern symbols that appear to be otherwise unused.
Given the context of this discussion, I think it's worth mentioning
that DEFPACKAGE is not required to leave your string designators
untouched in its expansion; in SBCL and CMUCL for example, if the
following form is put into a file, compiled, and the fasl loaded into
a fresh image, it does not cause the creation of :foo or :bar
(defpackage :foo (:use :cl) (:export :bar))
"Thomas F. Burdick" <········@gmail.com> writes:
> Given the context of this discussion, I think it's worth mentioning
> that DEFPACKAGE is not required to leave your string designators
> untouched in its expansion; in SBCL and CMUCL for example, if the
> following form is put into a file, compiled, and the fasl loaded into
> a fresh image, it does not cause the creation of :foo or :bar
>
> (defpackage :foo (:use :cl) (:export :bar))
Until recently[1] in SBCL, an (in-package :foo) *would* create
:foo. Even worse, (in-package foo) would create FOO in whatever
package was current when starting to load the file. This essentially
created an obscure dependency on whatever random package was hanging
around at the time. Fortunately it doesn't do that any more.
Zach
[1] http://article.gmane.org/gmane.lisp.steel-bank.devel/6978 ... wow,
has it really been 18 months since then?
Steven M. Haflich wrote:
> Pascal Costanza wrote:
>
>> #:my-package generates an uninterned symbol, that will, among other
>> things, typically be garbage collected. For interned symbols, there is
>> no guarantee that they are garbage collected (although that's possible
>> as well).
>
> I didn't want to let this go by without a quibble or two. It is
> _guaranteed_ that an interned symbol will _not_ be deleted, unless
> perhaps if the interning package(s) are themselves deleted. It is
> possible to test portably for the presence of a symbol in a package
> (e.g. with find-symbol), so an implementation cannot gratuitously
> unintern symbols that appear to be otherwise unused.
Oh, ok. Is that even true for keyword symbols?
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Jan 4, 12:15 am, Pascal Costanza <····@p-cos.net> wrote:
> > I didn't want to let this go by without a quibble or two. It is
> > _guaranteed_ that an interned symbol will _not_ be deleted, unless
> > perhaps if the interning package(s) are themselves deleted. It is
> > possible to test portably for the presence of a symbol in a package
> > (e.g. with find-symbol), so an implementation cannot gratuitously
> > unintern symbols that appear to be otherwise unused.
>
> Oh, ok. Is that even true for keyword symbols?
cl-user> (defun foo (&key some-keyword) some-keyword)
foo
cl-user> (unintern :some-keyword :keyword)
t
cl-user> (foo :some-keyword 10)
===========================================================
unknown &KEY argument: :some-keyword
[Condition of type sb-int:simple-program-error]
Restarts:
0: [abort] Return to SLIME's top level.
1: [terminate-thread] Terminate this thread (#<thread "repl-
thread" {AFDA9A1}>)
Backtrace:
0: (foo :some-keyword 10)
===========================================================
cl-user> (defun foo (&key some-keyword) some-keyword)
;; style-warning: redefining foo in DEFUN
foo
cl-user> (foo :some-keyword 10)
10
You have to remember that keyword arguments are judged for their
identity, even if superficially they appear to be about names only.
Cheers,
Maciej
Pascal Costanza wrote:
>> I didn't want to let this go by without a quibble or two. It is
>> _guaranteed_ that an interned symbol will _not_ be deleted, unless
>> perhaps if the interning package(s) are themselves deleted. It is
>> possible to test portably for the presence of a symbol in a package
>> (e.g. with find-symbol), so an implementation cannot gratuitously
>> unintern symbols that appear to be otherwise unused.
>
> Oh, ok. Is that even true for keyword symbols?
I don't know of anything that makes the keyword package different in
this regard from any other package. The keyword package is special
(in the sense of "special" meaning "irregular") because interning any
new string in the keyword package unconditionally declaims the new
symbol to be a constant, and sets the value of that constant to be
the symbol itself. But otherwise, I see no justification that an
implementation could spontaneously unintern symbols from the keyword
package because they are otherwise unreferenced.
This raises an interesting trivia question about Common Lisp:
Suppose I start my favorite implementation and immediately execute
this form
(defpackage :foo (:use :common-lisp :keyword))
what is the result? I suspect it will signal continuable error in
any conforming implementation, but it points out that exact content
of the keyword package is not specified. The undocumented
conclusion is that it was not intended for any packjage to use the
keyword package.
"Steven M. Haflich" <···@alum.mit.edu> writes:
> ...
> Suppose I start my favorite implementation and immediately execute
> this form
>
> (defpackage :foo (:use :common-lisp :keyword))
>
> what is the result? I suspect it will signal continuable error in
> any conforming implementation, but it points out that exact content
> of the keyword package is not specified. The undocumented
> conclusion is that it was not intended for any packjage to use the
> keyword package.
The KEYWORD package is documented to be "out of bounds" for
USE-PACKAGE.
<http://www.lisp.org/HyperSpec/Body/fun_use-package.html>
On the other hand, both CLisp and SBCL "only" complain about name
conflicts (indeed with continuable errors), which seems not to be
the best thing to do (but is a minor issue, of course).
---Vassil.
--
Bound variables, free programmers.
Vassil Nikolov wrote:
> The KEYWORD package is documented to be "out of bounds" for
> USE-PACKAGE.
> <http://www.lisp.org/HyperSpec/Body/fun_use-package.html>
Indeed, you are correct. I forgot about that. But this is a minor
quibble, since the question could be rephrased (recoded?) in any
number of other ways. For example, after starting a fresh Lisp
execution what does this return:
(find-symbol "TEST" :keyword)
Now, the keyword symbol :TEST is a keyword argument to any number of
functions defined in the common-lisp package, so one would expect it
to exist. But on the other hand, one could conceive (however unlikely)
that an implementation could have another way of associating keyword
argument indicators against the expected keywords that didn't depend
upon the actual symbol. So I conclude that the result of the above
form is unspecified (i.e. "harmless").
The original point, which was much more important, was that after
a symbol has been interned in _any_ package, it may not be uninterned
capriciously by the implementation, even if it is otherwise garbage.
"Steven M. Haflich" <···@alum.mit.edu> writes:
> ...
> (find-symbol "TEST" :keyword)
> ...
> The original point, which was much more important, was that after
> a symbol has been interned in _any_ package, it may not be uninterned
> capriciously by the implementation, even if it is otherwise garbage.
And just to add something which might shed a bit of useful light.
It occurs to me that the keyword package appears deceptively
different possibly because of the following---consider this
hypothetical scenario:
1. It is established that there exist no references to a keyword K
outside of the keyword package (perhaps because all referrers have
been garbage-collected).
2. K is discarded (uninterned and thus garbage-collected).
3. K is recreated on demand (interned) when the very next referrer
appears.
It might seem that (a) the absence of K between 2. and 3. would be
unobservable (no references), and then (b) the recreation at 3. is
an equivalent restoration of the status quo ante 2. I think it is
because of (b) that we might be tempted to think that discarding K
is permissible.
Except that (a) is false, as the value of
(find-symbol K :keyword)
would observably change at 2.
---Vassil.
--
Bound variables, free programmers.
Vassil Nikolov <···············@pobox.com> writes:
> "Steven M. Haflich" <···@alum.mit.edu> writes:
>
>> ...
>> (find-symbol "TEST" :keyword)
>> ...
>> The original point, which was much more important, was that after
>> a symbol has been interned in _any_ package, it may not be uninterned
>> capriciously by the implementation, even if it is otherwise garbage.
>
> And just to add something which might shed a bit of useful light.
> It occurs to me that the keyword package appears deceptively
> different possibly because of the following---consider this
> hypothetical scenario:
>
> 1. It is established that there exist no references to a keyword K
> outside of the keyword package (perhaps because all referrers have
> been garbage-collected).
>
> 2. K is discarded (uninterned and thus garbage-collected).
>
> 3. K is recreated on demand (interned) when the very next referrer
> appears.
>
> It might seem that (a) the absence of K between 2. and 3. would be
> unobservable (no references), and then (b) the recreation at 3. is
> an equivalent restoration of the status quo ante 2. I think it is
> because of (b) that we might be tempted to think that discarding K
> is permissible.
>
> Except that (a) is false, as the value of
>
> (find-symbol K :keyword)
>
> would observably change at 2.
(b) is false too:
(setf (get :ha :key) 'value)
(ext:gc) ; if it would remove unreferenced keywords
(get :ha :key) --> VALUE ; we'd still expect this result.
Also, AFAIK, nothing prevents to fbind a keyword.
(defun :ha () 'ah!)
(:ha)
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
Dan Bensen <··········@cyberspace.net> writes:
>> BTW, I've often wondered why the last sentence has been a rallying cry
>> just for perl when it so clearly applies to Lisp as well. I think it's
>> a strength.
>
> It's nice, but Lisp has more important features. I don't think
> bragging about TMTOWTDI is helpful. c.f. the TOOWTDI reaction
> in Python.
Well, bragging in itself might not be all that interesting, but it sure
have gotten perl a lot of attention and I do think tha fact that Lisp
helps you program in the way you want is a great strength. Maybe you are
right about the TOOWTDI reaction. Noo need to push that far.
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?