World: r3wp

ok, I'm not too familar with transcode. Let me make another example. 
This works today:

>> load "a ,0"
== [a 0.0]

What should this return:

load "a,0"

Sounds like it should return [a 0.0].

Steeve, a period is usable, but not used (in general). And the period 
being usable is likely why the comma is an error.

Today it's an invalid word. You suggestion would turn something invalid 
into being valid.

comma can be _used_ in words, but not in words that have to be serialised 
and then reloaded

    to-word "a,"    ;; this works  
    == a,

    to-word ",a"   ;; there are some limits
    ** Syntax error: invalid character in: ",a"

Don't serialise and reload O:
    o: make object! reduce [to-set-word "a," 1]
    == make object! [
        a,: 1
    ]

lol, good ones, Sunanda!

Sunanda, TO-WORD "a," being allowed sounds like a bug. Report it.

It's the general thing, we've talked a bit about before, that TO 
some datatype should put the result through LOAD or something, so 
valid REBOL comes out of it.

But it's R2 compatible :)

There are other edge cases -- Latin-1 chars that can be _in_ a word 
not not _start_ them, and do not serialise well.....I did a script 
and found them all once

not not ==> but not

We've already put restrictions on the character set of words - Sunanda 
just found a hole in those that needs repairing.

But it's R2 compatible :)
 - See bug#666 :)

Some languages only allow 7-bit ascii in the source except for strings.

re: 666 -- I'll dig that script out and run it tomorrow :)

I could use 8-bit danish letters in my REBOL source, if I would:

>> æble: "apple"
== "apple"


But I don't do it. I'm not sure, if it's a good idea to allow this. 
I guess, 8-bit values are allowed, because it makes the lexer faster.

All standard functions and syntax in REBOL fit within 7-bit ASCII, 
which is why R3 source is UTF-8.

UTF-8 encoded binary!

Adjusted #537 to reflect the post-alpha-39 behavior of TRANSCODE 
(can't believe I forgot to do so before now).

Geomol, please take another look...

Sunanda, #1167 created for that to-word "a," error.

{Is there a problem with getting operators?

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


This is not operator-specific, no variable can be handled like that:

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

{>> get to-word '=
== op!}

- in the above code the usage of TO-WORD is just a no-op

{Brian knows the internals.} - see the http://www.rebol.net/wiki/Comparisons
article containing the general principles

{>> get to-word quote <>}

- again, TO-WORD is just no-op above

Knowing the internals isn't hard. I haven't seen the native source 
- I've just seen the mezzanine source, followed the conversations, 
and read sites like the onee Ladislav linked above. The rest is deduction.

{so making string to words and making lit-words to words isn't quite 
the same, it seems!?
>> (to word! '=) = (to word! "=")}

- again, the first TO WORD! is just a no-op

{What's the need for QUOTE, when we have the get-word syntax?} - 
it serves a totally different purpose, e.g.:

quote (1 + 1) ; == (1 + 1)

for comparison:

first [(1 + 1)] ; = (1 + 1)

(1 + 1) ; == 2

another QUOTE:

quote  'a ; == 'a

(another way how to obtain that would be e.g.):

first ['a] ; == 'a

I *really* like the new :a parameter behavior in R3 that makes QUOTE 
possible :)

yes, that makes the thing really useful :-)

Or, since the get-word syntax was mentioned:

quote :x ; == :x

, so, the most useful property is consistency; it always does the 
same (actually nothing)

{while other operators work ok as lit-words:
>> '=
== =}


- just a note; in the above example there is no operator, just a 
lit-word, that is handled as "valid" by Rebol loader in this case 
(as expected)

the power/simplicity of QUOTE is, that even in case the lit-word 
syntax isn't handled correctly, QUOTE works as expected:

quote <> ; == <>

I think, the lit-word syntax should be fixed anyway.

I wasn't aware, that this doesn't work in R3:

get to word! "a"


So it's not a problem with operators, but a general change. The above 
code is valid R2 code. I can't judge, if it's a needed change or 
not, but it will trigger thoughts about R2 compability. I guess, 
the change will break a lot of R2 code!?

that would be because words aren't bound by default in R3.

I see. Does it make sense to not bind words by default? I feel, Carl 
might have a blog about this. :-)

I think this was quite a big topic a while ago. It has something 
to do with modules.

I came across another funny thing. Are << and >> planned as operators?

>> ? >>
No information on >>

So >> is a valid word. But >>> is not:

>> ? >>>
** Syntax error: Invalid "word" -- ">>>"

I think, the lit-word syntax should be fixed anyway.
Same can be said about get-word syntax.

Yes, it makes sense to not bind words by default. Carl has written 
many blogs about this, going back more than a year.

There is no one shared global context anymore, so which context to 
bind to is a policy decision. Default needs to be unbound to do this

>> and << are likely allocated for user-defined operators. Please 
don't allocate >>> and <<< - it would be too hard to discourage their 
use if they are allowed syntax. We don't want REBOL to become a write-only 
language like Perl.

Any reason why NONE acts as an honorary empty block in each of these 
under R3:
    a: none forskip a 1 [print a]
    a: none forall a [print a]
    foreach a none [print a]
R2 would not be happy!

Why not.. it seems to be logical to me.

Logical, maybe. Harmless, perhaps. But odd ..... and inconsistent 
with REPEAT:
    repeat a none [print a]

    ** Script error: repeat does not allow none! for its value argument
So I am wondering if it is a deep feature, or an oversight.

The REPEAT behavior sounds like an oversight - but the none argument 
was left out of MAP on purpose, so who knows?

As for the other functions, it is an intentional change from R2, 
which reduces special-case code wrapped around FIND and SELECT.

Thanks -- I'll add a curecode so the possible oversight is on the 
checklist.