PARSE returns input on success, PARSE? variant #202
Conversation
This implements #2165 where PARSE is to return the input series on success, and NONE on false, unless a RETURN is used to override it (in the future, COLLECT would override it as well). It also implements a twist, with a PARSE? variation that can only return TRUE or FALSE. Since it ends in a question mark, the idea that it act exactly like the old PARSE isn't a precise match...as the rule is that functions ending in question mark return *only* true or false. As one possible way of pushing that rule through, the PARSE? variant does not tolerate RETURN (unless it is a return of a LOGIC!) and will error. This makes PARSE? suitable for use in practically every case where the previous desire to return a TRUE or a FALSE was desired. In the cases where it was not, the PARSE variant makes more sense. Legacy support uses a heuristic to make a good guess about what the original PARSE output would have been, but can be tripped up if a RETURN happened to return the series at the input position. This is an experiment to see how it goes and if it turns out to be of benefit.
|
Optime! I think also could be handy if on false the index of input series is placed at "critical" point, where fail occurs |
That's an interesting idea; though I don't know it should be modifying the input value as a requirement. Besides semantics, it may be in a protected variable--you should be able to parse read-only data). Something I have thought is that the functionality of TRANSCODE should be part of PARSE. So that is to say that you should be able to say |
|
Relating to the idea from @giuliolunati... From my experience with my Rebol 2 parse debugging tools, one of the most useful bits of information is to show the maximum point through the input that the parsing process reached before ultimately failing. In most cases this can quickly draw attention to the parse rules that require debugging. In the case of block mode this may mean the deepest level. I'm unsure of the ultimate use of returning the input series upon success, but I think it is a good step. I think that one day it would be more useful if Parse returned a parsed structure resulting from the input and the rules by default. As Parse is little interpreter maintaining state variables such as Input-Position, Rule-Success and maybe one day Furthest-Postion and Parsed-Structure, it maybe useful to be able return all of them when required. |
This implements #2165 where PARSE is to return the input series on
success, and NONE on false, unless a RETURN is used to override it
(in the future, COLLECT would override it as well).
It also implements a twist, with a PARSE? variation that can only
return TRUE or FALSE. Since it ends in a question mark, the idea that
it act exactly like the old PARSE isn't a precise match...as the rule
is that functions ending in question mark return only true or false.
As one possible way of pushing that rule through, the PARSE? variant
does not tolerate RETURN (unless it is a return of a LOGIC!) and
will error.
This makes PARSE? suitable for use in practically every case where the
previous desire to return a TRUE or a FALSE was desired. In the cases
where it was not, the PARSE variant makes more sense.
Legacy support uses a heuristic to make a good guess about what the
original PARSE output would have been, but can be tripped up if a
RETURN happened to return the series at the input position.
This is an experiment to see how it goes and if it turns out to be
of benefit.