This topic needs to address legal issues such as copyrights, licenses etc.
Are all modules free?
TBrownell
----- Original Message -----
From: "Ryan Cole" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 09, 2001 10:58 AM
Subject: [REBOL] Re: Enabling the REBOL community
> I was just thinking about this over the the weekend, almost exactly as you
have written Joel. I was amazed to read your post. The simple make object!
idea is
> what I came up with too. I strongly agree that such a system would
especially benifit our community.
>
> I really would like to know RT's time frame for the release of thier
module system.
>
> --Ryan
>
>
> Joel Neely wrote:
>
> > 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-
> > --
> > To unsubscribe from this list, please send an email to
> > [EMAIL PROTECTED] with "unsubscribe" in the
> > subject, without the quotes.
>
> --
>
>
> Ryan Cole
> Programmer Analyst
> www.iesco-dms.com
> 707-468-5400
>
> "I am enough of an artist to draw freely upon my imagination.
> Imagination is more important than knowledge. Knowledge is
> limited. Imagination encircles the world." -Einstein
>
>
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
>
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
