·····@gmx.net (Wolfhard Bu�) writes:
> Is it possible for a caller to decide whether the called function
> returns nil or just no values?
Yes, but right now I can't think of any other way than through
multiple-value-list:
USER(101): (defun novalues ()(values))
NOVALUES
USER(104): (defun nilvalue ())
NILVALUE
USER(105): (multiple-value-list (nilvalue))
(NIL)
USER(106): (multiple-value-list (novalues))
NIL
--
(espen)
·····@gmx.net (Wolfhard Bu�) writes:
> Is it possible for a caller to decide whether the called function
> returns nil or just no values?
> How is the decision made by the top level loop?
(eq nil (values))
==> t
i.e. what's the difference?
dave
David Bakhash <·····@alum.mit.edu> writes:
> (eq nil (values))
>
> ==> t
>
> i.e. what's the difference?
There _is_ a difference. What your'e seeing here is just an effect of
the rules that come into play when there's a mismatch between the
expected and the actual number of values. Specifically, the rule is
that when more values are expected than provided, nil is substituted
for the missing values. EQ (or any function application, really)
expects one value, but gets none, so nil is substituted.
Likewise, if there are too many values, the superfluous values are
just ignored:
(eq 'foo (values 'foo 'bar))
=> t
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@acm.org> writes:
> David Bakhash <·····@alum.mit.edu> writes:
>
> > (eq nil (values))
> >
> > ==> t
> >
> > i.e. what's the difference?
>
> There _is_ a difference.
In that case, my reply to the original poster is as follows. If you
want the calling function to designate one or no return values, then
here's how I'd do it:
(defun some-function (a b &optional return-no-values-p)
(foo a)
(bar b)
(when return-no-values-p
(values)))
But what you end up saving by not returning NIL is probably less that
what you've lost with the added optional argument. Even if you used
some global variable, just checking its value will incur more cost
than returning an unneeded NIL.
There are languages (e.g. Perl, I think) where something about the
structure of the function call affects the computation and return
mechanism. I don't remember the details, though. It escapes me right
now what that something is.
dave
David Bakhash <·····@alum.mit.edu> writes:
> There are languages (e.g. Perl, I think) where something about the
> structure of the function call affects the computation and return
> mechanism. I don't remember the details, though. It escapes me right
> now what that something is.
ah. I feel better now. I finally remembered what that something in
Perl was. It's the wantarray() boolean-returning function, which can
be called from the callee to determine the context of the function
call, and if the value returned was to be placed in an array context
or not. So if you were to do:
In Perl this particular operator makes sense, because it is more
efficient to pass around refs than arrays, hashes, etc. So when some
people write functions that naturally return arrays (and hashes),
they'd like to use refs. However, it can get hard to keep track of
which functions return arrays and which return references to arrays,
and so sometimes the authors of these functions just keep it real
simple: use wantarray() to determine what to pass back.
Come to think of it, I used it all the time. But arrays, and array
refs, and globs, and all that nonesense. I can't say I enjoyed it too
much, but it wasn't too bad difficulty-wise. I considered it "the
price I was paying" for getting to use all the nice Perl modules and
libraries that simply do not exist for Common Lisp.
dave
David Bakhash <·····@alum.mit.edu> writes:
> There are languages (e.g. Perl, I think) where something about the
> structure of the function call affects the computation and return
> mechanism. I don't remember the details, though. It escapes me right
> now what that something is.
ah. I feel better now. I finally remembered what that something in
Perl was. It's the wantarray() boolean-returning function, which can
be called from within the callee to determine the context of the
function call. It returns boolean true if the value returned is to be
placed in an array context, and false otherwise.
In Perl this particular operator makes sense, because it is more
efficient to pass around refs than arrays, hashes, etc. So when some
people write functions that naturally return arrays (and hashes),
they'd like to use refs. However, it can get hard to keep track of
which functions return arrays and which return references to arrays,
and so sometimes the authors of these functions just keep it real
simple: use wantarray() to determine what to pass back.
Come to think of it, I used it all the time. But arrays, and array
refs, and globs, and all that nonesense. I can't say I enjoyed it too
much, but it wasn't too bad difficulty-wise. I considered it "the
price I was paying" for getting to use all the nice Perl modules and
libraries that simply do not exist for Common Lisp.
dave
David Bakhash <·····@alum.mit.edu> writes:
> "the price I was paying" for getting to use all the nice Perl
> modules and libraries that simply do not exist for Common Lisp.
Hear! Hear!
--
Jean-Louis Leroy
http://users.skynet.be/jll