World: r3wp

it will be "later".

In R3 Module Design Details, it says there is a function named SET-MODULE. 
I cannot find it in R3 a111. Anything changed?

Yeah, the whole module implementation model changed, twice. The docs 
reflect the second change. Sorry, been busy.

Sorry, the second version.

Thanks BrianH. Overall the doc is very good, I learned a lot.

I really need to update the guru-level docs, but someone else needs 
to read the updated version and write a user-level doc. I understand 
the details too well to be that good at explaining things to regular 
users.

It would be especially useful for the guru-level docs to explain 
the rationale behind the design decisions.

I might be able to do that as a by-product of learning R3 module.

Cool. I'll remember you said that :)

I have 10 days vacation, I am totally free before Oct 9th. I plan 
to read the R3 source code and refactoring my Translation Engine 
which was written in R3.

But as you can see, my Enginsh might not be good enough. That's the 
only thing that I worried about.

That might not be a problem - I am a better editor than a writer.

BrianH, I will send you a R3-Module Doc after my vacation for you 
to correct. Actually, I was a technical Editor in O'Reilly Taiwan. 
Of course, The books that I edited were all in Chinese.

Question for Carl? :)

   http://stackoverflow.com/questions/7577186/is-rebol-still-alive

I've read info out R3 Module Details from DocBase, R3 Blog and its 
comments, and source code. Many pieces of info are conflicted. It's 
annoying.

Yup. The source code represents the current intended design, though 
one question has popped up recently that didn't arise during the 
design process. The !REBOL3 Modules group here has a lot of info 
too. I hope to get the chance soon to go over the docs on rebol.net 
and update them to the latest design. I was going to do that last 
weekend, but I got really sick. However, I am using REBOL at work 
now for utilities, so I can afford to work on it again here and there.

I find that the source and the !REBOL3 Modules group are the best 
places to look for now if you want low-level docs and usage tips.

Andreas asked a lot of good questions :)

OK. Thanks BrianH. Take care of yourself.

Brian, regarding BIND, I mean e.g. this:

>> f: make function! compose/only [[a b c](body: [a do c])]
>> a: first body
== a

>> f 1 1 [a + b]
** Script error: b has no value
** Where: do f
** Near: do c

>> f 1 1 bind [a + b] first body
** Script error: none word is not bound to a context
** Where: bind
** Near: bind [a + b] first body

That is annoying, since it is actually false

here is how I can circumvent it:

The 'b in that case is just data, not the argument b. It's another 
word which has the same name but a different context.

yes, that is the unbound block, that does not matter

here is a way how I can circumvent it:

f 1 1 change [a] first body

Yeah, it is an interesting efficiency hack that MAKE function! does 
a BIND on the function body instead of a BIND/copy. It does mean 
that you need to be careful with the runtime accessibility of your 
source though.

MAKE function! does a BIND on the function body instead of a BIND/copy 
- it is not only for efficiency, it is actually the proper way even 
for safety

I do like that. but, nevertheless, the MAKE function is able to bind, 
while I am not, which proves, that it is just an artificial, (not 
making anything more secure) and annoying limitation

it is actually the proper way even for safety

 - Why so? Once the function is made, security dictates that the accessibility 
 of its bound body should be limited. If you can get a bound body, 
 you can trace through the bindings to get access to any internal 
 code it references. That is why R3's BODY-OF does something like 
 an UNBIND/deep COPY/deep. If MAKE function! does a BIND rather than 
 a BIND/copy, that means that any extant references to the original 
 body block argument are a potential security hole unless they are 
 contained.

security dictates that the accessibility of its bound body should 
be limited

 - yes, and it normally is For that it suffices for you to use the 
 FUNC function, and, voila, you are safe.

Yes, we've made other functions help work around the potential security 
weakness of MAKE function! - that's the tradeoff we made for efficiency. 
And as long as you either use COPY/deep generators like FUNC, or 
control the accessibility of your source, it's a really good tradeoff.

Well, for me, that is better than the R2 approach, where it actually 
is the other way around, i.e. insecure.

Definitely. Sometimes it's hard to go back to R2 after programming 
in R3 - you get spoiled by the advantages.

But, that does not solve the BIND annoyance.

In my opinion, BIND should simply obey and not annoy with error message 
in such a case

As said, if BIND does not do it for me, I can do it on my own using 
CHANGE, so no safety can be gained

...and, CHANGE actually isn't the only method usable, there are other, 
even uglier methods

You can do it with CHANGE only if you get access to the bound body 
block, which is why letting a reference to that out is a security 
hole.

Or to a bound word.

Yes, understood, but that is fine. I know what I am doing and arrange 
the security as I see fit

On second thought, allowing BIND to take a function! for its context 
argument would allow you to get around the security protections of 
BODY-OF.

I do not want to do that with a function. It really suffices to do 
it with a word

And, besides, it is circumventable anyway, the only reason why I 
do not show you that alternative is, that it looks even uglier than 
the usage of CHANGE

But you can already BIND to a word bound to a function context. BODY-OF 
just keeps you from getting access to a word bound to a function 
context from outside the function. As long as you control access 
to the original code block you are secure.

But you can already BIND to a word bound to a function context.

 - actually, I cannot, if the function isn't already running (in that 
 case BIND refuses to do that)

That is what I call "annoying"

>> bind 'a do func [/a] ['a]
** Script error: a is not in the specified context
** Where: bind
** Near: bind 'a do func [/a] ['a]


Well, then you don't have to be as careful with letting bound function 
words leak I guess.

(since it does not enhance security in any way)

But, that is wrong, since when you let the word out, you can bind, 
just not using the BIND function (you need to use CHANGE for that)

or, having the access to the body, you can do other tricks