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

[Andrew P. Black]

Begin forwarded message:

> From: James Noble <kjx at ecs.vuw.ac.nz>
> Date: 2 July 2011 22:34:11 PDT
> To: "Andrew P. Black" <black at cs.pdx.edu>
> Subject: Re: [Grace-core] Some notes on pattern matching on the wiki
> 
> Dashing out the door with the family..
> 
> (this went just to me - was there are reason for that -
> if not, can you forward it?)
> 
>>> In, say, Java, you can do all this with just the name "Cat"
>> 
>> Yes, you can. The result is that many Java programmers never learn the difference between types and classes.
> 
> Right. but they can get started more easily *without* knowing that distinction. 
> 
> I'm not sure of the best thing to do here!
> 
>> No, I'm not SURE.  But there is a strong argument that if you want to make clear the difference between two things, you should make them different.
> 
> Yes- which is why this is _so tricky_  
> we are attempting to come up with a conceptual model of programming
> 
>> This is also the argument behind my desire — getting stronger every day that we don't talk about it — to have self.foo(arg) be the syntax for requesting a method (i.e., using dynamic dispatch) on self, and foo(arg) be the syntax for calling a procedure or function, which is lexically (i.e. statically) bound.
> 
> I know, it's lurking there. 
> 
>> Two things => two syntaxes.   Makes for easy teaching and learning.
> 
> Or makes for the argument that we are unnecessarily separating things that are the same.

If they were the same ... but they are not.

> Or makes for the argument that we should have only one of those things.

Yes.  So we could have just factories, and not types.  And we could have only methods, and not lexical bindings.   But I don't think that either of these are viable choices.  

> 
>> I think that having pattern matches go in order might be a mis-feature.  It makes parallel implementation more difficult.  It makes writing a compositional semantics more difficult.  But I'm not sure.
> 
> me neither, again....
> 
>>> I'm never clear what the semantics is when I see these things.  Is the reason that you want a sequential semantics because you assume that all of these things are implicitly in a failure monad of some sort, where success exits the sequencing construct and failure means continue?  (This is just the opposite of the exceptions monad, right). 
>> 
>> If this is the case, maybe we should be looking a general way of creating user-defined structures of this kind.
> 
> oh well - we survived this long without the M-word...
> 
>>>> 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...
>> 
>> It seems to me that this is exactly the choice: build in one or two special things, or build in a general mechanism that lets us define such things.  In Grace right now, we can't define a new semantics for semicolon, but by putting statements in braces, we can  define combinators on statements that are really blocks.    (The composition for the match monad looks like short-circuit OR, and the composition for exceptions looks like short-circuit AND.)
> 
> 
> yes and yes.
> I think that doing the control flow with fail/success block arguments - rather than return  with values - 
> makes the structure harder to see. I'll try again...
> 
> James
>