Aaron Sloman writes:
> 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.
On the other hand, those of us at HP will breath a sigh of relief. I
agree that the change could have been handled better but I am
grateful that it has arrived.
In the specific case mentioned, surely all that is required is
a "+oldvars"?
> 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
I agree with this specific point. I can see no virtue in requiring
duplicate declarations. Duplicate declarations are pointless. Ban them.
Well, this topic boils down to the use of the matcher. This is
one of the teaching features of Pop11 that we all agree is successful
but does not make the jump to professional programming. I'd like
to see some effort invested in a matcher that supercedes the existing
buggy matcher. And I agree with Aaron that such an improvement
is overdue.
> The "official" answer to this is that one should not use the pattern
> matcher because it is flawed (e.g. because it does not work with
> "lvars" and section variables, and has some other problems - which is
> why I introdced LIB FMATCHES, which only partly solves the problems
> and can be hard to use in some contexts).
I feel the need to elaborate on this.
The worst problem is that the matcher does not work with multiple
segment pattern-variables. Surely there should have been a bug-fix
for this problem long ago? The next very serious problem is the
well-known confusion between data and pattern -- which Aaron has often
argued is an advantage. For example, when does the following
fragement return true?
[ a b c d ] matches [ a ^x c d ]
The answer is, of course, when x is bound to "b" or "??" (and "c" is
a permanent). The unexpected binding when "x" is bound to meta-
symbols makes the matcher wholly unsuitable for serious programs.
So, I think the criticism that I (and others) have levelled at
the matcher is justified. I think we should try to define a migration route
from the existing matcher semantics to a more desirable set that
will not break the existing material and yet still make it suitable
for commercial programming.
> Similarly, published books are suddenly rendered wrong because of this
> change.
I am not convinced by this point. I throw my hands up in horror at
all of the books. They were badly in need of updating to take account
of the improvements. Students could not learn to write well-engineered
programs with these books as their basis. I know, I know, people in
industry ought to have written a book for their needs and I'm as guilty
or guiltier than most of not having done this.
However, these changes reduce the discrepancy between the style of
programming shown in the published texts and good programming style.
One of the admirable things about Pop11 is that good programming
style was natural -- all the "improvements" to Pop11 made this less
true. The changes for variable declarations reverse that unhappy
trend.
> 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.)
Again, I remain unconvinced. Programming ideas have moved on a long
way from the 1960s and, fortunately, Pop11 has kept pace. But the evolution
of Pop11 has had a deleterious effect on the elegance and simplicity of
the language. Why? Because "global" qualities like elegance of design
are important but not urgent. A small loss of simplicity does not seem
like a big deal if a more urgent feature is incorporated.
I welcome these changes because they recognise that Pop11 has gone
too far in the direction of creeping featurism. We want the features
but we don't want them at any cost. The changes to default declarations
make the obvious way of writing Pop11 code the best way of writing code.
And although that isn't very urgent it is very important.
Having said this, I find myself agreeing with Aaron's specific complaint,
that local "vars" declarations now generate a superfluous warning. I
fail to see why a local "vars" declaration cannot be considered equivalent
to a top-level permanent declaration (together with a warning if there
is a changes of properties) + a dynamic localisation. The warning against
conflicting top-level definitions *is* essential.
Furthermore, I want to see more changes in the direction of simpifying
Pop11. Probably the most urgent one, in my view, is the cleanup of
the "for" loop syntax. These loops have become disorganised for no
good reason - for example, "with_index" is only allowed for vector
based loops but would be valuable on a wide variety of loops. There
are many other changes worth making but I fear I'm getting into deep
basenote drift.
Steve
|