guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Items blocking release 1.6.1 (2002-04-21)


From: tomas
Subject: Re: Items blocking release 1.6.1 (2002-04-21)
Date: Thu, 25 Apr 2002 11:09:14 +0200
User-agent: Mutt/1.3.24i

Hi,

it's not my intention to complicate further an already
delicate discussion, but just to supply an user's point
of view:

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

>                                  From a robustness standpoint,
> distinguishing between explicitely specifying a keyword with its
> default value in a function call, and not specifying it, should not be
> done.  That is, it is better to say "When you don't specify the :foo
> keyword, it's value is defaulted to #f.  A value of #f means bla."
> instead of "When you don't specify the :foo keyword, it means bla."

...but #f seems to be just wrong, since it's an often-used `logical'
value. Unspecified seems nice for something ``you don't specify'',
doesn't it? (I know, you were against that on a previous posting).

(BTW. I just resisted the temptation to propose '(), because
that's quite another thread ;->

Thanks
-- tomas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]