1.5.6: (bound? ) missing from optargs.scm

1.5.6: (bound? ) missing from optargs.scm

[Steve Tell]

The bound? macro appears to be missing from optargs.scm in guile-1.5.6 and
1.5.4, yet the documentation still lists it.  (section 10.2 along with
define* and lambda*)

Is this an oversight? Or what is the proper way to determine if a variable
associated with an optional-keyword has been set?

This may be the last thing standing between me and a gwave release that
supports guile-1.3.4, 1.4, and 1.5.6.


Steve


--
Steve Tell  tell@telltronics.org 


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

Re: 1.5.6: (bound? ) missing from optargs.scm

[Thien-Thi Nguyen]

   From: Steve Tell <tell@telltronics.org>
   Date: Thu, 28 Mar 2002 01:30:57 -0500 (EST)

   The bound? macro appears to be missing from optargs.scm in guile-1.5.6 and
   1.5.4, yet the documentation still lists it.  (section 10.2 along with
   define* and lambda*)

doc bug.

   This may be the last thing standing between me and a gwave release that
   supports guile-1.3.4, 1.4, and 1.5.6.

drat we need to change things more faster!

thi

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

Re: 1.5.6: (bound? ) missing from optargs.scm

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <ttn@giblet.glug.org>
   Date: Thu, 28 Mar 2002 00:52:12 -0800

   doc bug.

sorry, that was a glib answer.  here is the relevant change log excerpt:

2001-05-10  Marius Vollmer  <mvo@zagadka.ping.de>

	* optargs.scm (bound?): Removed.  We should not play games with
	the magical undefined value.

i don't particularly understand what kinds of games are no longer being
played, nor what is the suggested way to achieve prior functionality.
"doc bug" means some kind of blurb explaining these things is due in
NEWS.

thi

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

Re: 1.5.6: (bound? ) missing from optargs.scm

[Steve Tell]

On Thu, 28 Mar 2002, Thien-Thi Nguyen wrote:

> 2001-05-10  Marius Vollmer  <mvo@zagadka.ping.de>
> 
> 	* optargs.scm (bound?): Removed.  We should not play games with
> 	the magical undefined value.
> 
> i don't particularly understand what kinds of games are no longer being
> played, nor what is the suggested way to achieve prior functionality.
> "doc bug" means some kind of blurb explaining these things is due in
> NEWS.

That helps a little.  After a little thought I found an obvious
workaround, using the default-value facility.  That brings up the
question: with this change, when will it ever be useful to _not_ provide a
default value for a keyword or optional argument to a procedure built with
lambda*?

I suppose I can see how a "magical undefined value" could be a bit too
much like perl's "undef" for the purists, but this does make
lambda*/define* less useful IMHO.

Anyway, I am now successfuly building on 1.4 and 1.5.6, with 1.3.4 testing
still remaining.  I feel like I have to support 1.3.4 until more of the
major linux distributions start shipping with 1.4 or later.

Steve

 

--
Steve Tell  tell@telltronics.org 


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

Re: 1.5.6: (bound? ) missing from optargs.scm

[Thien-Thi Nguyen]

   From: Steve Tell <tell@telltronics.org>
   Date: Fri, 29 Mar 2002 01:40:57 -0500 (EST)

   [removing bound? makes lambda*/define* less useful]

this change breaks code that relies on def/undef as "valid bit".
programs that model and/or use such communication channels (e.g.,
hardware simulators) now need to implement that protocol.  if the
program already uses #f (the "obvious logical" fix) now it needs to
additionally define "my-undef".  otherwise it can use #f.

THUD author seethes inside (wtf! what a PITA), but i think i can see how
this change supports encapsulation, and so "re-layering" of the API
using some other out-of-band object is possible.  (we can bring `bound?'
back.  we just need to finish this iso-API change in the right way, or
justify in NEWS the new API.)

wrt other woes, when i took guile-snarf off of noinst_ i did not take
advantage of the dist-hook to modify already-distributed guile-snarf to
emit warnings when run, even though i thought about it.  my bad.

the story is that what we discussed and i implemented, mvo munged so
that SCM_MAGIC_SNARFER is now exposed/required/forgotten/fubared and
documented.  from no design to bad design, IMO.

   Anyway, I am now successfuly building on 1.4 and 1.5.6, with 1.3.4
   testing still remaining.  I feel like I have to support 1.3.4 until
   more of the major linux distributions start shipping with 1.4 or
   later.

some upgrade policies have proven difficult to foresee by guile
maintainers.  maybe someone will fork guile and merge it w/ chicken.
(this is how you trick distributors into upgrading. ;-)

actually, this reminds me i need to get 1.4.1 out.

thi

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

Re: 1.5.6: (bound? ) missing from optargs.scm

[Steve Tell]

On Thu, 28 Mar 2002, Thien-Thi Nguyen wrote:

> using some other out-of-band object is possible.  (we can bring `bound?'
> back.  we just need to finish this iso-API change in the right way, or
> justify in NEWS the new API.)

So, might it be back for 1.6?   
I've got some other code that uses optargs and bound.  Maybe I'll just
leave that on 1.4 and wait and see. OTOH, I'd like to be able to play with
goops.
 
> wrt other woes, when i took guile-snarf off of noinst_ i did not take
> advantage of the dist-hook to modify already-distributed guile-snarf to
> emit warnings when run, even though i thought about it.  my bad.

I'm glad you didn't - that would be rather antisocial (cf. discussion on 
peaceful coexistance of multiple versions)

> the story is that what we discussed and i implemented, mvo munged so
> that SCM_MAGIC_SNARFER is now exposed/required/forgotten/fubared and
> documented.  from no design to bad design, IMO.

Curious, what would you do differently if redesigning?  Now that its
official that every application has to implement its own snarfing system
(or go back to manual construction of the init functions), there's plenty
of room for experimentation with alternate mechanisms.  It actually didn't
take very much effort to disentangle my code from its mismash of snarfing
macros (a mix of 1.4 and stuff borrowed from the late scwm), so I'm not
annoyed.  I would like to get back to coding new stuff of my own and off
of compatibility-testing though.
 
> some upgrade policies have proven difficult to foresee by guile
> maintainers.  maybe someone will fork guile and merge it w/ chicken.
> (this is how you trick distributors into upgrading. ;-)

I get the sense that one only gets to break binary compatibility every few
years, so there's a strong need to make it count when it does become
necessary.  Some day soon, one supposes that for example RedHat will
decide whether its 1.4[.1] or 1.6 that goes into their 8.x series.  
Presumably other distributor make the same call on their own schedules.  

I hope I'm helping make 1.6 more likely to be what gets widespread
distribution for two years after that by porting to and testing the 1.5.x
ones and asking all these questions.

Steve


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

Re: 1.5.6: (bound? ) missing from optargs.scm

[Thien-Thi Nguyen]

   From: Steve Tell <tell@telltronics.org>
   Date: Fri, 29 Mar 2002 21:26:45 -0500 (EST)

   So, might it be back for 1.6?  I've got some other code that uses
   optargs and bound.  Maybe I'll just leave that on 1.4 and wait and
   see. OTOH, I'd like to be able to play with goops.

if it is to come back it has to be for 1.6 in order to sustain the
illusion of not leaving in the first place.  the alternative is to
justify the API change and then possibly justify its re-addition later,
all in addition to retooling client code, which is more messy.

currently i'm looking at 1.4.1 issues (getting closer), and i suppose
this could fall under the broader question of how/when/why to remove
things.  somewhat related, my impression is that guile maintainers found
a toy (deprecation) and went a little crazy w/ it (because virtualizing
interfaces is fun, admittedly).  unfortunately, the implication of
deprecation is removal at some point, and this requires planning that
was not done.  dropping `bound?' evokes the same disturbing feeling.

so yeah, it's likely i will spot-fix this (maybe this weekend) in the
process of getting a handle on 1.4 - 1.6 API changes generally.  since
this particular fix is small, a patch would be most gratefully received
and likely immediately applied (proabably no paperwork required).

   Curious, what would you do differently if redesigning?

well, i would hide SCM_MAGIC_SNARFER and require output file to be
specified, omitting guile-snarf writing to stdout in favor of it being
able to manage zonking the output file should the cpp fail in some way
(model after "gcc -o").  indeed, this is what i did before the work was
clobbered by foolish consistency w/ the mal-published past.

the macros and what not are fine, IMHO.  i'm just grousing because i
find it unpleasant to work w/ coding cowboys (yes mvo that's you) who
break things gratuitously and leave the pieces for others to clean up,
all the while wondering what the big deal is all about.  the big deal is
all about time and how precious it, wasted by thoughtlessness like this.

gak, i'm so worked up right now.

   Now that its official that every application has to implement its own
   snarfing system (or go back to manual construction of the init
   functions), there's plenty of room for experimentation with alternate
   mechanisms.

you mean like comment snarfing (a la doxygen and javadoc)?  this is a
pretty well trodden path it seems.

   It actually didn't take very much effort to disentangle my code from
   its mismash of snarfing macros (a mix of 1.4 and stuff borrowed from
   the late scwm), so I'm not annoyed.  I would like to get back to
   coding new stuff of my own and off of compatibility-testing though.

you and me both!

   I get the sense that one only gets to break binary compatibility
   every few years, so there's a strong need to make it count when it
   does become necessary.  Some day soon, one supposes that for example
   RedHat will decide whether its 1.4[.1] or 1.6 that goes into their
   8.x series.  Presumably other distributor make the same call on their
   own schedules.

i suppose we should do some research to see what kind of criteria they
use to determine upgrade yes/no.  in the ideal scenario this wouldn't be
far from our own plans.

   I hope I'm helping make 1.6 more likely to be what gets widespread
   distribution for two years after that by porting to and testing the
   1.5.x ones and asking all these questions.

this is very helpful; thanks!  (and mvo still has a place in my heart.)
brookes' mythical man month points out that coherent vision is necessary
for a project's success.  for collaborative free software efforts, such
a vision must necessarily be shared between both users and programmers,
and the only way this happens is w/ incisive questions back and forth.

as for longevity of 1.6, i'm still trying to figure that out.  if 1.6 is
released like 1.4, we can expect more pain.  (or maybe someone will fork
guile and merge it w/ chicken, any takers? :-)

thi

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

Re: 1.5.6: (bound? ) missing from optargs.scm

[Marius Vollmer]

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

>    Curious, what would you do differently if redesigning?
> 
> well, i would hide SCM_MAGIC_SNARFER and require output file to be
> specified, omitting guile-snarf writing to stdout in favor of it being
> able to manage zonking the output file should the cpp fail in some way
> (model after "gcc -o").  indeed, this is what i did before the work was
> clobbered by foolish consistency w/ the mal-published past.

It was not clobbered, please look more closely at what I did.  You
keep your '-o' option, and the rest of us gets to have command line
compatibility with the snarfer from 1.4.  This compatibility comes at
very little cost, if you want to call it a cost at all: the user is
not forced to switched to a better usage of guile-snarf, he is merely
allowed to.

I also removed the deprecation mechanism in the stable branch because
it partly duplicates the mechanism that we have already.

> the macros and what not are fine, IMHO.  i'm just grousing because i
> find it unpleasant to work w/ coding cowboys (yes mvo that's you)
> who break things gratuitously and leave the pieces for others to
> clean up, all the while wondering what the big deal is all about.

Yeah, I was not being very polite by snatching the hacking of
guile-snarf away from you.  Your first reply did not sound like you
wanted to continue, tho.

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

Re: 1.5.6: (bound? ) missing from optargs.scm

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 01 Apr 2002 00:06:35 +0200

   It was not clobbered, please look more closely at what I did.  You
   keep your '-o' option, and the rest of us gets to have command line
   compatibility with the snarfer from 1.4.  This compatibility comes at
   very little cost, if you want to call it a cost at all: the user is
   not forced to switched to a better usage of guile-snarf, he is merely
   allowed to.

what was clobbered was encapsulation of mechanism (internals) which
would allow us flexibility in the long run.  the general principle i
feel appropriate here is that: when starting, start w/ exposing as
little as possible; future changes are then relegated to "addition"
which is easier to satisfy normal compatibility constraints, than
"removal" or "renaming".

i felt that this principle was applicable (we are at starting point)
because "snarfer from 1.4" was not supported; adding retroactive support
is ok if the design was good, but it wasn't, so this was not really
justifiable.

the cost (aside from listening to me spew on like this) in a decision to
expose internals is always latent, which is understandably difficult to
perceive.  however, i'm sure you know the value of encapsulation because
of the `bound?' situation and am very glad to not think about that any
more and to watch you DTRT (i do this by watching tasks/TODO -- if you
claim some task i won't touch it).

   Yeah, I was not being very polite by snatching the hacking of
   guile-snarf away from you.  Your first reply did not sound like you
   wanted to continue, tho.

i had invested time to weigh the factors (as i learned them), explain my
reasoning, and do the work.  why would i want to continue when the job
was done?  more importantly, on the plate is doc snarfing -- are we
going to see the same behavioral patterns repeated?  more generally, i'm
about to open the doors to give more people write privs -- can you set a
good example for these people?

thi

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

Re: 1.5.6: (bound? ) missing from optargs.scm

[Marius Vollmer]

Steve Tell <tell@telltronics.org> writes:

> On Thu, 28 Mar 2002, Thien-Thi Nguyen wrote:
> 
> > using some other out-of-band object is possible.  (we can bring `bound?'
> > back.  we just need to finish this iso-API change in the right way, or
> > justify in NEWS the new API.)
> 
> So, might it be back for 1.6?   

Hmm, yes.

I removed 'bound?' and related code in 'let-o-k-template' since we can
not reveal the SCM_UNDEFINED value to Scheme code.  This was a bug and
needed to be solved.  The 'bound?' functionality itself is not
problematic (although not really critical as one can emulate it easily
with default-values, as you point out) and we can bring it back.
Thien-Thi is right that the removing was done without much planning or
work on the real fix, i.e. a 'bound?' that doesn't use the magic
SCM_UNDEFINED value.

'bound?' would switch from being a macro to being a function.  Would
that cause any problems?

I have recorded this issue as bug 'optargs-bound-gone'.  (Please also
see the upcoming announcement of the newish bug data base.)

> > wrt other woes, when i took guile-snarf off of noinst_ i did not take
> > advantage of the dist-hook to modify already-distributed guile-snarf to
> > emit warnings when run, even though i thought about it.  my bad.
> 
> I'm glad you didn't - that would be rather antisocial (cf. discussion on 
> peaceful coexistance of multiple versions)

You can't have two versions of Guile on your system
_for_compiling_programs_with_ anyway.  You can run programs that are
linked to different versions of libguile (with the same installation
prefix), but you can't install two sets of header files (with the same
installation prefix).

Leaving a guile-snarf around that does not correspond to the installed
header files will only cover up bugs.  I think you figured this out
yourself, right?

> [...] Now that its official that every application has to implement
> its own snarfing system 

guile-snarf will be back for 1.6.

> (or go back to manual construction of the init functions), there's
> plenty of room for experimentation with alternate mechanisms.

This room is still there, unless I'm missing something.  You are not
forced to use guile-snarf.  If you find it inadequate, feel free to
experiment with something else.

> I get the sense that one only gets to break binary compatibility every few
> years, so there's a strong need to make it count when it does become
> necessary.

In my happy ignorance of real world issues, I don't see why binary
compatibility is a big deal.  It's an annoying artifact of the usual
implementations of the C programming language, but Unix systems seem
to deal pretty well with it, anyway, wither by using static linking or
versioned shared libraries.  It has to catch up a bit when linking
dynamically (i.e. via dlopen), but it is manageable.  Source
compatibility is much more important.

Is there more to it?  (Likely.)

> I hope I'm helping make 1.6 more likely to be what gets widespread
> distribution for two years after that by porting to and testing the
> 1.5.x ones and asking all these questions.

Thanks, that's really appreciated!

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

Re: 1.5.6: (bound? ) missing from optargs.scm

[Marius Vollmer]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Steve Tell <tell@telltronics.org> writes:
> 
> > On Thu, 28 Mar 2002, Thien-Thi Nguyen wrote:
> > 
> > > using some other out-of-band object is possible.  (we can bring `bound?'
> > > back.  we just need to finish this iso-API change in the right way, or
> > > justify in NEWS the new API.)
> > 
> > So, might it be back for 1.6?   
> 
> Hmm, yes.

Well, no. :-/ We would be changing the default default value from '#f'
to something else.  That would be an unacceptable interface change.
Since it is easy for the user to provide the functionality on its own,
we can just leave it as it is.

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

Re: 1.5.6: (bound? ) missing from optargs.scm

[Marius Vollmer]

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

> 2001-05-10  Marius Vollmer  <mvo@zagadka.ping.de>
> 
> 	* optargs.scm (bound?): Removed.  We should not play games with
> 	the magical undefined value.
> 
> i don't particularly understand what kinds of games are no longer being
> played, nor what is the suggested way to achieve prior functionality.

SCM_UNDEFINED is used in C code to flag a variable that exists but has
no value associated with it.  For example, 'letrec' first creates all
new local variables with SCM_UNDEFINED as their value, and any try to
read their value will result in an error.  It also used as a special
not-a-legal-Scheme-value token in C code, for example with scm_list_n.

When Scheme code gets access to it, and treats it like any other
Scheme value, a lot of assumptions in the C code break down.

The old (ice-9 optargs) used this value as the default default value,
i.e. the value to use as the default value when no explicit default
value was specified.

We can use any other unique default default value, for example the
result of '(cons* 'unbound)'.

It might be tempting to use the un_specified_ value, SCM_UNSPECIFIED,
instead of SCM_UNDEFINED, but that wouldn't be really right, either.
SCM_UNSPECIFIED is a perfectly usable Scheme value (which
SCM_UNDEFINED is not), but it is not really specific to this purpose:
you will get it from a lot of functions, and you would then not be
able to distinguish whether your keyword has not been specified at the
call side, or whether it has been specified but with the unspecified
value (which would likely be an error, but you wouldn't notice).

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