[Grace-core] Some notes on pattern matching on the wiki

[Kim Bruce]

James,

I'm afraid I don't really understand your pattern matching semantics pages.  Is there any chance you can expand them, perhaps by adding examples?  I get lost starting in section 0 where I am not sure what bindings and pattern.boundvariables are to represent (can you give an example) and then in section 1 where I have no idea what the "pattern" is in "pattern.matchObject(pat)".

For the syntax, I'm more partial to the Scala version than newspeak.

> PS - one thing I note, is that "class names" now have another interpretation
> * as the name of the factory object to which one sends new
> * as the name of the type of the resulting instance
> * as the name of the "pattern" used to match against instances.
> 
> I'm not sure how all those names work. One simply solution is to unify these into a single object
> that plays all three roles... 
> 
> James
> _______________________________________________
I'm not in favor of overloading class names in these ways.

I prefer for classes and types to be different (including having different names).  I can live with myClass.toType as representing the type of the objects generated by the class (if we feel we need it), but I will generally want to give types and classes independent names, e.g. PointClass vs Point.

For pattern matching we need to decide whether we want to use types or classes as the basis of the pattern.  I'd personally like to try to stick with types, as to me, the cases are essentially anonymous function declarations and we want the parameters of functions to be annotated with types not classes.  

As an example of the simple use of matching, here is some sample code written for our interpreter.  Please ignore the (many, many!) superfluous "()" pairs as they will eventually go away.  We also need to drop the parameter names in method types (soon!).

       interface OptionNode {
            isNone () -> Boolean
            getOrElse (s:Node) -> Node
       }

       interface Node {
            isNone () -> Boolean
            getOrElse (s:Node) -> Node
            elt () -> String
            setElt(s:String) -> Unit
            next() ->  OptionNode
            setNext (n:OptionNode) -> Unit
	    getIth(count:Number) -> OptionNode
       }

Note that Node extends OptionNode (we don't have "extends" syntax to make this more compact yet).  With this we can write code like the following (e.g. in a method of NodeClass, implementing Node):

                       var returnN: OptionNode
                       match(next()) {
                           case {n: Node -> 
			       returnN := n.getIth(count-1)
			   }
                           case {nn: OptionNode ->
			       returnN := NoneNode()
                           }
                       }

Because the pattern matches go in order, we can pick up both cases correctly (even though a node would match both cases).  

For the more sophisticated pattern matches, we would like to have a method that shows up in the type, perhaps called extractor(), that returns a tuple.  I'm not certain what the best notation would be for this yet.  It might be that we write something like:

                       match(next()) {
                           case {Node(hd:String, tl:OptionNode) -> 
			       ... hd ... tl ...
			   }
                           case {nn: OptionNode ->
                               ...
                           }
                       }

though we could provide very little supporting syntax and just write the following (which might even be clearer -- and we could then let the user decide name the method whatever they want):

                       match(next()) {
                           case {n: Node -> 
			       (hd:String,tl:OptionNode) := n.extractor()
                               ... hd ... tl ...
			   }
                           case {nn: OptionNode ->
			       ...
                           }
                       }

By the way, I haven't seen convincing evidence yet that we need first-class patterns or combining operators on patterns.  [Consider this part of my continuing efforts to keep the language simple!]

Kim