Embeddable Common-Lisp

On 1/13/08, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll@...> wrote:

> In particular one needs reproducible cases. ECL reads perfectly fine
> the symbol ".n." when I type it, how and when does this happen?

Here is the macro DEFMFUN (slightly abbreviated) from Maxima.

(defmacro defmfun (function &body  rest &aux .n.)
  (cond ((and (car rest) (symbolp (car rest)))
         ;;old maclisp narg syntax
         (setq .n. (car rest))
         (setf (car rest)
               `(&rest narg-rest-argument &aux (, .n. (length
narg-rest-argument))))))
  `(progn
    (defun ,function . ,rest)))

Here is what I get in a fresh ECL session. /tmp/defmfun.lisp contains
just the macro definition shown above.

> (load "/tmp/defmfun.lisp")
;;; Loading "/tmp/defmfun.lisp"
"/tmp/defmfun.lisp"
> (macroexpand '(defmfun foo n (print (arg 0))))
The variable N. is unbound.
Broken at EVAL.No restarts available.
Broken at DEFMFUN.

Now if I change the symbol .n. to ecl-foo-.n. then I see this:

> (macroexpand '(defmfun foo n (print (arg 0))))
(PROGN
 (DEFUN FOO (&REST NARG-REST-ARGUMENT &AUX (N (LENGTH NARG-REST-ARGUMENT)))
   (PRINT (ARG 0))))
T

... which is to be expected.

Thanks for your help,

Robert

On 1/12/08, Waldek Hebisch <hebisch@...> wrote:

> I am not sure if it matters but linking is done by a separate
> compiler invocation.

What are the arguments for that separate invocation?
Compiling Maxima is organized by MK:DEFSYSTEM --
maybe MK:DEFSYSTEM is not executing the linking step.

Robert

On Jan 13, 2008 6:49 PM, Robert Dodier <robert.dodier@...> wrote:
> On 1/12/08, Waldek Hebisch <hebisch@...> wrote:
>
> > I am not sure if it matters but linking is done by a separate
> > compiler invocation.
>
> What are the arguments for that separate invocation?
> Compiling Maxima is organized by MK:DEFSYSTEM --
> maybe MK:DEFSYSTEM is not executing the linking step.

That phrase refers to a different process in which one compiles lisp
files into object files and then links them to form either a big
unified FASL or a single executable program. MKDEFSYSTEM is compiling
and loading files one after another, following the rules that the
system definition establishes.

Juanjo

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com

On 1/13/08, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll@...> wrote:

> Same thing applies to the compilation problems. The compiler does not
> require functions to be defined before compiling a file.

Yes, in most cases, functions which are undefined are eventually
called successfully. But there appear to be at least a few which are not.
One example, which, unfortunately, works correctly now,
involves the functions $SET_PARTITIONS and SET-PARTITIONS in:
http://maxima.cvs.sourceforge.net/maxima/maxima/src/nset.lisp
$SET_PARTITIONS is defined first and it calls SET-PARTITIONS.
When I compiled Maxima via MK:DEFSYSTEM, following these instructions:
http://maxima.cvs.sourceforge.net/maxima/maxima/INSTALL.lisp
the behavior which I observed was that SET-PARTITIONS seemed
to return NIL -- I don't specifically know that SET-PARTITIONS
returned NIL; maybe the function call was replaced with NIL, I can't
tell. But if Maxima is not compiled (only interpreted) then
SET-PARTITIONS is called correctly. As I mentioned, this bug
has now apparently gone away; I don't see it now, maybe I would
have to make a clean rebuild to see it again.

A similar bug which I am still seeing.
Maxima has functions for factoring polynomials and other tasks in:
http://maxima.cvs.sourceforge.net/maxima/maxima/src/rat3e.lisp
At the Maxima input prompt, factor(x^2 + 1) should return x^2 + 1.
However in Maxima compiled w/ ECL, it returns 0.
There are functions $RATSIMP which calls FULLRATSIMP which
calls FR1 to do part of the work. In compiled code, $RATSIMP
is called but not FULLRATSIMP. If I define $RATSIMP in the
repl, then FULLRATSIMP is called but not FR1. If FULLRATSIMP
is defined in the interpreter, then FR1 is called. This suggests there
is something amiss in the function calls. It appears that the function
call has been replaced w/ 0 in these cases.

Maybe there is a linking step for ECL which MK:DEFSYSTEM has omitted.

Thanks for your help,

Robert

On 1/13/08, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll@...> wrote:

> In particular one needs reproducible cases. ECL reads perfectly fine
> the symbol ".n." when I type it, how and when does this happen?

Here is a simpler example.

> (defun f (.x.) `((foo) , .x.))
F
> (f 10)
The variable X. is unbound.

HTH

Robert

On 1/13/08, Robert Dodier <robert.dodier@...> wrote:
> > (defun f (.x.) `((foo) , .x.))

It is a problem with the reader macro for  (,) the comma character
inside a quasiquote form. I will look into that.

Juanjo

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com

On 1/13/08, Juan Jose Garcia-Ripoll <jjgarcia@...> wrote:

> That phrase refers to a different process in which one compiles lisp
> files into object files and then links them to form either a big
> unified FASL or a single executable program. MKDEFSYSTEM is compiling
> and loading files one after another, following the rules that the
> system definition establishes.

Does ECL have a function to dump an image? SAVE and SAVE-SYSTEM
are mentioned in ECL src/doc/help.lsp but it appears they are not defined.

There are also C:BUILD-PROGRAM etc which, I guess, have somewhat
the same purpose. Maybe I should try to use those.

best,

Robert

On 1/13/08, Robert Dodier <robert.dodier@...> wrote:
> Does ECL have a function to dump an image? SAVE and SAVE-SYSTEM
> are mentioned in ECL src/doc/help.lsp but it appears they are not defined.
> There are also C:BUILD-PROGRAM etc which, I guess, have somewhat
> the same purpose. Maybe I should try to use those.

ECL no longer provides this dumping mechanism because it is very
difficult to port to different platforms. You can do two things: i)
rewrite the build process so that it no longer uses mkdefsystem and
instead it links object files together or ii) port the system
definition to ASDF and use ECL's mechanism for building a single FASL
file out of it.

Juanjo

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com