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

[ALLY] REBOL Modules Doc Re:(4)

From: agem:crosswinds at: 4-Aug-2000 0:08

--- [rebol--techscribe--com] wrote on 3-Aug-2000/10:44:46-7:00
> Hi Volker, > > you wrote: > >As far as i understand, modules have inheritance und > >autentification, but in another way: you can create > >a submodule IN the main-module, which inherits all > >bindings of its parent. then you can return this extended > >module on request. > > > > Regarding this the module documentation says: > > >Also note that like objects, > >modules can be nested to allow nested contexts. >
hm. first i expected the kind of nesting like in functions and today existing objects. a: -42 b: make object! [ a: 42 b: make object! [b: a] ]
>> probe b/b
make object! [ b: 42 ] like that. even if under discussion :) but, now i read in your way, yes.
> and the module documentation also says that: > > >>>>>>>>>>>>>>>>>>>>> > The new module architecture allows an enhanced context structure for REBOL > and its scripts. Scripts will no longer be bound by default to the global > frame (main-frame). Instead, scripts will be bound to a USER frame that is > created below the main frame. This allows entire scripts and all of their > functions and data to be garbage collected if they are no longer required. > This changes the binding process for scripts. The binder looks locally for > a word, then looks up the hierarchy for the name. If the word does not > appear anywhere in the hierarchy, then the module frame is extended with > the new word. Effectively, free variables become module local, rather than > global. > > The hierarchy of module contexts is now defined as: > > ROOT frame (natives, and C code references) > SYSTEM frame (most of the mezz functions) > USER frame (user script) > MODULE frame (sub-scripts or make modules) > When the USER module-option is used with MAKE, a peer frame is created to a > script. The new module is placed at the USER frame level, rather than at > the MODULE level. This allows you to create scripts that evaluate scripts > in pristine environments. (That is, in the same environment as your first > script.) > <<<<<<<<<<<<<<<<<<<<<
then a [make module![][] ] is more like a [make current-module![][]] instead of "make a new empty module and look for all other stuff in the current context"?
> Note the last paragraph about the USER module-option being used with make. > Since make supports the explicit assignment of USER as the parent module > for a newly created module, isn't it > > a) likely, > b) possible, > c) consistent, > d) desirable > > that the explicit make notation also permit that a module be declared as > the descendant of a module at a lower level than USER, and yet at a higher > level than the currently effective module context? >
for me this means: [do %file] will change. now it will have its own context. except i say "use mine", then it behaves like todays 'do : i get its new words in my context. At least i understand this in this way: " This allows you to create scripts that evaluate scripts in pristine environments. (That is, in the same environment as your first script.) "
> The notation I'm asking about is necessary to enable remote modules. With > respect to remote modules, it was late last night and I was rather > brain-dead when I read the module documentation and wrote my message. > > This morning I realized that we don't need a remote-module! type. > Notation-wise all we need is a url field in the module header. If REBOL > detects that a url field has been defined in the header, then that should > be sufficient for REBOL to realize that this module is intended as a > descendant module of the module defined at that url (where we expect a > REBOL process to be executing, which has evaluated the module we are > descending from). > > The evaluation of words that are not defined in the locally executing > descendant module are sent to the remote module (including their arguments) > for evaluation by the remote module in the namespace of the remote module, > using the physical resources available at the remote machine. >
i would prefer: send only the words. call for contents back. this would allow for easy callback-functions, like recursion between two contexts. it this way works ARexx, a server (spreadsheet) does what it knows and sends "questions" back. you could write [print/size/printer content :my-paper-calc-func] and get a call to my-paper-calc-func back :) handy. over the net, is this much slower?
> This would make for a very easy way of using specialized resources on a > remote machine (such as special graphic processors, or video compression > boards, etc.) Imagine a cell phone running REBOL and being able to make > full use of resources located on a remote machine simply by defining a > module with a url field that references the url of a remote machine > mainframe! ;-): > > cell-phone: make module! [ > title: "cell phone module" > url: > ][ > signup "me" "rebol-room" > chat > ] >
i would express this like [do/at [ signup "me" "rebol-room" chat ]] because i think make should make something new, while i see here a one-use-action in a specific context. but this is handy sometimes with objects, so why not with modules? maybe iam really wrong here. Carl says However, modules extend beyond objects in the following ways: , hm, no talking about restrictions.. the more i think about it, the more it makes sense.. Curious. Carl? :)