Google Summer of Code (GSoC) 2017

Below, you'll find a list of projects that we - the ABCL project community - came up with. These projects (or parts thereof) can be completed in a summer and would really help the project leap forward.

After assembling the proposals here, we need to liase with ​http://lispnyc.org/soc.

Testing framework for DEFINE-METHOD-COMBINATION (D-M-C, the long form)

During the 0.23 development cycle, experimental support for the long form of D-M-C has been added. However, in order to improve the quality of the implementation, tests need to be designed and implemented. If the project leaves time, optionally with fixes to the implementation that we currently have. SBCL's tests may serve as a good basis, but aren't suitable in a copy/paste manner, because their tests aren't RT based, while ABCL's are.

Metaclasses for generic functions

During the development cycle of 0.19, support for the :metaclass DEFCLASS option has been added to ABCL's CLOS. However, DEFCLASS isn't the only CLOS macro which requires support for that option: DEFGENERIC does too.

Difficulty of this project may be that generic functions are based on the FUNCALLABLE-INSTANCE class, for which some investigating may be required to determine if its supports is up to the task of implementing generic functions with non-standard metaclasses.

Make LispObject a Java interface

Make LispObject a Java interface, as God and Gosling intended. LispObject should be a union of superinterfaces (like HasPrintableRepresentation, HasNumericTower) for which the current code is abstracted into common implementations. Patches exist for some of from previous version. This project would first study that code, decide whether to bring those changes forward to abcl trunk or start from scratch, provide the implementation as a pluggable alternative to the current one, benchmark the differences, and write up the result in a short paper.

Just doing the above makes a nice summer project, but there is much more that could be done regarding portability , such as providing an implementation of LispObject that will work on .NET 9via IKBM) or Dalvik. Or Java7 with InvokeDynamic?. Or ...?

Port to Dalvik

First get the ABCL interpreter booted on Dalvik. Then, modify our complier to emit Dalvik bytecode.

Improve Java interoperability

Looking at the best ideas from ABCL's JAVA package and ​Alan Ruttenberg's JSS package while studying the best patterns from Clojure, design and implement an interface possibly using macros, auto-magic PACKAGE import, and other standard language extension features that allow Java developers to easily use ABCL but has solid Common Lisp foundations.

Implement a better debugging facility

ABCL could use a facility to inspect the current Lisp stack frame as well as maintaining better correspondence between compiled and source code. The ultimate goal would be the ability to single step through Lisp programs.

Improve Google App Engine/Java? integration

ABCL currently runs on GAE/J but startup times are a little too slow to handle user-facing UX code via ABCL from a cold start. GAE has a task abstraction that could be useful to synchronize requests with longer-lived "persistent" ABCL processes. Or the startup time could be improved.