[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New rx implementation with extension constructs
From: |
Mattias Engdegård |
Subject: |
Re: New rx implementation with extension constructs |
Date: |
Thu, 5 Sep 2019 18:49:23 +0200 |
5 sep. 2019 kl. 17.38 skrev Noam Postavsky <address@hidden>:
>
> 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!
Re: New rx implementation with extension constructs, Noam Postavsky, 2019/09/05
- Re: New rx implementation with extension constructs,
Mattias Engdegård <=
Re: New rx implementation with extension constructs, Mattias Engdegård, 2019/09/06