AltME groups: search

AFAIR, mod-action is required for mod-rsp. bind-extern RSP .r is 
required to send .r scripts to the RSP handler in workers.

so, if there is no bind-extern RSP [ .r ] then where are the .r files 
get executed? within the main cheyenne process?

onetom: They should be just served as a static resource if the 'bind-extern 
directive is not used.

what exactly is the purpose of the overwritten 'do function in the 
RSP handler?
 Bind the loaded code to a special per-webapp context.

do* == do/global == native 'do

There are cases where you want to bind your code to global context, 
so you will use 'do/global. For all other cases, you should just 
use 'do (especially now that nested 'do should to be fixed).

A thing should be noted.
repeat and foreach do a bind/copy of the evaluated block.

Even if they are the fastest loops, they should be not used too intensivly 
because they will polluate the memory.

It's particularly sensitive for graphics applications or services 
that linger in memory. 


So, that's why  I advise to use only LOOP, WHILE and UNTIL for intensive 
repeated loopings, if you don't want to blow up the memory used by 
your app.

how does this work?

switch event/type bind

(i'll get to the bind in a second, bear with me)

re the bind: i store the stuff the awake handler needs in order to 
work in port/locals

as a context. with the bind i can make those values appear as if 
they were local words, i.e. buffer refers to event/port/locals/buffer

2010.01.19 22:43:38 LOG5[4624:1256]: stunnel 4.29 on x86-pc-mingw32-gnu 
with OpenSSL 0.9.8l 5 Nov 2009

2010.01.19 22:43:38 LOG5[4624:1256]: Threading:WIN32 SSL:ENGINE Sockets:SELECT,IPv6

2010.01.19 22:43:38 LOG5[4624:5260]: No limit detected for the number 
of clients

2010.01.19 22:43:38 LOG3[4624:5260]: Error binding imaps to 0.0.0.0:993

2010.01.19 22:43:38 LOG3[4624:5260]: bind: Permission denied (WSAEACCES) 
(10013)

2010.01.19 22:43:38 LOG3[4624:5260]: Server is down

make function! [spec body] doesn't copy the spec or body, it just 
uses them (or does a BIND/copy, I'm not really sure). If that spec 
or body contains literal values that get modified later, they get 
modified in the function as well.

So in your example, mytemplate/release wouldn't be able to get the 
bindings of 'clear and 'blk from the calling context, since there 
isn't one. In order for the template to know what context to bind 
those words, a reference to that context would have to be passed 
as a parameter. The way that nested contexts are emulated in REBOL 
is through iterative overrides, not real nesting.


Making template! a datatype wouldn't help with this - it's part of 
the core semantics of REBOL. This is the same reason why the script 
or module Needs header can know what the target context to bind or 
resolve to is, but the IMPORT function can't.

So the mytemplate would be the word that gets bound to the context. 
 mytemplate/release is just a way of telling it BEFOREHAND what block 
to bind to the word.

In R2 I could write: in object 'self, but no longer in R3. What's 
the equivalent in R3?

 - I do not understand all that "harakiri" going on in R3 with 'self. 
 Nevertheless, the expression:
    first bind [self] object
works

Nevertheless, I think, that the fact, that
    first bind [self] object]
works, while
    in object 'self
does not, is at least surprising. What is that good for?

Ladislav, objects don't have a 'self field in R3 - the 'self binding 
is a side-effect of the BIND function. You shouldn't be using IN 
object 'self in R2 either - use BIND?.

So to discourage that behavior, 'self is hidden as-if with PROTECT/hide 
(effectively, not really), blocked from modification as-if with PROTECT 
(effectively, not really), not counted by LENGTH?, not unprotectable 
by UNPROTECT and only referenceable through BIND block! any-object!. 
It is unknown by anyone other than Carl whether the field actually 
exists in the object at all - I would guess that it does, because 
the alternative seems more complex and that's not his style. In any 
case, every reasonable effort has been made to discourage its use 
in any way except in code like Paul demonstrates above. R2's usage 
of the word was a security hole, and unnecessary once we got the 
BIND? function, both in R2 and R3.

Andreas, I don't have a problem with that solution in principle. 
It's just that it wouldn't work, and wouldn't be task-safe. The handlers 
for those functions would be task-local, the code blocks not. Plus 
it would break code that uses code block references rather than nested 
blocks, code that uses those functions through function values, and 
any function with the [throw] attribute (which we will be getting 
back in R3 with different syntax), and all of those exist in R3 mezzanine 
code. Plus there's all the extra BIND/copy overhead added to every 
call to loop functions, startup code, etc., and don't think that 
you won't notice that because that can double the memory usage and 
executiion time, at least.


The solution I proposed in the ticket comments is to have DO, CATCH 
and the loops set a task-local flag in the interpreter state when 
the relevant functions become valid, and unset it when they become 
invalid, then have the functions check the flag at runtime before 
they do their work (which they could because they're all native). 
This would be task-safe, only add a byte of task-local memory overhead, 
plus the execution overhead of setting and getting bits in that byte 
in a task-local way. It's the execution overhead that we don't know 
about, whether it would be too much. It would certainly be less than 
your proposal though.

It might be hard to believe, but R3 has gotten so efficient that 
BIND/copy overhead is really noticeable now in comparison. In R2 
there were mezzanine loop functions like FORALL and FORSKIP that 
people often avoided using in favor of natives, even reorganizing 
their algorithms to allow using different loop functions like FOREACH 
or WHILE. Now that all loop functions in R3 are native speed, the 
FORALL and FORSKIP functions are preferred over FOREACH or FOR sometimes 
because FOREACH and FOR have BIND/copy overhead, and FORALL and FORSKIP 
don't. The functions without the BIND/copy overhead are much faster, 
particularly for small datasets and large amounts of code.

Most of the time, actually, otherwise the BIND/copy overhead would 
make it a poor optimization.

That means that the BIND/copy overhead for BREAK and CONTINUE would 
happen at every call to a loop function, not just FOR, FOREACH and 
REPEAT. And 'break and 'continue would become keywords rather than 
function names, unable to be used for loop-local variables.

LOOP, WHILE, FORALL and FORSKIP don't currently have BIND/copy overhead. 
Which is why they are used a lot in R3 :)

The added BIND/copy overhead for loop functions currently not needing 
to BIND their body is certainly true. FOREVER would be another one 
of those.

REMOVE-EACH and MAP-EACH already have the BIND/copy overhead though.

But all the loop functions that take a word argument have BIND/copy 
overhead, and the rest don't.

Andreas: what you ask for has been discussed extensively when R3 
was started, by me, Ladislav and Carl. There are a number of disadvantages 
to that, starting from the fact that you need to bind/copy a lot 
more than you do now (eg. inside CATCH). It would also, unfortunately, 
not work in cases like this:

Carl, if you make RETURN and EXIT definitionally scoped, it would 
help if the throw: attribute would disable that, so functions like 
USE would work properly. Also, please keep BREAK, CONTINUE and THROW 
dynamically scoped - most of the functions that they break out of 
don't do definition, so making them do so would add unwanted BIND/copy 
overhead.

It seems that functions don't bind 'self to the code block, but they 
do reserve it in the function spec. So that's a separate ticket.

And closures don't bind 'self anymore either (I now vaguely remember 
a ticket related to that).

Internally, there is none. Ladislav is proposing that the internal 
'self field in the beginning of all contexts be made optional, with 
that option taken by MAKE object! (and as a side effect, modules), 
but not taken by contexts created by functions, closures and binding 
structural functions. As opposed to allowing the field to be overriden 
for that other stuff, and not doing the BIND trick with 'self in 
those cases (as we demonstrated we can do when that problem was fixed 
for closures).

Now bug#1529 is basically the same thing as bug#447, which was for 
closures: BIND is doing the special treatment of 'self where it shouldn't. 
And as bug#447 proves, you can shut that off with no difficulty (internally).

And functions and closures don't do the BIND trick with 'self, so 
that's not a problem.

I am suggesting that this ability to turn off BIND's special treatment 
of 'self be made available as a BIND/no-self option (or whatever 
else we decide to call it). This would allow us to write mezzanine 
functions that act like FOR and such, not necessarily in the sense 
of looping, but in the sense of not treating 'self weirdly.

Ah, but that is when you are *expecting* to override the context. 
Only advanced users expect FOR and such to override the context. 
And I don't see the problem: It's an easy fix, as was proved when 
the exact same fix was applied to MAKE closure! in bug#447. There 
don't need to be any structural changes; just flip a flag in BIND.

there are two problems...

 - actually, not, there are more than these two problems, as you bind/no-self 
 proposal illustrates, that is what I wrote in my comment

In case of the Context function you are in a different situation, 
since you expect it to bind the word 'self

this problem cannot be "cured" by bind/no-self, since it requires 
the user to always know, how he wants to bind the words in the block, 
while such an information is already "automatically available" (as 
can be proven in R2)

this problem cannot be 

cured" by bind/no-self, since it requires the user to always know, 
how he wants to bind the words in the block, while such an information 
is already "automatically available" (as can be proven in R2)"


This is not true. In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH 
and REMOVE-EACH we don't want the hidden 'self to be bound to the 
code block, but we *do* want the hidden 'self to be there in the 
context. In case the context persists beyond the execution of the 
function, it should be like a normal object context. The same goes 
for closures. Only for functions do the contexts not have indefinite 
extent (in R3) - they are stack-relative, so don't work beyond the 
return of the function.


However, in the case of your proposal to not have the 'self in some 
contexts, there is no way to specify that option in MAKE object! 
syntax, so the user can't tell whether it is the case or not. This 
is similar to the map! case-sensitivity option - we can't do it because 
we don't have the syntax. And we don't want to have anything that 
affects behavior on non-blackbox types that we can't see in MOLD 
or MOLD/all.

Now BIND/no-self is just a proposal to make *an internal option that 
BIND already has* usable by mezzanine code (like USE). And we know 
that BIND has that option because MAKE closure! already uses it. 
And we also want that internal option to be used by REPEAT, FOR, 
FOREACH, MAP-EACH and REMOVE-EACH, the same way that it is used by 
MAKE closure!..

''In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH and REMOVE-EACH 
we don't want the hidden 'self to be bound to the code block, but 
we *do* want the hidden 'self to be there in the context." - yes 
some may want all Rebol contexts to be isomorphic with objects, erasing 
a (perceived by me as useful) information (whether the context is 
supposed to be handled using BIND or BIND/NO-SELF, when applied on 
a block), which is present in R2, where the simple usage of BIND 
always does the right thing. It surely is a matter of preferences, 
that is why I am asking other users, what is more natural for them.

''In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH and REMOVE-EACH 
we don't want the hidden 'self to be bound to the code block, but 
we *do* want the hidden 'self to be there in the context." - yes 
some may want all Rebol contexts to be isomorphic with objects, erasing 
a (perceived by me as useful) information (whether the context is 
supposed to be handled using BIND or BIND/NO-SELF, when applied on 
a block), which is present in R2, where the simple usage of BIND 
always does the right thing. It surely is a matter of preferences, 
that is why I am asking other users, what is more natural for them.

Ah, but that's the problem. When that context is used by FOR, I want 
'self to not be bound. However, if the context persists after the 
FOR returns then I want BIND to do the 'self trick with any subsequent 
use of that same context; this is what I mean by "like a normal object 
context". That inconsistency is "the right thing". Having BIND not 
do the 'self trick based on some hidden quality of the object is 
*bad*. It means that I can't predict the behavior of BIND unless 
I know the originator of the object, and in many cases that wold 
mean dataflow analysis.

I don't want REBOL to guess whether I would want BIND or BIND/no-self 
to be used: I've already said so, do what I say to do :)

When that context is used by FOR, I want 'self to not be bound. However, 
if the context persists after the FOR returns then I want BIND to 
do the 'self trick with any subsequent use of that same context; 
this is what I mean by "like a normal object context". - yes, and 
that is, where our POVs differ - similarly as Brian, I do not want 
one thing: I do not want Bind to behave differently when used twice, 
since it is not the right thing in my opinion - it means, that I 
cannot predict the behaviour of Bind unless I know the originator 
of the context. are there any other opinions, than mine and Brian's 
on this?

Brian does not want to Rebol to guess, but he actually forces it 
to do so - R3 now guesses, that you want to bind 'self, unless you 
say otherwise. In case of R2, that is not the case - Rebol does not 
guess, since it uses the context as defined by the user.

Ladislav, your suggestion to have some contexts not have the hidden 
'self in them at all is not what you think. You are suggesting that 
we create object! contexts (for that is what all contexts are except 
for function! contexts) that *can't* be specified by MAKE object! 
syntax, ever. And thus these objects will have an attribute that 
doesn't show up when you MOLD it (because MOLD generates MAKE object! 
syntax) that affects one of the core features of the BIND function. 
And that attribute wouldn't be serializable even if you added it 
to the MOLD/all syntax, because MOLD/all serialization of objects 
doesn't work: MOLD/all syntax for objects doesn't restore word bindings, 
only DO syntax does.

Or perhaps he hates the idea of a hidden 'self field, and the corresponding 
BIND trick :)

...I cannot predict the behaviour of Bind unless I know the originator 
of the context.

 This seems like a core question to me. And while Steeve's example 
 is really neat, I wouldn't say it is REBOLish per se. BIND? doesn't 
 say a whole lot more, so I don't think either example is something 
 to hold up as a best practice. :-)


Is it by design? If so, how is it intended to be used, and how should 
it *not* be used? If not, what warnings do we need to include in 
docs?

bind/trick ? :)

Usually we use /only to mean /no-tricks, but /only is already used 
by BIND for something else.

so, bind/neat :)

But BIND is using /only to mean /shallow right now.

one more example in hope, that it will be understandable enough. 
First, the description in words: we define a function obtaining a 
block of code, which uses e.g. a Repeat loop. During the loop, the 
Block argument shall be executed too, but bound to the loop context, 
to be able to use the loop variable (s). The code looks as follows:

a-function: func [block [block!]] [
    repeat i 1 [do-in-context block 'i]
]

do-in-context: func [block [block!] context [word! object!]] [do 
bind block context]


I hope, that everyone understands, that this may well be a part of 
a real-world application, but my example is minimized to contain 
only the constructs that illustrate the problem. Now, in R2 the block 
will be executed "in the right context", being able to use the cycle 
variable 'i. In R3, the block is executed "in the wrong context", 
since the 'self variable will be bound, which was unsolicited.

However, we *can* make it an option of BIND. It's already a binding 
option for natives, we just can't see it from REBOL code.

Now when it comes to our interests, they are aligned. I agree that 
loop functions shouldn't bind 'self (#1529), and that functions should 
allow self in their argument lists (#1528), and that people should 
be able to bind a block without binding 'self if they don't want 
to (#1543). I also agree that /no-self is a dumb name and don't have 
a better one that isn't taken.

By "conflict of interests" I mean:


1) the interest to have seamlessly working loops, functions, closures, 
Use, etc. By "seamlessly" I understand "working without ever doing 
unsolicited 'self binding.

2) the interest to have a simple syntax for Mold/Load to describe 
these contexts


As far as I am concerned, 1) is a priority for me, therefore I prefer 
to have a different syntax for this type of contexts. Another possible 
option, which *might* be considered as an alternative is, to have 
a /self refinement for Bind as in BIND/SELF, since that variant covers 
the minority of use cases (just objects and modules), but I doubt 
it cold be called "functionally clean" anyway, thus, probably still 
violating 1)

Make a counter proposal then, like I did with APPLY/only vs. RAPPLY. 
It's real simple: We both want the option, but disagree on the default. 
I already made a proposal for BIND/no-self. Make a counter proposal 
for BIND/self in CureCode. One will be chosen, the other dismissed.

(Why "cripple" all these contexts so, that Bind has to do unsolicited 
work?)

Another datatype would work with MAKE syntax though. But it doesn't 
handle the most common case: People who need the 'self binding sometimes 
with a context, and don't need it other times with *the same context*. 
For that you need a BIND option.

:Why 

cripple" all these contexts so, that Bind has to do unsolicited work?" 
- The behavior of BIND is documented, so it is presumptuous of you 
to say that its behavior is "unsolicited" when it is behaving as 
it is documented to behave. It is much better to use the word "unwanted" 
here. It is clear that *you* don't want BIND to do the 'self unhiding 
trick, and if there's no way to turn that off then it is a problem 
for you, as a user of the programming language. So there should be 
an option, and maybe your preferred behavior should be the default.


However, you as a language designer (this is a different you, btw) 
has to consider what other users want to do, and that won't necessarily 
be consistent with what you (as a user) would want to do. So you 
(the designer) make tradeoffs, balance concerns, look for the most 
common behavior, make sensible choices, and try not to mess up. And 
then finalize the behavior in a tool that only does what it's told 
to do, and document that tool's behavior (at least on the surface). 
Then you (as a user) can know that the tool is going to respond the 
way it is documented to do when you tell it to do something - for 
a tool, this is what it means to do what it is supposed to do :)

For instance, if BIND/self (#1544) is implemented, then I will have 
to add the /self option to every usage of BIND in DO, LOAD, IMPORT, 
DO-NEEDS, INTERN and MAKE-MODULE, and perhaps some other places in 
the mezzanine code as well. This is not a problem (really, it isn't) 
but it is better to do this now while the scope of the effects is 
still calculable.

BIND is one of the most core functions in REBOL. Any change to its 
semantics would have big impact, so should be done sooner rather 
than later.

I am starting to be in favor of BIND/self, mostly because BIND/no-self 
looks so stupid (I hate the name). YMMV :)

People who need the 'self binding sometimes with a context, and don't 
need it other times with *the same context*.

 - this is the issue in a crystal clear form. As far as I am concerned, 
 I need to bind every block supplied to the Bind function to be bound 
 the same way, when the same context is given, because I need the 
 code to behave consistently. Therefore, I dislike the state, when 
 I do not know, what "the same way" is. As opposed to that, you seem 
 to prefer to bind blocks differently, even when they are bound to 
 the same context, which seems to be necessary only in case, when 
 the usual contexts have to contain, as I call it "unsolicited" 'self.

I only need to bind blocks differently to the same context *when 
I tell it to do so* (aka, when solicited). This is so I can write 
code that expects 'self to be bound without having to check whether 
the object I am binding to has the hidden 'self field. If I had to 
check for that, I would have to do that check with every usage of 
BIND where I had a 'self reference and use different code blocks 
depending on the results of that check. It is much better for BIND 
to just do what I tell it to do.

Ah, but that's a separate issue than the BIND/self vs. BIND/no-self 
thing. BIND already has the option, internally, accessible by native 
code, to not unhide and bind 'self. And the loop functions can already 
use that option, and should: They shouldn't override  'self bindings 
unless 'self has been overriden with another, unhidden 'self field.

And note that the 'self trick only applies to the special hidden 
'self field. And overrides of that field aren't affected: They will 
be bound or not, normally, depending on whether they are themselves 
hidden. And BIND/self shouldn't show a overriden 'self field if it 
is hidden - it should show the original 'self. Does that make sense?

BIND? was originally added to R2 to deal with that security problem 
- we used to use 'self more often. And in R3 the 'self is protected, 
and not unprotectable by UNPROTECT in a special case. So it's not 
just BIND that special-cases 'self.

And the programmer that matters when it comes to BIND is the one 
that is calling BIND, and providing the code block. Not the one that 
made the context. It's different with internal use of BIND, functions 
that make, use and discard a context. If the context persists then 
it needs to behave in a predictable matter. R2 is not a good example 
to cite when deciding what is good coding practices; we made the 
decision to change things in R3 for *many* good reasons.

And the programmer that matters when it comes to BIND is the one 
that is calling BIND, and providing the code block. Not the one that 
made the context.

 - this is interesting, again. My note is, that if the context was 
 created to support e.g. the functionality of For, then any subsequent 
 binding is meaningful for me, only if the functionality remains supported. 
 I think this way, even when I am the one calling Bind and providing 
 the block, unfortunately, I may not know, which alternative mentioned 
 by you to use, not knowing the type of the context I obtained.


As opposed to that, when I see a context without 'self, I know, that 
the context was created so, that it is not meant to support 'self 
binding, and that is all I need to know. How would you do it obtaining 
a context of unknown origin, that would contain '"unsolicited" self? 
(of course, not knowing that information, since there is no way how 
you can find that out)

Andreas, agreed, the problem could be solved by having two types. 
But that's unnecessary, since we have a solution already that doesn't 
require another type. And the two-type solution wouldn't help with 
loops and closures unless BIND? returned an object type from words 
bound to the non-object type, because to do otherwise would break 
BIND.

Because even if we made BIND not do the 'self trick by default, we 
would still *need* to add the /self option, and that option would 
*need* to have a 'self field to do the trick with, *every time*.

While I'm not even sure that we would still need /self, I can't see 
where the problem is. BIND/self simply won't work on context!s

Because otherwise every code block we are binding with BIND/self 
would leak references to whatever binding 'self had already.

You have to assume that the 'self trick needs to be able to work 
with every "context" that you pass to BIND, even if BIND doesn't 
do the trick by default. Because the trick is necessary for a lot 
of code. And leaked 'self references can be a security hole, allowing 
access to otherwise encapsulated code.

Ah, but you were also assuming that BIND doesn't do or depend on 
the 'self trick. Try the function with BIND/self.

Make sure that DO-IN-CONTEXT uses BIND/self, depends on it, requires 
it. Then pass in a "context" created by a loop function.

It's all well and good to say that the current BIND does the 'self 
trick and you don't like that. But there is a lot of code that depends 
on that trick, so if you don't want to do it for your code, you better 
make that an option (perhaps the default one).

Where is the problem in doing bind/self for object! contexts and 
bind/no-self for context! contexts?

Andreas, yes, those. TO-MODULE would break utterly, for instance, 
no recovery possible, if BIND accepted contexts that didn't have 
'self.

Btw, I felt uneasy when the first time I saw that code :

a-function: func [block [block!]] [ 
repeat i 1 [do-in-context block 'i] 
] 

do-in-context: func [block [block!] context [word! object!]] [do 
bind block context]

Now i know why. It's a serpentine way for simply doing:
>> repeat i 1 block

Erf :)

Sure, that's what is done with function! contexts after the function 
returns. And one of the functions that can't handle them is BIND.

Fine, but this is precisely about BIND acception two different types 
of contexts and determining by their type wether if should do the 
self trick or not.

Don't you see, if BIND/self is the only way to see the 'self word 
at all, and that word is otherwise not visible, and BIND/self would 
require the existence of that word, then there is no point in having 
a separate datatype. The only code that could possible be affected 
by the existence or not of a 'self field could not possibly be used 
with that type, and all other code wouldn't be able to tell the difference.

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.

Use context!s internally, wherever you are currently using object!s 
with bind/no-self

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.

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.

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.

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?

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.

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.

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.

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.

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.

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