[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Dec 4 18:20:36 1995 
Subject:Re: Making the matcher robust? 
From:Chris Dollin 
Volume-ID:951204.03 

Jon wrote:

| I often write code (in languages other than pop11) which use a
| procedural matcher (i've lost count of how many times i've written
| simple, one-off, dedicated matchers :-). [Presumably anathema to
| Chris Dollins ;-)].

No, no. I prefer generality, but it's always nice to have another go at
rewriting code.

| If I had to now add matching to pop11, I would do it like this.
| (1) use instances of a pattern variable class, instead of query
| variable-name. A bit like the way prolog unification works.
| (2) provide two pieces of syntactic sugar: to initialise lvars to
| instances of pattern objects, and to de-reference them.

I'd provide some pattern constructors and accessors, plus a matching
primitive (of course), and probably some syntactic sugar for the boring
cases.

[Oh rats, I've just accidentally justified the rest of jon's message,
making it unquotable. Still ...]

For example, I'd have pattern constructors

    pattern_id( name )          A pattern variable
    pattern_ident name          Ditto, except bound to ``ident name''
    pattern_id_value( pattern ) Gets value from pattern_id

plus the obvious

    pattern_seq( p1, p2 )       Sequencing
    pattern_alt( p1, p2 )       Alternative
    pattern_rep( p )            Repetition
    pattern_sat( p, pred )      Pattern constrained by predicate

plus

    pattern_match_bool( target, pattern )   simple test
    pattern_match_how( target, pattern )    test + answers

the latter returning the ``results'' in terms of what matched how,
probably as stuff on the stack, but with lists and vectors as
alternatives. Other possibilities come readily to mind. For example,
there's no reason to constrain matching to lists; matching over records
and vectors would be natural.

As with Jon's example, the details (such as the actual names of the
constructors) would need deeper thought. And there would be special
syntax for common cases, so one could write:

    if [% "a", "b" %] @pattern_match_how ## [?a ?b] then
        -> lvars (a, b, two);
        ...
    else
        ;;; either nothing or 0 on the stack, need to think about it
    endif

``## [?a ?b]'' is just syntax for something like

    pattern_seq( pattern_id( "a" ), pattern_seq( pattern_id( "b" ), [] ) )




Regards | "Always code as if the guy who ends up maintaining your code will be
Kers.   | a violent psychopath who knows where you live." - John F. Woods