[cl-unification-devel] Problems compiling code use #T template
John Leuner
jewel at subvert-the-dominant-paradigm.net
Sun Jun 18 14:38:53 UTC 2006
I tried it on clisp, here it works:
[1]> (asdf:oos 'asdf:load-op 'unification)
; loading system definition
from /usr/share/common-lisp/systems/unification.asd into #<PACKAGE
ASDF7683>
;; Loading file /usr/share/common-lisp/systems/unification.asd ...
; registering #<SYSTEM UNIFICATION #x204892B6> as UNIFICATION
;; Loaded file /usr/share/common-lisp/systems/unification.asd
;; Loading
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/unification-package.fas ...
;; Loaded
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/unification-package.fas
;; Loading
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/variables.fas ...
;; Loaded
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/variables.fas
;; Loading
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/substitutions.fas ...
;; Loaded
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/substitutions.fas
;; Loading
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/lambda-list-parsing.fas ...
;; Loaded
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/lambda-list-parsing.fas
;; Loading
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/templates-hierarchy.fas ...
;; Loaded
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/templates-hierarchy.fas
;; Loading
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/unifier.fas ...
;; Loaded
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/unifier.fas
;; Loading
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/match-block.fas ...
;; Loaded
file /var/cache/common-lisp-controller/1003/clisp/local/home/jewel/.sbcl/site/cl-unification/match-block.fas
0 errors, 0 warnings
NIL
[2]> (compile-file "extra.lisp")
;; Compiling file /home/jbominji/jbominji/extra.lisp ...
;; Wrote file /home/jbominji/jbominji/extra.fas
0 errors, 0 warnings
#P"/home/jbominji/jbominji/extra.fas" ;
NIL ;
NIL
[3]> (load "extra.fas")
;; Loading file extra.fas ...
;; Loaded file extra.fas
T
[4]> (check-recipient)
1 ;
T
where extra.lisp is:
(in-package :cl-user)
(defun check-recipient ()
(unify:find-variable-value '?a (unify:unify #T(list ?a ?b ?c) '(1 2
3))))
So maybe it is an SBCL bug?
John
On Sat, 2006-06-17 at 16:39 +0200, Marco Antoniotti wrote:
> Now that I think about it It may be a problem with the template
> implementation.
>
> Does any other Lisp have the problem other than SBCL? If so I think I
> know what is going on.
>
> Cheers
>
> Marco
>
>
>
>
> On Jun 16, 2006, at 5:51 PM, John Leuner wrote:
>
> > Someone on #lisp told me that it wasn't a problem with the reader
> > macro,
> > at least he said that the problem is that SBCL can't write this object
> > to the fasl file.
> >
> > So I tried it with SBCL without loading SLIME:
> >
> > * (asdf:oos 'asdf:load-op 'unification)
> >
> > ; loading system definition
> > from /home/jbominji/.sbcl/systems/unification.asd
> >
> > * (compile-file "extra.lisp")
> >
> > ; compiling file "/home/jbominji/jbominji/extra.lisp" (written 16 JUN
> > 2006 10:43:55 PM):
> > ; compiling (IN-PACKAGE :CL-USER); in:
> > ; LAMBDA (#:G14 #:G15
> > ; #:G16
> > ; #:G17
> > ; #:G18
> > ; #:G19
> > ; #:G20
> > ; #:G21
> > ; #:G22
> > ; #:G23
> > ; #:G24
> > ; #:G25
> > ; ...)
> > ; (TYPEP SB-PCL::.ARG1. 'CONS)
> > ; --> CONSP
> > ; ==>
> > ; SB-PCL::.ARG1.
> > ;
> > ; note: deleting unreachable code
> >
> > ; (TYPEP SB-PCL::.ARG1. 'SYMBOL)
> > ; --> SYMBOLP
> > ; ==>
> > ; SB-PCL::.ARG1.
> > ;
> > ; note: deleting unreachable code
> > ;
> > ; note: deleting unreachable code
> >
> > ; compiling (DEFUN CHECK-RECIPIENT ...)
> > ; file: /home/jbominji/jbominji/extra.lisp
> > ; in: DEFUN CHECK-RECIPIENT
> > ; (CL.EXT.DACF.UNIFICATION:UNIFY #T(LIST ?A ?B ?C) '(1 2 3))
> > ; ==>
> > ; #T(LIST ?A ?B ?C)
> > ;
> > ; caught ERROR:
> > ; don't know how to dump #T(LIST ?A ?B ?C) (default MAKE-LOAD-FORM
> > method called).
> > ;
> > ; note: The first argument never returns a value.
> >
> > ; '(1 2 3)
> > ;
> > ; note: deleting unreachable code
> > ;
> > ; compilation unit finished
> > ; caught 1 ERROR condition
> > ; printed 5 notes
> >
> >
> > ; /home/jbominji/jbominji/extra.fasl written
> > ; compilation finished in 0:00:01
> > #P"/home/jbominji/jbominji/extra.fasl"
> > T
> >
> > where extra.lisp has:
> >
> > (defun check-recipient ()
> > (unify:find-variable-value '?a (unify:unify #T(list ?a ?b ?c) '(1 2
> > 3))))
> >
> > Does that help? Since coming across this problem I've done some reading
> > about reader macros, it seems simple in principle but I don't
> > understand
> > the relationships between what reader macros are installed at
> > compile-time when compiling which packages etc.
> >
> > John
> >
> >
> > On Fri, 2006-06-16 at 15:33 +0200, Marco Antoniotti wrote:
> >> Hi
> >>
> >> I do not know if this is a problem with CL-UNIFICATION or SLIME. It
> >> seems it is something to do with SLIME. What happened if you try to
> >> COMPILE-FILE the code?
> >>
> >> Cheers
> >> --
> >> Marco
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Jun 14, 2006, at 2:32 PM, John Leuner wrote:
> >>
> >>> When I compile the following code in SBCL (using C-c C-k in Slime),
> >>>
> >>> (in-package :cl-user)
> >>>
> >>> (defun check-recipient ()
> >>> (unify:unify #T(list ?a ?b ?c) '(1 2 3)))
> >>>
> >>> I get this error report:
> >>>
> >>>
> >>> ;
> >>> file: /home/jbominji/jbominji/extra.lisp
> >>> ; in: DEFUN
> >>> CHECK-RECIPIENT
> >>> ; (CL.EXT.DACF.UNIFICATION:UNIFY #T(LIST ?A ?B ?C) '(1 2
> >>> 3))
> >>> ;
> >>> ==>
> >>> ;
> >>> #T(LIST ?A ?B ?C)
> >>> ;
> >>> ; caught
> >>> ERROR:
> >>> ; don't know how to dump #T(LIST ?A ?B ?C) (default MAKE-LOAD-FORM
> >>> method
> >>> called).
> >>> ;
> >>> ; note: The first argument never returns a
> >>> value.
> >>>
> >>> ; '(1 2
> >>> 3)
> >>> ;
> >>> ; note: deleting unreachable
> >>> code
> >>> ;
> >>> ; compilation unit
> >>> finished
> >>> ; caught 1 ERROR
> >>> condition
> >>> ; printed 2
> >>> notes
> >>>
> >>> ; /home/jbominji/jbominji/extra.fasl
> >>> written
> >>> ; compilation finished in
> >>> 0:00:00
> >>> STYLE-WARNING: redefining CHECK-RECIPIENT in DEFUN
> >>>
> >>> This code works when the compiler does not have to write a fasl file.
> >>>
> >>> What should I be doing to allow make-load-form to succeed?
> >>>
> >>> Thanks
> >>> John Leuner
> >>>
> >>>
> >>> _______________________________________________
> >>> cl-unification-devel site list
> >>> cl-unification-devel at common-lisp.net
> >>> http://common-lisp.net/mailman/listinfo/cl-unification-devel
> >>>
> >> --
> >> Marco Antoniotti http://bioinformatics.nyu.edu/~marcoxa
> >> NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
> >> 715 Broadway 10th FL fax. +1 - 212 - 998 3484
> >> New York, NY, 10003, U.S.A.
> >>
> >> _______________________________________________
> >> cl-unification-devel site list
> >> cl-unification-devel at common-lisp.net
> >> http://common-lisp.net/mailman/listinfo/cl-unification-devel
> >
> > _______________________________________________
> > cl-unification-devel site list
> > cl-unification-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/cl-unification-devel
> >
> --
> Marco Antoniotti http://bioinformatics.nyu.edu/~marcoxa
> NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
> 715 Broadway 10th FL fax. +1 - 212 - 998 3484
> New York, NY, 10003, U.S.A.
>
> _______________________________________________
> cl-unification-devel site list
> cl-unification-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cl-unification-devel
More information about the cl-unification-devel
mailing list