spam

Another little pop11 quirk (and quiz).

Q. What happens if you type

: 2, 3 =>

A. You get

** 2 3

Or do you? How about getting

** 3

No, I didn't redefine sysprarrow() -- which is the procedure
called by the print arrow syntax.

Try the following:

: sysunprotect("true");
: false -> true;
: 2, 3 =>
** 3

Arguably, this is a bug, not a feature!

: true=>
** <false>

Assigning false to true is *fairly* safe - things get a litle
stranger if instead we assign true to false.

However, I can't think of even one good use for this: shouldn't
the booleans true and false be constants, instead of protected
variables??

Normally I'm opposed to system constants, and think everything
should be a (protected) variable, so users can redefine it,
but in this case I think I'd make an exception ...

There's a (very small) underlying point to all this. The only
reason for using constants, instead of protected variables, is
for efficiency. And often syntax procedures plant code using
variable names, which is automatically optimised by the
compiler if they refer to constants -- this can't be done if
the variable, is protected and not constant.

So the compiled code for a call of
my_procedure(arg1, false, arg2);
for example, is (probably) slightly less efficient than it
could be.

Jonathan

waldek hebisch

Yes, definitely. Poplog runtime should use the actual boolean values,
not what happens to be bound to true and false.

IMHO true and false are part of language, so when user redefines
true system code should work using old value (exactly as happens
with if or +.

Well, I would say that constants are essential to have shared
context. If comma, parentheses and semicolon are variables,
then the line above can mean anything -- it is impossible to do
do any copilation (so there is runtime penalty), but it is
also impossible to predict what the code will do, which in turn
means that is impossible to write program which will work
correctly after redefinition.

--
Waldek Hebisch
hebisch@math.uni.wroc.pl