World: r3wp

Nonetheless, this is something we want (need?) to do, so the crypto 
infrastructure work will need to be done.

I forgot to mention the LOAD and SAVE option changes in alpha 108. 
Perhaps later after I sleep, if their HELP is insufficient.

Most user code for R3 will be written in 'scripts', not 'modules'.

Lets hope that this prediction will turn out to be wrong.

Thanks for the summary, Brian.

Need to find some time to play with it first, but it sounds like 
"private" modules and/or IMPORT/no-lib/no-user will be most useful.

The charts will help. I didn't have a problem with /isolate and /only 
as names. The new ones sound rather clunky at first glance, but I 
may grow to like them. Most important, I think, are small examples 
demonstrating why we have the various options. I hope the charts 
are the first step on that path.

Thanks Brian!

The new option names are a good choice because all of the /no-* options 
are a way of breaking modules that otherwise depend on acting the 
way that they were written. The whole group of them needs a warning 
label.

Andreas, for library code you are correct, but most end-developers 
just use library code, they don't write so much of it.

My hope is that eventually R3 will be used for more than just small 
and dirty throw-away scripts. And that'll directly induce the need 
for a module system.

My hope is to never, ever come across a "do %..." that "loads" utility 
functions again (in R3).

There are certain advantages to writing user scripts for the front 
end code:

- The user context will be task-local, so a lot of the multitasking 
problems will go away.

- The user context is shared by all scripts running in the same task. 
It acts like a shared isolated context.

- User scripts have fewer settings in their headers. For that matter, 
they can have no header at all. Every command you enter into the 
command line is a separate script, for instance.

None of those sound like an advantage to me. For the "settings in 
their headers" I'll once again have to punt until I look into the 
module system more closely.

Header settings that affect modules only:
- type: module
- name: blah
- version: 1.0.0
- exports: [...]
- options: [isolate]
- options: [private]
- options: [extension]

More than one option is combined in one block. The rest of the header 
stuff affects scripts too.

What's the minimal module header?

REBOL [type: module name: foo] ?

REBOL [type: module]. Or if you are loading it with IMPORT or the 
Needs header, REBOL [].

Well, then that's how it should be :)

Regular modules need a name though. Named modules don't get reloaded 
if you import them more than once, they get reused. There are all 
sorts of tricks you can do with that.

system/contexts/user still refers to the task-local user context?

Yup. Or in scripts, you can call it self.

That task-local thing is still a plan though. The code is designed 
with that assumption, but it's not yet true.

Technically, you can import modules with no header at all, though 
not DO them. Extension modules require a header though.

Of course, headers let you do all sorts of tricks that you can't 
do without them. In addition to the above stuff, header settings 
let you:

- Embed scripts in text or binary files, even if it's just documentation 
before the script header.
- Aggregate multiple scripts/modules in one file.
- Save and verify a script/module checksum.
- Compress scripts/modules.

Just double-checked. No, you need at least REBOL [] for all modules, 
extension or not.

Andreas, the (dis)advantage to private modules is that they need 
to be explicitly imported into your module for you to get their exports 
(selective import). For regular modules, you import into the runtime 
library once and it is just there to share. Regular modules can take 
advantage of this to support upgrading themselves in place, for instance, 
or more easily managing word overrides on a global basis; private 
modules can't be upgraded. Each approach has advantages and disadvantages 
in different situations. This is why we support both export models.

The differences between the two are less if you are importing to 
user scripts. Since scripts share a context, subsequent scripts can 
benefit from the effects of modules imported by previous scripts, 
whether they were private or not.

For me that's purely an advantage. Explicitly importing the modules/functions 
you need is how it should be.

There are real downsides to explicit import. Choose what works for 
your situation.

I'm also pretty sure that upgrading "private" modules is possible.

For instance, with explicit import you can't upgrade a running process. 
That can be a disadvantage for some apps.

But that doesn't worry me at all, at the moment. If R3 ever reaches 
the stability and maturity that such long-running become realistic, 
then I'll start to worry about in-place upgrades.

such long-running processes*

Part of exporting is copying the values to another context, where 
it is used. You don't normally get any references to the original 
module words. And part of importing is copying those words again 
to your own context (for isolated modules and for scripts), or binding 
to the runtime library. So in practice, the only known contexts that 
you can update the values in are your own, the runtime library, and 
the current task's user context. To upgrade other contexts they would 
need to register with you, and you would have to do them one at a 
time.

REBOL processes tend to run for years, if they don't have bugs and 
don't use a buggy REBOL. Do you remember the first mailing list outage?

Luckily, we can change allmost all of that.

But this copying you mention should actually make the updates I have 
in mind easier.

If you meant my last long message by "we can change allmost all of 
that" then no, not in the base system. You can work around it in 
your own code though.

As far as I understood the boot levels allow us to get rid of most 
of the default module system alltogether.

Yup. That is one of the workarounds I mentioned.

Too good a feature to call it a workaround.

What about the mailing list outage?

You say that having not worked with the module system, but yes, if 
you say so :)

I say that having followed the discussion around it and read the 
documentation and posts about it.

And I really appreciate the work you put into it.

The first REBOL mailing list outage happened because the server rebooted. 
The REBOL process that was running the mailing list had been started 
manually, and just kept running. They forgot to add the startup code 
for the mailing list to the init code for the server. But noone knew 
this because the process just kept running for more than 3 years. 
It took a UPS failure to stop the list.

That is the kind of runtime that REBOL is designed to support :)

Ah yes, the legendary REBOL mailing list script.

Times long gone :)

OK, most of the discussion of the new module system so far has been 
in a private world. And the final working system hasn't been released 
yet. And the documentation is outdated. So pardon me if I say that 
you should reserve judgement. But still, being to remove the module 
system with a boot level is a pretty cool feature :)

One which I haven't tested yet :(