World: r3wp

To me, the best way is, if the rules are so simple, you're never 
in doubt when programming. I compare these rules to operator rules. 
In REBOL, operators are evaluated left to right. It's a lot easier 
to remember, than having to look at page 53 in "The C Programming 
Language" every now and then, when I program in C, because I can't 
remember all those rules.


I guess, it would be dead simple, if all values were cloned by default, 
when creating new objects. And then use constants for those, that 
you don't wanna have cloned.

I have never used PROTECT. Do you guys use that? Maybe a warning 
system would be better!? hm

Geomol - with new semantics, you can choose datatypes, which values 
will be copied - copy/types [image!] for e.g., or something like 
that :-)

Submitted my CALL complaints to CureCode. Let's see what Carl thinks 
about it ;-)

Yes, I know. Is it too complex with copy/types? To me, it seems a 
bit complex.

Honestly i don't see the interest to protect things.

All the Rebol scripts are plain texts so that they are readable and 
modifiable by any skilled programmer.

If we could compile some scripts or modules to prevent them from 
being inspected, i would say yes, i will protect some things.
but not currently.

From the docs:


COPY/types - specify as a typeset the values to be copied. Note that 
you can use /types without /deep, in which case the copy is applied 
only to the top level of values.


COPY/deep - perform the copy recursively on each value. If you use 
/deep without /types, it is assumed that you want to copy all series 
values (any-string!, binary!, and any-block!) but not bitsets, images, 
vectors, maps, functions, or objects.


I'm pretty sure, I won't be able to remember these rules, so I have 
to look it up, every time I use it. Result: I will probably not use 
it, if I don't really really have to.

Steeve, I sometime manage to accidently redefine words as TO. The 
result is, my script produce strange results, and it's a hard bug 
to find. I could consider protecting all the system words (there's 
a function to do that). But maybe better, if REBOL could give me 
a warning, when I redefine a system word (or maybe changing type 
of one of my own words).

If it's just for debuging purposes, it's a matter of habits.

Never used PROTECT to debug things because i have different habits

Do you accidently redefine words, you shouldn't have? Or do you have 
your own naming convention of words, so your own words will never 
be called the same as a system word? Or maybe you just are very good 
at remembering all the system words? :-)

Geomol - it might be complex, but it serves the purpose to define 
wrapper functions, like object, context, etc. So you can createy 
- my-picture-obj :-)

First of all, i use local contexts everywhere, so that if i redefine 
a global words, the bad effect is limited.

Second: I mostly don't use mezzanines because i want my code as fast 
 as possible. So, I only have to remember the name of natives.

Third: I love REBOL and practices it every weeks, so it's not a pain 
to remember all the words.

fourthly: Because of that, i never do such bugs (except in old times)

:-) Do you use VID?

I like your habit of local contexts everywhere. I try to have that 
habit aswell.

But sometime I manage to write code like:

context [

main: layout [
	from: field
	to: field
]
view layout
]

See the problem?

I see, you forgot to declare your locals

Right, sometime I forgot those inside layout blocks, and that can 
be hard to debug.

I would modify the VID behaviour instead, to treat definitivly that 
case

Yes, good idea.

This is a dirty hack of the LAYOUT function: you're warned if a set-word 
in the layout is not local.

use [x src][
	src: third find second :layout 'while
	src: first find src/forever block!

 insert back tail insert src [if same? in system/words x:][x [print 
 ["Warning:" x "is global var"]]]
]

for 2.7.6

Seems like I wasn't up-to-date regarding PROTECT in R3.

Geomol, you can protect values already in R3 with PROTECT. Request 
granted ahead of time :)

Yup, I think, it might be a good idea to use that to guide copying 
of content within objects, so we don't have to have this complex 
copy semantics. A rule could be: protected values are like constants, 
and they don't get cloned, when creating new objects. All other values 
get cloned.
Makes sense to me.

A problem is though, if I wanna change such a protected value anyway. 
Then I have to first unprotect, change and (maybe) protect again. 
Alternatively, REBOL would need a new flag on values, that mark them 
as "changable constants" or "not-being-copied values" or whatever. 
A rule could be, that such values doesn't get cloned, but they can 
be changed effecting all objects having them.

R3 alpha 81 out, with the new modules. The existing module docs are 
mostly correct now, though still incomplete.

The module docs were good before, but the module system didn't work 
the way specified. Now it does.

So, finally your changes applied? :-)

Yeah, and only two words were wrong in the released version :)

My bad, not Carl's. The errors caused by the two wrong words are 
minor.

BrianH: is new object creation method already in-place? Does it cover 
the changes, you were suggesting in the past? Or simply put - what 
you think should come next?

The new object creation method is not in place yet, but the R2-style 
MAKE object! semantics are working, as are the COPY changes.

Most of the changes I suggested in the past for object! have been 
implemented using entirely different methods, but they're there.

I would prefer that the next version work on the new object spec 
block and the rest of the copy semantics. The version after that 
can focus on splitting off the system context. After that, I would 
love it if the rest of the PROTECT bugs were fixed.

>> ? in
USAGE:
        IN object word
        Returns the word or block in the object's context.
ARGUMENTS:
        object (any-object! block!)
        word (any-word! block! paren!) 


IN allow a list of objects OR a list of words as parameters but not 
together.

IN context [a: b: 1] [a b] == OK
IN reduce [context [a: 1] context [b: 2]] 'a == OK


But the more powerfull behaviour, to be hable to bind a block with 
a list of objects is forbidden.


IN reduce [context [a: 1] context [b: 2]] [a b] == ** Script error: 
invalid argument: [a b]

Why ????

There's a ticket about that already. "Why?" is that the behavior 
is undefined (as of yet).

don't find the ticket...

#895

It's hard to find a ticket about IN - the word is too common in English.

yep

Uf, I have put extensive comment to the R3 release strategy into 
It came from the outer space blog :-)

Can some of the R3 gurus answer a couple of questions I have regarding 
extensions (DLLs).


1. Is it possible to use a mutlti-threaded DLL? R2 can't receive 
return- data from a multi-threaded DLL.


2. Is it possible to do a callback into R3 so that I can use async 
calls to the DLL? Or do I still have to use a localhost interface 
for this?

No callbacks yet. Max proposed interesting solution - one mezzanine 
dispatcher for one extension handler. You can see his proposals in 
R3 Chat realated topic. As for threading - dunno. There are simply 
still some features missing, e.g. it is not clear how to work with 
Devices yet, but I only parrot what BrianH said, so better wait for 
gurus to give you some real answers :-)

A82 released - other OSes up-to-date now, excluding Extensions ....

It seems OSX A82 is more stable. It can at least launch chat.

I've thought a great deal more about shared content within objects. 
One problem is, they're called objects, because we then think of 
objects, as we understand them in other languages. If we think of 
them as contexts instead, then the goal to achieve is to share something 
between contexts.

Do we want to share words or values?


If we share values, then we could have one word in one context point 
to the same value as another words in another context. We can do 
this today with indirect values (like strings, blocks, contexts, 
etc.), but not immediate values like integers.


I think, it's better to share words between contexts. With this, 
I mean, that some word in one context should give the same value 
as the same word in another context, if I so choose.

>> same? context1/my-word context2/my-word
== true


And if I change the value for my-word in one context, then the value 
for the same word in the other context should change too (if I've 
specified this word to be a shared word). We can't do this with words 
representing immediate values in REBOL. So I see too simple solution 
(simple as in not complex):


1) Either a new type of word, the shared word, is implemented in 
the language, and this can handle both immediate and indirect values.

2) Or the simple R2 rule is enough. In R2, contexts within contexts 
are not cloned, but everything else is. We as programmers then have 
to put our shared words (representing all types of values, both immediate 
and indirect) inside contexts in our contexts (or using the REBOL 
terminology: inside objects within objects).

(Ah, good to get all this off my chest.) ;-)

... or we work with what we've got, which covers your requests, albeit 
a bit more complexly, otoh without the need to introduce new word-type 
:-) As for your second point, I want to have freedom to clone/share 
anywhere, not just whery system prescribes me to do so (subobject). 
You can post your comment to R3 Chat, to see what Carl thinks. Hopefully 
some other ppl will comment here ... especially Max ... where's MAX, 
when you need him? :-)

Geomol, regarding 1: Sounds good to me. And maybe we can make a big 
step forward to lazy evaluation including immediate values.

Robert - do you need such lazy evaluation? I mean - even 'alias seems 
being removed from R3. Don't we have enough of reflectivity? Anyway 
- anyone who imo wants to propose something, should definitely do 
so in terms of CureCode or R3 Chat, or Carl WILL NOT know about the 
request at all, and your only chance here will be BrianH :-)

Robert:

1. The extension interface is currently single-threaded, but that 
shouldn't affect what the DLL does inside itself.

2. Devices are the standard R3 method of handling asynchronous behavior. 
Though the extension interface currently doesn't support the creation 
of devices, that is intended to be supported next. Maxim's callbacks 
may be supported too, but what you are talking about is a job for 
devices.

Geomol, the main problem with sharing is doing it in a manageable 
way. The advantage of using explicitly shared contexts is that you 
can know where your values are and distingish them from non-shared 
values.


Your idea about a different word type for shared values won't work 
because words don't actually contain anything. All values are stored 
in contexts, blocks or type-specific containers. All values "assigned 
to words" are contained in contexts, no exceptions. Even function 
words are associated with contexts. The question is which one.

R3 has two context types already:

- object!: Similar to system/words in R2, though for some internal 
instances (like error!) expansion is blocked. Direct reference.

- function!: Not expandable, stack-relative reference. Task and recursion 
safe.


Closures have object-style contexts, with a new instance created 
with every call (with bind/copy overhead on the code block, sort-of).