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 _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
