You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, what exactly an "empty rule" is, is pretty much undefined:
there isn't really an empty rule like {}, as it gets autoconverted to NIL. Actually: {NIL}, even...
should it be "" instead?! And should that be the same as {""}, too?...
should NIL and "" mean the same, so therefore match the same way?
then how about "" always matching (unanchored), while NIL was supposed to be a forced failed match (as opposed to the forced successful match of T)?!...
Since every rule is boolean, it's an unavoidable question...
If false (NIL), then hitting an empty rule could cancel the matching of the entire syntax, rather than just being redundant, as one might expect, and as is with the _EMPTY pattern!...
OTOH, in LISP, ()is false (NIL).
Currently it's inconsistent, too: using "" would create a NIL rule, but using _EMPTY would match anything successfully.
_Not sure which one is right... _EMPTY might actually be wanted for matching the empty string exactly, and not matching a non-empty one... So, it's ambiguous.
Maybe the distinction is "explicit" empty (_EMPTY) vs "implicit" empty ("")?
NO: The distinction is that match() by default works with substrings! So _EMPTY duly matches the empty substring of everything!
It also feels natural to have both a forced-false (NIL) and a forced-true (T) rule, so this really is a conundrum now... The empty Production kinda must be NIL (to mimic LISP), but then it would not match anything, which would be inconsistent with the empty Atom ("") matching everything...
Maybe it's time to recognize and separate the result of matching something from the "result" -- the intrinsic value -- of the rule that's being matched! So, matching NIL (or false, for that matter) against "anything" can still be true! But should it?... Still don't know...
The text was updated successfully, but these errors were encountered:
xparq
changed the title
TBD: Should an EMPTY rule should be true or false?
TBD: Should matching an "EMPTY rule" succeed?
Sep 8, 2023
First of all, what exactly an "empty rule" is, is pretty much undefined:
{}
, as it gets autoconverted toNIL
. Actually:{NIL}
, even...""
instead?! And should that be the same as{""}
, too?...NIL
and""
mean the same, so therefore match the same way?""
always matching (unanchored), whileNIL
was supposed to be a forced failed match (as opposed to the forced successful match ofT
)?!...Since every rule is boolean, it's an unavoidable question...
If false (NIL), then hitting an empty rule could cancel the matching of the entire syntax, rather than just being redundant, as one might expect, and as is with the _EMPTY pattern!...
OTOH, in LISP,
()
is false (NIL).Currently it's inconsistent, too: using "" would create a NIL rule, but using _EMPTY would match anything successfully.
_Not sure which one is right... _EMPTY might actually be wanted for matching the empty string exactly, and not matching a non-empty one... So, it's ambiguous.
_EMPTY
) vs "implicit" empty (""
)?Anyway, there should be a straightforward and reliable way to choose to match the empty string only (in the sense that any non-empty string should not match). That should be achievable with anchoring (-> Add _END for anchoring, to reject extraneous input after a full match #21).
It also feels natural to have both a forced-false (NIL) and a forced-true (T) rule, so this really is a conundrum now... The empty Production kinda must be NIL (to mimic LISP), but then it would not match anything, which would be inconsistent with the empty Atom ("") matching everything...
The text was updated successfully, but these errors were encountered: