World: r3wp

I think your assessment is accurate though.

There are some occasions where the behavior of an op! or action! 
is different depending on what datatype its first argument is. Actions 
dispatch based on the type of their first argument only, so making 
the behavior work with the types reversed might require double-dispatch 
to work. This is a similar situation to that of Smalltalk classes.

hmm, it seems Carl did not succeed to resolve Plug-in interface, 
so we are getting some "simple method" ....

It's also possible that excessive complexity was the problem that 
needed resolving, and the "simple method" is the solution :)

yes. It is now at least clear, we will see soon :-)

A quick update on plugins - http://www.rebol.net/r3blogs/0226.html

nice

What's bad about a simple plug-in solution?

Only bad if simple = limited

maybe it's time for a beta version, as most features are in its place 
then?

still need modules and more bug fixes

I think that when we hit beta, people might expect to start writing 
production scripts with it. So we have to be sure that the important 
areas won't change too much between beta and final.

Two questions about calling other programs /scripts:


* when is CALL going to get some refinements -- like /wait and /output 
?

* what is the point of:
     launch none 
    ?

AFAIK:

* CALL might or might not get refinements - it may be a better strategy 
to just fix CALL so it doesn't need them. In any case, changes to 
CALL are likely to happen after the host code is released, since 
that is where CALL is implemented.

* What is the point of <anything about how LAUNCH behaves>: It's 
due for a complete redo - none of its current behavior is intended.

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" -- "'"