[REBOL] Enabling the REBOL community
From: joel::neely::fedex::com at: 8-May-2001 19:36
Those who are familiar with CPAN (the Comprehensive Perl
Archive Network) know that it is a significant factor in
the growth -- and ease of use -- of Perl. CPAN modules
provide:
1) A community-maintained, standard namespace for modules,
(e.g., a reasonable tree-structured taxonomy which
helps the programmer remember "where" a module is).
2) A collection of mirror sites from which modules may be
obtained.
3) A simple set of mechanisms for acquiring a module and
installing it in the standard place on one's local box.
4) A means of ensuring that a module has been successfully
loaded into a running program that wishes to use it.
5) A means of controlling the effect that loading the
module has on the global namespace.
6) A rich source of examples for newcomers learning the
language, as well as for older hands wanting to polish
their style.
I've seen many useful pieces of REBOL code written and
shared during the time I've been subscribed to this list.
I've written one or two tidbits that I hope someone has
found useful. But... where is all of this good stuff???
Some of it is in the mailing list archives, some of it
is on various individual or group sites, some may be
lost. This is sad, since there are many good wheels out
there that don't need to be re-invented.
Several of us (myself included) have written our own tools
for "include"-ing a REBOL module from a local library into a
running script. However, it occurs to me that this kind of
infrastructure itself is a wheel that doesn't need to be
re-invented.
All of this musing motivates a couple of specific questions:
1) Can we -- as a community -- begin to build the same kind
of resource for REBOL that CPAN serves for Perl?
2) Can we agree on (or at least discuss) the kinds of
standards/conventions/features that would make such a
resource effective for the old hands and easy for the
new kids on the block?
Let me give an example of the kind of thing I mean in the
second point. I've been toying with the idea that a re-
usable code unit could take the form of an "anonymous"
object, something like the following:
8<------------------------------------------------------------
rebol [
title: "Component test"
file: "cmptest.r"
author: "Joel Neely"
version: 0.1.0
date: 08-May-2001
history: [
0.1.0 [
08-May-2001 {Preliminary proposal draft}
]
]
]
make object! [
x: 1
y: 42
sum: does [x + y]
]
8<------------------------------------------------------------
At some level down under the hood, this could be included into
another script by the equivalent of...
8<------------------------------------------------------------
>> testobject: do %cmptest.r
>> testobject/sum
== 43
8<------------------------------------------------------------
but also by embedding inside other objects, as in...
8<------------------------------------------------------------
>> foo: make object! [
[ red: 23
[ yellow: 48
[ caramel: do %cmptest.r
[ ]
>> source foo
foo:
make object! [
red: 23
yellow: 48
caramel:
make object! [
x: 1
y: 42
sum: func [][x + y]
]
]
>> foo/caramel/sum
== 43
8<------------------------------------------------------------
The point of the anonymity is, of course, to avoid the danger
of conflicting with other words defined by the code that uses
the unit (or with words defined by other units).
The point of the phrase "at some level under the hood" above
is that I don't think a simple "do %unitname.r" is the right
solution. I suggest that the unit/module/component management
mechanism contain the idea of a standard path (or set of paths)
so that units stored in the canonical place are accessible to
any using code regardless of where in the directory structure
it (either one!) appears.
Therefore, the actual usage might resemble something like
8<------------------------------------------------------------
unit/add-unit-path %lib/ideas
>> foo: make object! [
[ red: 23
[ yellow: 48
[ caramel: unit/do %cmptest.r
[ ]
...
8<------------------------------------------------------------
which might imply that the file cmptest.r is in the lib/ideas
subdirectory under whatever is the standard library path (or
one of the standard library paths!) on the current box. Thus
the code above wouldn't change if I move to a different box or
platform with different library placement conventions (this,
of course, assumes that */lib/ideas/cmptest.r is in the "right"
library path for the other box/platform).
Comments, suggestions, alternatives, collaborators???
-jn-
