From: Ian Price <ianprice90@googlemail.com>
To: David Kastrup <dak@gnu.org>
Cc: guile-devel@gnu.org
Subject: Re: when and unless
Date: Thu, 08 Dec 2011 18:10:16 +0000 [thread overview]
Message-ID: <87y5un9bp3.fsf@Kagami.home> (raw)
In-Reply-To: <87liqno3nn.fsf@fencepost.gnu.org> (David Kastrup's message of "Thu, 08 Dec 2011 09:42:36 +0100")
David Kastrup <dak@gnu.org> writes:
> So here is another proposal: (values) is not the same as *unspecified*.
> But if you take the first value of a values list in single-value
> contexts, there is nothing about that coercion mechanism that would keep
> you from using *unspecified* whenever that values list would be empty.
This seems like a special case of the, I think, CL behaviour where you
get a nil for each of the values expected that were not explicitly
returned. Not my preference, but certainly not the worst thing you can
do.
(As an aside, people who want this behaviour can use
https://gist.github.com/1359350 which I wrote for dsmith a while back)
> So you would have
>
> (length (call-with-values (lambda () *unspecified*) list)) => 1
> (length (call-with-values (lambda () (values)) list)) => 0
> (eq? (values) *unspecified*) => #t
>
> After all, you will also have
>
> (length (call-with-values (lambda () (values #t #t)) list)) => 2
> (length (call-with-values (lambda () #t) list)) => 1
> (eq? (values #t #t) #t) => #t
>
> and nobody seems all too worried about that, I guess.
Some of us are, I think in the guile community this is a minority
view.
--
Ian Price
"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"
next prev parent reply other threads:[~2011-12-08 18:10 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-30 10:44 when and unless Andy Wingo
2011-06-30 21:46 ` Ludovic Courtès
2011-07-01 7:50 ` Andy Wingo
2011-07-01 12:47 ` Ludovic Courtès
2011-12-05 20:23 ` Andy Wingo
2011-12-06 7:48 ` Marijn
2011-12-06 8:29 ` Alex Shinn
2011-12-06 11:17 ` David Kastrup
2011-12-06 16:25 ` Andy Wingo
2011-12-06 16:42 ` David Kastrup
2011-12-06 17:35 ` Andy Wingo
2011-12-06 22:08 ` David Kastrup
2011-12-06 23:05 ` Chris K. Jester-Young
2011-12-07 9:23 ` David Kastrup
2011-12-07 15:58 ` Chris K. Jester-Young
2011-12-08 8:42 ` David Kastrup
2011-12-08 15:34 ` Chris K. Jester-Young
2011-12-08 16:10 ` David Kastrup
2011-12-08 18:10 ` Ian Price [this message]
2011-12-07 16:10 ` Chris K. Jester-Young
2011-12-06 19:05 ` Chris K. Jester-Young
2011-12-06 19:33 ` Andy Wingo
2011-12-06 14:39 ` Ludovic Courtès
2011-12-07 14:19 ` Ludovic Courtès
2011-12-07 14:27 ` David Kastrup
2012-01-07 0:16 ` Andy Wingo
2012-01-07 22:36 ` Ludovic Courtès
2012-01-20 20:19 ` Andy Wingo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y5un9bp3.fsf@Kagami.home \
--to=ianprice90@googlemail.com \
--cc=dak@gnu.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).