World: r3wp

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").

It shouldn't be a problem once we have the documentation. The /no-* 
options were named consistently like that by Carl for a very good 
reason though, to set them apart from the other options. The /no-* 
options can't be specified from the Needs syntax; this was a deliberate 
design choice, as every one of the /no-* options breaks normal module 
behavior in specific ways that would affect the design of the module 
code. As such, these needed to be exceptional cases rather than normal 
behavior.

If import/no-share and options: [isolate] have the same effect, using 
the same name seems appropriate.

If they don't, then nevermind.

I'll bring that up with Carl. He does the API design, at least the 
stuff that is arbitrary.

I only do the stuff that is inherent in the semantics of REBOL. And 
the implementing, of course.

Renaming wish submitted as #1807.

Moving this discussion what suffix to use for modules from !REBOL3 
Proposals:

Brian said:

No, you're not really supposed to use .reb, you're supposed to change 
the setting to what you were going to use anyways.


That's why the setting is .reb: There is no consensus on what extension 
to use, so the setting is set to something noone uses."

This is a distribution nightmare.

I strongly suggest that the default-suffix be changed to something 
practical which stands a chance of reaching consensus.

Module path searching only works with non-file! module names. I.e.
import 'foo

will search the system/options/module-paths for a file name %foo.reb. 
This search is a _very_ useful feature which we shouldn't rid ourselves 
of by stupid wars over which suffix to use.


As a module author, I want to use a suffix which I know will make 
using the module easiest for my target audience.


As a module distributor, I also want to make it easiest for my target 
audience to use the modules _and_ I need to enforce consistency within 
my distribution.


The only one who does not really care about the suffix is the actual 
user. The user just wants to use third-party modules without having 
to homogenise their suffixes first. But the burden of choosing a 
sensible suffix is currently imposed on the user. This does not make 
much sense.

To be more precise: having a default which is actually intended _not_ 
to be used does not make much sense.

Having a default which _is_ intended to be used would be a strong 
incentive for both authors and distributors to stick with this default.

This vastly reduces friction within the wider ecosystem, making life 
easier for all parties involved.

I can only say that Carl set the default, but I haven't seen any 
published scripts by him that use it. Good point, Andreas. Too bad 
we can't settle on .r, because R has taken that extension in most 
standard tools, and OSX uses .r for something else.

.rez resource files. It's a pain.

Here's another interesting trick: Make %rebol.r a unnamed module 
by putting type: module in its header and not giving it it a name. 
This isolates the words in it in its own context instead of putting 
them in the user context, controls the visibility of its code, and 
makes it easier to free up the memory it uses because its context 
is thrown away afterwards. It's the perfect occasion for an unnamed 
module: run once, and done for effect.


%rebol.r is a great place to set your preferred system/options/module-paths 
and system/options/default-suffix, to delay-load commonly used modules 
and extensions that you have checked out already, and to patch or 
wrap anything that you need to.

%rebol.r is run before any user code is run, even the --do and --import 
args. This makes it the best place to hack the module system for 
your own uses.