World: r3wp

Ok, I mix lex and parse. I mean lexical analysis.

XML and HTML are relatively easy to lex, and require Unicode support, 
so hand-written lexers are probably best. Schema validation is a 
diffferent issue.

REBOL is trickier to lex than to parse, but still in the middle of 
complexity overall.

Most generators seperate lexical analysis and parsing, but I've used 
ones that don't, like ANTLR and Coco/R. There are strengths to both 
approaches.

In answer to your comments link above:
- Syntax errors are triggered before semantic errors: 1.3, 11

- Words that start with + and - are special because of potential 
ambiguity with numbers: 1.1

- Arrows are only allowed in the special-case arrow words, not generally: 
1.2, 1.3, 4

- %: is ambiguous - it could be a file that wouldn't work on any 
OS, or the set-word form of %, so an error splits the difference: 
10.2
- Fixed already: 2.2 for arrows in R3, 7, 13


Some of the rest are related to http://issue.cc/r3/537and others 
have been reported already. If you want 10.2 to not trigger an error, 
it is more likely to be accepted as a set-word than a file. Thanks 
for these, particularly the lit-word bugs.

Also fixed already: 10.1 for ( ) [ ]

Never mind about the 10.2 stuff: For some reason I forgot that % 
wasn't a modulus operator :(

If I in a function have a local variable, v, but I want the value 
of a variable v in the context outside the function, I can write:

get bind 'v bound? 'f


, where f is the name of the function. Is that the way to do it, 
or is there a better way? Full example:

>> v: 1
== 1
>> f: func [/local v] [v: 2 get bind 'v bound? 'f]      
>> f
== 1

Is that the way to do it
 - I guess not, there is a more efficient way

If you know the context you want to use and it is always the same, 
then it is a bit inefficient to call the BIND function, not to mention, 
that

    bind 'v 'f

is more efficient than
 
    bind 'v bound? 'f

Thanks!

It's for the parse function, I'm working on, and I want to be sure, 
I don't get a local var, if vars are used in the parse rules.

if the parse rule is given as a parameter, vars within the rule will 
not be bound to the function.  the binding is static, i.e. it occurs 
only once, when the function is created.  the word in the parse, 
already is bound (or not).

Ah yes, thanks.

Tonights moment of REBOL ZEN:

>> f: func [/ref x] [print [ref x]]
>> f/ref/ref 1 2
true 2

ahhha...
>>  f: func [/ref x y] [print [ref x y]]   f/ref/ref 1 2 3 4
true 3 4

Can somebody confirm if the following crashes 2.7.8 on their machine

>> -1 * -2147483648

Crashes under Windows here,
Nice catch!

I was also running under Windows.

Crashes under OS X too:

>>  -1 * -2147483648
Floating point exception

Geomol, that's something I've never seen anyone do in REBOL before. 
The discarded arguments are even evaluated properly and typechecked.

Works in R3 as well.

An old one, Peter. It is in %core-tests.r

Do  you know if it is RAMBO as I guess Carl doesn't take much interest 
in %core-tests.r ?

#4229

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.