[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: http://www.rebol.com:6130/chat-server-module/
> ][
> signup "me" "rebol-room"
> chat
> ]
>
i would express this like
[do/at http://www.rebol.com:6130/chat-server-module/ [
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? :)