At 16:00 2001-11-30 +0100, you wrote:
>Hallo Peter,
>
> > To all who helped me out with the parsing problem I
> > finally found a solution by myself.
> >
> > Thanks a lot anyway!
>
>can you please share it with us if it's different?
Well, I used another way to parse where I included some
more
Hi Ladislav,
>> But there is at least one little problem with Ladislav's not-rule:
> This is not a problem with my rule, it is by design.
I did not say it was a bug. Only that it must be adapted to the goal you want
to reach. And your examples confirm my idea. :-)
---
Ciao
Romano
--
To unsub
Hi all,
I just uploaded a newer version of %parseen.r to my Rebsite
(Sites/Ladislav). It contains more examples, I left out the unnecessary A-B
rule and returned to iterative version of To-rule (the recursive version was
limited by the size of input).
Cheers
Ladislav
--
To unsubscribe from
Hallo Peter,
> To all who helped me out with the parsing problem I
> finally found a solution by myself.
>
> Thanks a lot anyway!
can you please share it with us if it's different?
Zaijian
Mario
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubs
Hello!
To all who helped me out with the parsing problem I
finally found a solution by myself.
Thanks a lot anyway!
Best regards,
Peter Carlsson
Peter CarlssonTel: +46 31 735 45 26
Saab Ericsson Space AB
Hi once again,
I am adding a variation on Romano's example to show how it can be solved:
nr: not-rule [1 1 1]
parse [1] [any [nr skip]]
parse [2] [any [nr skip]]
HTH
Ladislav
<>
But there is at least one little problem with Ladislav's not-rule:
>> nr: not-rule [1]
== [[[1] (f
Hi Romano,
<>
But there is at least one little problem with Ladislav's not-rule:
>> nr: not-rule [1]
== [[[1] (finish: [end skip]) | (finish: [])] finish]
>> parse [1] nr
== false
>> parse [2] nr
== false
> Regards,
> Brett.
---
Ciao
Romano
<>
This is not a problem with my rule, it is by de
Hi, Brett
> Something to think about regarding your solution is the ways that it is not
> equivalent to mine. You already pointed out
> that yours returns true for a void block by design. But yours also returns
> true when '| is the first word in the block. Also
> by design? :)
No, of course :-)
;[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 30, 2001 12:52 PM
Subject: [REBOL] Re: Problems with parsing
> Hi Brett,
>
> why not:
>
> rule: [any ['| (print "***") opt rule | set item word! (print mold
> item)]]
> parse
t;
To: <[EMAIL PROTECTED]>
Sent: Friday, November 30, 2001 1:41 AM
Subject: [REBOL] Re: Problems with parsing
> Hi Peter,
>
> > Any suggestions on how to make a parse rule for text
> > NOT including a special pattern?
> >
> >Crystal clear?!?
>
> Somewhat. I
Hi Peter,
> Any suggestions on how to make a parse rule for text
> NOT including a special pattern?
>
>Crystal clear?!?
Somewhat. It would be better to provide an example, because now I have to
show the solution *and* design an example :)
I have come across this sort of problem a few times and
Hallo Peter,
> Any suggestions on how to make a parse rule for text
> NOT including a special pattern?
'parse returns 'true or 'false if the rule is or isn't
matched so, if you make a rule to check if the pattern
exists:
not parse given-text pattern-rule
will be 'true if the pattern is not
12 matches
Mail list logo
