World: r3wp

Because it doesn't work.

At least I couldn't figure out how to call R3 so that it respects 
the boot-level flag.

I don't know, I haven't tested it yet.

My first priority was to get the module system working, and fix the 
slight design flaws that the previous system had (mostly the API 
of IMPORT). Boot levels are next.

You'd be shocked at how many significant subtleties are tested for 
in the test code. And that code isn't even complete yet.

It made sense though: It's easier to deliberately not load something 
when you know what you're not loading.

I'd probably not :)

Be shocked, I guess. Actually, I was just shocked: The mod-test.r 
file only has 696 lines in it at the moment. I guess this is a testament 
to how compact we can make REBOL scripts with the new system :)

Later! :)

Andreas: boot level info is found here:
>> usage

Example:
r3 -b sys


But, this is magic guru stuff because the boot is stopped early, 
which means that most of the nice funcs you depend on are not yet 
alive.

on boot-level sys, you'll also find that the user context does not 
exist, it is the same as the lib context

core
>> print stats
856824

core -b sys
>> print stats
793984

core -b base
>> print stats
573336

Note that -b base is not useful for you (it's for me) because schemes 
are not yet init'd.  It's a bit like booting an OS without the file 
system.

Also, -b sys is somewhat useful, because there is a very minimal 
LOAD that should work.

USAGE says:
	--boot-level L   Where L can be: base sys mods

Reported as #1713.

And from the hostkit: the long option name actually is "--boot".

I like that better. Nice catch.

Quick Q: are modules supposed to actually work with A109?

Because it seems I can't even get http://www.rebol.net/r3blogs/0344.html
to work.

No, they don't quite work in 109. All of the problems with modules 
have been fixed for alpha 110.

But in theory the stuff in that blog should have worked even in a109.

Next week, as time allows, I will be reformatting the module system 
into a loadable script that can work at lower boot levels. This will 
both be good documentation and allow better testing, for the module 
system and the boot levels too.

See here for the bug announcement, in the comments to the release 
announcement: http://www.rebol.net/cgi-bin/r3blog.r?view=0343#comments

As far as I can tell, hardly any of the "basic" features work in 
A109.

Doing a plain import %module.r from the console only works as expected 
if the module is named and not private. Unnamed, private+named, private+unnamed 
modules seem to not work.

Here's what I tried:
https://gist.github.com/cd03af7ddacc2eb9a2e3

Well, looking forward to A110 :)

Despite what the blog says, unnamed modules are a bit of an advanced 
feature in the R3 module system. Normally modules should be named. 
But yes, the bug was in the criteria that determined that private 
import should be done, and all unnamed modules do the private import 
method (in alpha 110+ at least).

Carl really should stop pushing unnamed modules in those blogs of 
his. I know they look cleaner, but they are only for certain purposes.

Poor REBOL if DRY gets relegated to an "advanced feature".

DRY?

Don't repeat yourself.

Oh, you mean like what unnamed modules do when imported more than 
once.

No, I'm hinting at the most simple and straightforward use.

I write a module in a file named %module.r. I don't want to repeat 
that name in a header unless necessary.

Do import 'module and you will be fine - the name gets applied.

In alpha 110 of course.

So by "stop pushing unnamed modules" you mean he should write import 
'module instead of import %module.r?

At the time he wrote that blog the name getting applied feature hadn't 
been added yet.

That was not what I asked.

Do you want him to write import 'module or do you want him to write 
REBOL [name: 'module] or both?

In order to be fully imported into the system, a module needs a name 
that the system can use to refer to it by in the modules list. If 
it doesn't have a name then it can't be reused or referred to later, 
so subsequent imports will reload the module source and create a 
new module. And all unnamed modules import privately, meaning that 
they import into the local context only, not into the system runtime 
library. This means no variable sharing.

The name isn't some random requirement - it means something, it is 
used.

Still no answer.

I don't care how someone wants to write their modules or import statements. 
We have tried to make unnamed modules work as well as we can, given 
their limitations. However, there is a real difference between the 
behavior of named and unnamed modules. For most code it won't matter, 
but if your code depends on that difference then you better make 
sure it loads the way you want it to.

Let's try again.


You wrote "Carl really should stop pushing unnamed modules in those 
blogs of his." I presume this also refers to:
http://www.rebol.net/r3blogs/0344.html

Considering this blog post, would your suggestion amount to:
- A: using import 'simple instead of import %simple.reb
- B: adding name: 'simple to the REBOL header
- C: both, A and B
- D: neither of the above

A, B or C. Or he can continue to gloss over the difference until 
he decides to write a blog about it.

Ah, so retract your suggestion. Fair enough.

I don't want to dictate someone's programming style. That is why 
we have more than one kind of module in the first place.