World: r3wp

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" -- {"}

python give you the file name and the normal error after... so you 
know where that happened.

So it was a load error then? Interesting that it would return that 
error - I've never seen the like, and modules and scripts are loaded 
the same, with the same code even.

yes error on load... it seems that other errors report the error 
correctly.

Well, LOAD loads scripts and modules alike. Where was the mismatched 
", header or code?

code.

loading a module twice crashes rebol.  :-(

even if its being loaded from different contexts.   

I tried importing vprint in main app and within liquid module... 
I get an "assertation failed" error.

You need to post example code when you find these things out - otherwise 
we can't fix things.

sure! like I did with the needs header   ;-)   hehehe