Re: useful list functions

[Peter Lund <firefly diku dk>]

On 7 Aug 2000, Maciej Stachowiak wrote:

> 
> > On Mon, 7 Aug 2000, John Cupitt wrote:
> > 
> > First off:  I love functional programming languages -- I've done my share
> > of programming imperative languages (since the mid-eighties) but I find
> > that I'm far more productive in ML than in C.  Part of this is because of
> > a nicer type system, pattern matching, automatic memory management and the
> > ability to use recursion in real-world programs -- part of it is due to
> > the wonderful higher-order functions available in the standard libraries.
> > 
> > If I wrote the functions John and I suggest, would they stand a chance at
> > getting included?
> 
> I think most of them are redundant with the ones I already suggested,
> and some of the others would be very hard to get right because of the
> memory management issues.
> 
> > 
> > > Maciej Stachowiak wrote:
> > > > /* Just like `map' in Lisp, Scheme or Perl, i.e. like for_each but
> > > >    return a list of the results. (non-destructive) */
> > 
> > >   gpointer slist_map( GSList *list, 
> > >     ListMapFn user_func, gpointer user_data );
> > 
> > Great -- I like having the bail-out option, could be used for simulating
> > exceptions :)
> 
> I disapprove of the way the bail-out option is implemented, as it uses
> in-band signalling (NULL is a valid list value) and this definition is
> foreign to the way `map' normally defined. If you need to "bail out"
> what you really want is to do a _find_custom and then operate on the
> value.

out-of-band signalling is of course much to be preferred.

> > take(l:list, n:integer) -- returns a list containing the first n elements
> >                            in l.
> > 
> > drop(l:list, n:integer) -- returns a list with the first n elements
> >                            dropped from l.
> 
> I suggested _copy_sublist which is more general than these.

:)

> > filter(l:list, f:filterfunction) -- returns a list of the elements for
> >                                     which the filterfunction returns true.
> 
> My suggested g_list_partition handles this functionality - however,
> for ease of memory management, it returns both the list for which the
> predicate was true, and separately the list for which it was false.

Nice :)

> > mappartial(l:list, f:optmapfunc) -- returns a list of the elements in l
> >                                     mapped onto a new domain (i.e. after
> >                                     conversion by the mapfunc).  Elements
> >                                     can be dropped/filtered out by the
> >                                     mapfunction.
> 
> Disapprove of in-band signalling here, you can always partition and
> then map. Note again also the memory management issues.

And it is a lot more useful if you have an OPTION type -- which you don't
have in C...

> > These should go a long way towards eliminating loops in (the application
> > programmers' part of) GTK+ programs.
> 
> My proposed functions were meant to work towards this goal. :-)

Your suggestions sound better than mine -- count my vote in favour :)

-Peter

And Visual Basic programmers should be paid minimum wage :)
	-- Jeffrey Straszheim (on comp.lang.functional)