Re: The Guile junk drawer and a C plea

[Dr. Arne Babenhauserheide]

Maxime Devos <maximedevos@telenet.be> writes:
> No it doesn’t, because of _the version number_. If you put (6) next to
> the module name, that’s the _exact_ version number, it’s not ‘6 or
> later’ or ‘maybe 6 whatever’, it’s ‘exactly 6’. You could load
> multiple versions of a module at the same time! (Not actually
> implemented currently, but it _could_ relatively easily be
> implemented.)

Yes, that’s what I mean.

And then I use a second library which gives me a comparator, so I pass
equal? from (rnrs base 7) to hash-table from (rnrs something 6).

Either this is allowed, then I just doubled my testing area, or this
is forbidden, then programs break on update of a library and need to
update all their libraries to the new dependency version.

> Also, what source maintenance? Software, that isn’t subject to changing 
> external demands, doesn’t rot, and a _precise_ version number
> is included which implies the lack of changing external demand.

I am writing about not breaking on update.

> In terms of implementation, realistically there would be a single module 
> version that contains the actual implementation, and various
> other version variants that only say ‘take these binding from that module 
> (vN), with those renamings’ (and the occasional ‘this binding
> was removed / has different arguments / ..., let’s provide a small wrapper).

I’m seeing in Guix how much more complex this approach makes packaging
Haskell-programs. How Rust programs spawn 500 MiB of
source-with-dependency for small features.

>>You can use methods to shift the load of backwards compatibility to
>> different groups, but you cannot remove it.
>
> I’m pretty sure you can remove backwards compatibility

You cannot remove *the load of backwards compatibility*.

> But in the case of _(guile)_, for most things in (guile) this isn’t really 
> the case. Likewise, (rnrs ...) is pretty well-defined – there are some
> changes to RnRS stuff, but it’s mostly just additions, removals and 
> reorderings – the semantics appear to have remained pretty much
> the same.

Yes, and that is how it should be.

It’s when you don’t actually need version numbers. And if you added
them, you’d still have to ensure compatibility between different
versions, because libraries you use will have to be updated, even if
your own code just keeps working.

That’s why I say that the load of backwards compatibility cannot be
removed: it can only be shifted on other people.

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.

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

signature.asc
Description: PGP signature