A Collections Framework?
in [Lisp]
|
Prev: scheme problem
Next: lisp student job offer
From: Pascal Costanza on 10 May 2010 09:35 On 10/05/2010 10:43, Alessio Stalla wrote: > On May 9, 2:27 am, "Scott L. Burson"<g...(a)zeta-soft.com> wrote: >> Oh yes -- Christophe Rhodes published a proposal for genericizing the >> CL sequence interface. I believe his proposal is implemented in SBCL, >> but I'm not aware that any other implementation has picked up on it. > > I recently ported it on ABCL, with the intent of adapting Java > collections to the Lisp sequence interface (not done yet). > >> My recollection is that it doesn't quite work for functional >> collections, which is partly why I didn't try to use it, but for >> imperative collections it might be useful. > > Indeed, the CL sequence API in some parts assumes mutable collections. > I think you should be able to avoid all such parts and still have a > fully usable API, but I haven't investigated deeply. Note also that > the Java Collections API referred to by the OP also has some > operations that involve mutation which are specified to be optional, > while having a core set of operations that is designed to also work on > immutable collections. The Java collection API inherently builds on mutability: It's very hard to create collections without having to "add" elements one by one, and as soon as you want to iterate over a collection, you get a data structure that keeps track of the iteration state by way of side effects. I hope that Lisp collection frameworks don't copy such "features". Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Norbert_Paul on 10 May 2010 09:46 Pascal Costanza wrote: > The Java collection API inherently builds on mutability: It's very hard > to create collections without having to "add" elements one by one, and > as soon as you want to iterate over a collection, you get a data > structure that keeps track of the iteration state by way of side > effects. I hope that Lisp collection frameworks don't copy such "features". I don't get the difference to LISP: (macroexpand '(dolist (var list result) body1 bodyn)) gives (BLOCK NIL (LET ((#:N-LIST610 LIST)) (TAGBODY #:START611 (UNLESS (ENDP #:N-LIST610) (LET* ((VAR (CAR #:N-LIST610))) (SETQ #:N-LIST610 (CDR #:N-LIST610)) (TAGBODY BODY1 BODYN)) (GO #:START611)))) (LET ((VAR NIL)) VAR RESULT)) So you have a "data structure" #:N-LIST610 which keeps track of the iteration state by way of the side effect of (SETQ #:N-LIST610 (CDR #:N-LIST610)) .. Note that you also have push, pop and delete. Are these the features you don't want? Norbert
From: Pascal Costanza on 10 May 2010 09:57 On 10/05/2010 15:46, Norbert_Paul wrote: > Pascal Costanza wrote: >> The Java collection API inherently builds on mutability: It's very hard >> to create collections without having to "add" elements one by one, and >> as soon as you want to iterate over a collection, you get a data >> structure that keeps track of the iteration state by way of side >> effects. I hope that Lisp collection frameworks don't copy such >> "features". > > I don't get the difference to LISP: > > (macroexpand '(dolist (var list result) body1 bodyn)) > > gives > > (BLOCK NIL > (LET ((#:N-LIST610 LIST)) > (TAGBODY > #:START611 > (UNLESS (ENDP #:N-LIST610) > (LET* ((VAR (CAR #:N-LIST610))) > (SETQ #:N-LIST610 (CDR #:N-LIST610)) > (TAGBODY BODY1 BODYN)) > (GO #:START611)))) > (LET ((VAR NIL)) > VAR > RESULT)) > > So you have a "data structure" #:N-LIST610 > which keeps track of the iteration state by way of > the side effect of > (SETQ #:N-LIST610 (CDR #:N-LIST610)) > . But you can also do this: (reduce function (mapcar (lambda (element) body) list) ....which is much harder to achieve in Java. > Note that you also have push, pop and delete. > Are these the features you don't want? I'm all for having options: Common Lisp also provides cons, cdr and remove. Again, getting those is harder in Java. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Norbert_Paul on 10 May 2010 10:28 Pascal Costanza wrote: > But you can also do this: > > (reduce function (mapcar (lambda (element) body) list) > > ...which is much harder to achieve in Java. > well, I often did things like that in Java: interface Function<X,Y>{ Y value(X x); } Then one could define: void mapcar(Function<X,Y> f, Collection<X> inColl, Collection<Y> outColl){ for( X x : innColl) { outColl.add(f(x)); } } and do: HashSet<Y> someOutColl = new HashSet<Y>(); mapcar(new Function<X,Y>(){ Y value(X x){ return doStuff(x); }}, someInColl, someOutColl); but you are right: It is verbose, ugly, and one reason why I returned to LISP (as soon as I could: Had to convince my principle first). Norbert
From: Scott L. Burson on 10 May 2010 12:17
On May 10, 6:35 am, Pascal Costanza <p...(a)p-cos.net> wrote: > > The Java collection API inherently builds on mutability: It's very hard > to create collections without having to "add" elements one by one, and > as soon as you want to iterate over a collection, you get a data > structure that keeps track of the iteration state by way of side > effects. I hope that Lisp collection frameworks don't copy such "features". Funny you should mention the iterator issue as I puzzled over it for some time. I eventually decided it made sense even for FSet to provide stateful iterators; for most uses the difference doesn't matter, and stateful iterators are more efficient. Also, as noted in the FSet documentation, if you want to do functional iteration, you might as well just convert the collection to a list -- it's hard to improve on lists for functional iteration. (Generating the list lazily might be some improvement, as it reduces the peak space requirement, but at a small cost in time because the "CDR"-like operation is now a little more involved.) -- Scott |