World: r3wp

Ok, from a freshly started REBOL, this doesn't work:

>> b: [print i]
== [print i]
>> f: does [use [i] [i: 1 do b]]
>> f
** Script Error: i has no value

But this does work:

>> b: [print i]
== [print i]
>> f: does [use [i] reduce [to set-word! 'i 1 'do b]]
>> f
1


Is it because, when b is reduced, I kinda get a new fresh copy of 
the block? Like if I wrote the block, [print i], myself instead of 
using a reference to b?

REDUCE makes a new block, and then USE does its binding.

Oki doki, that explains it.

BIND recurses into blocks, eg. 'b will be bound in the nested block 
[[b]],

but if 'b happens to currently have a value that is a block with 
words in it, that doesn't matter to BIND, BIND won't go in there.

Let me say that again, to be clear.

eg. Binding [[b]] somewhere will cause 'b to be bound (as long as 
'b exists in the "somewhere" context).

but if, before this bind occurs, b has a block value eg.  b: [some 
words] , then the bind will not touch 'some and 'words,

because it won't look to recurse into word values that happen to 
be blocks.

How to check for a datatype using TYPE? within a function in REBOL 
2? Let's say, I wanted to create my own ACTION? function using TYPE?:

>> a?: func [value] [action! = type? value]
>> a? :action?
== false

Doesn't work. Does the logic work outside a function?

>> action! = type? :action?
== true

Yes. So maybe I need to specify the argument as a get-word! ?

>> a?: func [:value] [action! = type? value]
>> a? action?
== false

No, still doesn't work. Now on to REBOL 3 to see, how that work:

>> a?: func [value] [action! = type? value]
>> a? :action?
** Script error: value is missing its value argument

Huh? Trying with a get-word! :

>> a?: func [:value] [action! = type? value]
>> a? action?
== false

No, doesn't work. What am I missing? Or is it bugs?

Try this in the console:

	>> action?
	== false


No arguments were provided. The function can accept unset! values.

Anyone got an old REBOL 1 lying around, I could have a look at?

Anton, ah, but my function doesn't work with other action! values 
anyway:

>> a?: func [:value] [action! = type? value]
>> a? first

** Script Error: value expected series argument of type: series pair 
event money date objec
t port time tuple any-function library struct ...

Trying dobble get-word! :

>> a? :first
== false

So maybe this doesn't work with any action! datatype?

It looks like your a? function evaluated the argument 'value. (I 
forget what get-word function parameters do...)
Works better like this:

	a?: func [value][action! = type? :value]

Better is
	a?: func [value][action? :value]

>> a?: func [value] [action! = type? :value]
>> a? :action?
== true

Bravo!

My mistake. I get it now!

Thanks!

Anyone got an old REBOL 1 lying around, I could have a look at?

I noticed a get-word parameter prevents a paren argument value being 
evaluated first.
>> f: func [a][print mold a]
>> f (action?)
false
>> f: func [:a][print mold a]
>> f (action?)
(action?)

Yeah, and you would probably like it to be mold :a in the function 
to not do the same mistake, I did. In your first example, you have 
evaluation of a two times, first as (action?) leading to false, and 
then false is evaluated when doing mold a.

Hey, I just read all that again. I can't figure out, why your second 
example returns (action?). That parenthesis should be evaluated, 
when you write mold a, shouldn't it?

It's the same in R3.

On the other hand, with the current behaviour, paren! works as block! 
in such situations. Blocks are not evaluated, when we write mold 
a, and a is a block. So why should a, if a is a paren! ? :-)

>> p: to paren! [a b c]
== (a b c)
>> mold p
== "(a b c)"

That's ok, I think.

yep, we need that in order to handle things like parens in dialects.

>> a: [1 2 (3 4)]
== [1 2 (3 4)]
>> third a
== (3 4)

Geomol, I think, that you missed http://en.wikibooks.org/wiki/REBOL_Programming/Advanced/Interpreter

Ladislav, how did you get the info to write that?

tests/experiments

Given some Json data like this::

{
page
:"1","total":4,"records":"22",
rows

:[{"id":null,"cell":["Quantum of Solace","Marc Forster","2008","Daniel 
Craig","200"]},

{"id":null,"cell":["Casino Royale","Martin Campbell","2006","Daniel 
Craig","150"]},

{"id":null,"cell":["Die Another Day","Lee Tamahori","2002","Pierce 
Brosnan","142"]},

{"id":null,"cell":["The World is Not Enough","Michael Apted","1999","Pierce 
Brosnan","135"]},

{"id":null,"cell":["Tomorrow Never Dies","Roger Spottiswoode","1997","Pierce 
Brosnan","110"]},

{"id":null,"cell":["GoldenEye","Martin Campbell","1995","Pierce Brosnan","58"]},

{"id":null,"cell":["Licence to Kill","John Glen","1989","Timothy 
Dalton","36"]}]
}


using Rebol-to-json, what sort of Rebol data object do I need to 
create to produce that output?

I've tried various combinations of objects and blocks and usually 
the rebol-to-json function just breaks.

I am beyond mystified!   what is wrong with this code?

(1.3 * (any  [rgb clr]))


both rgb and clr have tuple values... if I remove the any, it works, 
if I try the any and probe it, it returns the proper value... 

this is within a compose block.

 ** Script Error: Cannot use multiply on decimal! value
** Where: refresh-gfx
** Near: 1.3 * (any [rgb clr])

Try reversing the operands to the *. It seems to work:

>> clr: 0.0.0             
== 0.0.0
>> rgb: 4.4.4             
== 4.4.4
>> 1.3 * (any [rgb clr])  
** Script Error: Cannot use multiply on decimal! value
** Near: 1.3 * (any [rgb clr])
>> ((any [rgb clr]) * 1.3)
== 5.5.5

Haven't figured out why :-)

I can almost swear I tried it!  but anyhow I did the 'ANY earlier 
in the code.... and just use rgb directly now...

thanks for the help though... this is a really strange bug :-)

R2 does not allow [decimal! * tuple!] but it does allow [tuple! * 
decimal!] with a tuple! as the result
    1.3 * 9.9.9
    ** Script Error: Cannot use multiply on decimal! value
    9.9.9 * 1.3
    == 11.11.11

R3 allows both, with a tuple! as a result.

Looks like an R2 bug fixed only in R3.

In forming iso-8601 dates , you need to add the sign of the time 
zone.

Would you believe that 

pick [ "+" "-" ] positive? now/zone

is 4x faster than this

either (1 = (sign? now/zone)) ["+"] ["-"]

It relies on the behaviour of pick using false is same as pick 2

Is that going to be the same in R3?

R3 looks the same as R2 in that respect, at least right now
    pick [ "a" "b" ] true
    == "a"
    pick [ "a" "b" ] false
    == "b"

pick "+-" positive? now/zone

Those three methods timed under R3:
    dt [loop 100000 [pick [ "+" "-" ] positive? now/zone]]
    == 0:00:00.511

    dt [loop 100000 [either (1 = (sign? now/zone)) ["+"] ["-"]]]
    == 0:00:00.504

    dt [loop 100000 [pick "+-" positive? now/zone]]

    == 0:00:00.35    ;; looks like the speediest under current alphas.

If   time/zone is  0:00, should the answer be "-"?

I think it's normally + .. have to read up about it.  though + or 
- 0 is the same :)

In R2 quite different results


>> t1: now/precise loop 100000 [either (1 = (sign? -10:00)) ["+"] 
["-"]  ] difference now/precise t1
== 0:00:00.278

>> t1: now/precise loop 100000 [ pick [ "+" "-" ] positive? -10:00 
] difference now/precise t1
== 0:00:00.062

>> t1: now/precise loop 100000 [ pick "+-" positive? -10:00 ] difference 
now/precise t1
== 0:00:00.07

Interesting that R2 is much faster than F3 here.

R3

R3 is still beta -- so may be full of debugging code.

Also, are you comparing my times with yours? We have may have different 
speed machines

fastest algorithms on R2 and R3 are generally equally fast here.

I should rephrase that .. interesting my PC is much faster than yours!

....Or not running as many other processes :)

Just tried your code on R2.  You do have a faster machine than me, 
and R3 is currently much slower for this benchmark:
== 0:00:00.39
== 0:00:00.046
== 0:00:00.047