[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Nov 27 20:29:30 1995 
Subject:Re: New Default Syntax 
From:A . Sloman 
Volume-ID:951128.08 

Steve, I've just seen your earlier message which answered my question.

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

I've never met any instance of this causing anyone a problem, but I
accept that it could. In fact that's true of any language in which one
has the flexibility to create and interpret structures: if the code that
does the creation includes items (like "x") which take on values at run
time that are unexpected (like "??") then just by examining the code one
may not be able to see all the implications of what one has written.

In this case, I think the only way to avoid the problem is to have a
class of pattern elements which are special structures, like prolog
variables. For example we could have two new record types, one for
simple variables and one for segment variables, each containing a word
or identifier and possibly a restriction. Then the matcher would
recognize these objects and deal with them accordingly. I've built
and used pattern matchers like that in the past, as has Steve Hardy, who
was the original designer of the Pop-11 matcher (originally written in
PDP11/40 assembler code!). The decision to go for the simpler list
element matcher was entirely due to a requirement for something simple
for teaching purposes. Basically it works very well for that purpose.

Moreover it has proved sufficiently flexible that I've used it in more
serious contexts also (my poprulebase system for instance) though every
now and again I think I'll probably have to replace it. The simplest
replacement would be to keep lists as patterns but include new types of
pattern elements as sketched above. There are other options such as
introducing a new data-type for patterns, and allowing pattern elements
that can be made to match the contents of arbitrary data structures. But
that's a much bigger design job, which is probably why nobody has done
it. Maybe you and I should collaborate on it, as we both have enough
experience to do it without a huge amount of effort. It will never be as
elegant as the current matcher, though.

> On the other hand, those of us at HP will breath a sigh of relief.
I am amazed. Did you have a problem of naught people going on using the
matcher etc. for serious work despite being told not to?

> In the specific case mentioned, surely all that is required is
> a "+oldvars"?

Yes, that would do. Or making the procedure that prints the warnings
user-definable.


> 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?

There is no easy way of fixing this without making the matcher generate
a lot more garbage (it already generates too much). Maybe it could
analyse patterns at compile time to see whether they contain segment
variables and if not then invoke a deterministic matcher. I guess a
property could be used to record which patterns have already been
checked (though often people don't bother to make their pattern lists
constants even when they could do so, e.g. using #_< ... >_#).

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

What exactly are you looking for? If you want a prolog-type unifier,
there's already one! Can you give a high level specification of the sort
of matcher you would like to use? (I want one for production systems,
for example.)

> ....Programming ideas have moved on a long
> way from the 1960s and, fortunately, Pop11 has kept pace.

I guess the functional programming community would disagree ???

But then I am not one of them.

Aaron
PS
By the way the new sockets package in V15 is an example of a really good
development. I found it very easy to convert my NNTP news reader to
use it and now it goes significantly faster, and is probably more
reliable. John Gibson chose some very nice high level constructs. E.g.
you can do
	sys_socket_to_service(['news.site.ac.uk' 'nntp'], "line") -> socket