Re: CList glitch (some kind o off-topic response)

[John Cupitt <john cupitt ng-london org uk>]

Karl Nelson wrote:
> The problem I see with the whole glib structure is that often
> the concept of what is the list and what is a place in the list
> are confused.  It should have been designed so that the first
> argument to all list operations was a pointer to a list abstraction.

I have a LISPy background, and I like the way g_slist_*() works now :) If glib
had C++-style lists with iterators, I'd probably be clamoring for my
lispy-list stuff to be added. 

LISP lists have some advantages over C++ interators: because they are
recursive data structures (take the tail of a list, you still have a list),
lots of list manipulation operators have simple recursive implementations. 

For example, mkset() is a standard LISP thing to remove duplicates from a
list. You can do an efficient implementation in a few lines of C for g_slist,
it's far harder (I think) for g_list, and also much harder with iterators.

Also (we're really on a minor side-track here) program proofs are much easier
with g_slist ... you can just do induction. iterator-style interfaces require
list invariants, elaborate iterator axiom things and stuff like that. So I
find I'm more confident my program works if I use g_slist.

I'm not saying C++-style lists are bad, just that there are arguments for the
way things are now.

John
--
John Cupitt, john.cupitt@ng-london.org.uk, +44 (0)171 747 2570
VASARI Lab, The National Gallery, Trafalgar Square, London, WC2N 5DN