World: r3wp

If you still think that the word 'exports is appropriate, there is 
something you need to know: All this boot code, the 'sys and 'lib 
contexts and such is already pretty much there. And when it's done, 
only then can the module system be added. The 'sys and 'lib contexts 
don't depend on the module system at all, and currently don't include 
any code from it. The module system will integrate into and use the 
'sys and 'lib contexts, but don't define them.

Following issue! datatype conversation on blog - why the issue! type 
changed at all? What is the advantage of new behaviour, if it blocks 
most users of "old" issue! type from its usage?

Actually, it doesn't block most old users of the issue! type. Not 
many people change issues after they are created.

Think of the new issue! type (whatever we decide to call it) as an 
immutable string, with optimized storage. The rest of the behavior 
can be made to match.

One further question to boot-levels. There are three. And the top 
one is:


mods: initialize up to and including lower-level resident modules. 
In addition to boot-sys, this level adds high-priority resident modules, 
but not mezz plus (higher level mezzanines). 


I am a bit confused - what should I use for CGI? E.g. I don't need 
help, etc.

Hm, I just had error because of the change and had to change the 
datatype to something different. I used email! (I can't use string!), 
but I don't think it's the best replacement for old issue!.

For most actual users of the issue! type the new issues will be faster 
to use. And the "running out of words" argument isn't anywhere near 
as much of a problem as it is in R2, as noone has yet run out of 
words in R3 afaik.

Carl used -'base name, for some thing, which is almost useless, apart 
from few gurus. But I understand why such mode is needed. It just 
should be called 'debug or so. I thought that boot-level is about 
"packages of functionality", and for all long years, by 'base we 
refer to minimal runnable rebol environemnt ...

Pekr, most of the time you will not specify the boot level if you 
are doing CGI. The default (unspecified) boot level loads the module 
system and all of the opt-out modules.

It all seems to be so complicated.

I am a user, I should not care for the technical mumbo-jumbo :-)

Most of the time you won't specify a boot level at all.

All I needed to know in the past is, that for CGI I need fast system, 
which will not load unnecessary code, e.g. help, etc. Hence I used 
/base executable. Now:


base - initialize only the lower levels. This option is for special 
purpose testing only because it provides no way to load external 
code. (No schemes, such as file access, nor load or do functions.) 
If your host-kit build is crashing on startup, you can use this option 
to confirm that the exe image is loadable and runable.


sys - initialize up to and including the basic runtime lib and sys 
contexts. This option allows you to run a very "lean" system (minimal 
memory and boot time) where your code will be supplying all other 
run-time functions and modules. Provides a basic load function but 
with very limited special options (no import, needs, versions, or 
related features.)


mods - initialize up to and including lower-level resident modules. 
In addition to boot-sys, this level adds high-priority resident modules, 
but not mezz plus (higher level mezzanines).

The 'base boot level *is* the minimal running REBOL environment. 
It's just that R3 can run in a *much* more minimal environment than 
R2 can, so the base is smaller. At least Paul should be happy, as 
he has been requesting this for R2.

If you want something as high-level as R2's /Base, use -b 'mods.

OK, but in base, you don't have any load or do - it is practically 
useless, no?

I want to understand the stuff. So - if 'base does not allow load 
or do, I can't execute any code? I can not load additional stuff, 
etc?

No, 'base is not useless, it's just useful in more rare circumstances. 
Users like Maxim will likely want to replace all of that stuff anyways.

Now I want to understand 'sys level - "Provides a basic load function 
but with very limited special options (no import, needs, versions, 
or related features.)" - I don't understand the "no import" argument 
- so I can't use modules here?

Right. People who thought that the 'lib context is just a renaming 
of 'exports were way off.

And as for 'mods. This is why you try to define mezz+ packages? So 
that help will be e.g. in mezz+? So 'mods is now old /base?

Right. And no specified boot level is the old /Core.

OK, what is 'sys level precisely good for?

Maybe we should explicitly add 'all feature, which would be just 
the same as not specifying boot-level at all ...

No, it wouldn't, because there are still a few opt-in modules that 
are included but not imported by default. For instance, modules that 
implement conflicting functionality, such as CGI vs. GUI.

This stuff will require very precise documentation and examples, 
explaining e.g. how user can save some cycles for CGI purposes, yet 
how he/she can load his own framework (modules) etc.

The 'sys level is good for really low-level programming, replacing 
the mezzanines with your own, testing host code, all sorts of things. 
And it will enable the few users in the REBOL community who write 
their own module systems to use them instead of the standard one. 
You might be able to build sandboxes at that level too.

The best would be to have complete map of what functions are available 
for what level ...

Which has not yet been decided. For that matter, there is also the 
question of *where* they are available at different levels. It is 
possible that some stuff put into 'lib will be transferred from other 
contexts in the system catalog.

I like the SDK aproach - you get your base, and then you include 
any mezz funcs/packages you want. This all now sounds so cryptic 
...

I mean - without user not precisely understanding new module system, 
all the bindings, he has absolutly no chance to understand, what 
we are talking about ...

It only sounds cryptic because it isn't done yet. A system redesign 
has been planned for a while now, but we had to nail down the semantics 
of the language first and fix a *lot* of bugs.

This should become part of docs asap - http://www.rebol.net/r3blogs/0334.html

The module system, the boot levels, it is all progressive-reveal. 
By default, things are really simple for users and there isn't that 
much to understand. As you learn options you can make the system 
do more tricks, but the default is really simple.

Are you still working on module system?

I am putting the finishing touches on the initial implementation. 
More tweaks will be necessary for the integration (mostly renaming 
variables), but the new system model will simplify things a bit. 
In particular, the predefined 'sys word makes the module-tools mixin 
unnecessary, which simplifies the bootstrapping and use of the system 
immensely.

Why the rewrite, if I may ask? I thought your module code was already 
finished?

Well, there was a new feature required (delayed modules) that when 
added had wide-reaching implications for the rest of the module system, 
and caused a bunch of other features and the improving of others 
as a side-effect. Also, the old module system violated the "hit by 
a bus" principle: I was the only person who understood the code fully, 
so noone else could modify or enhance the code, and if I went away 
the code would become instantly unmaintainable. So the new code is 
easier to use, does more, and can be understood by the average REBOL 
guru. Believe me, it was that last part that has been the trickiest.

BrianH note that if you read my blog posts, I am rooting for 'RESIDENT... 
not 'EXPORTS.


and thanks for your better explanations they shed a little bit more 
light on the whole thing.

Don't handicap the implementors of R3 just because you want to handicap 
yourself.


Don't harm the users of R3 just because you are a lazy implementor.

But it will be easier to discuss this once there is a concrete implementation 
to play with and discuss, not just vapour.

And in any case, even having 'lib defined in 'lib won't stop script 
writers from just ignoring it, continuing to use the LIB name for 
their own purposes, and refer to the LIB context as system/contexts/lib 
if they ever need it.

See, that last message is exactly what I was recommending, Andreas. 
You have just pointed out that there is no harm whatsoever to defining 
the 'lib word in 'lib. Though there is no evidence of the "lazy" 
in your earlier comment.

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

Module issues.

uh oh, now I fear Carl will scrap BrianH's work, and we are going 
to wait for 3 months for Carl to come-up with his own version :-)

I hope this is not the case, however following is scary, while understandable 
-  ".... a fight between simplicity and complexity, between maintainability 
and chaos, between elegance and ugliness"

no Brian is doing the module work, its just that the changes to how 
the contexts are now layed out provoke deep changes in how things 
are bound.


because that is a big part of the module system's job, it means Brian 
has to update a lot of the code.


also remember that Brian has been splitting up the module code into 
sub-functions, so all of that makes it simpler, and more re-usable.

Earlier prototypes worked well. They were functional, clean, and 
simple. Understandable.

 - that simply means, that Carl does not like something about current 
 system ...

They where coding at opposite ends of the spectrum, now they are 
fighting to merge the two together.  that's how I read it.


IMO its just a question of getting it to work again. with new contexts 
layout and new, better module functionality.

AFAIK, Brian's code is usually accepted.