[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Items blocking release 1.6.1 (2002-04-21)
From: |
Marius Vollmer |
Subject: |
Re: Items blocking release 1.6.1 (2002-04-21) |
Date: |
28 Apr 2002 17:58:34 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
address@hidden writes:
> On Tue, Apr 23, 2002 at 08:16:20PM +0200, Marius Vollmer wrote:
> [...]
> > Yes. The way the old 'bound?' was implemented was a bug. The mistake
> > (my mistake) back then was to fix this bug in a sub-optimal way, by
> > just removing the functionality. Now it is too late to change it
> > again; and changing it would be quite gratuitous, too.
> >
> > Using #f as the default default value is a sensible thing, I'd say,
> > and should even be recommended.
>
> As a provider of some functionality I'd sometimes like to be able
> to distinguish between `value was provided' and `value was not
> provided at all'. It'd be perfectly reasonable to agree on a
> value which means `not provided' (like Perl's undef or Pythons
> None): an user providing *such* a value hopefully knows what
> she's doing...
Yes. You can do this easily when defining such a function. I.e.
(define not-provided (cons* 'not-provided))
(define* (foo :optional (bar not-provided))
(if (eq? not-provided bar)
...))
> ...but #f seems to be just wrong, since it's an often-used `logical'
> value.
To me, it seems just right as a default default value...
> Unspecified seems nice for something ``you don't specify'',
> doesn't it? (I know, you were against that on a previous posting).
You might use the 'unspecified value' (which is different from
SCM_UNDEFINED which was used previously) as the value of not-provided
above, but it seems to be too obscure, for my taste. It doesn't feel
right to me to give #<unspecified> any specific meaning.
- Re: Items blocking release 1.6.1 (2002-04-21), (continued)
Re: Items blocking release 1.6.1 (2002-04-21), Chris Beggy , 2002/04/23
Re: Items blocking release 1.6.1 (2002-04-21), Bill Gribble, 2002/04/22
Re: Items blocking release 1.6.1 (2002-04-21), Marius Vollmer, 2002/04/23
Re: Items blocking release 1.6.1 (2002-04-21),
Marius Vollmer <=
Re: Items blocking release 1.6.1 (2002-04-21), spu, 2002/04/28