World: r3wp

In a CGI use case, that is _definitely_ worth it.

It wouldn't help a CGI script, because it would need to import CGI, 
HTTP, HTTPS, ... ;-)

Don't be that anxious about your console. Once modularisation is 
done, it is ridiculously easy to get back a REBOL console with all 
modules and then some enabled and ready to use just like nothing 
ever happened.

It is the other way round that is hard.

It would help a CGI script a lot, because it won't have to import 
20 network protocols it never uses. But I sure noticed the ;-) at 
the end :)

Oh to have to complain about the overhead of 20 standard network 
protocols...<wistful sigh>


But I take you're point, if my CGI is called hundreds of times per 
day, it adds up. ;-)

I will have to do my own builds - full-fledged rebol - all-inclusive 
:-D

Yes, and you'll be nicely able to do just that :)

yeah, but what about scripts that are put out in the public domain 
- I can see some people forgetting to add includes if their version 
has everything

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