World: r3wp

R3 module exports import either one of two ways:

- Unnamed modules (mixins) import into the context of whatever module/script 
asked for them, redoing every time as if they were there

- Named modules import into the user context. only loading once per 
user context and then shared within it.

That last bit is the part that is affected by multitasking, since 
each task gets its own user context. Modules can manage word overriding 
explicitly in their init code, or the module/script that loads the 
modules needed by the application can manage it manually. There are 
no implicit overrides: If a word would override a already-loaded 
word, it doesn't unless you tell it to.

The mixins concept was my best attempt to make some use of unnamed 
modules, since you can't really tell if they're already loaded to 
reuse them if they have no name. So instead they basically incorporate 
themselves into the context from which they are called, as if their 
code was inlined. You can wrap a bunch of unnamed modules into one 
named one if you like though. Many other languages have a mixins 
concept; at least R3's is better than Ruby's :)

That user-context-per-task model is planned, btw, not fully working 
yet. But you have to take it into account when designing modules.

BrianH: if it gave you idea for anything then I am more than happy 
that I wrote it :) . I have to refresh my knowledge on mixins a little..

why call it a user context...  isn't there a better name... its confusing 
I find... shoudn't they be called something a bit more relevant to 
what they are?

(just a quick note... not a big thing)

I agree. I'm not assuming that it will continue to be called a user 
context - that's just what it's called now: system/contexts/user 
:)

The idea per thread is neat, btw.


but I will be adding the expose refinement to import for sure... 
I just can't use other people's modules and hack them everytime they 
are updated... that is how slim started out... I was using someone 
else's module and everytime he did a release, I had to take 2 hours 
to fix up the module so it would work into my code.


that is the point of importing only the words you want... especially 
renaming them to remove clashes within your code and the module being 
used.  I don't see how that has ANY thing to do with the per-task 
concept  the source which uses a module, just makes it obvious where 
things are coming from and debugging is GREATLY simplified.

All module export in R3 is what you call exposing in slim. Importing 
is a separate issue, and you can choose what to import. The export 
list is just that: a block of unbound words that are used as a guideline 
about what to import - all module context words are actually visible, 
unless they are hidden using the standard hiding facilities. You 
can choose to import just that list, or none, or go by a module reference, 
or import whatever visible words you want. What importing means depends 
on what kind of module or script you are calling from, or for that 
matter whatever you want it to mean.


You need to remember the model if you are doing selective import 
though. You aren't just importing to the current context if you are 
importing named modules. If you come up with a good model for selective 
import, be sure to tell me. I think that I'm one of only a few people 
who really understands the whole model (must write more docs).

Selective import is really easy to do if you need to, but not from 
the Needs header since that is usually importing to the user context.

but when a module "needs" another module I gather the callee is not 
going to import into the user context but within the caller module... 
right?

slim and R3 modules have a very similar model, as we discussed before, 
since I have the same concept of named/unnamed modules and they basically 
have the same limitations.

Nope, Needs is for requirements. Only mixins import into the calling 
context. You are expected to manage your system as a whole, rather 
than micromanage. That was a basic strategic decision that makes 
the rest possible.

And mixins import into the calling context even when called from 
scripts.

Though for scripts, "importing" means something different.

There are three kinds of importing and two kinds of exporting. Multiply 
those and you have six situations. Hence the complexity budget.

ok I see the difference with the needs vs import.  when you specify 
a needs block, are the exports done automatically in the user context?

or must you still add the import command in your script to have access 
to them?

If you have a Needs header (pardon the anthropomorphism), named modules 
in it are put in the module cache and the words in their exports 
list are resolved to the user context (resolve means copying the 
values to corresponding words in the target context, but not overriding 
existing words). Then the words from the system and user contexts 
are imported to yours, with "import" meaning one of three things 
depending on whether you are a script or a regular or isolated module. 
Then any unnamed modules in the list are imported into your context, 
also in one of three ways. The modules in the list are loaded in 
the order specified (transitively). No explicit IMPORT function call 
needed.

Any overrides other than first-come-first-served can be done explicitly 
by setting the value in system/contexts/user, or in self for mixins.

ok, that is exactly how I understood it.

The code to do the importing is no more than 2 or 3 function calls 
for each method, but study them carefully, as even the order of the 
calls matters. It is much easier to understand and use than it was 
to design, believe me.

don't worry, I know how complex module management is ... I think 
you know why  ;-)

I just recently added a few features to slim and I had a lot of fun 
too :-)

If you use the IMPORT function explicitly, there are some things 
you simply can't do to the calling code because it is already bound 
and running. That is the reason that the Needs header is there. However, 
IMPORT/only just loads the module and returns a reference to it, 
and doesn't put it in the module cache at all. Once you have that 
reference you can do whatever you want with it, including selective 
imports. Some wrapper mezzanines should be made to make certain things 
easier but at this point we don't yet know what needs to be made 
easier :)

Selective imports can include words that the module hasn't put in 
its export list at all - anything that isn't hidden.

yep

And by that, I mean in the *current* R3 module system.

You can choose to import just that list, or none, or go by a module 
reference, or import whatever visible words you want

 - eh, really? I thought that one of the ideas of the module is to 
 prevent user to mess with things. There are two point of views:


1) you debug some code, and your imported module function does some 
weird thing, so you want to debug foreign module. You can export 
some intermediate values from module (well, I am not sure it is best 
debugging method, but it is nice that such possibility is here


2) OTOH - you are a module author. Let's say you have some reason 
to protect your code/knowledge. So what you want is - compressed 
and scrambled source, checksum of code section into header field, 
and precisely defined Exports block of exported stuff = API to your 
module. And please don't push me to use Extensions in such a case. 
I am wondering, if security framework can be expanded, so that you 
can protect module/object, so that its words are not visible or gettable 
in any other reflective way :-)


I of course encourage to use open-sourced modules, but sometimes 
hidding the source and having only API exposed might mean a simplicity 
(user does not always need to look into internal, having headaches 
from thousands of line of code)

Well, I didn't say that it wouldn't be tricky. For one thing, you 
can't do any of that from the Needs header, you have to use the IMPORT 
function, and then it is tricky. Not tricky to do, tricky to know 
what to do or to do right. Hence the need for wrappers around IMPORT 
like the one Janko didn't realize he suggested.

For most developers though, you don't need to do any of this stuff. 
The Needs header capabilities are enough. Any more would be too much, 
leading to overcomplexity and bad design. Unmaintainable code - we 
don't want that.

If you want the security framework expanded, push Carl to fix the 
rest of the PROTECT and UNPROTECT tickets in CureCode.

PROTECT/lock and UNPROTECT/lock in particular.

brian, funny, when you say: "leading to overcomplexity and bad design. 
Unmaintainable code" ... lets just say that for me, its going to 
do the opposite.  cause now, we have to manage the redefining of 
words ourselves outside of the module management operation and out 
of context.


I'll stop talking about modules now, cause Carl wants a model where 
the modules control your script, and I want a model which controls 
modules... so we are fundamentally at odds.  I don't want to have 
to work like we in do C where everything ends up being defined in 
the root context, and we end up re-defining things in header file 
 just so they don't collide with other stuff, but that's what will 
happen and what Carl seems to want.  so be it.  to me that is more 
complicated cause its out of context to where its being used.  and 
it adds a shit load of useless files, dependencies and maintenance.

just so its clear... 


wrt MODULES, I'm not at odds with the work you have done brian, which 
is very clean and well done... I'm at odds with the philosophy itself 
of the module model Carl decided to use.  It doesn't change anything 
wrt to R2's scalability problems, a part from removing paths in DO. 
 that's just my PoV and people aren't obliged to agree with it.  
:-)


python's module management is the best I've used, cause users have 
control, not the modules.  And since its a language based on the 
use of modules, I hoped we would follow that path.  but it seems 
not. what can I say.  

slim R3?  ;-)

Max - so just cut your two messages and paste them to the blog article! 
Carl does NOT monitor this channel.

where can I get the code to R3 chat?  I know where is the data, but 
not where is the source to the whole chat app.

>> source chat
chat: make function! [[
    "Open REBOL DevBase forum/BBS."
    /local err
][
    print "Fetching chat..."
    if error? err: try [do http://www.rebol.com/r3/chat.rnone] [

        either err/id = 'protocol [print "Cannot load chat from web."] [do 
        err]
    ]
    exit
]]

ah, ok, I didn't think it got it from the net at each instance... 
I was going to source the chat func in a few minutes... hehehe

no prob, i like when you ask newbies questions ;-)

Message 3564

hehehe  yeah, I'm always a REBOL newbie a few minutes a day  ;-D

unlike me who is a the contrary a rebol guru a few seconds per years 
:P

Can I get my hands on an early HOST code release for windows?

only Carl can answer that, but so far only a few of us have it . 
  to keep support noise low and freedom of alteration high.

you'll have to ask Carl privately on R3 chat.

any word on when do we expect general availability?

I can do that.  Thanks Maxim.

Pekr, honestly... right now, a part from porting to another platform, 
there is too little documentation and oppeness for it to be very 
usefull to people in general.


I expect a few other platforms to get ported by Carl (he did a linux 
one this week), so he can continue to polish the OS independance 
of the code as much as possible.  


Supporting the extension model on other platforms seems to be a big 
priority.

Once that is done... then one or two rounds of adding "host-specific 
features" to the host and some documentation too.  


A lot of the limits and oppenness of the host is being discovered 
by us... Carl just made it compilable... now our job is to try enough 
stuff and report bugs, limitations,  requirements, suggestions, to 
Carl so the host itself can actually have stuff in it which is meant 
at host-specific features.  


things like: Native R3 callbacks.  host to extension interconnections, 
extensions within the host, device extension hooks, etc.


until the extension model is revised and few more things are added 
to the host, I don't expect the release to be tagged as"release", 
but it might go public.

the licensing also doesn't seem to be completely ironed out.


my humble guess... with the holiday season approaching?  end of january 
he should either be releasing a beta host with a lot more of functionality 
or the current stripped down version, with a lot of testing and a 
lot of platforms now at the same level.


I'd bet on the latter, with a feature testing version in alpha with 
the current crew hammering out tests and architecture discussions 
:-)