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

[ALLY] REBOL Modules Doc Re:(3)

From: rebol:techscribe at: 3-Aug-2000 10:44

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.
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.) <<<<<<<<<<<<<<<<<<<<< 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? 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. 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 ] Looks quite useful to me! ;- Elan [ : - ) ] author of REBOL: THE OFFICIAL GUIDE REBOL Press: The Official Source for REBOL Books visit me at