World: r3wp

No, not everything! Thats the point, that it works with some basic 
knowledge and the rest can be ignored.

(althouh they really suck in python)

Pekr, all the libs will do it. Or will maybe. Be prepared or burned.

what will all libs do? what libs?

The löibs in all that namespaces!

multithread. And change your uncopied data.

wasn't it mentioned that make task! will invoke OS thread, but no 
shared code sections?

(depends on implementation. we where starting with blindly copying 
other languages without rebolizing them, as i understand

where did we start copying other languages?

A rebolized or erlangized multithreading is something else.

so far I can see only logical additions to get into programming into 
large ...

Maxim: "what I have seen a lot through the years about people suggesting 
things (me included) on how to improve REBOL, is the tendency to 
ask for things from other languages."

Maxim: "I have somehow changed my perspective in that I find myself 
asking things like, why should I be doing that in REBOL"

I would add "how to do them in rebol". In case of namespaces, maybe 
a more dialected approach could be usefull.

but I also think things could be added as features, if we want any 
adoption or PITL, but rebol itself should not depend on them.

because it makes sense and because you want? What is the point in 
being different just for the sake of being different? Rebol's design 
is different, and adding namespaces, tasking, better event model, 
etc. does not ruin Rebol principles ....

modules add something we cannot DO in rebol, unless you become guru.

making a dialect is not trivial, however you want to approach it. 
 you must "understand" REBOL to a certain extent.

If i have to learn them it ruins rebol. if rebol is not dependent 
upon, it does not.

A parse-rule is not that different from a set of functions. And the 
way to write them could even be changed closer to functions.

making classes, functions, and data private and untouchable for security 
and code stability reasons are things which would allow REBOL to 
PITL.

Volker - then any new concept addition will ruin rebol for you, as 
you will have to learn it ... View is gonna be overhauled too - changes 
to face and who knows what .... from recent blogs, I can only see 
positives in getting them. I have a trust in Carl and that he is 
going to do those things in sensitive way ...

sorry to argue Volker but parse is not easy to grasp.

I can use /core without knowing about view at all.

Volker and Pekr, you are on the same side  ;-)

parse is not easy to grasp. but its not the only way to define dialects.

nope.

iirc modules will not intercept basic code and aproach to code? You 
don't have to use them at all?

As dialect-grammars can be parsed by parse and urned into parse-rules.

modules they are simply protected contexts with rules on sharing 
data to-from the modules.

I have implemented many dialects which are 100 miles from parse.

Glass was an example of a programmable dialect.

(the old glass, from 5 years ago)

is there any new glass? :-) (as you talk about old one ...)

I'm not saying parse cant do anything... its just something some 
people "get"  and some others dont.  I am of the latter kind.

yep. the one which is being worked on right now.

hence the !GLASS group. :-)

I am not against modules. I am against thinking "put things in namespaces 
and you can hide and forget them and they still work smothly together". 
That works when i am ready to hide a lot more than i would write 
otherwise. (that "only 25mb!!"-thing)

as with anything Volker, tools dont guarantee success.  useage of 
them does.  imagine rebol without contexts?

modules just extend them and allow us to make SURE they don't affect 
other code and dont get affected either.

I just don't want REBOL itself and all its mezz code or view to become 
private.

which is where Volker, Pekr and I agree I think  :-)

If they are used like this, i agree. But its easy to build modules 
which depend on modules. And i often hear "lets build great libraries 
for everything". If they are really used to keep stuff out of the 
way, without adding dependencies, i think on us we agreeing :)

(hum, my grammar..)

hehe

I guess the question is does library code isolation *need*  a language 
extension like modules or namespaces?

Or are existing contexts good enough provided we take care to avoid 
creating global words?

but protection is be required.

I opt for auto-protection for global words. So i think modules are 
a good think.

I wish the damn protect word had an option to make unprotecte impossible.

how can I garantee loaded code is safe?  ITS IMPOSSIBLE once you 
say OK to file I/O