Re: Re-addition of deprecated stuff to 1.7.

[Marius Vollmer <mvo@zagadka.de>]

Bruce Korb <bkorb@veritas.com> writes:

> I'm going to guess here, so please correct me if I am wrong.  I
> think the client model you are operating with is that someone
> develops some code and gets it running on their local system and
> then they are happy campers.  That is not what I am doing.  I am
> distributing my stuff to whomever and they will use whatever Guile
> happens to be installed on their systems.  Some of them are using
> libguiles that are quite a few years old.

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.  They should
not need to remove (the run-time parts of) Guile 1.4 for this; thus,
software that uses Guile 1.4 will continue to run.  Installing Guile
1.6 is no big deal, I hope.

The alternative, making sure that your code works with both Guile 1.4
and Guile 1.6, is much more painful and moreover, it wont allow your
code to cleanly take advantage of the 'new, improved' features of
Guile 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.

> For example, it would be _really_nice_ if it were to define a
> scm2newstr_size_t.  That way I would not be completely unbuildable
> on I32LP64 platforms that still use "int" for the size argument.
> Stuff like that would be Really Nice.

Yep, that's a bug in Guile 1.6.  We haven't been careful enough to
keep the public API backwards compatible.

For this specific bug, if you really need to work with both API
versions, I think it is best to have a configure check in your package
that detects what kind of gh_scm2newstr you are compiling against.
These configure snippets might be collected in a central place, maybe,
when people are willing to maintain such a thing.

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

> My desire is to use a small stable subset that won't vary very much.
> Which is also why I selected the advertized- as-stable gh interface
> for as much as possible.  *sigh*.

There are two reasons (at least) 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_.

Not the emphasis on _unchanged_.  Not wanting to do much work when
tracking API changes is a very good position to take.  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.  

It is of course good practice to minimize the needed changes, and we
probably have botched it a bit in the Guile 1.4 to Guile 1.6
transition.  Client code might need to change more than in an ideal
transition, but as I said, there should be no strong reasons not to
make these changes.

> 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... :-)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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