;)will

I second that.

Would this not be something for the Association of Lisp Users? They
could ask for nominations in January, have a committe choose the most
deserving entry, and then they could post the result on the website.

BTW, my Programming Languages class had to turn in that LISP lab today,
but at the end of class the prof walked out with the completed lab
assignment of only of the more thatn 20 students. Everyone else was
scrambling to grok enough LISP to complete the assignment. Guess which
student was able to complete the assignment. That's right, me, Claire
Quilty....

Ever faithfully,
Your boon and bosom companion,
Claire Quilty

  Does it really make you feel any better to have to post such obvious
  self-flattery that nobody can verify?  You are truly pathetic the
  way you have to post something so transparently intended to recover
  some of your lost credibility in your _own_ mind.

  It looks like you produced the insanity you insist on stuffing into
  somebody else's mouth.  Try and grow up so you can accept full
  responsibility for your own lack of ability to think clearly.

  Here's a clue for you: We're not talking about languages you invent.
  Here's another clue for you: Bad craftsmanship begets higher demand
  for (bad) craftsmen.  And yet another clue: If it is so hard to
  become good at a language that nobody really does, the people who
  get hired and fired shortly thereafter will be alarmingly higher
  than for a language that it is possible to learn really well,
  because the people who do are not in as high circulation.

  Go back to hacking some Perl and C++, now, "fella".  Those languages
  are more suitable to people of your intellectual prowess than you
  will understand, or admit if you do.

And since I am in a good mood tonight, I'll use this opportunity to
exercise my teaspoon-mode:

When you see such statistics, there are _several_ possible explanations
for their pattern:

   1. It could be that programmers of LISP are so efficient that the
      market only needs a very small number of them.

   2. It could be that programmers of other languages are so retarded
      as to create a mass demand for new programmers to sort out their
      messes and salvage whatever useful things there might be left in
      their projects after the crap has been filtered out.

   3. It could be that most companies that are searching for LISP
      programmers, have discovered that advertising for them doesn't work.

   4. It could be that LISP programmers have the ability to find good
      employers that are then able to keep them on for a _long_ time.

   5. It could be that the management of most companies out there are
      unaware of what the good tools are, and unwilling to listen to
      advice on this from people who know what they are talking about.

   6. It could be a combination of the above factors, and I won't rule
      out that there could be additional factors deciding this.

So, my remark was simply a tongue-in-cheek remark that there could be
several explanations for that kind of slant in ad numbers, and that
consequently, the numbers themselves could not be taken to either prove
or disprove (or even indicate) any theory on their meaning.

        (defun sum (&optional (lower 0) (upper lower))
          (loop for n from lower upto upper sum n))
* (sum)
0
* (sum 0 1)
1
* (sum 1 0)
0
* (sum 1 4)
10
*

Cheers

Cheers

    (defun sum (list) (reduce #'+ list))
    (defun range (lower upper)
      (loop for n from lower upto upper collect n))

except that Haskell is lazy so it's really more like
using SERIES.

(The point is that the snippet of Haskell above is
displaying two useful and concisely-expressed abstractions,
not a single, rather useless, sum-of-arithmetic-progression
function.)

I can tell you without switching to my lisp listener that
 sum[1..100] = (1 + 100) + (2 + 99) + ... + ( 50 + 51) =
             = (1 + 100) * 50
             = 5050

Homework #1: name the matemathician who was asked by a teacher to sum
all integers  between 1 and 100 in the hope that he is going to sit
tight for a good while (no HP calculators that time).

Homework #2: generalize the above algorithm and write a CL function that
sums [n .. m] in O(1) time.

And nobody dare to help Marco!

sum [1 .. 10] -> whatever ;-)
AND
product [1..10] -> factorial ;-)

So I just have to remember switching from sum to product. That suits
me ;-)))

Cheers

/Jon

Perhaps you mean the mathematician Gauss (as a child), of whom this
story is sometimes told.  

Sadly there seems to be little historical basis for the story.

D

; Well, let's optimize atleast a bit for speed and less debugging
(proclaim '(optimize (speed 2) (safety 1) (debug 1)))

; our iota
(defun iota (n)
  (loop for i upto n collect i))

; our naive sum
(defun sum (list)
  (reduce #'+ list))

; let's try it. conses the intermediate list
(sum (iota 100))

; let's define the shortcut from Mr. Gauss
(defun sum-iota (n)
  (/ (* n (1+ n)) 2))

; see it work. No list involved.
(sum-iota 100)

; Now a compiler macro. If we see a form (sum (iota something)) we replace it
; by (sum-iota something).
(define-compiler-macro sum (&whole form arg)
  (cond ((and (listp arg)
              (eq (first arg) 'iota))
         `(sum-iota ,(second arg)))
        (t form)))

; trace sum-iota
(trace sum-iota)

; a test, should do the usual reduce
(defun test0 ()
  (sum '(1 2 3)))
(test0)

; another test. should be optimized. no intermediate list.
(defun test ()
  (sum (iota 100)))
(test)

; we change the implementation.
; let's define an assoc-list of ( test-function transformer-function)
; this let's us add new optimizers at any time, by adding to this assoc-list.
(defparameter *sum-transformers*
  `((,(lambda (form)
        (and (listp form)
             (eq (first form) 'iota)))
     ,(lambda (form)
        `(sum-iota ,(second form))))
    (,(lambda (form)
        (and (listp form)
             (eq (first form) 'quote)))
     ,(lambda (form)
        (sum (first (rest form)))))))

; Okay, the simplified compiler macro
(define-compiler-macro sum (&whole form arg)
  (let ((transformer (second (assoc arg *sum-transformers*
                                    :test (lambda (form test-fn)
                                            (funcall test-fn form))))))
    (if transformer
      (funcall transformer arg)
      form)))

; trace everything
(trace iota reduce sum)

; a few tests. See when the functions are being called,
;  by the compiler or at runtime

(defun test0 ()
  (sum '(1 2 3)))
(defun test1 ()
  (sum (iota 100)))
(defun test2 (list)
  (sum list))

(test0)
(test1)
(test2 '(1 2 3 4))

Pretty cool...

/Jon