Third Brick Wall

Alessio Stalla alessiostalla at
Fri Jul 24 08:36:51 UTC 2020

Lisp lists are not Java List<T> instances. There are some automatic
conversions (e.g., from Lisp numbers to Java numbers) but not for lists or
hash tables. You could invoke Arrays.asList(...) in Lisp as well, I don't
remember the exact syntax to do that as I haven't been using ABCL for years.
Granted, it wouldn't be much work to either have Cons implement
List<LispObject> or provide a cons-backed List<T extends LispObject>
implementation. However, the devil is in the details – how do you convert
those LispObject's to the appropriate Java type? Is it Integer, Long,
Double, ...? Generics are erased at runtime, ABCL couldn't possibly know,
so we'd need another primitive, e.g., (jcoerce-collection collection &key
element-type (collection-type "java.util.ArrayList")). But then one would
have to know about it in order to use it.

ABCL could also do type inference and deduce the type of the elements of
the list from how they're used in the code, e.g., from the call to
parallelize. But 1) it's a lot of work to implement 2) it doesn't solve all
problems, e.g., I guess parallelize is itself generic like <T> List<T>
parallelize(List<T> data) or something like that, in that case, you as a
user would still have to spell a type name.

BTW – it gives me warm fuzzy feelings to read that you see extensible
sequences as a feature worth mentioning. I did the porting from SBCL back
then but it didn't look like it was used much. FWIW, back then I also
integrated CLOS dispatch with the Java class hierarchy – it may have bit
rotted, but you could write, e.g., (defmethod foo ((bar (jclass
"java.lang.List"))) ...) and it would do the "right thing" wrt Java
inheritance. But hey, maybe it's undocumented as well.

On Fri, 24 Jul 2020 at 09:55, Mark Evenson <evenson at> wrote:

> > On Jul 24, 2020, at 05:01, Steven Nunez <steve_nunez at> wrote:
> >
> […]
> >
> > @easye, you mentioned your ember project. If you're going to continue
> with that, please message me. A Spark wrapper would be useful, serve as a
> good exemplar for using ABCL to wrap a large library and, with a companion
> tutorial, help others overcome the kind of obstacles I've encountered. I'd
> be happy to contribute.
> Sorry to hear that you weren’t able to bootstrap your project in time.
> I will definitely continue with Ember to wrap Apache Spark as time permits
> to start crafting the sort of documentation/tutorial that you would have
> needed a week ago…
> --
> "A screaming comes across the sky.  It has happened before but there is
> nothing
> to compare to it now."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the armedbear-devel mailing list