World: r3wp

I had made two suggestions for clauses that would make parsing better, 
a USE clause and an IF clause. The use clause was meant to deal with 
the difficulty I was having with using variables in recursive parse 
rules. The if clause worked something like this:
    [if (test) rule1 | rule2]


The trick here was that the paren would be evaluated just like a 
normal paren, but the result of that evaluation would act as a match 
or not as far as the parser was concerned. It was an absolute requirement 
that the backtracker be able to backtrack through the if clause's 
paren, and that having it return a false or none would trigger a 
normal backtrack as if the parser had failed to match. Right now, 
normal parse parens won't be bactracked through because of internal 
issues in the engine's implementation.

You can fake this kind of behavior by changing
    if (test) rule1 | rule2
to
    (nextrule: either test [rule1] [rule2]) nextrule

but it shortcircuits the parser's backtracking to check alternatives.

I needed this kind of clause to be able to include semantic checking 
in parse rules when syntax checking is insufficient. Not all grammars 
can be translated to LL(n).

The particular thing to note here is that the
    if (test)

is the entire clause. It depends on the parse dialect's own flow 
control to tell where to go next, not some passed block.

Thanks Graham! According to the internet archive, the page was started 
in March, 2000 and was taken down after Dec, 2003.

The last version of this page is http://web.archive.org/web/20021209120704/www.robertmuench.de/parse_ideas.html

I am referenced twice in this page under different, outdated email 
addresses.

then I think, that your suggestion is exactly like mine...

(as opposed to Gabriele's proposal, that is different)

May I ask you to put it to RAMBO?

(both USE and IF look worth it, maybe you can have each in its own 
ticket?)

Would it be nice to have the raised to exponent (**) operation in 
rebcode? And with decimal exponent. Maybe we should ask Carl about 
that before the first version is closed? Maybe also root operation? 
(Not just square-root, as we already have.)

a ** b can be "translated" as follows:

log-e a
muld a b
exp a

similarly root:

log-e a
divd a b
exp a

;this is probably key rebcode if you want to deal with colors of 
image pixels:)
rgb-to-dec: rebcode[r g b][
	to-dec r r
	to-dec g g
	to-dec b b
	muld g 256.0
	muld r 65536.0
	addd b g
	addd b r
	return b
]

and alpha? :-)

rgba-to-int: rebcode[r g b a][
	to-dec r r
	to-dec g g
	to-dec b b
	to-dec a a
	muld g 256.0
	muld r 65536.0
	muld a 16777216.0
	addd b g
	addd b r
	addd b a
	to-int b b
	return b
]

Thanks Ladislav! Been a while since I learned about the math. I can 
cope with it using those 3 operations instead of exponent or root.

Oldes, I think this is a bit faster ;)
rgba-to-int: rebcode [r g b a][
	lsl a 24
	lsl r 16
	lsl g 8
	add a r
	add a g
	add a b
	return a
]

Cyphre, use OR instead of ADD and there will be no troubles with 
arithmetic overflow. It'll be faster too.

I think there shouldn't be aritmetic overflows as the passed arguments 
are meant within range 0-255 but you are right that OR should be 
even faster!

so probably final version:
rgba-to-int: rebcode [r g b a][
	lsl a 24
	lsl r 16
	lsl g 8
	or a r
	or a g
	or a b
	return a
]

There might be a problem with arithmetic overflow if a < 127, as 
lsl a 24 would result in a negative integer, but I may be wrong here. 
Still, why risk it?

>> rgba-to-int 255 255 255 255
== -1

Kru, which version did you use?

last one

Cool, it works the way I thought it would :)

BTW negative integer doesn't  matter when changing pixels in IMAGE!

>> to-integer to-binary  255.255.255.255
== -1

but to integer! to binary! [issue!] is not same as rgba-to-int

OTOH the pixelformat of accesing IMAGE! in RebCode id ARGB

>> rgba-to-int 255 255 255 1
== 33554431
>> to-integer to binary! 255.255.255.1
== -255

>> to-integer to-binary  1.255.255.255
== 33554431

ALPHA is the first component

(in Rebcode)

Really?

rgba-to-int: rebcode [r g b a][
	lsl a 24
	lsl r 16
	lsl g 8
	or a r
	or a g
	or a b
	return a
]

draw-pix: rebcode [r g b a][
	apply a rgba-to-int [r g b a]
	poke img 1 a
]

update-pixel: does [
	do draw-pix col/1 col/2 col/3 col/4
	probe img
	show i
]

col: 0.0.0.0
img: make image! 1x1

view layout [
	backcolor black
	i: image img 100x100
	scroller 200x16 [
		col/1: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/2: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/3: to-integer face/data * 255
		update-pixel
	]
	scroller 200x16 [
		col/4: to-integer face/data * 255
		update-pixel
	]
]

not if you do PICK on image!

I mean in regular REBOL code.

I guess Cyphre has a good qualification for such statements ;)

I REBOL the pixelformat is RGBA due to tuple! behaviour (you can 
left the last value of tupple == opaque pixel)

So another coversion needed :)

In REBCODE you are accessing image! internally so the pixelformat 
is ARGB.

Kru: yes, in Rebol there is conversion done. In Rebcode you are at 
full speed ;)

Cypher, have you looked at the apply problem?

not yet

There's an apply problem?

trying to reproduce the problem I've just crashed REBOL with CRASH 
Should not happen

Maybe not a problem, but overhead?

And REBOL ate all memory

can you post the code?

yes, show us!

two testing functions:

>> mulr: rebcode [a][mul a 2 return a]
>> mull: rebcode [a][loop 10000000 [apply a mulr [a]] return a]