I think this is a good point.
As REBOL grows in capability and application areas, it will be necessary to
consider such issues as scalability.
A /Core with the ability to add predefined facilities easily would be one
approach.
My concern would be that REBOL might end up with problems similar to what I
experienced with FORTH, where I experienced problems going from an embedded
language to a full development environment. The fact that the name space was
flat and there was no real modular way to control the expansion caused
problems.
As an example, REBOL modules seem to want to reside in a single home
directory. Perl uses a mechanism where module naming structure and directory
structure are parallel. This mechanism evolved to meet the problem of
managing a growing body of standard modules - it wasn't gratuitous. While
REBOL supports the idea of category, and REBOL-Org structures their library
based on it, it doesn't seem to be a formal mechanism. (I admit that I
haven't found any discussion of the category word and its use.)
FWIW,
Garold (Gary) L. Johnson
DYNAMIC Alternatives
[EMAIL PROTECTED]
562 802 1639
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
> One of the things that always amazes people is how powerful /Core is
> despite how small the binary is. I think /Core needs to stay around
because
> we will be looking to put messaging language into smaller and smaller
> devices and time goes by. Put /Core on a watch or in a medical device
which
> swims in the bloodstream and sends messages back to a computer via
> wireless. Keep /Core around, for sure, and work to make it SMALLER for
> gosh sakes.
> It's just my opinion, and that of many others so it seems, that /Core
> oughta stay around. This does not mean that we do not want /View or
> /Command or any of the others (we do, we do!)... It just means that /Core
> is the perfect entry level point for REBOL and we hope that
> ever-so-easy-to-open portal remains in place.
