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 &param), can i do this in Lisp or "i still thinking
procedurally " ? I using xlisp 2.1.

Cheers

(defparameter args '(1 2 3))

(setf args (func args))

coby

My experience is that you don't actually miss this, but then I've not
really been a C person for a long time.

  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.

(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.

        (setvars a b (incf c))

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.

  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.

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?"

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.

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'.

http://www8.informatik.uni-erlangen.de/html/lisp-enter.html

  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...  :)

* 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.

*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

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:

(locative a) is kind of like &a.