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

["Kévin Le Gouguec" <kevin.legouguec@gmail.com>]

Platon Pronko <platon7pronko@gmail.com> writes:

>> 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."

Drats.  So they do.  Second sentence of the docstring no less; and a
completely separate paragraph in "(elisp) Rx Functions".

I have no words 🤦

> 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

Thanks for the perspective, much appreciated!