World: r3wp

ok, so you will not catch the 'face word:-) as it end up in the img 
variable:-)

I think he might be using 'test-image in place of a real image! for 
this example ?

oldes, nope, because I have many different blocks. they either start 
with 'face or with 'image

never both

That's good.

So you can use ANY in an unlimited fashion.

and it makes the parse scalable, so I can add options later

thanks for your help, everyone :-)

cool :)

It's also a good thing with these discussions. I've never really 
grown 100% comfortable with parse.

About Layout : parse handles only the layout words (origin, space, 
at...), see source layout.

The face description is handled by a loop, not by parse. See system/view/vid/grow-facets

Hi, need a bit of help ....

I tried doing myself small template "engine", which will simply look-up 
for some marks, and replace values accordingly. I decided to look 
for the end of the marks and my friend suggested me, that I should 
name even ending marks, to be clear there is not an error. My parse 
looks like this:

REBOL []

template: {

<b><!--[mark-x]-->Hello x!<!--/[mark-y]--></b>
<b><!--[mark-y]-->Hello y!<!--/[mark-y]--></b>
<b><!--[mark-z]-->Hello z!<!--/[mark-z]--></b>
<b><!--[mark-w]-->Hello w!<!--/[mark-w]--></b>

}

parse/all template [
   some [
         thru "<!--["
         copy mark to "]-->"
         "]-->" 
         start:
         copy text to "<!--/["
         end:
         "<!--/[" mark "]-->"
         (print text)
         |
         skip
    ]
]           
         
halt

I now can create simply a func, which will accept mark name, and 
do some code-block accordingly - sql query, simple replace of value, 
whatever (well, it will not work for cases like img tags, so it is 
not as flexible as full html parser in temple for e.g., but hey, 
it is meant being simple)

... but should not be simpler, so I wonder - so far, as you can see, 
mark-x is not finished, so it is ignored. How to catch this case 
properly and eventually generate error, send email, write to log, 
whatever?

I did that recently for COMLib. Look for  build-comlib-website.r 
 in the files section of the COMLib website.

(my end tags are simpler though)

ok, will look into. Is that much complicated than mine is? :-)

this one works better for me:

parse/all template [
   some [
         thru "<!--["
         copy mark to "]-->"
         "]-->" 
         start:
         copy text to "<!--/["
         end:
         "<!--/[" 

         [mark "]-->" (print text) | (print ["not found end of: " mark]) :start]
         |
         skip
    ]
]

Petr.... you just reinvented erebol, rsp, .... build-markup?

But it does the job, as far as i read.

Maarten - not reinvented - rsp, iirc, mixes code of rebol with html, 
which I don't want to allow

template has to be displayable as gfx man does it, with temporary 
text, images, whatever .... I am just supposed to get correct data 
in there ....

Maarten - now looking into build-markup - sorry, it is just strange 
was of doing things .... noone will place rebol code into template, 
that will not work ... btw - the code is 'done? What happens if someone 
uploads template with its own code? I want presentation and code 
separation.

I looked into rsp some time ago, and I liked it, especially as it 
was complete, with session support etc., but later on I found shlik.org 
being unavailable ...

Maarten  - is RSP still available anywhere for download? erebol.com 
nor shlik.org do work ....

Petr, I have a copy with some notes here:
http://www.ross-gill.com/techniques/rsp/

I think, that Tim Peters knew what he wrote here: http://mail.python.org/pipermail/python-dev/1999-December/001770.html

Very nice comments. But comparing a parser with a regex is a bit 
unfair ;-)

Yeah, for either :)


Still, Peters seems to think that REBOL parse rule blocks are closures, 
for various reasons that are clear from context.

They aren't, though something like parse closures has been suggested 
during the latest round of enhancement proposals.

They are quite like smalltalk-closures. Without locals, but locals 
are not his point. (he may miss them for recursion).

Hey, locals and arguments (practically the same thing in REBOL) are 
the most important difference between closures and plain blocks. 
The difference is significant but Peters' background with Smalltalk 
made him miss it - Smalltalk "blocks" look like REBOL blocks but 
act like functions.

No, the main point is, easy definitions of code and referencing the 
original context. Rebol-blocks do that.

You can  have closures without any arguments.

The highlights he mentions is: lexically-scoped, code and data,  
freely mix computations in

That scoping is the difference between a closure and doing a "string" 
here.

REBOL blocks don't reference a context, but they may contain words 
that reference a context. Still, this distinction makes no difference 
to the argument that Peters was making - REBOL text processing is 
more powerful than regex and easier to use. It would be easier to 
replicate REBOL-style parsing in Python using closures and generators 
anyway (Peters' real subject), since that is the closest Python gets 
to Icon-style backtracking.

its not important what references the context, but that a variable 
can find one.

result := a > b
    ifTrue:[ 'greater' ]
    ifFalse:[ 'less' ]

There are two closures here. Rebol could do it the same way.

besides, Tim was a REBOL 1.x user

didn't parse come with 2.0?

it did, so it looks, that Tim is still silently watching REBOL

most probably he didn't leave as soon as we think :) i think i remember 
him on the list in 2.0 times too.

seems you are right

Maybe someone find it usefull:

remove-tags: func[html /except allowed-tags /local new x tag name 
tagchars][
	new: make string! length? html
	tagchars: charset [#"a" - #"z" #"A" - #"Z"]
	parse/all html [
		any [
			copy x to {<} copy tag thru {>}  (
				if not none? x [insert tail new x]
				if all [
					except
					parse tag ["<" opt #"/" copy name some tagchars to end]
					find allowed-tags name
				][	insert tail new tag ]
			)
		]
		copy x to end (if not none? x [insert tail new x])
	]
	new
]

Wouldn't it be nice, if the /case refinement for parse also worked 
with words, when parsing blocks?

>> parse [aBc] ['abc]
== true
>> parse/case [aBc] ['abc]
== true

It should work like when parsing strings, I think!

>> parse "aBc" ["abc"]
== true
>> parse/case "aBc" ["abc"]
== false

Why? words are not case sensitive by definition.