Hi bciceron,
The short version is: I believe it's a bug.
The long version:
space at the begining of string:
>> parse " LIB1" ["LIB1"]
== true
space smack in the middle of token:
>> parse "LI B1" ["LIB1"]
== false
Now, that somehow makes sense. If I am parsing for the token LIB1 I do not
want the two tokens "LI" and "B1" separated by anything - including a space
- to qualify. Otherwise I should make white spaces separating "LI" and "B1"
part of my rule.
>> parse "LIB1 " ["LIB1"]
== false
Apparently "LIB1 " with a trailing space is treated like "LI B1" with a
space separating two parts of the token. That space is not being ignored.
I think that's a parse bug and should be reported as such. The trailing
space should be ignored. That's because:
SPACE NOT IGNORED:
>> parse "LIB1 " ["LIB1"]
== false
SPACE IS IGNORED:
>> parse "LIB1 " ["LIB1"(print "found it")]
found it
== true
Note that I did not change the rule that determines which tokens are
recognized! I only added an instruction to print "found it" when the token
has been recognized. Since the token to be recognized has not changed, and
the string being parsed has not changed, the two previous cases should
evaluate to the same thing.
Here's another example:
>> parse "LIB1 " [some ["LIB1"]]
== true
Here I permit multiple occurences of "LIB1" in the input stream. Again the
trailing space is ignored.
My guess is that the parser does something like this:
1. Is the current character in the input stream identical to the current
character in the token?
2. Answer to 1: No.
Am I ignoring spaces and current character in input stream is character?
If Yes: increment input stream index.
Reset token index to beginning.
Return to 1.
If No: Return false
3. Answer to 1: Yes.
Then Increment input stream index, increment token index
4. Is the token index exhausted? Yes. Check input stream index:
5. Is there anymore stuff left in the input stream? Yes.
6. Are there anymore rules left? No.
7. Report false.
Instead, 7 should be
7. Am I ingoring spaces? Yes. Then
8. Do I encounter only spaces until string index is exhausted?
9. If 8. evaluates to YES: return true
If 8. evaluates to NO: return false
Until this is repaired you may want to go with the some version of
lib-type, i.e.
>> lib-type: [some ["LIB1" | "LIB2"] ]
== [some ["LIB1" | "LIB2"]]
>> parse "LIB1 " lib-type
== true
Hope this helps.
At 12:41 PM 4/5/00 -0500, you wrote:
>
>parse is very powerfull but still kills me with spacer:
>
>>> parse "asergd" lib-name
>== true
>>> parse "LIB1" lib-type
>== true
>
>so the 2 elements matches the 2 single rules.
>but pout together they don't :
>
>>> parse "asergd LIB1" [lib-name lib-type]
>== false
>>> probe parse "asergd LIB1" [lib-name lib-type]
>false
>== false
>>> parse/all "asergd LIB1" [lib-name lib-type]
>== false
>
>but the white space means trouble:
>
>>> parse/all "asergd LIB1" [lib-name " " lib-type]
>== true
>
>why one matches with extra white space and not the other ?
>>> parse "LIB1 " lib-type
>== false
>>> parse "asergd " lib-name
>== true
>>> parse " asergd " lib-name
>== true
>
>lib-name: [name]
>name: [ some symbol ]
>lib-type: [ "LIB1" | "LIB2" ]
>symbol: charset [#"0" - #"9" #"A" - #"Z" #"a" -
>#"z" #"." #"-" #"_" #"$" #"+" ]
>
>
>
>
>
;- Elan >> [: - )]
