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

[James Noble]

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

So this is an important issue.
Let's think about an example.

class Cat { name' : String ->  
 const name : String := name 
 method purr {print "Purr"} 
 method new {print "Meow"}
} 

var c : Cat 

c := Cat.new("Macavity")

In, say, Java, you can do all this with just the name "Cat"


Do we want to ensure all first or second week programmers have to type:

var c : CatType
c := CatFactory.new("Macavity")

or alternatively

var c : Cat.type
c := Cat.factory.new("Macavity") 


are we really sure? 



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

yep sure. 

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

yes that's right - I think this is a feature :-)

(there seems to be an extra parent in that example match, btw)

> 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:
>                          case {Node(hd:String, tl:OptionNode) -> 

right, yes we want to support something like this

> 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):
> 			       (hd:String,tl:OptionNode) := n.extractor()

well this has the advantage of not requiring any extra match syntax! 

> 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!]

we don't. As I implied earlier: they are worth it only if we get them for free...

James