World: r3wp

First docs appeared - http://rebol.com/cgi-bin/docs.r?do=sumlog

BrianH: I miss call/output, call/wait refinements at least ....

I also don't understand, why the regressioin of 'call happened.

Thanks for the explanation, Brian.

hmm, no IO, callbacks this time .... I look forward to REBOL gurus, 
bringing some usefull features to R3. However - it is more than clear 
that this type of interface is not for all. So - I still look forward 
for vastly improved DLL interfacing method, which allows even ppl 
like me to have some usefull things done ...

Does anybody know the reason that money! is not included in the list 
of immediate datatypes for plug-ins?

Following on from asking about CALL and LAUNCH.....Is TASK meant 
to be any thing other than a placeholder in the current alphas? All 
it does for me is crash the console.

Does anybody know the reason that money! is not included in the list 
of immediate datatypes for plug-ins?
 - money! is not 64-bit datatype

Money: Well, but it should be possible to exchange it as a struct 
or whatever is needed. And we can provide some C-level code to handle 
the internal format.

I somehow can't understand, what is the difference between a plug-in 
funciton, and for e.g. C level function wrapped into DLL call (R2 
way)? The example provided in doc shows rather complicated aproach 
of how such function has to be constructed. You simply can't write 
it your way? There has to be some reason for it :-)

Pekr, there is no regression: CALL in R3 is an entirely new function, 
which uses an entirely different, lower-level method to call stuff. 
I don't know whether the /output and /wait methods are possible with 
the new method, or whether they will be necessary once CALL is fixed. 
Right now CALL is a placeholder - the implementation is going to 
be in the host code (read: open-source), so development has been 
put on hold on CALL until the host code is released (which is intended 
to be soon).

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 :-)