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

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