6 | | 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. |
| 6 | LispObject should be a union of superinterfaces (like HasPrintableRepresentation, HasNumericTower, etc.) for which the current code is abstracted into common implementations. Patches exist for some of this from [http://code.google.com/p/uabcl/source/browse/trunk/src/org/armedbear/lisp/LispObject.java an earlier version of ABCL]. 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. |
15 | | easye: I don't think that a |
16 | | unitary LispObject interface is a good idea: I'd |
17 | | rathe see LispObject be union of interfaces |
18 | | (HasPrintableForm, HasNumericTower, etc.) And |
19 | | provide a polished set of AbstractLispObjects |
20 | | (AbstractJavaLispObject, etc.) to work with. |
| 15 | easye: I don't think that a |
| 16 | unitary LispObject interface is a good idea: I'd |
| 17 | rather see LispObject be union of interfaces |
| 18 | (HasPrintableForm, HasNumericTower, etc.) And |
| 19 | provide a polished set of AbstractLispObjects |
| 20 | (AbstractJavaLispObject, etc.) to work with. |