On Nov 11, 5:48 pm, Gene <gene.ress...@gmail.com> wrote:
> On Nov 11, 3:17 pm, JonathanSmith...@gmail.com wrote:
>
>
>
> > On Nov 11, 11:31 am, "William James" <w_a_x_...@yahoo.com> wrote:
>
> > > Rob Warnock wrote:
> > > > <JonathanSmith...@gmail.com> wrote:
> > > > +---------------
> > > > | Mark Carter <m...@privacy.net> wrote:
> > > > | > Suppose further that I want to accumulate totals based on keys.
> > > > The | > first element in the list is the key, and the second element
> > > > in the list | > is the value. Is there a Lisp function which is
> > > > callable something like:  | > (accum list) ; => '( (1 9) (3 4) (5 6) )
>
> > > > >  (defun accum-pairlist (list)
> > > > >    (let ((return-list nil))
> > > > >      (dolist (li list)
> > > > >        (if (assoc (first li) return-list)
> > > > >            (setf (second (assoc (first li) return-list))
> > > > >                  (+
> > > > >                   (second (assoc (first li) return-list))
> > > > >                   (second li)))
> > > > >          (pushnew li return-list)))
> > > > >      return-list))
> > > > +---------------
>
> > > > Careful!! Your solution has the same bug that my first
> > > > (and, thankfully, unpublished!) version I did -- it doesn't
> > > > give the same answer twice. [And why it behaves that way
> > > > is even more serious!!]  E.g.:
>
> > > >     > (defvar list '((1 2) (3 4) (5 6) (1 7)))
>
> > > >     LIST
> > > >     > (accum-pairlist list)
>
> > > >     ((5 6) (3 4) (1 9))
> > > >     > (accum-pairlist list)
>
> > > >     ((5 6) (3 4) (1 16))
> > > >     > (accum-pairlist list)
>
> > > >     ((5 6) (3 4) (1 23))
>
> > > Well, Jonathan, it seems that Xah Lee was right and you were
> > > wrong.  Lisp processing in archaic Lisp is more difficult than
> > > it is in a modern language.
>
> > > Ruby:
>
> > > def accum_pairlist list
> > >   accum = []
> > >   list.each{ |key,val|
> > >     pair = accum.assoc(key)  and
> > >     accum[accum.index(pair)][1] += val  or
> > >     accum << [key,val] }
> > >   accum
> > > end
>
> > > p accum_pairlist( list )
> > > p accum_pairlist( list )
>
> > > --- output ---
> > > [[1, 9], [3, 4], [5, 6]]
> > > [[1, 9], [3, 4], [5, 6]]
>
> > I don't see how my making an error using destructive functions puts
> > lisp in the doghouse.
>
> > I never argued that lisp was the be-all and end-all of basic list
> > processing. Xah Lee argued that it was terrible for it. His arguments
> > come from a fundamental lack of knowledge about lisp and lisp
> > implementations (He thinks lisp doesn't have things that it does have,
> > he assumes that cons structures in modern lisp implementations are
> > implemented in the same way as they were in the 1960s). He also argued
> > (through a misunderstanding of what a macro is), that lisp has
> > irregular syntax structure....
>
> > (defun fn-pairlist (mylist fn)
> >   (let ((return-list nil)
> >         (list (copy-tree mylist)))
> >     (print fn)
> >     (dolist (li list)
> >       (if (assoc (first li) return-list)
> >           (setf (second (assoc (first li) return-list))
> >                 (apply fn
> >                        (list
> >                          (second (assoc (first li) return-list))
> >                          (second li))))
> >           (pushnew li return-list)))
> >     (reverse return-list)))
>
> > (defun accum-pairlist (mylist)
> >   (fn-pairlist mylist #'+))
>
> > (defun gcd-pairlist (mylist)
> >   (fn-pairlist mylist #'gcd))
>
> > (defun lcm-pairlist (mylist)
> >   (fn-pairlist mylist #'lcm))
>
> > (defun subtract-pairlist (mylist)
> >   (fn-pairlist mylist #'-))
>
> > (defun list-pairlist (mylist)
> >   (fn-pairlist mylist #'(lambda (a b)
> >                           (if (listp a)
> >                               (append a b)
> >                               (list a b))
> >                           )))
>
> > You can expand it to fit whatever requirements you happen to have.- Hide quoted text -
>
> Friends,
>
> Programming languages only exist to match the programmers mental model
> of a program to the nearly non-existent ability of machines to
> understand it.

No, really? I thought it was like a magical incantation.

> It follows that complaints about language features are
> really reflections of individual intellectual styles, abilities, and
> limitations. Truly good programmers are so nimble in their thinking
> that language features don't even reach the level of consciousness;
> their ideas are bigger and more abstract.

Cripes you are full of it.

> Consequently, those who
> engage in language criticism are mostly revealing their shortcomings.

Or the shortcomings of a language in facilitating a certain way of
thought.

> Refutations and defenses are, in turn, wasteful, bordering on self-
> destructive.

Right. Well then, next time someone makes a post full of
misinformation, I'll make sure to ignore it.