[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Dec 1 15:51:57 1995 
Subject:Making the matcher robust? 
From:Chris Dollin 
Volume-ID:951201.08 

Aaron writes:

| I was discussing recent developments with a new convert to Pop-11
| at Birmingham, Riccardo Poli, who uses it for teaching and research
| (even on evolutionary algorithms).
|
| When I mentioned that I had found a way to make the matcher work with
| lvars by using lib readpattern and the syntax ![ ..... ] for patterns,
| he commented that in effect that violated the spirit of lvars because
| the matcher is then a procedure defined elsewhere that has access to the
| lvars variables, which is not supposed to be possible with lexical
| scoping!

This is not true.

``All'' lexical scoping does is to prevent access to a variable except
though text written in the scope of the variables declaration. Thus it
is possible to *explicitly* export access to that variable, eg by
passing around its ident, without violating the ``spirit'' of lexical
scoping.

[You don't need idents, either; with full lexical scoping, you can pass
around procedures which read and write the variable. Lexical scoping
prevents *accidental* access to the variable, as opposed to dynamic
scoping, provided by dlocal, which can cause unexpected interactions
between code fragments just because of a variable name.]

| This is a point that had never occurred to me nor, it seems, to others
| who had wanted the matcher to be made to work with lvars.

Because it's not relevant. Your code simply provides a lexically
explicit access to the variable; there's nothing wrong with that.

| His argument, therefore (if I understood him), was that calls to the
| matcher should always be "inline" code, so that it was impossible to
| pass the matcher a pattern created elsewhere, or to use the matcher, or
| a procedure using the matcher, as a procedure argument to another
| procedure in which patterns are created.

He's gone ott.

| In fact, that's exactly what LIB FMATCHES does: it defines fmatches as a
| syntactic operator, not a procedure. I had always claimed that that was
| inadequate, because it made it impossible to define things like present,
| remove, allpresent, and other procedures that can take a pattern as
| input.

But patterns should be first-class objects; it's just that their casual
representation as lists (and their early implementations using valof)
made that less obvious.

| Riccardo's argument is that on the contrary, fmatches is right, and
| moreover the other things that operate on patterns should ALL be syntax
| words that occur "inline" with the patterns they act on, e.g. all
| analogues of present, lookup, remove, allpresent, etc. would have to be
| introduced as new syntax words, as forevery and foreach are already.

No, no, no. Simply have a way of writing patterns that *isn't* just a
list; that's the only thing that should be ``inline'', ie, a special
piece of syntax.

| I had previously thought about generalising fmatches in that direction
| but decided that being able to use the matcher as an ordinary procedure
| was too important to give up.

You're right.

All you need do is to provided a syntax for *patterns*. The rest
follows, because the argument that this would violate lexical spirits is
ill-founded.


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