Subject: Re: Allegro compilation warnings
From: Erik Naggum <>
Date: 2000/10/13
Newsgroups: comp.lang.lisp
Message-ID: <>

* Mario Frasca
| unfortunately my understanding of the compilation process in
| Lisp is still far from complete, hence my questions.

  Sure, but it was your _irritation_ that I commented on.  Legacy code
  is _not_ a source of pain and suffering.  It can be a source of
  great pride and hubris: You're _so_much_better_ than the neanderthal
  who wrote the code to begin with.  It can be a wonderful source of
  satisfaction: Almost anything you do will be an improvement.  It can
  be used for target practice: Just print it out, hang it up, and fire
  at will.  It's not like you're killing anything that deserved to
  live.  However, make sure that whoever hired the neanderthal who
  makes you waste your time knows how you're spending your time --
  most managers are unaware that they need to adjust their behavior
  and their decision criteria because their inferiors are reluctant to
  tell them how they went wrong in the past.  Managers should be
  willing to listen to and learn from the experience collected by
  their inferiors, or _their_ manager(s) need to hear it.  It may be
  easier to move elsewhere, but that has the obvious downside of not
  identifying and virtually hanging neanderthal programmers _and_ the
  managers who hire them.  If this is not important to you, chances
  are that you are in the same category yourself.  (If you were only
  working with programming to get paid, bad legacy code is such a huge
  source of billable hours that you can't possibly be unhappy with it.)

| >| less disturbing are the ones:
| >| Warning: Variable X-DUMMY is never used.
| >
| >  So why is it there?
| wow, an easy question!

  I'm afraid not.

| you deserve two answers:

  I _deserve_ them?  Geez.

| 1) as far as these warnings are coming from code which I did not write,
| I just follow the rule "if it ain't broken, don't fix it".

  It _is_ broken.  That's why you get warnings, and that's why you're
  trying to fix it.  And I _deserved_ this answer?  Geez.

| 2) look at this example:
| (defun compute-coefficients (x1 p1 x2 p2 x3 p3)
|   (handler-bind ((DIVISION-BY-ZERO 
| 		  #'(lambda (x-dummy) (return-from compute-coefficients nil))))
|     (gauss:solve (list (list x1 1 (- p1) (* x1 p1)) 
| 		       (list x2 1 (- p2) (* x2 p2)) 
| 		       (list x3 1 (- p3) (* x3 p3))))))
| here I have to provide handler-bind with a one-parameter-function,
| but in this function I really don't know what to do with this
| parameter.  I named x-dummy so that when reading that warning I know
| I can ignore it.

  I suggest you look up handler-case to simplify the expression
  dramatically.  See?  Not an easy question.

  I agree with everything you say, but I would
  attack to death your right to say it.
				-- Tom Stoppard