New Default Syntax 
Author Message
 New Default Syntax

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

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

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

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

Quote:
> 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 #_< ... >_#).

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

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



Fri, 15 May 1998 03:00:00 GMT  
 New Default Syntax

Quote:
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"?  

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

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

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

Quote:
> 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



Fri, 15 May 1998 03:00:00 GMT  
 New Default Syntax

   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.

You might, Steve; but I've been using a define_form for yonks (``define
:proc'') which means that I've not had to worry about what the Pop11
parameter default is. What's more, it also allows me to write updaters as

        define :proc v -> f(x) as ...

which is much more suggestive about how it gets used.

In the light of other comments in this exchange, I think I'll also update
it so that lvars are required to be defined when declared (and to use a
version of ``for'' that declares its index variables!).

--

Regards,    | ``"I can't suit myself," said Weinbaum, a little petulantly.
Kers.       | "I work for the Government".'' - Blish, "The Quincunx of Time".



Sun, 17 May 1998 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Hash.new(Hash.new) doesn't use Hash.new as default value

2. Syntax Questions for a new language with somewhat Smalltalk-like syntax

3. Actual USEFULNESS of old Syntax (was Re: New Syntax -- with an implementation)

4. VHDL syntax question: generics default assignment in component versus entity declaration

5. YAI: syntax for preset locals without using dummy args with defaults

6. Default values for variables and Tcl syntax

7. Implementing letrec-syntax using only let-syntax and syntax-rules

8. New to Dolphin - Default view ???

9. A new kind of default model?

10. set default icon for new toplevels

11. dict.get(key, default): conditional default evaluation

12. *default-pathname-defaults* ?

 

 
Powered by phpBB® Forum Software