World: r3wp

I think I know what trouble novices have though .... when you look 
at C or java-script like languages, it is clear what is happening, 
even if you don't know exact meaning of function name ... but imo 
with rebol - novice is looking into longer sequences of lots of english 
words, without parens, so the programmer can't immediatelly map to 
what is done and when .... :-)

just like trying to understand a german sentence  ;-)

A thing that hurts is this copy-thing. You have to know it, that 
effct occurs everywhere. Thats what i call a core-"feature".

but its a feature. its not a bug.

it has to be made clear to newbies from the onset.

(i meant "hurts if you dont know it")

I was burned just as bad in python and its the other way around.

imo every novice will go into the same kind of trouble with references 
issue .... but iirc Core docs in pdf explained it even graphically, 
so I would urge novices to learn those facts first ...

but the documentation, when I looked, made it very clear.

Or multithreading would be a core-feature, or language-feature. If 
it is present, you have to expect random changes everywhere.

Volker, not much harm, I mean Rebol not showing everything at first 
look so you don't need worry about mastering everything

if you don't need it - don't start other threads then :-)

I dont think so.  python does multithreading and its just something 
you start once you need it.

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