Hello Stavros,
> 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?
Perhaps you mean stuff like op(1/3) => // . At this point I don't
know if that's useful or not. At any rate, introducing the false
return value didn't create that return value, and it doesn't
change it.
> 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.
> 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.
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 (e.g., op (x[1]) => x, OK by me,
op (1/3) => //, OK by me).
> 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).
Robert