World: r3wp

Thanks Ladislav.

Tonight's Moment of REBOL Zen:

Check this Fibonacci function:

fib: func [
	n [integer!]
	(
		if not local [
			a: 0
			b: 1
		]
		prin [a b ""]
		loop n [
			prin [c: a + b ""]
			a: b
			b: c
		]
		print ""
	)
	/local a [integer!] b [integer!] c
][
	do bind third :fib 'a
]

>> fib 10
0 1 1 2 3 5 8 13 21 34 55 89 
== 89
>> fib/local 10 55 89 none
55 89 144 233 377 610 987 1597 2584 4181 6765 10946 
== 10946


If you only want to execute the paren in the function spec, put this 
in the body instead:

	do bind to block! third second load mold :fib 'a

A more simple example of this weird function construction:


>> hello-world: func [(print "Hello, World!")] [do third :hello-world] 
    
>> hello-world
Hello, World!

moebius function. its body bends and bites back into its own spec 
:)

can anyone confirm that 'CALL on windows 7 is unable to launch apps 
without using the /show refinement.... which is VERY annoying.

it seems that call/shell no longer works.

I use CALL without /show in Cheyenne to start worker processes. Anyway, 
CALL is quite unreliable in 2.7.8 on Windows as shown by this RAMBO 
ticket: http://www.rebol.net/cgi-bin/rambo.r?id=4416&

Tonight's Moment of REBOL Zen:


The /local refinement in functions is just like any other refinement. 
This again mean, any refinement can be used for local variables, 
like in this example:

exp2: func [
	"2 raised to exponent"
	exponent [number!]
	/il-locale number [number!]
][
	if not il-locale [number: 2]
	number ** exponent
]

>> exp2 3
== 8.0
>> exp2/il-locale 3 3
== 27.0


But HELP will search for the /local refinement, when producing its 
output. But as any word, HELP can just be redefined to serve ones 
needs. HELP is even a function, so its source can be looked at, if 
someone wants to produce ones own HELP function.

/local is special only in HELP not listing any refinements and args 
from the /local refinement onwards. You can even use that to hide 
refinements (sth. like 'private' refinements):

>> zen: func [arg [integer!] /local /private base] [add any [base 
0] arg]
>> zen 1
== 1
>> help zen
USAGE:
    ZEN arg

DESCRIPTION:
    (undocumented)
     ZEN is a function value.

ARGUMENTS:
     arg -- (Type: integer)
>> zen/private 1 10
== 11

just remember that in R3, the /local refinement might be given special 
status in a future release. this was mainly to prevent you from supplying 
default values to locals which can be a pretty big security hole 
right now.

That shouldn't be a problem, Max, I don't think too many people abuse 
implementation specific hacks like this one in code other than zen 
examples ... ;-)

Long discussion of R3/local here:
    http://www.rebol.net/cgi-bin/r3blog.r?view=0341

Tonight's Moment of REBOL Zen:

>> skip [a b c] to integer! true
== [b c]
>> skip [a b c] true
== [a b c]

Yup. The order of logic values as considered by SKIP, PICK and POKE 
is true then false. This was done to make PICK compatible with EITHER.

Carl uses PICK instead of EITHER a lot. He also marvels that this 
trick isn't used more often, especially since he added logic indexing 
specifically for that purpose :)

Interesting explanation! Gives us even more Zen to think about:

>> pick [a b] true 
== a
>> pick [a b] to integer! true
== a
>> pick [a b] false           
== b
>> pick [a b] to integer! false
== none

well, difference in types is expected, its the point of having dynamic 
typing.  I don't think its a required feature for type casting to 
result in symmetric uses of other functions.    I expect to-from 
one type to another to be as symmetric as possible, but not what 
they mean in another context of usage.

Yup, because PICK, POKE, AT, INDEX? and /1 work with indexes, while 
SKIP works with offsets.

I would like to use the PICK option more, if also NONE was supported 
as the first item.

But that would make PICK data none the same as PICK data true, not 
PICK data false.

I would really like it if TRUE? was native. There's too much code 
that needs PICK reversed-data NOT condition, which would be better 
expressed as PICK data TRUE? condition.

perhaps there should be a three-state PICK instead.

0 = none, 1 = true, 2 = false?

Or -1, 0, 1 if you are thinking in terms of offsets instead of indexes.

that depends if both the concept of three states and index direction 
change can be merged into one function and if that makes sense.

I like that PICK is stopping point for none propagation. PICK data 
none should trigger an error, because otherwise you couldn't tell 
the difference between that and PICK [#[none]] 1.

is -> is a

We keep adding more points of none propagation, and every time we 
add one it makes more errors propagate further away from their point 
of origin. This makes it harder to figure out which code caused the 
error where none wasn't screened for or checked for, making it that 
much more difficult to debug.

We don't want REBOL code to be as difficult to debug as SQL.

Although PICK does propagate none indexes for datatypes where PICK 
acts the same as SELECT, such as map! or object!.

Tonight's Moment of REBOL Zen:

Literal and Get Arguments in R2

see: http://www.rebol.com/docs/core23/rebolcore-9.html#section-3.2

These functions use Literal Arguments:


 ++ -- ? ?? cd default deflag-face first+ flag-face flag-face? for 
 forall foreach forskip help l ls map-each remove-each repeat secure 
 set-font set-para source

This function uses Get Argument:

	quote

It could be questioned, why functions like

	get set unset in catch throw checksum


, which all have arguments named WORD, don't use Literal Arguments?

Lit-word arguments are for functions that treat words as keywords 
or part of the syntax, or for interactive command line functions 
that are supposed to act like shell funcs. If you use lit-word arguments, 
you can't easily generate the value passed using an expression, especially 
in R2 - in R3, those expressions can be put in parens, as is emulated 
in the R2 mezzanine backports of R3 functions that take lit-word 
arguments. For instance, if you made GET take a lit-word argument, 
GET IN wouldn't work.

The only exception to the above is ++ and --, which take lit-word 
arguments because their primary use is with a literal word value, 
so taking a lit-word argument gets rid of a ' in the most common 
case. And since ++ and -- started in R3 and has its behavior explicitly 
emulated in R2, you can put word-generating expressions in parens 
for the less common case.

FIRST+ is part of the same exception as ++ and --.

Does it make sense to have a timestamp datatype as distinct from 
a date type

Breakdown by reason:

- The word is pseudo-syntax for loop vars: FOR FORALL FOREACH FORSKIP 
MAP-EACH REMOVE-EACH REPEAT

- The function is pseudo-syntax for modifying operations on literal 
words as variables: ++ -- DEFAULT FIRST+

- Keyword arguments that aren't generally in expressions: DEFLAG-FACE 
FLAG-FACE FLAG-FACE? SECURE SET-FONT SET-PARA
- Interactive shell functions: CD LS ? ?? HELP SOURCE

>> to date! now
== 15-May-2011/10:41:51+12:00
>> to date! "15-May-2011"
== 15-May-2011

to date! creates two different types

A timestamp more precise than NOW/precise?

No, to date! creates either a date only , or a timestamp at present

it's inconsistent

it should create a date at 0:00 and GMT

if those are not provided

A source for errors ....

The date! type is a datetime type with an optional time portion. 
We can get rid of the time portion already. What do you want that 
we don't have already?

to date! should create a timezone and hour by default

But that doesn't work when you don't want a time and date.

>> d: now/date
== 14-May-2011
>> d: now d/time: none d
== 14-May-2011

When you requested a timestamp type, I thought you were requesting 
a timestamp type, not a datetime type.

in databases .. date and timestamp are different