I think this "what's the matter with conflicts, and an arbitrary package
putting things wherever it wants, and not having a notion of
non-backward-compatibility" is similar to "what's the matter with using
eval for everything" or "what's the matter with defmacro" or "what's the
big deal about having subroutines in a language".
The questioner's position works for them, some other person thinks it's
a very bad idea, and you can trot out hypothetical scenarios and
anecdotes, but -- since it can be argued to reduce to pragmatic
tradeoffs involving unknowns -- you can't (at least I can't) persuade
someone who thinks they know better.
How about we just say that the module system was originally designed as
something that core Racket developers would like to use, having a low
friction to moving an individual core developer's side projects into the
tidy-looking core, or to doing other kinds of shifting they would like
to do in core Racket? Without an acknowledgement that not all
third-party package developers will be working like that, nor that
everyone wants to make the substantial compromises to facilitate that
low friction.
For third-party developers like me, I can layer something to work around
some of the drawbacks, and, pragmatically, that's what I'll have to do.
Neil V.
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
