[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rx and rx-to-string handle (regexp VAR) differently
From: |
Platon Pronko |
Subject: |
Re: rx and rx-to-string handle (regexp VAR) differently |
Date: |
Fri, 9 Jun 2023 08:57:52 +0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 |
Is there a bug to file here, or have I missed something in the
documentation that explains why rx can work with (regexp VAR) but
rx-to-string cannot?
rx-to-string docs explicitly say: "The arguments to ‘literal’ and ‘regexp’ forms
inside FORM must be constant strings."
As to "why it was done like this?", I guess that's because (rx) is a macro and
(rx-to-string) is a function. So (rx-to-string) tries to evaluate everything in a
self-contained way, without accessing outside environment (this might prevent certain
error cases when rx form is created in one place, then stored and evaluated in a
different context).
But (rx) is a macro, and thus it can be free to expand to whatever it likes -
so it sets (rx--delayed-evaluation t) and outputs an expression that references
outside variables.
Re(-re)ⁿ-reading that last sentence makes me tentatively conclude that
foo-regexp is not in rx-to-string's "current lexical environment", but
somehow is in rx's?
In this case it actually is in rx-to-string's current lexical environment, but
it just doesn't care - it checks if expression is a literal string and throws
an error otherwise.
And in rx's case it also is in the current lexical environment, however the
symbol evaluation happens only after the macro was expanded - (rx) itself
simply returns foo-regexp as-is:
(macroexpand-1 '(rx foo)) ;; output: foo-regexp
--
Best regards,
Platon Pronko
PGP 2A62D77A7A2CB94E