World: r3wp

thanks for the ranking.  I feel all special now  ;-)

Another gotcha to look out for is that if you use the module lookup 
list, the extension automatically added to the script is .r, not 
.r3.

good point.  that should be a configuration in the future IMHO.

I'm reading the official module docs right now  :-)

its funny its sooo close to slim ... and slim is over 5 years old 
;-)

Well, some of the module capabilities aren't done yet (as I mentioned 
above), mostly because most of the system hasn't been converted to 
modules yet. One of the current gotchas is that system/contexts/current, 
system/contexts/system, system/contexts/exports, and system/words 
are all the same object. In the final module system, the first three 
should be separate contexts and system/words should be gone (it is 
now an alias for system/contexts/current).

noted

The requirements for a module system in REBOL are pretty much defined 
by the task and the language semantics, and those haven't changed 
much in 5 years. It's not surprising there are similarities :)

but there is definitely one thing that needs to be added, unless 
its just not documented.   the ability for import to RESTRICT what 
is exported by the module. 

this is the most powerfull concept in slim and I'll never want to 
live without it.  


in slim, its the module USER that has control over the module.  when 
you load the module, by default it uses the module's expose list, 
but if you supply your own, then the module doesn't expose anything 
else than what you ask of it.  


this allows me to have a clean current context, and I can prevent 
my module from cluttering the context its loaded in.  especially 
if its loaded AFTER some code has been defined, or using common global 
words.

this would be:

import/only 'libname [funcname]


where funcname must also be in export, so there is two sided restriction 
... was is available, and what is needed.

the export renaming is something I also use often, here is how it 
could like in R3.

import/only 'libname [fill*: fill make*: make]


meaning, load the module's 'MAKE func as MAKE* in my current context.

as people will start building public modules, name clashing will 
become an increasing problem... there is already some of that on 
rebol.org... altough not much... but there aren't a lot of similar 
libs there either.

or using only one feature from a newer version of a library and all 
the rest from the older one, cause the update isn't compatible... 
that should be allowed.

the way I see it, currently its really complicated to achieve.

In theory the module import list could be more complex, including 
particular imported words (the relevant function is DO-NEEDS). The 
current model is focused on being enough to keep us going with our 
modularization of the system. We intend to refine the model after 
enough real-world use has given us ideas for refinement.

well, I'm giving you 5 years of daily real-world usage above  ;-) 
  a lot of the slim spec has not been used, by natural selection, 
but the above is in just about 95% of all of my code.

I've been giving the module system a lot of thought lately - but 
it needs a bit more...

and I'm like you and pekr... I won't stop whinning about it until 
I get it  ;-)

One thing to remember is that simplicity is a real value here. We 
need to make sure that any features we add integrate well with the 
rest, and don't create a burden on the programmer. Any setting that 
you can make is a setting that you will have to decide whether you 
need to make, so that adds to the development overhead.

brian I know all of that...   /only is a choice, not a burden.   


the way it is setup up now, we are imposed the decision of the module 
author.  its EXACTLY like people who currenly use:

set 'word func [][]


this is very bad design, even more if the module functions themselves 
require words to be global.


PITL requires control over modules.   in all languages which have 
modules, name clashing is always annoying.


python has a very nice module system, cause you import specific words 
or all of a module.   with a few hundred libs as standard they had 
to make it clean.  I think they did their homework.

We already have an /only for IMPORT, and wouldn't need it for this 
purpose - adding the words block to the Needs would be enough.

is the needs header supposed to support file names?  cause its not 
working in A56.  'IMPORT function works properly though.

didn't find any note about this in curecode.... posted new ticket.

Works for me: 

>> write %mod1.r to-binary "rebol [type: module] print 1" 
>> write %mod2.r to-binary "rebol [type: module] print 2" 

>> write %mod.r to-binary "rebol [needs: [%mod1.r]] import %mod2.r 
print 3" 
>> do %mod.r 
1 
Script: "Untitled" Version: none Date: none 
2 
3 


Note that if you specify your Needs in file form, system/options/module-paths 
won't be searched. Any relative filename will be resolved relative 
to the path of the importing script. Does this affect you?

all files are in the same directory.

Oh, I get it, you forgot to make Needs a set-word.,

Needs:

DOH!

to close to the tree to see the forest       ' :-/

Shall I delete the ticket, or dismiss it?

delete it...

Done.

that was such a stupid error.  :-)

Do you know the R2 SDK source well enough to know whether the Needs 
header is handled by mezzanine code in R2? And where?

no idea where the needs is managed.

but a file content search of the whole code doesn't return anything 
relevent to the needs block.

I'd like to backport the R3 module system, but the use of the Needs 
header might be awkward.

yeah... maybe carl can just add a hook for you in the loader.

At least the Core version need syntax is compatible...

yesss, I have the basic features of vprint working in R3... no code 
changes where needed  :-)

can now move ahead with liquid.

Cool. You should have enough rank to post files - tell me if you 
have difficulty.

there is one thing That I did not see documented... how can I get 
the modules to print errors from within?  I just get:
** access error: cannot open: %liquid.r3 reason: none

this is impossible to use for development.

in this case it was a mismatched "  character.

I can't imagine trying to corner that in a 50kb module!

Don't get what you are saying. Is the access error something that 
happens when you try to print from within, or what you want to print?

Or do you want line numbers in your syntax errors or something?

when the application script loaded the module, it printed above message. 
 but the real error was that the module had a mismatched " char...

the same error in the main script would have given a real error... 
 ** Syntax error: invalid "string" -- {"}