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
Some expressions should always be inlined (character classes, literals), others should never be inlined (memoized or lexical rules, any future rule-level feature), and the rest should be considered for inlining depending on the specifics of their internals.
Some situations are fairly ambiguous, for example:
a = b b c c
b = any:. { any.ToUpper() }
c = any:. {{
/* a whole bunch of code... */
}}
In this case, I would want to write a rule that says, "if the code in the code section contains line breaks, do not inline it." So b, specifically, would be inlieable.
Due to the complex nature of this kind of rule writing, there needs to be a pretty good API for expressing these rules.
Not putting this on a release yet, since it needs to be thought out a bit more.
The text was updated successfully, but these errors were encountered:
Some expressions should always be inlined (character classes, literals), others should never be inlined (memoized or lexical rules, any future rule-level feature), and the rest should be considered for inlining depending on the specifics of their internals.
Some situations are fairly ambiguous, for example:
In this case, I would want to write a rule that says, "if the code in the code section contains line breaks, do not inline it." So
b
, specifically, would be inlieable.Due to the complex nature of this kind of rule writing, there needs to be a pretty good API for expressing these rules.
Not putting this on a release yet, since it needs to be thought out a bit more.
The text was updated successfully, but these errors were encountered: