World: r3wp

http://www.rebol.com/cgi-bin/blog.r?view=0489#comments

its Carl's REBOL blog.

I did a little of research... and found (remembered) the exact word 
it should be called.   

'RESIDENT

RESIDENT Evil :-)

'exports is self-descriptory .... it should not be changed, imo ...

The same goes for the 'sys boot level argument - it is also imo not 
accurate. Boot level arguments don't directly link its meaning to 
system contexts and hierarchy. They are more like packages of functionality 
to boot. 'sys should be imo definitely replaced by 'base, which we 
are used to for all those years ...

RESIDENT actually means exactly what the Exports context is.   data/ 
code which is external to your application but always accessible.

ok, maybe it is just that my english vocabulary is rather limited. 
In regards to module and oop systems, import/export work rather nicely 
...

ah, Carl reversed his decision - boot-level will use words :-)

Another naming contest :-) Should issue! datatype be renamed? 'key-word 
is one of candidate names - http://www.rebol.net/r3blogs/0338.html

I am actually fine with LIB and SYS, but I'd prefer if they were 
not bound in LIB per default. I.e. I'd rather prefer that you only 
have system/contexts/lib and system/contexts/sys to refer to those 
contexts, per default.

uh, what's Carl doing? ;-) He changed the blog content, and now it 
does not make sense at all ... boot levels confusion to the max .....

ah, it changed once again, and now it seems OK :-)

Having short words for the 'lib and 'sys contexts opens a lot of 
possibilities for system simplification. If they are renamed to something 
else, make sure that the replacement words are no longer than 4 characters 
each. And if you don't predefine them in the 'lib context, definitely 
make sute that they are predefined and protected in the 'sys context 
- that way the at least the system code won't be as disadvantaged 
as the user code will be by not including them in 'lib.

These are words that will be referenced a *lot*, both of them, so 
we want them to be really short.

Why would they be referenced a lot?

IIUC the lib context is automatically imported into the user context. 
So you'll only have to reference LIB if you shadow some name in lib 
with your own definition and then need to refer to the original definition 
again.

BrianH: that does not change the fact, that 'lib as a name sucks 
a lot. It says namely nothing, and in my eyes is a degradation from 
'exports ....

You export into the common shared library, or lib for short. The 
word "lib" is a common abbreviation for "library" for english-speaking 
programmers, so if you use the word 'lib the first thing many people 
will think you mean is library. Carl is right that the name reflects 
how the system works in practice. The lib context is a shared common 
import library.

The name exports is not necessarily any better for two reasons:

- Only regular module exports are imported into the common import 
library; the exports of mixin modules are imported directly into 
their calling modules or to the user script context.

- As of the coming system reorg, the core functions of the common 
import library won't be exported from anything, it will be added 
to the lib context manually.

The shared import library won't just have exports in it, it will 
have the core functions that are built before the module system is 
even loaded.

Why would they be referenced a lot?

 - Because we are trying to make using your own versions of the built-in 
 functions as easy as possible, especially through using local definitions 
 of the words. No reserved words in the DO dialect (except the two 
 in MAKE module!). In some cases *only* through using local redefinitions 
 of the words because the built-in definitions may need to be protected 
 from modification. This means that we want to make referencing the 
 built-in definitions as easy and concise as possible. 


This especially the case with the 'sys word, since the context it 
refers to isn't imported by default because it is the context for 
system internals (no, we can't use 'int). When you need to access 
the publicly visible words of 'sys you won't be able to get them 
imported: sys is not a module. You can copy over the words manually 
(maybe with the EXTEND enhancements).


Whether or not the 'lib and 'sys words are defined in the 'lib context, 
they definitely need to be defined where the mezzanines are being 
implemented (which is likely a combination of the lib and sys contexts, 
we shall see). Don't handicap the implementors of R3 just because 
you want to handicap yourself.

Maxim, you made a couple of wrong statements:

it obfuscates the meaning of what that context is...
 (about changing 'exports to 'lib):

Actually, if you read the boot levels blog post, you might notice 
that the R3 module system is now optional at the base boot level, 
and to a certain extent at the sys boot level too. The new role of 
the 'lib context is to be a runtime library - it is not dependent 
on the module system anymore, nor does it necessarily contain any 
exports from anything.

it also makes 'LIB a reserved word in general

Nope, you can override 'lib or 'sys locally in any module or script 
you need to. It might not be a good idea to do so, but that doesn't 
mean that it is not trivially possible. On the other hand, in top-level 
module code the words 'export and 'hidden *are* reserved keywords, 
so watch out.

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 ...