[Ecls-list] ecl.dll dynamic loading

[Matthew Mondor]

On Thu, 31 May 2012 23:57:11 +0400
red plait <redplait at gmail.com> wrote:

> It seems that under xp (both 32 and 64 bit) elc.dll cannot be loaded
> with LoadLibrary: http://redplait.blogspot.com/2012/05/ecldll.html
> I think __declspec(thread) for GC_thread_key must be rewritten to use
> explicit TLS allocation scheme to solve this problem

I didn't know about your blog, but after reading the article
``"embeddable" cl'' I agree with Juan that it appears to be an unfair
evaluation.  Although a few issues might be directly ECL related, most
didn't seem to be related to ECL...

The "famous REPL" is probably SLIME, or simply the general fact that
Lisp is designed to support live interactive development.

About the debugger, SLIME also improves things there, and is used by
most lispers.  Lisp also allows you to hook in your own debugger if you
cared to, it's a standard feature of the language to allow this, ECL is
no different, and SLIME exploits this feature.  If you compile to C,
you also have access to the C debugger of your implementation.  You
even have access to the C generated source if you use
(setf c::*delete-files* nil) before building your project.
It's possible that the bytecode be more easy to debug using the native
debugger than C-compiled code.

I know of no implementation including CFFI, most either provide UFFI or
their own more specialized FFI implementation, such as ECL which
supports both UFFI natively and directly embedded C code elegantly (ECL
deserves its name here, BTW, see the symbols of the FFI and C
packages, and the documentation on the web site).  Or install CFFI and
its dependencies.  ECL can also build decently sized final executables
or libraries, one of its strong points (also doing its name justice).
Other than being embeddable in a C/C++ application.

Quicklisp is one of the attempts at providing easily installable third
party software.  It's not part of the implementations that I know, but
is third party software.  Note that unlike Ruby or Perl, Common Lisp is
a standard, like C, with multiple implementations.  A lot of in-house
software is closed source or implementation-dependent, and the language
is powerful enough to allow quick development of custom libraries.  A
fraction of libraries were developed to be portable accross
implementations and publically distributable, and it is more work
involved for a small community to include every wanted feature in
portable, easy to install libraries, in a common repository, as the
community is fragmented accross both implementations and ideology.
Over time, however, the collection grows and with a tool like Quicklisp
it might get closer.  And even if Quicklisp exists, not all lispers use
it, it's not a standard.  The aforementionned SLIME is also not a
standard, and some commercial Lisp implementations offer sophisticated
GUI IDEs.

Registry access and OLE automation and VS integration?  You seem to be
looking for .Net or an implementation that depends on it, or for a
commercial implementation with particularily good Windows support.
Although you might want to consider Clojure or ABCL, if some Java
implementation has already what you need (I hear that there's an effort
to support the .Net common runtime for Clojure too).

For all these Windows integration features, there has to be a decent
financial incentive.  As far as I know, this is neither a commercial
project with the funds and workforce necessary, nor a Windows-centric
implementation, although there is effort to support Windows for the
basic features ECL provides, like threads, sockets and unicode which are
expected in a modern Lisp implementation (these are not even part of
the standard requirements).  Also, ECL attempts to be easily portable,
and most OS-specific extra functionality it could include would not be
portable elsewhere (there is POSIX for that, yet Windows requires extra
software to comply, and POSIX has no notion of those Windows features).
Registry access and OLE are exemples of features that wouldn't benefit
ECL on other systems, and are best provided as contribution libraries.
Consider ECL as a building block, not a panacea.

Although I decided to reply, I won't keep on debating after this post
(or reading the blog, not particularily yours, there are very few I
track), but I thought that the necessary minutes of my time to type
this might perhaps be worth it, assuming all you needed were clues to
find what you need.  If you already knew all of the above, please
accept my apologies, but it was not evident from what I read.  It's also
possible that ECL (or Lisp) is not what you need, it'll be for you to
decide.

Note that I don't officially represent the project and am only one of
its users.

As such, Juan, please feel free to correct my claims as needed :)
-- 
Matt