World: r3wp

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.

I'm wondering now if there will be easy ways to check whether a char! 
is: lowercase, uppercase, a number or an international char.

that might be useful during PARSE

I think that distinguishing between upper and lower case chars is 
very difficult with Unicode.

Carl seems to have done a great job with Latin characters:

>> uppercase to string! #{C3A0}
== "À"

>> lowercase uppercase to string! #{C3A0}
== "à"

>> uppercase to string! #{C48D}           
== "\u010c"

>> lowercase uppercase to string! #{C48D} 
== "\u010d"

Though don't know what the above will look like in AltME under Windows 
or Mac

looks good - R with comma upon it ...

There seems to be some problems with other alphabets though:

>> uppercase to string! #{E382A1}         
== "\u30a1"


\u30A1 is a small katakana letter A. The unicode for a caplital katakana 
A is \u30A2

Pekr - it is actually an a with a grave accent over it in UTF-8

hmm, should uppercase and lowercase really work with katakana and 
hiragana? the "small" versions have a completely different meaning 
and usage than our "lowercase" has.

it seems to me, that uppercase and lowercase should not modify kana... 
but I haven't read what the unicode standard mandates here.

No doubt you are right. I haven't read the unicode standard and know 
nothing about "non-Latin" alphabets.