RSL: Rebol Standard Library

...

I submit that we need more than just "a standard library". Earlier this month, (8-9 May) we had a thread entitled Enabling the REBOL Community , which discussed the value to REBOL (the language, the company, and the community) of having the following: 1) A library of reusable code "units" 2) A standard taxonomy (e.g., logical structure) of such units. 3) Conventions for how the source code for such units should be structured. 4) Conventions for how such units are to be incorporated into new code under development. 5) Servers (plural!) which host identical copies of the entire library using the same taxonomic structure. 6) Client and server code that implements all of the above. I assume we want all of the above to be REBOL-centric. That means that -- by definition -- we reinvent some wheels in order to have REBOL-brand wheels. However, to avoid re-conceiving what a wheel *IS*, I recommend that we look at CPAN (and any other similar examples anyone wants to propose) for ideas on how the issues of functionality, communication, code base management, etc. might be addressed. I'll write a subsequent note to illustrate the kinds of question I suggest we address in (3) and (4).

I'm willing to participate in all of the above, although I have limited time to spend on actually administering a publicly-accessible server at the present. -jn-

I have a server with 100Mb space and 5Gb/Month transfer. Provided that we can get this to a point where the project would be a realisable concern, I can devote some time to the creation and maintenance of a "RSL" (or whatever) repositry on there. Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- The Scripture of the Master Programmer [Principals 1:64] If at first you don't confuse, explain again in opcodes.

I have a server with 100Mb space and 5Gb/Month transfer. Provided that we can get this to a point where the project would be a realisable concern, I can devote some time to the creation and maintenance of a "RSL" (or whatever) repositry on there. Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- The Scripture of the Master Programmer [Principals 1:64] If at first you don't confuse, explain again in opcodes.

language

I've noticed a few of the regulars are working for EDS. It is good to see such support for REBOL. Cheers, Allen K

For one, what exactly does this have to do with the subject? We were talking about a standard library of sources developed by the community, for the community. NOT open sourcing REBOL for goodness sake. Has anyone here even MENTIONED open sourcing REBOL recently? No. There have been complaints about the fact that the "free" on the website is not quite the free that most people understand it to be (ie: everyone thought "free" means "no charge, for anything" when it really means free for personal use ) and the licensing was changed without even telling the people using the language. But the whole issue of open source/GPL wasn't even a factor until it was mentioned by Holger. People had assumed /core was free as in free beer, no one has been yelling for RT to release REBOL as OSS for quite some time. All we need now is for someone to mention the nazis, at least then the whole thread can be considered dead.. Chris

whole thread can be considered dead.. I reckon someone should open source code Nazi party policy, and sell it for beer hall money... Andrew Martin ICQ: 26227169 [new Rebol/eText site soon!]

LOL! :))) Chris

First, one must make a crack about AOL, then the Nazi's. ;-) I can't speak for Paul but I suspect he just "replied" to the wrong thread. The RSL thread is an important thread that shouldn't be prematurely killed. --Scott Jones

Well said, Chris!

As far as the issues of a community-supported code library versus "open sourcing REBOL", I have to agree that I did nazi any relationship between them... OOOPS, I KILLED IT! ;-) -jn- -- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

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-

100% agreement up to this point. IMO <UHURU ...>..</UHURU> is not required - look at the REBOL header, we already have File (which is UHURU:unit name) and Version. By extending the header so we have, say, a standard like: REBOL [ Title: "del-ascii-html: Delimited ASCII to HTML conversions" Version: 2.1 File: %del-ascii-html.r .. other standard fields in here ... UHURU-Path: %/text/conversion/ UHURU-Keywords: ["ASCII" "HTML" "comma" "tab" "convert" "text" "conversion"] UHURU-depends: %/text/conversion/delimited-ascii UHURU-doc: %del-ascii-html.html ] This way scripts could use their UHURU (we really need a better acronym I'm afraid ;)) information as metadata and the header processing the UHURU handling scripts would need is already built into REBOL. I'd even suggest allowing UHURU-doc to be either a file, in which case the file is obtained, or the keyword "auto" in which case code like my reboldoc is used to extract the html documentation from the source itself (which IMO is a lot easier on the programmer, and thus more likely to be used properly - there's only one set of docs, the docs in the code, to maintain rather than two.) Chris

On that subject (no tm check done on these BTW..) ROAST - REBOL Open Access Script Toolkit ROSE - REBOL Open Script Extension NARSIL - Network Assisted Rebol ScrIpt Library Chris

In my desire not to inflict a war-and-peace email on the list, I left out some of the rationale... The reasons I've suggested the <UHURU ...>...</UHURU> part are: 1) I assumed we'd want to keep all of the library-related stuff *out of* the header, so as not to conflict with any plans or future developments RT may have/make with header content. 2) I assuemd we'd want to keep "meta-data" in the UHURU XML so that we could modify or expand it without worrying about that increasing load times of modules being utilized. (The meta-stuff would get stripped out by INSTALL, so that it wouldn't be in the .r file. 3) We already have PARSE-XML, so the effort to implement the <UHURU...> stuff should be minimal. 4) We might want to drive other tools (e.g., a keyword-search tool) with meta-data. By putting the <UHURU ...> stuff first, such tools could remain oblivious to all other content. 5) I assumed that a unit file would be maintained as a single file by the developer. There would still be only one place to go to perform ongoing modification on the code, docs, and meta-data.

StarTrek Classic fans everywhere are priming their flamethrowers! ;-)

Everything to parse the <UHURU...> stuff *is* already built into REBOL (see (3) above), but the manipulation of the content would be added code in any case. The advantage of XML over the REBOL header block is that we get a conventional syntax for complex data structures for free (assuming one already knows XML).

As mentioned above, I'd like to see if we can avoid burdening the loadable REBOL code with non-executable content, but at the same time make it easy to supply that *with* the code. For example, a page-long narrative on a non-trivial object, along with usage samples, would be quite a bit of overhead to read through just to load the object def itself, IMHO. Anyway, those were my assumptions and preferences. I'm certainly open to discussion leading to something we can all live with and use effectively. -jn-

Good points, especially that about versioning - the last thing we we want is to be the creators of out own "DLL Hell". As you say, allowing the required version to be explicitly specified is a very good idea, but I would say that we need a bit of flexibility, for example: - Requesting Foo vN.M will return exactly that version - Requesting Foo vN will return the latest revision of version N of Foo - Requesting Foo will return the latest revision of the latest version. If the specification of the system demands that revisions must be backwards compatible while versions do not need to be this will allow people to obtain the latest bugfix of a package without necessarily knowing the revision required. As for using cvs... As a unix programmer I'm all for that idea, but it would be conterintuitive for a lot of Rebolutionaries. cvs is not the simplest of systems for people to learn, and if this is to be a sucess I think it needs to be hassle free. A secondary problem is that setting up cvs to do this requires one or more cvs servers, keeping them all in synch could cause serious logistical problems. I'd suggest that a better solution would be a REBOL script to do all this: REBOL has all the facilities built in to do what we need, and there is no need for a special server: the files could be obtained from a webserver using read. This has the nice side effect that it would be possible to synch the mirrors very easily - there's no need to do checkouts and checkins all over the place. Something as simple as a couple of ftp sessions (or even a cron triggered script) could do it. Of course, this means we actually have to write this thing :) Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- If you're not very clever you should be conciliatory. -- Benjamin Disraeli

StarTrek Classic fans everywhere are priming their flamethrowers! ;-) I think her name was spelled differently:) Actually I think Uhuru means freedom in some African language. It was the rallying cry of the Zulu warriors when they were trying to expel Dutch colonialists...

From: "Grant Parks"

means

Zulu

From http://heasarc.gsfc.nasa.gov/docs/uhuru/uhuru.html ==== Uhuru, also known as the Small Astronomical Satellite 1 (SAS-1) was the first earth-orbiting mission dedicated entirely to celestial X-ray astronomy. It was launched on 12 December 1970 from the San Marco platform in Kenya. December 12 was the seventh anniversary of the Kenyan independence and in recognition of the hospitality of the Kenyan people, the operating satellite was named Uhuru, which is the Swahili word for freedom . The mission operated over two years and ended in March 1973. ==== Somehow Joel's acronym still seems appropriate, but hopefully the system will last longer than the satellite mission! --Scott Jones

I see. I was just exercising the REBOL equivalent of Occam's razor - all the features could be done using nothing but REBOL's internals. But if there are good reasons, as you outline here, an XML intro would serve the project better.

Wasn't that Uhura? (Not a ST fan so..)

Hmm.. we're getting into Holy War subjects here ;) I guess stripped versions would be good, but as a heavy commenter the idea of commentless code is somewhat abhorrent ;)) Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- There is only one thing in the world worse than being talked about, and that is not being talked about. -- Oscar Wilde

I guess here, too, I would have to add what I'm envisioning (Chris, get ready with the telepathic powers so that you can translation for the rest of the readers ;-). I can envision circumstances where commented versions would be nice and uncommented versions would suffice. I one example, if a no-computer-literate consumer/user is running an application that needs to go to the Internet to get some functional component from the standard library, comments, just like unused components, would only serve to diminish bandwidth. If an error occurs and the app dies, this user would not be likely to persue the code. However, like some, if I were developing an app that used this functional component, the comments would be very helpful (at least for a partially demented person like myself). <alert type="feature bloat"> I could envision a mechanism, perhaps a flag, where this hypothetical central server would deliver the correct version based on some configurable feature or flag. </alert> Poor Joel is probably thinking, why did I ever restart this thread. And poor Maarten is probably thinking that this could have all been done very simply through LDC. And poor Chris is thinking does this guy really think I can read his mind? I'm really not in the know like many of you, so please don't hesitate to ask me to be quiet for a few minutes (hours/days). ;-) Thanks for staying tuned. --Scott Jones

Uhura. Lame in-joke. Sorry.

Swahili, IIRC. That was actually the motivation for the name, as mentioned in the thread early this month. -jn-

LOL :))

In other words, keep two copies of the scripts on the server: one containing all the comments and code and one stripped version and indicate in the request which you require, for example: UHURU/install text/conversion/del-ascii-html devel to obtain the commented version. Leave of the devel and you just get the code withthe comments stripped. Maybe even UHURU/install text/conversion/del-ascii-html devel doc could be used to indicate that the development version and documentation should be installed, leave off the doc and you just get the commented code. Not bloat so much as redundancy. If there was a quick and easy way to strip comments from REBOl code, you could just get away with storing the commented version on the server: If a request came in for the stripped code you just run the file through the comment stripper as you send it. If a request came in for the development version you just send the file as is. If a request came in for the developer version + docs then you could send the file and then use a doc generator to generate the docs (unless they have been pre-written of course). (The logical fourth option is to obtain the uncommented code + docs - although I guess this is only attractive to Real Programmers (who probably wouldn't be using REBOL anyway)) In the absence of a fast and clean comment stripper though, storing both files plus an optional html doc would be the easiest, if rather wasteful, way to do this.

I missed this the first time around - I was too caught up in the license thread. I'll try to read through the discussion tomorrow at work, I don't have to pay by the second there! ;/

:) /me passes Scott a bottle of dried frog pills Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- Main's Law: For every action there is an equal and opposite government program.

LOL. Must be one of those uniquely British sayings. My sister has lived there 20+ years. I'll see if she has heard of it. =) --Scott Jones

Actually, what I was in my head (for those who can't read *MY* mind ;-) was a bit simpler, for some definitions of simpler ... I'm all for documentation, but I tend to view "comments" as covering (at least) three very different things: 1) internal comments about some implementation detail, useful for someone needing to understand the code itself, 2) the interface help/hints in function specs, useful for someone interactively asking for a reminder about the calling conventions, and 3) the kind of long-running-narrative-text descriptions that explain the intended usage of a library unit, including tutorials, examples, etc., useful to someone browsing the library or trying to understand usage of a unit, but not interested in the implementation details. I'd also observe that we *WANT* for (3) to be as big and detailed and feature-rich and example-laden as is needed to provide comprehensive, self-contained reference material. My imaginary description from earlier in the thread assumed that all of the above were present in the library unit file, but that (3) was in a separate section of the file, (instead of distributed throughout the code or contained within the REBOL header) so that the installation could split the file into the documentation part (browsable at will) and the loadable part (still containing whatever of (1) and (2) that the author deemed fit, but not containing the readme/reference/ etc. content of (3). It was a conjecture as to how to resolve these conflicting forces: 1) We want the loaded components to be lean and mean, 2) We want authors to be free to write as much reference material as necessary, 3) We want all of the above "in one place" at least for the purposes of deployment. -jn-

Am 24.05.01, 21:47:19, schrieb Chris <[chris--starforge--co--uk]> zum Thema [REBOL] Re: [Fwd: Re: RSL: Rebol Standard Library]:

I doubt she will, unless she reads Terry Pratchett's Discworld books. In them, the Bursar at the Unseen University (the university at which most of the disc's wizards are trained) is utterly insane. One of the wizards came up with the idea that they could make the Bursar sane by making him halucinate that he was sane, this is done using the dried extracts of a deadly poisionous frog given to him in pill form. Hence the bottle of dried frog pills ;)) Chris

This is a wonderfull stuff. Its kind of like doctoring in an "Alice and Wonderland" world. It also sounds like just the medicine I need! Thanks! I should call you Doctor Chris. --Scott Jones

This is a wonderfull stuff. Its kind of like doctoring in an "Alice and Wonderland" world. It also sounds like just the medicine I need! Thanks! I should call you Doctor Chris. --Scott Jones

I'm sorry, but I simply don't believe this. I've only dabbled in Smalltalk, but I've used Perl and Jave extensively (along with a couple of dozen other languages during my career). My experience is that I can write "Hello, world!" in a new language with almost no learning time. If the language has features targeted toward a specific application area, and I'm already familiar with that area, I can begin writing code for those applications with very little learning time. When I start doing things that either fall outside the "sweet spot" of the language, or that fall outside my own existing knowledge of the application domain, I have to invest the time to learn something. That's true whether the "something" is the notation of the language, the capabilities of built-in language features, or the capabilities of a library. Perl is a very "rich" language, in the sense that Larry Wall built a huge (some would say bewildering ;-) set of features into the syntax of the language itself. Smalltalk, Python, LISP, and (to some extent) C are very "sparse" languages, in the sense that the designers created very streamlined syntax and added features by defining libraries/classes on top of that simple syntax. FWIW, I see REBOL as lying closer to the "sparse" end of that spectrum than the "rich" end. But the punch-line is this: if I want to write sophisticated text-processing code... ...in this language... ...I have to learn this... Perl regular expression syntax C regular expression functions Python regular expression funcs/objs REBOL PARSE dialect In *ANY CASE* one may need to learn something. If one already knows other Unix/Linux tools, such as grep, AWK, etc. or has a Computing Science background, then the effort of learning RE syntax in Perl is simple. If one already knows BNF from a Computing Science background, then learning the PARSE dialect is relatively straightforward. (For people who have no background that supports either, I suspect that individual thinking/learning styles would *STILL* lead to different people having different experiences. And that's OK. We aren't all alike and we don't have to learn alike.) As for the "years..." part, I don't believe that either. I usually learn a new language in a situation where there's something I want to be able to do and I believe that the new language offers some benefit(s). I usually find that, if my choice of language is a reasonable fit for the task, that I can learn enough of the language to get the job done fairly quickly. If that experience is pleasant enough, I keep expanding my understanding of the language by using it for a progressively wider range of application. All along the way, with each significant language I've ever learned, I find little moments of "enlightment" when something clicks into place and my insight into the language, its world view, and its usage will take a little quantum leap. But don't tell me it takes "years", because I know better. Been there, done that. Many times. Of course, if you try to take a language too far out of its comfort zone, there's no amount of experience that will make the task easy. Don't ask me to be productive while writing an XML parser in COBOL! ;-)

That statement has enough truth in it to be severely misleading. I think it's A Good Thing for a language to have a "gentle slope", so that you can quickly learn enough to begin using it. But I flatly reject the notion that this is sufficient for all situations and tasks. Example 1: Have you ever used REBOL to work with XML data? If so, did you write your own XML parser, or did you just (as I did) say something like content-block: parse-xml read %somefile.xml and then proceed with the task of doing something useful with the data in the content block? To parse XML in REBOL, you need only REBOL and inspiration. But you can get on with the job *MUCH* faster if you call on PARSE-XML as a "black box" and use its output, than if you embed in each application a hand-written one-of-a-kind XML parser written with PARSE. Example 2: Have you ever used REBOL to create a graphical user interface? If so, did you create your own interface totally out of View primitives, or did you use the VID? To create graphical user interfaces in REBOL, you need only REBOL and inspiration. But you can get on with the job *MUCH* faster if you can use VID to put together an interface out of standard components, than if you hand-craft a totally inspired and creative approach to human interfaces for each application you write. It's fun to try to create new things. The effort often leads to useful learning as well. It's also true that exploratory programming is a critical part of the process of creating code that ends up being worth sharing and/or re-using. But there's also a legitimate role for getting things done by plugging together existing components that work well enough together, and then moving on to the next task.

I must again take exactly the opposite view. If we fail to offer the newcomer to REBOL a large collection of existing code (both for the purpose of study *and* for immediate black-box re-use) then we condemn him to the task of building everything for himself from first principles. Such a task is much more suited to "highly skilled experts" than to everyday users. In fact, there *is* a start on such a collection already; it lives in the email archives, on various volunteers' web sites, in the published books, tutorials, and documentation, and (of course) on the World-Wide Reb. All I am proposing is that some of us, and especially the potential audience of newcomers to REBOL, would see benefit in having this collection pulled together in one place and made simpler to search, access, and use (or re-use). I do *not* suggest that everyone has be required to use it, but I strongly feel that to prohibit its use on the basis of some people's religio-philosophical positions or preferred coding styles would pose an unnecessary limit on the growth and acceptance of REBOL among those who don't have the time, skills, or patience to recreate everything for themselves.

All of those are interesting ideas (especially from a guy who didn't want lots of server-side stuff! ;-), and most or all of them are compatible with what I was trying to propose for UHURU. I'll be glad to discuss any of them in as much detail as you (or anyone) would like, and would be delighted to see them available to work with UHURU. However, I'll close with two observations: 1) The "core" of UHURU would, IMHO, be far easier to get up and running that the list above, and 2) Adding a reasonable amount of conventions regarding format and documentation would, IMHO, make all of the above more easy and effective.

And finally, remember what Sir Isaac Newton said, (here I'm quoting from memory, so please forgive any inaccuracies) If I have seen farther than others, it is because I have stood on the shoulders of giants. If learning and re-using ideas from others was good enough for Sir Isaac, it's certainly good enough for me. If the effort to create an accessible library makes it possible for newcomers to REBOL to stand on the shoulders of coding giants such as Carl, Allan, Petr, Ladislav, yourself (and I'll stop here with apologies for not having time to list everyone I'd like to!), then I'll be quite satisfied with the achievement. -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

So THAT is what that all day meeting was about! (:

As usual, Joel, your command of the language is awesome, and your grip on the important issues for the community is firm. I think you are on target with the basic goals of the proposed project. Chris is doing a great job of clarifying, interpolating and syncing all the helpful comments. I guess all that's left for me is to kibitz from the side-line. ;-) Like Volker, I tend to do a lot more cutting and pasting from example code so that I can tweak to do my own thing. But I do think that your ideas, Joel, and the compilation of ideas by and from Chris are on target with the more generally beneficial central repository. In my sleep-deprived ramblings yesterday, I did not intend to imply that the central server(s) needed to be smart, per se. I meant that taking the system as a whole, it would be nice to have control of some of these abilities. Maybe some of what I was suggesting would be better served as suggestions for future REBOL module/package distribution/control methods (REBOL/* 3.*). I just wanted to toss out the ideas, so that those who actually know the backs of their hands from the fronts could chew on the ideas (do lead paint chips and dried frog pills cause mid-life dyslexia?). It sounds like this has been happening. Good! Meanwhile I just need to figure out how to stand on the *ground* before I can worry about standing on the shoulders of giants! ;-) --Scott Jones

Am 25.05.01, 15:04:46, schrieb Joel Neely <[joel--neely--fedex--com]> zum Thema [REBOL] Re: [Fwd: Re: RSL: Rebol Standard Library]:

Not so much, but you express them better ;-) oh, did i say its very inspirating :)

Hm, well i read it sometimes. IIRC carl said something before going productive in smalltalk one has to learn all the collections and how they work together. This compared to similar powerful series.

hm.

parse string [thru »this« copy gimme to »that«] is usefull. »How are the dotsused in RE? Ups.«

»perl? Arg? No, never understand! - rebol? Ups, i write a script i use?!« notes on the HP. I try to talk about the first language ;-)

Yes, it did that :)

Yes yes yes yes ! 'parse and 'view ! :) i never wanted to talk about language without library. I even think the library is the more important part often. But i read and experience building good libraries is a very much harder part than special purpose code, because with SPC you know what you want, with libraries/frameworks you dont. (calling »the programmer« »you:) And function is only one part, usability is another. You try to anticipate what it will be use for, and that needs experience, experience and talent (i read:). Carl has it. I like to find functions quick and tell my stuff with few words. Dialects have no other use than helping that in a way ;-) I think the core-libraries should be build in and carefully balanced against each other, and cover the really important parts. If it can't do that, and i have to work with perl-like »collect your system first«, a large part of Carls promises failed. Maybe not bad, but not really rebol..

Want to mention the white-box-reuse. If i look in the library there are some of Carls scripts which have an example-section on the end which one has to outcommend before use. Making this an option would need if not args/no-example[ ... ] and thats the crux with black-box: you have to code much more options, and they bloat the code clarity, where a single char patch would be sufficient. And, having customized a script for use gives a good feeling specially to beginners (its another cake for a kid if it was involved with baking). I think »you can touch it« is a good message for rebol :)

Yes. hm. Maybe more in form of a story? Iam clicking the easy..'s here, small examples which are presenting a lot of ideas. I had read them quick, and after that i suddenly had known how to use vid / draw . That could cover some related scripts with examples and sandbox. Think about an easy-cgi with embedded webserver, some cgi's from the script-lib and an editor where they can be changed. Edit the html, start the browser, »wow! Iam programmer! A, mythical cgi simple gets the »?«part of the url? :)«. Instead of »i know i want something like this« - search? You know, beginners..

Hehehe, lets play rebol-gods :) i would say »to recreat, find or understand«. And the last two are growing easy if there is nobody skilled enough to collect, refactor and compress them. no, the general creation has do be done by rebol.com. We pay them for that ;-) IMHO our level should be more to give examples instead of to give solutions. Well, it may even be dangerous to establish second-class solutions while Carl hesitates a bit having the perfect solution somehow in mind«, but then has to stay compatible to lib-apis? ;-)

can't be go friend with automatic hidden install/update to users. Want to have all stuff visible. Having a place to get and collect a current developer-version would be fine. But the embedding in applications should be made by hand. And placed on my disk/server/.. . Ah yes, and the sandbox..

If well done, yes. Btw i would stay heavy on rebol & scriptheader, instead of XML (who mentioned that?). After all, to XML can translate a litte script..

Even giants Newton and - ahem, was it Gauss? *sigh* had dialect-problems about the right way of integrals-«apis« :) so the right way to say the basics seems to be really a giants job. And a »standard library« needs a lot of giants farth-seeing. I would prefer creating »standard examples« instead of »standard libray«. hm. what will i say with this?! Well - .. Volker

Am 25.05.01, 14:03:56, schrieb Joel Neely <[joel--neely--fedex--com]> zum Thema [REBOL] Re: [Fwd: Re: RSL: Rebol Standard Library]:

Sorry for the sound. Iam not an native english writer and was more thinking than writing, partly trying to confirm me to myself ;-)

Hm, we agree here to. I try to avoid version-conflicts by copying the script to my project-directory, ignoring updates sometimes, but avoiding hidden code-breaks (i have only to obey core rebol changes). If i apply an update, iam very used to visual diffs, like mgdiff on linux or windiff. Thats a surprising efficient way to see what has changed, and mix my changes with updates. Also rebol is short and says a lot »between the lines«, so it is more efficient to write an »open« script with some places to edit by the user, then to generalize, blackbox and add all the usefull options. You see, in rebol we often answer to »how can i do« with »look at [source send]«, where we otherwise (java, perl) would talk about api-secrets. And this »open« scripts have to be changed by me..

-volker