World: r3wp

{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.

BrianH: 'and, 'or, 'xor are allowed logical operations upon typesets. 
Do you think it would be usefull to allow also 'intersect and 'union, 
to allow creation of combinations?

Already spported, Pekr :)

ok then. Carl started to write-down A77 changelog, so it means we 
might be close to the first release .... or do you think he will 
merge some other tickets?

We'll see. Part of the reason for the release is to sync his work 
with the rest of the community. So, soon after a77 I can merge my 
fixes of those 15 CureCode tickets I wrote about modules yesterday, 
as well as other mezzanine fixes.

I think it's mostly a sign that we are reaching the end of this tunnel 
on plugins :)

no, we are starting to see the light at the end of the tunnel :-)

We saw the light last week :)

Hey, I just this moment figured out hot to do JIT-compiled native 
functions for R3 using Carl's new plugin model...

hot -> how

:-) cool, isn't it?

If I can get that method to work, that would allow me to work on 
the compiled REBOL dialect that I have been waiting on user-defined 
function types for. This is good news! It moves forward my schedule 
by months :)

so you don't need u-types anymore?

By the way, the method would not work with R2's library wrapping 
model - it requires the command! model.