World: r3wp

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.

There are real consequences to whether a module is named or not, 
but both styles are appropriate in different circumstances.

Bad typo: Ah, so you* retract your suggestion.

No, named should still be considered the default behavior. Unnamed 
is still exceptional.

If that weren't the case we wouldn't have added the IMPORT word! 
applies the name feature.

Well, then I simply observe that you don't want to give a straight 
answer to above question.

Or let's add, E: "Exactly one of A, B, or C", assume you chose E 
and be done with it.

Even the simplest discussions can be surprisingly hard when the means 
of communication are reduced to text.

I don't write blogs. If his purpose is to make the module system 
seem simpler than it is, cool. It can be that simple in practice. 
When called from user scripts there is very little difference between 
regular, unnamed or private modules. The context of user scripts 
is isolated, so all the values are copied into it afterall. It doesn't 
really become a big deal unless you are concerned about when words 
are added to the user context, or until we get concurrency going.

It matters a *lot* for modules that are imported into other modules, 
but no blog has mentioned that situation yet.

Hardly worth mentioning until it actually works.

...and is released in its working form. That first part is covered 
already.

I've not read the entire discussion... but let's roll back a little.


Andreas, simple things should be simple. A REBOL rule. So some points 
on modules:


1. We've used objects as "a type of module" for many years. Pretty 
easy.


2. The first thing you do is give them a new datatype, calling it 
module!  But, still basically an object. Easy.


3. Next, you make it clear what is exported... with the EXPORT word 
or EXPORTS block in the spec. Still easy.


4. Next, you want the runtime system to help keep track of the module. 
To do that, the module needs at least a name to identify it. Not 
difficult.


From there, you can imagine many other features you might want: versions, 
checksums, compression, dependencies (needs). You can add quite a 
lot. But, the more you add, the more likely it's going to get complicated... 
and few users will understand it, etc. So, for R3, Brian and I agree 
to a design that provided quite a few features without too much code, 
but also kept simple things simple.

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.