[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Nov 26 03:22:37 1995 
Subject:Re: reporting pop bugs (and pvars) 
From:A . Sloman 
Volume-ID:951127.01 

richardm@cogs.susx.ac.uk (Richard Matthias) writes:

> Date: Sat, 25 Nov 95 20:19:20 GMT
> ...
> I read in the REAME file for Linux poplog that it is completely unsupported
> and that we should come here for assistance. That's fair enough, but what
> I want to know is: Are they interested in hearing bug reports though?

Probably. See HELP BUGFORM if you wish to report a bug. But users of
free versions can't expect answers.

> ...When compiling the example 'wine-advisor' program from TEACH *
> PRODSYS, it gives lots of warnings about using vars where I should be using
> dlocals. When the same thing is done on the system in COGS it works fine. The
> version in COGS is still 14.51.

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 assume this is something to do with the change of default vars variable
> status in poplog 15.00 that it mentions in help news. This is fair enough, but
> shouldn't somebody update lib prodsys to take this into account???

It was perhaps tolerable to change the default procedure definition
semantics so that input and output variables now are automatically
interpreted as "lvars" if they are not declared otherwise using
"dlocal";

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;

instead of simply

	define foo .....

		vars p1, p2;

		....
	enddefine;

e.g. where p1 and p2 are pattern variables (e.g. as used in lib
prodsys). Nobody will want to use a language that requires so much
tiresome repetition.

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).

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.

It's even worse to make the change and then leave lots of libraries and
documentation that are then broken. I feel particularly annoyed because
I have spent a lot of time over the last five years trying to improve
the usefulness of Pop-11 for teaching, by producing a lot of teaching
materials, including a new primer. In my teach files and the primer,
I've encouraged the use of "lvars" for input and output variables (so
the first part of the new semantics will not do any harm), but also
making heavy use of the pattern matcher, one of the strongest features
of Pop-11 for teaching. (E.g. it has several advantages over Prolog's
unification in teaching beginners.)

Thus I've got masses of teaching documentation using "vars" for local
declaration of pattern variables, including the Pop-11 Primer which was
included in version 15 of Poplog at the same time as the new semantics
was introduced to make the Primer incorrect! I have no intention of
wasting my time revising all that documentation, especially as there's
no telling when yet another arbitrary change will make it out of date
again.

Similarly, published books are suddenly rendered wrong because of this
change.

A partial solution is to use the compile_mode option described in the
HELP NEWS file to restore the old behaviour. But that doesn't work on
libraries! So it will not help teachers who have produced demonstration
libraries.

Anyhow, I think it is totally wrong to encourage the use of compile time
switches which drastically change the semantics of the language
constructs since this is likely to lead to cases of "borrowed" code that
don't work, and maintenance problems because people forget which mode
code is compiled in.

What a shambles!

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.)

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
have to be assigned after the declaration, (b) it can't be used to
re-declare an input or output local, (c) it doesn't produce the annoying
warning messages. (A later version could fix (a), and possibly (b).)

=======================================================================
/* --- The University of Birmingham 1995.  --------------------------------
 > File:            $poplocal/local/auto/pvars.p
 > Purpose:			Introduce way of declaring local pattern variables.
 > Author:          Aaron Sloman, Nov 26 1995
 > Documentation:	TEACH * VARS_AND_LVARS, HELP * PVARS
 > Related Files:
 */

compile_mode: pop11+strict;

section;

define global constant syntax pvars;
	;;; Like vars but suppress warning messages inside procedure definitions.
	lvars item;
	repeat
		readitem() -> item;
	quitif(item = ";");
		unless item = "," then
			;;; compile([vars ^item;]);
			sysSYNTAX(item, 0, false);
			sysLOCAL(item)
		endunless;
	endrepeat;
	";" :: proglist -> proglist;
enddefine;

sysprotect("pvars");

endsection;
=======================================================================

Example of use:

define list_between(item1, item2, list) -> newlist;
	;;; if item1 and item2 occur in that order in list, return a list
	;;; of the intervening items, or false.

	pvars found;

	if list matches [== ^item1 ??found ^item2 ==] then
		found
	else
		false
	endif -> newlist;
enddefine;

The inability to initialise variables doesn't matter for pattern
variables, since one cannot assume any value will be preserved, even if
the match fails. So default values must be assigned after a match fails.

I hope that helps. The use of "pvars" should work on older vesrions of
Pop-11 as well as in V15.0 and later.

One advantage of moving towards a new declaration of pattern variables
is that it could later interact usefully with the pattern matcher.

Aaron