Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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 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-