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

magic? aberration



I understood that magic?  was working correctly-- hence my chuckle.  I
sympathize with your decision not to allow magic things as variable values.
However, it leads to the awkwardness described.  I predict this awkwardness
will come back to haunt you.  E.g., a list of objects cannot be stepped
through if it has a magic element.  All magic objects will behave like the
"unbound object" in ILISP.  You can do anything you like with it, except
set it to a variable in interpreted code.  This leads to unbelievable
contortions in some ILISP programs.  I fear the contortions will be much
more frequent in T programs.

I have a counter-proposal:
1) Allow magic things anywhere
2) If a "processor" (interpreter, e.g.)  sees (x ...), and x evaluates to a
magic object, then x must be the standard name of the object.  The compiler
will never detect this situation, of course, but the code it produces
could.  So (LET ((X COND)) (X ...)) blows up when X is called, in both
interpreted and compiled code, because X is not the standard name of its
value.

This covers all the cases I can think of, but I can only think of two.
-------