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

[Thien-Thi Nguyen]

   From: Steve Tell <address@hidden>
   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