[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: http://www.rebol.com:6130/chat-server-module/
][
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
http://www.REBOLpress.com
visit me at http://www.TechScribe.com
