[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


    Date: 17 Apr 86 09:41:00 EST
    From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>

    The book says that the IGNORE declaration affects only variable bindings.
    I think this is trying to say that you can't proclaim an ignore.

I dunno. The wording is kinda fuzzy if you ask me.

    Is it really that hard to put the appropriate declarations in the
    (hopefully) few places where you want to ignore something?

Yes, it is somewhat of a hassle because it does occur a lot. Macsyma, for
example, has a couple hundred functions which either ignore some argument
or which MULTIPLE-VALUE-BIND for a set of quantities, some of which will
need to be ignored. Writing the IGNORE declaration wastes lots of screen
space and sometimes makes just enough difference to make it impossible to
see an entire definition on one screen. (I didn't write those definitions
so please no lectures about how such functions are too long; I agree, but
it's not always so easy a thing to fix and I have more important things to
be doing with my time anyway.)

The places where I find the use of an IGNORE variable especially attractive
are things like:
This is short and to-the-point. Having to write:
makes the form wide enough and cluttered enough that it starts to be hard
to read. Also, as a point of style I like to break multi-statement LAMBDAs
onto multiple lines, and end up writing:
which I find to be readable, but which unfortunately uses a ridiculous amount 
of screen space to say something which should be much shorter and punchier.

Sometimes it makes sense to (DECLARE (IGNORE ...)). For example, I may do:
because it provides a kind of documentation in spite of its obvious waste of
vertical space. Plenty of my co-workers wouldn't dream of writing anything
other than this:
In other situations, though, I may not know or care what the thing is that
I'm ignoring, so it's a pain to have to think up a name for the argument. 
For example, sometimes I just want to do:
   (ERROR "I don't know how to draw a line."))
and I resent having to do:
   (ERROR "I don't know how to draw a line."))
because I think it's visual clutter to no good end.

In fact, there is at least one family of functions in Macsyma which we've just
never gotten around to fixing which take three arguments, the middle of which
is always ignored. NIL is always passed as the actual argument, so there
is really no proper name for the incoming data, the true purpose is long-since
forgotten. Instead, the functions all look like:
but again I'd prefer to be doing just
One of these days I'll get around to just changing the arg conventions and
updating all the callers, but in the meantime I find it distracting to waste
a screen line for a nonsensical declaration.

The real problem in my mind is that there is nothing in error about the 
following code:
There is really no reason for the compiler to be warning me about it. 
This sort of thing used to be the bread and butter of the lambda calculus.
You'd never have been able to write a serious program without it. It's
quite well-formed. It has an obvious interpretation. Warnings about code
like this from modern compilers is presumably intended as a courtesy to
me because someone thinks it's unlikely that I would really want to do
this. There are certainly many possible good reasons for doing it, though.
As such, the thing that warns me should take reasonable steps to notice
any clues that I might have given that would suggest that I might not want
to be bothered about this. I suggest that
is about as blatant a clue as I can think of. Heck, I'm even willing to
to make it doubly clear that when I really mean to ignore IGNORE. I'm not
asking for natural language parsing, after all. So here I am bending over
backward with a desire to tell compilers that it's OK to not warn me about
dozens of functions that weren't in error in the first place and some of
the compilers just aren't going to want to listen... Sigh.