World: r3wp

I'm not arguing about how lit-words are used.  I'm arguing about 
how lit-word? detects lit-word.

The rest is understood that it should work they way it should be 
cause of the manner of words in REBOL.  But the function of lit-word? 
is what to me seems inconsistent.

I understand all of that IzKata.  I have been using REBOL since 1998 
now.

That part has remained pretty much the same.

My argument lies specifically with the lit-word? function.

What is wrong in having lit-word? return True in this case:

lit-word? 'test
==true

but argument to lit-word? in your case is not lit word , it can't 
return true vithout magic 

>> 'test
== test (this is what lit-word? recieves in)

Yes it is Janko, a TRACE shows that my argument  is a lit-word.

If you were correct Janko then how would Trace know to classify my 
argument as a lit-word?

how do you make this trace (I never used it, and also don't understand 
what exactly it shows)

Trace shows what the rebol interpreter first finds, not what a datatype 
evaluates to:
>> type? 'test
Trace:  type? (word)
Trace:  'test (lit-word)
Result: (datatype)
== word!

Janko:
>> trace on
Result: (unset)
>> 'test
Trace:  'test (lit-word)
== test

Yes Izkata, it finds that 'test is a lit-word.

And the interpreter converts it to a word! before passing it to 'lit-word?

so lit-word? never sees a lit-word!

Yes, I understand that.  But that is not what it was given.

Again, I'm saying what is wrong with having the lit-word? function 
return true for a lit-word value?

Obviously the interpreter can see that it is a lit-word value even 
BEFORE it calls it a word! value.

But it does:
>> X: ['Test]   
== ['Test]
>> lit-word? X/1
== true

Yes, I know Izkata in that case but that  is not consistent with 
this one:

lit-word? 'test
==false

Nobody is answering my question though - what is wrong with having 
lit-word? return true in the case above?

Because it never sees an actual lit-word! - all the other (datatype)? 
functions do.

never actually sees*

Trace shows that it does see it as a lit-word

>> 'test
Trace:  'test (lit-word)
== test

Trace shows that the interpreter - not the lit-word? function - sees 
a lit-word before it gets evaluated

not after

Exactly!!!  So why don't we modify lit-word? function so that it 
can say true when it sees it?

See if I asked someone to tell me what type this is:

'test


They would most likely respond a lit-word.  So shouldn't the lit-word? 
function say the same?  I say it should.

Rebol, the interpreter, sees a lit-word!.  Trace shows this.  It 
*then* evaluates it to a word!, *then* passes it to lit-word?, and 
lit-word? never sees the original lit-word!

I would ask if it's a line of code or data

Trace doesn't show that it evaluates it to a word.  I don't know 
where you get that.

If it did, then I would think that Trace woudl show that but it doesn't 
- again:

>> 'test
Trace:  'test (lit-word)
== test

nothing about it being word! in that trace.

Exactly, trace doesn't show that.  Trace doesn't show everything.

Well then how can we be sure that is the case?

>> Gettype: func [A][print type? A  return A]
>> lit-word? Gettype 'Test                   
word
== false

In other words how do we not know that the native lit-word? function 
couldn't be modified to in fact report true in this case?

Unless large modifications are made to the language itself, it would 
also start returning true for regular word! values

Well that is my Izkata, how do we know that - are we just assuming 
that?  I mean we know that it can handle the data as a lit-word while 
it is in an unevaluated block.

For example, why can first ['test] return lit-word then?

Surely we can return true with a modification to lit-word? function 
to do the same for lit-word? 'test

Izkata, let my pose a hypothetical question to you.  If lit-word? 
could return TRUE to this statement:

lit-word? 'test

Would you desire that ability?

No, as I would then never know if something's datatype was a word! 
or a lit-word!

sure you would.  a word that doesn't have the tick in front of it 
woudl be a word!

No

first is function! that gets evaluated. it takes one argument - block! 
that argument is also evaluated and block! is evaluated to block!. 
then it returns first value of that block. this value is not evaluated 
- but that's ok, it's 'first's behaviour

But it's better to submit it as a wish into CureCore and see what 
Carl means

Oldes I was going to personally take it to Carl via RebDev but I 
won't if the community doesn't desire it to report true in such a 
case.

Paul, how would you check that?  String manipulation?  Because trying 
to get the first character of a word! or a lit-word! errors