World: r3wp

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.

Someone named Nick suggested having make/deep:
http://www.rebol.net/cgi-bin/r3blog.r?view=0239#comments

This could remove the need for copying contexts:

new-object: make/deep old-object [ ... ]

instead of what we have to do now:

new-object: make copy/types old-object any-type! [ ... ]

But the /deep refinement for make would only be used with objects, 
and it's maybe not ok to add a refinement to a function, if it's 
only to be used with one certain type of argument?

If not, then it could be solved with a new function: make-deep, make-new 
to something.

From time to time I ask myself, why I write so much about all this. 
It's because I care for the language, and I see many stange implementation 
decisions, and that's not good.

Geomol, my question was poorly worded.

I was wondering why Brian called you Robert (i didn't see the previous 
post from Robert)

Ah, ok! :-D

Oh my, it's not even enough to just copy/types, I have to do copy/deep/types 
to get a completely new object:

new-object: make copy/deep/types old-object any-type! [ ... ]

Does that look simple? No!

you just need to make a wrapper.

>>make-full: funco [obj spec][make copy/deep/types obj any-type! 
spec]

Is this such a pain in the ass ? ;-)

Yeah! I then need to remember to include this function in all my 
code. It would be better, if the language just did it right in the 
first place. ... time to make my own language. ;-)

Ask Brian for a mezzanine :-)

Lazy: Let's assume I have a quite complex evaluation graph with 100 
input parameters. Think of it like an Excel spreadsheet. Now what 
I want is that if one parameter changes, that all dependent parts 
are re-evaluated. Like Excel does it.

Maybe a constraint solver is  the better word

The problem with Excel is that you can create complex calculations 
quite easy but if you are not the author, doing a reverse engineering 
is tedious. Having an excel like model available on the language 
level would IMO be very nice.

i can work on it, what form of evaluation graph do you expect ?

Geomol, I'm not saying that what you want can't be done, I'm saying 
that you would be creating a new context type, not a new word type. 
The type of a word doesn't in any way affect the behavior of value 
slots that the word might refer to, but the context type does.


However, I don't think that a new context type would be needed here, 
because the object! context is shared by default. The only thing 
you are affecting is whether prototype fields would be shared amongst 
derived objects, or copied. You could easily implement this kind 
of sharing using a mezzanine like FUNCT (not FUNCT, but another mezzanine 
with a similar implementation). There would be no performance degradation 
on use of the shared words, and only minimal at creation time. The 
reslting code would be semantically equivalent to the R2-style shared 
inner object model, but the code wold be simpler.

For that matter, FUNCT/with implements something similar to what 
you request, but with functions instead of derived objects.

BrianH: in regards to #1228 - how can you access unnamed module by 
path notation? I mean - normally you can access unexported values 
by module-name/value, no?

(I probably need to start using them in real-life :-)

You need to import a module explicitly using IMPORT if you want to 
use path notation.

For the most part, you don't access unexported module variables, 
and don't use path notation. Minimal programmer overhead.