Jonathan L Cunningham <spam@sofluc.co.uk.invalid> wrote:
> 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!
>
Yes, definitely. Poplog runtime should use the actual boolean values,
not what happens to be bound to true and false.
> : 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 ...
>
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 +.
> 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.
>
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
|