On 5/7/06, Robert Dodier <robert.dodier at gmail.com> wrote:
>
> > However, it also makes it much easier to incorrectly assume that an
> > expression *has* an operator when it doesn't, and to propagate nonsense
> > further into the program.
>
> I don't see how you've reached this conclusion.
> How does introducing the false return value affect the
> cases for which op returns non-false?
It does not. It affects the case where the user has incorrectly assumed
that op(...) would return the operator of an expression. This is a very
common kind of error.
Perhaps you mean stuff like op(1/3) =3D> // .
No, that is a different case.
> Errors are a *good* thing in cases like this.
>
> This is off-topic at the moment, but: throwing something
> makes error recovery easier, if an error must be indicated.
I agree that errors should include more information, which can be caught by
a higher-level error-handler. But as you say, that is off-topic in this
discussion.
> > For that matter, checking whether an expression is an atom is usually
> not
> > the right thing -- you want to check whether it is a symbolic constant
> or
> > variable, which may be subscripted, so the above code would become:
>
> The test ($ATOM EXPR) only modifies the behavior of op
> in cases in which it prints an error at present.
Agreed.
Within the scope of the current proposal, I have no intent to
> modify the behavior of op in cases in which op now returns
> something successfully
I didn't say you did.
> In all, it seems to me that it would be a classic design error to have op
> do
> > anything other than give an error when it is passed inappropriate
> > arguments.
>
> I don't see anything inappropriate about op(1).
Well, "1" doesn't have an operator, that is all, so I don't see what the
meaning of op(1) could be. I would be interested in your comments on the
use cases I gave. In what cases do you think it would be helpful to the
user to define op(1) as false rather than an error?
-s