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

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

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> cc'ing guile-user to see who complains (besides me).  maybe someone can
> send a patch to do a clean fix, and explain it.  maybe it's time to fork
> guile (again).

If you think it's worth forking guile over this, please do.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Bill Gribble]

On Mon, 2002-04-22 at 15:05, Thien-Thi Nguyen wrote:
> cc'ing guile-user to see who complains (besides me).  maybe someone can
> send a patch to do a clean fix, and explain it.  maybe it's time to fork
> guile (again).
  
Is it a coincidence that 'Thien-Thi' could be pronounced close to
'TNT'?  It seems like you're jumping right to the discussion-ending
threat to fork Guile well before the diplomatic channels have been
exhausted.  Your emissaries are still trying to get through the
receiving line at the opening night cocktail party!  

b.g.
 


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Thien-Thi Nguyen]

   From: Bill Gribble <grib@linuxdevel.com>
   Date: 22 Apr 2002 15:29:42 -0500

   Is it a coincidence that 'Thien-Thi' could be pronounced close to
   'TNT'?

well, they say destruction is the first step in optimization...

   It seems like you're jumping right to the discussion-ending threat to
   fork Guile well before the diplomatic channels have been exhausted.
   Your emissaries are still trying to get through the receiving line at
   the opening night cocktail party!

i hope they get loaded so i can steal their shoes for more podium
pounding (mine are worn out at the "heal" ;-).

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    Ok, I'll looker closer into this, and I now have to say that we can't
>    'fix' it.  We would be changing the default default value from '#f'
>    to something else.  That would be an unacceptable interface change.
> 
> but removing `bound?' is acceptable?

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

>    Since it is easy for the user to provide the functionality on its
>    own, we can just leave it as it is.
> 
> to provide out of band info, you can use out of band methods (in fact,
> this is the fix i thought you were going to consider).

Yes, but we would have to change the semantics of (ice-9 optargs) in a
way that could lead to silent failures.  Removing 'bound?' did not do
that.

> cc'ing guile-user to see who complains (besides me).  maybe someone can
> send a patch to do a clean fix, and explain it.  maybe it's time to fork
> guile (again).

I think it would be smarter to just fork (ice-9 optargs), if you can
make such fine distinctions.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Mon, 22 Apr 2002 15:15:34 -0500

   If you think it's worth forking guile over this, please do.

you missed the irony: the act of introducing gratuitous incompatibility
(and subsequently allowing it to fester) is de facto "forking guile".
guile credibility is down because it has been f**ked so, many times.

paraphrased from some sig: it's not foolish to do foolish things, it's
foolish if we don't see the folly.  personally, i was foolish to think i
could help guile improve w/o seeing the folly that it is the guile
maintainers who need to improve (which is outside my control).

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> personally, i was foolish to think i could help guile improve w/o
> seeing the folly that it is the guile maintainers who need to
> improve (which is outside my control).

Of course you can help guile improve -- your past history and good
work is proof of that.

I can't speak for everyone else, but I'd really like to try to work
*with* the other maintainers to resolve our outstanding issues.  If I
wasn't interested in that I wouldn't be taking the time to do the
things I've been doing, including trying to work out a release process
everyone can agree on that will hopefully help avoid the disagreements
we recently had on the subject.

In this particular case, instead of the response you posted, I'd like
to hear what your specific complaints are wrt bound?, and to hear what
fix you have in mind, if any.  For example, you mention using
out-of-band communications, but can this be done in a way that doesn't
force everyone to change their code anyway?  If not, then how is it
any different than just removing bound?

Note that these aren't rhetorical questions.  I'm not all that
familiar with the issue since it wasn't my bug, and so I'd like to
understand all the considerations.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> In this particular case, instead of the response you posted, I'd like
> to hear what your specific complaints are wrt bound?, and to hear what
> fix you have in mind, if any.  For example, you mention using
> out-of-band communications, but can this be done in a way that doesn't
> force everyone to change their code anyway?  If not, then how is it
> any different than just removing bound?

Also FWIW the guile 1.4 info pages don't mention bound? AFAICT, and
anyone who found the mention of it in NEWS also saw:

  The optional argument module also exports the macros `let-optional',
  `let-optional*', `let-keywords', `let-keywords*' and `bound?'. These
  are not documented here because they may be removed in the future,
  but full documentation is still available in optargs.scm.

So bound?'s status was somewhat ambiguous in our last release.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> So bound?'s status was somewhat ambiguous in our last release.

Just to clarify -- that doesn't mean I think we *should* drop it.  I
just want us to try and figure out what the "right" answer is with as
much relevant information at hand as possible.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Mon, 22 Apr 2002 16:12:23 -0500

   Note that these aren't rhetorical questions.  I'm not all that
   familiar with the issue since it wasn't my bug, and so I'd like to
   understand all the considerations.

these were all discussed before.  when you ask people to repeat
themselves, they tend to reply obliquely at best, just to keep
interested.

part of maintaining the bugs database is to add relevant discussion to
the file so that everyone can see the thinking process clearly (which
reduces rehash).  alternatively we can be wombats, completely forgetting
that research can be viewed as a proper supserset of search.

for example, i recently asked about difference between characterset
designs, w/o doing the requisite digging.  the resulting silence tells
me this was unwise.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> for example, i recently asked about difference between characterset
> designs, w/o doing the requisite digging.  the resulting silence tells
> me this was unwise.

Or perhaps (at least wrt to my input) poorly timed -- I've seen the
(very long) character set discussion come up more than once, and
though I'm no expert, I'd be more than happy to try and work out a
good solution, but I'm not personally likely to do it before 1.6.1 is
released.  If others want to work on this right now, and can still
deal with the release critical issues then as far as I'm concerned,
that's fine.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[news]

Rob Browning <rlb@defaultvalue.org> writes:

> If you think it's worth forking guile over this, please do.

From a wannabe user's perspective, maybe you could just come up
with a release-naming scheme which would indicate how much damage
the changes in the release do to existing code like:

  pg-guile
  ttn-pers-scheme
  ams-pers-scheme
  mgrabmue-pers-scheme
  guile-gdbm
        .
        .
        .
       etc.
  
which ran under a released version at some time in the past.

Chris

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[tomas]

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

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[rm]

On Thu, Apr 25, 2002 at 11:09:14AM +0200, tomas@fabula.de wrote:
> 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."

I'd like to second Tomas here. Default values are essential for some
applications (esp. if guile want's to be used as a scripting language).
I don't want to force my users to have to specify all possible keywords
and i can well imagine that i need to have keywords with boolean values:

 (read-text :convert-newline #f) =/= (read-text) 

 (foo-create-window )  =?= (foo-create-window :map #f)

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

   ... not to mention NIL :-)

 Thanks
  ralf
  

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

tomas@fabula.de 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.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

rm@fabula.de writes:

> I'd like to second Tomas here. Default values are essential for some
> applications (esp. if guile want's to be used as a scripting language).

Yes, of course.  The quibbling is over the default default value,
i.e. the value to use as a default value when no default value has
been specified explicitely.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 28 Apr 2002 18:00:00 +0200

   Yes, of course.  The quibbling is over the default default value,
   i.e. the value to use as a default value when no default value has
   been specified explicitely.

no the quibbling is over removal of `bound?' (see summary field in the
bug report).  if you can expand the problem-solving process to solve
this (original) problem, that would be best.

remember to cover the case where an arg may be bound and have a
(internally consistent) value of #f.  i.e., whether or not an arg is
bound is indepdendent of its value.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 28 Apr 2002 18:00:00 +0200
> 
>    Yes, of course.  The quibbling is over the default default value,
>    i.e. the value to use as a default value when no default value has
>    been specified explicitely.
> 
> no the quibbling is over removal of `bound?' (see summary field in the
> bug report).  if you can expand the problem-solving process to solve
> this (original) problem, that would be best.

Yes, right.  I would propose to follow Common Lisp here:

    (define* (foo :optional (bar #f bar-bound?))
      (if bar-bound?
          ...))

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[spu]

On Sun, Apr 28, 2002 at 05:58:34PM +0200, Marius Vollmer wrote:
> tomas@fabula.de writes:
> 
> > On Tue, Apr 23, 2002 at 08:16:20PM +0200, Marius Vollmer wrote:
> > [...]
[...]
> 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)
>           ...))

Ah, I see now. Sorry for being ummm... thick.
-- 
tomas

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 22 Apr 2002 20:44:36 +0200

   [ice-9/optargs.scm bound? removal]

   Ok, I'll looker closer into this, and I now have to say that we can't
   'fix' it.  We would be changing the default default value from '#f'
   to something else.  That would be an unacceptable interface change.

but removing `bound?' is acceptable?

   Since it is easy for the user to provide the functionality on its
   own, we can just leave it as it is.

to provide out of band info, you can use out of band methods (in fact,
this is the fix i thought you were going to consider).

cc'ing guile-user to see who complains (besides me).  maybe someone can
send a patch to do a clean fix, and explain it.  maybe it's time to fork
guile (again).

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user