reference parameter
Arseny Slobodjuck
I am a novice in Lisp, can somebody help me with such a question ?
I need a function, which will modify given parameter(s). In C++ i has
wrote : int func(int ¶m), can i do this in Lisp or "i still thinking
procedurally " ? I using xlisp 2.1.
Thank You.
Marco Antoniotti
"Arseny Slobodjuck" <am...@altavista.net> writes:
The typical use of reference parameters in Algol/C/Pascal languages is
to pass back a "value" in the location. In Common Lisp you use
multiple values to that effect. So, first read about multiple values
in some Common Lisp literature. Secondm be sure that Xlisp supports
multiple values; if not switch to a real Common Lisp.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Coby
"Arseny Slobodjuck" <am...@altavista.net> wrote:
> Hi, all !
>
> I am a novice in Lisp, can somebody help me with such a question ?
> I need a function, which will modify given parameter(s). In C++ i has
> wrote : int func(int ¶m), can i do this in Lisp or "i still
thinking
> procedurally " ? I using xlisp 2.1.
>
>
>
The first approach that comes to my mind (still relatively new to lisp)
would be along the lines of:
(defparameter args '(1 2 3))
>args => (1 2 3)
(defun func (arg-list)
(list (+ 1 (first arg-list))
(+ 2 (second arg-list))
(+ 3 (third arg-list))))
(setf args (func args))
>args =>(2 4 6)
But this is still not very "lispy". Try looking at things more as data
structures and less as lots of distinct variables?...
coby
Sent via Deja.com http://www.deja.com/
Before you buy.
Barry Margolin
Marco Antoniotti <mar...@copernico.parades.rm.cnr.it> wrote:
>
>"Arseny Slobodjuck" <am...@altavista.net> writes:
>
>> Hi, all !
>>
>> I am a novice in Lisp, can somebody help me with such a question ?
>> I need a function, which will modify given parameter(s). In C++ i has
>> wrote : int func(int ¶m), can i do this in Lisp or "i still thinking
>> procedurally " ? I using xlisp 2.1.
>>
>
>to pass back a "value" in the location. In Common Lisp you use
>multiple values to that effect. So, first read about multiple values
>in some Common Lisp literature. Secondm be sure that Xlisp supports
>multiple values; if not switch to a real Common Lisp.
And if this doesn't address your needs, the other alternative is to write a
macro, rather than a function. The macro can expand into a use of SETF or
SETQ, which will assign to the place provided in the invocation.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, 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.
Tim Bradshaw
> Hi, all !
> I am a novice in Lisp, can somebody help me with such a question ?
> I need a function, which will modify given parameter(s). In C++ i has
> wrote : int func(int ¶m), can i do this in Lisp or "i still thinking
> procedurally " ? I using xlisp 2.1.
All arguments in lisp are passed by value. If the object that you
pass is mutable (like a list, or an array, or something), then you can
modify it using the normal destructive operators. What you can't do
is the explicit-pointer-based hacks that languages like C and C++ let
you do.
My experience is that you don't actually miss this, but then I've not
really been a C person for a long time.
--tim
Erik Naggum
| I am a novice in Lisp, can somebody help me with such a question?
| I need a function, which will modify given parameter(s). In C++ i has
| wrote: int func(int ¶m), can i do this in Lisp or "i still thinking
| procedurally"? I using xlisp 2.1.
as with any "I have X in language L1, so I need X in language L2" request
you will succeed only at random in getting what you only think you want.
rather than this first-level approach to comparisons, try "I solve some
problem A with X in language L1 -- is A solved with X in L2, or some
other way?" you don't need to do the introspection part that actually
answers what A is, obviously, but you need to be aware of the different
level of the question you're asking just so you are able to appreciate
the answers you get that don't match with the first question.
references in C++ are used to return non-primary values from a function.
C++ needs this because it has no better mechanism of dealing with more
than one return value from a function. a reference is fundamentally a
mechanism used to send a lexical variable to an inferior function so that
it can be modified in a different lexical scope than binds it. now, this
has a number of interesting ramifications for control flow analysis and
program design in general, but C++ programmers aren't aware of these. in
less immature languages with the same desire, they have opted for naming
the variables "in", "in out", or "out" according as the direction of
their value flows across the function call boundary. this is obviously a
very useful thing to know about variable bindings that you give away for
others to mess with that C++ also completely lacks, unsurprisingly.
in Common Lisp, you can obtain this behavior with closures, but we need
to know whether the binding is going to be used for incoming, outgoing or
both.
(defun foo (in out in-out)
(... in ...) ;use value of IN
(funcall out ...) ;set value of OUT
(... (funcall in-out) ...) ;use value of IN-OUT
(funcall in-out ...)) ;set value of IN-OUT
as you can probably guess, there are good reasons why Common Lisp
programmers don't do this (but you might see Scheme aficionados argue
that it's a great idea in Scheme because they don't need the FUNCALL :).
instead, Common Lisp programmers approach the problem from the
perspective where _control_ over the binding remains confined to its
lexical scope, and it's none of the callee's business to know that a
particular variable is to be reused with a new value. so instead of
focusing on what FOO would do, let's look at what BAR, which calls FOO
would do, first in the above sense, and then in the normal Common Lisp
sense:
(defun bar ()
(let ((a b c))
(foo a
(lambda (new) (setf b new))
(lambda (&optional (new nil set-p)) (if set-p (setf c new) c)))))
this is clearly in need of some macrologic wrappers to make sense to work
with at all, but it's also inefficient (although it could be made fast),
so instead we have opted for a much simpler mental model of dealing with
such mutable bindings:
(defun bar ()
(let (a b c)
(setf (values b c)
(foo a c))))
FOO would now be defined simpler, too:
(defun foo (in in-out)
(... in ...) ;use value of IN
(... in-out ...) ;use value of IN-OUT
(values out in-out)) ;return values for OUT and IN-OUT
in the more common case, you have a much simpler way to specify which
bindings are to apply:
(defun bar ()
(multiple-value-bind (b c) (foo <value-of-a> <value-of-c>)
...))
and skip the variable thing altogether.
the morale of this story is that if it's a good idea in C++, it's very
likely to be a bad idea somewhere (if not everywhere) else, because they
have voluntarily decided against good design at the core language level,
and therefore have to solve problems by riveting on layer upon layer with
special features and magic that people think are The Solution, when in
fact C++ is only really good at creating new problems that confuse people
when they come to better-designed languages.
of course, once you realize what multiple values are and how C++ sucks,
you'll have a hard time working within the stultifying C++ environment
again, so if your goal is really to continue writing C++ programs, you
might want to stop working with Common Lisp right away... of course,
XLisp is not Common Lisp, so you might not have to give up C++ just yet.
#:Erik
William Deakin
> What you can't do is the explicit-pointer-based hacks that languages like C
> and C++ let you do.
>
> My experience is that you don't actually miss this, but then I've not really
> been a C person for a long time.
IMHO, this can save you from shooting yourself in the foot.
:) will
David Hanley
Arseny Slobodjuck wrote:
> Hi, all !
>
> I am a novice in Lisp, can somebody help me with such a question ?
> I need a function, which will modify given parameter(s). In C++ i has
> wrote : int func(int ¶m), can i do this in Lisp or "i still thinking
> procedurally " ? I using xlisp 2.1.
Instead of trying to tell you what you want to do, here is a way
to do what you want :
(defmacro setvars( x y z )
`(progn
(setf ,x (func1 ,z))
(setf ,y (func2 ,z))))
(defun func1(x)(* x 2))
(defun func2(x)(* x 4))
this should give you a skeleton to work with.
dave
Tim Bradshaw
> Instead of trying to tell you what you want to do, here is a way
> to do what you want :
> (defmacro setvars( x y z )
> `(progn
> (setf ,x (func1 ,z))
> (setf ,y (func2 ,z))))
> (defun func1(x)(* x 2))
> (defun func2(x)(* x 4))
Well, not actually a way to do what you *probably* want:
(setvars a b (incf c))
--tim
David Hanley
Tim Bradshaw wrote:
Well, he's a big boy and a C++ programmer, right? He can
ask again and get a gensym version, or make a temp variable.
I think one of the reasons perl has succeeded while lisp has
not is because perl gurus respond with "how do I" questions
with "here's how" instead of pontificating on what they consider
good programming practices. Yes, it leads to a lot of ugly
perl code, and it might be a bad thing in the long run, but check out
the number of libraries for this brand-new language.
dave
Erik Naggum
| I think one of the reasons perl has succeeded while lisp has not is
| because perl gurus respond with "how do I" questions with "here's how"
| instead of pontificating on what they consider good programming practices.
when trying to tell people about better ways is considered wrong and
teachers are castigated for their attempts to illuminate, you have a
world where stuff like Perl will succeed beyond your wildest dreams.
so you confuse cause and effect. Perl is a language _designed_ to have
"do this"-type answers to every question. the consequence is that there
is no good programming practice in Perl to pontificate about, and people
just learn to do in Perl whatever they already think is OK. (if it was
not doable that way, Perl was modified so it would be.) Perl is a cheap
whore of a language for equally indiscriminate people. some consider
this a very positive property and call it "popularity"; others don't.
personally, I would rather see pontifications about good programming
practice than bad, which is what Perl aficionados and defenders do.
#:Erik
Gareth Rees
> I think one of the reasons perl has succeeded while lisp has not is
> because perl gurus respond with "how do I" questions with "here's how"
> instead of pontificating on what they consider good programming
> practices.
I think this maligns "Perl gurus" unfairly. In fact, people on
comp.lang.perl.misc spend a lot of time trying to discover and solve
people's genuine problems rather than just answering their questions.
Consider for example Tom Christiansen's articles explaining why symbolic
references are a bad idea. This is something that might come up in
Lisp, too -- someone might say something like "I have the name of a
variable in a string, how do I get the value of the variable?". You
could answer them by telling them about INTERN and SYMBOL-VALUE but I
think that if you didn't explain why this is a bad idea (and what to do
instead) you would be doing them a grave disservice.
People need to learn things at a number of different levels -- not just
"how do I do what I want to do?" but "is what I want to do a good thing
to want?" and "how do I analyze my problem so as to find a good
solution?"
--
Gareth Rees
Howard R. Stearns
> ...
> I think one of the reasons perl has succeeded while lisp has
> not is because perl gurus respond with "how do I" questions
> with "here's how" instead of pontificating on what they consider
> perl code, and it might be a bad thing in the long run, but check out
> the number of libraries for this brand-new language.
It may not be the best idea to ASSUME that some language or another is
more successful due to the number of libraries for its code, books about
it, etc.
- Especially without real data with respect to these figures. -
For example, I've heard it claimed (without rigorous evidence), that
there are an order of magnitude more books about Lisp than Java and Perl
(combined?), and similarly for code repositories, scientific papers,
references in the literature, etc. Does that mean that Lisp is that
much more popular, widespread, important, relevent, etc.?
Before you ask, no I don't know if this included Scheme or other
dialects. The point is that such claims are made pretty lightly, and it
probably isn't even relevent to ask.
And if you feel that Lisp's 40 year history tips the scales, I leave it
to you as an engineer/scientist/manager or whatever, whether or not to
hold longevity against a technology.
David Hanley
Gareth Rees wrote:
> David Hanley <d...@ncgr.org> wrote:
> > I think one of the reasons perl has succeeded while lisp has not is
> > because perl gurus respond with "how do I" questions with "here's how"
> > instead of pontificating on what they consider good programming
> > practices.
>
> I think this maligns "Perl gurus" unfairly.
I am not maligning the perl gurus by a long shot.
> Consider for example Tom Christiansen's articles explaining why symbolic
> references are a bad idea. This is something that might come up in
> Lisp, too -- someone might say something like "I have the name of a
> variable in a string, how do I get the value of the variable?". You
> could answer them by telling them about INTERN and SYMBOL-VALUE but I
> think that if you didn't explain why this is a bad idea (and what to do
> instead) you would be doing them a grave disservice.
Maybe, maybe not. maybe this could be a one-line solution to a problem,
rather than perhaps hundreds of lines of rewrite. Programmers are happy
to receive simple solutions to their problems.
> People need to learn things at a number of different levels -- not just
> "how do I do what I want to do?" but "is what I want to do a good thing
> to want?"
If a person is requesting an education, this is more appropriate. If they
want to get somethign finished, it is not. Yes, intern and symbol-value
are not always the best idea. But if it allows someone to produce
working code, what right does someone else have to try to "correct"
them? There's also an implicit assumption that the "helper" knows more
about the problem than the one trying to solve it.
dave
David Hanley
"Howard R. Stearns" wrote:
> David Hanley wrote:
> > ...
> > I think one of the reasons perl has succeeded while lisp has
> > not is because perl gurus respond with "how do I" questions
> > with "here's how" instead of pontificating on what they consider
> > good programming practices. Yes, it leads to a lot of ugly
> > perl code, and it might be a bad thing in the long run, but check out
> > the number of libraries for this brand-new language.
>
> It may not be the best idea to ASSUME that some language or another is
> more successful due to the number of libraries for its code, books about
> it, etc.
> - Especially without real data with respect to these figures. -
>
> For example, I've heard it claimed (without rigorous evidence), that
> there are an order of magnitude more books about Lisp than Java and Perl
> (combined?),
I find this truly hard to beleive. In any case, if anyone thinks lisp
has more mindshare than either of these languages, well, I have
land to sell them. And if you feel that Lisp's 40 year history tips the
scales, I leave it
> to you as an engineer/scientist/manager or whatever, whether or not to
> hold longevity against a technology.
Thre's two ways to look at it. You can say that it's good that it's
gone forty years, or bad that it's gone forty years and never
gotten real marketshare. After fortran and cobol are really
old too; few argue that cobol is a wonderful language.
dave
Tim Bradshaw
> Maybe, maybe not. maybe this could be a one-line solution to a problem,
> rather than perhaps hundreds of lines of rewrite. Programmers are happy
> to receive simple solutions to their problems.
.. even if it hurts them and their customers *really* badly in the
long term. I think the point of how Lisp people behave is that we are
interested in *not* doing that. A good example of this is the macro
solution to call-by-reference which, even when fixed to not multiply
evaluate, will hurt you later when you try and funcall it or redefine
the funtion, and just generally be really fragile.
Unfortunately, the `immediate gratification with severe long-term
pain' approach resonates very well with human nature (look at smoking,
for God's sake!). We're fundamentally apes, and we really can't do
rationality unless we have the right training, and even then it is
very hard work. So really, Lisp people, who are trying to act
rationally, are just doomed to fail in a world where almost everyone
is doing gradient-descent.
To ruthlessly steal a quote: `Perl: a moment of convenience, a
lifetime of regret'.
--tim
Tim Bradshaw
> Thre's two ways to look at it. You can say that it's good that it's
> gone forty years, or bad that it's gone forty years and never
> gotten real marketshare. After fortran and cobol are really
> old too; few argue that cobol is a wonderful language.
And there's a *lot* of fortran and cobol code out there, I wouldn't be
surprised if there's more Cobol than perl, at least.
--tim
Rainer Joswig
> > For example, I've heard it claimed (without rigorous evidence), that
> > there are an order of magnitude more books about Lisp than Java and Perl
> > (combined?),
>
> I find this truly hard to beleive.
See this Lisp bibliography:
http://www8.informatik.uni-erlangen.de/html/lisp-enter.html
> > to you as an engineer/scientist/manager or whatever, whether or not to
> > hold longevity against a technology.
>
> Thre's two ways to look at it. You can say that it's good that it's
> gone forty years, or bad that it's gone forty years and never
> gotten real marketshare.
FUD
Pierre R. Mai
> * David Hanley wrote:
>
> > Thre's two ways to look at it. You can say that it's good that it's
> > gone forty years, or bad that it's gone forty years and never
> > gotten real marketshare. After fortran and cobol are really
> > old too; few argue that cobol is a wonderful language.
>
> And there's a *lot* of fortran and cobol code out there, I wouldn't be
> surprised if there's more Cobol than perl, at least.
I would be very surprised if there was more Perl code than either
Cobol or Fortran code out there.
--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Erik Naggum
| But if it allows someone to produce working code, what right does someone
| else have to try to "correct" them?
the same right they have to give false or misleading answers, answers
that work only most of the time, or no answer at all. you ask in a
public forum, you get whatever people feel like providing at the time,
and the rights involved are quite fundamental, so why do you consider
_this_ a question of "right"?
the "right" I think you favor is the "right" to remain wrong and ignorant
and to be protected from having it demonstrated to you. such is not a
right; it is a wrong.
| There's also an implicit assumption that the "helper" knows more about
| the problem than the one trying to solve it.
you're implying that when asking for and receiving Perl answers, this
assumption does not hold... :)
#;Erik
Christopher R. Barry
> Tim Bradshaw <t...@tfeb.org> writes:
>
> > * David Hanley wrote:
> >
> > > Thre's two ways to look at it. You can say that it's good that it's
> > > gone forty years, or bad that it's gone forty years and never
> > > gotten real marketshare. After fortran and cobol are really
> > > old too; few argue that cobol is a wonderful language.
> >
> > And there's a *lot* of fortran and cobol code out there, I wouldn't be
> > surprised if there's more Cobol than perl, at least.
>
> I would be very surprised if there was more Perl code than either
> Cobol or Fortran code out there.
A lot people buying $15M mainframes from IBM always talk about the
"unmatched stability" of Cobol. They have plenty of good things to say
about PL/I as well.
Christopher
Joe Keane
Erik Naggum <er...@naggum.no> writes:
> personally, I would rather see pontifications about good programming
> practice than bad, which is what Perl aficionados and defenders do.
You're just jealous.
--
Joe Keane, amateur mathematician
Erik Naggum
| personally, I would rather see pontifications about good programming
| practice than bad, which is what Perl aficionados and defenders do.
* Joe Keane
| You're just jealous.
I'm sorry I was unclear. I meant pontification about bad _programming_
_practices_, not just any random bad pontification. I hope this clears
up your confusion. now go away.
#:Erik
Coby
is
> > > because perl gurus respond with "how do I" questions with "here's
how"
> > > instead of pontificating on what they consider good programming
> > > practices.
> >
> > Consider for example Tom Christiansen's articles explaining why
symbolic
> > references are a bad idea. This is something that might come up in
> > Lisp, too -- someone might say something like "I have the name of a
> > variable in a string, how do I get the value of the variable?". You
> > could answer them by telling them about INTERN and SYMBOL-VALUE but
I
> > think that if you didn't explain why this is a bad idea (and what
to do
> > instead) you would be doing them a grave disservice.
>
> Maybe, maybe not. maybe this could be a one-line solution to a
problem,
> rather than perhaps hundreds of lines of rewrite. Programmers are
happy
> to receive simple solutions to their problems.
>
> > People need to learn things at a number of different levels -- not
just
> > "how do I do what I want to do?" but "is what I want to do a good
thing
> > to want?"
>
> If a person is requesting an education, this is more appropriate. If
they
> want to get somethign finished, it is not. Yes, intern and symbol-
value
> are not always the best idea. But if it allows someone to produce
> working code, what right does someone else have to try to "correct"
> them?
I believe it is beyond doubt that when a person asks a question in a
public forum, any one reading it has the right to answer it in any
manner of their choosing. People should be ready for whatever may come.
*However*, no right comes without responsibility, a principle of life
that, IMHO, north american pop-culture desperately needs to learn. (i
couldn't resist a brief pontification of my own here...sorry but it IS
my right :-)
It is our responsibility to refrain from purposely provoking hostility,
to refrain from making insulting or degrading remarks and refrain from
using offensive language. Aside from that *anything* goes! This
includes everything from "do this" answers to "you don't really want to
do that anyway" answers to "Well, I think <insert totally off-topic and
unsupported opinion>" answers.
As an asker of "How do I..?" kinds of questions myself, I can agree
with David Hanley that I am very happy to receive simple, straight
forward, "here's how" replies. And because, like most of us, I have an
immediate problem that needs a solution, I cut and paste and modify and
put it in. No harm.
But I am equally appreciative of the other kinds of answers, like "you
should have set it up this way" or "try thinking about it from another
angle" (less so the "only an idiot would want to do that in the first
place" answers :) The others i will sift through and absorb or ignore
as i see fit. That is my right as the reader.
Personal opinion:
i want to get the job done, but i also want to become a better lisper
and better problem solver in general.
Free advice: (and believe me it is worth the price :)
Give the answer you think is best without being insulting and don't get
upset with other people who choose a different angle.
Coby
Jeff Dalton
> * Arseny Slobodjuck wrote:
> > Hi, all !
> > I am a novice in Lisp, can somebody help me with such a question ?
> > I need a function, which will modify given parameter(s). In C++ i has
> > wrote : int func(int ¶m), can i do this in Lisp or "i still thinking
> > procedurally " ? I using xlisp 2.1.
>
> All arguments in lisp are passed by value. If the object that you
> pass is mutable (like a list, or an array, or something), then you can
> modify it using the normal destructive operators. What you can't do
> is the explicit-pointer-based hacks that languages like C and C++ let
> you do.
Having read a number of further responses, I suspect that what I'm
about to say will annoy just about everyone, but there is a not all
that bad, function-based, hack that pretty much deals with this.
(That you could use functions/closures was mentioned, but not very
enthusiastically.)
You may recall that Lisp Machine Lisp had "locatives" that were
(ok, are) essentially pointers. What's perhaps less well known is
that T (a kind of Scheme) had function-based "locatives" for those
who wanted them. And, just as call-by-name can be done with "thunks",
...
Here's a Common Lisp version.
This was written around 1987 and has not been fully brought
up top date for ANSI Common Lisp and probably has some other
stupidities about it too.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
;;; Locatives `a la T 2.8
;;;
;;; Jeff Dalton, AIAI, University of Edinburgh
;;;
;;; A locative is a pointer to a place, where the place is specified
;;; by a generalized variable as in SETF. Operations:
;;;
;;; (LOCATIVE place) Macro, creates a locative pointing to place.
;;; (CONTENTS locative) Dereferences a locative. Can be used with
;;; SETF.
;;; (LOCATIVE-P object) Predicate for recognizing locatives.
;;;
;;; In (LOCATIVE place), subforms of place are evaluated when the locative
;;; is created, and not when it is dereferenced.
;;;
;;; Unlike pointers in languages like C, or in Lisp systems that can make
;;; use of "invisible pointers", the locatives defined here are not very
;;; efficient: they're implemented using thunks.
(provide "LOCATIVES")
(in-package "RANDOM")
(export '(locative locative-p contents))
(defstruct (locative (:print-function print-locative))
"Represents a locative pointer."
(val-thunk ())
(set-thunk ())
(source ())) ;for debugging...
(defun print-locative (loc stream depth)
(if (and *print-level* (>= depth *print-level*))
(write-string "#" stream)
(format stream "#<Locative from ~S>" (locative-source loc))))
(defmacro locative (place)
"Returns a pointer to a place, place as in SETF."
(if (symbolp place)
`(make-locative
:val-thunk #'(lambda () ,place)
:set-thunk #'(lambda (val) (setq ,place val))
:source ',place)
(multiple-value-bind (temp-vars val-forms store-vars
store-form access-form)
(#-:ansi-cl get-setf-method
#+:ansi-cl get-setf-expansion
place)
(unless (= (length store-vars) 1)
(error "Can't handle more than one store value in ~S" place))
;; could skip binding vars in some cases...
`(let* ,(mapcar #'list temp-vars val-forms)
(make-locative
:val-thunk #'(lambda () ,access-form)
:set-thunk #'(lambda ,store-vars ,store-form)
:source ',place)))))
(defun contents (loc)
"Dereferences a locative."
(check-type loc locative)
(funcall (locative-val-thunk loc)))
(defun set-contents (loc val)
"Sets the place indicated by a locative."
(check-type loc locative)
(funcall (locative-set-thunk loc) val))
(defsetf contents set-contents)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
and then:
>(defun f (ref-int int)
(setf (contents ref-int) (* int int)))
F
>(let ((a 100))
(f (locative a) 22)
a)
484
(locative a) is kind of like &a.
-- jeff
Tim Bradshaw
> I wrote
>> All arguments in lisp are passed by value. If the object that you
>> pass is mutable (like a list, or an array, or something), then you can
>> modify it using the normal destructive operators. What you can't do
>> is the explicit-pointer-based hacks that languages like C and C++ let
>> you do.
> Having read a number of further responses, I suspect that what I'm
> about to say will annoy just about everyone, but there is a not all
> that bad, function-based, hack that pretty much deals with this.
> (That you could use functions/closures was mentioned, but not very
> enthusiastically.)
I think this is a wonderful solution. But `really' this agrees with
my point, that if you pass a mutable data structure you can modify it.
In this case you're using the fact that environments are mutable data
structures in CL (if not quite visible ones).
--tim
Rahul Jain
> Having read a number of further responses, I suspect that what I'm
> about to say will annoy just about everyone, but there is a not all
> that bad, function-based, hack that pretty much deals with this.
> (That you could use functions/closures was mentioned, but not very
> enthusiastically.)
>
> You may recall that Lisp Machine Lisp had "locatives" that were
> (ok, are) essentially pointers. What's perhaps less well known is
> that T (a kind of Scheme) had function-based "locatives" for those
> who wanted them. And, just as call-by-name can be done with "thunks",
> ...
But this solution is only equivalent to global variables; it won't work if
there are multiple variables with that same name. Possibly locative could
return a unique identifier for the newly created locative which could be passed
to the function that uses it.
Being a Lisp newbie, maybe I missed the fact that your code does this
already...
--
-> -=-=-=-=-=-=-=-=-=- < Rahul -=- Jain > -=-=-=-=-=-=-=-=-=- <-
-> "I never could get the hang of Thursdays." -Douglas N. Adams <-
-> -=-=-=- URL: http://hoohoo.brrsd.k12.nj.us/~rjain/ -=-=-=- <-
-> -=-=-=-=-=- E-mail: mailto:rahul...@usa.net -=-=-=-=-=- <-
Version 9.105.999.1111111111111.23.042
(c)1996-1998, All rights reserved.
Disclaimer available upon request.
Pierre R. Mai
> Jeff Dalton wrote:
>
> > Having read a number of further responses, I suspect that what I'm
> > about to say will annoy just about everyone, but there is a not all
> > that bad, function-based, hack that pretty much deals with this.
> > (That you could use functions/closures was mentioned, but not very
> > enthusiastically.)
> >
> > You may recall that Lisp Machine Lisp had "locatives" that were
> > (ok, are) essentially pointers. What's perhaps less well known is
> > that T (a kind of Scheme) had function-based "locatives" for those
> > who wanted them. And, just as call-by-name can be done with "thunks",
> > ...
>
> But this solution is only equivalent to global variables; it won't
> work if there are multiple variables with that same name. Possibly
> locative could return a unique identifier for the newly created
> locative which could be passed to the function that uses it. Being
> a Lisp newbie, maybe I missed the fact that your code does this
> already...
Since Jeff's solution uses closures to keep track of the referenced
variables, his locatives _do_ work for lexical bindings:
* (use-package :RANDOM)
T
* (defun trial-fun (x y)
(let ((a 0))
(let ((a-loc1 (locative a)))
(let ((a -1))
(let ((a-loc2 (locative a)))
(values (contents a-loc1) (contents a-loc2) a
(progn (setf (contents a-loc1) x) (contents a-loc1))
(contents a-loc2) a
(progn (setf (contents a-loc2) y) (contents a-loc1))
(contents a-loc2) a))))))
TRIAL-FUN
* (compile *)
Compiling LAMBDA (X Y):
Compiling Top-Level Form:
TRIAL-FUN
NIL
NIL
* (trial-fun 4 5)
0 ; (contents a-loc1)
-1 ; (contents a-loc2)
-1 ; a
4 ; (contents a-loc1) after setf of a-loc1
-1 ; (contents a-loc2) after setf of a-loc1
-1 ; a
4 ; (contents a-loc1) after setf of a-loc2
5 ; (contents a-loc2) after setf of a-loc2
5 ; a
*
Regs, Pierre.
Jeff Dalton
> * Jeff Dalton wrote:
> > I [Tim B] wrote
> >> All arguments in lisp are passed by value. If the object that you
> >> pass is mutable (like a list, or an array, or something), then you can
> >> modify it using the normal destructive operators. What you can't do
> >> is the explicit-pointer-based hacks that languages like C and C++ let
> >> you do.
> > Having read a number of further responses, I suspect that what I'm
> > about to say will annoy just about everyone, but there is a not all
> > that bad, function-based, hack that pretty much deals with this.
> > (That you could use functions/closures was mentioned, but not very
> > enthusiastically.)
> I think this is a wonderful solution. But `really' this agrees with
> my point, that if you pass a mutable data structure you can modify it.
> In this case you're using the fact that environments are mutable data
> structures in CL (if not quite visible ones).
Just so, in the case of a locative to a variable; and for those
cases, I would normally do something more lightweight, namely to
use a little one-slot "ref" object. I have actually sometimes
found them useful.
However, the T-style locative hack is pretty general and also lets you
point to, say, the 3rd entry in a vector or to some slot in a struct
instance. It's yet another demonstration of the power of closures,
long may they rule.
-- jd