World: r3wp

Please study http://erights.organd http://genode.org.Without that, 
this discussion probably won't go anywhere

Not so.

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.

We can't directly use the E model because E is compiled, so there 
are things that happen at runtime in REBOL that happen in the compiler 
in E.

It's a VM, so you still have control over them

It's still compiled, and word lookup is handled by the compiler, 
not at runtime.

What difference does that make?

For E, these capabilities can basically be resolved statically in 
a lot of cases by the compiler. For REBOL, every capabilities check 
would need to happen at runtime.

Yes, obviously. So, no difference in possibility

I have to go now (well, an hour ago). May we continue this later?

Certainly. It's been a favourite topic of mine for a decade :-)

From http://erights.org/history/original-e/programmers/Econcepts.html

Once the capability to reference an object or send a message has 
been granted, no further run-time check is required.

I hadn't checked E for a long time, but they are now implementing 
capabilities in JavaScript for Google, so we're going to hear from 
it whether we want or not:

http://code.google.com/p/google-caja/

I guess this is another one of those things where REBOL has the choice 
between being ahead or staying behind a lost opportunity

Pretending that security doesn't matter is a worse policy.

 - for me, security does matter, but this just pretends to be security

And what never matters to me is pretence.

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

As for the

    a: quote (1 + 2)
    a ; == (1+ 2)


, that is not a "security measure". It is just a more comfortable 
behaviour.

...and I know it, since it was me who proposed it

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?

Regarding your implementing the first APPLY, that's great. I wish 
I had seen or heard of your version, so I wouldn't have had to implement 
the R2/Forward version from scratch. Then maybe we wouldn't have 
needed the bug fixes that R2's APPLY got later.

IIRC, you provided some advice that helped with the R2/Forward version 
before it got included in R2 the first time. If so, thanks.

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.

Would that be acceptable to you?
 - I found out, that everyone except you is against it

No, you found that out about functions, not blocks.

or, maybe not, we should make another poll

Remember, having it evaluate blocks and parens like that would make 
it not consistent with how words and paths are treated when evaluated 
inline.

Consistency was the biggest argument you had for the treatment of 
word values with functions assigned to them.

Well, it looks, that

    do 'a ; == (1 + 2)

may be more convenient

Cool.

(not that I intend to use it frequently)

It is interesting, that for the case:

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

we have only two opinions

currently, and both prefer the lit-word! datatype as the result

That isn't what you said in #1434 - you said that you would prefer 
getting the word! type.

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.

As for #1434 (and your most recent code example), I would prefer 
to have lit-words and lit-paths be consistently active values (the 
way lit-words are in R3 now) for the same reasons you proposed #1881 
and #1882. This means having them convert to word and path when they 
are evaluated instead of just gotten. But if you would prefer them 
to be a special case like parens (the way lit-paths are in R3 now), 
that would work for me too as long as that is the case for both lit-words 
and lit-paths - it would make them a little easier to work with.

I'd prefer lit words to be "dead", its so much pain to preserve lit-words 
within datasets.  I've often had "word has no value" errors when 
building data blocks for dialects or datasets which are being manipulated 
one way or another .

I meant the "you" in "if you would prefer" to be the collective "you", 
the consensus opinion, not necessarily that of you in particular, 
Ladislav :)

;-)

If lit-words are turned into a special case, being otherwise inactive 
(like lit-paths are now), that would work for me. Though normally 
we would want lit-words to be converted to words, if the #1882 change 
to word evaluation goes through, that would mean that lit-words could 
change to words which could execute functions. If that kind of thing 
could happen, I would rather it happen through explicit conversions 
so you can see it in the code.

in #1434 I did not say anything about my preferences

I just asked whether a note about "incosistency" contained in there 
was appropriate

not to mention, that the example here is not the example in #1434

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.

in my opinion, the behaviour of

    do quote 'a

expression is something else than the behaviour of the

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

example

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.