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