Re: New rx implementation with extension constructs

["Mattias Engdegård" <mattiase@acm.org>]

5 sep. 2019 kl. 17.38 skrev Noam Postavsky <npostavs@gmail.com>:
> 
> Do you mean that macros don't support (literal LISP-FORM) and (regexp
> LISP-FORM)?  Or something else?

No, those work just as before. I just meant that user-defined rx forms work by plain substitution and have no computational power. They are more like C macros than Lisp macros in that respect.

But you are quite right --- `literal', `regexp' or `eval' could be (ab)used to get computing macros, so it isn't really a limitation.

> It would help to add some concrete examples (i.e., of things that
> would count as `t', `seq', etc) to this abstract explanation.

Thanks, will do.

>> +(defun rx--translate-symbol (sym)
>> +  "Translate an rx symbol.  Return (REGEXP . PRECEDENCE)."
>> +  (pcase sym
>> +    ((or 'nonl 'not-newline 'any) (cons (list ".") t))
> 
> Is there a reason not to use '((".") . t) here (and similar for the rest
> of the alternatives)?  If yes, then it's probably worth mentioning in a
> comment.

It's because they may be fed into mapcan; I'll add a comment (or maybe use something non-destructive). Thank you.

> If not using string-to-multibyte, I think this lambda can be replaced
> with #'unibyte-char-to-multibyte.

Didn't know about that one, thank you!