World: r3wp

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

There will be ways to make object word references more task-safe, 
but that isn't implemented yet. Focus on that: it's the real problem.

Robert, you can do lazy evaluation using functions that replace themselves 
with their results. Anything more requires a full language semantics 
overhaul, and might not be possible in an interpreted language. What 
do you hope to accomplish?

Most algorithms that would benefit from laziness are done in REBOL 
using code blocks or get-word parameters.

Btw, who is Robert ? Geomol ?

Right-click on their names. They've been here for a while :)

Sorry, i was seeking the post related to laziness from Robert and 
didn't found it....

I was wondering if Geomol was Robert

Geomol is John. Robert's laziness post starts with "Geomol, regarding 
1".

yep, found it now

Sort of...


lazy: funco [code][does reduce [first back stack/block 2 to-paren 
code]]
c: context [
	a: lazy [b + c]
	b: lazy [c + 5]
	c: 2
]


>>probe c
==make object! [
    a: make function! [[][
        a: (b + c)
    ]]
    b: make function! [[][
        b: (c + 5)
    ]]
    c: 2
]

>> c/b
== 7
>>probe c
>>make object! [
    a: make function! [[][
        a: (b + c)
    ]]
    b: 7
    c: 2
]

>>c/a
==9
>> probe c
==make object! [
    a: 9
    b: 7
    c: 2
]

I was thinking named functions assigning results to their names, 
but with debug access that way will work too :)

I used a similar method to write the ONCE function.

Steeve, who are you?
Robert: http://www.colellachiara.com/devcon05/robert.html
Me: http://www.colellachiara.com/devcon05/john.html

Brian wrote "Your idea about a different word type for shared values 
won't work because words don't actually contain anything."


Don't say, it won't work. It can be made to work, if the will is 
there. I can think of many different possible implementations of 
REBOL with the current behaviour, we see. As I don't know, how exactly 
REBOL is implemented (I guess, only Carl does), I won't go in detail 
how to do, what I propose. Anyway, I personal feel, it might NOT 
be worth the efford to implement, what a programmer would observe 
as shared words. The C code will be more complex, and it will probably 
hit performance to some degree. Shared contexts within contexts as 
in R2 is probably just fine. Only problem (as I see it) in R2, is 
that it's difficult to not share contexts within contexts. But the 
R3 possibility to copy contexts can solve that. I think, the current 
R3 implementation of contexts (objects) and the copy semantics is 
far too complex.