World: r3wp

except that "init-subsystem" requires no lookup (fast) while "m/init-subsystem" 
requires a lookup (slow)

I still want to have /protect ability though ...

Gab, you did prot -http as a module.  Should all protocols be modules?

actually, when i did prot-http.r there were no modules yet, there 
just was an assumption that we would get them.

anyway, yes, i would guess all protocols should be modules, unless 
they are trivial enough (though, having them as modules as well may 
help with how they are loaded etc.)

Ok, good to know for when we start our rewrites :)

All protocols should be modules, period.

All infrastructure code that is loaded from the host should also 
be in modules or extensions. Scripts are for users.

Pekr, I answered your question in the blog. But in short, exporting 
is about exporting, not about hiding what isn't exported. Exporting 
means adding a word to the (closest thing that R3 has to a) "global" 
context. Otherwise, the word is just available in its local context. 
Modules are there for code organization, not encapsulation. Encapsulation 
is a separate process, and only rarely needed.

Nonetheless, we will be making it easier on a module basis by supporting 
a 'hidden keyword, similar to the 'export keyword.

I wish the word "expose" had been used instead of export... it seems 
more preceise to me.

in that case, just overload the word 'show

Nope - they are exported. Unless explicitly hidden, all module words 
are exposed.

the fewer characters the better

no has fewer characters than yes, but they mean different things.

We don't want to overload the word 'show because there are SHOW functions 
in common use that get exported from modules, and these keywords 
get *removed* from the source during their processing. Also, exposed 
by default was a deliberate design choice.

As was not-exported-by-default.

There are 3 levels of visibility:

- Exported to system/exports, or directly into the requesting context 
if the module is a mixin. Note that it is the value that is exported, 
not the word.

- Visible (or exposed, or shown, if you prefer), but not exported 
(the default)

- Hidden, meaning it can't be bound beyond code that has been bound 
to it already, usually just the module.


There is no point to an 'expose or 'show keyword, because words are 
exposed/shown by default. Hiding words is generally only done for 
security.

From the loading modules doc: "...if a version number appears before 
any module name, it is assumed to be the REBOL system version.

  Needs: [3.0.2 mysql 2.3.0 http-server 1.0.1]

 Is there an explicit alternative? And how would you specify that 
 you need View or Command rather than Core?

And for checksums, would 
 it make sense to allow a keyword before the checksum, so you could 
 choose md5, sha1, or something else in the future? An unmarked binary 
 could still be sha1. I know it maps to the /check refinement on IMPORT 
 as well. I'm just thinking of implicit meaning versus long lifecycles.

Hidden words can't be exported, because the export process has to 
see the words to export their values. This means that the 'export 
and 'hidden keywords will conflict. I can resolve that conflict by 
having one take precedence over the other, but that just seems like 
a hidden gotcha. It seems to me that triggering an error if both 
keywords try to modify a word would be the best approach. What do 
you think?

I agree. Conflicts are fine when they make sense.

Gregg, for R3 the View, Core and Command stuff are considered to 
be capabilities, not builds. With the host kit, we are assuming dozens 
of different builds (afaik). If you want View capabilities, put its 
module in your Needs header. Yes, I'm aware that they aren't yet 
fully modularized, but that is the plan.

Great. I still wouldn't mind the option to have an explicit 'rebol 
key at the head though.

Disambiguation and all that.

I tried that, as a 'core key as well, but it was too difficult to 
resolve potential conflicts with some module of that name. There 
is a complexity budget for the import process.

The disambiguity in the current rules is simple: Only a version-with-no-name 
at the beginning is treated as a system version.

What about 'REBOL as the key? I understand the problem, but the leading 
tuple blows the key-value format.

There is no key-value format, there is a key opt-val-1 opt-val-2 
format. Needs is processed with PARSE.

Check the source of the DO-NEEDS function.

Yes, poor wording on my part. The point being that there is an identifier 
before the version and other information related to a module, and 
the system version is an implicit exception.

Yup. But it's always at the beginning. There's another exception 
where Needs can just be a tuple, and only the system version is checked.

And it's not implicit, it's documented.

I'll cast my vote to allow 'REBOL as an optional key, rather than 
'core, and leave it at that.

Documented does not equal explicit.

All very cool though. It's nice to only pick on little things like 
this. :-)

It turns out that there is no 'system or 'rebol module - it's a chicken-vs-egg 
thing. If it is a module, it can be overriden, so it really does 
need to be special-cased. I don't like that there is a 'core optional 
keyword, because there can also be a 'core module and that isn't 
screened for. But the 'core keyword is there for backwards-compatibility.

I could screen for it in DO-NEEDS, but that wouldn't help with everywhere 
else the modules list is accessed. It would really be better to not 
have any optional keyword at all, but there's that backwards-compatibility 
thing. We'll have to resolve this before we have a real R3 release.

For now, you can have a module named 'core, but you might run into 
gotchas when trying to use it.

Should we do it here?

Sure, let's show how the sausage is made :)

If you are adding a module to the module list, and there is an existing 
module of that name, then the new module either overrides it, replaces 
it, or doesn't get added (possibly with an error triggered, but so 
far not). The question is which one to do in the particular circumstances. 
The factors are whether it is the same module, for whatever "same" 
means here considering it might be reloaded or still source; whether 
the versions are the same or greater; whether the existing module 
has already been made or is still source, and the same for the module 
to be added.

There's also the option of keeping both. That is, my code may have 
bindings to the first instance.

(Maybe that's the "overrides" option.)

Yes.

So far, my guess is that

- Premade modules can't be delayed since their code blocks and side 
effects have already been executed.

- Delayed modules can't be added unless they have at least the version 
of an existing delayed module, or more than an existing imported 
module.

- Premade modules can't be added unless they have at least the version 
of an existing delayed module, or more than an existing imported 
module.

- If a overriding module is added and the existing module is delayed, 
the existing reference should be replaced, not overriden.

- If a overriding module is added and the existing module is already 
imported, the new module overrides the old but the old reference 
is still there.

- If a delayed module is a mixin, the module is made and returned, 
but the stage-two delayed source is kept in the list.
- I'm missing something.

The questions I have are:

1. What do we do when a module is not added due to a policy issue? 
Currently the add accessor returns none if it is a version issue, 
and triggers an error for a checksum violation.

2. How do we determine (officially) that two modules are to be considered 
the same? Name and version?

2. Can we safely LOAD-EXTENSION more than once with the same extension?

3. Does LOAD-EXTENSION on an embedded extension have any side-effects 
beyond creating an object?

4. ... return the same source each time, or different copies of the 
same source? Testable by SAME?

5. Is is safe to delay the object returned by LOAD-EXTENSION instead 
of the source?

6. Should the checksum of an extension include the extension-specific 
source added?

7. Should the version in the header of a module be set to 0.0.0 if 
not a tuple? Currently it is.

8. If so, should module checksums be done after the version field 
is fixed?

Questions and answers posted here: http://www.rebol.net/wiki/Module_Design_Details

Will be edited as the remaining design decisions are made.

Awesome.  Just read through the messages here and will be reading 
the document you linked shortly.

I haven't added documentation for the individual functions yet, since 
they are not yet done. Well, most are, but there might be changes 
required to implement the rest. That is a guru-level doc, but it 
could be used as source material for user-level docs.