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

UHURU unit structure

 [1/10] from: joel::neely::fedex::com at: 28-May-2001 10:36


More concrete, less philosophy! ;-) I'm working on a prototype of the UHURU client-side code today (this being a US holiday), but thought I'd pitch out a couple of ideas, to be followed by demo code Real Soon Now ;-) I propose that the "working code" portion of an UHURU unit *always* have the following structure: REBOL [ ; header data to be discussed later ] make object! [ ; the usual stuff... ; *without any* SET referring to external words ] and that one *always* incorporate an UHURU unit via one of the two following means (layout/whitespace choices optional): my-obj-name: UHURU/make unit-name or my-func-1: my-func-2: my-func-n: none ; or other null value, ; later followed by set [ my-func-1 my-func-2 my-func-3 ] UHURU/import unit-name [ unit-func-1 unit-func-2 unit-func-n ] Why???? Namespace collisions are a monumental pain in code reuse. The simplest way to avoid any such collisions is for each unit to be an object that *NEVER* messes with any namespace except its own, IMHO. Both of the above mechanisms are based on the assumption that a unit is an object. In addition, both of these mechanisms allow the user of a unit to "place" words based on the unit wherever (s)he wishes in the local code under development. I trust the first is obvious, as it is based on the idea that a unit defines a conventional REBOL object. The second is based the idea that a unit could represent a function library of conceptually-related functions which don't seem to be methods on a conventional REBOL object. For example, authors might define a sets of functions for 1) hyperbolic trigonometry, 2) html generation, 3) various standard check-digit calculations (UPC/EAN, ISBN, ABA, etc.), 4) (I'm sure you can think of others...) There's some reasonable likelihood that each of the above groups contains functions that may share implementation code, may be used within the same user's local program, or both. This means that it's A Good Thing to have them packaged together. However, there's no "thing" which holds state that methods are working against, hence there's no benefit to forcing the down-stream programmer either to think in terms of an object, nor to have to repeat prefixes over and over as in: hyp-trig: UHURU/make hyperbolic-trigonometry a: hyp-trig/sinh x b: hyp-trig/cosh y c: hyp-trig/tanh z ; and so on To accomplish IMPORT, UHURU could perform the following steps: 1) make a working copy of the unit's object, 2) verify that the supplied list of words to be IMPORTed are actually defined within the unit's object, 3) return a block of values associated with each IMPORTed word (as defined within the unit's object). It's up to the user of the unit to set those values wherever (s)he wishes. -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [2/10] from: agem:crosswinds at: 29-May-2001 1:35


(Was kicked of the list, so escribe-copy)
>-->
From: Joel Neely Date: Mon, 28 May 2001 08:45:50 I propose that the "working code" portion of an UHURU unit *always* have the following structure: REBOL [ ; header data to be discussed later ] make object! [ ; the usual stuff... ; *without any* SET referring to external words ] <--< sounds like something as http://jove.prohosting.com/~screbol/reb/ctx-contexter4.r to me? With some work?
>-->
and that one *always* incorporate an UHURU unit via one of the two following means (layout/whitespace choices optional): my-obj-name: UHURU/make unit-name or my-func-1: my-func-2: my-func-n: none ; or other null value, ; later followed by set [ my-func-1 my-func-2 my-func-3 ] UHURU/import unit-name [ unit-func-1 unit-func-2 unit-func-n ] <--< suggestion: (replace [do %file.r] with [UHURU/make unit-name] if you want) [REBOL [title: {uhuru-import, one line}] save/header %lib-demo-obj.r [ context [ f1: "f1" f2: "f2" ] ] [] obj2: context [ import: func [words src] [set words reduce bind/copy words in src 'self] test-obj: do %lib-demo-obj.r f1: none ;may be automatic using something like contexter import [f1] test-obj ] ? obj2 ]

 [3/10] from: g:santilli:tiscalinet:it at: 29-May-2001 14:32


Joel Neely wrote:
> Namespace collisions are a monumental pain in code reuse. > The simplest way to avoid any such collisions is for each > unit to be an object that *NEVER* messes with any namespace > except its own, IMHO.
make object! [ f: func [a] [ b: a + 1 ] ] We really need modules, eh? :-) Or just: make-module [ ; *every* set-word found here will be made "local" ] make-module/global [a b c] [ ; *every* word except 'a, 'b and 'c is "local" ] It wouldn't be too difficult to implement IMHO.
> However, there's no "thing" which holds state that methods > are working against, hence there's no benefit to forcing
<<quoted lines omitted: 5>>
> c: hyp-trig/tanh z > ; and so on
Also, doing so would force REBOL to do a dynamic lookup, so it could slow down things in some cases. (Of course, the user could always export them manually, like: sinh: get in hyp-trig 'sinh but why not doing it automatically then?)
> It's up to the user of the unit to set those values wherever > (s)he wishes.
or even better, using a dialect: import-module some-module [ exporting [a b c] exporting [d e f] as [g h i] exporting this as that ] My two cents, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [4/10] from: joel:neely:fedex at: 29-May-2001 9:50


Hi, Gabriele, Gabriele Santilli wrote:
> We really need modules, eh? :-) >
It would be nice, but I'd rather proceed based on what we can do now than wait for it.
> Or just: > make-module [
<<quoted lines omitted: 4>>
> ] > It wouldn't be too difficult to implement IMHO.
I'm willing to start with convention, and then figure out if we need the extra layer in the implementation. I'd rather keep the list of dependencies as small as possible, at least at first.
> but why not doing it automatically then?) >
My thoughts exactly.
> > It's up to the user of the unit to set those values wherever > > (s)he wishes.
<<quoted lines omitted: 4>>
> exporting this as that > ]
That would be a nice extension also. -jn-

 [5/10] from: agem:crosswinds at: 29-May-2001 20:07


>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 29.05.01, 13:32:33, schrieb Gabriele Santilli <[g--santilli--tiscalinet--it]> zum Thema [REBOL] Re: UHURU unit structure:
> Joel Neely wrote: > > Namespace collisions are a monumental pain in code reuse.
<<quoted lines omitted: 7>>
> ] > We really need modules, eh? :-)
the trick here is to change the script. This can be done automatic, as long as the human knows how it works. With my contexter you would write the script with the function and it would create the object with all locals (and some overhead i found handy.) It creates a %ctx-script.r from a %script.r . it looks for set-words, [set 'word], [set [a b]] and [parse s[copy piece]]. Can be extended. It uses the header-entry [confusing: [words]] for words which could be local, specially [parse s[copy piece]] and [a: copy first b] are confusing. Also it has a list of rebol-words, build from a clean rebol. It warns if a selected local is in this list, giving chance to copy this in confusing. (but shows that on console yet, ugh). Exporting the interesting words to global context is also supported, there is a 'dial in the object to do this. Header-entry [export: [words]] For me thats handy, working on console, [ed/dial] and i have the usefull editor words there. Not as good as real modules, but handy. Till now only personal used, needs some feedback for docu, better names, and so on..
> Or just: > make-module [ > ; *every* set-word found here will be made "local" > ]
note 'copy in a 'parse is like a 'set, easily overlooked.. but not in usual code..
> make-module/global [a b c] [ > ; *every* word except 'a, 'b and 'c is "local" > ] > It wouldn't be too difficult to implement IMHO.
Mentioning happily again ;declare in the importing object import: func [words src] [set words reduce bind/copy words in src 'self] ;then import [want this and that] the-other-object :) (would need handling in contexter then similar to set..)

 [6/10] from: g:santilli:tiscalinet:it at: 30-May-2001 13:55


Joel Neely wrote:
> > Or just: > >
<<quoted lines omitted: 14>>
> need the extra layer in the implementation. I'd rather keep the > list of dependencies as small as possible, at least at first.
I agree. It's just that a user might feel safe not to trash the global context because he's inside an object, but this is not true. If we really want to avoid name clashes then we have to do that (thin) extra layer; otherwise, we're leaving all up to the user, just exactly as it is now --- which is not necessarily bad, but which was not our objective, was it? Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [7/10] from: g:santilli:tiscalinet:it at: 30-May-2001 14:38


Volker Nitsch wrote:
> the trick here is to change the script. > This can be done automatic, as long as the > human knows how it works.
Exactly my point. I'm just suggesting to let BIND do the change for you. :-)
> With my contexter you would write
[...] It looks nice; I'm sorry I din't have the time to check it yet...
> note 'copy in a 'parse is like a 'set, easily overlooked.. > but not in usual code..
Yup, I was going to suggest making ALL words (excepts a given list) local, but then it would be quite uncomfortable. Your idea of parsing the code might be a solution, but it is not general enough. (You'd have to keep ALIAS in consideration, or even worse MY-SET: :SET; also, I could be using a dialect where SET means something totally different...) Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [8/10] from: joel:neely:fedex at: 30-May-2001 8:11


Gabriele Santilli wrote:
> Joel Neely wrote: > >
<<quoted lines omitted: 9>>
> which is not necessarily bad, but which was not our objective, > was it?
Two quick thoughts... 1) The idea behind the every-unit-makes-an-object convention was just to standardize on something that would *allow* the user to place words in whatever context (s)he wished. The IMPORT mechanism was just a small assistance to that end. This certainly doesn't add any fundamental new capability to REBOL, but removes one more weak excuse not to play well with others ("I wasn't sure how ...") It also was intended to minimize the run-time overhead of using code provided by units. 2) The choice of the word "layer" was deliberate, and intended to recall the idea of protocol stacks. If we build the basics of UHURU (e.g, the INSTALL, MAKE, IMPORT for clients and some simple conventions for servers) we can always provide thicker walls and new utilization methods as later upgrades based on real experience with using UHURU. Alternately, we can pursue those discussions (among the users -- and with RT participation I hope!) in parallel to the discussion/development of server/transport/client stuff. -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [9/10] from: agem:crosswinds at: 30-May-2001 16:05


(list-kickoff again.. thanks for escribe :)
>->->->
From: Gabriele Santilli Date: Wed, 30 May 2001 05:40:30 Volker Nitsch wrote:
> the trick here is to change the script. > This can be done automatic, as long as the > human knows how it works.
Exactly my point. I'm just suggesting to let BIND do the change for you. :-)
> With my contexter you would write
[...] It looks nice; I'm sorry I din't have the time to check it yet...
> note 'copy in a 'parse is like a 'set, easily overlooked.. > but not in usual code..
Yup, I was going to suggest making ALL words (excepts a given list) local, but then it would be quite uncomfortable. Your idea of parsing the code might be a solution, but it is not general enough. (You'd have to keep ALIAS in consideration, or even worse MY-SET: :SET; also, I could be using a dialect where SET means something totally different...) <-<-<-< we could make the object and check by living context, which words are bound to global context? Checking against a list of rebol inbuilds, all words wich are not there are made automatic local? Inbuilds are trappt while debugging with 'protect-system. This gives of course no warranty, but as Larry Wall would say: rebolers are a polite society, they could break contexts, but they would try not to do so. So with good analysing tools for help most scripts should be ok? Currently we have - parsing like %nonlocal.r / contexter, some other. Contexter is extensible in principle, so if one knows he does [MY-SET: :SET],, he could patch his copy to know that. - running script and compare global context before/after - maybe the method above?
>->->
Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/ <-<-<-< -Volker

 [10/10] from: g:santilli:tiscalinet:it at: 30-May-2001 17:23


Volker Nitsch wrote:
> we could make the object and check by living context, which > words are bound to global context?
Yes, it could be done easyly with QUERY.
>> query/clear system/words
== [end! unset! error! datatype! context! native! action! routine! op! function! object! struct! library! port! any-type! any-word!...
>> context [a: 1 b: 2 do [c: 3]] >> query/clear system/words
== [c] Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted