Newbie question
Tomek
.............
inside of some function
............
(setf x '0)
(inc x)
(print x) ====>> 0 ( still 0 )
............
Inc is defined :
(defun inc (x)
(setf x (+ x 1))
)
My question is how( or is it possible in CLisp) to pass a variable by
reference (so that it could be changed inside function's body) --
similarly to pointers in C or a reference in C++
Regards
-Tom
Barry Margolin
Lisp doesn't have pointers or passing by reference. You can pass closures
that will do what you want:
(defun inc (getter setter)
(funcall setter (+ (funcall getter) 1)))
(inc (lambda () x)
(lambda (new-val) (setf x new-val)))
However, the more common way to implement what you want is with a macro:
(defmacro inc (var)
`(set1 ,var (+ ,var 1)))
BTW, Common Lisp already has this built-in, it's called INCF.
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Marco Antoniotti
Tomek <sav...@poczta.fm> writes:
Pointers (C), references (C++), var parameter (Pascal), out parameters
(AdaXX) are there solely because you do not have multiple valued
functions. :)
Sorry if the above is cryptic. :)
I.e. you do not need them in Common Lisp because you can return more
than one value from a function. Hence they are not there.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Geoff Summerhayes
"Barry Margolin" <bar...@genuity.net> wrote in message news:l2qw6.156$U4.6852@burlma1-snr2...
>
> However, the more common way to implement what you want is with a macro:
>
> (defmacro inc (var)
> `(set1 ,var (+ ,var 1)))
>
> BTW, Common Lisp already has this built-in, it's called INCF.
>
I know I'm just a newbie, but it strikes me that this might be misinterpreted,
if I'm not mistaken INCF uses GET-SETF-METHOD and is a bit more complicated
than the INC example may lead someone to believe. Just a word of caution to
the OP.
Geoff
Barry Margolin
INCF does what the original poster wants and more. I just didn't want to
complicate my simple macro with all the details needed to handle the
general cases; it would completely overwhelm the newbie.
Kent M Pitman
> However, the more common way to implement what you want is with a macro:
>
> (defmacro inc (var)
> `(set1 ,var (+ ,var 1)))
>
> BTW, Common Lisp already has this built-in, it's called INCF.
And, of course, it uses SETQ, not SET1. I'm sure just a typo on
Barmar's part but didn't want anyone to get confused.
Geoffrey Summerhayes
>
> INCF does what the original poster wants and more. I just didn't want to
> complicate my simple macro with all the details needed to handle the
> general cases; it would completely overwhelm the newbie.
>
I understand and agree with the motives, I just wanted to let them know
that it is a simplification.
Geoff
Roger Corman
This is not generally considered the best programming style, but
certainly can work for you. Just use a cons as the variable value.
(defun inc (x)
(setf (car x) (+ (car x) 1))
(setf x '(0))
(inc x)
(print x) --> (1)
Java has a common idiom of using an array of a single element for this
type of use. I think this is basically the same approach, in lisp, but
using a cons rather than an array (an array would work in lisp as
well).
Obviously this doesn't change what the variable refers to, but it does
change the contents of the thing it refers to, and that usually
satisfies what you need (in my experience).
Usually a macro will give you a more elegant solution, but with added
complexity.
Roger Corman
Vladimir V. Zolotych
>
> (defun inc (getter setter)
> (funcall setter (+ (funcall getter) 1)))
>
> (inc (lambda () x)
> (lambda (new-val) (setf x new-val)))
Thanks for interesting example.
--
Vladimir Zolotych gsm...@eurocom.od.ua
Daniel E. Wilson
> Here is a piece of my code :
>
> ..............
> inside of some function
> .............
>
> (setf x '0)
>
> (inc x)
>
> (print x) ====>> 0 ( still 0 )
>
> .............
>
> Inc is defined :
>
> (defun inc (x)
> (setf x (+ x 1))
> )
>
> My question is how( or is it possible in CLisp) to pass a variable by
> reference (so that it could be changed inside function's body) --
> similarly to pointers in C or a reference in C++
You have two possibilities to make this work. If you
want the function form then use the set function. Like
this:
(defun inc (x)
(set x (+ (symbol-value x) 1)))
The other possibility is:
(defmacro inc (x)
`(setf ,x (+ ,x 1)))
You are better off using the incf macro.
--
Daniel E. Wilson <chr...@teleport.com>
The perversity of the Universe tends towards a maximum.
-- Larry Niven
Janis Dzerins
> (defun inc (x)
> (setf (car x) (+ (car x) 1))
>
> (setf x '(0))
You advise to modyfy a constant list, don't you? (Just a remark for newbie.)
> (inc x)
> (print x) --> (1)
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
Barry Margolin
Daniel E. Wilson <chr...@teleport.com> wrote:
>You have two possibilities to make this work. If you
>want the function form then use the set function. Like
>this:
>(defun inc (x)
>(set x (+ (symbol-value x) 1)))
Warning: the above only works for special variables.
Kent M Pitman
>
> In article <3AC2F522...@teleport.com>,
> Daniel E. Wilson <chr...@teleport.com> wrote:
> >You have two possibilities to make this work. If you
> >want the function form then use the set function. Like
> >this:
> >(defun inc (x)
> >(set x (+ (symbol-value x) 1)))
>
> Warning: the above only works for special variables.
And not ones named X. :-)
Well, depending on whether you've proclaimed X special, which hopefully
you have not.
Btw, as a style point, I recommend using SETF of SYMBOL-VALUE here, not SET.
I'm not sure if there's ever a reason to use SET, maybe with MAPC or
some other higher order function, but certainly if you're pulling out the
value with SYMBOL-VALUE it is stylistically more perspicuous to stuff the
value back by the same means.
Roger Corman
>ro...@corman.net (Roger Corman) writes:
>
>> (defun inc (x)
>> (setf (car x) (+ (car x) 1))
>>
>> (setf x '(0))
>
>You advise to modyfy a constant list, don't you? (Just a remark for newbie.)
>
>> (inc x)
>> (print x) --> (1)
>
>--
You're right, I should have not used a constant list, since this is
not entirely portable.
Please change the example to
(setf x (list 0))
-or-
(setf x `(0))
Kent M Pitman
Uh, this last one is the same as '(0) in most implementations, and is also
not "safe". In the *very* early days of backquote, back in Maclisp times,
there was a competing version of backquote which guaranteed to copy structure
when you did backquote, but it didn't survive. It was too important to most
users to get sharing where possible, so backquote gets rewritten to forward
quote (effectively) except where commafication (if that's a word) is going on.
Barry Margolin
Kent M Pitman <pit...@world.std.com> wrote:
>> (setf x `(0))
>
>Uh, this last one is the same as '(0) in most implementations, and is also
>not "safe". In the *very* early days of backquote, back in Maclisp times,
>there was a competing version of backquote which guaranteed to copy structure
>when you did backquote, but it didn't survive. It was too important to most
>users to get sharing where possible, so backquote gets rewritten to forward
>quote (effectively) except where commafication (if that's a word) is going on.
I wonder what most versions of backquote would do with:
`(,0)
In the case of `(,<non-constant-expression>) it would have to translate to
(list <non-constant-expression>). Do any backquote implementations check
the expression after a comma to see if it's a literal so they can optimize
away the runtime consing?
I'm not saying it would be a good idea to depend on this, I'm just curious.
Kent M Pitman
>
> In article <sfwk858...@world.std.com>,
> Kent M Pitman <pit...@world.std.com> wrote:
> >> (setf x `(0))
> >
> >Uh, this last one is the same as '(0) in most implementations, and is also
> >not "safe". In the *very* early days of backquote, back in Maclisp times,
> >there was a competing version of backquote which guaranteed to copy structure
> >when you did backquote, but it didn't survive. It was too important to most
> >users to get sharing where possible, so backquote gets rewritten to forward
> >quote (effectively) except where commafication (if that's a word) is going on.
>
> I wonder what most versions of backquote would do with:
>
> `(,0)
>
> In the case of `(,<non-constant-expression>) it would have to translate to
> (list <non-constant-expression>). Do any backquote implementations check
> the expression after a comma to see if it's a literal so they can optimize
> away the runtime consing?
>
> I'm not saying it would be a good idea to depend on this, I'm just curious.
LispWorks 4.1.20 ...
CL-USER 1 > (read)`(0)
(QUOTE (0))
CL-USER 2 > (read)`(,0)
(QUOTE (0))
CL-USER 3 > (read)`(,t))
(QUOTE (T))
CL-USER 4 > (read)`(,x)
(SYSTEM::BQ-LIST X)
Daniel E. Wilson
You are correct. I was still thinking EMACS Lisp from some
code I wrote a few minutes before I wrote this.
Sometimes I wish that EMACS would be rewritten in Common Lisp
or Scheme but the code base is too large for that.
Kent M Pitman
> Sometimes I wish that EMACS would be rewritten in Common Lisp
> or Scheme but the code base is too large for that.
I seriously doubt that's the reason.
I don't know how big the Emacs code base is. I long ago rewrote Macsyma
(100,000 lines) from a dialect pretty similar to emacs-lisp into Common Lisp
and the process took about 3 months for me alone.
The Emacs community may be large, but that means there'd be good parallism
after someone converted a workable common core.
What's missing is simply the will.
Stallman has in the past said he very much dislikes CL's lexically
scoped nature, and that the decision of emacs-lisp to stay with
Maclisp-style dynamic scoping is not accidental. Whether his opinion
matters, of course, is an interesting question.
Friedrich Dominicus
>
> What's missing is simply the will.
Maybe it's the money? If someone is interested and willing to pay for
that, he might stand up now and ask for it. We'll see how many answers
we get on this request ;-)
Here's my estimate for that to happen.
0.001
So is it the will or is it the money ;-)
Regards
Friedrich
Kent M Pitman
> Kent M Pitman <pit...@world.std.com> writes:
>
> >
> > What's missing is simply the will.
>
> Maybe it's the money? If someone is interested and willing to pay for
> that, he might stand up now and ask for it. We'll see how many answers
> we get on this request ;-)
I thought money was never an issue in free software. ;-)
Tim Bradshaw
> I don't know how big the Emacs code base is. I long ago rewrote Macsyma
> (100,000 lines) from a dialect pretty similar to emacs-lisp into Common Lisp
> and the process took about 3 months for me alone.
I thould think it's at least a million lines - the (somewhat old)
version of xemacs I'm using now has nearly 600,000 in the
distribution.
Further, comverting the code to CL is about a tenth of the problem -
writing the google emacs primitives and odd semantics (buffer-local
variables &c).
Not that it's undoable, but it's a fair bit of work.
--tim
Marco Antoniotti
"Daniel E. Wilson" <chr...@teleport.com> writes:
> Sometimes I wish that EMACS would be rewritten in Common Lisp
> or Scheme but the code base is too large for that.
In principle you could rewrite Emacs in CL, but you are lacking way
too many things in Scheme to make that possible.
Friedrich Dominicus
> "Daniel E. Wilson" <chr...@teleport.com> writes:
>
> > Sometimes I wish that EMACS would be rewritten in Common Lisp
> > or Scheme but the code base is too large for that.
>
> In principle you could rewrite Emacs in CL, but you are lacking way
> too many things in Scheme to make that possible.
It depends on the Scheme one uses. I'm quite sure that Schemes are out
there which are as complete as Common Lisp is.
Regards
Friedrich
Friedrich Dominicus
> Friedrich Dominicus <fr...@q-software-solutions.com> writes:
>
> > Kent M Pitman <pit...@world.std.com> writes:
> >
> > >
> > > What's missing is simply the will.
> >
> > Maybe it's the money? If someone is interested and willing to pay for
> > that, he might stand up now and ask for it. We'll see how many answers
> > we get on this request ;-)
>
> I thought money was never an issue in free software. ;-)
Really. Who can afford to contribute to free software and from whom
is most of the free software? I guess RMS is still paid by the FSF, so one can
easily imagine that is a no-issue at least for him. And how many
others are there which get paid by some governement? Of course
if you have cash cows as SUN, IBM, Microsoft it should be easy to pay
even a hundred developers just to be sure one is mentioned if someone
is talking about free software.
How many can afford it anyway? Seems to be an open question ...
If it's a non-issue, now than it should be easy for those to say, hey
we want it, who wants to implement it. Anyway I do not have seen any
such request here since I read this newgroup. So it seems to be a real
issue. Or a non-issue that no-one cares but Common Lisp lovers ...
Regards
Friedrich
Marco Antoniotti
Friedrich Dominicus <fr...@q-software-solutions.com> writes:
Let's be precise. You mean: there are Schemes implementations
(incompatible) out there that re-implement incompatibly and at a great
expense of energy almost all that has been there in CL since 1984.
Trolling away....
Friedrich Dominicus
> Let's be precise. You mean: there are Schemes implementations
> (incompatible) out there that re-implement incompatibly and at a great
> expense of energy almost all that has been there in CL since 1984.
So what? You said too many things a missing in Scheme and I pointed
out to Scheme implementation in which this is not true. So you are
righ in a way that "core" Scheme is not "serious" enough. Anyway
nothing keeps anyone away from using a Scheme which have their extensions.
>
> Trolling away....
Sometimes I have the impression you Common Lips guy a like
lemmings. If someone is saying something in favour of Scheme and/or
Scheme implementations he gets such comments.
To make you feel a bit better: I would choose Common Lisp, anyway I
could live with a full-fledged incompatible Scheme
implementation. Could you?
Regards
Friedrich
Marco Antoniotti
Friedrich Dominicus <fr...@q-software-solutions.com> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Let's be precise. You mean: there are Schemes implementations
> > (incompatible) out there that re-implement incompatibly and at a great
> > expense of energy almost all that has been there in CL since 1984.
> So what? You said too many things a missing in Scheme and I pointed
> out to Scheme implementation in which this is not true. So you are
> righ in a way that "core" Scheme is not "serious" enough. Anyway
> nothing keeps anyone away from using a Scheme which have their
> extensions.
Of course not. People use C/C++ and Python.
> > Trolling away....
> Sometimes I have the impression you Common Lips guy a like
> lemmings. If someone is saying something in favour of Scheme and/or
> Scheme implementations he gets such comments.
It's in my genes. :)
> To make you feel a bit better: I would choose Common Lisp, anyway I
> could live with a full-fledged incompatible Scheme
> implementation. Could you?
I don't know. I have a full fledged CL environment on my Linux box
and on my PC box. Why should I use a full fledged Scheme instead?
Happily Trolling Away.....
Bijan Parsia
[snip]
> Stallman has in the past said he very much dislikes CL's lexically
> scoped nature, and that the decision of emacs-lisp to stay with
> Maclisp-style dynamic scoping is not accidental. Whether his opinion
> matters, of course, is an interesting question.
Whether that opinion has changed seems to matter a bit. Given that Guile
(a Scheme) is his choice for an ELisp successor, I presume that lexical
scope *per se* is no longer a killer objection for him.
Cheers,
Bijan Parsia.
Roger Corman
wrote:
>ro...@corman.net (Roger Corman) writes:
>
>> On 29 Mar 2001 13:17:40 +0200, Janis Dzerins <jo...@latnet.lv> wrote:
>>
>> >ro...@corman.net (Roger Corman) writes:
>> >
>> >> (defun inc (x)
>> >> (setf (car x) (+ (car x) 1))
>> >>
>> >> (setf x '(0))
>> >
>> >You advise to modyfy a constant list, don't you? (Just a remark for newbie.)
>> >
>> >> (inc x)
>> >> (print x) --> (1)
>> >
>> >--
>>
>> You're right, I should have not used a constant list, since this is
>> not entirely portable.
>>
>> Please change the example to
>> (setf x (list 0))
>>
>> -or-
>>
>> (setf x `(0))
>
>Uh, this last one is the same as '(0) in most implementations, and is also
>not "safe". In the *very* early days of backquote, back in Maclisp times,
>there was a competing version of backquote which guaranteed to copy structure
>when you did backquote, but it didn't survive. It was too important to most
>users to get sharing where possible, so backquote gets rewritten to forward
>quote (effectively) except where commafication (if that's a word) is going on.
Can you explain to me what is not safe about modifying a quoted or
backquoted list? I have heard that this is not a good thing to do, but
I am a bit fuzzy as to why. Obviously if it is shared this makes
sense. However, in this simple example it is not shared, and unless
multiple occurrences get coalesced somehow I don't see how there would
be a problem.
Are there some common lisp systems for which
(eq `(0) `(0)) -> true ?
Are there any common lisp systems which complain if you modify a
backquote-produced list?
Obviously, you don't want to do this:
(defun make-reference-var () `(0))
because that quoted reference is then shared all over.
TIA,
Roger
Barry Margolin
>scoped nature, and that the decision of emacs-lisp to stay with
>Maclisp-style dynamic scoping is not accidental.
I'm not sure how true this is now. Didn't he decide to use Scheme-based
Guile as the extension scripting language for new projects?
Barry Margolin
Roger Corman <ro...@corman.net> wrote:
>Can you explain to me what is not safe about modifying a quoted or
>backquoted list? I have heard that this is not a good thing to do, but
>I am a bit fuzzy as to why. Obviously if it is shared this makes
>sense. However, in this simple example it is not shared, and unless
>multiple occurrences get coalesced somehow I don't see how there would
>be a problem.
Even if it's not shared, the implementation is permitted to allocate it in
read-only memory. This won't usually be done if you type the expression in
the REPL, but the compiler or image dumper may relocate constants to pure
pages.
>Are there some common lisp systems for which
>
>(eq `(0) `(0)) -> true ?
I think so. Compilers are allowed to coalesce similar constants. See
Section 3.2.4.4 Additional Contraints on Externalizable Object in the
HyperSpec.
>Are there any common lisp systems which complain if you modify a
>backquote-produced list?
You could get "Segmentation violation (core dumped)" if you try to modify a
read-only page. Or it might simply ignore the attempted modification.
Marco Antoniotti
Barry Margolin <bar...@genuity.net> writes:
> In article <sfwsnjv...@world.std.com>,
> Kent M Pitman <pit...@world.std.com> wrote:
> >Stallman has in the past said he very much dislikes CL's lexically
> >scoped nature, and that the decision of emacs-lisp to stay with
> >Maclisp-style dynamic scoping is not accidental.
>
> I'm not sure how true this is now. Didn't he decide to use Scheme-based
> Guile as the extension scripting language for new projects?
Yes. And that was a misguided decision on his part.
Cheers
Daniel Barlow
> Whether that opinion has changed seems to matter a bit. Given that Guile
> (a Scheme) is [rms's] choice for an ELisp successor, I presume that lexical
> scope *per se* is no longer a killer objection for him.
In AI Memo 519a, an HTMLized version of which you can find at
http://chemeng.iisc.ernet.in/mohan/html/rms-emacs-paper.html#SEC17
(probably not the only place that paper's on the web, but the first
match I found in Google) he says
"It is not necessary for dynamic scope to be the only scope rule
provided, just useful for it to be available."
... which I think is a fairly uncontroversial point. That was in 1981
So I've never asked him personally and the original poster may well
have heard him expound more forcefully on dynamic scope before or
since, but I don't think all the evidence points entirely to a crusader
against lexical scoping
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
cbbr...@hex.net
> Barry Margolin <bar...@genuity.net> writes:
>> In article <sfwsnjv...@world.std.com>,
>> Kent M Pitman <pit...@world.std.com> wrote:
>>>Stallman has in the past said he very much dislikes CL's lexically
>>>scoped nature, and that the decision of emacs-lisp to stay with
>>>Maclisp-style dynamic scoping is not accidental.
>> I'm not sure how true this is now. Didn't he decide to use
>> Scheme-based Guile as the extension scripting language for new
>> projects?
> Yes. And that was a misguided decision on his part.
If the "evil" of CL was the the matter of lexical scoping, then
choosing Scheme, which is lexically scoped, and which I _think_ was
responsible for the introduction of lexical scoping to CL, would be a
vastly more ludicrously stupid idea than I can imagine RMS picking.
But I digress...
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://vip.hex.net/~cbbrowne/resume.html
"You can only examine 10 levels of pushdown, because that's all the fingers
you have to stick in the listing."
-- Anonymous programmer - "TOPS-10 Crash Analysis Guide"
Tim Moore
> If the "evil" of CL was the the matter of lexical scoping, then
> choosing Scheme, which is lexically scoped, and which I _think_ was
> responsible for the introduction of lexical scoping to CL, would be a
> vastly more ludicrously stupid idea than I can imagine RMS picking.
I always had the impression that RMS' distaste for Common Lisp had more to
do with its association with Symbolics and its employees than problems
with the language per se. Though, flames from the Lucid Emacs vs. Emacs
19 wars indicate that he disliked the new data types (characters, structs)
and perferred an older style (integers, alists).
Tim
Kent M Pitman
> In article <3ac4e0c3...@news.callatg.com>,
> Roger Corman <ro...@corman.net> wrote:
> >Can you explain to me what is not safe about modifying a quoted or
> >backquoted list? I have heard that this is not a good thing to do, but
> >I am a bit fuzzy as to why. Obviously if it is shared this makes
> >sense. However, in this simple example it is not shared,
No, this is false.
> >and unless
> >multiple occurrences get coalesced somehow I don't see how there would
> >be a problem.
>
> Even if it's not shared, the implementation is permitted to allocate it in
> read-only memory. This won't usually be done if you type the expression in
> the REPL, but the compiler or image dumper may relocate constants to pure
> pages.
This and other points Barry makes are certainly true but are not the extent
of the danger.
What is potentially shared under the langauge definition is more
sweeping than most people are aware. Consider that some important system
function might also have a copy of '(0) and that this might NOT be allocated
in a read-only area but merely in a "shared constants" area. That is, the
read-only-ness is not required to be enforced as a condition of coalescing.
Consequently, doing (setf (car '(0)) 1) might change the car of EVERY quoted
list equal to (0) that has ever been seen by the implementation.
Now, you might think that interactively in the interpreter, this isn't going
to happen, but in some implementations, e.g., MCL, typing some expression
X to the interpreter is the same as typing
(funcall (compile nil `(lambda () ,X)))
in most other implementations. What MCL's policy on coalescing is something
I know, but really doesn't matter; there is a set of possible compilers
like MCL that have various policies granted by the standard.
In some of them, as Barry notes, the coalesced constants will be enforced
read-only space. In those, you'll get a segmentation violation or pure page
trap or read-only page violation some such error. But just because you don't
doesn't mean you're home free. Having the assignment succeed might secretly
mean there was a change to something else somewhere. Indeed, the list
'(1 0) in some other program might have been modifed to be '(1 1).
Kent M Pitman
> In article <sfwsnjv...@world.std.com>,
> Kent M Pitman <pit...@world.std.com> wrote:
> >Stallman has in the past said he very much dislikes CL's lexically
> >scoped nature, and that the decision of emacs-lisp to stay with
> >Maclisp-style dynamic scoping is not accidental.
>
> I'm not sure how true this is now. Didn't he decide to use Scheme-based
> Guile as the extension scripting language for new projects?
When I was around MIT more, I used to run into this issue more directly
on a regular basis but the last time I spoke with him personally on this
issue was when I hosted a Lisp Users and Vendors conference and invited
him as a guest speaker. My recollection is that at that time, people were
pushing to make various Lispy dialects CL compliant, and he didn't want that
for emacs-lisp. I think it's a logicaly separate point whether there's a
different langauge he might port, too, though; so I wouldn't regard it as an
inconsistent point if he's both willing to think about scheme and still
insistent that emacs-lisp should be more dynamic.
Kent M Pitman
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
> > Barry Margolin <bar...@genuity.net> writes:
> >> In article <sfwsnjv...@world.std.com>,
> >> Kent M Pitman <pit...@world.std.com> wrote:
> >>>Stallman has in the past said he very much dislikes CL's lexically
> >>>scoped nature, and that the decision of emacs-lisp to stay with
> >>>Maclisp-style dynamic scoping is not accidental.
>
> >> I'm not sure how true this is now. Didn't he decide to use
> >> Scheme-based Guile as the extension scripting language for new
> >> projects?
>
> > Yes. And that was a misguided decision on his part.
>
> If the "evil" of CL was the the matter of lexical scoping, then
> choosing Scheme, which is lexically scoped, and which I _think_ was
> responsible for the introduction of lexical scoping to CL, would be a
> vastly more ludicrously stupid idea than I can imagine RMS picking.
>
> But I digress...
I've heard Stallman express distaste for various linguistic positions,
but my personal impression is that the notion of "evil" is something
he's reserved for sociological phenomena such as licensing issues.
I'm the last person to speak for him, since he and I disagree hugely
on a great many philosophical points, but my impression based on my
own first-hand interactions with him over the years, absent someone
with better first-hand interactions on a more regular basis, is that
he'd give priority to the question of whether Scheme had the right
license, appropriate volunteer manpower, etc. over issues of scoping.
If he could achieve a point for free software by proceeding in this way,
I don't think he'd stand on ceremony about a small language detail.
Just my intuition though. I'm hardly his spokesman.
Friedrich Dominicus
>
> Of course not. People use C/C++ and Python.
And Perl ;-), but some still are quite happy with Scheme ;-)
>
> > > Trolling away....
> > Sometimes I have the impression you Common Lips guy a like
> > lemmings. If someone is saying something in favour of Scheme and/or
> > Scheme implementations he gets such comments.
>
> It's in my genes. :)
Gosh I did not know that it's in so many Common Lispers genes
;-). It's remarkable how many generations can probably know and adopt
to Common Lisp. It's just 10 or so years old. Must be Internet time ;-)
> I don't know. I have a full fledged CL environment on my Linux box
> and on my PC box. Why should I use a full fledged Scheme instead?
Me too and even a bit more
>
> Happily Trolling Away.....
Ok I'm going...
Regards
Friedrich
Daniel E. Wilson
> "Daniel E. Wilson" <chr...@teleport.com> writes:
>
>
>> Sometimes I wish that EMACS would be rewritten in Common Lisp
>> or Scheme but the code base is too large for that.
>
>
> I seriously doubt that's the reason.
>
> I don't know how big the Emacs code base is. I long ago rewrote Macsyma
> (100,000 lines) from a dialect pretty similar to emacs-lisp into Common Lisp
> and the process took about 3 months for me alone.
>
> The Emacs community may be large, but that means there'd be good parallism
> after someone converted a workable common core.
The hard part is modifying all of the C code that makes
up the Emacs Lisp interpreter. In fact the underlying
byte code interpreter would have to be changed.
Since I work full time and am trying to get a CS degree
I am not about to under take such a project. Too bad
the program is based on C++.
> What's missing is simply the will.
>
> Stallman has in the past said he very much dislikes CL's lexically
> scoped nature, and that the decision of emacs-lisp to stay with
> Maclisp-style dynamic scoping is not accidental. Whether his opinion
> matters, of course, is an interesting question.
I suspect it does.
I use dynamic scoping in my own code so little that having
to declare a variable to be special reminds me that
I am doing something unusual.
I like Emacs but the quirks of its Lisp can be trying at
times.
Tim Moore
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
> > > > Trolling away....
> > > Sometimes I have the impression you Common Lips guy a like
> > > lemmings. If someone is saying something in favour of Scheme and/or
> > > Scheme implementations he gets such comments.
> >
> > It's in my genes. :)
> Gosh I did not know that it's in so many Common Lispers genes
> ;-). It's remarkable how many generations can probably know and adopt
> to Common Lisp. It's just 10 or so years old. Must be Internet time ;-)
More like 20 years, with a direct lineage going back more than 40...
Tim
Roger Corman
wrote:
>Barry Margolin <bar...@genuity.net> writes:
Thanks for your answers, Kent and Barry, although a part of my
question "are there any common lisp systems for which (eq `(0) `(0))
is true?" is not really answered. Obviously one can postulate many
possible implementations. I cannot imagine creating an implementation
in which (setf (car `(0)) 1) could break system functions. This would
not exactly be, how do I say, in the nature of a lisp system...
(IMHO). From a pragmatic perspective, as a user of lisp systems, I am
more interested in what existing systems do than in what they are
allowed to do. By the same token, when implementing lisp systems, I am
highly interested in building a system that conforms to users
expectations, above and beyond meeting a standard. I have no doubt
that the above setf expression, if it broke an implementation, would
cause users to complain and send defect reports. Pointing to the
standard is not a reasonable response.
Then, given that I cannot initialize a modifiable tree with either
(setf *x* '(this (is (my initial) structure)))
or
(setf *x* `(this (is (my initial) structure)))
do I really have to use:
(setf *x* (list 'this (list 'is (list 'my 'initial) 'structure)))
which is difficult to read and easier to get wrong?
I thought backquote could be used for this type of thing, but now know
that to be wrong. I am not exactly a newbie either...
I guess an option would be:
(setf *x* (copy-tree '(this (is (my initial) structure))))
This seems to introduce some unnecessary overhead to accomodate a
coalescing feature that lisp implementations don't actually use. Not
just overhead in run time performance, but also in explaining to
newbies what copy-tree does and why it is necessary to use it in a
simple example.
Where in the standard is this explained? I looked in the hyperspec for
a while and couldn't find it (not sure which section to look under).
Thanks,
Roger
Michael Hudson
> Thanks for your answers, Kent and Barry, although a part of my
> question "are there any common lisp systems for which (eq `(0) `(0))
> is true?" is not really answered.
$ lisp
CMU Common Lisp 18c, running on atrus.jesus.cam.ac.uk
Send questions to cmucl...@cons.org. and bug reports to cmuc...@cons.org.
Loaded subsystems:
Python 1.0, target Intel x86
CLOS based on PCL version: September 16 92 PCL (f)
CLX X Library MIT R5.02
Hemlock 3.5
* (defun f () (eql `(0) `(0)))
F
* (compile 'f)
Compiling LAMBDA NIL:
Compiling Top-Level Form:
F
NIL
NIL
* (f)
T
So, "yes", if I understand what you're asking.
Cheers,
M.
--
In short, just business as usual in the wacky world of floating
point <wink>. -- Tim Peters, comp.lang.python
Kent M Pitman
> Thanks for your answers, Kent and Barry, although a part of my
> question "are there any common lisp systems for which (eq `(0) `(0))
> is true?" is not really answered.
Of course, even if the answer were "no" the answer the next day might
be "yes". What decision would you make based on a "no" answer that you
would make differently if the answer were "yes"??
If I were implementing a Lisp, I would probably make (eq '(0) '(0))
return true, and consequently (eq `(0) `(0)) likewise. It's hardly an
implausible situation.
> Obviously one can postulate many
> possible implementations. I cannot imagine creating an implementation
> in which (setf (car `(0)) 1) could break system functions.
Why? Can you imagine creating an implementation in which you ever
return a system-critical list to the user in order to avoid consing?
Must PATHNAME-DIRECTORY cons, for example? Surely SYMBOL-PLIST mustn't
cons. Why single out SETF of CAR and CDR?
> This would not exactly be, how do I say, in the nature of a lisp system...
Sure it would. There were a billion easily accessible things that the Lisp
Machine would give users. One quickly learned which ones not to rplacd.
> (IMHO). From a pragmatic perspective, as a user of lisp systems, I am
> more interested in what existing systems do than in what they are
> allowed to do.
But you can't even know what existing systems there are. Nor can you know
what systems will do in the future. For example, what if most systems don't
do this not out of fear of hurting the user but just not having noticed the
available optimization? And, of course, if you put the item in read-only
space, you're certainly not going to hurt the system--only the person who
tries to setf the list structure.
> By the same token, when implementing lisp systems, I am
> highly interested in building a system that conforms to users
> expectations, above and beyond meeting a standard. I have no doubt
> that the above setf expression, if it broke an implementation, would
> cause users to complain and send defect reports.
> Pointing to the standard is not a reasonable response.
WOW, that's an interesting point of view.
To me, the whole POINT of the standard to say what people should and
shouldn't depend on just exactly so one doesn't have to universally
quantify over existing implementations, only to find the world
different the next day. If a standard does not have this effect, there
is little point to a standard, or so it seems to me.
> Then, given that I cannot initialize a modifiable tree with either
> (setf *x* '(this (is (my initial) structure)))
> or
> (setf *x* `(this (is (my initial) structure)))
>
> do I really have to use:
> (setf *x* (list 'this (list 'is (list 'my 'initial) 'structure)))
Well, or use COPY-TREE (which is what I do in the very rare case this
ever comes up; it's been years since this happened to me). But yes.
> which is difficult to read and easier to get wrong?
COPY-TREE is hard to get wrong and more perspicuous because it effectively
declares your intent to modify.
> I thought backquote could be used for this type of thing, but now know
> that to be wrong. I am not exactly a newbie either...
(I knew that.)
> I guess an option would be:
> (setf *x* (copy-tree '(this (is (my initial) structure))))
Yep.
> This seems to introduce some unnecessary overhead to accomodate a
> coalescing feature that lisp implementations don't actually use.
Though an implementation that could prove the argument was "fresh"
could optimize out the copy.
> Not
> just overhead in run time performance, but also in explaining to
> newbies what copy-tree does and why it is necessary to use it in a
> simple example.
I disagree here. I think it's fine to just tell the newbie that lists
are ordinarily not to be modified but that when you're going to modify
one, you must request a private copy. That doesn't seem like
"overhead" to me; it seems like "good advice" and well within the scope
of proper work for proper gain.
> Where in the standard is this explained? I looked in the hyperspec for
> a while and couldn't find it (not sure which section to look under).
The discussion of coalescing?
3.2.4.2 (Similarity of Literal Objects)
3.2.4.2.2 (Definition of Similarity)
...
cons
Two conses, S and C, are similar if the car[2] of S is similar to the
car[2] of C, and the cdr[2] of S is similar to the cdr[2] of C.
3.2.4.4 (Additional Constraints on Externalizable Objects):
... With the exception of symbols and packages, any two literal objects
in code being processed by the file compiler may be coalesced if and only
if they are similar ...
[Note that in CLHS, a tex->html transcription problem (probably caused by
misbalanced bracketing in the tex source not caught by tex itself) causes
3.2.4.4 to get hidden as a child page of 3.2.4.2. Sorry 'bout that.]
The consequences of the design decisions are nowhere explained, I suspect.
That's left to vendors and book authors and user experimentation.
> Thanks,
> Roger
You're welcome.
Kellom{ki Pertti
> Sometimes I have the impression you Common Lips guy a like
> lemmings. If someone is saying something in favour of Scheme and/or
> Scheme implementations he gets such comments.
It is starting to look more like a simple conditioned response in the
best Pavlovian tradition.
--
Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
Tim Bradshaw
> Thanks for your answers, Kent and Barry, although a part of my
> question "are there any common lisp systems for which (eq `(0) `(0))
> is true?" is not really answered.
Yes. ACL with the optimizer cranked up I think (I had just this
problem a while ago). Duane can probably explain in more detail the
circumstances under which it can happen.
I've also just checked CMUCL and it is true there too.
--tim
Duane Rettig
> * Roger Corman wrote:
> > Thanks for your answers, Kent and Barry, although a part of my
> > question "are there any common lisp systems for which (eq `(0) `(0))
> > is true?" is not really answered.
>
> Yes. ACL with the optimizer cranked up I think (I had just this
> problem a while ago). Duane can probably explain in more detail the
> circumstances under which it can happen.
Whenever the compiler is building a constant "table" (a place where
constants not already in a global place are drawn from on a per function
basis, which in Allegro CL is space at the end of the function object
itself), it adds to this table based on some uniqueness algorithm.
In Allegro CL this uniqueness is determined (roughly) by EQUAL. There
are exceptions, but in normal compilations that are not load-time
evaluated they are merged in this way. You can see these constants by
disassembling the function.
The interpreter is another story; constants are not merged generally
because the lookup of constants in a global place would slow down an
already relatively slow process of interpretation. Some implementations
implement their interpreter with their compiler, and thus get the constant
merging as a part of that process.
I have kept quiet on this issue because I agree completely with Kent,
who is not arguing from an implementation point of view, but from a
spec and a portability pov instead. It wouldn't matter if _no_
implementation actually did merging of constants; the fact that the
standard makes it possible means that users should never change these
constants. If the rules of the spec are followed, then theoretically
your code will port to different CL implementations, whatever the vendor.
A quick story: As background: years ago, when we added a "pure" space
for strings and codevectors (currently called a .pll file) we found that
the SIGSEGV or SIGBUS error that occurred when you write into read-only
memory could be identified in some operating systems, and so we took
advantage of this in the interrupt handler and gave a simple-error of
to that effect when it recognized that the address you were trying to
store into was within the purespace range. So on some implementations,
if you place (setf (aref "CAR" 0) #\d) as the sole form in a file and
compile and load that, you will get
; Fast loading /tmp_mnt/net/beta/gamma/tech/duane/xxx.fasl
Error: Received signal number 11 (Segmentation violation)
[condition type: SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL]
[...]
whereas (for example) on Sparc you would get:
; Fast loading /tmp_mnt/beta/gamma/tech/duane/xxx.fasl
Error: Attempt to store into purespace address #xfa4edddc.
[condition type: SIMPLE-ERROR]
Well, all that setup to say that when we went to compile products other
than the base lisp we found several instances where a constant string
had been used as temporary storage. We had ourselve fallen prey to the
non-portability of constant modification. Having the lisp tell us what
we were doing wrong was useful, and presumably saved us from
hard-to-reproduce errors that could have remained hidden for years.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Roger Corman
>Tim Bradshaw <t...@cley.com> writes:
>
>> * Roger Corman wrote:
>> > Thanks for your answers, Kent and Barry, although a part of my
>> > question "are there any common lisp systems for which (eq `(0) `(0))
>> > is true?" is not really answered.
>>
>> Yes. ACL with the optimizer cranked up I think (I had just this
>> problem a while ago). Duane can probably explain in more detail the
>> circumstances under which it can happen.
>
>Whenever the compiler is building a constant "table" (a place where
>constants not already in a global place are drawn from on a per function
>basis, which in Allegro CL is space at the end of the function object
>itself), it adds to this table based on some uniqueness algorithm.
>In Allegro CL this uniqueness is determined (roughly) by EQUAL. There
>are exceptions, but in normal compilations that are not load-time
>evaluated they are merged in this way. You can see these constants by
>disassembling the function.
>
Thanks, all, for the information. I have a better understanding of
what a literal is than I used to.
As I now understand it:
Coalescing of literals is prohibited by the standard when EVAL or
COMPILE is used (CLHS 3.2.4).
Coalescing is optional when COMPILE-FILE is used, and some
implementations (such as ACL) currently will coalesce literals in some
circumstances.
Roger
Tim Bradshaw
> Yes. ACL with the optimizer cranked up I think (I had just this
> problem a while ago). Duane can probably explain in more detail the
> circumstances under which it can happen.
Just to be clear (reading my own article...) the problem was with my
code, not what ACL / CMUCL does, which is clearly legal behaviour.
--tim
Kent M Pitman
> As I now understand it:
> Coalescing of literals is prohibited by the standard when EVAL or
> COMPILE is used (CLHS 3.2.4).
Yes, this is because it's not "compiling" per se which is allowed to do this
but "externalization to a file" that is permitted to.
Rob Warnock
If this is really true [but see later], then CMUCL would appear to be
violating your reading of 3.2.4:
* (defun foo () (eq `(0) `(0)))
FOO
* (foo) ; interpreted
T
* (compile 'foo)
Compiling LAMBDA NIL:
Compiling Top-Level Form:
FOO
NIL
NIL
* (foo)
T
*
But does 3.2.4 really prohibit this? Other than the result of the EQ,
the two lists would not otherwise be observable as distinct "objects
in the source code" [since the bodies of even interpreted functions
are not required to be accessible], so we cannot say whether the objects
being passed to EQ *are* the "same" or not [without running the code].
If they are, then the result is permitted, yes?
Likewise, also because we're not allowed to look "inside" functions,
these should be permitted too, I'd say:
* (eval `((lambda () (eq ',`(0) ',`(0)))))
T
* (eval (list (list 'lambda nil (list 'eq '`(0) '`(0)))))
T
*
-Rob
p.s. Note that even though CMUCL *does* coalesce the values of *A*
and *B* below when file-compiled, it doesn't do so when the same is
typed to the REPL, which is kinda what one would expect:
(defvar *a* `(0))
(defvar *b* `(0))
(defun bar () (eq *a* *b*))
-----
Rob Warnock, 31-2-510 rp...@sgi.com
SGI Network Engineering <URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
Kent M Pitman
Well, the history on this is complicated by the later introduction of
LOAD-TIME-VALUE and then [I feel] a failure to go back and clean up the
implications. I think it's reasonable what CMU CL does notwithstanding
that it's possibly nonconforming because to do what I'm about to say
should use LOAD-TIME-VALUE for stylistic reasons, now that it exists.
But originally, the issue was that one wanted so sometimes get efficiency
by including mutable objects with a designated identity into quoted code.
e.g., the following contrived example shows
(defvar *temp-vectors* (make-hash-table))
(defun temp-vector-named (name)
(or (gethash name *temp-vectors*)
(setf (gethash name *temp-vectors*)
(make-array 100 :fill-pointer 0 :adjustable t))))
(defmacro temp-ref (name-form index-form)
(if (and (consp name-form) (eq (car name-form) 'quote))
;; optimize the case where we know the value
;; works ONLY with COMPILE but not with COMPILE-FILE because
;; otherwise the value will be looked up too soon (in compiler env).
`(aref ',(temp-vector-named (cadr name-form)) ,index-form)
`(aref (temp-vector-named ,name-form) ,index-form)))
Long ago, it used to be necessary to do some things like this under certain
limited situations. Nowadays, LOAD-TIME-VALUE will do this better because
it assures the code will work in either compiled or interpreted code, file
compiler or not.
>
> Likewise, also because we're not allowed to look "inside" functions,
I don't know what this is about.