[ALLY] REBOL Modules Doc
[1/13] from: carl::rebol::com at: 31-Jul-2000 13:24
--=====================_951290263==_
Content-Type: text/plain; charset="us-ascii"
Jim just reminded me that I promised to say a few words about REBOL Modules here on the
ally list. I'll do better than that: Here's a short document that describes REBOL modules.
Take a look.
-Carl
--=====================_951290263==_
Content-Type: text/html; charset="us-ascii"
Content-Disposition: attachment; filename="modules.html"
<html><title>REBOL Modules
</title><body><font face="arial,helvetica"><h2>REBOL Modules
</h2></font><p><b><pre> REBOL Enhancement Proposal: REP002
Version: 1.0.1
Author: Carl Sassenrath
</pre></b>
<HR><P><font face="arial,helvetica"><h3>Contents:</h3></font><p><blockquote><font face="arial,helvetica"><B><A
HREF="#section-1">1. Overview
</A><BR><A HREF="#section-2">2. Context Binding
</A><BR><A HREF="#section-3">3. Creating Modules
</A><BR><A HREF="#section-4">4. Module Hierarchy
</A><BR><A HREF="#section-5">5. Module Reflection
</A><BR></B></font></blockquote><HR><A NAME="section-1"></A><p><font face="arial,helvetica"><h3>1.
Overview
</h3></font><p><blockquote>A REBOL module is an independent context - a namespace. Modules
are
similar to objects in that they associate variables with values.
However, modules extend beyond objects in the following ways:
<p>
<ul><li>You cannot access the variables of a module unless they have been
explicitly exported nor can you access the word list of a module (as in the
first of an object).
<p>
<li>Modules include descriptive blocks that define the module title, date,
version, and other reflective information.
<p>
<li>You can create modules that act as a global environment, shielding
the words above it from direct access.
<p>
<li>Your scripts can be defined as modules. This is specified by script
headers.
<p>
</ul>Also note that like objects, modules can be nested to allow nested
contexts.
<p>
Modules should not be confused with components, which are the plug-in
feature-sets of REBOL. However, a component may include one or more
modules.
<p>
</blockquote><HR><A NAME="section-2"></A><p><font face="arial,helvetica"><h3>2. Context
Binding
</h3></font><p><blockquote>The module design allows for varying degrees of context binding.
You can
control how free words (non-locals) are bound.
<p>
<blockquote><table cellspacing=0 border=0><tr><td valign="top" width="80"><B>Strict</B></td><td
valign="top">Bind every word to the local frame. The binder will extend
the local frame as much as necessary to hold all words. The module
is completely encapsulated.
</td></tr>
<tr><td valign="top" width="80"><B>User</B></td><td valign="top">Every word that is not
defined in a previous context will be
bound to the local context. This allows users to get to REBOL's
predefined words but have all new words bound to the local context. This
is how most scripts will operate by default.
</td></tr>
<tr><td valign="top" width="80"><B>Explicit</B></td><td valign="top">An explicit list
of local words is provided for the module.
All other free words will be bound to previous frames.
</td></tr>
<tr><td valign="top" width="80"><B>Implied</B></td><td valign="top">Words that use SET
notation at the top block level of the
module will be local. All other are bound above. This is the same as
object instance variables. This is the default for the MAKE module
function.
</td></tr>
</table></blockquote></blockquote><HR><A NAME="section-3"></A><p><font face="arial,helvetica"><h3>3.
Creating Modules
</h3></font><p><blockquote>Modules can be created with either the MAKE function or by
evaluating
scripts that contain module words in their headers.
<p>
To create a module with MAKE, you must supply a module interface
specification block and a body block. The MAKE has the general form:
<p>
<b><pre> new: make spec body
</pre></b>
The value returned from MAKE is the new module and it can be assigned
to a variable, passed to another function, or returned as the result
of a function.
<p>
<p><font face="arial,helvetica"><i><h4>3.1. Interface Specification
</h4></i></font><p>The specification block is a header that is similar to that used with
scripts. It contains a title, date, version, author, and other fields of
a header. In addition, there are fields that are unique to modules:
<p>
<blockquote><table cellspacing=0 border=0><tr><td valign="top" width="80"><B>export</B></td><td
valign="top">Provides a block of words that define the variables that can be
accessed externally from the module.
</td></tr>
<tr><td valign="top" width="80"><B>import</B></td><td valign="top">Provides an optional
block of imported words. When this block
has been provided, no external words are bound within the module other
than those that have been specified. This allows you to limit the
module's access to REBOL functions.
</td></tr>
<tr><td valign="top" width="80"><B>local</B></td><td valign="top">Specifies an optional
block that explicitly defines the local
variables of the module. If this is not specified, then the local
variables will be defined by their top level block set operations (as
done with objects).
</td></tr>
<tr><td valign="top" width="80"><B>module-options</B></td><td valign="top">special flags
used to control the level of binding for
the module. For instance, the LOCAL attribute forces free variables that
are not bound in any frame to be bound in the module, not bound in parent
contexts. The USER attribute makes the module a top level frame (like a
user frame).
</td></tr>
</table></blockquote>Here is an example of a simple module definition:
<p>
<b><pre> example: make module! [
title: "Example module"
version: 1.0.0
export: [do-it]
][
data: [block of local data]
do-it: does [probe data]
]
</pre></b>
The do-it function can now be called with:
<p>
<b><pre> example/do-it
</pre></b>
But, you cannot access the data. This line would cause an error:
<p>
<b><pre> example/data
** Script Error: Invalid path value: data
** Where: example/data
</pre></b>
<p><font face="arial,helvetica"><i><h4>3.2. Scripts as Modules
</h4></i></font><p>For convenience, a script can also be defined as a module. This is
done
by specifying the module description as part of the script header:
<p>
<b><pre> REBOL. [
title: "Script Module"
version: 1.0.0
module: 'script-module
export: [do-it]
]
...
</pre></b>
When the script is evaluated, it will be evaluated as a module. All of
its free words (globals) will be local to the module.
<p>
<p><font face="arial,helvetica"><i><h4>3.3. Variable Definitions
</h4></i></font><p>Within a module, variables are defined as module-local in the same
way that objects define their instance variables. You can write:
<p>
<b><pre> make module! [export [a]] [
a: b: c: d: e: f: none
...
]
</pre></b>
You can explicitly declare the variables that are local to a module
(but you will also need to remember to maintain this list!):
<p>
<b><pre> make module! [export [a] local [a b c d e f]] [
...
]
</pre></b>
All such locals will be set to NONE when the module is created.
<p>
Of course, if the LOCAL module-option is used, then all variables will
be bound locally other than those that are explicitly imported.
<p>
</blockquote><HR><A NAME="section-4"></A><p><font face="arial,helvetica"><h3>4. Module
Hierarchy
</h3></font><p><blockquote>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.
<p>
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.
<p>
The hierarchy of module contexts is now defined as:
<p>
<b><pre> 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)
</pre></b>
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.)
<p>
<b><pre>
</pre></b>
</blockquote><HR><A NAME="section-5"></A><p><font face="arial,helvetica"><h3>5. Module
Reflection
</h3></font><p><blockquote>You can obtain the header specification of a module with the
FIRST
function. This will return the header as was used to define the module.
This also allows you to reflectively determine what words are exported by
a module. You can use this to automatically generate documentation about
a module.
<p>
<b><pre> foreach word get in first module 'export [
print word
]
</pre></b>
</blockquote>-End: Makespec 1.4.0</body></html>
--=====================_951290263==_--
[2/13] from: petr:krenzelok:trz:cz at: 31-Jul-2000 23:28
[carl--rebol--com] wrote:
> Jim just reminded me that I promised to say a few words about REBOL Modules here on
the ally list. I'll do better than that: Here's a short document that describes REBOL
modules. Take a look.
>
> -Carl
>
Carl,
sounds very promissing, although it will last a little bit to swallow the concepts. Will
next official release of REBOL support modules already (e.g. /View beta 5)?
btw: you are using 'variables name often, although you are using 'words name too. Is
there any difference or are we just still talking "words"?
btw2: as for garbage collector - how are modules "unloaded"? by 'unset modulename ?
Thanks,
-pekr-
[3/13] from: robert:muench:robertmuench at: 1-Aug-2000 0:15
> -----Original Message-----
> From: [carl--rebol--com] [mailto:[carl--rebol--com]]
> Sent: Monday, July 31, 2000 10:25 PM
> To: [ally--rebol--com]
> Subject: [ALLY] REBOL Modules Doc
> Here's a short document that describes REBOL modules. Take a look.
Hi Carl, what's makespec (I expect it to be a Rebol script)? Was it
every released? Robert
[4/13] from: allenk:powerup:au at: 1-Aug-2000 8:00
Q. Could security be handled in a module by module basis too? Something like
...
A default user level secure applied to all modules unless there is a
specific secure entry in the module header. Then by using a secure entry in
the module header, we can be more specific. So we could give full access to
file mod we trust without giving the same level of access to an untrusted
mod.
;default user level secure [net allow file [allow read ask write ask
execute]
files: make module! [
title: "File Access module"
secure: [net allow file [allow read allow write allow execute]
][...]
testing: make module! [
title: "Untrusted Mod"
secure: [net ask file [ask read ask write ask execute]
][...]
Cheers,
Allen K
>Jim just reminded me that I promised to say a few words about REBOL Modules
here on the ally list. I'll >do better than that: Here's a short document
that describes REBOL modules. Take a look.
[5/13] from: al:bri:xtra at: 1-Aug-2000 15:13
Carl wrote:
> Jim just reminded me that I promised to say a few words about REBOL
Modules here on the ally list. I'll do better than that: Here's a short
document that describes REBOL modules. Take a look.
It's nice, clean and simple. It looks to be a very clean way to
enhance/extend Rebol with your own scripts.
Andrew Martin
ICQ: 26227169
http://members.xoom.com/AndrewMartin/
[6/13] from: allenk:powerup:au at: 1-Aug-2000 23:18
[7/13] from: rebol:techscribe at: 3-Aug-2000 1:07
Hi Carl,
I like your module specification. It appears to be a useful tool for
complex scripts. A few questions.
A) Inheritance
Question 1:
Given your example:
example: make module! [
title: "Example module"
version: 1.0.0
export: [do-it]
][
data: [block of local data]
do-it: does [probe data]
]
do modules support inheritance like objects:
example-2: make example [
title: "Example 2 module"
version: 1.0.0
export: [do-it-as-well]
][
data-2: [block of additional data]
do-it-as-well: does [probe data probe data-2]
]
a) Can I now say:
example-2/do-it
b) If a module can inherit a parent module, what kind of permissions are
effective for the descendant module?
Question 2:
If the answer to question 1a) is "YES", then given the parent module
parent-module: make module! [
title: "Parent module"
version: 1.0.0
export: [do-it set-it]
][
data: [block of local data]
do-it: does [probe data]
set-it: func [some-data] [ insert block some-data ]
]
and the descendant module
descendant-module: make module! [
title: "Descendant module"
version: 1.0.0
export: []
][
set-parent-block: does [ set-it "descendant's data." ]
]
if I evaluate
>> descendant-module/set-parent-block
will the parent-module's data block be effected, or will an independent
copy of the data block be effected that is local to descendant-module? I.e.
once set-parent-block in the descendant module has been evaluated, will
>> parent-module/do-it
display the "descendant's data." string as part of parent-module's data
block, or will this string only be displayed if I evaluate
>> descendant-module/do-it
Question 3:
If a descendant module shares the parent module's context (i.e.
parent-module/do-it will display a block that includes the string
descendant's data.
), then can you include the following functionality?
descendant-module make remote-module! [
title: "Descendant module"
version: 1.0.0
url: http://www.rebol-remote-module-server.com/
export: []
][
set-parent-block: does [ set-it "descendant's data." ]
]
such that evaluating
>> descendant-module/set-parent-block
will connect over the Internet to the remote parent module and modify the
data block that is stored in the RAM of the remote machine?
Or am I dreaming? Message-based module inheritance over the Internet?
Based on the pending module enhancement and REBOL's current messaging
features, we need to add only two more words: the make-able type
remote-module! and the addition of url as a module header field:
local-module make remote-module! [
title: "Client Module"
version: 1.0.0
url: http://www.rebol-remote-module-server.com/
export: []
][
]
This would be quite useful.
A simple chat type application, for instance, could be easily implemented.
The chat client could look like this:
The Chat Client
===============
chat-client-module: make remote-module! [
title: "Chat Client Module"
version: 1.0.0
url: http://www.rebol-chat-server.com/
export: []
][
userid: none
login: func [my-user-id] [
userid: my-userid
signup userid
]
chat: does [
forever [
either input? [
post-message userid input
] [
if new-messages? userid [print get-messages userid]
]
]
]
]
>> do chat-client-module.r ;- or chat-client.rm?
== module
>> signup "me" "chat-room-1"
== true
>> chat
given a chat server available on a remote machine that may be implemented as:
The Chat Server
===============
chat-server-module: make module! [
title: "Chat Server Module"
version: 1.0.0
export: [ signup post-message get-messages new-messages? ]
][
chat-db: [
chat-room-1 [
users []
messages []
message-pending []
]
chat-room-2 [
users []
messages []
message-pending []
]
chat-room-3 [
users []
messages []
message-pending []
]
]
signup: func [userid chat-room] [
append chat-db/:chat-room userid
]
new-message: func [chat-room] [
chat-db/:chat-room/message-pending: copy chat-db/:chat-room/users
]
post-message: func [userid chat-room message ] [
if found? find chat-db/:chat-room/users userid [
append chat-db/:chat-room/messages rejoin [userid ": " message]
new-message chat-room
]
]
new-messages?: func [ userid chat-room ] [
found? find chat-db/:chat-room/message-pending userid
]
get-messages: func [userid chat-room /local user] [
if all [
found? find chat-db/:chat-room/users userid
user: new-messages? userid chat-room
]
[
remove user
chat-db/:chat-room/messages
]
]
]
The neat thing about the module feature is that a different site may
implement a different, more stable or capable chat server, and the same,
unmodified chat client could have access to the improved capabilities,
provided that the improved chat server continues to support the same public
interface as the old one. Additional interface functions could be used by
more advanced chat clients.
Your module proposal is only "a few" lines of code away from remote
capabilities. Do you think it is possible to extend your specification to
include this?
B) Can features be added to a module, such that a module may selectively
expose additional functions, if asked to do so by an authorized client?
i.e
authentication-example: make module! [
title: ...
authenticate: true
export: [ authenticate ... ]
authenticated-export: [ authenticated-function ]
][
authorized-clients: ["some-userid" "some-password"
"some-other-userid" "some-other-password"
]
authenticate: func [userid password] [
foreach [user pass] authorized-clients [
if (reduce [user pass]) = (reduce [userid password]) [
return true
]
]
return false
]
authenticated-function: does [
print "only accessable to authenticated modules."
]
]
client: make module! [
title: ....
authorization-id: none
userid: "some-userid"
password: "some-password"
][
authentication-example/authenticated-function
]
Explanation:
When client attempts to evaluate authentication-example's
authenticated-function, authentication-example retrieves the fields userid
and password from client and uses the user-supplied authenticate function
to determine if the module is an authorized module.
If so, authentication-example issues a unique authorization-id and reports
it to client. This authorization-id will remain valid throughout this
session. Based on this authorization-id, authentication-example permits
client to evaluate its authenticated-function, which is any function that
is listed in authentication-export.
When client's module is garbage-collected the module authentication-example
forgets
the authorization-id it issued to client.
B) would be a nice extension to A).
Can't wait to hear from you ... ;-).
At 01:24 PM 7/31/00 -0700, you wrote:
>Jim just reminded me that I promised to say a few words about REBOL
Modules here on the ally list. I'll do better than that: Here's a short
document that describes REBOL modules. Take a look.
>-Carl
>
>Attachment Converted: "c:\eudora\attach\modules.htm"
>
;- 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
[8/13] 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
[9/13] from: agem:crosswinds at: 3-Aug-2000 15:12
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.
;have to read real syntax again :)
hotel: make module! [export: [give-room-key]][
give-room-key: func[a][some-checks a return room]
room: make module! [export: [bathing ...]]
bathing: func[me][...]
...
]
]
temp-home: hotel/give-room-key my-password
temp-home/bathing me
remote modules sounds nice :)
-------------------------
[rebol--techscribe--com] wrote:
> Hi Carl,
> I like your module specification. It appears to be a useful tool for
<<quoted lines omitted: 229>>
> http://www.REBOLpress.com
> visit me at http://www.TechScribe.com
Volker
[10/13] from: petr:krenzelok:trz:cz at: 3-Aug-2000 23:52
> cell-phone: make module! [
> title: "cell phone module"
<<quoted lines omitted: 4>>
> ]
> Looks quite useful to me!
yes, just a few comments. your solution provides only solution for remotely
placed modules. but - what about functions, objects, words? Wouldn't it be more
general if we would be able to type e.g. ble: make/target image! 200x200 'url?
As 'url is represented by schemes, even ram:// or ram-disk:// could be
introduced to rebol.
In any case, it would require REBOL to have some kind of default protocol for
RPC, as not all types of schemes are suitable for such kind of behavior.
future:
joke: make/target function! [][call "set time 11:00"]
Hey Elan, type 'joke at your console - just trust me. Hmm, what? Did nothing?
Perhaps buggy. Well go to bed and start your timer
Elan:
->> awake-me 06:00
pekr:
Hehe, Elan will sleep a little bit longer ;-)))
-pekr-
[11/13] 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:
<<quoted lines omitted: 7>>
> >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:
> >>>>>>>>>>>>>>>>>>>>>
<<quoted lines omitted: 19>>
> 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
<<quoted lines omitted: 6>>
> 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
<<quoted lines omitted: 10>>
> 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
<<quoted lines omitted: 9>>
> 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? :)
[12/13] from: rebol:techscribe at: 4-Aug-2000 18:07
Hi Petr,
In response to my example:
>> cell-phone: make module! [
>> title: "cell phone module"
<<quoted lines omitted: 6>>
>> Looks quite useful to me!
>>
you wrote:
>yes,
:-).
>just a few comments.
Yikes!
>your solution provides only solution for remotely
>placed modules. but - what about functions, objects, words? Wouldn't it be
more
>general if we would be able to type e.g. ble: make/target image! 200x200
'url?
>As 'url is represented by schemes, even ram:// or ram-disk:// could be
>introduced to rebol.
I disagree (surprised?) with you, that the remote module extension is not
general enough. Yes, any function, image ... that is to be shared remotely
must be
a) defined in a module, and
b) accessed from within a module.
But that is only a limitation in as much as giving the host the ability to
control what he wishes to expose on his REBOL server. And that is a
sensible limitation. Other than that, if you read what Carl wrote about
modules, your scripts will always be evaluated in the context of some
module. Remember that any script you load - if it is not a module - will
nevertheless be evaluated in the context of the USER module.
This means that if you wanted to create a function based on an
argument-block and body-block combination derived from a remote machine,
then given an evaluated module on a remote machine:
remote-module: make module! [
export: [arg-block body-block]
][
arg-block: [a b]
body-block: [print [a b]]
]
a client could create his local function:
local-module: make module! [
url: rebol://rebol.TechScribe.com/remote-module
][
local-function: make function! arg-block body-block
]
Since REBOL does not find the words arg-block and body-block defined in the
module local-module, and since local-module includes the url
rebol://rebol.TechScribe.com, his local REBOL interpreter will connect to
the remote REBOL interpreter located on TechScribe.com, at a specific port
address that is defined by the rebol:// protocol, and bind local-function
to a function that is created in the local REBOL instance, by using the
blocks on the remote machine for the function's prototype.
>In any case, it would require REBOL to have some kind of default protocol
for
>RPC, as not all types of schemes are suitable for such kind of behavior.
Perhaps an implementation of XML-RPC would be sufficient? We really should
be able to implement that right now.
>future:
>
>joke: make/target function! [][call "set time 11:00"]
>
>"Hey Elan, type 'joke at your console - just trust me. Hmm, what? Did
nothing?
>Perhaps buggy. Well go to bed and start your timer"
>
>Elan:
>
>->> awake-me 06:00
>
>pekr:
>
>"Hehe, Elan will sleep a little bit longer ;-)))"
Hey, what time is it, oh, no, have to run.
;- 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
[13/13] from: petr:krenzelok:trz:cz at: 5-Aug-2000 8:18
[rebol--techscribe--com] wrote:
> Hi Petr,
> In response to my example:
<<quoted lines omitted: 12>>
> >yes,
> :-).
:-)
> Since REBOL does not find the words arg-block and body-block defined in the
> module local-module, and since local-module includes the url
<<quoted lines omitted: 3>>
> to a function that is created in the local REBOL instance, by using the
> blocks on the remote machine for the function's prototype.
just one comment. Make 'url field more general. We currently have 'Needs field,
which can contain block of needed components, so:
If creating script=module, we could use even 'Needs, e.g. Needs: [Core 2.2 View
1.0 ODBC 1.0 rebol://www.rebol.com/module http://www.rebol.com/some-script.com]
or just what if your module needs to be linked into two another modules? Then
your 'url field should accept also block of urls ....
Do you disagree? :-))
> >
> >In any case, it would require REBOL to have some kind of default protocol
> for
> >RPC, as not all types of schemes are suitable for such kind of behavior.
>
> Perhaps an implementation of XML-RPC would be sufficient? We really should
> be able to implement that right now.
>
IIRC someone mentioned it already, but any results so far probably ...
Cheers,
-pekr-
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted