[REBOL] [Fwd: Re: RSL: Rebol Standard Library]
From: joel:neely:fedex at: 24-May-2001 7:40
Hi, Maarten, (or anyone who's interested...)
Here's the promised follow-on...
I apologize for the length of the introduction, which is
there for anyone who wonders why I don't just want to say
do http://some.server.org/name-I-found-by-magic.r
and hope for the best. ;-)
After the preamble, I give a hypothetical example of how
I imagine a shared library might work in practice. I am
proposing a usage story as a starting point for discussion
of the features that such a service/system would have. As
far as I am concerned, everyone's input is VERY welcome.
Let me make one request -- if anyone sees anything in the
ongoing discussion not to his/her taste, please feel free
to say so, BUT in the form of an explanation of why you
don't think something will work well, along with your
proposal of an alternate solution (i.e., positive and
constructive).
-jn-
Maarten Koopmans wrote:
> Proposal:
>
> Why not create the Rebol Standard Library (RSL)?
>
My perception is that, up to this point, code sharing in REBOL
has taken one of the two following forms:
1) Someone writes a "chunk" of REBOL code and places it in a
publicly-accessible place, including:
1.1) A single function definition in an email message.
1.2) A collection of related functions, defined in a
single source file, placed on an http/ftp server.
1.3) A collection of code, wrapped in an object to
protect the global namespace, placed on a server.
1.4) ...etc...
2) Someone "publishes" availability of a REBOL fragment,
function(s), object(s), or script(s) via the WWR. An
access to that published chunk causes it to be mirrored
by View in a subdirectory tree that is a combination of:
2.1) Where REBOL is installed on the local system,
2.2) Which RebSite offered the chunk, and
2.3) Where in the directory tree under that RebSite's
document root the chunk came from.
Neither of these provised a scalable solution to certain issues
that I think are critical success factors for a community
library:
a) A way to understand where to look for something;
b) A way to know where to look if the answer to (a) is not
available, overloaded, responding slowly, etc.;
c) A way to mirror locally just the parts of the library
that I need for a specific task;
d) A way to obtain quickly the parts under (c) that I need
for a specific task at hand;
e) A way to verify whether my local copy of stuff is up
to date, and to refresh any/only those that are not,
and to do so automatically;
f) A set of conventions that provide high confidence that
I can use a newly-obtained unit without:
f.a) Having to read the complete source to figure out
the (possibly unique) usage interface for that unit;
f.b) Having collisions in the global (or other...)
namespace;
f.c) Having to look elsewhere for appropriate docs.
As a concrete example (PLEASE NOTE: HYPOTHETICAL!) one could
use the following conventions, similar to those we discussed
in connection with UHURU
(Universal Home for Useful REBOL Units,
Unit Handling Utility for REBOL Users,
or whatever...)
Let's imagine that:
1) A local box can configure a directory as its "UHURU root"
directory. All source from the standard/shared/UHURU lib
lives in a directory tree under that root. Let's imagine
that on my box that directory is /usr/local/bin/reblib .
2) The directory tree matches the concept tree of the library.
3) I want to use a function from a published unit of text
file utilities: one that reads a tab-delimited file and
creates an HTML table from it.
4) To find that function, I browse an on-line description of
the concept tree and find that
/text/conversion/del-ascii-html
defines an object containing such a function, named
tdf-to-table
5) I go to an interactive console and enter
UHURU/install /text/conversion/del-ascii-html
Unknown to me, that source file depends on another unit
located at
/text/conversion/delimited-ascii
However, the install routine is able to determine that
fact from markup in the one I asked for, checks to see that
I do (or do not) already have it installed, and installs if
if necessary.
6) As a result of the installation, my local box now contains
the files
/usr/local/bin/reblib/del-ascii-html.r
/usr/local/bin/reblib/del-ascii-html.html
where the first is a usable code module and the second is
documentation for all of the functions it defines, samples
of usage, etc. (Any other depended-upon units are likewise
represented in the appropriate places.)
7) I am now writing code which needs that capability. Inside
one of my source files make-phone-book.r , I say
#!/usr/local/bin/rebol
REBOL [
; ... details omitted ...
]
make object! [
; ... more details omitted ...
tdf-tbl: UHURU/import del-ascii-html.r [tdf-to-table]
; ... etc ...
run: func [filename [string! file!] ...] [
print tdf-tbl/width to-file filename 600
...
]
run %dept-phones.txt
]
This creates the word TDF-TBL *within the context* of the
object I am defining. Neither TDF-TBL, nor anything that
the sourcefile del-ascii-html.r defines, nor anything that
del-ascii-html.r imports, are inserted into the global
namespace.
My subsequent code is now free to use TDF-TBL as an internal
function.
8) Some time later, I see an announcement on a mailing list that
there is a new version of del-ascii-html available that has
both a new, highly-useful refinement added to tdf-to-table,
and also adds three more nice functions. I go to a console
session and type
UHURU/update /text/conversion/del-ascii-html
after which the latest-and-greatest is on my local box. I
do this without fear, because:
8.1) All contributors agree not to break or remove functions
that are already in published units, therefore the
TDF-TO-TABLE function in del-ascii-html.r still does
what it used to.
8.2) Even though the new version contains more code, I am
only IMPORTing one function, therefore I don't worry
about code bloat. The ones I don't use don't show up
in my namespace. The fact that dependencies are
automatically resolved by INSTALL lets unit developers
build finer-grained units, instead of building giant
kitchen-sink files with every good idea piled in "just
in case".
8.3) Even though the new version contains LOTS of great
documentation and examples, I don't worry about taking
up run-time memory (or time to read through it),
because INSTALL splits all that stuff out of the down-
loaded file and creates the separate .html file above.
The .r file is now lean and mean.
I could go on imagining other usage stories, but that's more
than enough for now! Let me imagine, in closing, that the file
I download satisfies the implied requirements from above by
looking something like this:
<UHURU version="1.2">
<UHURU:unit name="del-ascii-html"
ver="2.1"
path="/text/conversion" />
<UHURU:keywords>
ASCII HTML comma tab convert text conversion
</UHURU:keywords>
<UHURU:depends-on>
/text/conversion/delimited-ascii
</UHURU:depends-on>
<UHURU:doc type="html" />
</UHURU>
<html>
<head>
<title>del-ascii-html: Delimited ASCII to HTML
conversions</title>
</head>
<body>
... lots of useful documentation ...
</body>
</html>
REBOL [
....
]
make UHURU/unit [
...
tdf-to-table: func [...][...]
...
]
which contains all the information and content to fulfill the
requirements of the imaginary story above. As alternatives,
the documentation could have been written in XML, using a set
of <UHURU:...> tags, which the installer expands into the
appropriate HTML, complete with standard formatting/boilerplate.
Of course, I'd expect for the MAKE-SPEC format to be supported
as well. ;-)
-jn-
