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@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@common-lisp.net http://common-lisp.net/mailman/listinfo/cl-interpol-devel