World: r3wp

Nothing changes in this situation. Either tell people how they should 
run your script (same problem currently: /View or /Core?) or make 
sure your script runs with the plain, unmodified official downloads.

Sorry for not being here earlier to clear up the misconceptions about 
the module system and functionality split :(

Gregg, you don't have to explicitly import modules into every module 
like you do in the Qtask system. Importing means something different 
in R3.

(Maybe move the discussion to !REBOL3 Modules, while we are at it 
...)

If they were reading !REBOL3 Modules we wouldn't need to have this 
discussion. The info is there already.

But I have a new idea, based on what is possible with the new modules 
(that haven't been integrated yet), so let's move there :)

There is no reason that R3 can't have standard builds that include 
everything. In fact, the blog says as much: Most of the options are 
opt-out based on a command line option, not opt-in. But we definitely 
need some stuff to be opt-in, like graphics stuff on OSes like Linux 
that don't necessarily have the supporting libraries.

Yeah, I was thinking an opt-out command-line option would be the 
best. That way we can keep running with all the functions we've gotten 
used to.

Added bug#1664 "Rename the issue! datatype". I think the basic wish 
is rather uncontroversial, but naming is hard. If you have any good 
ideas for a name, please comment: 

http://www.curecode.org/rebol3/ticket.rsp?id=1664

Perhaps we should shouting names here at first.
btw, I propose the shout! type :-)

Refinements are also words, so I don't think we have to use the *-word 
convention.

yep, I prefer something short and shiny

dry!

ANY-WORD! is a typeset of value: make typeset! [word! set-word! get-word! 
lit-word! refinement! issue!]

Could also use symbol!, but I think it would be a shame to waste 
that nice name on this mundane datatype :)

Or maybe key-word! ...

keyword! or label!

Hm, I was in favour of KEY-WORD! or KEYWORD!, but LABEL! is very 
nice and concise.

R3 boot-levels - http://www.rebol.net/r3blogs/0337.html

It seems Carl got over-voted in regards to using integers instead 
of words as boot options args. We will see, if he will change his 
mind :-)

Am I the only one that *REALLY* hates that  'EXPORTS is being renamed 
to 'LIB?

it obfuscates the meaning of what that context is... I REALLY don't 
care to save 4 bytes if it makes the whole idea obscure.

it also makes 'LIB a reserved word in general, which is not really 
cool either.


I would much prefer if carl at least used the full word 'LIBRARY 
and also 'SYSTEM.. . not 'SYS or 'LIB.


I am sure another word is even better than 'LIB, but 'EXPORTS always 
was perfect already.... so why change that?

Max - please read my comment in the blog article, the last one :-)

I even don't like sys, I thought it is the rename of system, but 
that's not true, so we have got system, and sys. However, it seems 
to me, that Carl needs our eye. I mostly agreed to naming conventions, 
but 'lib and using integer for boot-level is imo an oversight ...

Max - here's the diagram - http://www.rebol.net/r3blogs/0334.html

I am wrtiting a big blog post on Carl's REBOL blog since he posted 
an entire post on this specific rename....

I also stopped to understand, why some R3 related posts appear in 
Carl's blog :-)

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.