[Grace-core] Comments on matching

[James Noble]

> Reading https://projects.cecs.pdx.edu:8443/~black/NewOOL/index.cgi/wiki/GracePatternMatchingCombinators
> 
> LiteralPatterns assume that there is == defined between arbitrary pairs of objects. Is == object identity?

seems to be, in minigrace at least. Or EGAL. It should be egal.

> I'm confused by the paragraphs that start with
> 
>> "If we had types, reflection to access them ... the next simplest would be a pattern that tests on type. For this example (in minigrace) I assumed a brand field on every object. A BrandPattern? matches by checking the object's brand."

> My confusion is that I don't know from this whether you mean that these patterns (of which I saw no example) are in fact reflective type tests (which means that there should be an explicit mire somewhere, no?) or whether they should be brand tests (which test some aspect of the object's behavior which the designer of that object can control).  To me, this is an absolutely fundamental distinction.

yes it is fundamental - but that distinction doesn't affect the design of the pattern matching framework (if indeed we go this way)
minigrace doesn't have any kind of type, or instanceof, or type test build it an all: I just simulated _something_ to show it could work. 

Either we can implement whatever matching we do natively, or we can translate it e.g. into message requests between patterns and objects -
if we translate it, we will need some lower-level facility to support whatever kind of type/brand tests we decide we do want. 
if we don't translate it, well match/case/blocks will need to do it themselves.

> I don't think that your extract method is typeable.  Suppose A has a field a and that AB is a subtype of A with an extra field b.   The A's extract will return an < a >, while AB's extract will return an < a b >, which is presumably not a subtype of < a >.  Or do you mean the result to always be a list of objects of arbitrary length?

yes you're probably right - although given the returned sequence should probably be immutable, <a b> can be a subtype of <a>;
the return types of extract can be covariant, so it could be typed like that.
For matching to be typesafe, whatever extraction mechanism we do needs to be typesafe.
But, again, the way extraction is done is another point of variation in the overall design.

> The lambda patterns translation stuff was beyond me.

Almost beyond me to - I was quite surprised that I got it all to work.

This does end up close to what I understand as your monadic solution:
each case leg (a LambdaPattern pairing a reified pattern 
and an irrefutable lambda expression that doesn't match) is joined by the Or-combinator. 

We can try and talk about it in the next telecon, or I can try and type more examples.

James