World: r3wp

I am having a hard time with using REMOVE on a parsed string.

symbol: charset [#"a" - #"z" #"A" - #"Z" #"0" #"9" "_-?!*+~"]
nstr: "...aa.....a.....a.....h." 

parse/all nstr [
	some [
		symbol | end skip | 
		[

   here: ( probe here either none? here/1 [print nstr print "!!"  ][print 
   here/1 print nstr remove here here: back here]) ; :here skip
		]
		;:here
	]
] probe nstr

this just does an infinite loop... this is one of MANY twists I've 
put on the rules... (notice commented out :here)

and nothing works... if I set here to be the previous letter and 
then use skip in the rules... the first dot from nstr will not get 
removed... since we cannot go past the begining.

doh.... was about to give a better example... then I realise the 
error... there is nothing to match in the last rule, just an expression, 
so a no match is always matching nothing !

It's nice just thinking out loud once in a while...we're here for 
you Maxim.  Cerebration.  :)

it like saying the last rule matches the tail of the string.


Thus parse never gets "passed" the end cause my last rule matches 
the end, and thus prevents the parser from ever reaching it.

well, I was trying to say that I had not realized this was possible... 
and its quite cool... we can actually use that in some ways  ...


 make rules which make parse become an event handler for example ! 
  the moment you feed a string some value, parse will start treating 
 it...

and then fall back to silence... (just inserting a little wait in 
the loop will take care of cpu load)

it would be nice if the result from the expression could be used 
to determine if the rule is a match or not...

thus having (whatever expression TRUE)  would have allowed my previous 
last rule to match "everything else"

Off topic but...that was what intrigued me with SNOBOL and Icon...succeed, 
fail and a result.

If you haven't, take a read through Icon pattern matching...mondo 
powerful.  Off topic...sorry.

here is the solution... complement the valid symbols and match them 
explicitely.

rebol []

symbol: charset [#"a" - #"z" #"A" - #"Z" #"0" #"9" "_-?!*+~"]
invalid: complement symbol
nstr: "...aa.....a.....a.....h." 

end-rule: []

parse/all nstr [
	some [
		symbol | [here: invalid (remove here) ] :here
	]
]

reading? what is that? .... oh yeah... I remember ...  something 
people with time can do ... ;-)

More off topic...I wept a little bit when I heard of Dr. Ralph Griswold 
passing, back in October.  Never met him, much respect.

Final off topic;  Now I'm slowly replacing all my computer heroes...Names 
like Kernighan, Pike, Moore, Griswold, Lovelace... are now Sassenrath, 
DocKimbel, Anton, Cyphre, Graham, Maxim, Ladislav, Henrik, Oldes...et 
al.  Thanks guys.  You are making my world a better place.

Final final...Gregg, Gabriele, Sunanda...I'm missing too many.  :) 
 And the big hook drags me off the stage.

Max: ...symbol | end skip | ... does not have much sense, since it 
is equivalent to just ...symbol | ...

Max: "it would be nice if the result from the expression could be 
used to determine if the rule is a match or not" - that is of course 
possible as follows:

rule: [(next-rule: unless result-of-expression [[end skip]]) next-rule]

see this:

>> rule: [(next-rule: unless result-of-expression [[end skip]]) next-rule]

== [(next-rule: unless result-of-expression [[end skip]]) next-rule]
>> result-of-expression: false
== false
>> parse "" rule
== false
>> result-of-expression: true
== true
>> parse "" rule
== true

yes... see the supplied fixed parser rules... I had not submitted 
the right one... I saw that after posting it  :-)

ladislav, what you demonstrate is that you can evaluate an expression 
within parse rules... parse itself does not handle the return value 
OF the expression.

right, but the value of the expression *can be used* to determine 
if a rule is a match

otherwise, I am for addition of a rule which would take the result 
of the paren! expression directly into account without us having 
to resort to this (more complicated) way

that is what I meant... I'd like parse to do it for us .

obviously, using many tricks we can let parse do anything  (including 
become an event parser as I discussed above  ;-)

anyway, when you have got the RULE above, you can now always write: 
parse "" [(result-of-expression: compute-something) rule]

got to go *now*   ;-)   female in the house   ;-)

if you use a more appropriate rule name like check-result, you have 
got a more readable:

parse "" [(result-of-expression: compute-something) check-result]

guru question;  Will a utype! definition be allowed to wrap builtins? 
 SNMP MIBs require a fairly heavy weight tuple!  But will a short 
MIB conflict with internal scans of tuple! or do utype! scans take 
some form of precedent?  I've become curious, yet remain dumb enough 
to not know.

Isn't this a bug?
>> parse [a/b] [a/b]
** Script Error: a has no value
** Near: parse [a/b] [a/b]

I don't want the a to be evaluated in the parse rules!

hm... ech.. I'm stupid.. normaly is evaluated as well, so it's not 
a bug.. but is there any way how to parse specific path! ?

I mean:
>> parse [a] ['a]
== true
>> parse [a/b] ['a/b]
== false

Brian: only Carl probably knows that.

>> parse [a/b] [(path: 'a/b) path]
== true
>> parse [a/c] [(path: 'a/b) path]
== false

that works, but it's ugly:(

older versions did not evaluate paths. since newer version do, we 
need 'a/b to work. dunno if this is in RAMBO... but it needs to be 
fixed.

Yes I know they were not evaluated before, but I'm not sure if it's 
not a feature, that they are evaluated now.

I just think, that maybe it would be good to have parse [a/b] ['a/b] 
== true as is parse [a] ['a]

But I'm not sure at all.

..because it would not be useful anyway as I would have to write 
a special rule for each refinement.

it's not a bug that they are evaluated (in fact it was requested 
in a rambo ticket). it's a bug that - since now they are evaluated 
- lit-paths are not used to match paths.

Maybe if the result of parens were parsed, we could use a paren to 
evaluate a path (and don't use a paren to leave as is).

What's the status on implementing the PARSE suggestions that we hammered 
out months ago?

Many of the requests here would be handled easily by the extensions 
we proposed last year.

it looks like that 3.0 won't have a new parse, but i don't have any 
details and i'm just guessing.