unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Steve Tell <tell@telltronics.org>
Cc: guile-user@gnu.org
Subject: Re: 1.5.6: (bound? ) missing from optargs.scm
Date: Fri, 29 Mar 2002 21:26:45 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.21.0203292058010.18381-100000@ariel.lan.telltronics.org> (raw)
In-Reply-To: <E16qr3v-0001eu-00@giblet>

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


  reply	other threads:[~2002-03-30  2:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-28  6:30 1.5.6: (bound? ) missing from optargs.scm Steve Tell
2002-03-28  8:52 ` Thien-Thi Nguyen
2002-03-28 23:32   ` Thien-Thi Nguyen
2002-03-29  6:40     ` Steve Tell
2002-03-29  7:44       ` Thien-Thi Nguyen
2002-03-30  2:26         ` Steve Tell [this message]
2002-03-30  4:42           ` Thien-Thi Nguyen
2002-03-31 22:06             ` Marius Vollmer
2002-04-01  1:42               ` Thien-Thi Nguyen
2002-03-31 22:46           ` Marius Vollmer
2002-04-24 17:52             ` Marius Vollmer
2002-03-31 22:59     ` Marius Vollmer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.21.0203292058010.18381-100000@ariel.lan.telltronics.org \
    --to=tell@telltronics.org \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).