World: r3wp

When I go into discussion like this, it's mostly because I want to 
understand, what REBOL is. After using it for like 10 years, there 
are still areas, where I'm not sure, what's intentional and what 
isn't. Must of the problem (of understanding the REBOL behaviour) 
is because it's not officially well documented. ("Officially" I mean 
by Carl.) REBOL is still not set in stone, as I see it.

What about MAKE block! ? Does that include a copy? Will it in R3?
 - this is a funny question. The

    make block! []


expression does make a copy of the block given, both in R2 and in 
R3. The reason is quite simple: if it did not make a copy of its 
argument it would not make a block at all.

As you may verify, all MAKE calls actually make a new value, so it 
would be a violation of that rule

Right, and I asked this question to test a general view, if MAKE 
should involve copy or not.

But, as you may see, there is another general rule in effect there

MAKE BLOCK! 10 does not make a copy of anything, yet it makes a new 
block as wished

Cyphre fell into 

the trap" when writing async code" - as it stands, async code is 
"too hard" in REBOL. (IMHO of course.)

Can FIND find the datatype block! among blocks in a block? Boy, does 
that sound like a strange question? An example:

>> find reduce [[] [] block!] block!     
== [[] [] block!]


That's not the result, I'm after. I want FIND to return [block!], 
but that doesn't seem to be possible. Is there a trick?

I think you have to do it in two steps. First find datatype! and 
then check if that datatype is block!.

Or you may use PARSE.

>> find reduce [[] [] block!] datatype!     
== none

That seems odd.

Yeah, I was thinking along the same line, doing it in two steps. 
If one wants to make a mezzanine SWITCH, it'll be slow, I guess.

Henrik, yes, surpricing!

That works in R3 though, so must be missing in R2.

http://www.rebol.net/cgi-bin/rambo.r?id=4332&

Same issue with FIND on native! values: http://www.rebol.net/cgi-bin/rambo.r?id=4126&

A sidenote about SWITCH: I often find myself needing a switch, where 
I look for datatypes, like:

	switch type? value reduce [
		integer! [...]
		word! [...]
	]


It works, but only if I include the REDUCE, else the words in the 
block are just words. I was thinking, if SWITCH should have a refinement 
telling it to reduce the block, or something. Do you have same kind 
of switch as me?

geomol, use type?/word

that returns the type as a word. it seems to be made precisely for 
this scenario.

ah, didn't notice type?/word, thanks! :)

I tried it only in R3, I'm not sure about R2

So my original FIND can be solved with:

>> find [[] [] block!] to word! block!
== [block!]

well, if the block is reduced elsewhere, that would be a problem.

yes

I have got a question of soon-to-join-us-here reboller, asking about 
the possibility to launch new rebol process, using lowered security.

launch "some-script.r" works
lanuch "--secure allow --script some-script.r" does not work

I think I might use 'call instead?

Hmm, strange. When I type: launch "-s some-script.r", then uninstall 
dialog box appears.

Yep there are some problems using launch I think.

launch {-s --noinstall} ;--> starts nre Rebol process in trace mode. 
just like I use -t option.
Strange..

>> launch/as-is {-s}
** Script Error: Feature not available in this REBOL
** Near: launch/as-is "-s"

I suggested my friend to use: call "rebol.exe -si my-script.r"

better option I think as launch is really problematic.

LAUNCH, RUN, and CALL make things confusing. I almost always use 
CALL now.

Composing a lit-path:

>> f: [b d e f]
== [b d e f]
>> i: 2
== 2

It would be nice that instead of this:

>> compose 'f/(i)
== f/(i)

you would get:

== f/2

Doesn't work in R3 either.

I think that it should throw error, because 'compose should accept 
only block! value.

lit-path is a series, so I think the argument is sound for the latter 
result.

It gets rid of a workaround, where I must store a path, where some 
values in the path can't be determined until storage, the moment 
where COMPOSE needs to act. The workaround is to create the path 
as a block, and then TO-PATH it on use.

>> f: [b d e f]
== [b d e f]

>> i: 2
== 2

>> my-path: rejoin [to path! [] 'f i]
== f/2

or, in R2:

    my-path: rejoin [#[path! []] 'f i]

or
>> append to-path 'f i

A fast way is:
>> to path! reduce ['f i]
== f/2

(Maybe the fastest?)

But yes, Henrik, COMPOSE should maybe work on path too, as it is 
a series. And maybe also on parens (also a series), where COMPOSE 
should work on parens inside.

REBOL handles parens in paths today. I can see the usefulness of 
having that evaluation return a composed path.

>> equal? make object! [] make object! []
== false

is this intentional?

It may be because they are considered to have distinct 'self's

    a: make object! []
    b: make object! []
    equal? a b
    == false
    equal? (first  a) (first b)
    == true
    equal? (second  a) (second b)
    == false
    equal? (third  a) (third b)
    == true
    a/self = b/self
    == false

and it's more useful than the other way I think. Once I wrote a function 
to test if two object is similar. It looks a bit silly but works 
for me. Can be extended to test values also:

similar?: func [
    {Returns true if both object has same words in same types.}
    o [object!] p [object!] /local test
][

    test: [if not equal? type? get in o word type? get in p word [return 
    false]]
    foreach word sort first o test
    foreach word sort first p test
    true
]

>> similar? make object! [] make object! []
== true

There's some (fixable) bugs in R3 related to equality of objects, 
and some different (unfixable) bugs in R2. In R3 at least:
>> equal? make object! [] make object! []
== true

R2's behavior in this may not be intentional, but it's not fixable 
because of backwards compatibility :(

ok, interesting, thanks.

Today's Long Moment of REBOL Zen:


When making an object, code in the block argument is executed. I 
found, BREAK stops further execution:

>> o: context [a: 1 break b:2]
>> ? o
O is an object of value: 
   a               integer!  1


So the B assignment isn't carried out. Ok, what about a RETURN in 
object creation then? I'll use MAKE OBJECT! instead of CONTEXT, so 
the RETURN is not handled by CONTEXT, which is a function:

>> o: make object! [a: 1 return 0 b:2]
>> ? o
O is an object of value: 
   a               integer!  1


It seems like, making objects can handle returns ... in R2 at least. 
This has changed in R3, where the result is:

>> o: make object! [a: 1 return 0 b: 2]
** Throw error: return or exit not in function


This seems reasonable. What if I use CONTEXT and use RETURN in the 
object creation? In R2 CONTEXT doesn't have a THROW function attribute, 
so my guess is, RETURN will return from CONTEXT, and the rest of 
the object isn't made, and this is what happens:


>> o: context [print "before return" return 0 print "after return"]
before return


Ok, I now want to fix CONTEXT by putting the THROW attribute in, 
and then test it by making an object using CONTEXT, but this time 
inside a function:

>> context: func [[throw] blk] [make object! blk]

>> f: does [context [print "before return" return 0 print "after 
return"] print "still in f"]


When running F, I would expect to just see the words "before return", 
but

>> f
before return
still in f


I see, that THROW doesn't work as intended, when making objects. 
This is the same in R3, where CONTEXT also doesn't have THROW, and 
when trying to fix that by changing CONTEXT, it's still the same 
behaviour as in R2.