🚀 go-pugleaf

In article <2798@syma.sussex.ac.uk> aarons@syma.sussex.ac.uk (Aaron Sloman) writes:
]jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
]] In article <2790@syma.sussex.ac.uk> aarons@syma.sussex.ac.uk
]] (Aaron Sloman) writes:
]] ]I don't see any difference between this problem and the problem
]] ]arising in any programming language where you define procedures or
]] ]functions with arguments of certain types and then have to invoke
]] ]them by giving the right number of arguments in the right order.
]]
]] Do you really see no advantage to using functions to extract
]] parts of structures rather than some positional notation?
]
]I was not aware that I was commenting on that. All I was commenting
]on was the point you made (I think) about the difficult of keeping
]programs consistent in languages that use pattern matching. I was
]simply suggesting that this is a general difficulty with positional
]notations, used in many programming languages, not just pattern
]matching programs.

And I was simply suggesting that (1) even though there are similar
problems elsewhere we might still want to do something about this one
rather than not do something; and (2) the problem tends to be worse
for patterns than it is for functions [see below].

Moreover, if I say X is a problem, and you say X is the same as Y,
this sort of suggests that we shouldn't worry any more about X than we
do about Y; and I wanted to say the we ought to worry, perhaps, a
little bit more.  Indeed, the last N years of programming have shown
the value of treating data abstractly, so that it seems, at least to
me, a step backwards to employ very concrete representations as
patterns.

]Yes, I do think there are occasions when it is nicer to use a
]function to extract a component of a structure, e.g.
]
]    last(x)

If that's how far it has to go before you think a non-positional
notation is better than a positional one (and yes I regard a
two-argument function as non-positional with respect to the field it
is accessing), then I guess we'll just have to agree to disagree.

BTW, I don't mean to imply in any of this that there aren't ways
to make pattern-matching more abstract.  There are, and it's a good
idea to employ them.  However, in many languages pattern matching
is not abstract, it is very concrete.

]But that doesn't mean pattern matching is inferior in all contexts.

Which no one has said it was.

]] A possibly related question is: do you find nothing wrong with
]] functions/procedures that take, say, 7 positional arguments?
]
]I wasn't commenting on that either.

See above and note that it is usually more common to see data
structures with, say, 7 fields than to see procedures with 7
arguments.  In Prolog, it's true, the two problems are much more
nearly the same.  However, one of the techniques that can sometimes
help reduce the number of parameters to a predicate, namely combining
some of them into a single structure (when it makes sense to do so),
doesn't help as much as it might if you later use pattern-matching to
take the structure apart.

]I seem to remember Bob Boyer once telling me that in order
]to write a lisp pretty printer he had to have a procedure with some
]large number of arguments (about 14?) on most of which it recursed.

For the record, it is not necessary to have that many parameters
in a Lisp pretty printer.

]] ]In most languages you'd have to write at least three nested loops
]] ]to do this and would probably not get it right first time.
]]
]] In Common Lisp:
]]
]]   (some #'(lambda (sublist) (member 'b (member 'a sublist))) x)
]
]I think a picture of what you mean (i.e. a pattern) is much easer to
]understand, and to get right first time.

I wasn't commenting on that...

]] Not that this proves anything.  Besides, what you'd really do in Lisp
]] would be to write some procedures or macros that made it easier to
]] express such things.
]
]Why not add a pattern matcher instead? 

That's what the procedures and macros might amount to, but I think
there might be other solutions as well.

]] By the way, what happens with a pattern like
]]
]]     [[??a ??b] ??a]
]]
]] "[??a ??b]" can match in more than one way.  Will more than one
]] possibility be tried when trying to match the second "??a"?
]]
]Good point. In fact the standard Poplog Pop-11 matcher cannot find
]the way to match this successfully (though the Alphapop matcher
]designed by Jon Cunningham can).

I thought Poplog might handle such things because it uses downward
success continuations (I think) for the "log" part (ie for Prolog).

-- Jeff