Speed of UPARSE

[hostilefork]

@hostilefork

'optional combinator [
    "If applying parser fails, succeed and return NULL; don't advance input"
    return: "PARSER's result if it succeeds, otherwise NULL"
        [any-value? pack?]
    parser [action?]
    <local> ^result
][
    [^result remainder]: parser input except e -> [
        remainder: input  ; succeed on parser fail but don't advance input
        return null
    ]
    return ^result  ; return successful parser result
]

Speaking of optimizations, this doesn't even need the result temporary. Nor does it care what the raised error is, so the branch doesn't need to be a lambda:

return [{^} remainder]: parser input except [
    remainder: input  ; succeed on parser fail but don't advance input
    return null
]

(Truly being equivalent requires the {^} to not decay synthesized pack results, which should possibly be the same behavior you get if you'd named a variable, I need to look into this.)

Instead of a preemptive RETURN inside a RETURN, you could write that instead so the branch gives back the result and remainder as a pack (antiform block):

return [{^} remainder]: parser input except [
    pack [null input]
]

But I happen to be certain that would be slower... you pay to reduce [null input], and then you have to pay for SET-BLOCK! to unpack the multi-return.

Neat as all that is (and I think it is neat), worrying over such details isn't really where I want to focus right now.

---

Note that usermode micro-optimization can get fairly crazy, e.g. you know that NULL needs to do a WORD! lookup to fetch the value of NULL... but the quasiform ~null~ has a rote evaluative rule of just setting the quote byte of the quasiform from 2 to 0 to be an antiform... so return ~null~ is faster than return null. Many historical Rebol programmers were obsessed with this kind of detail...