[r6rs-discuss] [Formal] Version reference syntax is overly complex.

From: William D Clinger <will>
Date: Thu, 21 Jun 2007 08:35:42 -0400

Mike Sperber wrote:
> In the real world, I've often seen people work around bugs, effectively
> producing code that depends on their specific nature. (I know they
> shouldn't, relying only on the interface. We don't even have a serious
> notion of "interface".) Fixing the bug breaks their code. So,
> patch-level changes are really often incompatible changes.

The editors should not be trying to solve this problem.

In the real world, dynamically typed languages will
never be competitive among programmers whose main
concern is to isolate themselves from the bugs in
standard and third-party libraries, many of which
are written in inherently unsafe languages that will
never interoperate all that well with safe languages
anyway. The editors should abandon their attempt to
design a language that seeks to isolate programmers
from those libraries, and focus instead on the task
of making those libraries more accessible.

> It also gets bumped when old procedures work on more inputs than
> before. Mostly OK, but can cause problems when clients rely on
> exceptions for these cases.

The exception system of the draft R6RS was never
intended to support that style of programming.
Clients should never rely on exceptions; they
should only recover from them. You should state
that as a principle and stick to it. Clients
who rely on the existence of bugs deserve to
lose when those bugs are fixed.

> I'm still oversimplifying a bit, but you get the drift, I hope. That
> leaves conservative extensions to the syntax as the only mostly-safe way
> to do a non-major upgrade to a library.

If true, that is a sad comment on R6RS libraries.

It also implies there is *no* mostly-safe way to
do a non-major upgrade to libraries that aren't
written in Scheme. That doesn't sound like a
real-world design to me.

> This is why the whole versioning thing is comparatively rich---people
> won't get their version references right on the first try, but they'll
> evolve. And, if they look funny, that's a sign the library author has
> probably done something wrong.

Tom Lord is partly right about this. Most of
the versioning mess should be the responsibility
of the same layer that maps library names to
files and other real-world objects. The editors
have declared that layer to be outside the scope
of the normative part of the report, so versions
should probably be outside of the report's scope
also. Versions don't belong in ordinary source
files; get rid of them.

Will
Received on Thu Jun 21 2007 - 08:35:42 UTC