The Embeddable Common Lisp (2005) [pdf] | Hacker News Reader

The Embeddable Common Lisp (2005) [pdf]

ecl.common-lisp.dev

42 pointsandsoitis24 comments

Hey, I'm one of ECL maintainers. If you have some questions I'll be glad to answer.

Thanks for your work! Question: are there any projects you know of where people use ECL compiled to Apple’s M1/M2 and used as a library with Swift and SwiftUI? I experimented with LispWorks for macOS and it was fairly nice for building Mac apps, but I had issues getting an app accepted by the Apple Store (probably my fault).

EDIT: other people and companies had LispWorks apps accepted by the Apple Store

I know that ECL works on Apple M1 and otherwise, as of Swift - no idea. LQML / EQL5 created by Paul Ruetz is a very cool project that works on iphone, android and such with appealing graphical inteface. It is basically ECL embedded in QT.

If I recall correctly Paul has a few applications in the Apple Store, but you'd need to ask him directly to confirm that.

Is it possible to compile to native in a fully static binary?

By default, ECL seems to link with a libecl (or something like that) shared object. If I compile with “--disable-shared”, it seems to also remove the “compile to native” part. Or at least that’s how it appeared to me.

It’s possible I’m misunderstanding, but it I didn’t see why those two aspects (static binary and native/non-byte code) are coupled. Again, apologies if I’m just misinterpreting!

Edit: my motivation is I have some small utilities that I’d like to be able to just copy to any Linux box (even musl libc-based Alpine) and have them work, regardless of glibc/ECL being present.

The short answer is no - ECL links against the libc present on the system. It is not that it could not be improved in this regard.

Even when you compile with "--disable-shared" you'll link against libc (but everything else will be statically linked). The function "--disable-shared" does not remove the compiler to native, it removes compilation of fasls to native. The reason for that is this:

- "native" fasls are shared objects under disguise linked against libecl (dlopen)

- they can't not link against libecl unless you want to statically link whole ecl with the fasl

Imagine that you call a PRINT function from the FASL. The symbol you will probably reference is ecl_print that is defined in ECL core runtime (usually in libecl.so, libecl.a/static-ecl).

The native compiler still can produce statically linked native binaries.

Now I'll get into current ECL developments - mind that this is not granted that this pan out as expected - perhaps I'll scrap whole work at some point:

I'm refactoring ECL compiler to have multiple frontends and backends (something like LLVM) - currently passes are far more coupled. With that I hope to have a better control over a generated code and we could use static analysis about which parts of CL are used, and in an opt-in manner we could allow minimal static builds that do not depend on full CL. Such static binaries could be really small.

As far as libc, I should have clarified that I meant linking with musl libc, which can in fact be linked in statically, unlike glibc. So that part is not a problem for me.

As for the FASL compilation part, it sounds like I did indeed misunderstand the documentation, but I’ll need to digest your comment a bit more :)

Thanks!

I think that you'd need to tinker a little with ECL makefile to adjust flags in order to enable static linking. That said ECL does work with musl libc, so at least from the porting perspective there should not be any problem.

If you manage to link musl libc statically then I'd greatly appreciate if you share your experience on our issue tracker or on irc (#ecl @ libera.chat), and if you have problems with it, you may ask in either for advice.

> If you have some questions I'll be glad to answer.

What is the main difference between ECL and GCL?

Both ECL and GCL are descendants of Kyoto Common Lisp. That said ECL (generally speaking) is a complete as ANSI Common Lisp implementation[1], has more "man years" under its belt, has active community, better support across platform, is recognized by Common Lisp developers and has more "man years" under its belt.

[1] One of current GCL goals is to reach it

Is anyone using ECL in their projects? https://ecl.common-lisp.dev/main.html

What do you love it about it? What do you wish was better or different?

I would like to use it to produce fully static executables for simple utilities written in Common Lisp, but I haven’t successfully gotten it to work yet. Basically, in any case where a 50 MB SBCL binary would be overkill (eg performance is not critical and portability is the top concern).

I’ve also read elsewhere that ECL runs on OpenBSD, where other CLs have traditionally not been fully featured.

Edit: also seems like it could help with compiling to WebAssembly (again, when performance is not critical), although I think their work there is not complete yet.

If you are willing to use somewhat older version of SBCL (2.1.11) then you can use daewok's static executable branch and link against musl. That version only supports gzipped images, but even so you can get it down under 15mb for small programs.

Yes, thanks, I forgot to mention that as an option. I’d like a solution that doesn’t involve patching SBCL, but I’ve been following that project and it’s exciting!

There is also http://ciel-lang.org/#/scripting for scripting in Common Lisp (similar to Janet)

I had not run across this. Thanks!

Looks like this doesn't support musl libc-based distributions? Also, it seems to require an account to download, which seems odd.

Hey! Emscripten port works (it will be merged somewhere soon, and we anticipate a release later this year), the next thing to target is "pure" WASI. Yes, ECL runs fine on OpenBSD (as well as on Windows, Linux, other BSD, haiku, iphone, android and - in a branch - wasm).

That’s awesome news!

Has anyone gotten cl-sdl2 to work with ECL? I'm trying to load it via quicklisp via "(ql:quickload :sdl2)" on my mac m1 for starters, but I get the following:

https://pastebin.com/1nq1gqLQ

SDL2 is installed to /opt/homebrew/lib/libSDL2.dylib but I've never really learned how to work with cffi in common lisp for different architectures other than to search github issues and pray

No idea, but when you build C projects you have to tell the compiler/linker where to look for the library with sdl2-config:

https://manpages.ubuntu.com/manpages/jammy/man1/sdl2-config.....

Have you tried that?

I can build projects using sdl2 in C with sdl2-config, or using cl-sdl2 with SBCL by following some steps I found online to fix macbook m1 quirks (see below).

Right now I’m trying and failing to load cl-sdl2 it from an ECL repl- I’m not sure how sdl2-config would be used in that situation. ECL is installed via homebrew but I’m not really sure how it’s configured to look for C libraries for cffi or how I should tell it where to look.

https://github.com/lispgames/cl-sdl2/issues/154#issuecomment...

Try pointing one of the environment variables mentioned here to your installation of SDL2 before launching ECL:

https://developer.apple.com/library/archive/documentation/De...

    LD_LIBRARY_PATH
    DYLD_LIBRARY_PATH
    DYLD_FALLBACK_LIBRARY_PATH

I don’t know if there’s a way to do that from within ECL.

Thank you! That got me past the error and on to the next one. :)

I'd start by trying to add all the different paths to

  cffi:*foreign-library-directories*
  cffi:*darwin-framework-directories*

and if that doesn't work for whatever reason, patching the library definition in cl-sdl2 https://raw.githubusercontent.com/lispgames/cl-sdl2/main/src...

Reply on news.ycombinator.com