Trying to port code from the JVM to GCJ is not straightforward. Porting code between implementations that meet the Java standard, however is straightforward. P

Trying to port code from the JVM to GCJ is not straightforward. Porting code between implementations that meet the Java standard, however is straightforward. Porting code between Common Lisp implementations that meet the ANSII specification isn't. If you prefer property lists, then forget about alists if you want. But really, a lisp in which you couldn't make an alist would seem awkward and irregular to me. It's not that hash tables, alists, and plists are redundant, (they aren't) but that they're too different. Hash tables are efficient, alists holds any kind of association and allows you to go both ways, and plists map right into argument key-lists. Each has an advantage the others can't easily duplicate. But, they hold very similar, and sometimes overlapping kinds of data. It's trivial to write one, but there should be an established interface for converting between types as needed as well as one for using them. I should be able to pass a piece code a map of any sort, and expect the code to be able to handle it so long as it doesn't need to do anything particular to a specific kind of map. A single method, get-value, should be able to dispatch based on whether or not a data structure is a hash-table, etc and fetch the key/value pair requested. Ideally you'd be able to do this with methods, but because alists and plist are of the same type, this isn't really possible, which leads into the un-uniformity of the object-orientation. On the rare occasion that I want to implement something like a new type of sequence It's not so much about implementing new kinds of sequences by about polymorphically extending the kinds that already exist. Both alists and plists are of the type 'list,' but they should be of the type 'alist,' and 'plist,' each of which a subtype of both 'list' and a generic 'map' class. This would make it much easier to design and extend a consistent interface across similar data-structures. I've wanted for this ability before, attempting to design methods to instantiate objects that would either clone an object passed it, or accept a plist, hash-table, alist, and use the values listed to initialize the slots. I was able to do it, but my solution was significantly less clean that it should have been.