REBOL3 tracker
  0.9.12 beta
Ticket #0001882 User: anonymous

Project:



rss
TypeWish Statusreviewed Date3-May-2011 08:11
Versionalpha 111 CategoryNative Submitted byLadislav
PlatformAll Severityminor Prioritynormal

Summary DO WORD behaviour
Description I asked REBOL users what did they prefer as the result of the example code below.

All of them preferred to get the string! datatype like in R2, with only one exception, Brian Hawley preferring to obtain the function! like in R3.

Reasons for the preference were:

* the users prefer the DO function to treat words the same way as they are treated when DO encounters them inline in a code block

* the users think that for the alternative behaviour they can use the GET function

* some of the users think the current R3 behaviour is a bug

* the users find the R2 behaviour when processing the example code perfect and more logical
Example code
a: make object! [b: does ["OK"]]
type? do in a 'b

Assigned ton/a Fixed in- Last Update6-Jan-2016 14:25


Comments
(0003170)
BrianH
3-May-2011 12:04

Um, sorry, you are missing the other part of the R2 behavior: What you propose to have DO do if passed a word value with a function assigned to it, executing the function, R2's DO also does with blocks or parens assigned to the words - even DO evaluating an inline word doesn't do something like that. It's a pretty severe unfixable bug in R2 because of backwards compatibility. Also, I notice that all of the example code in your poll had no side effects and took no parameters, let alone use words with blocks assigned to them, so the vote doesn't really count as much as you think.

In R2:

>> a: does [print "pwned!"]
>> do 'a
pwned!
; DO of a word! assigned a function executes the function, like inline word evaluation

>> a: [print "pwned!"]
== [print "pwned!"]
>> do 'a
pwned!
; DO of a word! assigned a block executes the block, completely inconsistent with inline word evaluation

>> a: func [:x y] [set :x :y insert clear :y "bye-bye data!" print "pwned!"]
>> do 'a b: [valuable data]
pwned!
>> b
== ["bye-bye data!"]
; DO of a word! allows get-word hacking!

In the mezzanine code, DO of an arbitrary function value is considered to be an unsafe practice since you can hack the code of functions using get-word parameters. At least when doing blocks and parens we can be sure that they take no parameters, so they are at least safe to call (SECURE, PROTECT and binding tricks ensure they are safe to run). For function values we use APPLY to prevent hacking, or more often we screen them out altogether categorically.

For words, there is no APPLY. We can screen them out by only allowing block! and paren!, sometimes. Adding the feature you request would add word! to the set of types that it wouldn't be safe to DO without data flow analysis or a lot of screening code.

The consistency argument (your first bullet point) is not a bad one, as long as we are really specific about what we want to be consistent with. Following the pattern of your proposed behavior for lit-words in #1434, and that of parens, it seems that it would be reasonably safe for all word and path types to have this:
>> do :some-word-or-path-value
be treated the same as this:
>> do reduce [:some-word-or-path-value]

The putting-it-in-a-block-by-itself restriction in the equivalence is important. Note that a set-word or set-path evaluated by itself in a block would trigger an error, so DO of a set-word or set-path value should also trigger an error, though not necessarily the same one (see #1883 for details). And a word or path that refers to a function would trigger an error if the function takes parameters, but not otherwise. Both of these errors reduce the attack surface of calling code, so malicious words and paths can't get access to the original version of a function body and inject code or see hidden contexts and bindings. This would make words and paths no more unsafe to DO than parens or blocks.

The behavior of R2's DO path! follows this model pretty well, so it might not be a bad idea to emulate. See #1881 for details.

When deciding about a language feature you need to not only consider how it will be used in the best case, but how it will be used in the worst case. How much screening code will you need to add to make the feature safe to use in your code? How does the amount and awkwardness of the code plus its screening guards compare to the code to do the equivalent behavior without the feature? What does the feature add that you couldn't do before? Hopefully this comment can help with this evaluation.
(0003174)
Ladislav
3-May-2011 13:28

"DO of a word! assigned a block executes the block, completely inconsistent with inline word evaluation " - I did not try to discuss that in this ticket. Please, let me know if the summary does not suffice to explain the subject of the ticket in an understandable way.
(0003175)
BrianH
3-May-2011 13:43

"* the users find the R2 behaviour perfect and more logical " - that is the part that discusses that subject. The example is misleading.
(0003178)
Ladislav
3-May-2011 14:07

Changed the formulation to "the users find the R2 behaviour when processing the example code perfect and more logical" to underline that the ticket relates to the summary. Otherwise, there are many examples when REBOL users *don't* find the R2 behaviour perfect and logical.
(0003179)
Ladislav
3-May-2011 21:04

"...and since you've requested that lit-word! and lit-path! be returned to their R2-style..." - I did not request that
(0003183)
BrianH
5-May-2011 14:03

Updated the comment accordingly, and in accordance with the conclusions reached in #1434. #1881 has some more explanation of why the limits of R2's DO path! are a good idea to follow, and #1883 deals with the same issue for DO set-path!.
(0004273)
BrianH
27-Feb-2014 20:44

Note: I am working on an implementation of this and #1881, with this behavior:
>> do :some-word-or-path-value
be treated the same as this:
>> do reduce [:some-word-or-path-value]

Coming soon.
(0004681)
Ladislav
6-Jan-2016 14:19

BrianH: "DO of a word! assigned a block executes the block, completely inconsistent with inline word evaluation" - yes, and completely consistent with explicit evaluation
(0004682)
Ladislav
6-Jan-2016 14:25

BrianH: "DO of a word! allows get-word hacking!" - you must be joking, how exactly does crippling the functionality of DO in this way prevent simpler:

a b: [valuable data]

?

Date User Field Action Change
6-Jan-2016 14:25 Ladislav Comment : 0004682 Added -
6-Jan-2016 14:19 Ladislav Comment : 0004681 Added -
5-Mar-2014 09:16 BrianH Status Modified submitted => reviewed
5-Mar-2014 09:16 BrianH Category Modified Unspecified => Native
27-Feb-2014 20:50 BrianH Comment : 0003170 Modified -
27-Feb-2014 20:50 BrianH Comment : 0004273 Modified -
27-Feb-2014 20:44 BrianH Comment : 0004273 Added -
7-Oct-2013 10:36 Ladislav Description Modified -
7-Oct-2013 10:35 Ladislav Comment : 0003178 Modified -
7-Oct-2013 10:34 Ladislav Comment : 0003178 Modified -
5-May-2011 14:03 BrianH Comment : 0003183 Added -
5-May-2011 13:59 BrianH Comment : 0003170 Modified -
5-May-2011 13:58 BrianH Comment : 0003170 Modified -
3-May-2011 21:04 Ladislav Comment : 0003179 Added -
3-May-2011 14:13 Ladislav Comment : 0003174 Modified -
3-May-2011 14:11 Ladislav Comment : 0003178 Modified -
3-May-2011 14:09 Ladislav Comment : 0003178 Modified -
3-May-2011 14:08 Ladislav Comment : 0003178 Modified -
3-May-2011 14:07 Ladislav Comment : 0003178 Added -
3-May-2011 14:06 Ladislav Code Modified -
3-May-2011 14:06 Ladislav Description Modified -
3-May-2011 13:43 BrianH Comment : 0003175 Added -
3-May-2011 13:37 Ladislav Comment : 0003174 Modified -
3-May-2011 13:28 Ladislav Comment : 0003174 Modified -
3-May-2011 13:28 Ladislav Comment : 0003174 Added -
3-May-2011 12:49 BrianH Comment : 0003170 Modified -
3-May-2011 12:04 BrianH Comment : 0003170 Added -
3-May-2011 08:11 Ladislav Ticket Added -