World: r3wp
[!REBOL3]
older newer | first last |
BrianH 5-May-2011 [8457] | The choice is between having behavior like what R3's lit-words do now (fully active), or what R3's lit-paths do now (special case for inline evaluation, otherwise inactive). |
Ladislav 5-May-2011 [8458] | 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. |
BrianH 5-May-2011 [8459] | 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. |
Ladislav 5-May-2011 [8460x4] | I intendedly coined the terms active value to refer to a value that when encountered inline in a block does not evaluate to itself word-active value to refer to how a word is evaluated when referring to a value |
These two cannot be "consistent" nor "inconsistent" | |
for example, parens are active, but they are word-inactive | |
(which is conveinient) | |
BrianH 5-May-2011 [8464x2] | OK. There is stuff like functions, and these are called "active values" - they behave consistently for inline, regular or explicit evaluation. There is stuff like parens, which behave one way for inline, and a different way for regular or explicit evaluation - what term would you like to use to refer to this pattern with? Because those are the only two choices that would make sense with lit-words and lit-paths. |
Maxim apparently prefers that lit-words and lit-paths act like parens, and so does Geomol. I would be OK with that model. | |
Ladislav 5-May-2011 [8466] | I prefer that as well |
BrianH 5-May-2011 [8467] | Then please say so in a comment to #1434, so we can have a consensus recorded :) |
Ladislav 5-May-2011 [8468] | OK, I will try |
BrianH 5-May-2011 [8469x2] | Then I can change the "should be" comments in the ticket example code accordingly :) |
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. | |
Ladislav 5-May-2011 [8471] | Your terminology: inline evaluation regular evaluation and explicit evaluation is acceptable for me (although I am not sure about the "regular evaluation", isn't there a chance to find a better notion?) |
BrianH 5-May-2011 [8472] | I hope so - that term seems to need too much explanation. |
Ladislav 5-May-2011 [8473] | how about "indirect evaluation"? |
BrianH 5-May-2011 [8474] | implicit? |
Ladislav 5-May-2011 [8475x3] | (there is a level of idirection, since an evaluated word refers to a value) |
so, my preferred would be "indirect evaluation" | |
But, again, we actually can see two kinds of indirect evaluation: Inline indirect evaluation , or "explicit indirect evaluation" | |
BrianH 5-May-2011 [8478x2] | Sure. The reason I called it "regular" is because a word! has no markings, either in terms of characters added to the syntax, or qualifiers added to the type name. This implies that word! evaluation is the default, or the regular style, while the others are exceptional. |
:a evaluation is inline too, so "inline indirect evaluation" could apply to that. | |
Ladislav 5-May-2011 [8480] | Why I hesitated to write my preferences regarding indirect evaluation of lit-words was, that I felt the #1434 ticket was more about the explicit evaluation |
BrianH 5-May-2011 [8481x2] | The #1434 ticket is about making lit-word and lit-path consistent with each other, and about documenting some of the intentional changes from R2. |
Are you OK with this, Ladislav? >> 'a/1 == a/1 >> b: quote 'a/1 b == 'a/1 >> do quote 'a/1 == 'a/1 Or do you require this? >> do quote 'a/1 == a/1 | |
Ladislav 5-May-2011 [8483] | Yes, but the summary says "DO evaluation...", which, for me, means either "inline evaluation", or "explicit evaluation". |
BrianH 5-May-2011 [8484] | All of this evaluation is done with DO. The question is *how* it is done with DO. |
Ladislav 5-May-2011 [8485] | OK, nevermind. I prefer do quote 'a/1 to yield == a/1 to be honest |
BrianH 5-May-2011 [8486] | As long as that is documented, I would be OK with that too. Geomol? Maxim? |
Ladislav 5-May-2011 [8487] | , i.e. I see a greater difference between direct and indirect evaluation, than between inline and explicit evaluation. |
BrianH 5-May-2011 [8488] | Then you can put your preferred behavior model (with that i.e. justification) in your comment, and we can get a consensus there through people agreeing with you. This would be the code: >> 'a == a >> b: quote 'a b == 'a >> do quote 'a == a >> 'a/1 == a/1 >> b: quote 'a/1 b == 'a/1 >> do quote 'a/1 == a/1 |
Ladislav 5-May-2011 [8489] | I will write it, removing the older (and maybe misleading) comments |
BrianH 5-May-2011 [8490] | Cool (because I definitely misunderstood that last comment). |
Ladislav 5-May-2011 [8491x2] | one more question (I guess, that a kind of glossary may be of use). How about replacing the "explicit evaluation" by "immediate evaluation" to contrast it more with the "inline evaluation"? |
may not be ideal, just wondering whether we could find something which would be obvious to be opposite of "inline" | |
BrianH 5-May-2011 [8493x2] | I meant explicitly calling DO. The other two styles of evaluation are usually the result of calling DO implicitly (through function evaluation, IF, etc.). |
All of those forns of evaluation are done by calling DO in one way or another. | |
Ladislav 5-May-2011 [8495] | OK, nevermind, I shall use "explicit evaluation" for now |
BrianH 5-May-2011 [8496] | We need to make sure that we don't follow the same pattern for set-words and set-paths. Explicit DO of set-word/set-path values doing any setting is another security hole. |
Ladislav 5-May-2011 [8497] | I do not have any preferences regarding explicit evaluation of set-words yet (do not use it), but would be curious, whether there are other users having some preferences in that regard. |
BrianH 5-May-2011 [8498] | I like the current behavior of set-words: >> a: 1 do quote a: 2 a ** Script error: invalid argument: a: But the behavior of set-paths leaves a bit to be desired: >> a: [1] do quote a/1: 2 a == [1] ; no error triggered, just a noop. |
Maxim 5-May-2011 [8499] | yeah an error there would be better. |
BrianH 5-May-2011 [8500x2] | Considering that the main use of that would be to get access to values in function code blocks that you shouldn't have access to, triggering an error seems best. |
I'll write up a bug ticket about that. | |
Ladislav 5-May-2011 [8502] | I would like to direct your attention to the http://issue.cc/r3/1641 ticket, since it is (IMO) directly related to the glossary. |
BrianH 5-May-2011 [8503x3] | I figured out a new way to express the equivalence that can safely be used for word! (http://issue.cc/r3/1882), path! (http://issue.cc/r3/1881), lit-word! and lit-path! (http://issue.cc/r3/1434), set-word! and set-path! (http://issue.cc/r3/1883), and get-word! and get-path! (current behavior), that matches the behavior of paren!. This code should work in all cases. use [a b] [ a: func [] ["blah"] foreach t compose [(paren!) (to-block any-word!) (to-block any-path!)] [ assert [any [all [error? try reduce [to t 'a] error? try [do to t 'a]] same? do reduce [to t 'a] do to t 'a]] assert [b: to t 'a strict-equal? to t 'a b] ] ] Basically, the equivalence of an individual type would be this (using word! as an example): same? do [a] do 'a b: 'a same? 'a b The important part of the equivalence would be that DO value would be equivalent to DO reduce [:value], that it be equivalent to evaluating that value inline *in a block all by itself*. That would deal with the parameter problem, with making sure that set-words and set-paths trigger errors properly, it even would work with refinements and issues. |
The only thing that it isn't equivalent for is unset words of the word! type or as the first element of a path! - inline evaluation triggers an error, explicit DO just returns unset. | |
I mean, wouldn't be equivalent after those tickets go through. Do we need another ticket or are we OK with the unset word difference? | |
Ladislav 5-May-2011 [8506] | Didn't you forget about the difference between inline evaluation of blocks versus explicit evaluation of blocks? |
older newer | first last |