AltME groups: search

parse handles a literal word indivisibly

You'd probably need parse if the item was more complex.
I think parse would be overkil here.

thanks...got all that working (did a parse after all, mold/only the 
block of words to strings before parsing.

the main problem I think with this kind of hierarchical and dynamical 
size struct is to be anought performant and close to the original 
to save code writing  time and tu enhance the loading performances 
in such tasks. Actually you need to parse and readapt each data from 
the binary dump file to rebol based   things. And that's an heavy 
task


This can be usefull for all langages that allow binary dump file 
read/wirte like C, VB and many others.

if that is the struct of the data stored in a file, it should not 
be too hard to parse the file to get the information...looks like 
a 3-D rendering file or ?

when Josh appears, we will scratch each others heads and see if we 
can determine a way to parse this...he has done some work like this 
for his NASA project...and he is working on some crazy computer science 
parsing algorithms...I think he has been chatting with Ladislav too 
long ... ;-)

Not really. I start with a string:
output: make string! 10000

then I go into a parse, where I build REBOL content within my output 
string. Sometimes I have to append a string (as a string) to output, 
and it fails, when I have newlines and { like characters.

Yes, I'm aware of that REBOL trick. :-) It's because, what I'm parsing 
might be blocks within blocks in a recursive way.

XML is an example of such a structure. If I see a start-tag, I insert 
the beginning of a block in my result, then parse further in the 
document finding content and other start-tags and so on. The best 
way is to produce the output in a seriel manner from beginning to 
end, like I parse the input.

That's a nice idea for a sort of "REBOL explainer" application.
But it would be difficult to do in the Library.

The Library does attempt to load and parse scripts -- that's how 
we do the colorisation. But (as with Gabriele's code) we rely on 
REBOL's own reflective abilities to tell us what is a word, function, 
operator etc.

The Library runs an old version of Core (and even if we update that, 
we'd never run a version of View on a webserver) so it does not have 
access to all the information a proper explainer.highlighter would 
need.
Take this script for example:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?color=yes&script=reboldiff.r

'new-line is a valid REBOL word, but it is not colored: that's because 
it is not a word in the version we use.

So sadly, the colorisation at REBOL.or remains a nice bit of eye 
candy rather than a solidly dependable feature.

There is big problem with rebol.org library if you are using different 
than ascii chars. I've just submited a script which contains latin2 
chars and it's not uploaded correctly as there were converted to 
utf8 (so the script will not be working correctly as the chars are 
used in parse.

Hmm... How to do that?
We need to know where a particular
Maybe:
1. Read script *and* Load script
2. Visit each item in the loaded block, recursively.
3. As each item is visited, check its type.

4. Depending somewhat on type, parse (in the READed script) to the 
molded item:
4.1  If it's a series, search for the "opener", eg. block! -> "["
4.2  If it's a non-series, search for it molded.
4.3

Mike

I checked your library example from the I'm new group producing errors.

There is probably a weakness, as the script does not regard comment 
lines.
A short enhancement would be
   
parse-ini-file: func [
    file-name [file!]
   /local ini-block
    current-section
    parsed-line
    section-name
][
 ini-block: copy []
    current-section: copy []
    foreach ini-line read/lines file-name [
		if #";" <> first ini-line [ ; do not process comment lines
			section-name: ini-line
			error? try [section-name: first load/all ini-line]
			either any [
				error? try [block? section-name]
				not block? section-name
			][
				parsed-line: parse/all ini-line "="
				append last current-section parsed-line/1
				append last current-section parsed-line/2
			][
				append ini-block current-section
				current-section: copy []
				append current-section form section-name
				append/only current-section copy []
			] ;; either
		]
    ] ;; for
 append ini-block current-section
 return to-hash ini-block
 ]

Thanks, sqlab......That works fine. (I should read the documentation 
in future before writing the script :)
I've updated the script in the Library:
   http://www.rebol.org/view-script.r?script=parse-ini.r

ctx: context bind [
	chars: charset [ #"A" - #"Z" #"a" - #"z" #"0" - #"9" #"-" #"_"]
	non-chars: complement chars

	set 'copy-word has [start end end-rule car-pos] [
		if any [not focal-face not caret] [exit]
		
		car-pos: index? caret
		end-rule: copy []
		
		parse/all head caret [
			any [
			 	start: some chars end: (

     if all [car-pos >= index? start car-pos <= index? end] [end-rule: 
     'break]
				) end-rule
				| some non-chars (start: end: none)
			]
		]

  if all [start end] [write clipboard:// probe copy/part start end]
	]
] in system/view 'focal-face

view layout [
	area "This is some text to test"

 text "To copy the word under the cursor : hit CTRL+K or press the 
 button bellow"
	button "Copy word" #"^K" [copy-word]
]

Thank you DideC this is what i was looking , i thought that parse 
will do the trick  I just did not know how. All i need to do now 
is see how fast this works with a 100KB text file.

I'm not a parse guru myself. May be there is a simpler solution.

donno but it does what i need  =)  and it looks "easy" hmmm I can 
see why someone can get addicted to rebol. I need to study more about 
bind and parse.

Parse is probably the best way.

page: read http://www.rebol.com

images: copy []

use [whsp ws non-end-tag strd p1 p2 delim non-delim][

	whsp: charset " ^-^/" ; whitespace
	ws: [any whsp] ; a rule for any number of whitespace characters
	non-end-tag: complement charset ">" ; all characters except ">"
	strd: charset {"'} ; string delimiters, double and single quote
	parse/all page [
		any [
			thru "<img" [
				ws "src" ws "=" ws 

    p1: [strd (delim: form p1/1) | (delim: ">")] (non-delim: complement 
    union whsp charset delim)

    p1: any non-delim p2: (append images copy/part p1 p2) ; keep the 
    url
				| non-end-tag
			] | skip
		]
	]

]


new-line/all images on ; add hidden newlines to the images block 
so it molds nicely
print mold images

I should mention some characteristics of the above parse rule.

Since it does not parse html, its detection of real img tags is simple 
and cannot determine the context in which the string  "<img" is found. 
 For instance, there might be written some code in a preformatted 
text section, eg:
	<pre>
		<img src="...">
	</pre>

Such a section should be left alone by the parser as it is not "inside" 
the html.
Unfortunately, making a full html parser is not so easy...
But you may find the above rule is sufficient for your needs.

page: read http://www.rebol.com
images: copy []

use [whsp ws non-end-tag strd p1 p2 delim non-delim][

	whsp: charset " ^-^/" ; whitespace
	ws: [any whsp] ; a rule for any number of whitespace characters
	non-end-tag: complement charset ">" ; all characters except ">"
	strd: charset {"'} ; string delimiters, double and single quote
	parse/all page [
		any [
			thru "<img" whsp [
				any [
					ws "src" ws "=" ws 

     p1: [strd (delim: form p1/1) | (delim: ">")] (non-delim: complement 
     union whsp charset delim)

     p1: any non-delim p2: (append images copy/part p1 p2) ; keep the 
     url
					| non-end-tag 
				]
			] | skip
		]
	]

]


new-line/all images on ; add hidden newlines to the images block 
so it molds nicely
print mold images

page: read http://www.rebol.com
; special test cases from Alek_K
;page: {<img src="one two.jpg">} ; OK
;page: {<img alt="picture" src=one.jpg />} ; OK
images: copy []


use [whsp ws non-end-tag strd wh- non-str-delim p1 p2 delim non-delim][

	whsp: charset " ^-^/" ; whitespace
	ws: [any whsp] ; a rule for any number of whitespace characters
	non-end-tag: complement charset ">" ; all characters except ">"
	strd: charset {"'} ; string delimiters, double and single quote


 wh-: charset "^-^/" ; whitespace minus the space character (space 
 is allowed inside a quoted string)
	non-str-delim: complement union whsp charset ">"	

	parse/all page [
		any [
			thru "<img" whsp [
				any [
					ws "src" ws "=" ws 

     ;p1: [strd (delim: form p1/1) | (delim: ">")] (non-delim: complement 
     union whsp charset delim)

     p1: [strd (non-delim: complement union wh- charset form p1/1) | (non-delim: 
     non-str-delim)]

     p1: any non-delim p2: (append images copy/part p1 p2) ; keep the 
     url
					| non-end-tag 
				]
			] | skip
		]
	]

]


new-line/all images on ; add hidden newlines to the images block 
so it molds nicely
print mold images

Now, the tricky thing with modifying parts of a string in a parse 
rule is that you have to leave the current parse index at the end 
of your new replacement string.

What usually happens is you parse up to your search string, set a 
marker (here it's done with p1:), parse through your search string, 
set another marker (p2:), then

 	(remove/part p1 p2
	insert p1 "my new string")


but if the the new string is shorter or longer than the old string, 
then the parse index will be left in the wrong position.

So to fix that we need to set p2 to p1 plus the length of the new 
string, then set the parse index to that position so it can continue 
as intended:

	(p2: p1 + length? new-string) :p2


So the full example above can modify links in place if you simply 
replace:

	(append images copy/part p1 p2)

with something like:

 	(
		old-string: copy/part p1 p2
		new-string: "create your new link from the old one here"
		remove/part p1 p2
		insert p1 new-string
		p2: p1 + length? new-string
	) :p2

parse string [integer!]

It is entirely possible to parse blocks into text markup, when you 
want to allow code to automatically generate its own document (that 
is a hierarchical source, source code)

(I was just perusing the source...the parse of enum2 and enum3 show 
">" and ">>"

hmm,  maybe I am already decided, thanks for any input, but it seems 
to me easier to directly compose valid mySQL syntax, than to think 
how to overcome rebol block conversion syntax, as I can't know what 
cases Doc's driver is able to parse ...

No, you must extend the parse-rule.

So what's needed:

1. We need a way to continually parse the SSHD log-file, something 
like tial

2. We extract the IP address and add it to some firewall, to block 
it for some time
3. We need to remove the IP from the firewall

Anyone interested in such a project?

I think parse would do a trully great job for this  kind of rebol 
software

with trace/net on:

>> read http://192.168.1.27/cgi-bin/test.cgi
URL Parse: none none 192.168.1.27 none cgi-bin/ test.cgi
Net-log: ["Opening" "tcp" "for" "HTTP"]
connecting to: 192.168.1.27
Net-log: {GET /cgi-bin/test.cgi HTTP/1.0
Accept: */*
Connection: close
User-Agent: REBOL View 1.2.46.3.1
Host: 192.168.1.27
}
Net-log: "HTTP/1.0 200 OK"

and there it sits until I escape it

I want to access a mysql db via a cgi interface directly with a rebol 
client.


I have a cgi script  that accesses the db and prints the results 
which I can read with the client but is this the best method? Is 
there a way to send the data directly to the client as rebol blocks 
or do I need to essestialy parse a cgi built web page as I am doing?

As text? Is the XML a DOM tree, parse-xml generated blocks, what?

http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=xml-parse.r

How to get started with xml? I know the simple things, kind of object-tree, 
similar to what parse-xml does. What extras would be needed?

Volker: user xml-parse+ instead of xml-parse ... you will receive 
block/object structure IIRC ...

dunno if much of an overhead, but maybe parse-xml could be used to 
parse even html?

SAX is like parse. [a-tag another-tag (do-something) /a-tag]. DOM 
works like load does. AFAIK.

so what is the difference basically in when you parse XML document 
using SAX and using DOM?

If its more like a block of records, it would be DOM. parse<->sax, 
load <-> DOM.

Thats what i understand from the overviews. Then comes how it works, 
and i am quickly back to real parse and load..

Yes, load is our tree, parse our events. Think of parse as "Here 
comes the word 'file. Yuppa, and a real 'file! . Good, and a 'binary!. 
(fine, now i store that data in that file)"

Chris - following is true imo which favors SAX with me:


Tree-based APIs are useful for a wide range of applications, but 
they normally put a great strain on system resources, especially 
if the document is large. Furthermore, many applications need to 
build their own strongly typed data structures rather than using 
a generic tree corresponding to an XML document. It is inefficient 
to build a tree of parse nodes, only to map it onto a new data structure 
and then discard the original.

Organizing data - if data is in blocks, you can use path-notation, 
but also runwith a parse-rule through the loaded data.

But for that parse-rule we need a fixed mapping, i think i start 
with functions first, until i know what i need. Easier to change.

>> do http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=xml-parse.r
>> parse-xml+ read http://www.ross-gill.com/
** Script Error: Invalid path value: parse-xml
** Where: parse-xml+
** Near: xml-parse/parser/parse-xml code

Chris -- that do from REBOL.org works for me.

parse-xml is an RT mezzanine. Perhaps its not present in your rebol.exe

>> parse-xml read http://www.ross-gill.com

== [document none [["html" ["xmlns" "http://www.w3.org/1999/xhtml"
"xml:lang" "en" "lang" "en"] ["^/" ["head" n
one [["title" none [...

>> source parse-xml+
parse-xml+: func [[{
    Parses XML code and returns a tree of blocks.
    This is a more XML 1.0 compliant parse than the built-in
    REBOL parse-xml function.
}
        code [string!] "XML code to parse"
    ]][
    xml-parse/parser/parse-xml code
]

Likely because in the code, it says -- parser: make object! [[  ... 
 parse-xml: ...]]

Similarly, the parse-xml+ arguments block is doubled too -- [[code 
[string!]]]

If I make those fixes, I get 'false' when I parse my homepage (which 
validates as xhtml)

Chris -- I don't get that problem,

But you did make me look closer, and my earlier statement was wrong.
I'm using

http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=xml-object.r
Which is similar to xml-parse, but not identical.
Example of usage:
probe: first reduce xml-to-object parse-xml
     {<?xml version="1.0" encoding="ISO-8859-1"?>
      <xxx>11</xxx>
     }

Chris - somehow I don't understand, what you are talking about here? 
You have to always to parse first, no?

Gavain' s code consists of two or so sections - first you parse into 
block representation, then you convert to object representation ...

Petr, it's best to know what format you're parsing to before you 
actually attempt to parse.  I'm making the assumption that the results 
of parse-xml, parse-xml+ and xml-to-object are unsuitable for manipulation.

oh, now I understand what did you mean. I thought you are trying 
to somehow "parse XML without actually parsing it", my bad :-)

This is a convoluted as I'm faking the end document object (which 
would be created by a parse rule):

The imported characters would be fine (their integrity can be checked 
by the parse rule) but local Rebol higher characters would need to 
be vetted before inserting them...

Carl has talked several times about a binary format for saving REBOL 
structures (can't find any references off-hand).

That would probably solve this problem as what is saved is, in effect. 
the internal in-memory format: useless for non-REBOL data exchange 
and perhaps dangerous for cross-REBOL releases data exchange, but 
much much faster as it'd avoid most of the parse and load that REBOL 
does now.

Doing my first steps with REBOL I tried to do something with XML

(reading/eventually modifing/writing). I looked for some scripts 
helping
me to do this and found:

1. xml2rebxml/rebxml2xml:
    I got the following problems:
    - missing/loosing comments
    - missing/loosing elements - that's realy serious
    my steps were:
      my-doc: xml2rebxml read %simple.xml
      write %simple2.xml rebxml2xml my-doc


    The second documents finishes outputting elements after some comment
    block in
     the source xml doc.

 2. xml-parse/xml-object:

     The versions I found on the reb library didn't work, I used some

     older versions from rebXR-1.3.0, I've got my objects, but it would 
     be

     nice to have a third module like xml-write to get the object tree
     back to xml. Is somebody developing something like this?

 3. mt.r:

     I tried to figure out how it works. Basically I can write some XML

     based on a REBOL block but I couldn't figure out how to define the

     rules about elements and attributes. Where can I find an example

     about writing for instance svg with mt.r, how looks the coresponding
     REBOL block and the rules for svg?


Where can I find more about xml and REBOL, I think it would be very 
nice
to have some REBOL scripts, doing things like 
   some-elem: xml-create [ elem "foo" namespace "myns" attribs [
                                     bar "something"
                                     xyz "123"]
                                     ]
   xml-modify [ elem another-elem append some-elem ]
and finally
   xml-write %mynewxml.xml my-doc


Is somebody developing something like this with REBOL? Some scripts 
giving

me the same comfort in REBOL like maybe XOM (http://www.xom.nu) is 
giving
for XML in Java. Of course done with some nice REBOL dialects?

What is the above mentioned "EasyXML" - is it available for use/testing?

Thank you for any tips, carsten

By "handle", I mean parse them, but comments ain't in the output. 
The script shouldn't stop for valid XML input.

carsten: I should have kept my mouth shut about XOM and asked you 
before :-)

the port-idea was just that a thought - in any case if one wants 
to use a dialect there has to be an entity to interpret the dialect, 
whether that's an function or something else doesn't matter, but 
a port seams to be a common rebol entity to encapsulate things - 
that's why I thought it would maybe even make sense to use a port 
as abstraction .... opening a port to an xml file and the port will 
parse it in whatever way - by sending (inserting) a dialected block 
into the port the xml document could be worked on - at least from 
the users point of view one wouldn't have to handle the xml-code-block/rebol 
code block separetely - even though it might be nice to access it 
directly .... well maybe I have too little glue about ports so the 
idea might not make too much sense when I forgot about some important 
drawbacks and the like

It would be triviel to parse a RebXML block and add the node names 
(elem, attribs and comment), if that format is desired, but RebXML 
itself should be with as little overhead as possible.

Did you have a look at the source of 'parse-xml ? Is this what is 
meant to be event-driven ?

No, parse-xml generates a (broken, incomplete) DOM tree. Gavin McKenzie's 
xml-parse is more like a SAX parser.

I've also had a look inside xml-parse, it seems to be really like 
SAX - ready to use. But nobody is maintaining it, I think. As far 
as I understand, somebody could create a Handler to get the desired 
block structure (for instance a Handler for RebXML or any other model). 
I have to learn about this in REBOL.


A question: how can I measure memory for a block or an object tree 
in REBOL?

in the moment i play a little bit with xml-parse.r, it has a lot 
of things done, some are still open (like  <!ENTITY ...> parsing) 
and it is like SAX - I try to implement some handlers to learn REBOL, 
but it's still in progess. A benefit of xml-parse is, that there 
would be only one parser and some kind of standard API and the handler 
could then generate rebxml or some other desired format

does it work SAX way or DOM way? I mean - load first, then parse, 
or parse while reading way?

( I know nothing really of XML .. just know I have to parse some 
data, and rewrite out my data as xml )

dialect rewriting is basically what my rewriting engine for rebcode 
does; it's rewriting where instead of using a regexp you use a parse 
rule; and instead of compiling a tree to another tree you compile 
a dialect to another dialect.

brian: do you think that structural pattern matching could be done 
with parse rules too? or, do you think we need something like "longest 
match" (which can be implemented in parse but is tedious to do manually)

You can do some structural pattern matching with parse rules, but 
with how parse is currently implemented it can be a little awkward. 
The lack of arguments to parse rules make recursion quite difficult, 
and the lack of local variables make the rules difficult to use concurrently. 
It is difficult to examine both the data type and the value of elements 
in block parsing, to switch to string parsing mode for string elements, 
to parse lists, hashes or parens, to direct the parse flow based 
on semantic criteria (which is needed to work around any of these 
other problems).


And don't even get me started on the difficulties of structure rebuilding. 
The thing that is the most difficult to do in parse is the easiest 
thing to do with regexes: Search and replace. Didn't we make a web 
site years ago collecting suggestions for improving parse? Wasn't 
a replace operation one of those suggestions? What happened with 
that?


Structural pattern matching and rebuilding currently has to be done 
with a mix of parse and REBOL code that is tricky to write and debug. 
If parse doesn't get improved, I'd rather use a nice declarative 
dialect, preferably with before and after structures, and have the 
dialect processor generate the parse and REBOL code for me. If that 
dialect is powerful enough to be written in itself then we'll really 
be cooking.

Brian, did you post a rambo on parse after a discussion we have a 
while ago ?

my rewrite function works quite well for search and replace. it still 
has the limitations of parse, though, but they don't seem a huge 
problem so far.

do you have common examples that you consider problematic for parse? 
we can probably use rewrite on the parse rules themselves to extend 
them in a similar way that compile-rules does.

Has anybody done work on translating XML schemas (perhaps automagically) 
to REBOL parse rules that can work on REbelXML/RebXML like native 
syntax?

I did not do it using parse for lack of knowledge ... and also the 
fact that schema and PARSE do not have the same traversal mechanisms... 
but its still very fast and error report is extremely precise (it 
gives you the full path of the error!)

obj-xml: make object! xml-to-object parse-xml+ read %my.xml

Peter - what tools are you referring to? What is xml-to-object and 
parse-xml+?

>> do %xml-parse.r

Script: "A more XML 1.0 compliant set of XML parsing tools." (2-Mar-2005)
** Script Error: Invalid argument:
    Parses XML code and returns a tree of blocks.
    This is a more XML 1.0 compliant parse than the...
** Where: throw-on-error
** Near: func [[{
    Parses XML code and returns a tree of blocks.
    This is a more XML 1.0 compliant parse than the built-in
...
>>

well, just use parse-xml ....

This is a quickie -- designed to make 'parse-xml output more parseable:

http://www.ross-gill.com/r/qxml.r

Any thoughts, comments?

I thought about the # convention.  # can be used in parse literally. 
 It may have no semantic meaning, but is a very concise anchor.

response: context [
	status: name: value: none
]

example: {<rsp>
	<status>Good</status>
	<payload>
		<value name="one">two</value>
	</payload>
</rsp>}

probe make response [
	parse load-xml example [
		<rsp> into [
			<status> set status ["Good" | "Bad"]
			<payload> into [
				<value> into [
					/name set name string! # set value string!
				]
			]
		]
	]
]

; You can still parse the tree too:
parse doc/tree [<some> into [<xml> "to try"]]

I've never posted that specific version cause it was closed source 
for a client.   but I have my own new engine, which does the same, 
but attacking the parse rules directly... its probably faster.
I've not released it.

my newer version doesn't have the schema validation process.... that 
is a very complex engine to build.   schemas and Parse traversal 
do not follow the same algorythm... so its a bitch to implement.

Anton:
** Script Error: cv has no value
** Where: do-parse
** Near: cv mold type-converter/c-to-rebol-map

I want to kick of some sort of simi-regular Rebol School for new 
comers.


We need to expose more people to Rebol, the best way is a 2 hour 
school online.


I'm thinking like the old days where we all jump online, but I want 
Video too!


My idea is that we would focus on a given topic, like: parse, data 
driven programming, view, etc.


Someone would be picked as the lead speaker, and someone else might 
be in charge of moderating the Chat.



People could ask for examples, and would write them up on the spot. 
 Hopefully many Rebol Experts would be on hand to throw some samples 
up.


I have about 5 newbies that really want lessons.  I know that another 
5-7 of my team would be present to help, to learn, to be friendly.

Any one else interested?
Anyone know the best way (what software) to do this?

denismx, when I've taught REBOL to people, even people who are already 
familiar with other programming languages, it has been helpful to 
make the distinction between the REBOL language and the dialect engines.


REBOL is really a data model and related syntax, and a bundle of 
library functions that manipulate data in this model. A dialect is 
really a semantic model for interpreting this data, like what people 
think of as a language in real life. A dialect engine is a set of 
library functions that think of the data in the same way - I know 
this sounds anthropomorphic, but it makes it easier to explain REBOL 
if you think of the different dialect engines as entities that are 
acting on a set of commands you are giving them. You can even use 
role playing to demonstrate this, having one of your students act 
out the part. It also helps to name each of these models after the 
main function that implements them - otherwise people might not get 
the distinction between them and REBOL as a whole.


There are some functions that only deal with the REBOL data model 
and don't really do anything with the data other than translate it 
from or to some concrete syntax. It is best to group these functions 
by the syntax they implement - the group that implements what people 
normally think of as the REBOL syntax is LOAD, SAVE and MOLD.


When teaching REBOL dialects I usually start with what I call the 
DO engine, what people normally think of as the REBOL language. DO 
is a stack machine like Forth, but it uses a prefix syntax to make 
it easier to use (by making DO dialect code more resemble that in 
other programming languages). DO also does a simple swapping hack 
to implement inline operators, which you will have to demonstrate 
so that your students will understand DO's operator precedence or 
lack thereof. DO always works on REBOL data: If you pass it a string 
or file that contains REBOL syntax code, DO will call LOAD to convert 
it to REBOL data - this is an important distinction to make so that 
your students can distinguish between the data and the processor 
of that data. There are many functions that depend on DO to interpret 
their blocks of "code", such as IF, WHILE, FOR, etc. It is important 
to note that these are just functions, not "syntax". DO's only syntax 
is the predefined operators that DO swaps (these are effectively 
keywords because of how the swap is implemented), the word/set-word/get-word 
difference, the interpretation of paths and the precedence of parens. 
Everything else is a function.


There is also the PARSE engine, a rule-based recursive-decent parser 
with limited backtracking, that implements three dialects (simple 
parse, string parse and block parse). These dialects actually have 
keywords, as well as an entirely different execution model. Also, 
there is the View engine, which implements the LAYOUT and DRAW dialects.


Refering to these engines as state machines isn't helpful, because 
the distinctions between their execution models, or whether they 
even have execution models, is important for distinguishing between 
them. You need to use the higher-level terms like stack machine, 
composition engine and such.

I hope this helps!

When you load, the file has to be LOADable by rebol, which means 
everything in it must be parseable into rebol values.

When you read, the file can be absolutely anything. I usually have 
to read web pages and parse a string, for instance.

to extract substrings without use of 'PARSE you can do:
substring: copy/part find sentence "debut" find sentence "fin"

Interesting: just downloaded this free ActionScript compiler http://www.mtasc.org/
and will try if it would be possible to integrate it with the rswf 
(so I could use *.as file for actions without need to parse it in 
Rebol)

>> rswf/parse-ActionRecord compile-actions [a: 1 + 2 + b]
     aPush ["a" 1 2]
     aAdd2 #{47}
     aPush ["b"]
     aGetVariable #{1C}
     aAdd2 #{47}
     aSetVariable #{1D}

In between working with Gabreile on parse extensions, of course.

do-browser in Mozilla: haven't looked at it yet. it would require 
access to both the Javascript interpreter as well as an "evaluate" 
(or execScript) method that would parse and interpret the script.

Pekr: actually, I'm sure there is, that's why you are asking. Can 
you explain the problem in a little more detail? You need that auto-config 
script interpreted? Maybe it would be easier to configure REBOL to 
rad the auto-configure script than to try to get IE to parse it and 
get the details via an API. Thoughts?

is is parse base, each rule consist of a match block!, a transform 
block! and a logic! to continue thru next rule or break

you have one hour to build the most impressive:
-parser (using parse)
-view app
-core app