r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Andreas
25-Mar-2010
[1945]
More like map!, I guess, but yes.
BrianH
25-Mar-2010
[1946]
It's an alternative that wouldn't work: We'd still need /self or 
/no-self. For that matter, BIND has that option already, internally. 
It can be used by native code only, for now.
Andreas
25-Mar-2010
[1947x2]
Why would we need that?
Use context!s internally, wherever you are currently using object!s 
with bind/no-self
BrianH
25-Mar-2010
[1949]
The suggestion to add /self or /no-self to BIND is only a suggestion 
to make a proven, already existing, already used internal option 
externally visible.
Andreas
25-Mar-2010
[1950]
I agree about everything but the "proven".
BrianH
25-Mar-2010
[1951x2]
Proven to exist (by bug#447).
I don't see the point to another datatype which is *indistinguishable 
from object by all code that would accept it*. The only code that 
wouldn't accept it is BIND/self (the current BIND behavior). And 
BIND/self is the only way to see the 'self field at all - otherwise 
it basically is not there.
Andreas
25-Mar-2010
[1953x3]
The point is that we would have a clean way to refer to an environment 
which is not conflated with an object.
And it's not indistinguishable from all code accepting it; it makes 
a big difference to code that uses BIND.
And finally, you still don't see that this only makes sense as a 
combined proposal with adapting BIND to predicate behaviour on the 
type of context.
BrianH
25-Mar-2010
[1956]
But no reason to - there would be no difference that you could detect. 
If you don't use BIND/self, you can't get access to the 'self word 
at all. So if you can't get access to the word, why would it matter 
if tit's there?
Andreas
25-Mar-2010
[1957x2]
So it's really about: context! + object! + bind without /self or 
/no-self
And if that all matters is a question about how you assume typical 
BIND code to look like. Ladislav's point (at least as far as I understand 
it, Ladislav please correct me if I'm mistaken) is that there are 
situation in which I as BIND user don't know whether I want to do 
BIND/self or BIND/no-self on the context.
BrianH
25-Mar-2010
[1959x2]
But that wouldn't work: Leaked references to 'self would cause security 
holes. There is no code where the existence of 'self *matters in 
any way*, that would be safe to accept your context! type. So context! 
has no purpose - it would be *exactly the same as object in all code 
that could possibly work on it at all*.
The situation where the user of BIND doesn't know whether to use 
/self or not, is a case of a non-programmer trying to program. REBOL 
doesn't try to solve that problem.
Andreas
25-Mar-2010
[1961]
Ok, this view is certainly a way to avoid the problem.
BrianH
25-Mar-2010
[1962]
That problem can only be solved by the programmer reading the docs 
and making a decision.
Ladislav
25-Mar-2010
[1963]
Leaked references to 'self would cause security holes.

 - interesting, when checking the situation of Repeat, e.g., for me 
 the references to 'self are "leaked", are they a security problem?
BrianH
25-Mar-2010
[1964]
Any code that can access 'self depends on being able to access 'self. 
For any code that doesn't access 'self, the existence of 'self doesn't 
matter.
Andreas
25-Mar-2010
[1965x3]
I think continuing to argue here does not make any sense.
You categorically ruled ou that there is code where the user of BIND 
does not know (or care) whether SELF is of importance. Anything that 
follows after that is only begging the question.
In any case, adding a BIND/self refinement would certainly be an 
improvement over the current situation.
BrianH
25-Mar-2010
[1968x3]
REPEAT et al doesn't need to have 'self be bound in its code block. 
But if a reference to the object created by REPEAT persists after 
the function ends, any subsequent use of that object would either 
need to use its 'self, or not see its 'self at all. REPEAT *can't* 
know which. If the object is used by any code that needs to see 'self 
(like BIND/self) then that 'self absolutely must be there, because 
the otherwise the 'self references in the code block would retain 
the bindings they had before, which will likely be encapsulated code 
in a module (this is R3, remember). If the object doesn't need to 
use 'self, *it can't*: The reflectors, the formatting code, and BIND 
without the 'self trick can't tell if there is a 'self there or not, 
so if it's not there it *would make no difference whatsoever*. So 
all you are proposing is to make a datatype that doesn't contain 
a hidden 'self field, but which can *only* be used in cases where 
there not being a hidden 'self field is something that doesn't affect 
it at all.
If you make the loops and closures create a non-object that doesn't 
have a 'self field, all that you have done is make those objects 
not usable where the existence of the hidden 'self field matters 
in the slightest. And for code that doesn't use the 'self field, 
it doesn't *see* the 'self field either, and can't tell that it is 
there or not. So you have added nothing, and taken away something 
that might be useful for no good reason. It's a bad idea.
Yes, I like Ladislav's BIND/self proposal. The /self option would 
be used where 'self matters, and otherwise not used. Good balance 
to that.
Ladislav
25-Mar-2010
[1971]
I am not sure, whether I understand my proposal ;-) What does it 
mean for code like:

repeat self 4 [...]

?
BrianH
25-Mar-2010
[1972x6]
You can do that now: The hidden 'self is overriden, and the 'self 
trick doesn't apply. Like this:
; Current behavior: 
>> a: construct [] 
== make object! [ 
] 
>> append a [self: 1] 
== make object! [ 
self: 1 
] 
>> do bind [self] a 
== 1 
>> protect/hide in a 'self 
== self 
>> do bind [self] a 
== make object! [ 
] 
>> same? a do bind [self] a 
== true
See, the override 'self can be modified, isn't hidden until you hide 
it, and easily overrides the hidden 'self like any other hidden field.
And if we BIND/no-self on a object with an overriden 'self field 
we can still see it. And if the override 'self is hidden, BIND/self 
doesn't unhide it, it inly unhides the original 'self.
And UNPROTECT will unprotect an override 'self field, even though 
it refuses to unprotect the original 'self field.
I don't think you can unhide a field at all, let alone 'self.
And you can't override a field unless it's hidden.
Gabriele
26-Mar-2010
[1978x2]
Ok, so let me try to recap this huge discussion. In R2 we had context! 
and object! as two separate types, although context! was hidden from 
users and only accessible by converting it to object! - conversion 
which was broken because it did not create 'self that object! requires. 
So, instead of fixing this by making context! accessible, it was 
decided to remove context! altogether and add 'self to all contexts, 
and add a bunch of exception refinements to BIND to work around all 
the problems that come out of that?
Do I need to say "KISS" here?
BrianH
26-Mar-2010
[1980x5]
Nope. You missed a bit of the R3 part. But that is a good characterisation 
of how bad things got for R2.
The part you missed for R3 was that there were no exception refinements 
added to BIND to deal with this at all - they weren't needed. And 
we are proposing to add *one* refinement to BIND, out of a choice 
of two.
So given that, you can now say "KISS", and realize that we did.
The rest of the conversation was discussion of subtleties and implications, 
mostly as an object lesson.
Oh, and the stack-relative contexts of the function! type in R3 to 
make functions more safe for recursion and multitasking.
Pekr
26-Mar-2010
[1985]
why not to fix context! vs object! discrepancy, at least for R3, 
instead of coming with other "workarounds"? :-)
BrianH
26-Mar-2010
[1986]
We already fixed this for R3.
Pekr
26-Mar-2010
[1987]
Question for Carl - after 2.7.8.  - are we finally back to R3? :-)
BrianH
26-Mar-2010
[1988x2]
EXTRACT fix posted for R3 (and R2 as well). Good catch, Sunanda :)
The R3 version is a lot faster because of the native loops :)
Gabriele
27-Mar-2010
[1990]
Brian, I don't agree that a half-keyword SELF is the simplest way 
to solve the problem.
BrianH
27-Mar-2010
[1991x4]
That's true. The simplest way to solve the problem would be to not 
have 'self at all, even for objects. Simplest isn't always best.
But if you are comparing to having separate object! and context! 
types, that would move all of the inherent complexity of the situation 
out into the mezzanine code, where dealing with complexity is the 
most expensive. And object! would still need all of the current 'self 
tricks to make it safe to use, so there's no real gain. At least 
with R3's solution the inherent complexity of the situation is encapsulated 
and dealt with.
Finally, the only reason we still need 'self is because you can't 
use path notation with the results of a function (BIND? in this case). 
So you have to have the result assigned to a word to be easily able 
to do the tricks one can do with path notation. Thus the only reason 
we need 'self is for convenience, so that the end developer doesn't 
have to constantly reinvent their own 'self references, badly.
When I say "badly", we come to the only thing you can't do with a 
roll-your-own 'self: The UNPROTECT exception. UNPROTECT won't unprotect 
'self: it refuses to. And it will unprotect any other protected word 
(future security restrictions allowing). So the one thing you can't 
fake is a persistent word reference to the object that you can't 
modify (the way you can in R2). At least not without writing your 
own UNPROTECT.