A.Sloman@uk.ac.bham.cs wrote:
> All sorts of students and teachers are going to complain about this
> change. I think a dreadful design decision has been taken, in complete
> disregard of the needs of students and teachers, who are, at present,
> the main users of Pop-11, and are likely to be for the foreseeable
> future.
I think it's an excellent design decision. It makes Pop11 a "serious"
language which means that more than "students and teachers" are likely to
use it.
> What was completely unacceptable was forcing warning messages on the
> user wherever "vars" is used simultaneously to declare a variable as
> "permanent" and dynamically local (e.g. for the pattern matcher). It's
> completely stupid to try to force people to write
>
> vars p1 p2;
>
> define foo .....
>
> dlocal p1, p2;
>
> ....
> enddefine;
Not at all. Imagine the following program:
define f1;
vars foo;
enddefine;
define f2;
vars fooo;
foo =>
enddefine;
It has a bug in it (I've misstyped foo in f2). In v<15 Pop11 this compiles
completely silently (as foo and fooo are really globals now) but will fail
to work. As a novice (or even an expert) I imagine it would be very hard
to spot this typo in a morass of code. Novices would have a particularly
hard time as
"vars are local to the procedure, yes???"
I've heard this many times times when during lab classes...
Whereas if I'm forced to do this:
vars foo, fooo;
define f1;
dlocal foo;
enddefine;
define f2;
dlocal fooo;
foo =>
enddefine;
(which is what is really going on) then I know I should keep much firmer
control on my name space (or, at least, keep a firm eye on those foos)
> However, to use such an argument as a basis for making such a change
> without FIRST fixing the pattern matcher is extremely insensitive and is
> exactly the sort of bad decision that alienates users.
I'm with you on that one.
> It's even worse to make the change and then leave lots of libraries and
> documentation that are then broken.
Absolutely. It wouldn't have been hard to search all the libraries and put
compile_mode :pop11 +oldvar;
at the head of each file that used the matcher.
> What a shambles!
Yup
> Pop-11 used to be such a nice language. (It always had flaws, but there
> were far more important things to do to fix them than this kind of
> irksome tinkering.)
I dissagree that this is "tinkering". It was a major design flaw in the
old defaults. It was about time it was fixed.
> A partial solution:
> People who don't want to use compile time switches and who insist, as I
> do, on wanting to use a SINGLE local declaration for pattern variables,
> can adopt the following, which declares a new autoloadable syntax word
> "pvars", which can be used like "vars" for local declarations except
> that (a) it does not accept initialisations, so that default values
No, no, no, no, no.... arrrghhhh
Please don't start pushing yet another variable type (particularly as this
isn't - it just looks like it is)!
The correct solution is to fix the matcher to recognise lvars.
All IMHO of course ;-)
Ian.
|