Stephen White wrote:

# > J> I must say that despite the fact that this would change 
incompatibly the
# > J> language in a big way, I like very much this proposal. Much cleaner 
than
# > J> current ruby semantics, in my opinion. But probably not feasible :(
# > 
# >  and scripts in RAA (rwiky, tmail, erb, etc) perhaps it's faster to 
rewrite
# >  completely RAA :-(
# 
# Or invent an upgrade mechanism to take care of any language changes
# that happen in future.

I doubt that is really feasible, but trying to move in that direction 
might still be quite useful for other reasons. (Of course this would be 
very handy for Ruby 6 or Ruby 3000.) The problem is that the RAA is 
probably a small fraction of the world's total existent Ruby code, which 
may be 100x--1000x larger than the RAA and standard Ruby libraries. Some 
significant fraction of this code is in active use, which in many cases 
would cause very serious problems if it stopped working or had to be 
fixed. 

Plus you break code in other very inconvenient places--i.e. people's 
personal reference books.

Moreover, iIf you have to check and repair existing code due to language 
changes, that effectively shoots down many of the psycho-ergonomic and 
socio-economic arguments for using Ruby in the first place. Unfortunately 
for many-to-most people that have been using Ruby for any length of time, 
the only thing more obnoxious than backwards compatibility is lack of it. 
The best way to deal with it seems to be Perl4 --> Perl5 --> Perl6.

# Ruby programs can specify the version of Ruby they're written for,

They could, but most don't, AFAIK.

# then there's a few different ways of handling it. Scanning code for
# stuff that will break, backwards compatibility modules,
# auto-conversion, etc.
#
# I think the main problem is that there's no one place where all the
# code can be handled together. If a part of Ruby gets changed,
# unpacking files from RAA, building, testing and re-packing isn't
# feasible.
# 
# What about a giant source code tree where everything Ruby can be
# compiled in one go, like BSD's "make world" scheme?

I think this is a pretty good idea. You need some way of specifying the 
largest subset of the RAA for which this makes sense.
 
# This would allow a number of interesting possibilities. One thought
# that springs to mind would be apt-get style functionality for Ruby
# modules, which could take advantage of a unified unit testing scheme
# to fetch the reqested module, compile, unit test and install.

Definitely cool.

However, this would also help produce a nice Master Ruby distribution (aka 
"batteries included distribution", "SDK distribution", "Sumo 
distribution") for downloads and for Linux distros and InstallShield 
distros. 

One thing that I think helped Java catch on is that it came with a 
shipload of common libraries. Many Tcl folks think that having lots of 
neat stuff that had to be tracked down and fetched has greatly hindered 
Tcl popularity. Many Perl6 proponents are pushing for a standard "SDK" 
distribution that comes with a lot more in the way of web and XML and 
other frequently fetched library modules. 

# This would allow a core change to be rippled out to modules in one
# hit.

More likely this system would be used to *preclude* a core change that 
produced nontrivial hits. But that's also a good reason to have it.

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)