So this is good when you're writing an expression that's supposed to return a value. But if you're only interested in if the parse reached the end or not, it's not good enough.
>> try parse "aaabbb" [some "a" opt some "b"]
== ~null~ ; anti
That parse reached the end, but the product of the OPT combinator inside the parse block when it doesn't match is NULL. So if try parse ... is unfortunately not a general answer to testing if a parse completed.
-
if not raised? parse ... works but is overly verbose.
-
if unraised? parse ... is a little shorter but awkward.
-
if ok? parse ... is no longer an option due to the meaning of okay in Flexible Logic
-
if try? parse ... builds on the existing TRY concept so you can see the relationship, but is a bit weird.
-
if did parse ... looks nice but DID is taken for something else, that I don't think should be conflated with error defusion.
-
if success? parse ... or if succeeded? parse ... is a little bit like OK? in the sense that success is a pretty open-ended concept. But TRY is tied up a bit with "success" so SUCCESS? as the complement to RAISED? isn't a terrible thing.
-
if good? parse ... is weird, and the suggestion of BAD? as a synonym for RAISED? is weird also.
-
if parse? ... as a different form of PARSE that just returns true or false based on reaching the end is something that has shown up from time to time, but I've never been crazy about it. Functions ending in question mark tend to take one argument. This is like it's testing if something is a parse-state object or similar, and I can't quite read it as "if parse reached end".
-
if completed? parse ... is appealing, it's a bit of a parallel to Rebol2's FOUND? to pair with FIND. It leads to a world where completed? null is true. While not being a generic word it would function generically to other things that might raise failures leading to misuse, and it's a long word.
Everything has its upsides and downsides.
Or... A Refinement to PARSE, or Combinator?
For the sake of covering all the bases, I'll mention this could be attacked on the insides of parse, as well.
if parse/completed "aaabbb" [some "a" try some "b"] ...
if parse/tail? "aaabbb" [some "a" try some "b"]
if parse "aaabbb" [completed? [some "a" try some "b"]] ...
if parse "aaabbb" [some "a" try some "b" || accept <end?>] ...
Experience Probably Informs This
I think it's hard to see clearly in particular having seen so many different return modes of PARSE over time.
People can of course easily make their own shorthands, even PARSE?, if they like it.