Prev: Searching some references
Next: Comparing Lisp to Python, what you consider more important:speed or macros.
From: Tim Bradshaw on 30 Apr 2010 09:08
On 2010-04-30 11:52:53 +0100, RG said:

> Good grief, I'm surrounded by idiots.

You are living in a hall of mirrors.

> Of course it's different. Here
> you're calling a function of two arguments with one argument.

And there you're feeding no values to a form which expects one. You
may observe a certain partly-broken symmetry there.

> That has
> nothing to do with whether or not (values) "really" returns NIL as Kenny
> claimed.

Why do you think I said it had anything to do with that? Because, you
know, I don't think I did. Obviously, though, you are much better at
interpreting what I wrote than I am.

From: Espen Vestre on 30 Apr 2010 10:15
His kennyness <kentilton(a)gmail.com> writes:

> Cool, nice exception to the exception to the exclusion. But it is a
> compiler-macro that complains, so it is not that (values) does not
> return nil if asked (it better, it's in the spec) it's that
> multiple-value-call knows how to count.

I see you guys are having fun flaming each other... I think your wording
above is not quite right though. It's true that the spec says (section
3.1.7) "if the form produces zero values, then the caller receives nil
as a value", but it's misleading to say that (values) "returns nil if
asked".

I think it's better to compare it to what happenes if you try to assign
more variables than there are values in multiple-value-bind, all excess
variables get bound to nil:

CL-USER 6 > (let ((foo (values)))
foo)
NIL

CL-USER 7 > (multiple-value-bind (foo bar gazonk)
(floor 2 3)
(list foo bar gazonk))
(0 2 NIL)

CL-USER 8 >

I think it would be misleading to explain thas as "floor returns NIL as
its third value if asked" ;-)
--
(espen)
From: Pascal Costanza on 30 Apr 2010 11:11
On 30/04/2010 16:15, Espen Vestre wrote:
> His kennyness<kentilton(a)gmail.com> writes:
>
>> Cool, nice exception to the exception to the exclusion. But it is a
>> compiler-macro that complains, so it is not that (values) does not
>> return nil if asked (it better, it's in the spec) it's that
>> multiple-value-call knows how to count.
>
> I see you guys are having fun flaming each other... I think your wording
> above is not quite right though. It's true that the spec says (section
> 3.1.7) "if the form produces zero values, then the caller receives nil
> as a value", but it's misleading to say that (values) "returns nil if
> asked".
>
> I think it's better to compare it to what happenes if you try to assign
> more variables than there are values in multiple-value-bind, all excess
> variables get bound to nil:
>
> CL-USER 6> (let ((foo (values)))
> foo)
> NIL
>
> CL-USER 7> (multiple-value-bind (foo bar gazonk)
> (floor 2 3)
> (list foo bar gazonk))
> (0 2 NIL)
>
> CL-USER 8>
>
> I think it would be misleading to explain thas as "floor returns NIL as
> its third value if asked" ;-)

Common Lisp is an infinite-functional language, because every form
returns an infinite number of values.

Or is it a multiple-values-limit-functional language?

Confused... ;)


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Tim Bradshaw on 30 Apr 2010 11:45
On 2010-04-30 15:15:51 +0100, Espen Vestre said:

> I think it's better to compare it to what happenes if you try to assign
> more variables than there are values in multiple-value-bind, all excess
> variables get bound to nil:

Or like calling a function all of whose arguments are optional. The
fact that (funcall (lambda (&optional x) x)) returns NIL doesn't
somehow mean that no-list-at-all is the same as NIL.

There is quite an interesting symmetry between multiple values and
function arguments. One of the places it the symmetry is broken is
that the handling of multiple values generally behaves as if all values
were optional, while the handling of function arguments generally
(unless you ask otherwise via &optional and so on) behaves as if all
arguments are mandatory. That's because that turns out to be the
useful behaviour: very frequently the use of multiple values is to be
able to say "here's the answer, and by the way here is some other stuff
you might be interested in", and the optional-by-default behaviour
captures that.

There are languages where function arguments are optional by default
(Perl is sort-of like this). I find that a pain.

From: Tim Bradshaw on 30 Apr 2010 12:03
On 2010-04-30 16:45:47 +0100, Tim Bradshaw said:
>
> There is quite an interesting symmetry between multiple values and
> function arguments.

And of course, that's because, if you think of CPS-transforming things,
they are in fact exactly the same thing: values are the arguments you
pass to your continuation. This must be well-known, though I've only
just realised it.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Prev: Searching some references
Next: Comparing Lisp to Python, what you consider more important:speed or macros.