Comments on: PARSE: what to do about ANY?
This is a really old issue. There is a special case in parse that requires better definition. It occurs when you write rules like:
The ANY word means accept 0 or more repetitions of the rule. But that block has no rule... so nothing fails. The question is: when does the loop stop?
One thing to note in the case above: the input series is not advancing. That is: we're not parsing anything, we're just looping.
So, we either need to require that users write:
any [pos: fail]
to avoid the infinite loop, or we must redefine ANY to accept 0 or more repetitions, as long as the input is advancing. Or, we just let it remain an infinite loop.
And, of course, this issue applies to more than just ANY.
Let me know your thoughts on this.
We had a big discussion about this on AltME that sort of went:
Me vs. everyone else. :-)
1. In R2, it's easy to trigger this state using the console, and you can't stop it with escape (which has been claimed to be a bug in the R2 console). I wanted it to throw an error instead.
2. When testing parse blocks in the console, a beginner has to worry about this, and an expert can accidentally create an empty rule. Both can ruin a console session in R2 and it might scare the beginner, and it did for me in the beginning.
3. R3's console generally allows fewer cases than R2, where you can escape from an infinite loop by pressing Ctrl-C.
This was generally disagreed upon for three reasons:
1. In order to allow Turing completion, the loop would have to remain and beginners would have to take that into account. This would be in the same area as typing:
which you just don't do. An unwritten rule.
2. any  is just one case. You can create complex rules that never move forward, and so, a fix to this problem would have little effect.
3. Type more carefully. RTFM. Parse isn't for beginners.
4. R3's console might be fixed to allow escaping from such loops. Will it?
I lost the argument.
The discussion Henrik mentions is here:
Please do do sometime about non-advancing rules!
Just for these who don't know it, you can skip from such a loop in R2 if you use () inside:
>> parse "" [any [pos: ()]]
But I agree that it would be good to be able escape from such loops even without this trick. Except of that I would leave it as it is.
There are cases, when we do not want to advance the input (see e.g. the usefulness of the AND keyword). If we do it in an ANY loop not wanting to loop forever, we may e.g. change some state variable of our own.
Forbidding such constructs means limiting the capabilities of Parse. I prefer to allow infinite loops instead.
Please allow infinite rules. In addition to the productions and manual position setting you had in R2, R3 also has the lookahead rules and and not, the semantic check rule if and the modification rules change, remove and insert. All of these operations can affect the input conditions in ways that don't involve advancing the position. Don't hobble us when writing such rules.|
Elitist Defender: "It's right, but it's right! It's Alan Turning worshipping at its finest!"
Practical Man who recognizes life is short (about 80 years): "But can everyone use it?"
The following comment taken from above smacks of elitism and serves no purpose: "3. Type more carefully. RTFM. Parse isn't for beginners."
PARSE is for everyone and at all times.
The purpose of computing is to get results. Better computing lets ever more persons "speak the language."
If you feel the lame need to believe that you're superior to others, go program in assembler.
If the design of something that is not obvious or requires intense explanation where defense of the kludgy design rests on theoretical foolery, then the design sucks, it fails.
Post a Comment:
You can post a comment here. Keep it on-topic.