World: r3wp

First bugfixes appearing in CureCode  for A98 ....

Self reflection - http://www.rebol.net/r3blogs/0312.html

I wonder how the 'self discussion resolves. Brian - Carl just pointed, 
that the description to #1549 ticket is not clear to him .... there 
is also new Doc page to it - http://www.rebol.com/r3/docs/concepts/objects-self.html

I'm reading the page. So far it reflects the surface behavior of 
my proposal, but is less detailed so I can't say for sure.

it seems pretty straight forward to me.

I would like to more understand the 'self topic :-) (well, maybe 
I will never be able, but ...) .... what is the difference between:

- field
- flag (eventually)
- and - keyword?


Is that the field is a real variable (word), flag would require some 
internal storage, but is not an user level value/attribute of the 
context, and keyword is just something like flag known in runtime 
during execution? But 'self, being a keyword, has to be somewhere 
stored too, no? :-)

The word 'self, when a keyword, only has the storage for the word 
value itself; it doesn't have any associated value slot in the object. 
A field of an obhect has a value slot in the object. And a flag is 
internal, probably just one bit somewhere.

So a keyword only takes up as much space as an unbound word.

so the word 'self keeps pointer to context it is bound to?

Yeah, but it's a special binding, with just a reference to the context, 
not to a field. The object doesn't have a 'self field. The 'self 
keyword is currently just a side-effect of the BIND and IN functions, 
not something that is really in the object.

That's why the previous debate about this was so confused - that 
info wasn't known back then.

why the change from R2 model, where it was a field? Was it troublesome 
for iterators, which counted 'self as a regular object word?

Yes, plus it took a lot of space (it adds up). Plus the objects that 
didn't have that field behaved badly - such objects were created 
to serve as function contexts, or by functions like USE and FOREACH. 
Since all of the code that worked on objects had to skip past the 
first field ('self), if the first field wasn't 'self it was still 
skipped. Plus the 'self field was writeable, which made code injection 
attacks possible when running untrusted code - not really a concern 
for R2 with its known insecurity in such situations, but for R3 it's 
a design criterium to be able to sandbox code. It is really better 
to not have the field at all, and just make it a keyword in certain 
limited circumstances (imo).

This wasn't really much of a problem for experienced R2 developers 
because they learned the workarounds and checks necessary to add 
to their code to make it work. Or in the case of things that work 
badly or not at all, they got used to not doing those activities, 
no matter how useful they would be. It was a "good enough is good 
enough" situation, with noone asking whether it really was good enough 
until the R3 project started.

This is why arguments like "We never needed to do that before!" break 
down. The reality is that we *didn't* do these things before because 
we couldn't, or because it wasn't safe, not because we didn't need 
to.

Does the situation also change because on some new models to R3, 
as e.g. separated user/script/module contexts etc.?

I don't undersand all the fuss about the 'self :-) Is your and Ladislav's 
point of view really so different here? :-)

... and also - does Carl's new doc provide you with some explanation, 
how actually 'self is handled in various situations?

Not really. But the change in function evaluation affects it somewhat.

Carl's doc is too high-level to be helpful here. His list of tests 
is better, but still incomplete.

Carl put temporary decision to the 'self case ... we are probably 
very close to A98 release ...

Looks like the argument has been settled. Good for us :)

A98 released - see R3 Chat ...

sorry, marked as A97, Core only, for the purpose of 'self testing 
...

wow that 'self topic has become pretty intense.  just one question 
left...  

what color gloves (boxing) are  Brian and Ladislav wearing?   ;-)

Hey, I did my best to express his point in a timely manner in a way 
that would be understood, same as with the opposing points. There 
was a lot of discussion that had to be gotten across quickly to Carl, 
so that he could make a final ruling. And it looks like a refined 
version of Ladislav's proposal was chosen. So we did a good job :)

my gloves are blue, Max (I live in a Blue Street)

hehe... fighting with gloves ON is ok  (that was my point btw. ;-)

The 'self test doesn't seem to be working as expected so far, at 
least for closures and loops. Weird.

Ladislav, for comparison I added the tests from the blog to #1543, 
#1544 and #1549. Take a look and tell s what you think. English is 
overrated - clearly, we should be expressing our arguments in REBOL 
:)

tell s -> tell us

Right,Brian, in REBOL it usually is less ambiguous, that is why the 
Bindology article contains that much Rebol code

I added your philosophical point tests to the example code of the 
#1549 ticket, and the practical tests to a comment. Please check 
both.

And test them against the build linked above, to see whether they 
match. There doesn't seem to be a SELFLESS? function yet, so the 
downsides of the proposal haven't been resolved yet by the posted 
build.

In the posted build, functions are fixed, but closures and loops 
aren't yet.

If my last tests are more understandable, then I am able to simplify 
the #1549 wording by removing older text, etc. keeping and explaining 
only the newer tests

does that make sense?

BTW, I wanted to edit the TO-BINARY function description in R3 documentation 
to explain the "network bit order", but did not succeed; while I 
edited some parts of the documentation, now I am unable to log in, 
and have no idea why (posted a private MSG to Carl in R3 chat, but 
he may have missed the message?)

Sure. Btw, your philosophical tests pass now, at the expense of other 
bugs continuing, including the return of #447. The practical tests 
show the errors in question. Basically, #447, #1528 (for closures), 
#1529 and #1552 are still problematic.

Is there somewhere I can get A98?

We are all asking that

Updated the practical tests to explicitly test for the missing fixes 
(except #1552). Go to R3 chat for the link to the build.

OK

there is no A98, just A97 core, the link is in R3 Chat ...

http://www.rebol.com/r3/downloads/r3c-a97.exe

I was trying to avoid posting that link in a web-public forum.

yes, but why?

Don't know :)

OK, so I solved it then :-)

(From chat #7216) Some tests pass, others fail. It's a good start.

- The tests in the example code of bug#1549 pass (Ladislav's philosophicals)

- The practical tests don't. In particular, bug#447, bug#1528 (for 
closures), bug#1529 and bug#1552 are still problematic.

- We need a SELFLESS? function (or whatever it should be called) 
to resolve the main downside of the #1549 approach, and we need it 
for the a98 release.

Here are the practical tests that need to pass:

; Objects
ob: object []
print same? ob do bind [self] ob
print same? ob do in ob [self]

; Functions
ob: object [f: func [/x] [do bind/copy [self] 'x]]
print same? ob ob/f
; Can't use the context after the function returns.
; This is not a side effect of Ladislav's proposal.

; Functions with a 'self parameter (#1528)
ob: object [f: func [/self] [do bind/copy [self] 'self]]
print not same? ob ob/f

; Closures (#447)
ob: do closure [x] [bind? 'x] 1
print 1 = ob/x
print not same? ob do bind [self] ob
print not same? ob do in ob [self]

; Closures with a 'self parameter (#1528)
ob: do attempt [closure [self] [bind? 'self]] 1
print 1 = attempt [ob/self]
print not same? ob do bind [self] ob
print not same? ob do in ob [self]

; Closures shouldn't bind 'self unless it is a parameter (#447)
print same? self do closure [x] [self] 1
print not same? self do attempt [closure [self] [self]] 1

; Loops (#1529)
ob: repeat x 1 [bind? 'x]
print 1 = ob/x
print not same? ob do bind [self] ob
print not same? ob do in ob [self]

; Loops with a 'self variable (#1529)
ob: repeat self 1 [bind? 'self]
print 1 = attempt [ob/self]
print not same? ob do bind [self] ob
print not same? ob do in ob [self]

; Loops shouldn't bind 'self unless it's a variable (#1529)
print same? self repeat x 1 [self]
print not same? self repeat self 1 [self]


See also #1552: There needs to be a way to distinguish selfless contexts 
from selfish contexts at runtime (a SELFLESS? function), and selfless 
contexts need to MOLD into DOable syntax (perhaps a different datatype, 
or a flag).