[cl-interpol-devel] Support for Perl $1 and Makefile-like special variables

[Edi Weitz]

Hi Evgeniy,

I haven't used cl-interpol for quite some time, so I'm generally cool
with extensions or changes as long as a few criteria are met:

1. The code should try to be backwards-compatible.  People who don't
want to use the new features should be able, if possible, to use the
new version like they used the old one.

2. Everything that's added should be documented with the same
attention to detail that is currently used.  I'm not willing to accept
patches where I have to go over the patch and spend a lot of time
correcting and re-formatting.  The general patch guidelines are here:
http://weitz.de/patches.html

Judging from what you described, I agree that the best solution might
be to add one or two hooks that enable people to extend the syntax if
they want to.  I'm not sure about things like $1 and so on.  That'd
require tight integration with CL-PPCRE, wouldn't it?

Maybe the best idea is to provide a rough sketch of what you want to
do and present it to the mailing list before you do the actual work.
I'd be more interested in a detailed description of the new features
than in the implementation.

Thanks,
Edi.


On Wed, Dec 16, 2009 at 4:00 PM, Evgeniy Zhemchugov <jini.zh at gmail.com> wrote:
> Dear cl-interpol developer(s),
>
> I would like to use cl-interpol to parse strings containing Perl
> subpattern variables like $1 and Makefile special variables like $<,
> $^ etc. I also want statements like #?"$(f 5)" when
> *optional-delimiters-p* is t to be expanded into something like
>
> (with-output-to-string (#:string) (princ (f 5) #:string))
>
> rather than
>
> (with-output-to-string (#:string) (princ (progn f 5) #:string))
>
> as they do now. (However, for better compatibility with Makefiles I
> need to treat the case of the list made of a single element in a
> special way, expanding it to the value of the corresponding variable.)
> Overall, I would like to have better control over the read-form
> function, maybe the possibility to supply my own one. Could you
> install some hook there? I'd gladly do it myself and send you a patch
> but I'm not sure which way is the best and whether you will accept
> such a change at all. If you advice me some workaround that doesn't
> involve modifying cl-interpol it would also be great. I just don't
> want to fork or recreate the whole library because of a single
> function.
>
> _______________________________________________
> cl-interpol-devel site list
> cl-interpol-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cl-interpol-devel
>
>