World: r3wp

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

New test build, all of Ladislav's and my tests pass. Success, and 
agreement, yay!

selfless?: func [context [word! object!]] [
	make object! [
		myself: 'self
		return same? myself first bind [self] context
	]
]

>> selfless? make object! []
== false

>> repeat i 1 [selfless? 'i]
== true

>> upgrade
Fetching upgrade check ...

** syntax error: script is missing a REBOL header: http://www.rebol.com/r3/upgrade.r

>> f: func [/local x] [selfless? 'x]
>> f
== true

>> f: closure [/local x] [selfless? 'x]
>> f
== true

>> selfless? 'rebol
== false

if we want to have the function faster, this version should suffice:

make object! [
	set 'selfless? func [context [word! object!]] [
		return same? 'self first bind [self] context
	]
]

optimized:

make object! [
	set 'selfless? func [context [word! object!]] [
		'self =? first bind [self] context
	]
]

as it looks, this optimization was "too much", since the function 
modifies itself, so either we need to always create a new object, 
like above, or use BIND/COPY at least:

make object! [
	set 'selfless? func [context [word! object!]] [
		'self =? first bind/copy [self] context
	]
]

Thanks, I'll modify the ticket accordingly :)

yes, I found out, that you actually wrote the function in CureCode; 
is the 'self argument already accetable in functions?

Yes. All of both our tests pass now in the new build.

And your version is more secure than mine, which used DO rather than 
FIRST.

if the 'self argument is acceptable, then I probably do not have 
the same version as you do

I use /local self. I was talking about your
    'self =? first bind/copy [self] context
vs. my
    self =? do bind/copy [self] context
Mine has a code-injection risk.

So I switched that line for yours :)

Strangely enough, the code injection risk doesn't come from the DO 
vs. FIRST, it comes from the self vs. 'self. We can't use :self with 
=? in R3 because self is a frame! that evaluates to an object!, not 
an object! itself.

Another way to resolve the risk would be to change the line to this:
    :self =? do bind/copy [:self] context

Or to put a [none!] typespec after /local self.

according to Time-block my version is a little bit faster, but that 
should not matter

>> f: func [/local self] []
** Script error: duplicate variable specified: self
** Where: make func
** Near: make function! copy/deep reduce [spec body]

No, that absolutely matters, because this is a mezzanine that won't 
be turned into a native unless it gets used a *lot*. Carl is convinced 
that the function isn't critical, so we have to make due with a mezzanine, 
if he puts it in at all. And I will insist.

(still not working here, and I downloaded again to make sure

It only works in the test builds. And that was one of my tests, so 
if it doesn't pass I will be surprised.

Carl is convinced that the function isn't criticall
 He's not the only one :)

yes, I used r3c-a97.exe as downloaded just now

Hey, it is the only way to get me to accept #1549. Use the second 
test build (it came out while you were asleep last night).

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

aha, ok, a different name...

There is no special context! or selfless! type, selfless contexts 
are just regular objects with an internal flag (that you can't set 
at all) switched. They display like normal objects, don't survive 
a DO MOLD conversion, and are otherwise undetectable. It's a hack. 
Congratulations!

But all tests pass, even my most stringent ones, so we can live with 
the limitations, like #1552 being dismissed.

Don't take "It's a hack." as an insult. It's a *really good hack* 
:)

no problem with #1552 either

See, I told you that we can live with the limitations :)  But only 
if there is a built-in way to detect the difference. Because I write 
code that has to be secure from attack, and 'self not binding every 
once in a while is a major attack vector that I can't accept, so 
we need a way to test contexts to see if they are safe.

The SELFLESS? function would be even more useful in R2, though it 
would need to be rewritten in it. The optional 'self field is even 
less secure in R2, and causes a lot more problems. The SELFLESS? 
function would be needed there to make conditional code for formatting, 
iterating, reflection, ...

A great discussion with an even greater outcome. I'm hardly able 
to follow, but I love the pure elegance of the proposed solution 
with selfish objects and selfless functions and alike. I'm deeply 
impressed by the security implications your drawing and in general 
all the situations both of you, Ladislav, Brian, with the help of 
Carl and Gabriele, are considering when it comes to answer a question 
which is easy to ask but hard to answer in a satisfying way. So, 
first of all, this is just a note to let you know how much your work 
is appreciated. 


On the other - off topic - hand, it has made me curious especially 
for the security concerns one has to deal with in REBOL. Not the 
kind of security issues you always have to deal with like SQL injections, 
everything related to proper encryption and proper password handling, 
but the kind of rebolish security you have to deal with when, let's 
say, executing arbirtray code. What are the appropiate measures you 
have to take in order to protect yourself from harm, that kind of 
stuff. Are there any documents on this subjects somewhere beyond 
Ladislav's articles?

*your drawing = you're drawing

The biggest REBOL-specific attack vector is functions with get-word 
parameters being passed in as values to functions that don't screen 
for that kind of thing. Get-word parameters can be used to inject 
code into the calling code.