World: r3wp

Agreed on all 4 points. But those are easy.

The devil's in the details.

You bet it is.

For example, for 4. it would be sufficient to always derive the module 
name from the filename.

Obviously someone decided against that simple solution. And I am 
sure for good reason.

The word "sufficient" there isn't quite true.  Explicit naming is 
more powerful... and provides a map as well from name to filename.

The rest of the above banter was just me getting lost in a particular 
question.

Module systems are always difficult.

Brian and I have both used quite a few... but not really cared much 
for most of them.

A110 will release all the code for the module system, and you can 
browse through it.

There's always room for improvement, but I'm goint to be the complexity 
firewall... because they so often become unusable.

If anything, I would aim improvements at simplifying further.

But it's basically impossible to have a sensible discourse about 
this module system without being able to try it out.

It _is_ already far too complex for that.

I like the idea of not needing to repeat a name = name the module 
automatically upon the filename. "However, there is a real difference 
between the behavior of named and unnamed modules." - why? Because 
someone said there should be a difference? So just not explicitly 
naming the module means it gets treated the different way? Why? And 
what was the technical reason to decide so?

Of course - auto-naming unnamed module according to filename might 
be tricky - what if file contains more than one module?

modules within modules work fine from A108.  I've required this feature 
in CGR.  I am using the named version though (I'm conditioned by 
slim which also makes this the default and simplest use case).

if the module has a name and you rename the file, it should fail, 
which is probably what it does already.

in slim I also added an extension filename, in order to allow import 
by name to work with alternate extensions which is very usefull when 
you want to use the module system as a plugin mechanism for an application.

extension filename  == "filename extension /refinement"

Technical reason = because one has a name and the other doesn't. 
I'm not dumbing it down, it really is that simple.


Say you are a module, and I want to import you. It's rather straightforward, 
I just add your exported words to my collection (how I do that depends 
on what I am, but that's a story for another time). And then I can 
use those words, no problem.


But what if I don't know whether you have been imported already? 
Or what if I know you have been imported by someone else, but I want 
to use you in particular instead of someone who just looks like you? 
Or what if you have data that you want to share, or resources that 
can't be used more than once at the same time? Or what if you want 
to know if a previous version of you was imported already, so you 
can get that guy's data or resources and take over for him?


To do all of these things, you need a way for others to refer to 
you, a name. If you have a name, I can put you in a collection with 
other modules and then others can look in that collection for a module 
of that name and if they find one they can know that it's you. Simply 
having some way to find you in a crowd makes all of that stuff possible. 
It really is that simple.

Another trick that I can do if I have a name for you is to just put 
you in a box and then import you later: delayed modules. If you don't 
have a name, I can't find you in that box, you look just like all 
the other delayed modules.

It turns out that every little feature or quirk of the module system 
is there for a reason that is as simple as that. It's just that there 
are a lot of these little situations that pop up when you are writing 
a module system if you want to make it work properly. Especially 
if you want to hide a lot of that complexity from the user, to deal 
with the complexity in the module system itself so the programmer 
using it doesn't have to think about any of that. Simple on the outside 
requires some complexity on the inside.

Carl, how simple would it be to implement REFLECT module! 'title 
? See here: http://www.curecode.org/rebol3/ticket.rsp?id=572(low 
priority still).

As of alpha 110, all tests of the module system pass! Time to write 
more tests :)

Regarding REFLECT... would store the spec in the module! object. 
There is room for it.

Glad to hear it!

Time to show examples of all of what it can do... and get developers 
using some of this good stuff.

The spec is already stored in the module object.

Or what do you mean by spec? The module header returned by SPEC-OF 
is stored in the module object. See here: http://www.curecode.org/rebol3/ticket.rsp?id=1586

Let's switch this discussion to where it belongs.

I was referring to my understanding that many module-related things 
are half-broken at the moment.

Last time this came up, you (Brian) seemed to be aware of the problems.

As it seems those issues are forgotten by now, I guess I'll have 
to dig them out again.

No, they were fixed in a110. We had that discussion before a110.

No, we had it post A110 and you said "whoops, last-minute errors 
slipped in".

I'm digging ...

That was a109. There was another las-minute error that slipped into 
a110, but it wasn't a module system error, it was a startup error.

There has only been one issue in the modukle system itself (aside 
from the possible cURL thing) that has been discovered since a110, 
and that is not as much a bug as it is a gotcha, and hasn't been 
reported yet.

(stupid typos in recent messages - bad keyboard or fingers, can't 
figure out which)

Ok, seems the bugs I was referring really were in A109.

At least those seem to be gone now in A110. So maybe it's time to 
look at this stuff again.

Yeah. We have a pretty thorough test suite for modules, and all tests 
pass for a110. And I checked the tests for accuracy too :)

Probably time to publish this test suite.

In any case, if A110 is deemed good, I'll certainly have another 
look at the module system.

Sorry for spreading FUD based on me mistaking the A109 bugs for still 
present in A110.

Most of a110 was dedicated to fixing those bugs, so I understand 
and appreciate the sentiment :)

I can get to the publishing of the test suite next week, barring 
unforseen stuff. This week is going to be swamped for me.

Maybe using the same name for the "isolate" option and the "/no-share" 
refinement would be a good idea.

I.e. either isolate for both, or no-share for both, or something 
else for both (like "private").