World: r3wp

Late, but got it. it would enclose "ABCDEF" but should ignore it 
because of the small letters..

Yup. Parse is fun.

You can drop one charset by changing [non-alpha | end] to [alpha 
end skip | end | none] .

would alpha break work?

No, that would break out of the enclosing all loop. The end skip 
will always fail and proceed to the next alternate.

capital: charset {ABCDEFGHIJKLMNOPQRSTUVWXYZ}
latipac: complement capital
rule: [
    any latipac here:
    copy token some capital there:
    (all[ 4 < length? token
        insert :there "</strong>"
        insert :here "<strong>"
        there: skip :there 16
    ])
    :there
]
parse/all/case txt [some rule]

problem is "Aa", thats aword, but notan all-uppcase-word. so it should 
be ignored.

capital: charset {ABCDEFGHIJKLMNOPQRSTUVWXYZ}
latipac:  complement capital
ws: charset { ^/^-}
rule: [
    any latipac here:
    copy token some capital there:
    opt [some ws
        (all[ 4 < length? token
            insert :there "</strong>"
            insert :here  "<strong>"
            there: skip :there 16]
        )
    ]
    :there
]
parse/all/case txt [some rule]

Fails on "aA".

The inserts are a nice touch though.

capital: charset {ABCDEFGHIJKLMNOPQRSTUVWXYZ}
ws: charset { ^/^-}
latipac: difference complement capital ws


sub-rule: [
	some capital there:
	[ws | end]
	(all[ 4 < length? copy/part :here :there
		insert :there "</strong>"
		insert :here  "<strong>"
		there: skip :there 17]
	)
]
rule: [
	any latipac 
	[	some ws here:
		sub-rule
	]|[skip there:]
	:there
]
parse/all/case txt [here: opt sub-rule some rule]

Doesn't take into account punctuation in the ws charset. This would 
fail on "HELLO, WORLD!"

left as an exercise for the reader

:-)

Of course mine doesn't handle words with apostrophes or hyphens in 
them either. Easy fix though, just add ' and - to the capitals charset.

Actually my further spec for this requires the parser to detect spaces 
between capitalised words :)

And do what?

treat the two capitalised words as one so <strong>HELLO DOLLY</strong>

What about "HELLO, DOLLY!" or such?

I think that punctuation is part of a word

For that matter, what about words in quotes?

only if capitalised

So, no difference.

I'll explain the purpose of all this.

A person is writing a text file.  It has headings which are denoted 
by caps, and terminating in ":".

But some headings are two or more words ... with the last terminating 
in ":" only.

Words inside the text, even in caps should not normally be highlighted.

that's the more complete spec.

Anyway, i have a working version now :)

Well, I hope I helped :)

Yep .. thanks all.

replace/all "</strong> <strong>" ""

What is the best description of Parse?  I would like to point some 
people to Parse as an example of the power of Rebol

reichart, I wrote one in the wikibook, don't know if it's useful.

Since you wrote one, do you know of a better one?  This is not a 
reflection on yours, but it is a great way to know what you considered 
the next best thing.

salvation from regular expressions

I may have added some the the rebol wikibook

To use the simpler of the CS terms:


Parse is a rule-based, recursive-descent string and structure parser 
with backtracking. It is not a parser generator (like Lex/Yacc) or 
compiler (like most regex engines) - the engine follows the rules 
directly. Since Parse is recursive-descent it can handle patterns 
that regular expressions wouldn't be able to. Since Parse backtracks 
it can handle patterns that ordinary recursive-descent parsers can't.


Basically, it puts the text and structure processing abilities of 
Perl 5 to shame, let alone those of the lesser regex engines.


In theory, Perl 6 has caught up with REBOL, but Perl 6 only exists 
in theory for now. By the time it becomes actual REBOL should surpass 
it (especially if I have anything to say about it).

It's pretty easy to demonstrate patterns that regular expressions 
can't handle. It's only somewhat difficult to demonstrate patterns 
that can't be handled by a recursive descent parser without backtracking 
or unlimited lookahead.


I have never run into a pattern that can't be handled by Parse in 
theory - its only limits are in implementation (available memory 
and recursion depth). I am not qualified to describe its limits. 
Still, you have to be careful about how you write the rules or they 
will trip you up.

A little dry as explanations go, I suppose. You may get better luck 
by showing some magic parse code tricks :)

Somewhat buzzy: Its a simplified compiler-compiler. Could be used 
to build a java-compiler (eg such complex syntax), but its also as 
easy as regex for simpler things. But still readable. (less buzzy: 
not always that easy due to the poorer lockahead).

Volker, it's more like it can do what a compiler-compiler can do 
without needing to compile :)

And backtracking is about the same as unlimited lookahead, but more 
powerful.

Thanks Brian, but as is the theme with questions I ask, I don't ask 
for myself, but rather that the "world" can learn what "we" know. 
 So perhaps you should add your 2 cents to Henriks, and Tom's in 
a public forum of the Wikibook.

the compiling is no big argument  as compiler-compilers are for compiled 
languages anyway ;) the point is, you can mix a grammar and actions 
for semantics easy.

Reichart, I figured as much (hence the "dry" comment). I'll look 
over the Wikibook and see if I can help.

Your points are ok,only wanted to try somewhat shorter

Volker, it still might be a good point that you can skip a step with 
parse, depending on the listener. Parse is more of a compiler-interpreter 
really. The real point I was making was about the lookahead.

I can plug in handcrafted parsers with some cocos too.

I agree brian parrse allows you to write interpreter easily. Regarding 
compilation I guess it does that too. But the problem is more difficult.

aah. a compiler-compiler produces sourcecode to be compiled, but 
you can interpret data with it.