[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Nov 27 16:10:32 1995 
Subject:Re: reporting pop bugs (and pvars) 
From:Ian Rogers 
Volume-ID:951129.03 

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.