World: r3wp

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

reformulation: is should have said: "only if the said 'paren' is 
not supplied as a result of an expression"

I remember reading, parens are evaluated (an active type, I think 
you call it). It's a very fundamental thing. Breaking this rule make 
the code less readable. Is it really necessary? What natives or mezz 
have get-word arguments? Kinda the same with lit-word arguments (in 
the spec block). My guess is, Carl made those, so he could write:
help add
instead of
help 'add

Please, stop writing "get word arguments", they are not "get word 
arguments"

Similarly, the "lit word arguments" are not "lit word arguments"

right, what should we call them to not make confusion?

Maybe "get-word func parameters"?

they are "unevaluated arguments" in case of the QUOTE function, and 
and "partially evaluated arguments" in case of e.g. the first argument 
of the FOREACH function.

by "unevaluated" is meant "never evaluated", by "partially evaluated" 
is meant "sometimes evaluated, sometimes not evaluated"

(i didn't know about the :p where is it documented? otherwise i used 
the 'p notation many times. it even allows to add explanatory words 
to the parameters, so u can make a nice dialect by using the default 
'do evaluator...)

The R2 doc for "get arguments" is here:
http://www.rebol.com/docs/core23/rebolcore-9.html#section-3.3

thanks a lot. i thought i know the core docs in and out :)

:) I look in them now and then, as it's easy to forget many of the 
features in the language.

About unevaluated lit arguments (or literal arguments, as Carl call 
them), the functions FOR, FOREACH, REPEAT and maybe more use them 
(I couldn't remember earlier when I posted). And yes, it's more convenient 
to write
	repeat i 10 [...]
than
	repeat 'i 10 [...]


But used in some cases, it's probably easier to create less readable 
code. I can imagine a language, where this is different. About the 
other type of unevaluated arguments (get arguments as Carl call them), 
I haven't found other functions than QUOTE, that use it. There must 
be others!?

there is no LIT-LIT-WORD argument, so, to obtain a lit-word, the 
most natural way is to use: quote 'a

Some thoughts:

So one use of this is to make it easier to e.g. insert a lit-word 
in a block. I come to think of how to insert a block in a block. 
We can't do:

	insert blk [a b c]


as that will insert the 3 words, a, b and c, in blk. So I can write:

	insert blk [[a b c]]
or
	insert/only blk [a b c]


Why not use the same kind of thinking, when dealing with lit-words? 
So I can write:

	insert blk ['a]
or maybe
	insert/only blk 'a


(maybe the refinement should be called something else than /only). 
Now, the rule for INSERT should then be, that if it get a word (the 
lit-word, 'a, will be translated to the the word, a), it should change 
that to a lit-word, if it got the refinement too.


Result is, that unevaluated get arguments can be avoided making the 
REBOL scanner/parser simpler.

Geomol, if you agree with this model:
>> do quote 'a/i
== a/1
, put your agreement in http://issue.cc/r3/1434where it counts.