World: r3wp

well then it's fawesome already

fawesome ?

:) some startup invented word fugly here .. f*** ugly ... so this 
would be f*** awesome :)

you can do several bind in chain.
bind bind [...] haru-pdf image-loader

aha, so you could create bind-all that would receive a block of contexts 
and bind to them all .. I see now bind is also in R2 which I have 
here

Allowing a block of contexts for bindings has been already requested 
in curecode for R3

ha, I tried and it really works :) 


a: context [ name: "janko" ]  aa: func [ ] bind [ print name ] a 
aa 
janko

(btw fugly was the for the measuring the code ugliness and it was 
the most ugly code)

I posted your example on paste code for anyone that will be looking

fine

Janko, your proposal gives me an idea for a simple mezzanine IMPORT 
wrapper that would help with binding IMPORT/only modules to a code 
block as if they were mixins. The mixins concept is a little tricky 
to replicate manually, so having a mezzanine like that would help.

I'd Rather have IMPORT/only to control what I want imported from 
the module.   I hate the export concept where modules push their 
shit in your application.  with two modules exporting the same words 
your fucked.

But we have IMPORT/only already. I considered adding that facility 
to IMPORT, but the complexity of the process was reaching its limits 
already, and we didn't want to encourage that behavior anyways because 
it was at odds with the model that we had to use to support multitasking, 
to manage overrides, and to minimize the need for import headers. 
If you support selective import in the headers, managed overrides 
are impossible, as is multiple user contexts for multiple tasks.


Selective import really is the job for a higher-level mezzanine function 
 One that would call IMPORT/only, btw.

With R3's module system most of your modules/scripts don't need Needs 
headers at all, and duplicate ones even less so.

However, it does mean that the trust model of R3's module system 
is different than that of Slim. In particular, you are supposed to 
be able to tell everything you need to know about a module from its 
loaded source, or from its header if there is no source available. 
If you don't trust the module, or if it would trounce the other modules 
you are loading, don't use it.


The R3 module system is designed for competent programmers who need 
to organize their code, but don't want to be bogged down in the beaurocratic 
overhead of maintaining import graphs in a multitasking environment. 
There is enough flexibility to help you structure your application 
as you see fit, and very little management overhead at design, development 
or run time. And it's statically determinable so a preprocessor can 
turn it all into one script with nested modules if need be.

slim allows nested static linking, preserving the import system  
;-)


its the multi-tasking part I don't get... what do you mean by that?

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.