Stephen Wilson <wilsons@...> writes:
> On the other hand, Lisp is a very robust language. It has been
> designed not to error out except in truly erroneous situations. I can
> get past my subjective dislike for duplicate parameters by seeing this
> as a `robustness' issue.
OK, I think we're getting to the core of the disagreement now. Here's
some of it:
> The way in which I deal with complaints raised by a compiler is not
> too different regarding whether it is a compiler error or warning.
> Machine generated Lisp code cannot respond to an error.
This is not so, I think: it can handle errors in the same way as it
can handle all sorts of conditions, and signalling an error allows the
program generating the lisp code to recover in ways natural to that
> > I think that the absence of specification of what happens when some of
> > the varj have the same name is telling.
> Ya, so do I. Too bad we are getting different messages :)
I don't think we are: I think we agree that in the case of LET, the
standard does not specify what happens if names are the same. The
difference lies in what we want to do about it: you want to be
permissive, and infer what the behaviour should be from that of
similar constructs, which you claim to be sufficiently unambiguously
specified to make this inference. I want to assist the user in
writing or generating code that will run not just in one version of
one implementation, but in all versions of all implementations (modulo
bugs), and if that means that I cause errors to be signalled in cases
where it would be possible to return one of many possible answers,
then so be it.
That is, I am prepared to accept a certain loss of more-or-less
ill-defined programs (I'll agree that we're still disagreeing on
whether same-named required parameters in a lambda list are in fact
ill-defined) if that assists in identifying programs which are
guaranteed to run not just now but in ten years' time; particularly if
there's no strong agreement from other implementations currently over
the meaning of the ill-defined program.
> iii) The introduction of an erroneous state in an otherwise well
> defined situation is not ideal as it leads to a less robust system.
If you consider a run-time error to be something utterly fatal, then I
can see some of where you're coming from; however, I think that it is
preferable to signal an error than generate an arbitrary,
unpredictable result, and I would say that silently returning nonsense
leads to significantly less robust systems than signalling errors.
Generating only-maybe-legal Lisp code and running it expecting it
never to signal an error is not robust against changes to lisp
implementations, and no amount of requesting implementations not to
signal errors will make it in actual fact robust to new and changing
implementations: only generating unambiguously specified Lisp code and
running it stands a chance of doing that.
> A warning is appropriate and more in line with the spirit of the
I think this might have been true once, before the development of the
condition system; however, given the condition system as a mechanism
for conveying information about exceptional situations from and to
different parts of a program considered as a whole -- including
portions generated at runtime -- I no longer think it is true.
> v) For TAGBODY and go tags, the guiding principle should be
> consistency across `similar' constructs which introduce bindings. To
> my mind, the behaviour should be:
> (tagbody (foo) :A (bar) :B (baz) :A (jar)) ==>
> (tagbody (foo) (bar) :B (baz) :A (jar))
> In other words, go tag bindings should be introduced from left to
> right, where rightmost shadows duplicates on the left, and where an
> appropriate warning is issued.
Again, I think that an error is the right answer, consistently with
the guiding principle that that which is undefined (and does not
substantially add to expressivity) should be signalled as such in no