guile-user
[Top][All Lists]
Advanced

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

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


From: Steve Tell
Subject: Re: 1.5.6: (bound? ) missing from optargs.scm
Date: Fri, 29 Mar 2002 21:26:45 -0500 (EST)

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




reply via email to

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