World: r3wp

I thought about user, downloading a distro. If those are not distinguished, 
I would try to DO each script, just to demo the REBOL. And doing 
a module usually does nothing more than loading the module = nothing 
visually usefull. So I would not mind having .r3, .rm, .rx

(I know that modules are distinguished by the header, but that was 
not the reason to propose having .rm )

If you want to call your modules .rm or .r3m or whatever, go for 
it. We don't have a standard suffix for scripts, but feel free to 
make one. Actually, the default suffix for R3 module files is .reb 
:)

bleee :-)

And that is only used when you are doing lookup by name through module-paths.

if reb, then extensions should be .rex :-)

But servers as Github will not colorize any extension as REBOL code:) 
I like colorized code.

The .rex extension is taken on Windows by a third-party app, but 
that may not matter. The main reason the default extension is .reb 
is because Carl likes it, but the programmer is expected to change 
it, and even Carl doesn't use it. I like .r3 for R3 scripts and modules 
both, because there's really not enough of a difference between them 
to justify a different name, but YMMV. Maybe we can get Github to 
treat .r3, .r2 and .reb as REBOL scripts.

.r3 and .r2 are already... don't know .reb

well, there was even one other suffix, for a compressed scripts, 
was it .rip? I like .r3, .rm, .rx, and those I will use (maybe really 
not necessary to do a separate suffix, I will see). .reb just says 
- nothing ...

btw... it would be good to update the colorizer used, the source 
is here https://github.com/Oldes/RebolLexer

I think that is the real reason the default is set to .reb: Noone 
uses it. People either use .r or .r3, and you are expected to change 
system/options/default-suffix to what you need it to be. That is 
the reason it's a system option.

we are very flexible, what do users think? I want free buttons, different 
extensions. I hope R4 prohibits user to load script, that would be 
best - we should be strict :-)))

No separate extension for compressed scripts is needed, as all scripts 
can be compressed. For that matter, script-encoded compressed scripts 
can even be colorized, though the data is just a big binary. Again, 
YMMV, you might have another opinion about this :)

pekr... "we should be strict "   hahaha    ;-)

if people are distributing their files in a single dir, they will 
have .so, .dll  in the same dir.


can't we just build a little .r file which imports the proper lib, 
no?

Many of you are conflating distribution and usage here.

Distribution is an entirely different matter to what Kaj is getting 
at.

Once your libraries are distributed (and installed), you already 
have the proper library suiting your specific platform.

You won't have 4 .dll's and 10 .so's. You will have _one_ file that 
suits your platform.

And as R3 extensions are loaded via the platform's regular loader, 
you can utilise all the features of said loader.

At which point it makes a _lot_ of sense to not artificially hide 
an R3 extension's nature as dynamic library and just use the platform-specific 
conventions.

Which will generally lead to better tool support and acceptance.

Now for most extensions they: a) won't be delayed extensions built 
into the host, and b) will easily be cross-platform across at least 
some platforms.

Having a simple cross-platform way to load those extensions while 
not imposing artificial naming constraints would be _extremely_ useful.

This is what Kaj is proposing, and I couldn't agree more.

The desired mechanism is simple: give an abstract name, have the 
platform-specific extension taken care of automatically, and then 
fall back to the loader.

And this really ought to be part of the "standard" R3 distribution, 
as it will be used widely and we want to be able to rely upon it 
being there.

I've used a few applications which have their own extension names 
simply because there is a lot of overlap in names and clashing with 
the OS is very easy at some point.

I use many applications which don't use their own extension names.

I'd prefer using system names, only not the system load path management. 
  Rebol, should only look for R3 extensions withing its path configs... 
whatever they are... the R3 extensions *will* use the OS loading 
path, which is normal, since the extension is in fact a bridge between 
the OS and rebol.

And name clashes is what a proper loader is there to take care of.

The OS's shared library loader, that is.

so if a rebol zlib interface is installed, I want the r3 module to 
be loadable using   IMPORT zlib     ... not r3zlib.

Doesn't necessarily have to be IMPORT. I agree with Brian that we 
probably want to have extension loads "stand out" a bit.

it goes beyond name clashes... R3 extensions have a specific duty, 
we are not loading OS libs directly within R3... import must not 
try to access these.


I would prefer to have a specific loader for extensions something 
like.

EXTEND my-extension

which could allow .rx and platform .so or .dll to match the name.

But I want to do `import-extension 'zlib` and not:

import switch system/platform/1 [Linux [%zlib.so] Win32 [%zlib.dll] 
...]

yep we agree.   but I like having .rx also.    its something pretty 
standard on windows to have different names for dlls... the OS itself 
uses different names for various subsystems.

I couldn't care less about .rx.

It's fine if you want to use it, but it makes no difference at all.

Use .rx on Win32, Linux, FreeBSD and whereever you feel like it; 
just don't prescribe its use.

I'd just leave that up to the developper's  as long as the extension 
loader supports both   :-)

It's not only the developers choice, there are also distributors.

But it's easy enough to have the extension loading mechanism support 
multiple extensions per platform.

That's just a matter of definition.

(I.e. define the order in which multiple extensions are attempted 
and define which extensions are attempted on each platform.)

my only issue is that the interpreter musn't look for extensions 
in OS paths cause that will invariably lead to library management 
issues.   


many extensions are simply stubs for real OS libs.  furthermore, 
some stray lib could be picked up and cause dangerous side-effects 
when run by the interpreter.


if an R3 os package is built, any extension packages which are built 
for it, should dump the files in R3's own unique search-path setup.

Maxim, R3 does a simple `dlopen`.

It does no "looking" at all.