Re: rx and rx-to-string handle (regexp VAR) differently

[Platon Pronko]

> 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