AltME groups: search

the parse doc is becoming scary precise :-) I hope Carl is not scared 
by the amount of requests :-) Can't wait to do similar job to low 
level View. Maybe we could start :-)

If I'm getting this right, OF is designed to do this:

	blk: [1 two 3.0]
	parse blk [of [integer! word! decimal!]]
	== true
	parse blk [of [number! word!]]
	== false (only accounts for one number)
	parse blk [of [word! decimal! string! issue! integer!]
	== true (can be none if a given type is missing)


I have another scenario to which the word 'of would apply.  There 
are situations where I want to match one item from a block of options. 
 Currently, those options need to be pipe-separated, requiring preprocessing 
if those options come from a data source (see languages: in my emit-rss 
script for an example).   This appears in both string and block parsing. 
 An example (using IN as the hypothetical operator):

	m28: ["Feb"]
	m30: join m28 ["Apr" "Jun" "Sep" "Nov"]
	m31: join m30 ["Jan" "Mar" "May" "Jul" "Aug" "Oct" "Dec"]
	b28: repeat x 28 [append [] 29 - x]
	b30: repeat x 30 [append [] 31 - x]
	b31: repeat x 31 [append [] 32 - x]
	parse date-str [
		in b28 "-" in m28
		| in b30 "-" in m30
		| in b31 "-" in m31
	]

This would be true for "1-Jan" "30-Sep" and false for "31-Feb".

'append would do it...

numbers don't work in string parsing

 - I thought about this when I developed the example, thought it might 
 be possible as the numbers appear outside the dialect.  But 'check 
 seems like the better option.  

joins were in the wrong direction
 - d'oh!

simpler date checker

 - that's only useful if to-date recognizes the date format : )  (and 
 using dates was illustrative - there are other situations with similar 
 needs).  Though on dates, what would be the most succinct way with 
 the proposals on the table to do the following?

	ameridate: "2/15/2008"
	parse ameridate ...rule...
	newdate = 15-Feb-2008

One attempt:

	parse ameridate [
		use [d m][
			change [copy m 1 2 digit "/" copy d 1 2 digit]
			(rejoin [d "/" m])
		]
		"/" 4 digit end check (newdate: to-date ameridate)
	]

but that's not parse related, the Rebol lexer should be improved 
to do that.

I think it has something to do with INTO not return true.

...or better, do you know where I can find a simple algebra parse 
script, which can compute simple expression like [1 + (2 /3)] ?
I'm learning how to parse, and such example would be illuminant

Okay Oldes, your solution works, but why does my code fail, any ideas? 
 I have other scenarios that follow this same sort of structure but 
do not have a simple two word expected result.  I've been able to 
handle these so far, simply by changing the order and moving the 
'stop' word of the Ampersand to the bottom of the rule options.  
[I'm trying Chris's option now]

paul asked: "Question for you regarding parse.  How do you force 
parse to return false immediately without processing the rest of 
the string or block one it evaluates a paren?"

now the question, paul, is do you want the WHOLE parse to fail, or 
just that rule?  up to the paren?

or do you want to do, basically, look ahead assertion?

What I'm talking about is this:

words: [this that blah]


result: parse [this that bleh blah][some [set w word! (unless find 
words w [do something to return false here)]]

The CHECK workaround is the easiest way to do reserved words that 
can change at runtime.

the new stuff allows what I want to do, but still makes it non-trivial... 
a bit like the first example.


a lot is done in so few lines... but its not obvious to analyse... 

my idea was for a system called 'PERSIST

If Carl sticks to his word in his intial request all the proposals 
will be rejected:


Each improvement will require test code be provided that would certify 
its correctness. No test code, no improvement. (Sorry... you often 
ask me what you can do to help. Please don't put the burden of testing 
such changes on me.)

What do you want to accomplish?

basically it seems to me right now, PARSE is mega powerfull for anything 
that comes in somewhat PREDEFINED order, like dialects and many other 
things (I could do mulitple html extraction programs with it for 
some search project I was making without hitting this limitation 
- it was predefined order too).. but it seems to get limited at things 
that repeat/exchange themselves at random etc--

I really like REBOL when I'm able to do things like:
c1: context [
	n: 1

 lexer: [copy x 1 skip (prin reform ["in context:" n "=> "] probe 
 x if x = "." [root-lexer: c2/lexer]) | end skip]
]
c2: context [
	n: 2
	d: charset "0123456789"

 lexer: [copy x some d (prin reform ["in context:" n"=> "] probe x 
 root-lexer: c1/lexer) | end skip] 
]
root-lexer: c1/lexer
parse "abcd.123efgh" [ some [() root-lexer]]

I intended to make a blogpost .. "REBOL parse challenge" and present 
this problem and ask if people can provide solutions in other languages 
that would be more elgant ... (in similar note as the "arc challenge" 
... now that it seems even more hard nut to crack I should probably 
really do it .. does anyone think this would be easy to solve using 
the conventional language? (I think not)

regex I imagine sucks at structured stuff , where you have to make 
some sort of state machine , for example I don't think regex can 
well parse xml ... state machines are exelent at that but they do 
require more code than parse would

I don't know the exact term for this but I build many parsers for 
things like xml, wiki text and some other custom things in various 
lower level langauges using simple state machine (at least that's 
how I called it)... To my understanding you can parse anything with 
something like that, also structured nested data with it but it of 
course takes some more coding than this rebol solution... what I 
mean as a state machine is a loop that accepts characters or words 
and has a predefined number of states and code for what to do at 
each state and when to switch to another state etc..

aha.. I think / hope I found an example of my problem ( I already 
settled that I have to do thins like this in multiple passes )

hm.. really thanks for this example.. I took it as unsolvable, but 
this is totaly elegant way to solve it .. I will need to think on 
this a little and do some more examples to difest it :) thanks

If you need to parse complex structures, like the marup language, 
you should use charsets and not 'to or 'thru commands... for example 
you cannot say that tag starts with < and ends with > because such 
a tag is valid as well:
<input value="<>">

The 'to and 'thru commands are useful, if you, for example, do datamining 
and don't care to parse all page structure to get just a bit of information 
from it.

Hi, I have one question .. can you somehow break out of some loop 
by rebol code .. for example


parse [ aa zzz cc ]  [ some [ set W word! ( ?? W if equal? W 'zzz 
[ break ] ) ] ]  ...  that break doesn't work that way, but is there 
some way to do this? I need to compare W with a runtime value

; Here's one way to do it...

>> digit: charset "1234567890"
== make bitset! #{
000000000000FF03000000000000000000000000000000000000000000000000
}

>> rule: [s: some digit e: (print copy/part s e) | h: #"a" (h: tail 
h) :h | skip ]

== [s: some digit e: (print copy/part s e) | h: #"a" (h: tail h) 
:h | skip]
>> parse "12b34c56a78" [any rule]
12
34
56
== true

Using your code to do the same thing...

match func [ data rules ] [
	parse rules [ 
		SOME 

  [ 	set L lit-word! blk: ( either equal? L reduce first data [ data: 
  next data ] [ blk: tail blk ] ) :blk | 
			set W word! ( set :W first data  data: next data ) 
		] 
	]
]

I guess I can do it without using parse .. just replace all the headers 
with a mark, that allows me to split off all the sections, and then 
i can match the sections with all the section headers.

In fact i could extend my solution easly to prevent those errors 
and throwing safe errors it the parsing failed.
I takes 5 minutes to do.

But adding such exceptions or other sub-rules is so easy that i don't 
see the interest to prevent those cases.

It's my philosophy when i write parsing rules.

They are so easy to extend, there is no reason to anticape thoses 
cases by guessing what is in the in the mind of the  final user.
Whe have to extend the grammar ? 
Ok, give me 5 minutes.

I'm not a magician, i can't figure all the cases if the given specifications 
are incompletes.

Everybody has a job to do, it's not mine to work on wrong specifications.

My...

The problen in the method i proposed has nothing to do with the line 
by line approach.

Can't you figure that ? It's only because i try do recognise headers 
whitout knowing them.


I can rewrite your solution without using your line by line approach 
in 5 minutes (you didn't do yours in 30 secs btw).
It will be smaller and faster than yours.
But i don't see the interest, i thougth anyone could figure that.

on the other hand, I do see that parsing in the rebol scene seems 
to be the cause for bragging rights.  its a complex system reserved 
for a select few who have spent time and effort learning how to come 
to grips with it.


looking at working rules, makes it seem simple, but the deeper knowledge 
of how it works ... really isn't.

for proper CSV parsing, we'll need some good functions for R3/Plus 
instead of trying to do some crappy stuff with PARSE directly.

What info do you need, the path or what comes after it? If the data 
after it is only a limited set of possible answers, you can try to 
skip to those in turn.

parse/all/case line [[to "WALMARK" | to "BUILTIN"] a: (do something)]

but - I could also not do it all with one ICACLS call, but instead 
to REBOL level recursion and using separate CALL to ICACLS for each 
dir separately ...

I got it working. I use the following trick - I identify DOMAIN\USER:(RIGHT) 
or (RIGHT) sections first. Then I put weirdly markers around and 
catch the rest with the skip. The file is "clean", so actually what 
do I skip is either spaces, or path. I do check in emit function:

emit: does [
 if find tmp: trim copy/part p-start p-end ":\" [path: tmp]
 print [path domain user rights]
]

;--- rules - spaces, tabs, newlines

spacer-chars: charset [#" " #"^-" #"^/"]
spacers: [some spacer-chars]

;--- user-rights rules
;--- would be easier, if filesystem would not allow () ...

right-char: charset [#"A" - #"Z"]
right-rule: ["(" 1 2 right-char ")" ]

rights-rule: [r-start: some right-rule r-end: (rights: copy/part 
r-start r-end)]

;--- rule to identify user part

user-chars: complement charset {".,;:\/*}
user-rule: [copy user some user-chars ":" ]


;--- rule to identify domain - I expect it being typed in CAPITAL, 
can contain "-"
;--- the exception is "NT AUTHORITY" - contains space

domain-chars: charset [#"A" - #"Z" "-"]
domain-rule: [
    "NT AUTHORITY\" (domain: "NT AUTHORITY")
    |
     copy domain some domain-chars "\"  
]


;--- rules for combinations of: rights only (RIGHT), or DOMAIN\USER:(RIGT)
domain-user-rights: [
     rights-rule 
    |
     domain-rule
     user-rule
     rights-rule
]


parse/all str: read from-file [p-start: any [ p-end: domain-user-rights 
(emit) p-start: | skip ] to end]

What's the most economical way to do this.  I have a line of text, 
and I want to classify each line.  So, if I find the word "tablet" 
in it, I class this as a U2, and if I find "capsule", it's AV.

I can do a sequence of finds inside a case statement, or I can use 
a parse.  But in the first instance I have multiple find statements, 
but in the latter I have mutliple assignments in my code.

the lines are so few in number that it won't make any practical difference 
... just wondering if there were a preference on how to do this without 
code duplication.

I decided that since the way I was going to use parse, or case meant 
the code was mixed in with the data .. it was better to do it differently.

thru consumes the end word, and then detects that, as a result, it 
would put you beyond the end.  
really, its quite logical.  


but in practically, thru shouldn't complain.... cause as you say, 
in this specific context, thru and to really do mean the same end.

at least that's my opinion ... I always delayed this kind of project 
I was expecting someone to do it 
But time passed and no complete documentation emerged.

yeah i'm ready it ..

that's complete but it's missing a human dimension to that documentation 
i mean i read it and i'm still not able to do what i want to do ....

The above problem reduces to:

	spacer: charset " "
	parse/all " " [to spacer]
	
	** Script Error: Invalid argument: make bitset! #{
	0000000001000000000000000000000000000000000000000000000000000000
	}
	** Near: parse/all " " [to spacer]

The reason is Rebol2 parse does not allow "to subrule".
(Pointed out by sqlab, thanks.)
	
Here's a way to do it using COMPLEMENT (suggested by Graham):
	
	spacer: charset " ^-^/"  ; Space, tab, newline.

 non-spacer: complement spacer ; All chars except the three above.
	whatever: [some non-spacer]
	spaces: [some spacer]
	rule: ["a" spaces copy varb whatever spaces "c"]
	parse/all "a b c" rule ;== true

You can just set your block that you want to parse to a word.  Such 
as:

blk: [ "cmd" {if error? try [1 + "x"] [print "Did not work."]}
rsp
   {Did not work.} 
cmd
  {if error? try [load "$10,20,30"] [print "No good"]}
rsp
  {No good}]

; and then do this:

>> parse blk [some [set s string! (print s)]]

I have this code which does this:

cmd-txt: "unasg"  cmd-term: "<"

pre-txt: "unasg"  pre-bgn:  "<pre>"               pre-end: "</pre>"

rsp-txt: "unasg"  rsp-bgn:  {<span class="eval">} rsp-end: {</span>}
site-url:	http://rebol.com/r3/docs/functions/try.html

page-txt: to-string read site-url
probe parse page-txt [thru pre-bgn copy pre-txt to pre-end]
probe parse pre-txt  [copy cmd-txt to cmd-term]
probe parse pre-txt  [thru rsp-bgn copy rsp-txt to rsp-end]

print [{"cmd"} "{" cmd-txt "}"]
print [{"rsp"} "{" rsp-txt "}"]

will yield this:
cmd

 { if error? try [1 + "x"] [print "Did not work."]          <-- this 
 is close to what I want to do
}
rsp
 { Did not work. }


This is close to what I want, but it is not foolproof.  For example, 
I would like to capture all displayable text that is separated from 
any html tags.  In my code example, if a displayable greater than 
symbol  < was displayed, then the parse would stop prematurely.


I am guessing someone has already created some code to "pull apart" 
a html web page, separating displayable text from invisible markup 
code.

A little, but the main drawback i have with parsing in editor is 
that parse doesn't handle incremental parsing.

Because i do parsing line by line to be able to parse only modified 
lines.

So that, i have to rewrite all the rules (describing the document) 
in an obfuscated way to deal with incremental parsing.

About STAY, i don't see the interest to continue even if the following 
rule is not matched . Can someone give an use case ?

because when i  do this:

>> parse [1] [stay skip ?? to end]
to: [1]
== true

or

>> parse [ ] [stay skip ?? to end]
to: [ ]
== true

it's like doing:
>> parse [ ...] [?? to end]

STAY have no purpose to my mind...

It's not a bug, it's behaving like Carl wanted. 
The final question is:  To do what ?

STAY is only useful for rules with effect: modifiers, and rules containing 
productions. Sometimes you need to do stuff where necessary and not 
care whether they were necessary later.

since we can easily do [11 skip]  to simulate an index.

you do not know shorthand for NOT? It may be as follows:

    a: [not b]

is equivalent to

  a: [b then fail | none]

All of the new additions are superfluous, Ladislav. They were added 
to make our lives easier, not to enable stuff we couldn't do before.

well, but I do not know if Carl intends to implement the full TO/THRU, 
as I said...

what do I mean? the "full"

    a: [thru b]

can be defined as a "shorcut" for

    a: [b | skip a]


you can try, that this works for any rule B as far as you don't need 
to use too deep a recursion. As opposed to that, the THRU keyword 
does not accept any rule B, as documented in Carl''s blog

but the A: [b | skip A] is weird, i never do that to avoid the stack 
limit error.
this instead:
a: [
    any [
       b break
       | skip
    ]
]

Brian, if a special command allow to return the stack [a list of 
positionned blocks], it's not really difficult to perform the continuation, 
i don't need for a special mode to do that.

It took reversing the if then condition to do it.

Pekr: the original rule was a little bit more complicated: paren: 
[any [#"(" paren #")"]], but still much simpler, than the above hell. 
Which is nothing compared to a trial to do the same in the case of:

bracket: [any [#"(" bracket #")" | #"[" bracket #"]"]]

The fact is, that this has nothing to do with tail recursivity: neither 
of PAREN or BRACKET is tail-recursive. The only problem is, that 
the stack depth does not look sufficient to use recursive rules for 
moderately complicated cases.

change must replace the complete matched rule, it has nothing to 
do with the quality (length) of the replacement data.
I'm sure it's a bug

We are in PARSE here, it has nothing to do with the behavior of CHANGE 
in normal rebol code

why do you repeat it? I try to point out, that it might share internal 
representation, and that might be buggy?

Actually, Steeve, the behavior of parse's change does have to do 
with the behavior of change in normal code. That would be an error 
if the CHANGE/part function had that same behavior. It's a bug.

I just rewrote the math expressions resolver.

digit: charset "0123456789"
num: [some digit opt [#"." any digit]] 
term: [num | #"(" any lv1 term #")" | #"-" any lv3 term]
calc: [
	remove [copy num1 term copy op skip copy num2 term]
	(expr: do reform select [
		"+"  [num1 op num2]
		"-"  [num1 op num2]
		"*"  [num1 op num2]
		"/"  [num1 op num2]
		"^^" [num1 "**" num2]
		"%"  [num1 "//" num2]
		
	] op)
	stay insert expr (probe e)
]
lv4: [term #"%" term then fail | break | calc]
lv3: [any lv4 term #"^^" any lv4 term then fail | break | calc]

lv2: [any lv3 term [#"*" | #"/"] any lv3 term then fail | break | 
calc]

lv1: [any lv2 term [#"+" | #"-"] any lv2 term then fail | break | 
calc]

I just think it's more clear like that.
Moreover, it's prepared to use the further AND command.

Because this nasty trick i use:
[rule THEN FAIL | BREAK | calc]
will be replaced by:
[AND rule calc]

the advantage would be to avoid skipping newlines. now that I think 
of it, you don't want it if you want to parse across a newline, but 
you wouldn't do that for CSV parsing.

Guys, i think your opinion about NOT is a little harsh.

In the case of complementing  a charset, you just have to SKIP after 
the NOT rule.
In the other cases, not advancing is of better use. 

At least that's what I see while rewriting some scripts as I do now.

We don't need BREAK/return anymore, but he can reuse the code he 
used to implement the RETURN paren operation. I hope we get DO, but 
Carl was iffy since few were puushing for it. Gabriele's been silent, 
which is weird since it was his idea.

Um, yeah, but he should about OF (as ALL). What he wanted to do with 
OF was important.

All PARSE needs is a few final decisions. I expect that it won't 
be too difficult to do the rest, at least the rest that won't be 
put off.

The DO operation was proposed 5 years ago, before R3's change in 
the behavior of DO/next. The new DO/next is much better suited to 
the parse workarounds than the old DO/next was. We can thus do without 
the DO operation if need be.

The DO keyword was added to A91 - Gabriele should be happy now :-) 
http://www.rebol.net/r3blogs/0276.html

I really want to do it... but I'm so deep into parsing right now 
I don't want to loose the few GB of information in my brain's cache. 
 I'm writing self-modifying parse rules and its pretty nightmarish. 
 although it works.

Do we have a list of PARSE changes that are no longer compatible 
with R2? I think that would be important in porting parse scripts 
from R2 to R3.

Both w1 and w+ appear to be very large values.  Would it be smart 
to perhaps do:

	[[aw1 | w1] any [aw+ | w+]]

Where 'aw1 and 'aw+ are limited to ascii values?

I guess parse can do this too?

   http://stackoverflow.com/questions/1621906/is-there-a-way-to-split-a-string-by-every-nth-seperator-in-python

Chris, there can be an advantage in R3 to breaking up a bitset into 
more that one bitset on occasion, mostly memory savings. However, 
it might not work as well as you might like since offset and/or sparse 
bitsets aren't supported. Bitsets that involve high codepoints will 
take a lot of RAM no matter what you do.

Will, R2/Forward is already available for download in DevBase (R3 
chat). It is a little outdated though, since I had to take a break 
to rewrite R3's module system. I'll catch up when I get the chance. 
The percentage of R3 that I can emulate has gone down drastically 
since the last update, since R3 has made a lot of changes to basic 
datatype behavior since then. We'll see what we can do.

The second one failed when I tried to extend the dialect with multiply 
(*) and divide (/). After further experimentation, it seems that 
you can't escape the "/". Google has not been helpful here... Does 
anybody have any ideas? I could parse for just a word! instead of 
the +, -, etc., but I wanted parse to do the work of deciding what 
was a valid operation or not. Sorry for the multiple messages, I'm 
still trying to figure this client out... Thanks for any advice!

JoshF: Rebol load does not parse the '/, but you can do:

as-lit-word: func ['word [any-word!]] [to lit-word! word]
lit-div: as-lit-word /

parse [3 - 2] [some [integer! (print "number") | ['+ | '- | '* | 
lit-div] (print "op")]]

...except for the fact, that lit-words are used in the Do dialect 
(= when Rebol is concerned, as you say), when you want to write an 
expression, which evaluates to a specific word, so, e.g. the expression:

'a

evaluates to the same value as the expression:

first [a]

, which happens to be the word A

yes , then you have to do charset parsing (but I don't know that 
yet :) ) .. I was just trying to say if there would be the way to 
say something like "to any [ "A" | "B" ] and it would go to the closest 
one A LOT of problems with parse would be easily solvable

Janko, best thing to do is show us a  string you can't parse ... 
and someone will show you how to do it.

It's not necessarily a PARSE limitation, but there are things we'd 
like PARSE to do that aren't always reasonable. :-)


TO and THRU can work very well, but that doesn't mean they'll work 
for every situation. You may have to use rules where you check for 
your target value or just SKIP, marking locations in the input as 
you go.

I know parsing csv can be messy ... at least at this high level I 
don't know how to do it with escapes and commas in etc

Janko: the only problem is, that you cannot use:

C: [to [A | B]]

, where A and B are "general rules", but you can always write:

C: [here: [A | B] :here | skip C]

, which would do what you want

Just to complete the list of possible equivalents to the

    C: [to [A | B]]

rule, here is a way how to do it in Rebol3 parse:

    C: [while [and [A | B] break | skip | reject]]


you can find other equivalent idioms at http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse#Parse_idioms

I didn't know you could set the position back with :here

 - you can set the position back even without :here, the choice operator 
 is sufficient for you to be able to do that, see the above idioms 
 as an example

unfortunately what you say isn't feasible, even if you can technically 
do it.  who is going to program a parser to colorise code which is 
usefull for only one application? its actually going to take more 
time to write your  color parser for each piece of code than write 
the code itself  :-P


so bottom line, Graham doesn't like this syntax. any others care 
to comment?

BNF is just a syntax form, with a *lot* of variation. The real difference 
that matters between Yacc and PARSE is the parsing model. Yacc implements 
an LR parser (or some variant thereof), and PARSE implements a variant 
of TDPL parsing (related to PEG), though more powerful and with a 
completely different syntax. How you structure the parse rules depends 
on the parsing model, not the syntax.


For instance, LR parsers tend to do recursion rather than iteration, 
and when they recurse the recrsive call tends to be on the left, 
with the distinguishing clause on the right. For PEG parsers, recursion 
goes the other way. This is not an error, this is a difference in 
parsing model.


If you are translating from Yacc to PARSE, it's not just a syntax 
change. You have to reorganize the rules to match the new model. 
And watch out: Certain patterns are easier to express in some parsing 
models than in others. Some patterns aren't supported at all in some 
models, and so no amount of translation will help you. We chose the 
TDPL model for PARSE because it is more expressive than the LR model, 
so in theory you should be able to translate LR rules to PARSE with 
some topological twists (redoing the sturcture of the rules). However, 
there are patterns that you can express in PARSE that can't be translated 
to LR, even with topological changes.

And it stopped doing that.  I'll see if I can get it to do it again.

I'm still running into some problems with PARSE... mainly from the 
expectation of what ANY and SOME should do.

For example:
>> parse "" [any [copy tmp to end]]
>> tmp
== ""

There are a few ways to do it, but that is not my point.

PARSE returns true if the rule matches and covers the entire input, 
or false otherwise. Your rule matched but there was input left over. 
PARSE's return value doesn't matter in this case, just whether file 
is set or not. If you are using R3 you can do this too:
parse buffer [ "get" [ "http" | "/" | return to " "]]

R2 or R3 ?
In any case, the first rule may fail.
you can't do "TO 1 2 digits"

given that to and thru do "more" in R3, it probably is not bad to 
consider it a bug. (maybe it should be considered a bug in R2 as 
well, given that FIND does work with charsets...)

It's simple to understand, it's faster until it's not anymore, depending 
the use cases, do your own tests

And here I thought yesterday, wow I finally understood Parse and 
gosh it's awesome. And now I read change/part, which I used, is not 
the way to do things unless it is. I am confused! Generally, but 
also now specifically.

Gregg, I used to use append/part to avoid the memory overhead of 
copy/part in many case.
Instead of doing like in the Ladislav's example. 
>> change/part something copy/part something-else range part.
I used  to do.

>> change/part something append/part clear #{} something-else range 
part.
It's not faster, but saves memory.


So, I don't know if it's a good idea to discard this use case from 
append and insert.

So I get the job done. This is the question: If I do parse/all so 
that spaces are not automatically included, how to I include the 
space in my parse rule?

Using LOAD/NEXT, I still have to use a O(n^2) algorithm. I'd now 
like to do my own parse, which can be O(n).