AltME groups: search

Also do we have any standart way how to specify that a script requires 
R3 in script's header?

maybe to-binary on vector! could do the job best way but this is 
not implemented yet probably

I'm not sure it's completely OK though, since there is one part of 
strict comparison that SELECT/case doesn't cover: binding.
>> select/case reduce [use [a] ['a] 1 'a 2] 'a
== 1
>> strict-equal? use [a] ['a] 'a
== false

Nor do we want it to, because SELECT, FIND and other functions to 
which /strict would apply would generally not be applied to data 
which could be guaranteed to have the same binding as the value you 
are searching for.

Since you are the one who dismissed it in the first place, feel free 
to go ahead and do as you deem right.

I do not want to use the "immediate value" notion, since it is an 
"implementation detail" in the sense, thant e.g. Doc's attempt implementation, 
while attempting to be compatible, has drawn the line differently.

How do then have come to conclusion regarding the immutability of 
the new-line attribute?

if we talk assembler

 - well, I actually do not have any problem to use the same definition 
 there - if I mutate the memory, I say, that I mutate the memory, 
 not the value it contained

See the PROTECT bugs. The problem is that once the PROTECT tickets 
are all implemented, we will have a sufficiently capable system, 
but it will be too difficult to use. I think we need to rethink the 
model a little when we do the security/multitasking revamp.

Just a summary of the above "directly modify the slot" readers/watchers, 
that might not understand the whole discussion:


1) In REBOL some values, like blocks, maps, etc. can refer to other 
Rebol values. It is not reasonable to call the referring substructures 
"value slots" (I don't think I disclose too much when I say, that 
these referring substructures are 256-bit "wide"), since it can be 
easily demonstrated, that the substructures in fact don't "contain" 
the values, but rather they refer to them. (this is obvious if the 
value referred to is any of the values, that simply cannot be described 
by less than 256 bits) but is true also in case the value could eventually 
be described in less than 256 bits. (Brian calls such values "immediate", 
but I dislike that notion, since the values Brian calls "immediate" 
cannot, in fact, "fit in" the referring substructures either, and 
everybody having read my identity article knows enough to be able 
to do that as an exercise.).

2) Andreas asked in the discussion above, whether the possibility 
to "directly modify" the referencing substructures does not make 
all REBOL values mutable. The answer was "no", one of the resons 
is the fact, that the ability to "directly modify" the referencing 
substructures makes all values containing them mutable, which means, 
that REBOL blocks containing modifiable referencing substructures 
are mutable, etc... Any modification of the reference substructure 
is a mutation of the value containing the substructure, but cannot 
be a mutation of the value referenced by the substructure exactly 
because the substructures don't contain any values.

The opinion I presented above may be seen as "controversial", since 
it uses notions/definitions from my "Identity" article, which some 
see just a possible, but "unusual" alternative. If asked, I can be 
talked into demonstrating the fact, that the referencing structures 
don't contain any values, but, I do not want to start any flame wars 
about that, so, I reserve my right to not feel obliged to change 
the mind of all people seeing it differently.

Nonetheless, if you like you can think of all value slots as being 
references, but these are not necessarily references in the C pointer 
sense.

 - correct, I do not want to say, they are references in the C pointer 
 sense, that should be emphasized".

I mean... I can do:
>> if error? err: try [1 / 0][probe err false]
make error! [
    code: 400
    type: 'Math
    id: 'zero-divide
    arg1: none
    arg2: none
    arg3: none
    near: [/ 0]
    where: [/ try]
]
== false


but what if I would like to form the error message to look like if 
the error is really evaluated:

>> do err
** Math error: attempt to divide by zero
** Where: / try
** Near: / 0

So far I have this:
my-attempt: funct[code /local val][
	either error? set/any 'val try code [
		val: to-object val 
		do bind [
			print rejoin [

    "!! " val/type  " error: " reduce system/catalog/errors/(val/type)/(val/id) 
    #"^/"
				"!! Where: " val/where #"^/"
				;"!! Near: " val/near  #"^/"
			]
		] val
		false
	][
		:val
	]
] 

my-attempt [debase #ff]
my-attempt [1 / 0]

but not perfect... the Near and Where info is modified :-/

Oldes, a perhaps simpler version for R2 is: http://www.rebol.it/power-mezz/mezz/form-error.html

I thought FORM was supposed to be able to do the same thing on R3, 
not implemented yet?

weren't there some problems with the code that someone trying to 
do their own schemes brought up? can't remember the details.

Async devices would be very nice to do it properly, though

it also saves on RAM, and I could do multi-processing liquid nodes, 
for example... right now its impossible to do.

great to hear about ARM support - do you have any idea if this is 
just core or inc. graphics?

I bet it is just core because so far there is noone who would like 
to port graphics to Linux. What would you Linux guys do without Wine? 
:-)

For the record, I do want to port R3 graphics to Linux, but that 
doesn't mean that it's possible or wise. It's not possible due to 
fulltime work on other R3 stuff, and it's not wise because the Amiga 
patches haven't been integrated yet, so the host kit is still very 
Windows oriented while more work has already been done

Seems the Color Nook can run Android 2.2 ( aka Honeycomb ).  And 
R3 is now running on Arm.  What's to do to get it running on Android?

Creating and returning binaries is supposed to be safe if you do 
it in one go

This may just be a variant of CC#1506.....But why does this throw 
an error:
    do [print 222 break]
    222
    ** Throw error: no loop to break

While this does not?
    also true do [print 222 break]
    222
    == true

In R3, DO of a word! value is basically equivalent to GET of the 
word. So in the example above, the first DO performs a GET of 'now, 
retrieving the value assigned to it, the NOW function. Then the second 
DO of the value of the NOW function performs that function.

So, getting rid of the distracting REDUCE, the first line is this:
    b: [now]

It is a block with a word! value in it. In the context that the word 
is bound to, the function value NOW is assigned to that word.

You can either have a dialect processor like DO interpret the block:
    do b

or you can treat the block like data and interpret the data yourself, 
emulating the dialect processor (all of these lines are equivalent):
    do do first b
    do do b/1
    do get b/1

Hmm, I do not see a consistency there anyway - system/contexts/user 
context words are not initialized to NONE

So, instead of achieving consistency in R3 we just obtained a different 
kind of inconsistency. (Actually, I do not mind much, I just do like 
to name the things properly)

Moreover, the local words in functions (I mean function arguments) 
actually are not initialized to #[none!]. The only observation that 
is true is, that after a function call, and only when the corresponding 
refinement is not used in the function call, the corresponding "refinement 
variables" are set to #[none!] - notice, that I intendedly did not 
use the notion of "initialized", since the function variables (do 
not confuse with closure variables) "exist" even before a function 
call is made in a sense, that can be easily demonstrated.

who cares the developpement is on hold Carl have better more profitable 
things to do than loose his time with rebol 3

R3 has a real chicken and egg problem. Much work could be done without 
Carl's direct involvement but for many people Carl's work is not 
yet sufficiently complete for them to do it. (A good example being 
the work you've put into R3 schemes, Graham).


The RM-Asset team are doing a great job of making progress with R3/GUI. 
Lets hope that they can continue and don't hit some issues which 
will need a lot of Carl's time to fix.

In Carl's absence .. we need a project lead who is going to take 
over .. or we just do the Milton thing

Why do you think schemes need to be included in the executables published 
by Carl?

I do know how to spell include just now hoe to type it !!

Graham I was never able to get connection using Doc's NTLM to IIS 
6.0.   Do did you have success with a Windows domain where you can 
display the login with a REBOL UI and then request information from 
IIS?

That's a matter of how much risk you are willing to take. R3 works 
quite well, but if you do hit a problem, it will be impossible to 
fix

As for advantages, YMMV. For me, the improved PARSE, binary conversions 
that make sense, the map! type, the module system, the faster and 
more powerful loops, better error handling, and the increased consistency 
make R3 much easier to use. The extension model makes it more powerful 
- I always hated R2's library access model. But I don't do much GUI 
work in REBOL. R2 has database access that I use pretty often, and 
HTTPS support which I use rarely but it's important when I do. I've 
backported the most important missing functions from R3 to R2 in 
mezzanine form, though there is still some stuff I miss.

We need a prioritized list of stuff that we need Carl to fix. The 
rest (mezzanine and host) we can do ourselves.

...serialized constructors...
 - For me, the terminology is quite unfortunate, because

     "1 2"

is not "more serialized" than

    "#[false] #[true]"


I still do not understand, why it is so important to pretend the 
opposite.

The real distinction is between serialized constructors: #[map! [a 
1]]

and programmatic constructors that you have to DO: make map! [a 1]

The security issue is to not have a file that is done automatically 
be writeable using the same permissions that the scripts are run 
under.

- I do not have any problem to agree with that. But, in my opinion, 
this does not require to ban files, that are done automatically. 
Rather, we should make it possible to define special rights for such 
files.

Andreas, in the OSes with which I am familiar, you can't set a file 
to read-only and then count on that file staying read-only unless 
the user is asked for permission to change that setting. In REBOL 
you can. The security of a DOable %user.r depends on it not being 
writeable between when REBOL shuts down and when it starts up again. 
So that means using OS permissions to guard it, and those are based 
on user capabilities, not enough protection. The situation is different 
with %rebol.r since we only load it from the same location as the 
R3 executable, and that location can be protected with user permissions; 
this is why we can still DO %rebol.r in R3.

Because you can have a worm spread using a combination of REBOL and 
code that is not written in REBOL but writes %user.r to do its propagation.

you can have a worm spread using a combination of REBOL and code 
that is not written in REBOL but writes %user.r to do its propagation

- yes, you can, but when you run a worm like that, then you are insecure 
anyway, since the worm could overwrite even your rebol.exe file.

Sure, and such a worm could spread much more easily by writing my 
.bashrc to do the propagation.

Ladislav, you can put the rebol.exe file in a place that only admins 
can write to; %rebol.r too. You can't do the same with %user.r.

I am still having issues with what is considered "secure" here. As 
far as REBOL goes, for me, it is not unsecure, if it relies on the 
user environment being secure. (How can any program be secure, if 
it runs in an insecure environment?) Thus, the only concern I do 
have as far as REBOL goes is my wish for the REBOL interpreter to 
not overwrite the %user.r file unless specifically allowed to do 
that.

Oh, there's a to do list

To complete the informations, I should probably perform a user poll 
in here. So, here goes:


*For me, one of the main goal of logic operators like NOT, AND, OR, 
XOR is to yield a value, that is used mainly as the CONDITION argument 
of the IF, UNLESS, EITHER, etc. control functions.


*Taking NOT (which is a unary logic operator) as an example, we see, 
that it is compatible with the above mentioned main purpose. The 
goal is achieved by "delegating" other functionalities NOT does not 
perform to COMPLEMENT. It is not possible for NOT to be both compatible 
with IF and perform the operations COMPLEMENT does.


*Taking OR (which is a binary logic operator) as an example, we see, 
that it is incompatible with the above mentioned main purpose, not 
being able to correctly handle some logic combinations, that would 
be compatible with IF. As an example, see the expression
    0 or true

, which cannot be used to yield an argument for IF, although both 
its arguments *are* compatible with IF. Interestingly, there is not 
a shortage of functions that are meant to perform analogical non-logic 
operations. I would like to specifically mention the UNION function, 
which seems to be related to OR similarly as COMPLEMENT is related 
to NOT.

*The question I am asking you is:

- Do you prefer the "logical" solution used in the case of NOT, and 
apply it to other operators like AND and OR as well, or

- Do you prefer the "non-logical" solution used in case of AND and 
OR and apply it to the NOT operator as well, or
- Do you prefer to keep the current state of affairs for R3?

I also only use them as bitwise ops, but I don't remember tripping 
over it very often. I just always use ANY and ALL. NOT was probably 
designed to be friendly, rather than pure, and I do use it a lot.

We can do explicit conversions, and our code becomes easier to understand 
as a result.

None is a falsey value (NOT the value returns true), but not a false 
value. If we want to have AND, OR and XOR accept none as a false 
value, this will lead to errors being ignored unintentionally. We 
can do it, but there is a drawback. Still, I prefer that to making 
a separate set of operators for bitwise operations.

OK, reading the Brian's formulations, a different expression of the 
poll question might be: "Do you, REBOL users, want to have 'combined' 
logic and bitwise' binary operators, wouldn't you prefer the operators 
to be conditional?"

the whole bitwise thing is pretty fucked up anyway. i tried to do 
a disk editor, a pic microcontroller HEX file processor, a custom 
serial communication protocol and in all cases i had to ping-pong 
between binary! issue! integer! and had to trim to the right bit/byte 
counts. it was a nightmare all the time.

although having the set functions support the bitwise ops like they 
should...

I *also*I want bitwise infix ops... as long as the set functions 
to do the same arithmetic... basically just like how  'ADD  and  
'+  are equivalent.

OK, that is why I was suggesting a separate ticket. Do you mind a 
little rewording in the ticket, or splitting into more tickets, if 
the proposal stayes the same, semantically? This would allow us to 
make them more precise, and show competing proposals, some of which 
could be rejected in favor of others. The existing ticket seems like 
a summary of an AltME conversation, so it would be tricky for an 
implementor to follow.

Yes, I suggested the INTERSECT, etc. modification as a supporting 
matter to show how one can do without changing too much. I can imagine 
a lot of different alternatives, though.

Tamas, did you read the ticket? I do not want to repeat everything 
I wrote in there.

Is it correct to say, that AND and OR can be used as bitwise operators 
and to check on logic! values. And that e.g. IF can do more than 
this and then isn't really compatible with AND and OR?

I am trying to use a slightly different formulation: IF can check 
not just logical expressions (yielding LOGIC! values), but conditional 
expressions (yielding any values). We do not have operators combining 
conditional expressions into more complex conditional expressions 
(ANY and ALL are dialects, not operators, although they can be used 
successfully).

It is definitely possible to implement ANY and ALL as functions if 
you use DO/next (either the R3 or R2 version).

brian we are talking an api issue.  what happens before application 
starts is irrelevant.   on init, let R3 do whatever it wants.


once we start running the script, have an api-minded function which 
just makes sure that any function you send to the core used as an 
op is safe.  I don't care for any limits... just document them and 
I'll live with.   whatever the core has which I can't have... who 
cares.


as far as error reporting goes, that is the reason for the stub. 
  IT will have to either handle the error appropriately or just raise 
an error.   


really, there is no technical reason for this not being done.  its 
just a question of doing it.    limited user ops are still infinitally 
better than none.

The other trick that would need to be accounted for is that the actual 
process of calling functions is different for every function type, 
and afaict the differences are implemented in the evaluator itself 
rather than in some hidden action! of the function's datatype implementation. 
This is why I was glad to figure out that the command! type was sufficient 
to implement what we needed user-defined function types for, because 
it appears that user-defined function types are impossible in R3, 
even potentially. The op! redirector needs to be able to understand 
how to call the function types it supports. R2 ops only understood 
how to call actions (technically, DO did the redirection in R2, not 
the op! code itself). R3 ops can also redirect to natives, which 
is why some functions are native! now that were action! in R2. In 
order to support making ops from user-defined functions, the op! 
redirector code would need to be expanded to support calling those 
function types.

Strangely enough, if ops were implemented using the R2 method - DO 
swaps the op keyword for its prefix equivalent, instead if the op 
itself redirecting - then unary postfix and ternary ops would be 
possible right now with the current op! type, no new internal flags 
needed. Prefix functions can have infix keywords already, as long 
as they are not optional - the arity of the function needs to stay 
the same, but there's nothing illegal about infix keyword parameters 
in REBOL.

That's what I do in most cases, but HH needs to be HHH (24-hour time). 
Sometimes I need to have sub-second or added extensions, but that's 
the basic idea.

it should be simple to do as a mezz

The latters seems ok to me. But what if w is a word holding 'b or 
'a/b, as I was testing, in relation to the object a? This is what 
I get:

In R2:
>> a: make object! [b: does ["OK"]]
>> w: first ['b]
== 'b
>> type? :w
== lit-word!
>> a/:w

** Script Error: Invalid path value: b	; To me, that error is wrong 
worded, it should show 'b.
>> in a :w
== 'b		; Confused, as a doesn't hold any 'b
>> do in a :w
== 'b		; Why?
>> type? do in a :w
== lit-word!

Same in R3:
>> w: first ['b]
== 'b
>> type? :w
== lit-word!
>> a/:w

** Script error: cannot access :w in path a/:w		; Not sure about 
this error. Could be better, I think.
>> in a :w
== 'b			; ?
>> do in a :w
== b			; ??
>> type? do in a :w
== word!

As said, all the respondents above prefer the function to be evaluated 
when doing a word that refers to the function. The only way how you 
can influence it would be if you said you preferred the current behaviour 
as implemented in R3. Do you?

Regarding the example evaluating words above:

    lit-path: first ['a(b]
    do [lype? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatype

Correction: Regarding the example evaluating words above:

    lit-path: first ['a/b]
    do [type? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatypeRegarding the example evaluating 
words above:

    lit-path: first ['a(b]
    do [lype? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatype lit-path: first ['a/b]
    do [lype? lit-path]

Correction: Regarding the example evaluating words above:

    lit-path: first ['a/b]
    do [type? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatype

I prefer lit-path!. The same for lit-words:

	lit-word: first ['a]
	do [type? lit-word]


I prefer that to return lit-word!. It's only, if the word being looked 
up (lit-word in this example) is a function (or native, op, action, 
...) that further computation should occur, I think.

Strangely enough, with http://issue.cc/r3/1882you are proposing 
to do the opposite of http://issue.cc/r3/1881

In #1881 you are proposing to take what in R3 is currently an active 
value and render it inactive, which will make it mildly safer to 
handle - lit-word/lit-path conversion to word/path is a trivial thing. 
In #1882 you are proposing to make the word! type into an active 
value, where you would have to treat every word value as carefully 
as you treat the function it is assigned. Except it's worse, because 
in R2 it has the effect of doing *blocks* as well, if those blocks 
are assigned to a word - even DO of an inline word isn't that unsafe. 
It is really bad.

Most of you might not remember this, but parens used to be treated 
as active values in R2. If you had a paren assigned to a word, putting 
that word inline in a DO dialect block would cause the paren to be 
executed. I used to use this as a way of having quick thunks (functions 
that take no parameters) without calling DO explicitly. However, 
this made it difficult to work with paren values, and was eventually 
removed for security reasons because it made screening for potentially 
dangerous values more difficult than a simple ANY-FUNCTION? call. 
It would be bad to make word! and path! values just as difficult 
to work with.

In #1881 you are proposing to take what in R3 is currently an active 
value and render it inactive
 - do I?

Btw, this comment in #1882: "and since you've requested that lit-word! 
and lit-path! be returned to their R2-style inconsistency" may not 
be an accurate representation of your proposal (here earlier in conversation). 
You might be proposing that R3 do a better job at being inconsistent 
than R2 is doing (as demonstrated in #1434). If so, cool.

I prefer convenience, but understand the concerns about security. 
Less aggressive evaluation by DO doesn't solve the security problem 
though, does it? If we say "Never DO untrusted data", DO can provide 
more convenience. Of course, that means it may be less convenient 
if you have to evaluate untrusted data, but at least the line is 
clear.

>> o: make object! [f: does [42]]

>> do in o 'f		; This is a problem, as nothing seems to be happening!
>> o/f
== 42

I'm not sure, I understand the security concern.

If somebody wants to use DO, he is responsible for knowing what he 
is doing

Pretending that security doesn't matter is a worse policy. Here is 
what would resolve the security issue:

- Putting warnings in the docs for DO, in the same section where 
they talk about the special treatment of functions and blocks.

- Make parameters not work, and don't do blocks and parens through 
word values, same as R2's DO of path values.

- Make sute that we don't try to make set-words and set-paths do 
assignment when you DO them. Treat them like get-words and get-paths.


Together, those restrictions would make DO of word and path values 
no more insecure than DO of block and paren values. For functions, 
we have APPLY.

DO of block and paren values is something that we can say is secure 
enough already, assuming that variables and such are protected and 
secured, so that is a good set of restrictions to follow for words 
and paths. Calling functions through inline words is secure enough 
if you can control the binding and writeablility of those words. 
DO of function values has the argument problem, but it's known and 
has built-in workarounds (APPLY, putting function calls in parens), 
and we already have simple ways to screen for them.

DO is seductive, because sometimes I want to create (easily) a "dialect 
environment" and just use DO to evaluate my dialect., safely and 
securely. 


Is there a security page in the docs (I don't see one in the R3 docs 
right now)? If not, that would be good to have. If we have a list 
of functions and operations you shouldn't use on untrusted data, 
and what the risks are, that's a good start.

I would love it if we as a community were to really think through 
the (UN)PROTECT model, because the current model is incomplete (even 
for the stuff that works) and the proposed model is starting to look 
a bit awkward to use. Keep in mind that PROTECT may also be used 
to make series sharable among tasks, but that this isn't implemented 
and there is likely a better way to do this. I would love it if there 
was a good security model that can integrate well with REBOL semantics.

Some factors to consider about the REBOL semantic limitations:


- There is no such thing as trusted-vs-untrusted code in a REBOL 
process, nor can there be, really. Levels of trust need to be on 
a process boundary. You can't (even hypothetically) do LOAD/secure 
level or DO/secure level, but you can do LAUNCH/secure level.


- If you want to make something readable or writeable to only certain 
code within a process, binding visibility tricks are the only way 
to do it. The only way to ensure that your code has access to something 
and other code doesn't is to make sure that other code can't even 
see yours. This is why BODY-OF function returns an unbound copy of 
the body in R3, not the original.


- We need a way to make protection stick so you can't unprotect things 
that are protected, or protect things that need to stay unprotected, 
but still allow changes to the protection status of other stuff. 
The currently proposed model does this through a chain of PROTECT 
and UNPROTECT calls, then a PROTECT/lock, not allowing unlocking 
if there is a SECURE 'protect. However, the proposed model seems 
too difficult to use, and as the pre-110 module system demonstrated, 
people won't use something that is too complex to use, or will use 
it badly. We need a better way of specifying this stuff.

Now, for your questions, Kaj.


Mezzanines execute arbitrary code with DO. You can't even know if 
something is code or not until you pass it to a dialect interpreter 
like DO or PARSE - code is data. Blocks don't have bindings, only 
their any-word contents do, so the code blocks of functions are not 
bound to functions, only their contents are. The same goes for functions 
in modules or objects - they aren't bound to their objects or modules, 
only referenced by them.


(making this up on the fly) It could be possible to make the binding 
visibility of words be defined as a set of capability tokens as part 
of the object spec (in the SPEC-OF sense), and have the function 
spec dialect be extended to contain such tokens. This would have 
to be checked with every word access, and we would have to be careful 
to make the model in such a way to avoid unauthorized privilege escalation. 
Then changes in capabilities would happen on the function call stack, 
which is task-specific.


The problem with this is making sure code can't make functions with 
more capabilities than the code making them currently possesses. 
Though R3 doesn't really have a user model, it does have a task model 
and we could make the capability level task-specific. Code could 
constrain capabilities for code it calls, but we don't want privilege 
escalation at function creation time. It would be possible to have 
privilege escalation at function call time if the function called 
was created by something with the necessary capabilities.

Drawbacks:

- If we do this for binding visibility, this means a capabilities 
check would go into every word access. Word access would be SLOW.

- This doesn't add anything to the PROTECT/hide model, which handles 
binding visibility without the slowdown.


Capabilities would be like the SECURE model, but more flexible, so 
that's something to consider there. What SECURE protects is heavy 
enough that a capabilities check wouldn't add much to the overhead.

Of the 3, SECURE seems like the most likely to be enhanceable with 
capabilities. Functions could be enhanced by capabilities specs, 
where the function code could only create other functions of equal 
to or lesser capabilities than are currently available in the call 
stack. Once a function is created, it could run code with the capabilities 
that it was created with (with the exception of that function creation 
limitation earlier). There could be a function like DO that reduces 
capabilities and then does a block of code, and maybe MAKE module! 
could be made to use that function based on capabilities in the module 
spec.

It seems to me that you are still talking in terms of plugging all 
the holes in the myriad of capability that would supposedly be around. 
This is not how true capabilities work. They implement POLA: there 
is no capability unless it is needed, and in that case, it needs 
to be handed down as a token by the assigner of the work. If the 
boss doesn't have the token, the employee will by definition not 
be able to do the work

Basically, the code that creates the token is the only code that 
has access to the token, and it can pass that token along to other 
code if it is safe to do so. The only difference is that code isn't 
protected unless it needs to be.

OK, the problem with that model *in this case* (PROTECT/hide) is 
that we are talking about object fields here, bindings of word values. 
REBOL objects bind their code blocks before executing them. If there 
is going to be any blocking of bindings, at least the object's own 
code needs to be bound first. This means that if you are going to 
make word bindings hidden, you need to do so after the object itself 
has been made, or at least after its code block has been bound. You 
can do this binding with PROTECT/hide, or with some setting in an 
object header, it doesn't matter. Since words are values and their 
bindings are static, being able to create a new word with the same 
binding means that you need access to a word with that binding, with 
*exactly* the same visibility issues as token access. The difference 
in this case between POLA and PROTECT/hide is whether object fields 
are hidden by default or not, not a matter of when they are hidden.

Make parameters not work, and don't do blocks and parens through 
word values, same as R2's DO of path values.

 - this is exactly a complicated way how to pretend something is more 
 secure than it actually is. The only real effect is obtaining a less 
 comfortable and more annoying system

On the other hand, I would never propose

    do a


to yield anything other than 3, pretending it might be perceived 
as "more secure".

Regarding APPLY- I was the one who implemented the first APPLY in 
REBOL, and I was the first who used it to obtain a more secure evaluation 
than using DO

Agreed about this from your example above:
>> a: quote (1 + 2)  do a
== 3
But what I was proposing above was this:
>> do 'a
== (1 + 2)
Would that be acceptable to you?

pretend something is more secure than it actually is

 - the biggest security concern of R3 is making sure that outside 
 code can't modify the code of functions.


There are various tricks that can be done in order to make sure that 
doesn't happen (putting calls to function values in parens, APPLY, 
SECURE 'debug). DO of blocks and parens don't need the APPLY or DO 
in a paren tricks in order to make sure they can't modify the calling 
code because they can't take parameters, so you can DO blocks and 
parens without changes to your source code - SECURE 'debug doesn't 
require changes to source code. This means that less effort is needed 
to make DO of blocks or parens more secure than DO of functions that 
can take parameters. The same goes for DO of any non-function type.


If you constrain DO of paths or words with functions assigned to 
them to not be able to take parameters, then they would be exactly 
as secure as DO of blocks or parens, and can be called with the same 
code - no additional code wrappers or screening would be needed. 
This would make DO of words or paths a drop in substitute for DO 
of blocks or parens.

I'm more concerned with people trying to sneak functions into data, 
which could then use parameters to get access to the original code 
of another function. This can be used for code injection, or for 
getting access to bound words that have since been hidden, or to 
internal contexts. Given that words are often valid data, having 
a special case where they can execute functions by sneaking in a 
bound word is a real concern. However, if that function can't take 
parameters, there is no hacking potential and function code can be 
secure. The workaround if you don't want any functions executed (beyond 
the hacking) could be to unbind words retrieved from data, bind them 
to a known context, or just avoid using DO word or path altogether.

I guess I had trouble parsing this sentence:

I do *not* propose the result of 

do quote 'a 

to be a lit-word, 
since the word really looks reasonable to me.


That seemed to be a preference for lit-words converting to words 
in that case, though I may have misinterpreted that.

Whether or not there is going to be a difference between inline evaluation 
of lit-words and evaluation of lit-word values, evaluation of lit-word 
values needs to be consistent whether you do so by referring to them 
with an inline word, or through explicit DO. R2's behavior is a bug.

Once again that "consistent" word. There is the main difference. 
I do not think you can call "inconsistency" any difference in the 
evaluation of the former and the latter expression, since the former 
expression is about handling lit-words as arguments of the DO function, 
while the latter is about handling words as inline block values, 
when they refer to lit-words.

I've been using the terms inline evaluation for having the value 
inline in the code, regular evaluation for when the value is referred 
to through an inline word, and explicit evaluation for when the value 
is passed to DO directly. If the first is to be different, the latter 
two need to be consistent with each other, same as with parens.

The proposed model is something like this:
>> 'a/1 
== a/1 ; inline evaluation of lit-path converts to path 
>> b: quote 'a/1 
== 'a/1 
>> b 

== 'a/1 ; regular evaluation of lit-path value does not convert to 
path 
>> do :b 

== 'a/1 ; explicit evaluation of lit-path value does not convert 
to path


So it's not exactly like parens, but it's what Maxim, Geomol and 
I would prefer.