Another style/usage/good practice question: how often do you use
non-global special variables. I.e. variables that are "declared"
special but not "proclaimed" or "declaimed" special (whether
explicitly or implicitly by DEFVAR)?
Also, when you do, do you still name them with *'s around the name or
are the *'s reserved for globally special variables?
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
In article <··············@javamonkey.com>,
Peter Seibel <·····@javamonkey.com> wrote:
> Another style/usage/good practice question: how often do you use
> non-global special variables. I.e. variables that are "declared"
> special but not "proclaimed" or "declaimed" special (whether
> explicitly or implicitly by DEFVAR)?
See http://www.tfeb.org/lisp/hax.html#DYNAMIC-STATE for an example of local special variables.
> Also, when you do, do you still name them with *'s around the name or
> are the *'s reserved for globally special variables?
I don't think this makes sense - if you declare a local variable
special, only other code that knows about it can use it by declaring it
special again. So I guess there is actually no use for a naming
convention. That is, apart from improving readability.
However, one should perhaps make sure that the name used is unique to
the extent that accidental name clashes with other special variables
(global or local) cannot happen. So for example it should be a symbol
interned in a dedicated package, or should be generated by gensym.
Pascal
I like the idea of your project to track down the origins of names and
idioms in Common Lisp. What I would be interested in is the origin of
declaim/proclaim/declare...
From: Tim Bradshaw
Subject: Re: Non-global special variables?
Date:
Message-ID: <ey37k96xwwt.fsf@cley.com>
* Pascal Costanza wrote:
> I don't think this makes sense - if you declare a local variable
> special, only other code that knows about it can use it by declaring
> it special again. So I guess there is actually no use for a naming
> convention. That is, apart from improving readability.
I use %...% for local specials, /.../ for global lexicals (now...),
and ..... (hmm, I mean .xyz.) for things macros introduce which are
not gensymmed but I want to be clear are private (so for WITH-x macros
that expand to CALL-WITH-x, I do:
(let ((.fn. #'(lambda (...) ...)))
...
(call-with-x .fn. ...))
--tim
Tim Bradshaw wrote:
> I use %...% for local specials, /.../ for global lexicals (now...),
> and ..... (hmm, I mean .xyz.) for things macros introduce which are
> not gensymmed but I want to be clear are private
Other than those, and the usual *...* for global special variables,
+...+ for constants, and - inside symbols to delimit words, are there
any other naming conventions people use?
For example, an initial % sometimes seems to indicate a low-level
function, and I've seen / used inside symbols sometimes. What's that
about?
From: Joe Marshall
Subject: Re: Naming conventions (was: Non-global special variables?)
Date:
Message-ID: <7k8kgxha.fsf@ccs.neu.edu>
Lars Brinkhoff <·········@nocrew.org> writes:
> For example, an initial % sometimes seems to indicate a low-level
> function,
I use that convention. I picked it up from LispM hacking.
> and I've seen / used inside symbols sometimes. What's that
> about?
I've been using that as well. I picked it up from Chris Hanson.
Generally, I use it as (type/operation ....), so if I have a FOO
object, I might write:
(defun find-foo (search-key initial-foo)
(and initial-foo
(or (eq search-key (foo/key initial-foo))
(find-foo search-key (foo/next initial-foo)))))
"Lars Brinkhoff" <·········@nocrew.org> wrote in message
······················@junk.nocrew.org...
> Tim Bradshaw wrote:
> > I use %...% for local specials, /.../ for global lexicals (now...),
> > and ..... (hmm, I mean .xyz.) for things macros introduce which are
> > not gensymmed but I want to be clear are private
>
> Other than those, and the usual *...* for global special variables,
> +...+ for constants, and - inside symbols to delimit words, are there
> any other naming conventions people use?
>
> For example, an initial % sometimes seems to indicate a low-level
> function, and I've seen / used inside symbols sometimes. What's that
> about?
In the Lisp Machine a % before a function warned the user
that the function was a low-level function that could trash
the machine if it was used wrong. It is ment for systems programming, and
should be avoided if it could be. (Pointer manipliation, etc.)
The $ before a function means that the function was visible from
Macsyma--this way the Macsyma user could extend Macsyma by writing Lisp
code. (I don't know if the $ convention carried over to other scripting in
Lisp.)
Puting n before a function usually signifies that it is a destructive
operator, can modify a variable (pass by reference) not dangrous
to the machine like the % functions
i.e. (just examples not real functions)
%set-pointer! [function] set's a pointer to a new value
%program-counter [var] the pointer to the current frame
(%set-pointer! %program-counter (+ 1 %program-counter))
& real functions
(reverse list) ;; list does not change. (call by value)
vs
(nreverse list) ;; list could change. (call by reference)
From: Matthew Danish
Subject: Re: Naming conventions (was: Non-global special variables?)
Date:
Message-ID: <20030521122340.H11522@mapcar.org>
On Wed, May 21, 2003 at 02:19:03PM +0000, Franz Kafka wrote:
> (nreverse list) ;; list could change. (call by reference)
No. NREVERSE is a normal function following normal Lisp semantics
(call-by-value). The structure of the list could change, but you are still
required to use the return value of NREVERSE:
(setf list (nreverse list))
Usage of NREVERSE is for efficiency reasons, not for laziness.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> On Wed, May 21, 2003 at 02:19:03PM +0000, Franz Kafka wrote:
> > (nreverse list) ;; list could change. (call by reference)
>
> No. NREVERSE is a normal function following normal Lisp semantics
> (call-by-value). The structure of the list could change, but you are still
> required to use the return value of NREVERSE:
>
> (setf list (nreverse list))
>
> Usage of NREVERSE is for efficiency reasons, not for laziness.
Indeed, a common (but NOT a required) implementation-dependent behavior
leaves you with effects like this, which are conforming:
(let ((temp (list 'a 'b 'c 'd)))
(values temp
(last temp)
(nreverse temp)))
=> (A), (D C B A), (D C B A)
I checked that this is what LispWorks does, for example.
I don't have my LispM handy, but I'm pretty sure it will do the following
which is conforming and also makes complete sense if you look at the internals
of cdr-coding, but which might surprise newbies:
(let ((temp (list* 'a 'b 'c (list* 'd 'e 'f (list* 'g 'h 'i nil)))))
(values temp
(last temp)
(nreverse temp)))
=> (C B A), (G F E D C B A), (I H G F E D C B A)
The moral? Always rely on the return value, not on the side-effect behavior.
From: Thomas A. Russ
Subject: Re: Naming conventions (was: Non-global special variables?)
Date:
Message-ID: <ymismr7nbfk.fsf@sevak.isi.edu>
Not to mention that the following is also conforming:
(let ((temp (list 'a 'b 'c 'd)))
(values temp
(last temp)
(nreverse temp)))
(A B C D)
(D)
(D C B A)
Although destructive operation is ALLOWED by the standard, it is not
REQUIRED. A conforming implementation could define
(defun nreverse (list) (reverse list))
and have nreverse not be destructive at all. (Although almost all
implementations don't do this.
> (Kent Pitman)
> The moral? Always rely on the return value, not on the side-effect behavior.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
From: Kalle Olavi Niemitalo
Subject: required destructive operations (was: Naming conventions)
Date:
Message-ID: <8765o02znx.fsf_-_@Astalo.kon.iki.fi>
···@sevak.isi.edu (Thomas A. Russ) writes:
> Although destructive operation is ALLOWED by the standard, it is not
> REQUIRED.
That seems to vary. For NCONC, it is definitely required.
I then looked in the descriptions of the other N... functions and
found this in NBUTLAST:
| nbutlast is like butlast, but nbutlast may modify list. It
| changes the cdr of the cons n+1 from the end of the list to
| nil.
First this says that NBUTLAST "may modify", but then "it
changes". Does this mean that NBUTLAST is not required to change
the list, but if it does, then only the change specified in the
second sentence is permitted?
There is a similar rule for NSUBSTITUTE.
From: Paul F. Dietz
Subject: Re: required destructive operations (was: Naming conventions)
Date:
Message-ID: <d7ydnZxbh9pIDFKjXTWcqg@dls.net>
Kalle Olavi Niemitalo wrote:
> First this says that NBUTLAST "may modify", but then "it
> changes". Does this mean that NBUTLAST is not required to change
> the list, but if it does, then only the change specified in the
> second sentence is permitted?
It means there are situations where NBUTLAST doesn't need
to change the list, and should not. For example: if the list
is a proper list and n is 0, or if n is >= the length of the list.
The previous paragraph on the NBUTLAST page has "If there are fewer
than n conses in list, nil is returned and, in the case of nbutlast,
list is not modified."
Paul
From: Nils Goesche
Subject: Re: Naming conventions (was: Non-global special variables?)
Date:
Message-ID: <lyr86sb26i.fsf@cartan.de>
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> (reverse list) ;; list does not change. (call by value)
>
> vs
>
> (nreverse list) ;; list could change. (call by reference)
There is no such thing as ``call by reference�� in Common Lisp.
Function calls /always/ have call-by-value semantics. This has been
discussed here a thousand times before. Check Google. Do not start a
long thread about this. If you think Lisp has call-by-reference
``sometimes�� or something, you are simply wrong. Again: Google.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
From: Tim Bradshaw
Subject: Re: Naming conventions (was: Non-global special variables?)
Date:
Message-ID: <ey33cj8wdx3.fsf@cley.com>
* Lars Brinkhoff wrote:
> For example, an initial % sometimes seems to indicate a low-level
> function, and I've seen / used inside symbols sometimes. What's that
> about?
I use / to mean `with' quite often:
(defmacro with-foo (&body code)
`(let ((.fn. #'(lambda () ,code)))
(declare (dynamic-extent .fn.))
(call/foo .fn.)))
(defun call/foo (fn)
;; implement WITH-FOO
... (funcall fn) ...)
I also just use it as a convenient division in a name:
(defun do-x (...)
...
(if simple (do-x/simple ...) (do-x/general ...)))
(defun do-x/simple (...)
;; do the simple, fast, case
...)
Lars Brinkhoff <·········@nocrew.org> writes:
> Tim Bradshaw wrote:
> > I use %...% for local specials, /.../ for global lexicals (now...),
> > and ..... (hmm, I mean .xyz.) for things macros introduce which are
> > not gensymmed but I want to be clear are private
>
> Other than those, and the usual *...* for global special variables,
> +...+ for constants, and - inside symbols to delimit words, are there
> any other naming conventions people use?
>
> For example, an initial % sometimes seems to indicate a low-level
> function, and I've seen / used inside symbols sometimes. What's that
> about?
For accessor functions that have type names attached, I use type.slot
(I use this in condition readers, for example). I'm pretty sure I got
this from SBCL.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
So in summary, the standard non-alphanumeric characters can be
classified something like this, right?
Reserved by CL: "'(),:;\`|
Reserved for user: !?[]{}
Macro char at start of symbol: #
Has CL convention: &
Have (some) user conventions: %*+-./
Have mathematical meaning: <=>
Remaining: ·@^_~
Lars Brinkhoff <·········@nocrew.org> writes:
> So in summary, the standard non-alphanumeric characters can be
> classified something like this, right?
>
> Reserved by CL: "'(),:;\`|
> Reserved for user: !?[]{}
> Macro char at start of symbol: #
> Has CL convention: &
> Have (some) user conventions: %*+-./
> Have mathematical meaning: <=>
> Remaining: ·@^_~
Well, without looking back at the standard in detail, what you say looks
vaguely right but also looks to be presented in overly dramatic form. After
all, we're only talking the 'initial' readtable.
For example, I commonly code using some of those characters that seem
reserved. If I were to encounter an implementation that disagreed, I
would just create my own readtable for that application, since the
appliation obviously runs without whatever feature they've got it
assigned to. There is no internal restriction on what characters can
be in a symbol.
I heartily recommend that people not restrict themselves particularly
on the issue of characters like '?' and '!' as suffixes, and that people
who write readmacros on these characters make them be non-breaking so
that they can compatibly co-exist with users who do that.
I also don't see a problem with using '&' infix.
I don't see that mathematical meaning keeps you from using symbols like
--> or ==> or <foo>.
But arguing over it doesn't do much good since readtables can partition
things nicely.
For the record, there's one more common convention that haven't been
brought to light yet in this thread: adding * to the end of an
operator to mark it as a variation of another operator, e.g. do*,
prog*, let*, list*.
In article <·················@junk.nocrew.org>,
Lars Brinkhoff <·········@nocrew.org> wrote:
>So in summary, the standard non-alphanumeric characters can be
>classified something like this, right?
>
>Reserved by CL: "'(),:;\`|
>Reserved for user: !?[]{}
>Macro char at start of symbol: #
>Has CL convention: &
>Have (some) user conventions: %*+-./
>Have mathematical meaning: <=>
>Remaining: ·@^_~
OPS5 and related production system interpreters (i.e.,
expert system shells) bracket variable names with "<"
and ">". For example, <A> and <NOUN-PHRASE> are
variable names in these languages.
This constraint is enforced lexically, by checking that
the SYMBOL-NAME of a variable is delimited by these
characters. A reader macro is *not* defined.
In other rule-based languages, however, you often see
variable names prefixed with "?" (e.g., ?A, ?NOUN-PHRASE)
where a reader macro is defined for #\? (e.g., so that
the example variable names expand to (VARIABLE A) and
(VARIABLE NOUN-PHRASE), respectively).
Lars Brinkhoff <·········@nocrew.org> writes:
> So in summary, the standard non-alphanumeric characters can be
> classified something like this, right?
>
> Reserved by CL: "'(),:;\`|
> Reserved for user: !?[]{}
> Macro char at start of symbol: #
> Has CL convention: &
> Have (some) user conventions: %*+-./
> Have mathematical meaning: <=>
> Remaining: ·@^_~
I am using <...> for most of my classes (this has remained from my Scheme
history using Guile). I am still not sure if this is really good because
it does not fit with the convention for the built-in classes.
Nicolas.
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> I am using <...> for most of my classes (this has remained from my
> Scheme history using Guile). I am still not sure if this is really
> good because it does not fit with the convention for the built-in
> classes.
Presumably you are not overloading the reader syntax for #\< ?
So you should probably switch to using print-unreadable-object, which
will wrap your output in #<...>, and more.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Presumably you are not overloading the reader syntax for #\< ?
> So you should probably switch to using print-unreadable-object, which
> will wrap your output in #<...>, and more.
(No, I don't.) I guess I don't understand the problem - could you
elaborate? I'm using something like:
* (defclass <test> ()
())
#<STANDARD-CLASS <TEST> {480C8E1D}>
* (make-instance '<test>)
#<<TEST> {480CC3DD}>
Nicolas.
P.S.: One problem which I have is that I do not succeed in getting Ilisp
into properly recognizing <> as part of a symbol. More precisely, when I
set
(set-ilisp-value 'ilisp-symbol-delimiters "^ \t\n\('\"#\)<>")
in my .ilisp-File, using M-x cmulisp gives the error:
"You must start an inferior LISP with run-ilisp."
(I should ask on the ilisp-list, I know...)
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> Frode Vatvedt Fjeld <······@cs.uit.no> writes:
>
>> Presumably you are not overloading the reader syntax for #\< ?
>> So you should probably switch to using print-unreadable-object, which
>> will wrap your output in #<...>, and more.
>
> (No, I don't.) I guess I don't understand the problem - could you
> elaborate? I'm using something like:
>
> * (defclass <test> ()
> ())
Oh, sorry, I thoght you were saying you wrote print-object methods
that would print objects of type test something like "<test ...>".
--
Frode Vatvedt Fjeld
Hi Lars Brinkhoff,
> So in summary, the standard non-alphanumeric characters can be
> classified something like this, right?
>
> Reserved by CL: "'(),:;\`|
> Reserved for user: !?[]{}
> Macro char at start of symbol: #
> Has CL convention: &
> Have (some) user conventions: %*+-./
> Have mathematical meaning: <=>
> Remaining: ·@^_~
Here's my attempt at the table ;-)
<http://www.lispworks.com/reference/HyperSpec/Body/02_ad.htm>
No character is reserved since all can be escaped, e.g. (in readtable
invert mode):
* '|"(This; is: `a ,symbol)"|
|"(This; is: `a ,symbol)"|
# is a dispatching macro character:
<http://www.lispworks.com/reference/HyperSpec/Body/02_dh.htm>
* + . / are just predefined symbols. Nothing that can't be redefined:
(defun * (&rest args) (apply #'+ args))
(* 1 2 3 4) => 10
Regards,
Adam
"Adam Warner" <······@consulting.net.nz> wrote in message
···································@consulting.net.nz...
> Hi Lars Brinkhoff,
>
> > So in summary, the standard non-alphanumeric characters can be
> > classified something like this, right?
> >
> > Reserved by CL: "'(),:;\`|
> > Reserved for user: !?[]{}
> > Macro char at start of symbol: #
> > Has CL convention: &
> > Have (some) user conventions: %*+-./
> > Have mathematical meaning: <=>
> > Remaining: ·@^_~
>
> Here's my attempt at the table ;-)
> <http://www.lispworks.com/reference/HyperSpec/Body/02_ad.htm>
>
> No character is reserved since all can be escaped, e.g. (in readtable
> invert mode):
>
> * '|"(This; is: `a ,symbol)"|
>
> |"(This; is: `a ,symbol)"|
>
> # is a dispatching macro character:
> <http://www.lispworks.com/reference/HyperSpec/Body/02_dh.htm>
>
> * + . / are just predefined symbols. Nothing that can't be redefined:
>
> (defun * (&rest args) (apply #'+ args))
> (* 1 2 3 4) => 10
>
> Regards,
> Adam
It's not good coding style to redefine built in operators--esp.
if you change their syntax.
If you add features such as allowing * to operator over
arrays now that's an other story.
But packages are usually used in case their is an error in the
* code. You can still use the built-in star.
Hi Franz Kafka,
>> (defun * (&rest args) (apply #'+ args))
>> (* 1 2 3 4) => 10
>>
>> Regards,
>> Adam
>
> It's not good coding style to redefine built in operators--esp.
> if you change their syntax.
I tend to disagree. Since I have been redefining * as + all my code has
been so much easier to understand.
Regards,
Adam
On Fri, May 23, 2003 at 01:11:30AM +1200, Adam Warner wrote:
> * + . / are just predefined symbols. Nothing that can't be redefined:
The consequences of doing so are undefined.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Hi Matthew Danish,
> On Fri, May 23, 2003 at 01:11:30AM +1200, Adam Warner wrote:
>> * + - / are just predefined symbols. Nothing that can't be redefined:
>
> The consequences of doing so are undefined.
[Replaced the . with a - as in the message supersede]
The intent (since I misunderstood the topic) was to point out that these
are mere symbols. It's a remarkable difference compared to ALGOL where one
has user function notation segregated from other special operators like *,
+, - and /.
Would you mind pointing out in the HyperSpec where it states that the
consequences are undefined? I can imagine the problems since compiled code
should be able to eliminate potential function calls to basic operators
such as * as a useful optimisation.
Regards,
Adam
Adam Warner wrote:
> Would you mind pointing out in the HyperSpec where it states that the
> consequences are undefined?
11.1.2.1.2 Constraints on the COMMON-LISP Package for Conforming Programs
Paul
Hi Paul F. Dietz,
> Adam Warner wrote:
>
>> Would you mind pointing out in the HyperSpec where it states that the
>> consequences are undefined?
>
> 11.1.2.1.2 Constraints on the COMMON-LISP Package for Conforming
> Programs
Thanks Paul. I wasn't looking in the Packages chapter of the HyperSpec
(although it's a sensible place to look for constraints on the COMMON-LISP
package!)
That's a lot of exceptions! The relevant constraint is:
2. Defining, undefining, or binding it as a function. (Some exceptions are
noted below.)
(and the exceptions aren't relevant)
Regards,
Adam
Adam Warner wrote:
> That's a lot of exceptions! The relevant constraint is:
> 2. Defining, undefining, or binding it as a function. (Some exceptions are
> noted below.)
>
> (and the exceptions aren't relevant)
Note, however, that if a user wants a custom +, it can be done
by working in a package where + isn't CL:+. So in practice
it's not a big deal.
Paul
"Paul F. Dietz" <·····@dls.net> wrote in message
···························@dls.net...
> Adam Warner wrote:
>
> > That's a lot of exceptions! The relevant constraint is:
> > 2. Defining, undefining, or binding it as a function. (Some exceptions
are
> > noted below.)
> >
> > (and the exceptions aren't relevant)
>
> Note, however, that if a user wants a custom +, it can be done
> by working in a package where + isn't CL:+. So in practice
> it's not a big deal.
>
> Paul
>
if anyone wants to redefine CL:+ or CL:* to do anything
other that the math funct. and damages the functions so
they don't work according to CLtL2, ANSI or CLHS
many librarys that relie on CL:+ or CL:* will break.
You never know maybe CL:sqrt or CL:expt or
any other fuction depends on CL:+ or CL:* to
do their work.
This is directed to the guy who wanted to redefine CL:*
to be CL:+ -- many more math funcs. could end up
breaking, and some librarys too--iff they depend on
CL:* or CL:+
however, nothing prevents you from extending CL:* or
CL:+ as long as you can "garentee" that the standard
def. of the functions remains "unchanged."
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> wrote in message
····················@news01.roc.ny.frontiernet.net...
>
>
> however, nothing prevents you from extending CL:* or
> CL:+ as long as you can "garentee" that the standard
> def. of the functions remains "unchanged."
>
That is incorrect, it is still undefined behaviour, a conforming
implementation is allowed to self-destruct.
Read 11.1.2.1.2 and 11.1.2.1.2.1 of the CLHS
http://www.lispworks.com/reference/HyperSpec/Body/11_abab.htm
http://www.lispworks.com/reference/HyperSpec/Body/11_ababa.htm
However, you can shadow the definition in another package and do whatever
you want.
--
Geoff
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> however, nothing prevents you from extending CL:* or
> CL:+ as long as you can "garentee" that the standard
> def. of the functions remains "unchanged."
How do you "extend" the definition without "changing" the definition?
Hi Franz Kafka,
> This is directed to the guy who wanted to redefine CL:* to be CL:+ --
> many more math funcs. could end up breaking, and some librarys too--iff
> they depend on CL:* or CL:+
Words fail me how whatever-your-name-is could conclude for even a moment
that I was serious.
Regards,
Adam
"Adam Warner" <······@consulting.net.nz> wrote in message
···································@consulting.net.nz...
> Hi Franz Kafka,
>
> > This is directed to the guy who wanted to redefine CL:* to be CL:+ --
> > many more math funcs. could end up breaking, and some librarys too--iff
> > they depend on CL:* or CL:+
>
> Words fail me how whatever-your-name-is could conclude for even a moment
> that I was serious.
I had programmers who wanted to do all kinds of weird things.
I could see extending the math functions to work over arrays,
by shadowing CL:* and CL:+ and replacing them with
Vetor:* (also works like CL:* for numbers) and Vector:+ (also works like
CL:+ for numbers)
I've know programmers, mostly C programmers trying 2 turn C
into Pascal ;) define things like
#define begin {
#define end }
#define var &
and ending up with a nightmare worse than any you could imagine :)
void main()
begin
....
end
so, I don't put 2 much past people. Sorry, if that is not you.
But, at least u wont shoot your self in the foot ;), and then
complain about how your Lisp broke. BTW, if you want to
extend a function--expect the compiler to break, and test
test test :-> (if the extension works, and is useful more people
might start using it, and it could before a defacto standard.
(I think I am going to try to create, in a Vector package of course,
math for vectors that will run in ANSI CL, expect this in a few
months--I am busy with school. :) + plus it should be alot easier than alot
of the other things I was thinking about doing.)
>
> Regards,
> Adam
Hi Lars Brinkhoff,
> So in summary, the standard non-alphanumeric characters can be
> classified something like this, right?
>
> Reserved by CL: "'(),:;\`|
> Reserved for user: !?[]{}
> Macro char at start of symbol: #
> Has CL convention: &
> Have (some) user conventions: %*+-./
> Have mathematical meaning: <=>
> Remaining: ·@^_~
Here's my attempt at the table ;-)
<http://www.lispworks.com/reference/HyperSpec/Body/02_ad.htm>
No character is reserved since all can be escaped, e.g. (in readtable
invert mode):
* '|"(This; is: `a ,symbol)"|
|"(This; is: `a ,symbol)"|
# is a dispatching macro character:
<http://www.lispworks.com/reference/HyperSpec/Body/02_dh.htm>
* + - / are just predefined symbols. Nothing that can't be redefined:
(defun * (&rest args) (apply #'+ args))
(* 1 2 3 4) => 10
Regards,
Adam
"Adam Warner" <······@consulting.net.nz> writes:
> No character is reserved since all can be escaped, e.g.
> * '|"(This; is: `a ,symbol)"|
That's right, but I was asking about naming conventions. (Perhaps you
didn't see the start of the thread.) Are you saying you conventionally
use symbols like that?
> > Macro char at start of symbol: #
> # is a dispatching macro character
But it's not a terminating macro character, so it can be used
unescaped in symbols, except at the start. Or am I confused? Still,
it's perhaps a poor choise of character to use in symbols.
Hi Lars Brinkhoff,
> "Adam Warner" <······@consulting.net.nz> writes:
>> No character is reserved since all can be escaped, e.g.
>> * '|"(This; is: `a ,symbol)"|
>
> That's right, but I was asking about naming conventions. (Perhaps you
> didn't see the start of the thread.) Are you saying you conventionally
> use symbols like that?
Thanks for the topic reminder! No I don't conventionally use symbols like
that. Just pointing out that they are not reserved.
>> > Macro char at start of symbol: #
>> # is a dispatching macro character
>
> But it's not a terminating macro character, so it can be used
> unescaped in symbols, except at the start. Or am I confused? Still,
> it's perhaps a poor choice of character to use in symbols.
It's great to learn something new! Printing differences between
implementations are interesting though (both ANSI readtable invert mode):
CLISP: 'a#bc => a#bc
CMUCL: 'a#bc => |A#BC|
NB: (eq 'a#bc '|A#BC|) => t
Regards,
Adam
Peter Seibel <·····@javamonkey.com> writes:
> Another style/usage/good practice question: how often do you use
> non-global special variables. I.e. variables that are "declared"
> special but not "proclaimed" or "declaimed" special (whether
> explicitly or implicitly by DEFVAR)?
When trying to reduce the dependency of a program on special variables,
this is often a transitional strategy. Legacy code sometimes either comes
this way out-of-the-dusty-box or moves this way over time.
When trying to set up an evaluation environment for a call EVAL, this
is one way to do it (if you know in advance that the variable name;
otherwise, PROGV is how you do it and the declarations are not required).
When working with a variable whose name is necessarily fixed by an external
force to not have *'s around it, it might be considered polite to do explicit
binds each time, just so no one accidentally binds it thinking it's lexical
or accidentally reads your code thinking it is.
There may be other cases.
> Also, when you do, do you still name them with *'s around the name or
> are the *'s reserved for globally special variables?
The rule is more often violated in that case.