This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GSOC | Extending Common Lisp support


On 06/26/2012 01:31 PM, Charles Turner wrote:
I'm looking to do the various DO-ALL-SYMBOLS iterators, I'm not
planning on implementing them just yet, but require a first order
approximation to them in Java. I'd like a LList or maybe an iterator
over the symbol table in Namespace. I could go ahead and use
LocationEnumeration#nextLocation() as a template to build a
list/iterator for Namespace, but I'm wondering is that the recommenced
way? It would be nice to wrap Namespace#table up in something like a
LocationEnumeration, but I'm not sure if such a class would have much
use outside of the DO-*-SYMOLS iterators. It appears a bit tricky to
do this properly due to the layout of hash table in Namespace, it
kinda irks me that we have custom hash tables all over the place in
Kawa and I can't just call table.elements(), but I understand that
Kawa has good reason to do it this way (efficiency avoiding lots of
object allocations typically). Maybe there's an abstraction to be had
here?

Perhaps we should re-implement Namespace so it extends AbstractHashTable<SymbolRef, String, Symbol>. In that case SymbolRef would have to extend Map.Entry<String,Symbol>.

I'm looking into this.

Some of the performance benefits of custom classes are probably not worth it.
Note that Namespace and Simplementnvironment (which could perhaps
also use AbstractHashTable) predate AbstractHashTable.
--
--Per Bothner
per@bothner.com http://per.bothner.com/




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]