A Collections Framework?
in [Lisp]
|
Prev: scheme problem
Next: lisp student job offer
From: Norbert_Paul on 12 May 2010 02:41 samantha wrote: > In what way do CL generic functions and CLOS fail to be many times > more powerful and better at expressing interfaces than Java > interfaces? Well it might be the case, theat they are only less than two times more powerful, say, 1.999? Then it would be less than "many" times. This, however, should be precicely measured. Note that there is a difference between generic functions in LISP and abstract methods in Java. However, to make clear what I meant in my initial post: I did not question LISP's power to express these tings. I rather wanted to know if someone had already made use of this power, and, in particular, if this had even resulted in some agreed standard. Norbert
From: Norbert_Paul on 12 May 2010 03:00 Alessio Stalla wrote: > Suppose I want to add a new method called "cons" which, when called on > a Collection C and an object O, will return a new Collection with O > appended in front of C. What would the signature of that method be? > > Collection.cons(T obj) : Collection -> loses type information, needs a > cast (e.g. to ImmutableLinkedList), also casts in Java are dynamic > type checks so an inefficiency (though small) is introduced If you used generics there are less type casts. Most generic type information is only for the compiler and will be erased at run time. > Collection<COLLTYPE>.cons(T obj) : COLLTYPE -> ugly, every concrete > collection class C must implement Collection<C> This is against the API. > <COLLTYPE> Collection.cons(T obj) : COLLTYPE -> probably the best, > it's unsafe (caller decides the type), but we're Lispers so we don't > care ;) - but fits badly with the rest of Java > > others? I can't come up with any. I had made my own static <T> Collection<T> disjointUnion(Collection<T> head, Collection<T> tail); which is iterated head first and then tail, and then could do disjointUnion(singletonSet(obj),c);
From: Alessio Stalla on 12 May 2010 03:29 On May 12, 9:00 am, Norbert_Paul <norbertpauls_spam...(a)yahoo.com> wrote: > Alessio Stalla wrote: > > Suppose I want to add a new method called "cons" which, when called on > > a Collection C and an object O, will return a new Collection with O > > appended in front of C. What would the signature of that method be? > > > Collection.cons(T obj) : Collection -> loses type information, needs a > > cast (e.g. to ImmutableLinkedList), also casts in Java are dynamic > > type checks so an inefficiency (though small) is introduced > > If you used generics there are less type casts. Most generic type > information is only for the compiler and will be erased at run time. I'm not talking about generics here but concrete Collection subclasses which I may want to use if I want to leverage some specific methods. > > Collection<COLLTYPE>.cons(T obj) : COLLTYPE -> ugly, every concrete > > collection class C must implement Collection<C> > > This is against the API. I was imprecise: that was supposed to read Collection<COLLTYPE, T> and C<T> implements Collection<C, T>. > > > <COLLTYPE> Collection.cons(T obj) : COLLTYPE -> probably the best, > > it's unsafe (caller decides the type), but we're Lispers so we don't > > care ;) - but fits badly with the rest of Java > > > others? I can't come up with any. > > I had made my own > > static <T> Collection<T> disjointUnion(Collection<T> head, Collection<T> tail); > > which is iterated head first and then tail, and then could do > > disjointUnion(singletonSet(obj),c); That's nice, but it has two problems that make it not suitable to be a general purpose API, imho: 1. it cannot be specialized on a per-class basis; if a certain Collection can implement disjointUnion more efficiently, you have to make it a separate overload and resolve it statically rather than using late binding. 2. it loses type information: if I'm using LinkedLists, that method will return Collection, and I'll have to cast to LinkedList if I want to use some LinkedList-specific method. Of course if that was Lisp and not Java, neither of the two problems would be there ;) Alessio
From: Alan Malloy on 12 May 2010 13:43 Alessio Stalla wrote: > On May 12, 9:00 am, Norbert_Paul <norbertpauls_spam...(a)yahoo.com> > wrote: >> Alessio Stalla wrote: >>> Suppose I want to add a new method called "cons" which, when called on >>> a Collection C and an object O, will return a new Collection with O >>> appended in front of C. What would the signature of that method be? >>> Collection.cons(T obj) : Collection -> loses type information, needs a >>> cast (e.g. to ImmutableLinkedList), also casts in Java are dynamic >>> type checks so an inefficiency (though small) is introduced >> If you used generics there are less type casts. Most generic type >> information is only for the compiler and will be erased at run time. > > I'm not talking about generics here but concrete Collection subclasses > which I may want to use if I want to leverage some specific methods. > >>> Collection<COLLTYPE>.cons(T obj) : COLLTYPE -> ugly, every concrete >>> collection class C must implement Collection<C> >> This is against the API. > > I was imprecise: that was supposed to read Collection<COLLTYPE, T> and > C<T> implements Collection<C, T>. > >>> <COLLTYPE> Collection.cons(T obj) : COLLTYPE -> probably the best, >>> it's unsafe (caller decides the type), but we're Lispers so we don't >>> care ;) - but fits badly with the rest of Java >>> others? I can't come up with any. >> I had made my own >> >> static <T> Collection<T> disjointUnion(Collection<T> head, Collection<T> tail); >> >> which is iterated head first and then tail, and then could do >> >> disjointUnion(singletonSet(obj),c); > > That's nice, but it has two problems that make it not suitable to be a > general purpose API, imho: > > 1. it cannot be specialized on a per-class basis; if a certain > Collection can implement disjointUnion more efficiently, you have to > make it a separate overload and resolve it statically rather than > using late binding. > 2. it loses type information: if I'm using LinkedLists, that method > will return Collection, and I'll have to cast to LinkedList if I want > to use some LinkedList-specific method. > > Of course if that was Lisp and not Java, neither of the two problems > would be there ;) > > Alessio I don't think either of these complaints holds water. 1) You could define an AbstractCollection whose "naive" cons method calls Collections.disjointUnion; if you can write a better implementation then override it, otherwise don't. 2) This hasn't been true since 1.5, years ago. Subclasses are permitted to return a more specific class than the interface requires. Callers who aren't aware of (or don't care about) LinkedList will get a Collection, while you get a LinkedList. The first signature you proposed (and discarded) is in fact perfect: it's typesafe, flexible, and doesn't lose any information. interface Collection<T> { public Collection<T> cons(T t); } class LinkedList<T> implements Collection<T> { public LinkedList<T> cons(T t) {...} } It's possible I've misread your signature and you prefer to write cons as a static method instead of an instance method: class CollectionUtils { public static <T> Collection<T> cons(Collection<T> cdr, T car) {...} } -- Cheers, Alan (San Jose, California, USA)
From: His kennyness on 12 May 2010 15:37
samantha wrote: > On May 5, 2:06 am, "Captain Obvious" <udode...(a)users.sourceforge.net> > wrote: >> NP> Is there something Comparable ($\ddot\smile$) to the >> NP> Java Collections Framework in LISP. >> >> Unfortunately, no. >> Closest I was able to find is cl-containers, but it is half-assed, to say it >> lightly. >> >> NP> productive with huge data sets I will need things like >> NP> balanced-trees etc. and I don't want to re-invent >> NP> the wheel. >> >> There are some implementations of balanced trees available, but all of them >> have some deficiencies. >> (At least at time I was checking it.) >> >> NP> What I like in particular in Javas Collections is >> NP> the separation of semantics (via "Interfaces") and >> NP> implementation. There should be a similar standard in >> NP> LISP. >> >> That would be nice, but I'd start with good underlying data structure >> implementations. > > In what way do CL generic functions and CLOS fail to be many times > more powerful and better at expressing interfaces than Java > interfaces? Please do not interject anything accurate about Lisp into this otherwise barren exchange -- it would die of loneliness. hk |