World: r3wp

Cool (because I definitely misunderstood that last comment).

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"

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.

OK, nevermind, I shall use "explicit evaluation" for now

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.

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.

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.

yeah an error there would be better.

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.

I would like to direct your attention to the

http://issue.cc/r3/1641

ticket, since it is (IMO) directly related to the glossary.

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?

Didn't you forget about the difference between inline evaluation 
of blocks versus explicit evaluation of blocks?

No, I just didn't include them in that list. It's a special case.

yes, that exception should be kept, certainly

How about the unset word exception? Should explicit DO trigger an 
error too?

no harm if it does, IMO

That would also extend to unbound words. The harm would be in having 
explicit DO trigger an error in an otherwise harmless case that would 
be common in data. Do we need this error?

Consistency might be a good enough excuse to do so, but I don't want 
to break code unnecessarily.

(I am totally in favor of breaking code necessarily.)

For me, there is no trouble in it, but others should tell what their 
preferences are. (maybe they just don't mind much, I could tell almost 
the same about myself)

The advantage would be to trigger errors when you DO code that isn't 
properly bound or set. It's either an error that it isn't bound or 
set, or it's an error that you are trying to DO it.

Brian wrote:

<quote>
>> 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.
</quote>

No, I just posted the observed behaviour. I don't agree with it.

I would expect this behaviour:

>> do quote 'a/1
== a/1

Or better, as I'm not sure, I like get-words as function arguments 
(see source of quote):

>> do first ['a/1]
== a/1

as I'm not sure, I like get-words as function arguments

 - this formulation is unfortunate. What the spec block of the QUOTE 
 function does is that it specifies how the argument expression is 
 handled. In R3 it means "don't evaluate the argument".

Yeah, of course get-words can be function arguments. :-)

As you said, get-words in function spec blocks. I'm also not too 
fond of lit-words in spec blocks. I know, functions like HELP and 
SOURCE works like they do because of this, but if used frequently, 
code will be less readable, as I see it.

The QUOTE function is fine, and it is actually necessary, since e.g. 
there is no LIT-LIT-WORD argument, so, to obtain a lit-word, the 
most natural way is to use

    quote 'a

If it's necessary, then we need to come up with examples of functions, 
that take a lit-word as an argument. I can't think of any.

Beside trivialities like TYPE? :)

that take a lit-word as an argument
- that looks unrelated

do we understand each other?

For example, the INSERT function can take a lit-word as an argument, 
if that is what you asked

...but why did you ask that?

Yes, that's an example. I'm ok with writing

insert blk to lit-word! 'a


I asked, because you said, QUOTE is necessary. I don't see it as 
really necessary.

(old discussion, I know) :)

insert blk first ['a] is much more reasonable than that (your example 
converts a word to a lit-word, and unnecessarily so.

...because it first converts the said lit-word to a word (undesirably)

well, if it works and do the job. And it's nice, there are more than 
one way to do things.

...and I do not think it has been discussed thoroughly, but, anyhow, 
I guess, that nobody objects against having lit-words or lit-paths. 
In that case, it is strange to object against QUOTE, especially taking 
into account, that QUOTE is much more universal, so, instead of saying

    get 'word

we can always say

    get quote word

I guess, that you feel, that the ' is much less universal (available 
only in some cases), while QUOTE is universal in R3 (always usable).

Why I wrote "QUOTE is necessary" - because that is the only way how 
to do it directly. Using the "double conversion method" you can do 
it usually as well, but that certainly does not count as a "direct 
method".

I even recall we used QUOTE to explain some issues to a beginner, 
which would be impossible to explain using the "double conversion 
method"

Moreover, the first ['a] method does not apply as a "direct method" 
as well, since it really performs some action, namely it gets the 
first value of a block, which is not a trivial operation, like QUOTE.

If allowing get-words in spec blocks, then QUOTE is fine. I'm questioning 
allowing get-words in spec blocks. It can lead to uses as this:


I make a function, that can do a paren! (in lack of better example, 
but it makes the point, I think):
>> do-paren: [:p] [do p]
I can try it on a paren:
>> do-paren (1 + 2)
== 3
Works ok so far, so I try having a var holding a paren:
>> q: quote (1 + 2)
== (1 + 2)
>> do-paren q
== 3
I got the feeling, I know how do-paren works, until I write:
>> do-paren quote (1 + 2)
** Script Error: do is missing its value argument
Hm, what if I use the old method:
>> do-paren first [(1 + 2)]

** Script Error: p expected series argument of type: series pair 
event money date object port time tuple any-function library struct 
even...

That's confusing, as I see it. (Example done in R2.)

do-paren: [:p] [do p] - the only problem with the function is, that 
the function is so, that it can "do a paren", but only if that "paren" 
is already supplied as a value, i.e. not as an expression