Re: The Guile junk drawer and a C plea

[Dr. Arne Babenhauserheide]

Maxime Devos <maximedevos@telenet.be> writes:
>> But when the culture shifts so people say “hey, we have versioned APIs
>> now, let’s change everything around to fit this new style; it won’t
>> break existing clients (until we remove the old version)” (can you say
>> that you never saw people do that? I did see it), then it causes serious
>> problems.

> Someone else said to remove the old version, not me.

It’s how this thread started, so that’s what I’m talking about.

I comment on the case without deleting them at the end.

> It also probably does not, because ‘equal?’ from (rnrs base (7)) would 
> likewise be the same as (rnrs base (6)).
>
> Also, this is allowed, because (IIRC) (rnrs something (6)) has an API where 
> you specify _which_ hash and _which_ comparator – so it doesn’t care
> which comparator and hash (as long as they are compatible with each other and 
> the comparator is, in fact, a comparator (reflexivity,
> transitivity, symmetry)). In particular, it breaks nothing.

It breaks nothing right now, because people took care to keep the
semantics the same. They cared about backwards compatibility. But this
is what changes if we use versions as reason to ignore backwards
compatibility.

> This does not increase the testing area, because the testing area of
> (rnrs something (6)) is already infinite since it can’t care about
> which comparator in particular it is passed – 2*infinity = infinity
> for most notions of infinity.

This is sophistry: leaving out that there are non-infinite parts of this
infinity which are important to tested for most use-cases — and that
these non-infinite parts double.

> I also never claimed that versioning is a panacea.

Then I misunderstood you, because all I am doing is to warn, that
versioning APIs to make big changes has drawbacks and risks a cultural
shift towards breaking backwards compatibility.

I’ve seen this with Python 3. It shows again with Rust.

Scheme implementations have a pretty good history of backwards
compatibility and making that worse is what I worry about.

> Can you stop it with the strawmen?

It’s only a strawman if it isn’t real.

I am showing you examples where it leads when version numbers are
treated as a free pass to break backwards compatibility.

This is not a strawman, but the risk I see when a warning not to break
backwards compatibility is answered with “we need versions”.

>> That’s why I say that the load of backwards compatibility cannot be
>> removed: it can only be shifted on other people.
>
> This is false, you can also shift it on yourself (i.e. whoever does a bunch 
> of renamings, also changes the version number and under the old
> version number adds some bindings referring to the new names in the new 
> version number).
> 
> I guess this is technically a ‘load’, but the effort required is so minimal 
> that this is hyperbole.

It sounds like this is the main point where our opinions differ. I do
not consider this effort as minimal. It may look small with the first
change, but it grows more than exponentially, because if you want to
give a guarantee, every version has to be tested against every
combination of already existing versions.

> what would be the problem with _renaming_/ _relocating_ when the old names 
> are still preserved?

Off the cuff: You now have two sets of documentation to keep in sync
(including tutorials that no longer match the best-practices), you must
ensure that the implementations stay the same, you get code using mixed
and matched module hierarchies, dependent parts can get imported with
different names depending on which best-practices their authors
followed.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

signature.asc
Description: PGP signature