Dear all,
I'm trying to get Aldor (a compiler that's able to compile Aldor code to lisp)
work together with sbcl-based FriCAS (a fork of axiom, a computer algebra
system).
The current state is that this works well with gcl. However, I'd like to
support several lisp implementations.
The first problem I hit is that aldor produces in-package calls like
(in-package "FOAM-USER" :use '("FOAM" "LISP"))
and it seems that they are not ANSI. The gcl doc says:
-------------------------------------------------------------------------------
Function: IN-PACKAGE (package-name &key (nicknames nil) (use '(lisp)))
Package:LISP
Sets *PACKAGE* to the package with PACKAGE-NAME, creating the package if it
does not exist. If the package already exists then it is modified to agree with
USE and NICKNAMES arguments. Any new nicknames are added without removing any
old ones not specified. If any package in the USE list is not currently used,
then it is added to the use list.
-------------------------------------------------------------------------------
I know very little about lisp, so I'm unable to produce a ANSI Common Lisp
replacement with the above semantics. Of course, I do not know either whether
this would help, there might be some other cltl specific things later on, I'm
afraid. Still, I'd like to try it. Help?
Martin
Martin Rubey <········@yahoo.de> writes:
> The first problem I hit is that aldor produces in-package calls like
>
> (in-package "FOAM-USER" :use '("FOAM" "LISP"))
>
> and it seems that they are not ANSI.
The modern equivalent is:
(defpackage "FOAM-USER" (:use "FOAM" "CL"))
(in-package "FOAM-USER")
http://www.lispworks.com/documentation/HyperSpec/Issues/iss195_w.htm has
some details about why it changed.
Zach
Zach Beane <····@xach.com> writes:
> Martin Rubey <········@yahoo.de> writes:
>
> > The first problem I hit is that aldor produces in-package calls like
> >
> > (in-package "FOAM-USER" :use '("FOAM" "LISP"))
> >
> > and it seems that they are not ANSI.
>
> The modern equivalent is:
>
> (defpackage "FOAM-USER" (:use "FOAM" "CL"))
> (in-package "FOAM-USER")
>
> http://www.lispworks.com/documentation/HyperSpec/Issues/iss195_w.htm has
> some details about why it changed.
Thank you. I tried to write a macro that makes in-package understand the three
argument form, but I was unable to:
(defmacro in-package (s &rest l) (common-lisp:in-package s))
produces an infinite loop... (unfortunately, I cannot easily modify the
in-package call (in-package "FOAM-USER" :use '("FOAM" "LISP")), since it is
generated by a compiler I do not control)
many thanks in advance,
Martin
Martin Rubey <········@yahoo.de> writes:
>> Thank you. I tried to write a macro that makes in-package understand the three
> argument form, but I was unable to:
>
> (defmacro in-package (s &rest l) (common-lisp:in-package s))
>
> produces an infinite loop... (unfortunately, I cannot easily modify the
> in-package call (in-package "FOAM-USER" :use '("FOAM" "LISP")), since it is
> generated by a compiler I do not control)
Did you remember to shadow IN-PACKAGE first?
Without shadowing the in-package symbol, you will likely (at least if
your package :USEs the COMMON-LISP package have
(eq 'in-package 'common-lisp:in-package)
which would, of course, explain the infinite loop....
--
Thomas A. Russ, USC/Information Sciences Institute
My suggestion: if you can fix the problem and do not work around it.
Get to the "compiler" part that generates the guilty IN-PACKAGEs and
fix them.
Cheers
--
Marco
On May 9, 3:14 pm, Martin Rubey <········@yahoo.de> wrote:
> Zach Beane <····@xach.com> writes:
> > Martin Rubey <········@yahoo.de> writes:
>
> > > The first problem I hit is that aldor produces in-package calls like
>
> > > (in-package "FOAM-USER" :use '("FOAM" "LISP"))
>
> > > and it seems that they are not ANSI.
>
> > The modern equivalent is:
>
> > (defpackage "FOAM-USER" (:use "FOAM" "CL"))
> > (in-package "FOAM-USER")
>
> >http://www.lispworks.com/documentation/HyperSpec/Issues/iss195_w.htmhas
> > some details about why it changed.
>
> Thank you. I tried to write a macro that makes in-package understand the three
> argument form, but I was unable to:
>
> (defmacro in-package (s &rest l) (common-lisp:in-package s))
>
> produces an infinite loop... (unfortunately, I cannot easily modify the
> in-package call (in-package "FOAM-USER" :use '("FOAM" "LISP")), since it is
> generated by a compiler I do not control)
>
> many thanks in advance,
>
> Martin
Marco Antoniotti <·······@gmail.com> writes:
> My suggestion: if you can fix the problem and do not work around it. Get to
> the "compiler" part that generates the guilty IN-PACKAGEs and fix them.
Well, the problem is that this requires everybody to update. Since the
workaround is easy
(defpackage "BOOT" (:use "VMLISP" "FRICAS-LISP") (:shadow "IN-PACKAGE"))
;; Aldor 1.1.0 produces in-package statements with :use options. These can be
;; ignored, so we do not use
;; (defpackage package options)
;; (in-package package)
(in-package "BOOT")
(defmacro IN-PACKAGE (package &rest options)
`(COMMON-LISP:IN-PACKAGE ,package))
I'll require an updated aldor only later, when other things change, too.
Thanks for helping, in any case.
Martin
On May 10, 6:49 pm, Martin Rubey <········@yahoo.de> wrote:
> Marco Antoniotti <·······@gmail.com> writes:
> > My suggestion: if you can fix the problem and do not work around it. Get to
> > the "compiler" part that generates the guilty IN-PACKAGEs and fix them.
>
> Well, the problem is that this requires everybody to update.
Yes. But let's see the full meaning of "update". You actually mean:
"this requires everybody to update to the 'correct' (as in ANSI)
working definition of IN-PACKAGE". There is value in that.
Cheers
--
Marco
> Since the
> workaround is easy
>
> (defpackage "BOOT" (:use "VMLISP" "FRICAS-LISP") (:shadow "IN-PACKAGE"))
> ;; Aldor 1.1.0 produces in-package statements with :use options. These can be
> ;; ignored, so we do not use
> ;; (defpackage package options)
> ;; (in-package package)
> (in-package "BOOT")
> (defmacro IN-PACKAGE (package &rest options)
> `(COMMON-LISP:IN-PACKAGE ,package))
>
> I'll require an updated aldor only later, when other things change, too.
>
> Thanks for helping, in any case.
>
> Martin