Hello,
I'm rather new to lisp and I was wondering, if is it possible to have
two different names for the same variable in common lisp? If yes, how
would I do something like that?I googled and tried to look it up in
the news group, but without any
luck. This is either to easy to be written down somewhere or I'm just
not
aware of the correct terminology to ask the right question. So I hope
you
might help!
Thanks in advance for your help,
Lukas
--
Lukas Pustina
On Feb 21, 5:12 am, ··············@googlemail.com"
<·············@googlemail.com> wrote:
> I'm rather new to lisp and I was wondering, if is it possible to have
> two different names for the same variable in common lisp? If yes, how
> would I do something like that?
DEFINE-SYMBOL-MACRO.
Cheers,
Pillsy
On Feb 21, 10:12 am, ··············@googlemail.com"
<·············@googlemail.com> wrote:
> Hello,
>
> I'm rather new to lisp and I was wondering, if is it possible to have
> two different names for the same variable in common lisp? If yes, how
> would I do something like that?I googled and tried to look it up in
> the news group, but without any
> luck. This is either to easy to be written down somewhere or I'm just
> not
> aware of the correct terminology to ask the right question. So I hope
> you
> might help!
Well it depends what you're doing. By the time you come to be passing
complex structures like lists, arrays or objects around they're passed
by reference anyway so you get these capabilities for free. It's only
if you're passing little things like numbers about that you have to
work to get these capabilities.
See below for an example.
Chris
CL-USER> (defparameter x 5)
X
CL-USER> (defparameter y x)
Y
CL-USER> (setf x 3)
3
CL-USER> y
5
CL-USER> (defparameter x '(5))
X
CL-USER> (defparameter y x)
Y
CL-USER> (setf (first x) 3)
3
CL-USER> y
(3)
On 21 Feb., 23:34, ·····················@gmail.com wrote:
> CL-USER> (defparameter x '(5))
> X
> CL-USER> (defparameter y x)
> Y
> CL-USER> (setf (first x) 3)
> 3
> CL-USER> y
> (3)
You should never change a literal list like '(5) destructively like
this! The consequences are undefined. Your example should be:
(defparameter x (list 5))
(defparameter y x)
(setf (first x) 3)
ciao,
Jochen
·····················@gmail.com schrieb:
> On Feb 21, 10:12 am, ··············@googlemail.com"
> <·············@googlemail.com> wrote:
>> Hello,
>>
>> I'm rather new to lisp and I was wondering, if is it possible to have
>> two different names for the same variable in common lisp? If yes, how
>> would I do something like that?I googled and tried to look it up in
>> the news group, but without any
>> luck. This is either to easy to be written down somewhere or I'm just
>> not
>> aware of the correct terminology to ask the right question. So I hope
>> you
>> might help!
> Well it depends what you're doing. By the time you come to be passing
> complex structures like lists, arrays or objects around they're passed
> by reference anyway so you get these capabilities for free. It's only
> if you're passing little things like numbers about that you have to
> work to get these capabilities.
> See below for an example.
> Chris
> CL-USER> (defparameter x 5)
> X
> CL-USER> (defparameter y x)
> Y
> CL-USER> (setf x 3)
> 3
> CL-USER> y
> 5
That was what we expected.
First you bind x and y to the same object and then, with your setf
you change the binding of x (to 3).
The same would happen with these "complex structurcs like lists":
CL-USER> (defvar x (list 1 2 3))
X
CL-USER> (defvar y x)
Y
CL-USER> x
(1 2 3)
CL-USER> y
(1 2 3)
CL-USER> (setf x (list 10 20 30))
(10 20 30)
CL-USER> x
(10 20 30)
CL-USER> y
(1 2 3)
> CL-USER> (defparameter x '(5))
> X
> CL-USER> (defparameter y x)
> Y
> CL-USER> (setf (first x) 3)
> 3
> CL-USER> y
> (3)
The implementors of your Lisp were nice. They allow you to do that at
the repl. But what you did here was changing the source code of your
program.. don't do that.
Better say (list 5) instead of '(5) here.
Andr�
--
On Thu, 22 Feb 2007 03:18:09 +0100, =?ISO-8859-1?Q?Andr=E9_Thieme?= <······························@justmail.de> said:
|| ...
|| CL-USER> (defparameter x '(5))
|| X
|| CL-USER> (defparameter y x)
|| Y
|| CL-USER> (setf (first x) 3)
|| 3
|| CL>USER| y
|| (3)
| The implementors of your Lisp were nice. They allow you to do that at
| the repl. But what you did here was changing the source code of your
| program.. don't do that.
| Better say (list 5) instead of '(5) here.
And then, with regards to the original poster's question, we do not
have "two names for the same variable here". What we have instead is
two variables, X and Y (as a strong matter of style, should have been
called *X* and *Y*), that are (currently) both bound to the same object
(a cons cell), but nothing constrains them to be always bound like
that.
As mentioned earlier, see symbol macros.
---Vassil.
--
Our programs do not have bugs; it is just that the users' expectations
differ from the way they are implemented.
> And then, with regards to the original poster's question, we do not
> have "two names for the same variable here". What we have instead is
> two variables, X and Y (as a strong matter of style, should have been
> called *X* and *Y*), that are (currently) both bound to the same object
> (a cons cell), but nothing constrains them to be always bound like
> that.
>
> As mentioned earlier, see symbol macros.
>
> ---Vassil.
>
Yes all this is true. But as the first post began, "I'm rather new to
lisp..." I worried that DEFINE-SYMBOL-MACRO was the right answer to
the wrong question.
C
> The implementors of your Lisp were nice. They allow you to do that at
> the repl. But what you did here was changing the source code of your
> program.. don't do that.
> Better say (list 5) instead of '(5) here.
>
> André
> --
I know what modification of literals does generally, but is it still
undefined if performed outside a loop at the REPL? The read and
evaluation occur directly after each other and no code is revisited.
There doesn't seem to be any room for ambiguity here.
However, my bad and I will try to conform to the ANSI standard while
posting to .lang.lisp in the future. ;)
C
On 22 Feb 2007 02:58:49 -0800, ·····················@gmail.com said:
| I know what modification of literals does generally, but is it still
| undefined if performed outside a loop at the REPL? The read and
| evaluation occur directly after each other and no code is revisited.
As soon as a form is evaluated, any literals in it may be placed in
read-only memory (perhaps as a side effect of compilation on the fly).
---Vassil.
--
Our programs do not have bugs; it is just that the users' expectations
differ from the way they are implemented.
Vassil Nikolov <···············@pobox.com> wrote:
+---------------
| ·····················@gmail.com said:
| | I know what modification of literals does generally, but is it still
| | undefined if performed outside a loop at the REPL? The read and
| | evaluation occur directly after each other and no code is revisited.
|
| As soon as a form is evaluated, any literals in it may be placed in
| read-only memory (perhaps as a side effect of compilation on the fly).
+---------------
A conservative reading of CLHS glossary item for "literal"
would suggest tightening that to say:
As soon as a form is READ any literals in it may be
placed in read-only memory...
since self-evaluating objects are also considered to be
"literal data", not just forms wrapped in QUOTE.
The "Description" section of "Special Operator QUOTE"
is consistent with this.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Thu, 22 Feb 2007 23:11:54 -0600, ····@rpw3.org (Rob Warnock) said:
| Vassil Nikolov <···············@pobox.com> wrote:
| +---------------
| | ...
| | As soon as a form is evaluated, any literals in it may be placed in
| | read-only memory (perhaps as a side effect of compilation on the fly).
| +---------------
| A conservative reading of CLHS glossary item for "literal"
| would suggest tightening that to say:
| As soon as a form is READ any literals in it may be
| placed in read-only memory...
Right. Thanks. ("Form" is of course a key word here, i.e. this
is about READ called from within the language processor (interpreter
or compiler), not about just any call to READ.)
---Vassil.
--
Our programs do not have bugs; it is just that the users' expectations
differ from the way they are implemented.
Vassil Nikolov <···············@pobox.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) said:
| | Vassil Nikolov <···············@pobox.com> wrote:
| | +---------------
| | | ...
| | | As soon as a form is evaluated, any literals in it may be placed in
| | | read-only memory (perhaps as a side effect of compilation on the fly).
| | +---------------
|
| | A conservative reading of CLHS glossary item for "literal"
| | would suggest tightening that to say:
|
| | As soon as a form is READ any literals in it may be
| | placed in read-only memory...
|
| Right. Thanks. ("Form" is of course a key word here, i.e. this
| is about READ called from within the language processor (interpreter
| or compiler), not about just any call to READ.)
+---------------
Well, some more wizardly CLHS maven(s) than I may chime in here,
but at this point I'm not sure the loophole you seem to be looking
for is actually there. READ reads characters from an input stream
(any input stream) and returns objects. If the characters that
it reads are of the syntax of "literal objects", then it seems
that the read-only rule applies there, too. I'm less certain
about any list structure that might be wrapped *around* such
literal objects, but my gut feeling is that it's legitimate for
an implementation to consider *all* objects returned by READ[1]
to be "literal objects", including list structure, since their
external representaions were literally present in the input stream.
-Rob
[1] Well, with the exception of objects explicitly constructed
by read-time evaluation. E.g., I'm of the opinion that the
object returned by #.(COPY-SEQ "abcde") should be mutable.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Sat, 24 Feb 2007 05:04:32 -0600, ····@rpw3.org (Rob Warnock) said:
| ...
| READ reads characters from an input stream
| (any input stream) and returns objects. If the characters that
| it reads are of the syntax of "literal objects", then it seems
| that the read-only rule applies there, too. I'm less certain
| about any list structure that might be wrapped *around* such
| literal objects, but my gut feeling is that it's legitimate for
| an implementation to consider *all* objects returned by READ[...]
| to be "literal objects", including list structure, since their
| external representaions were literally present in the input stream.
I argue that that does not apply to any input streams, but only
to input streams treated as source, i.e. being consumed by the
language processor (interpreter or compiler) for the purposes
of, ultimately, evaluation.
I know I should be quoting chapter and verse here; I'll try to
look it up later when I can.
(That said, as a matter of programming style, the closer to
immutability, the better, and, as it has been said many times
before, the fact that it is legal to modify an object does not
necessarily mean it is a good idea to plan to do so.)
---Vassil.
--
Our programs do not have bugs; it is just that the users' expectations
differ from the way they are implemented.
On Sat, 24 Feb 2007 05:04:32 -0600, ····@rpw3.org (Rob Warnock) said:
| ...
| READ reads characters from an input stream
| (any input stream) and returns objects. If the characters that
| it reads are of the syntax of "literal objects", then it seems
| that the read-only rule applies there, too. I'm less certain
| about any list structure that might be wrapped *around* such
| literal objects, but my gut feeling is that it's legitimate for
| an implementation to consider *all* objects returned by READ[...]
| to be "literal objects", including list structure, since their
| external representaions were literally present in the input stream.
So I looked it up.
In the HyperSpec, Section 3.7.1 [1] only speaks about destructive
modification of _literal_ objects, and those are found only in program
source [2]. (And on the other hand, READ is specified to build an
object, but not a literal object [3].)
[1] http://www.lisp.org/HyperSpec/Body/sec_3-7-1.html
[2] http://www.lisp.org/HyperSpec/Body/glo_l.html#literal
[3] http://www.lisp.org/HyperSpec/Body/fun_readcm_re_g-whitespace.html#read
---Vassil.
--
Our programs do not have bugs; it is just that the users' expectations
differ from the way they are implemented.
····@rpw3.org (Rob Warnock) writes:
> Vassil Nikolov <···············@pobox.com> wrote:
> +---------------
> | ····@rpw3.org (Rob Warnock) said:
> | | Vassil Nikolov <···············@pobox.com> wrote:
> | | +---------------
> | | | ...
> | | | As soon as a form is evaluated, any literals in it may be placed in
> | | | read-only memory (perhaps as a side effect of compilation on the fly).
> | | +---------------
> |
> | | A conservative reading of CLHS glossary item for "literal"
> | | would suggest tightening that to say:
> |
> | | As soon as a form is READ any literals in it may be
> | | placed in read-only memory...
> |
> | Right. Thanks. ("Form" is of course a key word here, i.e. this
> | is about READ called from within the language processor (interpreter
> | or compiler), not about just any call to READ.)
> +---------------
>
> Well, some more wizardly CLHS maven(s) than I may chime in here,
> but at this point I'm not sure the loophole you seem to be looking
> for is actually there.
I'm no kind of CLHS wizard, so I hope that Rob will not turn
me into a toad for daring to disagree. I think that "3.2.4
Literal Objects in Compiled Files" is the key page and
foregrounds the idea that COMPILE-FILE is different from
both EVAL and COMPILE because the compiled file may be
loaded into a different image from the one that read the
source file.
I take 3.2.4 Literal Objects in Compiled Files as
legitimizing this kind of shenanigan:
Make a couple of lists, conincidently the same
CL-USER> (defvar *change* (list 1 2 3))
*CHANGE*
CL-USER> (defvar *fixed* (list 1 2 3))
*FIXED*
Build a form
CL-USER> (defparameter *form*
(sublis (list (cons 'change *change*)
(cons 'fixed *fixed*))
`(let ((x 'change)
(y 'fixed))
(incf (second x) 10)
x)))
I cannot use backquote because 2.4.6 permits the
implementation of backquote to produce anything that is
EQUAL to what you hoped for, but I want my form to share
structure.
(list *change* *fixed* *form*) =>
(#1=(1 2 3)
#2=(1 2 3)
(LET ((X '#1#) (Y '#2#)) (INCF (SECOND X) 10) X))
(defparameter *result* (eval *form*)) => *RESULT*
(#1=(1 12 3)
#2=(1 2 3)
(LET ((X '#1#) (Y '#2#))
(INCF (SECOND X) 10)
X))
I think this wild and dangerous escapade is conforming :-)
I think that I am guaranteed that the *change* list is
changed because 3.2.4 requires
The functions eval and compile are required to ensure
that literal objects referenced within the resulting
interpreted or compiled code objects are the same as the
corresponding objects in the source code
I think that I am guaranteed that the *fixed* list is
unchanged because 3.2.4 requires
eval and compile do not copy or coalesce constants.
I feel that this discloses a broader vision of how it is all
supposed to fit together. You rather hope that the file
compiler will coalesce constants. It would be rather
disappointing if you had to coalesce them manually with lots
of #= in the source files. The price for this is that
changing a constant is no longer reasonable, you have no way
of knowing what structures are being shared. So the CLHS
prohibits this worthless option, allowing the implementor to
make the garabage collector run faster (no need to walk
constants, they cannot be pointing to anything freshly consed).
> READ reads characters from an input stream
READ must be a red-herring because the controversial bits of
my form where freshly consed by LIST and SUBLIS. Also READ
is used for data S-expressions. It doesn't know wether the
list (quote a) object it builds when it reads "'a" is code or
data. Indeed I've been notating context free grammars like
this
(a b 'c)
(a 'd)
(b 'b a)
distinguishing terminals from non-terminals with quote
to benefit from the predefined macro character. I would be
shocked if READ was doing more than building a data
structure and was actually marking some of it as immutable.
On the other hand 3.1.2.1.3 Self-Evaluating Objects is
explicit
The consequences are undefined if literal objects
(including self-evaluating objects) are destructively
modified.
and this is repeated in the page for QUOTE, so I think I am
going to be turned into a toad.
My final qestion, before I croak, is why does 3.2.4 place
requirements on eval and compile that make them different
from compile-file? What was the point?
Alan Crowe
Edinburgh
Scotland