World: r3wp

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.

it's also true that some requests could be implemented rather easily... 
so maybe they can make it in for the first release.

Does that imply there won't be a Unicode Charset with which to parse 
unicode strings?

There is going to be a unicode! datatype

sorry.  Didn't finish...hit wrong key...


but I'm not sure what that means for charsets

Perhaps vector! will play a part in solving the unicode problem

having Unicode datytype does not mean we have unicode datatype ;-)

you can make a bitset with 65000 bits in r2... so why not in r3?

Gabriele - how do you create unicode (mostly 16bit, or varrying) 
charset in R2? :-)

btw - pity R3 does not integrate any parser helpers, which could 
make life easier

what do you mean by "does not integrate" and by "parser helpers"?

helpers = suggestions ... historically there were 2 or 3 lists with 
various suggestions, to some of them even Carl said he could consider 
to add them. First one was Robert's site, next one was yours, and 
several times ono various altme channels?

I don't know, as for me, I just wanted to|thru [a | b | c] :-)

I would let others more skilled parse gurus to raise their wishes 
...

petr, i didn't say r3 won't improve on parse, i said that the first 
release may not have the new features.

we won't stop at 3.0... there will be a 3.1 and so on... at least 
we hope so :)

(lost my connection yesterday night and the message i was typing...)

parsing utf-8 in r2 is easy. utf-16 and utf-32 are less confortable 
but should be easy too.

of course with r3 it's much easier because - i guess - you can just 
parse the unicode! string.

Is it possible to combine two bitset!s?

using  'union

great, thanks!

Is there some way to make this work: parse "aaa" [some "a" "a"] or 
PARSE just don't work this way?

What do you mean?
>> parse "aaa" [some "a"]
== true

Why the second "a"?

It may seem strange I know, but this is automaticaly created rule

Parsing for [some "a" "a"] will return false, because you've already 
parsed past the "a"s.