[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Dec 1 20:40:53 1995 
Subject:Re: Making the matcher robust? 
From:A . Sloman 
Volume-ID:951201.09 

Thanks for the further comments.

[AS]
> | 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;

I am not sure what you mean by that. If you mean they should be objects
that can be created at run time, returned as procedure values, stored in
datastructures, passed as arguments, etc. then I agree with you. I think
Riccardo was claiming that such objects should not include lvars
identifiers that could be changed by valof anywhere.

This is different from the case of creating a lexical closure, which is
a procedure that can manipulate values of lexical variables, for there
all the code that does the manipulation is explicit within the scope of
the variable.

On the other hand if you aleady have a language that allows lists,
arrays and other datastructures to be updated outside the context in
which they are created, giving heebee jeebees to those committed to
functional programming, then perhaps there's not so much of a problem
allowing lexical variables also to be changed by hidden code.

> ..it's just that their casual
> representation as lists (and their early implementations using valof)
> made that less obvious.

Not sure what you mean by "casual representation as lists". It's obvious
that as lists they are first class objects, isn't it?

[AS]
> | 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.

Depends what's in the patterns. If they contain special data structures
then there's no problem. If they contain lexical identifiers you can
have code of this form

	lvars x .....;
		.... x ....

	foo(<pattern .... x ....>);

		.... x ....

and then the changes between the second and the fourth occurrences of
"x" are unpredictable, just as with the current matcher.

I suspect that what you are saying is close to what Riccardo said. I
elaborated it, perhaps misleadingly. (he's away for a few days, so I
can't ask him.) I think his main point was to object to my construct

	![ .......]

which creates an object that contains lexical identifiers that can then
be passed out of the current lexical scope and directly manipulated
elsewhere using valof or idval. My impression was that you don't seem to
like that either: you want any such use of patterns to return some
explicit values, like the Pop-11 "which" construct
	
    which([x z], [[parent ?x ?y][parent ?y ?z]]) =>
    ** [ [tom harry] [tom mary] [lucy albert] ]

except that which ALSO gives x,y and z new values.

(See HELP WHICH, LIB * WHICH).

It has occured to me that I could change "!" so that it turns a pattern
into a declaration. I.e. the variables in the pattern are declared
as lvars, and can be used only AFTER the pattern has been created.

Thus

	lvars x;

		..... x .....

		.... ![ .... ?x ....] ....

		... x ....

would not be allowed, but
		.... ![ .... ?x ....] ....

		... x ....

would, with no preceding use of x in the same scope (except maybe
a use in a pattern!).

However, this would require access at compile time to the current list
of locally declared variables in the current lexical block. I don't know
if pop_new_lvar_list already has all the relevant information.

Aaron