problem with elisp compilator

problem with elisp compilator

[Pascal Bourguignon]

I have the following  problem while compiling some common-lisp sources
with emacs:

Compiling pjb-regexp.lisp ...
defining string=
While compiling pjb-re-string-match in file /home/pascal/src/common/lisp/common-lisp/pjb-regexp.lisp:
  ** string= called with 6 args, but requires 2
While compiling pjb-re-decorate-tree in file /home/pascal/src/common/lisp/common-lisp/pjb-regexp.lisp:
  ** member called with 4 args, but requires 2
Wrote /home/pascal/src/common/lisp/common-lisp/pjb-regexp.lisp.elc
Done


The compilator invocation is done as follow:

    emacs -batch -q  -l ../emacs/.emacs -l ../emacs/pjb-cl.el \
       -f batch-byte-compile pjb-regexp.lisp


../emacs/.emacs contains (add-to-list 'load-path ... statements)

../emacs/pjb-cl.el requires 'cl and contain additionnal common-lisp definitions.

In particular, it contains:

    (eval-when (compile load eval)
      (mapc (lambda (sym) (fmakunbound sym))
            '(
              ;; ...
              string=
              string<
              ;; ...
              )
            )
      )

    (message "defining string=")

    (defun string= (string1 string2 &rest cl-keys) 
      ;; &key :start1 :end1 :start2 :end2)
      ;; ...
    )

    (defadvice member 
      (around pjb-cl-member first (item alist &rest cl-keys) activate)
      ;;...
    )
    (ad-activate 'member)


The message "defining  string=" shows that pjb-cl.el is  loaded at the
beginning  of the compilation  of pjb-regexp.lisp,  but then  it seems
that the  compilator does  not take into  account definitions  in this
file  neither of  a  new string=  definition  or of  an  advice to  an
existing primitive.

Doesn't it looks like a bug?  What can I do about it?


-- 
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him.  -- Robert Heinlein

Re: problem with elisp compilator

[Kevin Rodgers]

Pascal Bourguignon wrote:

> The message "defining  string=" shows that pjb-cl.el is  loaded at the
> beginning  of the compilation  of pjb-regexp.lisp,  but then  it seems
> that the  compilator does  not take into  account definitions  in this
> file  neither of  a  new string=  definition  or of  an  advice to  an
> existing primitive.
> 
> Doesn't it looks like a bug?  What can I do about it?


The same thing that Emacs' CL emulation does: Don't override Emacs Lisp
function definitions; instead, define a new function with "*" appended
to the name.

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: problem with elisp compilator

[Pascal Bourguignon]

Kevin Rodgers <kevinr@ihs.com> writes:

> Pascal Bourguignon wrote:
> 
> > The message "defining  string=" shows that pjb-cl.el is  loaded at the
> > beginning  of the compilation  of pjb-regexp.lisp,  but then  it seems
> > that the  compilator does  not take into  account definitions  in this
> > file  neither of  a  new string=  definition  or of  an  advice to  an
> > existing primitive.
> > Doesn't it looks like a bug?  What can I do about it?
> 
> 
> The same thing that Emacs' CL emulation does: Don't override Emacs Lisp
> function definitions; instead, define a new function with "*" appended
> to the name.

I don't  want the  same features as  in Common-Lisp under  a different
name.   I  want to  be  able  to use  the  same  lisp  source both  in
Common-Lisp and in Emacs Lisp.

Anyway, this is a general  problem, and it occurs both when redefining
a function and when advising a function.


-- 
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him.  -- Robert Heinlein

Re: problem with elisp compilator

[Kai Großjohann]

Pascal Bourguignon <pjb@informatimago.com> writes:

> I don't  want the  same features as  in Common-Lisp under  a different
> name.   I  want to  be  able  to use  the  same  lisp  source both  in
> Common-Lisp and in Emacs Lisp.

I think the best approach is to define compatibility functions in
your own namespace.  That is, when you want to compare strings, use
pjb-string=, then define that function appropriately.  Maybe a simple
defalias (does that exist in CL, too?) is sufficient.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)