Is there ever a reason to use setq in preference to setf? As far as
I can tell, the following forms are identical in effect:
(setf a 1) => 1
(setq a 1) => 1
However, setq only takes a symbol for its first arg. I can't use it
like this:
(setf a '(1 2 3)) => (1 2 3)
(setf (car a) 6) => 6
a => (6 2 3)
(setq (car a) 1) => ERROR!
There is also set, but the CLHS says it is deprecated.
Since setf can do what setq can do, and more, why should anyone use
setq?
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
David Steuber <·············@verizon.net> writes:
> Is there ever a reason to use setq in preference to setf? As far as
> I can tell, the following forms are identical in effect:
>
> (setf a 1) => 1
> (setq a 1) => 1
>
> However, setq only takes a symbol for its first arg. I can't use it
> like this:
>
> (setf a '(1 2 3)) => (1 2 3)
> (setf (car a) 6) => 6
> a => (6 2 3)
> (setq (car a) 1) => ERROR!
>
> There is also set, but the CLHS says it is deprecated.
>
> Since setf can do what setq can do, and more, why should anyone use
> setq?
Nostalgia. Stick with SETF.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> > Since setf can do what setq can do, and more, why should anyone use
> > setq?
>
> Nostalgia. Stick with SETF.
Good enough for me. Thanks.
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
David Steuber wrote:
> Is there ever a reason to use setq in preference to setf? As far as
> I can tell, the following forms are identical in effect:
>
> (setf a 1) => 1
> (setq a 1) => 1
>
> However, setq only takes a symbol for its first arg. I can't use it
> like this:
>
> (setf a '(1 2 3)) => (1 2 3)
> (setf (car a) 6) => 6
> a => (6 2 3)
> (setq (car a) 1) => ERROR!
>
> There is also set, but the CLHS says it is deprecated.
>
> Since setf can do what setq can do, and more, why should anyone use
> setq?
>
This is tangential, but there is no MULTIPLE-VALUE-SETF, which is why
you would use MULTIPLE-VALUE-SETQ... :)
On Wed, 24 Mar 2004 05:02:10 GMT, David Sletten <·····@slytobias.com> wrote:
> This is tangential, but there is no MULTIPLE-VALUE-SETF, which is
> why you would use MULTIPLE-VALUE-SETQ... :)
* (let ((a (list 1 2 3)))
(setf (values (first a) (third a))
(values 42 'foo))
a)
(42 2 FOO)
Edi.
Edi Weitz wrote:
> On Wed, 24 Mar 2004 05:02:10 GMT, David Sletten <·····@slytobias.com> wrote:
>
>
>>This is tangential, but there is no MULTIPLE-VALUE-SETF, which is
>>why you would use MULTIPLE-VALUE-SETQ... :)
>
>
> * (let ((a (list 1 2 3)))
> (setf (values (first a) (third a))
> (values 42 'foo))
> a)
>
> (42 2 FOO)
>
> Edi.
Can you please give a little explanation for this code snippet?
I don't understand why it works the way it works.
Andr�
--
>>>>> On Thu, 25 Mar 2004 01:05:05 +0100, Andr� Thieme ("Andr�") writes:
>Edi Weitz wrote:
>
> (let ((a (list 1 2 3)))
> (setf (values (first a) (third a))
> (values 42 'foo))
> a)
>
> ==> (42 2 FOO)
Andr�> Can you please give a little explanation for this code
Andr�> snippet? I don't understand why it works the way it works.
It creates a list of three numbers and binds the variable A
to that list, then mutates the list, and then returns the
value of A.
The thing you probably don't understand is that SETF is a special
form. The arguments given to a special form are Lisp forms (that is,
source code -- lists). The normal syntactic rules of evaluation are
not in play, which is why these are called "special" forms.
A special form analyzes the source code it's given and delivers
whatever semantics it's defined to. (This is conceptually almost
the same as what a macro does when a macro transforms source code
into new source code in its place.)
SETF's first argument is construed to represent an abstract "place"
that can have a value. The second argument is the value to put in the
place. For example, the simplest usage of SETF is to set a variable:
(SETF X 42) assigned 42 to the variable X. But SETF can set more
interesting "places" besides just variables named by symbols.
(FIRST A) and (THIRD A) refer to positional elements
located in the list that's bound to A, of course.
VALUES is how multiple values are returned in Lisp.
(VALUES 1 2) would result in two values, 1 and 2.
In the context of a normal function call
(VALUES (FIRST A) (THIRD A))
would return two values: 1 and 2.
But we're not making any function call -- we're in the context
of the special form SETF, and the semantics of SETF are that
this argument represents the "place" where SETF will (by means
that are opaque to us) set a value. VALUES is the abstract
reference that tells SETF that it's supposed to set the value
of multiple places (each of which will in turn be some kind
of abstract reference that SETF understands).
The second argument to SETF is defined to be the value that
will be put in the "place". The second argument is defined
to be evaluated like normal.
Original value of A: (1 2 3)
| |
+-------- + +--+
| |
(VALUES (FIRST A) (THIRD A))
(VALUES 42 'FOO) => 42, FOO
Original value of A: (1 2 3)
New value of A: (42 2 FOO))
So the example code fragment is saying, "Please set two places,
the first and third elements of the list in A, to the corresponding
two values 42 and FOO". And the function returns the list in A.
If you think about how Lisp normally evaluates an expression,
you can see that SETQ is also a special form like SETF.
It must be, since the first argument to SETQ is not evaluated,
but is instead a piece of code that abstractly represents a
location to be set. The difference is that SETQ restricts its
first argument to be just a symbol, while SETF allows more
complex pieces of code representing a variety of kinds of "places".
Chris
······@news.dtpq.com (Christopher C. Stacy) wrote in message news:<·············@news.dtpq.com>...
>
> The thing you probably don't understand is that SETF is a special
> form. The arguments given to a special form are Lisp forms (that is,
> source code -- lists). The normal syntactic rules of evaluation are
> not in play, which is why these are called "special" forms.
> A special form analyzes the source code it's given and delivers
> whatever semantics it's defined to. (This is conceptually almost
> the same as what a macro does when a macro transforms source code
> into new source code in its place.)
In fact, it's conceptually identical, because SETF is a macro, not a
special operator.
Tim Bradshaw wrote:
> ······@news.dtpq.com (Christopher C. Stacy) wrote in message news:<·············@news.dtpq.com>...
>
>
>>The thing you probably don't understand is that SETF is a special
>>form. The arguments given to a special form are Lisp forms (that is,
>>source code -- lists). The normal syntactic rules of evaluation are
>>not in play, which is why these are called "special" forms.
>>A special form analyzes the source code it's given and delivers
>>whatever semantics it's defined to. (This is conceptually almost
>>the same as what a macro does when a macro transforms source code
>>into new source code in its place.)
>
>
> In fact, it's conceptually identical, because SETF is a macro, not a
> special operator.
Are there any "special operators" in Lisp? Or does it in every case mean
that (when someone is talking about them) it is a macro?
Andr�
--
On Thu, 25 Mar 2004 22:14:10 +0100, Andr� Thieme <······································@justmail.de> wrote:
> Are there any "special operators" in Lisp?
* (do-external-symbols (symbol :common-lisp (values))
(when (special-operator-p symbol)
(print symbol)))
PROGV
MULTIPLE-VALUE-CALL
GO
THROW
BLOCK
LABELS
MULTIPLE-VALUE-PROG1
FUNCTION
LOAD-TIME-VALUE
QUOTE
THE
LET
LET*
EVAL-WHEN
LOCALLY
TAGBODY
CATCH
UNWIND-PROTECT
MACROLET
FLET
DECLARE
SYMBOL-MACROLET
IF
SETQ
PROGN
RETURN-FROM
See also 3.1.2.1.2.1 of the CLHS.
> Or does it in every case mean that (when someone is talking about
> them) it is a macro?
Quoting from 3.1.2.1.2.2:
"An implementation is free to implement a Common Lisp special
operator as a macro. An implementation is free to implement any
macro operator as a special operator, but only if an equivalent
definition of the macro is also provided."
In other words: Although your Lisp can decide to /implement/ some
special operators as macros and vice versa, to the user it must look
as if they were special operators or macros as defined in the ANSI
standard.
Edi.
Frankly, I can never remember which things are macros and which
are special forms, since they effectively mean the same thing.
The difference is just that a special form does not necessarily
work by macro expansion -- it may be known to the compiler in
some more magical opaque way. The thing for the newbie programmer
to understand is that special forms and macros are both Lisp forms
that have arbitrary rules of evaluation (and that there is a means
for the programmer to define new macros).
Newbies like to explore Lisp by drawing conclusions from the results
of interactive experimentation. One thing to note for them is that
some macros provided in the Lisp standard may expand into code that
exposes internal implementation details; the resulting code may be
educational, but it's not necessarily an example they should follow.
The existence of special forms and macros is why it's not true that
"Lisp has no syntax" or that "the syntax is entirely regular", etc.
The only part that's really regular is that the CAR of the form
is the thing that somehow controls what the CDR of the form means.
In a normal function call, the CDR consists of things to be evaluated,
but in special forms and macros, the meaning of CDR depends on the
syntax rules that defined by what's the CAR.
Christopher C. Stacy wrote:
> The existence of special forms and macros is why it's not true that
> "Lisp has no syntax" or that "the syntax is entirely regular", etc.
> The only part that's really regular is that the CAR of the form
> is the thing that somehow controls what the CDR of the form means.
> In a normal function call, the CDR consists of things to be evaluated,
> but in special forms and macros, the meaning of CDR depends on the
> syntax rules that defined by what's the CAR.
In other programming languages, the term "syntax" usually means the
stuff that is described by a grammar, for example specified in BNF. In
this light, Lisp definitely has an extremely simple syntax. The
evaluation rules for special forms and macros would already be
considered part of the semantics. But you're right, the distinction you
make is the more important one.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Andr� Thieme <······································@justmail.de> wrote:
+---------------
| Tim Bradshaw wrote:
| > In fact, it's conceptually identical, because SETF is a macro, not a
| > special operator.
|
| Are there any "special operators" in Lisp? Or does it in every case
| mean that (when someone is talking about them) it is a macro?
+---------------
Yes; and no, not necessarily (but maybe). There *are* special operator
in Common Lisp, see CLHS "3.1.2.1.2.1 Special Forms" for a list:
The set of special operator names is fixed in Common Lisp;
no way is provided for the user to define a special operator.
The next figure lists all of the Common Lisp symbols that have
definitions as special operators.
block let* return-from
catch load-time-value setq
eval-when locally symbol-macrolet
flet macrolet tagbody
function multiple-value-call the
go multiple-value-prog1 throw
if progn unwind-protect
labels progv
let quote
Figure 3-2. Common Lisp Special Operators
HOWEVER... There is a good reason you might occasionally be a little bit
confused about that, namely CLHS "3.1.2.1.2.2 Macro Forms", which says:
An implementation is free to implement a Common Lisp special
operator as a macro.
And conversely:
An implementation is free to implement any macro operator as a
special operator, but only if an equivalent definition of the
macro is also provided.
All clear now??? ;-} ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Andr� Thieme <······································@justmail.de> wrote in message news:<············@ulric.tng.de>...
>
> Are there any "special operators" in Lisp? Or does it in every case mean
> that (when someone is talking about them) it is a macro?
Yes, there are some really special magic things, but not very many
(20-something, I forget). You can find them by enumerating the
symbols in CL and asking SPECIAL-OPERATOR-P of them.
From the user point of view the difference is often small - who cares
if IF is a macro or a special operator, really? From the point of
view of a program which is trying to understand Lisp code, the
difference is crucial, because it has to understand all the special
operators, while it can just expand macros. I think there are some
ugly issues that (perhaps) macros can expand to
implementation-specific special-operators or something, which is bad
news for anything that wants to portably understand code.
--tim
Tim Bradshaw wrote:
> I think there are some ugly issues that (perhaps) macros
> can expand to implementation-specific special-operators or
> something, which is bad news for anything that wants to
> portably understand code.
3.1.2.1.2.2 Macro Forms says that
An implementation is free to implement a Common Lisp
special operator as a macro. An implementation is free
to implement any macro operator as a special operator,
but only if an equivalent definition of the macro is
also provided.
So your code walker should be able to obtain macro
expansions and understand the code, even it the
implementation doesn't actually do it the way the
macroexpansion says.
Alan
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> Tim Bradshaw wrote:
>> I think there are some ugly issues that (perhaps) macros
>> can expand to implementation-specific special-operators or
>> something, which is bad news for anything that wants to
>> portably understand code.
>
> 3.1.2.1.2.2 Macro Forms says that
>
> An implementation is free to implement a Common Lisp
> special operator as a macro. An implementation is free
> to implement any macro operator as a special operator,
> but only if an equivalent definition of the macro is
> also provided.
>
> So your code walker should be able to obtain macro expansions and
> understand the code, even it the implementation doesn't actually do
> it the way the macroexpansion says.
Unfortunately (for code analyzers) there's nothing that says that the
macros defined in the standard must expand only into forms with
semantics defined by the standard. For example an implementation could
define DOTIMES as:
(defmacro dotimes ((var count-form &optional result-form) &body body)
`(sys::do-dotimes ,var ,count-form ,result-form ,body))
After your code analyzer macroexpands a DOTIMES call, you still have
no way of determining what actually happens other than by the
definition of DOTIMES.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Christopher C. Stacy wrote:
>>>>>>On Thu, 25 Mar 2004 01:05:05 +0100, Andr� Thieme ("Andr�") writes:
>
>
> >Edi Weitz wrote:
> >
> > (let ((a (list 1 2 3)))
> > (setf (values (first a) (third a))
> > (values 42 'foo))
> > a)
> >
> > ==> (42 2 FOO)
>
> Andr�> Can you please give a little explanation for this code
> Andr�> snippet? I don't understand why it works the way it works.
>
> It creates a list of three numbers and binds the variable A
> to that list, then mutates the list, and then returns the
> value of A.
>
> The thing you probably don't understand is that SETF is a special
> form. The arguments given to a special form are Lisp forms (that is,
> source code -- lists). The normal syntactic rules of evaluation are
> not in play, which is why these are called "special" forms.
> A special form analyzes the source code it's given and delivers
> whatever semantics it's defined to. (This is conceptually almost
> the same as what a macro does when a macro transforms source code
> into new source code in its place.)
>
> SETF's first argument is construed to represent an abstract "place"
> that can have a value. The second argument is the value to put in the
> place. For example, the simplest usage of SETF is to set a variable:
> (SETF X 42) assigned 42 to the variable X. But SETF can set more
> interesting "places" besides just variables named by symbols.
>
> (FIRST A) and (THIRD A) refer to positional elements
> located in the list that's bound to A, of course.
>
> VALUES is how multiple values are returned in Lisp.
> (VALUES 1 2) would result in two values, 1 and 2.
>
> In the context of a normal function call
> (VALUES (FIRST A) (THIRD A))
> would return two values: 1 and 2.
>
> But we're not making any function call -- we're in the context
> of the special form SETF, and the semantics of SETF are that
> this argument represents the "place" where SETF will (by means
> that are opaque to us) set a value. VALUES is the abstract
> reference that tells SETF that it's supposed to set the value
> of multiple places (each of which will in turn be some kind
> of abstract reference that SETF understands).
>
> The second argument to SETF is defined to be the value that
> will be put in the "place". The second argument is defined
> to be evaluated like normal.
>
> Original value of A: (1 2 3)
> | |
> +-------- + +--+
> | |
> (VALUES (FIRST A) (THIRD A))
>
> (VALUES 42 'FOO) => 42, FOO
>
> Original value of A: (1 2 3)
> New value of A: (42 2 FOO))
>
> So the example code fragment is saying, "Please set two places,
> the first and third elements of the list in A, to the corresponding
> two values 42 and FOO". And the function returns the list in A.
>
> If you think about how Lisp normally evaluates an expression,
> you can see that SETQ is also a special form like SETF.
> It must be, since the first argument to SETQ is not evaluated,
> but is instead a piece of code that abstractly represents a
> location to be set. The difference is that SETQ restricts its
> first argument to be just a symbol, while SETF allows more
> complex pieces of code representing a variety of kinds of "places".
Very well written, I now understand this issue 100%. *cheers*
This explanation should be saved for future newcomers.
Andr�
--
Andr� Thieme <······································@justmail.de> writes:
> Very well written, I now understand this issue 100%. *cheers*
> This explanation should be saved for future newcomers.
Does someone else besides Google archive c.l.l in a searchable
fashion?
Edi's setf example was certainly more creative than I expected from
any kind of "asignment" operator. That was good. SETF is even
_more_ flexible than I thought.
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
Andr� Thieme wrote:
> Edi Weitz wrote:
>
>> On Wed, 24 Mar 2004 05:02:10 GMT, David Sletten <·····@slytobias.com>
>> wrote:
>>
>>
>>> This is tangential, but there is no MULTIPLE-VALUE-SETF, which is
>>> why you would use MULTIPLE-VALUE-SETQ... :)
>>
>>
>>
>> * (let ((a (list 1 2 3)))
>> (setf (values (first a) (third a))
>> (values 42 'foo))
>> a)
>>
>> (42 2 FOO)
>>
>> Edi.
>
>
> Can you please give a little explanation for this code snippet?
> I don't understand why it works the way it works.
The LET binds the list (1 2 3) to the variable a.
SETF takes a settable-place, and a value to be stored there. (Actually,
it can take any number of settable-places and values, alternating, but
let's keep it simple). So, you can say
(SETF <PLACE> <VALUE>)
The most common thing for <PLACE> to be is a variable name, as in
(SETF X 10)
which sets X to 10. However, lots of other places are settable. For
example, slot-values on CLOS objects are settable, so if you imagine
that you had defined a cartesian point class, then you could expect to
do something like
(SETF (slot-value my-point 'x-coordinate) 100)
Things like CAR and CDR are settable, so you can do
(SETF (CAR my-list) my-head)
(SETF (CDR my-list) my-tail)
And, in the example above, the subexpressions of the first VALUES
expression are settable; SETF sets them to the values of the
corresponding subexpressions of the second VALUES expression, mutating
the list bound to a.
"mikel" <·····@evins.net> wrote in message
·························@newssvr27.news.prodigy.com...
> Andr� Thieme wrote:
> > Edi Weitz wrote:
...
> >> * (let ((a (list 1 2 3)))
> >> (setf (values (first a) (third a))
> >> (values 42 'foo))
> >> a)
> >>
> >> (42 2 FOO)
> >>
> >> Edi.
> >
> >
> > Can you please give a little explanation for this code snippet?
> > I don't understand why it works the way it works.
>
> The LET binds the list (1 2 3) to the variable a.
>
...
> And, in the example above, the subexpressions of the first VALUES
> expression are settable; SETF sets them to the values of the
> corresponding subexpressions of the second VALUES expression, mutating
> the list bound to a.
So VALUES is the ,@ of the function return world?
a wrote:
> "mikel" <·····@evins.net> wrote in message
> ·························@newssvr27.news.prodigy.com...
>
>>Andr� Thieme wrote:
>>
>>>Edi Weitz wrote:
>
> ...
>
>>>> * (let ((a (list 1 2 3)))
>>>> (setf (values (first a) (third a))
>>>> (values 42 'foo))
>>>> a)
>>>>
>>>> (42 2 FOO)
>>>>
>>>>Edi.
>>>
>>>
>>>Can you please give a little explanation for this code snippet?
>>>I don't understand why it works the way it works.
>>
>>The LET binds the list (1 2 3) to the variable a.
>>
>
> ...
>
>>And, in the example above, the subexpressions of the first VALUES
>>expression are settable; SETF sets them to the values of the
>>corresponding subexpressions of the second VALUES expression, mutating
>>the list bound to a.
>
>
> So VALUES is the ,@ of the function return world?
I suppose you could look at it like that. VALUES returns multiple
values, so SETF of VALUES sets multiple values.
When I was just starting to learn Lisp, I thought SETF was one of the
coolest things ever. I still think it's pretty handy.
On Thu, 25 Mar 2004 01:05:05 +0100, Andr� Thieme <······································@justmail.de> wrote:
> Can you please give a little explanation for this code snippet? I
> don't understand why it works the way it works.
In addition to the fine explanations others have already given
consider the fact that in good Lisp tradition SETF itself is of course
extendable, i.e. you can define new kinds of 'places' on which SETF
can operate. A simple (and, again, silly) example would be a function
'3rd' which always returns the third element of an array:
* (defun 3rd (arr) (aref arr 2))
3RD
* (defun (setf 3rd) (new-value arr) (setf (aref arr 2) new-value))
(SETF 3RD)
* (let ((a (make-array 5 :initial-element 0)))
(print (3rd a))
(setf (3rd a) 42)
a)
0
#(0 0 42 0 0)
For more interesting stuff see DEFSETF and DEFINE-SETF-EXPANDER in the
ANSI standard and the corresponding chapters in Graham's "On Lisp."
Cheers,
Edi.
Edi Weitz <···@agharta.de> writes:
> On Thu, 25 Mar 2004 01:05:05 +0100, Andr� Thieme <······································@justmail.de> wrote:
>
> > Can you please give a little explanation for this code snippet? I
> > don't understand why it works the way it works.
>
> In addition to the fine explanations others have already given
> consider the fact that in good Lisp tradition SETF itself is of course
> extendable, i.e. you can define new kinds of 'places' on which SETF
> can operate. A simple (and, again, silly) example would be a function
> '3rd' which always returns the third element of an array:
>
> * (defun 3rd (arr) (aref arr 2))
>
> 3RD
> * (defun (setf 3rd) (new-value arr) (setf (aref arr 2) new-value))
>
> (SETF 3RD)
> * (let ((a (make-array 5 :initial-element 0)))
> (print (3rd a))
> (setf (3rd a) 42)
> a)
>
> 0
> #(0 0 42 0 0)
Here's yet another one of those great but seldom-thought-of
applications for macros:
If you define 3rd as a macro instead of a function and it
expands to something setf-able, then you get the setf
capability for free, without having to define an inverse function
for it:
(defmacro 3rd (arr) `(aref ,arr 2))
Now 3rd works as itself and as a setf place.
--
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 Thu, 25 Mar 2004 01:05:05 +0100, Andr� Thieme <······································@justmail.de> wrote:
>> * (let ((a (list 1 2 3)))
>> (setf (values (first a) (third a))
>> (values 42 'foo))
>> a)
>> (42 2 FOO)
>
> Can you please give a little explanation for this code snippet? I
> don't understand why it works the way it works.
You can of course simply ask your Lisp how it works:
* (macroexpand '(setf (values (car a) b) (values x y)))
(LET* ((#:G1091 A))
(MULTIPLE-VALUE-BIND
(#:G1090 #:G1092)
(VALUES X Y)
(VALUES (COMMON-LISP::%RPLACA #:G1091 #:G1090) (SETQ B #:G1092))))
T
* (macroexpand '(setf (values (first a) (third a)) (values 42 'foo)))
(LET* ((#:G1094 A) (#:G1095 A))
(MULTIPLE-VALUE-BIND
(#:G1093 #:G1096)
(VALUES 42 'FOO)
(VALUES (COMMON-LISP::%RPLACA #:G1094 #:G1093)
(COMMON-LISP::%RPLACA (CDDR #:G1095) #:G1096))))
T
Edi.
Edi Weitz <···@agharta.de> writes:
> You can of course simply ask your Lisp how it works:
>
> * (macroexpand '(setf (values (car a) b) (values x y)))
Sorry :( I should read all thread first.
regards, szymon.
Edi Weitz wrote:
> On Thu, 25 Mar 2004 01:05:05 +0100, Andr� Thieme <······································@justmail.de> wrote:
>
>
>>> * (let ((a (list 1 2 3)))
>>> (setf (values (first a) (third a))
>>> (values 42 'foo))
>>> a)
>>> (42 2 FOO)
>>
>>Can you please give a little explanation for this code snippet? I
>>don't understand why it works the way it works.
>
>
> You can of course simply ask your Lisp how it works:
>
> * (macroexpand '(setf (values (car a) b) (values x y)))
Ah okay, I will remember this. I just played a bit with it and it seems
that it will give me a non-macro expression back unchanged. So there is
no "danger" involved by using it.
Andr�
--
Andr� Thieme writes:
> Can you please give a little explanation for this code snippet?
> I don't understand why it works the way it works.
I'm not Edi, sorry ;) , but:
macroexpand is your friend --
CL-USER> (macroexpand '(setf (values (first a) (third a)) (values 42 'foo)))
(LET* ((#:G2179 A) (#:G2180 A))
(MULTIPLE-VALUE-BIND
(#:G2178 #:G2181)
(VALUES 42 'FOO)
(VALUES (LISP::%RPLACA #:G2179 #:G2178)
(LISP::%RPLACA (CDDR #:G2180) #:G2181))))
regards, szymon.
David Sletten <·····@slytobias.com> wrote in message news:<····················@twister.socal.rr.com>...
> This is tangential, but there is no MULTIPLE-VALUE-SETF, which is why
> you would use MULTIPLE-VALUE-SETQ... :)
(setf (values ...) ...)
>>>>> On Wed, 24 Mar 2004 04:15:23 GMT, David Steuber ("David") writes:
David> Is there ever a reason to use setq in preference to setf?
David> Since setf can do what setq can do, and more,
David> why should anyone use setq?
David> There is also set, but the CLHS says it is deprecated.
SETQ and SET are historical legacies from the original Lisp
languages that directly preceeded Common Lisp. SETF was new,
and was not used by the large body of existing programs for
which Common Lisp was designed to be portability target.
Note that SETQ is "a special form of SET", and so if you are
writing code that sets variables by calling the SET function,
you might want nearby code to employ the contrasting SETQ function.
But people don't really write SET anymore, because most variables
are lexical variables. And if you want to set a value cell,
nowadays you can SETF the SYMBOL-VALUE instead.
The only reason to write SETQ anymore is to highlight the fact that
you're setting a variable. This is a pretty weak argument. since it's
syntactically obvious that you're setting a variable. (And it's not
even guaranteed to be true, anyway, in the face of symbol macros.)
If we were inventing a new Lisp dialect today, willing to break
compatability with old Lisp programs, we would get rid of SET, SETQ,
and SETF -- and we would just have a form named SET (meaning SETF).
When hacking variables, I always write SETQ rather than SETF.
Mostly this is because I am a geezer who has been writing it
that way since before Common Lisp was a twinkle in the eye.
And when I think about modernizing my personal style to use SETF
instead of SETQ, I get as annoyed by the letter "F" as by the "Q".
I am then tempted to start writing in my own dialect, using the
package system to make "SET" mean "SETF".
And I can't quite bring myself to do that.
Yet.
Christopher C. Stacy <······@news.dtpq.com> wrote:
+---------------
| SETQ and SET are historical legacies from the original Lisp ...
...
| Note that SETQ is "a special form of SET"...
+---------------
As this late-comer understands it, "In the beginnning there was SET..."
Only. And the evolution of style went something like this:
(set (quote foo) (+ baz 13)) ; Pronounced "SET QUOTEFOO..."
(set 'foo (+ baz 13)) ; Still pronounced "SET QUOTEFOO..."
(set' foo (+ baz 13)) ; Note the slightly different spacing!!
; Pronounced "SETQUOTE FOO..."
Then somebody did this (or the moral equivalent of it):
(defmacro setq (var val)
`(set ',var ,val))
(setq foo (+ baz 13)) ; Still pronounced "SETQUOTE FOO..."
Then when lexical variables can around, SETQ had to become a special
form, not just a macro. And then SETF and DEFSETF and SETF functions
happened, and that's where we are today.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Christopher C. Stacy <······@news.dtpq.com> wrote:
> +---------------
> | SETQ and SET are historical legacies from the original Lisp ...
> ...
> | Note that SETQ is "a special form of SET"...
> +---------------
>
> As this late-comer understands it, "In the beginnning there was SET..."
> Only. And the evolution of style went something like this:
>
> (set (quote foo) (+ baz 13)) ; Pronounced "SET QUOTEFOO..."
>
> (set 'foo (+ baz 13)) ; Still pronounced "SET QUOTEFOO..."
>
> (set' foo (+ baz 13)) ; Note the slightly different spacing!!
> ; Pronounced "SETQUOTE FOO..."
>
> Then somebody did this (or the moral equivalent of it):
>
> (defmacro setq (var val)
> `(set ',var ,val))
>
> (setq foo (+ baz 13)) ; Still pronounced "SETQUOTE FOO..."
IIRC from reading other posts, I think the history was that SETQ was
introduced at a time when the "'" reader macro wasn't available yet.
This makes sense because sometimes SETQ is described as an abbreviation,
but it isn't much of an abbreviation when you have "'" around.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
······@news.dtpq.com (Christopher C. Stacy) wrote in message news:<·············@news.dtpq.com>...
> >>>>> On Wed, 24 Mar 2004 04:15:23 GMT, David Steuber ("David") writes:
>
> David> Is there ever a reason to use setq in preference to setf?
>
> David> Since setf can do what setq can do, and more,
> David> why should anyone use setq?
>
> David> There is also set, but the CLHS says it is deprecated.
>
> SETQ and SET are historical legacies from the original Lisp
> languages that directly preceeded Common Lisp.
There exists a style guide for Lisp programming which suggests that
the most specific rather than most generic operation be chosen:
``Use the most specific construct that does the job. This lets readers
of the code see what you intended when writing the code. For example,
don't use SETF if SETQ will do (e.g., for lexical variables). Using
SETQ will tell readers of your code that you aren't doing anything
fancy. Likewise, don't use EQUAL where EQ will do. Use the most
specific predicate to test your conditions.''
http://www.lisp.org/table/style.htm
This guide is in need of some sanity review.
Using SETQ will not signal to your readers that you are doing nothing
fancy, because it has all the power of SETF hidden in it. The symbol
being assigned to could be a symbol macro expanding to an arbitrary
place form. Sheesh!
In article <····························@posting.google.com>,
···@ashi.footprints.net (Kaz Kylheku) wrote:
>
> There exists a style guide for Lisp programming which suggests that
> the most specific rather than most generic operation be chosen:
>
> ``Use the most specific construct that does the job. This lets readers
> of the code see what you intended when writing the code.
I certainly agree with the general principle.
> For example,
> don't use SETF if SETQ will do (e.g., for lexical variables). Using
> SETQ will tell readers of your code that you aren't doing anything
> fancy.
As an old-timer, I tend towards SETQ but that's personal bias, not principle.
> Likewise, don't use EQUAL where EQ will do. Use the most
> specific predicate to test your conditions.''
This is a different kettle of fish. Each of the equality predicates
has different semantics. None is "more specific" than another.
The relevant style rule is not about specificity, but doing the
usual thing. If your code has no special needs, it should use EQL.
The closest to SETF/SETQ for me is EQL vs =. If you working with
numbers, I recommend = over EQL. = will treat non-numeric data
as an error. It also fits in better with < and >.
> http://www.lisp.org/table/style.htm
>
> This guide is in need of some sanity review.
Apparently.
>
> Using SETQ will not signal to your readers that you are doing nothing
> fancy, because it has all the power of SETF hidden in it. The symbol
> being assigned to could be a symbol macro expanding to an arbitrary
> place form. Sheesh!
I think you're conflating communicating with guaranteeing. I think
using SETQ does communicate the normal intent to simply assign a variable.
It's redundant but redundant communication is good as long as it's not
repetitious. But, because of the special SETQ/SYMBOL-MACROLET rule, it
doesn't guarantee that's what you're doing.
On Thu, Mar 25, 2004 at 12:43:10PM -0600, Chris Riesbeck wrote:
> The closest to SETF/SETQ for me is EQL vs =. If you working with
> numbers, I recommend = over EQL. = will treat non-numeric data
> as an error. It also fits in better with < and >.
There's more than that:
(= 0.0 0) => T
(eql 0.0 0) => NIL
(eql 1.0s0 1.0d0) => NIL unless single and double-float are same
(= 1.0s0 1.0d0) => T
(eql 0.0 -0.0) => NIL if positive and negative zero are distinct
(= 0.0 -0.0) => T
Basically = understands arithmetic semantics better than EQL, which is a
simple comparison of type and immediate value (numbers, characters, and
identity).
--
; 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."
>>>>> On Thu, 25 Mar 2004 12:43:10 -0600, Chris Riesbeck ("Riesbeck") writes:
Riesbeck> I think using SETQ does communicate the normal
Riesbeck> intent to simply assign a variable.
That's the position I've always espoused, too, but I am recently
thinking that that's just a rationalization and that it's really
just pointless. You can plainly see that you are setting a variable.
If you're looking at a symbol in a SETQ/SETF and have no idea where
it came from, won't you go looking to see? And isn't it rather the
point that you don't, a priori, need to know whether it's a symbol
macro or something? Especially since SETQ works on symbol macros?
Chris Riesbeck <········@cs.northwestern.edu> writes:
> It's redundant but redundant communication is good as long as it's not
> repetitious.
I'm not sure why, but this line made me chuckle.
As for communicating information to the reader, I'm all for that. My
standard MO has been to try and be descriptive with the names of
functions and variables. Long names are not a huge issue when you
can do auto-completion while typing and comments can fall out of sync
with the code as it changes.
I don't eschew comments entirely, but I do comment my code less than
what some other programmers I've worked with in the past would seem
to prefer.
If someone else is reading my code, I hope that they can not only
figure out what I am trying to do, but also why. That last one is
tricky. I've read the MD5 hash algorithm in RFC-1321 and translated
it from K&R C to ANSI so that it could compile in a C++ compiler. I
knew exactly what it was doing, but not why it worked. The real
kicker of course is that Ron Rivest described the algorithm in the
RFC.
So much for literate programming and I think I am set on setf.
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
Kaz Kylheku wrote:
>
> ······@news.dtpq.com (Christopher C. Stacy) wrote in message news:<·············@news.dtpq.com>...
> > >>>>> On Wed, 24 Mar 2004 04:15:23 GMT, David Steuber ("David") writes:
> >
> > David> Is there ever a reason to use setq in preference to setf?
> >
> > ...
>
> There exists a style guide for Lisp programming which suggests that
> the most specific rather than most generic operation be chosen:
>
> ``Use the most specific construct that does the job. This lets readers
> of the code see what you intended when writing the code. For example,
> don't use SETF if SETQ will do (e.g., for lexical variables). Using
> SETQ will tell readers of your code that you aren't doing anything
> fancy. Likewise, don't use EQUAL where EQ will do. Use the most
> specific predicate to test your conditions.''
>
> http://www.lisp.org/table/style.htm
>
> This guide is in need of some sanity review.
>
> Using SETQ will not signal to your readers that you are doing nothing
> fancy, because it has all the power of SETF hidden in it. The symbol
> being assigned to could be a symbol macro expanding to an arbitrary
> place form. Sheesh!
intention counts. one view is to use setq for one purpose only. to set special
variables. both defparameter/defvar variables and variables with dynamic
bindings only. for everything else one uses setf.
...
In article <·············@news.dtpq.com>, Christopher C. Stacy
<······@news.dtpq.com> wrote:
> >>>>> On Wed, 24 Mar 2004 04:15:23 GMT, David Steuber ("David") writes:
>
> David> Is there ever a reason to use setq in preference to setf?
>
> David> Since setf can do what setq can do, and more,
> David> why should anyone use setq?
>
> David> There is also set, but the CLHS says it is deprecated.
>
> SETQ and SET are historical legacies from the original Lisp
> languages that directly preceeded Common Lisp. SETF was new,
> and was not used by the large body of existing programs for
> which Common Lisp was designed to be portability target.
I don't understand how SETQ can be a "historical legacy". What other
special form sets lexical variable bindings? Without this, there would
be yet another implementation-defined special form around instead of a
defined form for doing this.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook wrote:
> I don't understand how SETQ can be a "historical legacy". What other
> special form sets lexical variable bindings? Without this, there would
> be yet another implementation-defined special form around instead of a
> defined form for doing this.
SETQ was introduced at a time when Lisps weren't lexically scoped.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
>>>>> On Thu, 25 Mar 2004 09:00:30 -0500, Brian Mastenbrook ("Brian") writes:
Brian> In article <·············@news.dtpq.com>, Christopher C. Stacy
Brian> <······@news.dtpq.com> wrote:
>> >>>>> On Wed, 24 Mar 2004 04:15:23 GMT, David Steuber ("David") writes:
>>
David> Is there ever a reason to use setq in preference to setf?
>>
David> Since setf can do what setq can do, and more,
David> why should anyone use setq?
>>
David> There is also set, but the CLHS says it is deprecated.
>>
>> SETQ and SET are historical legacies from the original Lisp
>> languages that directly preceeded Common Lisp. SETF was new,
>> and was not used by the large body of existing programs for
>> which Common Lisp was designed to be portability target.
Brian> I don't understand how SETQ can be a "historical legacy".
Brian> What other special form sets lexical variable bindings?
SETF