Just a week ago, things stood at the idea that TRY was for "defusing NULL" by turning it into a BLANK!:
>> try null == _ ; tolerated by some functions that would not tolerate NULL
But that's all out the window, now. TRY is for saying "hey, wait, don't fail... you can be a no-op, that's fine." Nothing to do with blanks anymore.
This makes it a candidate for being a very literate alternative to OPT in parse!
>> parse "aaaccc" [some "a", try some "b", some "c"] == "c"
It helps make the loss of "ANY" as a looping construct more palatable, as
try some is easier on the eyes than
But...what about conflation with the purpose of defusing NULL arguments?
>> rule: null >> parse "aaaccc" [some "a", try some rule, some "c"] == "c" ; ???
Hmmm. And what if you wanted to require it unless it was null?
>> rule: "b" >> parse "aaaccc" [some "a", try some rule, some "c"] ; null (e.g. conceptually I was TRY-ing RULE, not the SOME)
That doesn't feel right. And I don't like the idea that we'd be seeing things like opt try some rule on any kind of regular basis.
Let's Remember: This is a Dialect
Things are already stretched around a bit, and we make things line up when they make sense...and unalign them when they do not.
We're free to say that TRY has nothing (or little?) to do with tolerating NULL inputs to parse rules, but where it shares heritage in meaning is "a no-op here is okay".
I think there are two reasonable options:
Keep the current policy that most times, passing a NULL to rules is an error. If you want a no-op rule, use
or for more efficiency, (the ') (a quoted null)
So this would mean that the decision is on a per-combinator basis, vs. saying all parser arguments to combinators are implicitly
[<try>]... and so things like SOME would not choose to label its argument that way.
Exceptions could be made for things like SEEK, where try seek (null) would be a way to say it's okay if you don't provide a seek position.
Systemically allow conflation on all combinators, where some null errors but try some null is legal.
Off the top of my head here, I think (1) is probably the better choice. If someone disagrees, we might want to make it easier to change via a switch vs. having to copy all the combinators and add
<try> to their arguments.
But I definitely don't like the idea that a rule prefaced with TRY would be expected to succeed if its argument were non-null. TRY should mean the rule cannot fail its match (other than by raising an error).