World: r3wp

And now the 'a/b:

In R2:
>> a: make object! [b: does ["OK"]]
>> w: first ['a/b]
== 'a/b
>> do w
== "OK"
>> do :w
== 'a/b

In R3:
>> a: make object! [b: does ["OK"]]
>> w: first ['a/b]
== 'a/b
>> do w
== 'a/b
>> do :w
== 'a/b

wrt:

And, how many users prefer:

a: make object! [b: does ["OK"]]
type? do in a 'b ; == function!
versus

a: make object! [b: does ["OK"]]
type? do in a 'b ; == string!

============================

the first should be supported via the 'GET word, so I'd say the later 
is better, otherwise, there is no point with 'GET. 

basically, this was perfect in R2, why did it change in R3?

seems like a bug

It changed because functions were getting executed when you were 
doing a word referring to a function, rather than doing the function 
itself.

Ladislav, that ticket was related because it explained that lit-words 
were active values and that the behavior was intentional. This can 
be changed if we decide differently, but it isn't currently a bug, 
it's intentional.

I understand that the change was intended, but currently, all the 
respondents prefer the original behaviour.

And no wonder they do. If a user calls the DO function, then it is 
expectable that functions, etc. get evaluated.

Yes. But that is doing the *function*, not doing a word that refers 
to the function.

It's the difference between a: :print and a: 'print.

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?

For that, absolutely. For the lit-word/lit-path thing, no.

I hope we get more answers, since it is weekend now.

http://issue.cc/r3/1881and http://issue.cc/r3/1882submitted

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]

This keyboard is getting me crazy, sorry

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

(in R3 yout get the lit-path!, while in R2 the 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.

Makes sense

Actually I ran into problems related to this, when programming the 
bparse function. At one point, I need to test, if a token variable 
is equal to the word END. To specify the word END, I write it as 
a lit-word, because lit-words are changed to words on the run. I 
need to use == to compare, because I want the type to be the same 
too. So I would expect, this is the correct test:

	token == 'end

Let's test:

>> token: first [end]
== end
>> token == 'end
== true

Seems to work, but then the surprise, if token is a lit-word:

>> token: first ['end]
== 'end
>> token == 'end      
== true

Also true? Hmm, so I have to write:

>> :token == 'end
== false

The above is done in R2.

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.

Please, be consistent here. If you accept #1881, please reject #1882, 
for our own safety.

Oh wait, I misread #1881, I thought it was the lit-path thing. Never 
mind, it's unsafe too.

I noticed when you did the poll, you used a safe function that you 
knew the source of. Do the poll again with a function that deletes 
your hard drive, or even a block of code for some other dialect that 
will coincidentally do damage when interpreted by the DO dialect 
(since R2 does this with blocks and parens as well). Or even a function 
that takes an unknown number of parameters, and put the call in the 
middle of code that might be affected by evaluation order or get-word 
hacking.

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?

No, I mistokk what you were saying, and corrected myself in the "Oh 
wait" message.

#1434, #1881 and #1882 now have clarifying comments.

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.

Frankly, there is no security problem which can be influenced by 
this.

Stating otherwise is just pretending

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.

sute -> sure

btw, I've been using apply in R2.7.8 and it works really well   :-)

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.

And, as Brian mentions, having workarounds or being able to screen 
for exploitable features.

I'd still like to see the sort of safe evaluation as dreamt of in 
this older ML thread:
    http://www.rebol.org/ml-display-thread.r?m=rmlNVBC

There isn't much of a security page right now, though it would be 
a good idea to make one if only to document the stuff that doesn't 
currently work (like SECURE in the last 4 versions). I don't know 
if anyone else has made a concerted effort to attack REBOL and then 
fix the security problems found.

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.

Capabilities

Won't work within a process, only on a process boundary.

Depends on if you make it work

It's inherent in the semantics of REBOL, a side effect of the code-vs-data 
thing.