World: r3wp

(Just as READ, OPEN, etc will have to do internally.)

Not sure I want to think about what those simple, generic, rebol-leveraging 
funcs might look like. Still, I'll keep an open mind. Show me the 
benefit and let me count the cost.

If we had a list of modules, along with their cost in memory consumption, 
"clutter", and load time, it would be easy to weigh their value.

Sorry, "weigh their value" should be "evaluate their cost".

$ rebol3 --do what | wc -l
480

(-3, because of some useless startup output.)

so rebol3 is worth 480$ ?   ;-)

+ all schemes (currently only http is bundled with R3), + all functions 
which are not yet bundled in R3 but where available in R2 (cgi, html), 
+ modules which might be worth bundling (database?)

I guess the first step will be to go through these 480 functions 
and group them into some basic modules: possibly core, extra, math, 
debug.

extra == "plus". In a recent CC bug Carl for example mentioned having 
LAST? in core and moving SINGLE? to plus, if it is still wanted.

(And note that all "plus" functions will still be immediately available 
per default.)

I am fully with Gregg here. At least http(s), ftp, smtp, pop, could 
be allowed by default ...

I often use those protocols in console, and I don't want to become 
'import monkey ...

well voice, your needs on the web  ;-)

hum... the comma there makes the sentence a bit weird... ignore it...

Pekr, import [http ftp smtp pop] is tough typing, for sure.

And as I mentioned above, most likely READ will do the import automagically 
for some "blessed" internal modules.

there will probably be shortcuts like import_plus  import_full.

Maybe a pseudo-module named 'full, then import 'full will do.

And I'm sure there'll be a way to just put the import in user.r/rebol.r 
and be done with it.

Andreas, while the typing is simple, do you agree that you aren't 
just going to type it once, and that there is a cognitive overhead 
to defining the imports?

I agree.

Again, I'm not necessarily against it, as long as there is a benefit. 
If the benefit is 3ms faster loading and 30K less memory consumption, 
I will probably say that my time is more valuable than that. :-)

3ms would be a startup time improvement of over 10%.

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!