Tagged as lisp
Written on 2014-06-23
This post contains some things I want in Common Lisp, in no particular order. I'll try to keep things short and to the point.
Right now, the concept of a "library" in idiomatic Lisp is a .asd file along with some Lisp source code. I don't always want to distribute the source code. (Though most of the time I do.)
It would be nice if we had both statically and dynamically linkable/loadable libraries like those from C. Of course Lisp's model of how things work doesn't quite match up to this, but I think it could be done if implementations standardized on some loading (and unloading?) strategy.
As far as I know, the closest thing we can do to this is something like concatenating FASL files. But I would like something more robust and semi-standard across implementations.
Lisp isn't too friendly with the outside world. It is difficult to call Lisp code from another application, unless you're using a special implementation. Right now, message passing seems to be the only way to go.
It would be nice if there was some standard interface to call into Lisp with. Maybe even with just other Lisp applications. Something like a calling convention.
I honestly can't recommend Lisp to anyone personally who wants to do graphical programming. There's the commercial LispWorks CAPI which works relatively well, but it comes at a cost.
Right now, all of the existing open source "solutions" are junk. Qt is junk. SDL is marginally better but still junk. Garnet is old and junk. McCLIM is broken and junk (though it's interesting!). Tcl/Tk is antiquated and junk.
This has been the largest pain point for me for writing open source scientific simulation code.
I want to be able to have, for example, a hash table that can specialize efficiently on different types. In Lisp, you essentially either support every type (perhaps with a few restrictions) inefficiently, or you support a single type efficiently.
I don't think there exists a good way to have generic and efficient code reuse right now. All of the polymorphic stuff built in to Lisp is efficient only because the compiler knows about it.
I ranted about this a little bit here.
TYPECASE is not a solution. Inlining is not a solution.
Polymorphic/algebraic/recursive types that the compiler knows about is probably the most difficult thing on this list, since it gets into language semantics.
It would be nice to programmatically specify interfaces/APIs. C has header files. C++ has class declarations. SML has signatures/structures/functors. I would love to in my source code to specify programmatically what is provided.
Packages do not solve this problem. Packages just let us group symbols together. Packages cannot tell the difference between a function, type, class, or variable. Many people still use packages as the way to write an "interface" though. I do, usually with an annotation of what each symbol is. But that isn't very good.
I've tried my hand at some sort of
As an extension, although it doesn't quite fit with the philosophy of generic functions, it would be nice to specify which methods a subclass should implement to really be a subclass of that class. And it would be nice if this was checked statically.
I started working on something at least dynamic many years ago but never finished it. You can find it here.
It would be nice if we could have better static analysis tools for Lisp that aren't baked into a single Lisp compiler. Lisp should be amenable to this, even if the analyzer has to make some bold assumptions about the code.
Whole program optimization, tree shaking, all that would be
nice. There's LispWorks'
mechanism, which has some sophisticated features, but that's about
it. Everyone else just dumps out an image with a little bit of start
up code, and maybe some compression.
Fast start-up times would also be very useful for small, oft-called utilities.
Arbitrary precision floats (including complex floats) would be nice if they were seamlessly integrated into the language compiler/runtime without any performance penalty on other types.
CLISP has this, but that's it. An MPFR interface is in development. (SB-MPFR, Fateman's MPFR interface.) Something portable would be nice. I myself started working on an MPFR interface with CFFI but have little to show. And of course it's not integrated with the rest of Lisp like all of the other numeric functions are.
A standard way of controlling precision would need to be developed. I
think this is a non-trivial problem; simply setting some global
*long-float-precision* might not be good enough.
Lisp has some built-in things to ensure that standard symbols and definitions are not screwed around with. It would be nice if implementations had some options to protect the current state of the Lisp image from being destructively modified in certain ways. It would also be nice if some operations were reversible, such as unloading a library or cleanly removing the existence of a package (and ensuring it gets cleaned up from memory).
It would be nice if there existed efficient class-wide finalizers, so
there could be smoother integration with C stuff. If a Lisp object
gets deallocated, then the corresponding C stuff gets
well. (Of course, this should be programmed by the programmer, not
some special construct.)
allows one to set finalizers on individual Lisp objects, and of course
we can set a finalizer for every object allocated by a class easily.
I don't know if it would be right to bake TCE into the standard
itself, but it would be nice if I could turn it on and off via some
Some implementations of course do some TCE with the right compiler policy, but more granularity and less "you get TCE and the kitchen sink of optimizations" would be nice.