Greetings,
I am having a lot of trouble building Eu2C and am hoping I can solicit
some help. Eu2C is an EuLisp compiler written in Common Lisp. I assume
it used to work fine but is woefully out of date with current Common
Lisp standards.
I am using CLISP on Linux. I haven't done virtually anything because I
can't seem to get past one (probably simple) problem. I have used lisp
on-and-off for over 25 years but I have never written anything
significant in Common Lisp.
My hope is to get the code up-to-date, port it to CLISP, SBCL, etc.,
write some docs and make it available on the net. Your help would be
greatly appreciated.
I got to the problem pretty early in the boot loading process. I spent
about 10 hours on it but I am totally lost. One problem is that part of
the system is written in Common Lisp and part of it is in EuLisp. Once
it loads sufficient amount of Common Lisp it starts loading the EuLisp
code. The problem point seems to be when it starts to load the EuLisp
code. It seems to be trying to interpret it as Common Lisp. I think
the program is reading in the EuLisp code and instead of passing it to
the EuLisp processor (written in Common Lisp), it is just passing it
directly to Common Lisp.
Anyway, the code is available at:
http://blake.mcbride.name/Eu2C.tar.gz
What I am doing once it is unpacked is:
export Eu2CROOT=`pwd`
clisp
(load "Apply/boot1.eu2c")
I believe that someone very familiar with Common Lisp and CLOS would
find this a trivial issue. I am hoping I can find someone to work on
this with me (or get me past this point at the very least).
Your help is greatly appreciated.
Blake McBride
·····@mcbride.name
On Dec 29, 10:39 am, Blake McBride <·····@mcbride.name> wrote:
> I am having a lot of trouble building Eu2C and am hoping I can solicit
> some help. Eu2C is an EuLisp compiler written in Common Lisp. I assume
> it used to work fine but is woefully out of date with current Common
> Lisp standards.
[[ ...some stuff moved downwards... ]]
> export Eu2CROOT=`pwd`
> clisp
> (load "Apply/boot1.eu2c")
>
Hello!
Thanks for resurrecting all these olds Lisps -- they are very cool.
I've downloaded your code collection. I didn't find any README's or
other docs, except for a EuLisp manual. I tried the same steps you
described, also with clisp, and got as far as:
DEFGENERIC COMPARE-GENERIC::BINARY<: invalid generic function lambda-
list: Invalid lambda list element (N1 <OBJECT>)
[Condition of type SYSTEM::SIMPLE-SOURCE-PROGRAM-ERROR]
The culprit, in compare-generic.em, is
(defgeneric binary< ((n1 <object>) (n2 <object>)))
(defgeneric binary= ((n1 <number>) (n2 <number>)))
// OK: I was wrong. This is here just for the info, to provide context
// Generic functions in CL do not take specialisers. I see that
10.4.1.2
// in the enclosed manual (EuLisp-0.99.ps) says this:
//
// "gen-lambda-list: The parameter list of the generic function, which
// may be specialized to restrict the domain of methods to be attached
to
// the generic function."
//
// Does any CLOS/MOPers know how we can fix cl:defgeneric to take
// specialisers? A short term workaround is to simply delete those
// specialisers from the EuLisp code.
The defgeneric forms are actually calling eulisp-kernel::defgeneric
(not cl:defgeneric, or actually, in clisp, clos::defgeneric. Man,
gotta watch out for the symbol package when debugging this stuff.)
which converts the EuLisp lambda-list to CL generic lambda-lists and
pass them onto cl:defgeneric.
There is a bug here, and the equivalent "short term solution"
mentioned above is to modify eulisp-kernel::defgeneric from
(cl:defmacro defgeneric (name lambda-list)
`(cl:defgeneric ,name ,(make-cl-lambda-list lambda-list)))
to
(cl:defmacro defgeneric (name lambda-list)
`(cl:defgeneric ,name ,(make-cl-generic-fun-lambda-list lambda-list)))
(cl:defun make-cl-generic-fun-lambda-list (el-lambda-list)
(cl:mapcar (cl:lambda (arg) (cl:if (cl:listp arg) (cl:car arg) arg))
(make-cl-lambda-list el-lambda-list)))
removing all specialisers (yeah, I know, what's up with the weird
indentations). Maybe the proper equivalent is to macro expand to
something like
(defgeneric name (arg1 arg2)
(:method ((arg1 t) (arg2 t))
(error "Generic function is restricted to (~{~a~^, ~})"
specialisers))
(:method ((arg1 specialiser1) (arg2 specialiser2))
(error "Generic function is unimplemented, but supported for
(~{~a~^, ~})." specialisers)))
Next bunch of errors:
FIND-CLASS: DOUBLE-FLOAT does not name a class
or something like
FIND-CLASS: FIXNUM does not name a class
In clisp, the classes FLOAT and INTEGER can be used instead. c.l.l can
pipe up here on what BUILT-IN classes can be found in various
implementations today.
The code to fix this is already there, so simply add :clisp to
conditionalise the code to run. A more general CL portable solution
might be required especially if you start porting to the other Lisps.
eg: Eu2C/EulispModules/double.em
#-(or :cmu (and :ALLEGRO :FRANZ-INC) :clisp)
(make-eulisp-class double-float)
#+(or :cmu (and :ALLEGRO :FRANZ-INC) :clisp)
(make-eulisp-class double-float float)
In places, I also added the appropriate import module declarations.
#module spint
import
#+:clisp
(only (find-class class-name) clos)
There's more errors, but that's what I've seen so far. This is
probably a good place to take it off-list, if you have anymore
queries.
> I got to the problem pretty early in the boot loading process. I spent
> about 10 hours on it but I am totally lost. One problem is that part of
> the system is written in Common Lisp and part of it is in EuLisp. Once
> it loads sufficient amount of Common Lisp it starts loading the EuLisp
> code. The problem point seems to be when it starts to load the EuLisp
> code. It seems to be trying to interpret it as Common Lisp. I think
> the program is reading in the EuLisp code and instead of passing it to
> the EuLisp processor (written in Common Lisp), it is just passing it
> directly to Common Lisp.
So far, I've only seen CL code. Most of the EuLisp constructs are
mapped into CL constructs and cl:load'ed. Eg, there's a reader macro
#module (or anything that starts with #m) for reading in modules with
proper treatment of symbol packages. But I also saw some files (still
haven't met them during loading) with similar looking (defmodule ...)
forms, which CL probably cannot read directly (due to the symbol
package management). Most of this stuff I picked up in
EulispModules/el-modules.lisp
Is this a translater to C? There seem to be a C runtime as well in
ApplyC. It would be cool to have a EuLisp interpreter/compiler inside
Common-Lisp, if that is what this is (looks like it). Cheers, good
luck, and happy translating!