Comments on: PARSE: which is proper COPY result?
While looking over the new decode-url bug, the source of the problem comes from this small difference in parse:
>> chars: charset "abc"
>> parse "x" [copy s [some chars | none]]
before the rewrite, s was set to NONE. The question is, which result is correct?
This situation also exists for blocks:
>> parse [a] [copy b [some 'x | none]]
The fact that both s and b have values is an indication that the rule succeeded. The prior parse behavior came from the fact that if the input did not advance, then the result was NONE.
We need to make a decision on this. The code change is minor, but we must weigh the issues of compatibility with correctness.
I prefer the new behaviour. It looks more understandable than the previous one, exactly since the COPY result is related to the success of the rule, so it adheres to the principle of the least surprise.|
... and less error handling code is needed.
1+ for the new return type|
For years now we've had to workaround the old behavior in productions to get the new behavior. The old behavior was a frequent cause for frustrated questions in the help groups too. Keep the new behavior :)|
I think it is clear to anyone copying and pasting code snippets that R3 and R2 are not directly compatible.
Anyone making the switch will have to go over existing code with an eye toward a migration issues checklist. Parse is already on that list.
Which makes the choice in a matter like this obvious: correctness.
I will reiterate my proposal that "simple parse" be renamed (e.g. to lexify) in order to make parse *always* return either true or false, as well as to make sure all search hits on parse land people on interesting pages as opposed to trivial ones. People have a tough time getting new ideas in their head, and you make it harder when you say "parse is this mundane thing, but it's also this exciting thing"
Much more of a slam dunk when you can say "parse is amazing! always! it always returns either true or false, and it always takes a dialect!" The whole idea of formalized parsing is beyond the average programmer, and there's no sense making it trickier by conflating ideas into a single bizarro function.
Ok, the new behavior stands. I'll fix DECODE-URL.
HF: That's a good point and the subject for a new blog.
Post a Comment:
You can post a comment here. Keep it on-topic.