Various Topics on Lisp

..ristoph.. .. ..a..

chris@ibanktech.net (Chris C apel) writes:

> V***il Nikolov <vnikolov@poboxes.com> wrote in message news:<lzd60gz11h.fsf@j****.v***il.nikolov.names>.. .
> > What's wrong with
> >
> > (setq v (delete-if #'(lambda (ignored) t) v :start i :count 1))
> >
> > to destructively delete the i-th element of v, or
> >
> > (setq v (delete-if #'(lambda (ignored) t) v :start s :end e))
> >
> > for a range?
>
> What's wrong is that you have to have the symbol.
> A collection shouldn't be tied to its symbol.

What symbol are you talking about?

.... ..ni..

In article <69d0f981.0409210658.7433008e@posting.google.com >, Chris C apel wrote:
>
> I think that, while Lisp is a much higher-level language than most
> .NET languages, Lisp collections are lower-level than .NET
> collections. That's the core of my argument. All the primitives are
> there, but they need to be organized, fleshed out, and made more
> consistent.

Exactly. So why isn't anybody doing it? My guess is that a generic
collection isn't as useful as it seems. Most of the time your specific
tradeoffs will make the use of an array, list, hash table, etc. the
more natural choice. And it really doesn't take long to get familiar
with the Lisp primitives, so by the time someone knows enough Lisp to
write their collection library, they realize that they don't really need
it.

Anyway in case you haven't learned about generic functions yet, here is
how you could implement a generic access-by-index function on an array,
list, and hash table:

(defgeneric by-idx (collection index))

(defmethod by-idx ((collection list) (index number))
(nth index collection))

(defmethod by-idx ((collection vector) (index number))
(aref collection index))

(defmethod by-idx ((collection hash-table) index)
(gethash index collection))


Other operations left as an exercise to the reader :-)

--
Eric Daniel

..th.. ..mme..

Christopher C. Stacy wrote:

>> > What's wrong with
>> > > (setq v (delete-if #'(lambda (ignored) t) v :start i :count 1))
>> > > to destructively delete the i-th element of v, or
>> > > (setq v (delete-if #'(lambda (ignored) t) v :start s :end e))
>> > > for a range?
>>
>> What's wrong is that you have to have the symbol. A collection shouldn't be tied to its symbol.
>
> What symbol are you talking about?

He probably means the variable V.

Arthur

..r.. ..p..

Pascal Costanza wrote:

> In my Java past (until about 2.5 years ago) I have tried the JGL (which
> I have been told is modeled after the C++ STL library), the Java
> Collection API and the C# collection API. JGL was very good, the Java
> Collection API ok (and the first example of Sun acting like Microsoft, -
> they didn't just adopt the JGL without any good technical reasons), and
> the C# collection API was just total ****. If you really take it
> seriously to program against interface and not against concrete cl***es,
> the C# design just didn't work because you always had to cast things
> around just to get at that particular operation you just need. It may
> work well with concrete cl***es, but then what's the point?

Are you talking about the ArrayList indexer returning its members as
"objects"? This doesn't have anything to do with the collection API itself.
It's the staticly typed nature of the langauge. In Lisp, you don't need to
cast things to treat them as having a certain type, so this problem goes
away.

Chris Capel

..t.. ..ib..

Pascal Costanza <costanza@web.de> writes:

> Peter Seibel wrote:
>
>> And use MAP-INTO to copy the data rather than looping and copying the
>> elements yourself; there's at least a chance the implementation will
>> have implemented MAP-INTO to use bulk copying primitives where
>> possible.
>
> What about REPLACE?

Er, yeah. That's good too. ;-)

-Peter

--
Peter Seibel peter@javamonkey.com

Lisp is the red pill. -- John Fraser, comp.lang.lisp

..r.. ..p..

Christopher C. Stacy wrote:

> chris@ibanktech.net (Chris C apel) writes:
>
>> What's wrong is that you have to have the symbol.
>> A collection shouldn't be tied to its symbol.
>
> What symbol are you talking about?

(defparameter *my-list* (list 1 2 3))

(defun do-something ()
(remove-at 1 *my-list*))

(defun remove-at (index list)
(setq list (delete-if (lambda (ignored) t) list :start index :count 1)))

(do-something)

*my-list* ==> (1 2 3)

Chris Capel

..sc.. ..stan..

Chris Capel wrote:
> Pascal Costanza wrote:
>
>
>>In my Java past (until about 2.5 years ago) I have tried the JGL (which
>>I have been told is modeled after the C++ STL library), the Java
>>Collection API and the C# collection API. JGL was very good, the Java
>>Collection API ok (and the first example of Sun acting like Microsoft, -
>>they didn't just adopt the JGL without any good technical reasons), and
>>the C# collection API was just total ****. If you really take it
>>seriously to program against interface and not against concrete cl***es,
>>the C# design just didn't work because you always had to cast things
>>around just to get at that particular operation you just need. It may
>>work well with concrete cl***es, but then what's the point?
>
> Are you talking about the ArrayList indexer returning its members as
> "objects"? This doesn't have anything to do with the collection API itself.
> It's the staticly typed nature of the langauge. In Lisp, you don't need to
> cast things to treat them as having a certain type, so this problem goes
> away.

No, I am talking about programming against interfaces which means that I
don't use the ArrayList type directly but some more abstract interface.
That's the recommended practice in those statically typed OO languages,
but it doesn't work in C# becaues the interfaces are too small-grained.
So you keep switching between different interfaces to uncover the
different methods that you actually need. On the other hand, when you
use the ArrayList type directly to cir***vent this problem you don't
really take advantage of the cl*** hierarchy.

I don't really remember all the details anymore. As I said, maybe things
have changed or I just didn't get it at that time. But it doesn't really
matter. CLOS centers around generic functions instead of cl***es and
that's clearly the better approach to OOP in my opinion - the lesser
need to squeeze a collection API into a hierarchy is just one of many
examples that turn out much simpler because of that approach.


Pascal

--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."

.... ..rtu..

"Chris C apel" <chris@ibanktech.net> wrote in message
news:69d0f981.0409210628.4d17f574@posting.google.c om...
> Which serves my point, that Common lisp is built so much around
> non-destructive (immutable object like) semantics that it's sometime
> much more difficult to write any other code. I [often] want my
> collections/arrays/lists to be mutable!

You're confusing things.

Arrays in CL are no different from arrays in pretty much any other language.
Including C#. C#'s arrays work and operate the same way.

There is no reason why you can not construct a collection hierarchy similar
to C# or Java in CL using CLOS. These will be as mutable as you want them to
be, and they'll be just as expensive to use as Collections in C#.

Idiomatically, however, because of built-in Lists, among other things,
typically something like Collections have not been necessary in CL.

In all of my java code, 99% of my use of ArrayList is to collect objects,
and then, later, iterate over them. I pretty much never need to access the
"nth element". Normally, I need to simply access the "next element".

The mechanics of doing this in CL is to either use this idiom with (push
....) and (nreverse ...):
(let ((l (list)))
(dotimes (i 10)
(push i l))
(nreverse l))
(0 1 2 3 4 5 6 7 8 9)

or use LOOP and COLLECT, and let it work out the details.
(loop for i from 0 below 10
collect i)
(0 1 2 3 4 5 6 7 8 9)

Then, to iterate over the list, you have several facilities available: MAP*,
DOLIST, LOOP, etc.

So, the real problem here is not what CL can or cannot do or does or does
not have. The problem is that you're trying to write C# using CL, and this
will cause you endless grief. Because CL is designed to write CL. While with
enough force and pure determination you can make CL have more C# like
facilities, the energy to do so is better and more efficiently spent in
learning the CL constructs and idioms, because with those you won't have to
fight every other construct in CL that doesn't know about the new things you
introduce, or every utility library available.

So, simply put, CL doesn't have a Collections hierarchy like C# because it
simply doesn't need one. It already has these facilities and more, they're
just organized differently, and more organic in their presentation because
they evolved and mutated under the searing pressure of the hot hammers,
keyboards and forges of folks writing enormous bits of software rather than
designed out of whole cloth from a clean slate.

So, again, while CL is more than capable of adopting those C# idioms, it is
probably easier to change the programmer than the language.

Regards,

Will Hartung
(willh@msoft.com)