Subject: Re: Allegro compilation warnings From: Erik Naggum <erik@naggum.net> Date: 2000/10/13 Newsgroups: comp.lang.lisp Message-ID: <3180422882654354@naggum.net> * 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. #:Erik -- I agree with everything you say, but I would attack to death your right to say it. -- Tom Stoppard