World: r3wp

http://www.rebol.net/r3blogs/0299.html

Juicy stuff now.

what is command! type ?

This is a function exported from extension, becaouse you can write 
different function using differend type of arguments it is globally 
called command! Another thing is some abstraction in names used in 
future things in (Carl's) mind.

http://www.rebol.net/r3blogs/0300.html

New 'export method.

http://paste.factorcode.org/paste?id=1057Is this dumb proposition 
?

Janko, I don't see the need, we can do that easly, using bindology.

make-report: func [ data ]  bind [
    p: new-page
    f: font "arial" 12
    goto p 100 100
    print p f data/title newline
    row p f [ "item" "qty" "price" ]
    save p %file.pdf
] haru-pdf

even better then :) .. but what is haru-pdf in this case ? is it 
a module?

and can you put more than one in-there?  for example two modules 
[ haru-pdf image-loader ]  ?

? bind

haru-pdf can be a module or an object

I don't have rebol at this comp.. I will look

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  ;-)