Marius Vollmer wrote:

> I'd say it is a trade-off between how much pain you are willing to
> inflict upon your clients and how much pain you are willing to suffer
> yourself.
> 
> I think (and hope) it is entirely tolerable to require you clients to
> install Guile 1.6 when they want to compile your code.

As the author of a piece of code that is relatively obscure,
it is tough enough to get it test-driven, let alone test-driven
after they have had to upgrade something else.  Current distributions
are still using 1.4 (leastwise the latest Red Hat 7.x and SuSE 8.1
use it).  These releases are not even a year old yet.  It *will*
be a couple of years before it is reasonable to expect all potential
clients to have 1.6.

> > May I please encourage you to supply configury stuff that is capable
> > of adapting current interfaces to old Guiles?
> 
> Too much work for too little gain, I'd say.  Instead, we should make
> it as easy as possible to install Guile 1.6 so that there is no reason
> not to have it on ones system.

I sent some macros, tho I coded around the need to use it myself.

> These configure snippets might be collected in a central place, maybe,
> when people are willing to maintain such a thing.

That's what I was suggesting...

> But given the above, I think it is OK to just fail and require Guile
> 1.6.

Too early.

> There are two [main] reasons... to want stability in an interface:
> one is that your code works unchanged with multiple
> versions/implementations of the other side of the API, another is that
> you don't want to do the work of tracking the changes in an API.

> In my opinion, the first reason is not very valid for Guile; there
> should be no reason to require some code to compile _unchanged_
> against multiple versions of Guile.  When there are such reasons, we
> should work to remove the reasons, not to make it easier to compile
> _unchanged_.

I don't want to really say, "unchanged".  I do want to say
that the compatibility glue is important.  I am now developing against
1.6.  However, as much as you would like to see 1.4 retired,
the bulk of the distributions at this time have 1.4.  I need
to be able to jigger what I use so it can adapt to whatever
is locally installed.  By the time the bulk of installations
are running 1.6, you'll be shipping 1.8 and using the same arguments.

> Note the emphasis on _unchanged_.  Not wanting to do much work when
> tracking API changes is a very good position to take.

I'm taking both positions (I get to, I'm not developing Guile ;-).
But I'm also willing to share what I've done.  (Attached are two
configury macros.  One to find libguile, even on systems where
guile-config was omitted [Red Hat], the other to detect 1.4 systems
and provide #define glue for scm_eval_x and scm_port.)

> When changing
> the Guile API, we should make it in such a way that client code needs
> to change as little as possible.  This often means that it doesn't
> need to change at all.  However, it is not an unbreakable requirement
> that client code must continue to compile with all new versions of
> Guile.

That's a little extreme.  OTOH, when you retire ``scm_port'' you
could also add:

  #if (THE_LAST_GUILE_VERSION_I_KNEW_ABOUT < GUILE_VERSION_1_6)
  #  define  scm_port scm_t_port
  #endif

and delete that code only after 1.6 has been in the major distros
for a couple of years.  The Guile version I understand is a
mix of 1.4 and 1.6 'cuz I'm transitioning.  The attached configury
checks for 1.4 and does the reverse #define:

  /* Define this if no scm_t_port */
  #define scm_t_port scm_port

> It is of course good practice to minimize the needed changes,

I'm sure you do your best.  One's best cannot ever be perfect.

> > P.S. If _anyone_ can show me how to set the string port file
> > name and line number, I *sure* would be a happy camper.
> 
> I'm getting to that in a few minutes... :-)

Cool.  :-D