World: r3wp

Parse may be a C interpreter, but the rules are REBOL blocks, not 
text. In some ways the compiler step of a regex compiler is done 
already in parse.

sub-rule: [ ..] sub-rule-2: [ .. ]
rule: ["<" (sub-rule: sub-rule-2) sub-rule]
; is better imho.

the rexexp-rules are byte-compiled in perl to, at least optional.

Those "interpreted" aren't interpreted themselves, they are implemented 
in efficient native code in the parse engine itself.

No, it has to look up what 'any does, then there is a char. Its done 
quickly by lookup-tables, but we compare to tiny native loops here.

Yeah, that is the style I generally use too, when possible.

Right now any of those flexible parsing and rule changes are implemented 
in do dialect code in the parens. To make the rules static, you would 
have to compile that code too.

thats what 'rebcode would do.

(rebol-code) -> use rebol
rebcode [rebcode-code] -> use rebcode

But rebcode only implements a subset of the REBOL semantics. General 
REBOL isn't really compilable.

In theory.

Thats what i mean. i don't need full rebol when appending a char. 
rebcode would do.

And parse processes a lot of bytes. The parsing is fast. then the 
() are slowing down things.

There have been suggestions for additional parse operations: remove, 
replace and change. I even suggested an if clause that would allow 
the return value paren to direct the parsing flow. Between these, 
that would take care of the vast majority of the operations performed 
in parens, and thus would speed up parse a lot in practice. Even 
more than rebcode would.

By the way, the if clause in Ladislav's compile-rules is not like 
the one I suggested, not even slightly.

I prefer better handling for output. replace and change are quite 
slow (moving the whole tail). instead a fresh string and appending 
there is faster. but tickier to code.

Change/part can be fast, especially if you what you are changing 
to is the same length.

some kind of default output would be nice. 
 html: parse/out [ newline emit[<br>] ]

[ pass to "http://"copy  to {"} emit[build-tag .. ] ] ; pass appends 
to as-is, better name?

Brian: "By the way, the if clause in Ladislav's compile-rules is 
not like the one I suggested, not even slightly." - the IF clause 
at R.E.P. was proposed by Gabriele and I commented it and tried to 
suggest a "simpler" version. Where is your version described?

A few years ago the list was collecting complaints and suggestions 
about the parse dialect. Robert Muench put up a web page where those 
suggestions were collected for REBOL Tech's benefit, and then it 
went nowhere. His page isn't there anymore, but it used to be http://www.robertmuench.de/parse_ideas.html

wayback ?

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