gmane.lisp.interpol.general

Thank you

Anthony Martin — 2012-05-02T01:18:30

Thank you for contacting me. ASM
_______________________________________________
cl-interpol-devel site list
cl-interpol-devel< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/cl-interpol-devel

Re: Support for Perl $1 and Makefile-likespecial variables

Edi Weitz — 2009-12-21T20:15:53

OK, I see.  Sorry, I only took a quick glance.  That's why I asked for
a description instead of the implementation... :)

If you can provide in January what would be added to the cl-interpol
documentation, then we'll have something to talk about.  We can
discuss the implementation afterwards.

Thanks again,
Edi.


On Mon, Dec 21, 2009 at 7:40 PM, Evgeniy Zhemchugov <jini.zh< at >gmail.com> wrote:

_______________________________________________
cl-interpol-devel site list
cl-interpol-devel< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/cl-interpol-devel

Re: Support for Perl $1 and Makefile-likespecial variables

Evgeniy Zhemchugov — 2009-12-21T18:40:37

I'm not sure if you get me right. Perhaps I haven't made myself clear
enough, sorry. The =~ macro is what I'm going to use in my code, I
don't think it should belong to the library. At least not until I test
it in one of my projects. The actual modification I propose is the
change in the read-form function so user would be able to supply their
own reader to be executed during expansion of the $form --- in the
same way as we supply readers to Lisp's read via set-macro-character.
No change of CL-PPCRE is required in this case --- everything can be
done on the user side.

I can suggest another solution though. We can declare the *read-form*
special variable like this:

(defvar *read-form* #'read-form)

and replace the calls to read-form by funcalls to *read-form* in the
inner-reader function. The user can then set this variable to the
value they desire thus controlling the way cl-interpol expands
$-forms. However, I think the former solution is more elegant.

Don't bother to answer soon. I'm also busy these day

Re: Support for Perl $1 and Makefile-likespecial variables

Edi Weitz — 2009-12-21T16:38:42

I'm not sure if I really like this, especially as I think this is a
very specific addition only to be Perl-compatible.  I'd be more happy
with something like a very thin layer atop cl-interpol that enables
users to extend it (for example in the way you want) but doesn't
prescribe an actual syntax.

But I'm pretty sure I don't want to change CL-PPCRE for this goal.

Anyway, I won't have more time to think about this before the next
year begins.  Too busy, sorry.

Thanks and Happy Holidays,
Edi.


On Thu, Dec 17, 2009 at 8:58 PM, Evgeniy Zhemchugov <jini.zh< at >gmail.com> wrote:

_______________________________________________
cl-interpol-devel site list
cl-interpol-devel< at >common-lisp.net
http://common-lisp.net/mailman/listinfo/cl-interpol-devel

Re: Support for Perl $1 and Makefile-likespecial variables

Evgeniy Zhemchugov — 2009-12-17T19:58:38

I was thinking about something like this:

(defvar *groups*)

(defmacro =~ (scanner string &body body)
  `(let (($_ ,string))
     (multiple-value-bind ($- $+ < at >- < at >+) (cl-ppcre:scan ,scanner $_)
       (let ((*groups* (map 'vector
                            (lambda (start end)
                              (subseq $_ start end))
                            < at >-
                            < at >+)))
         ,< at >body))))

; Just as in cl-interpol
(defvar *readtable-copy* (copy-readtable))

; Readtable modification for $1, $2, etc
(set-macro-character #\$
  (lambda (stream char)
    (if (digit-char-p (peek-char nil stream nil #\newline t))
      ; Doesn't work well with symbols like $1:a. Also, interns unnecessary
      ; symbols. The alternative is to parse the stream until a terminating
      ; character occur (with some check for package designators), but
      ; how to determine whether a given character is a terminating one?
      (let ((symbol (read stream nil nil t)))
        (if (subtypep (type-of symbol) 'in

Re: Support for Perl $1 and Makefile-likespecial variables

Edi Weitz — 2009-12-17T07:44:21

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

Support for Perl $1 and Makefile-like specialvariables

Evgeniy Zhemchugov — 2009-12-16T15:00:51

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