World: r3wp

Tasks are pretty much placeholders for now, but are intended to be 
included in the final R3. The model isn't settled.

Is there a problem with getting operators?

>> get to word! "="
** Script error: = word is not bound to a context

Using get-word syntax works:

>> :=
== op!

Ditto:
>> get to-word '=
== op!

The get-word syntax has a problem with the <> operator:

>> a: :<>
** Syntax error: invalid "word-get" -- ":"

Sunanda, so making string to words and making lit-words to words 
isn't quite the same, it seems!?

>> (to word! '=) = (to word! "=")
== true
>> (to word! '=) == (to word! "=")
== false

Strange!

>> type? to word! '=
== word!
>> type? to word! "="
== word!

Yes --  not sure why. Brian knows the internals.

Re broken syntax. QUOTE can help, eg:

>> get to-word  '<>
** Syntax error: invalid "word-lit" -- "'"

But:
>> get to-word quote <>
== op!

:-) QUOTE
(never heard of that one before)

It's R3 only

You can't do QUOTE for words in R2, but it works for other types 
(including other word types).

What's the need for QUOTE, when we have the get-word syntax?

QUOTE is mezzanine, and in mostly for qoting function references 
and other active values in generated code.

Geomol, the reason that
>> 'a == to-word "a"
== false

is because == now takes into account the binding of the word. TO-WORD 
string generates unbound words. LOAD string generates words that 
are bound to the user context - console commands are loaded just 
like scripts.

>> 'a = use [a] ['a]
== true
>> 'a == use [a] ['a]
== false

If you want to take into account the binding of a word but not its 
type (equivalency within the word types), use EQUIV? (no operator 
for it).

>> equiv? 'a use [a] [/a]
== false
>> equiv? 'a /a
== true

I see. Being a tad complex, I think.

We completely revamped equivalence. There are 4 levels now. There 
was a big blog discussion about it.

4 levels of equivalence, wow! Is that a record in computer languages? 
;-)

Not even slightly - many languages have it much worse :)

Btw, if you want to get the value of the <> word, remember that the 
same value is also assigned to the != word:
>> same? get quote <> :!=
== true

Yeah, I found !=. I guess, the :<> is a lexical bug?

(I'm still working on a deep test on the lexical analyzer and hope 
to send the result to Carl and the rest of the R3 developers in the 
near future.)

Please add the bug (perhaps aas a wish) to CureCode. There are other 
unresolved lexical bugs there already (like #537).

I'll handle it in my lex report. There are many problems with < and 
> in different combinations. I guess, it's because they clash with 
the tag! datatype. For example:

>> '<
** Syntax error: invalid "word-lit" -- "'"

while other operators work ok as lit-words:

>> '=
== =

Any use of those words conflicts with the tag! syntax. The trick 
is to set priorities.

No, the trick is to program the lexer correctly without bugs! ;-)

The lexer is where the priorities are set. What you are talking about 
isn't bugs, it is preferences (and good ones at that).

Non-configurable preferences, mind you. They have to be set in the 
source of the lexer.

Ok, I see it differently. If it's possible to make a lexer, that 
can cope with tags and lit-words and get-words like '< and :<, then 
I see it as bugs in the current implementation.

You could see it either way. Those "bugs" are backwards compatible 
with R2. However, this is clearly related to bug#666 :)

I prefer to think of them as justifiable improvements :)

We take Wish tickets as seriously as Bug tickets. Whether it is a 
Wish or a Bug doesn't affect prioritization of ticket handling.

Output from my work-in-progress lexer:

:>
Valid get-word: :>
'>
Valid lit-word: '>
<a>
Tag begin


Next it should get the whole tag and return that as a valid tag. 
I think, it's possible to make a lexer, that can handle all this 
correctly (as I see it).

It all sounds doable so far. Please remember #537 in your proposal.

Why would you write

a,


? Comma is not allowed in words. I wondered about this some months 
ago, like if Carl had some future idea for the use of comma!?

I don't want to allow , in words, I want to have the word be recognized 
and then have the lexer complain about the , next time.

Try not to break things like:
>> url? *::,
== true
(It's not always as easy as it looks :-)

Read the comments - this would be word-only. This is why I was so 
precise in the ticket, referring to TRANSCODE behavior.

Brian, ah ok.


As : is not allowed in words, that url example should be ok. But 
I'm wondering, why comma isn't allowed in words, as point is.

>> a.: 1
== 1
>> a,: 1
** Syntax error: invalid "word" -- "a,:"


I don't see the reason, other than if Carl has some special future 
idea for comma.

The comma is so bad syntactically that throwing an error every time 
someone tries to use it is considered a valuable feature.

Or maybe because comma is used in many languages to separate arguments, 
and by not allowing comma in words, REBOL might be easier to read 
for everyone.

Plus, having something as difficult-to-see as a comma in any syntax 
role is considered a bad thing. REBOL syntax didn't come out of nowhere 
- these choices were maade for good reasons. It's why we don't use 
periods as well.

If you get it, like to describe in #537, what should this return 
then?

transcode "a,0"

[a ",0"]

period is usable

and

reduce [a,0]

Except in binary. TRANSCODE works on UTF-8 binaries now. I need to 
adjust that ticket accordingly.

Geomol, that reduce example uses TRANSCODE/all, not TRANSCODE.