From ...
From: Erik Naggum
Subject: Re: Allegro compilation warnings
Date: 2000/10/13
Message-ID: <3180422882654354@naggum.net>#1/1
X-Deja-AN: 680958251
References: <3180342535878529@naggum.net>
mail-copies-to: never
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: newsmaster@eunet.no
X-Trace: oslo-nntp.eunet.no 971436208 14369 195.0.192.66 (13 Oct 2000 11:23:28 GMT)
Organization: Naggum Software; vox: +47 800 35477; gsm: +47 93 256 360; fax: +47 93 270 868; http://naggum.no; http://naggum.net
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
Mime-Version: 1.0
NNTP-Posting-Date: 13 Oct 2000 11:23:28 GMT
Newsgroups: comp.lang.lisp
* 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