RE: [Gcl-devel] Various questions about GCL

[Mike Thomas]

Hi Michael.

 

Thanks for your interest in GCL.

-----Original Message-----

Hi,

 

I'm currently evaluating GCL for use in our internal project. It has some nice features for our

purpose but there are some issues and questions I'd like to ask. I put everything in one mail.

I'd be pleased to get some feedback/comments on these.

 

I'll say what I think and leave this reply open for comments by the others on the list with a better understanding of the issues involved, particularly on ANSI compliance.

 

1) Would it be possible to make GCL embedded into a C library (preferably shared) such that

a 3rd party application could make use of GCL as an embedded computation engine? This

would mean to have an API to initialize/terminate the GCL engine, to convert between C types

and LISP objects, to "eval()" or "funcall()" arbitrary code. Our final target is actually to embed

a LISP engine into a MEX file such that our framework written in LISP can be accessed from

the MATLAB user interface. 

 

As you may have already discovered, GCL is not set up to do this.  My guess is that if compiler::link were to be altered appropriately and the necessary initialise/terminate functions written, it would be possible to produce a "GCL in a box" in the form of a DLL or Unix shared library.

 

I don't know how MATLAB and MEX work, but if the DLL had to be a COM server rather than a simple C based DLL on Windows, then things might (or might not) be much tougher; I have a faint memory that COM servers have to be reentrant.   If COM is needed, you should seriously consider Corman Common Lisp which is supplied as an in-process COM server.

 

2) Is there any FFI framework?

 

Yes, but compared to other functional programming language implementations it is very primitive.  Examples may be seen in the xlib, opengl, JAPI and MPI extensions to GCL.

 

3) (make-hash-table :test #'equalp) is not supported

I'm not an ANSI expert but I assume we will add that if it is part of the spec, or if you really need it.

4) Code like the following does not compile:

(unless (find-package "MYPKG")

  (defpackage "MYPKG" (:use "COMMON-LISP")))

(in-package "MYPKG")

(export 'f1)

(defun f1 (x) (* x x))

 

It complains at "in-package" statement. If I enclose the first 2 top-level forms (unless, in-package)

into an "(eval-when (compile load eval) ...)" form, it compiles but doesn't load (after restarting GCL),

still complaining at "in-package" statement.

(Note: I'm using anonymous CVS version under Linux)

You're probably talking about the warning ";; Warning: The package operation (IN-PACKAGE "MYPKG") was in a bad place." shown below.  This is  a long standing problem and is, I believe something we mean to address during the move towards releasing version 2.7.0:

 

=================================================================

$ /c/lang/gcl-270/bin/gcl
GCL (GNU Common Lisp)  2.7.0 ANSI    Sep 22 2004 15:42:17
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

 

Use (help) to get some basic information on how to use GCL.

 

>(load (compile-file "c:/test.lisp"))

 

Compiling c:/test.lisp.
; (IN-PACKAGE "MYPKG") is being compiled.
;; Warning: The package operation (IN-PACKAGE "MYPKG") was in a bad place.
Error in IN-PACKAGE [or a callee]: A package error occurred on "MYPKG": "No such
 package".

 

Fast links are on: do (use-fast-links nil) for debugging
Broken at IN-PACKAGE.  Type :H for Help.
 1 (Continue)
 2 (SYSTEM:ERROR-SET '(EVAL '(IN-PACKAGE "MYPKG")))
 3 Return to top level.
dbl:>>

=================================================================

 

5) Would GCL compile/work under Win32/MSVC6?

The only Windows compiler routinely supported is MinGW32 gcc.

 

However I did once build with MSVC6, based on alterations to produce a Windows CE GCL and Maxima that someone once did (I think it was GCL version 2.4.3).  I haven't tried this recently but have tried to keep the code in such a state that Visual C could be easily supported as I believe that would be a positive thing for GCL on Windows.

 

I would be pleased to help you if you went ahead and tried this.  I would suggest simply building under MSYS for the convenience of the build system, using the VC6 compiler and linker instead of gcc/ld.  The alternative would be to write nmake compatible makefiles and run under a Windows command prompt, but you would then always be one step behind the main build system.

 

We look forward to hearing further from you and hope we can help you achieve your aims.

 

Cheers

 

Mike Thomas.