Guards

[Maurizio Cimadamore]

Hi Brian

On 05/03/2021 23:11, Brian Goetz wrote:
> I have long had a nagging feeling that this will eventually be 
> desirable.  Let's say we have P & g & Q & h; under what conditions can 
> we commute g and Q without regret?  I can think of four potential 
> sources of regret:
>
>  - g declares bindings that are inputs to Q
>  - the cost model of Q is such that we'd like to run g first, and 
> short-circuit
>  - Q might throw an exception when g does not hold
>  - Q might have side-effects that we don't want to run if g does not hold

You are right to point out that swapping guards with patterns is not 
free - that said, if a guard doesn't introduce any additional bindings, 
then the first point also is not a concern. Why am I focusing on guards 
that do not introduce new bindings? Simply because, IMHO, a guard after 
a pattern is meant to add extra "imperative" conditions on one or more 
of the bindings that have already been extracted. Sure, you can (in 
principle) also use it to declare additional binding which you can use 
elsewhere - but I'm less sure that this is a use of a guard I would 
agree with.

It seems to me that if you want to use the guard to add extra bindings, 
you can get there by nesting a pattern - e.g.

Point(var x, var y) when pred(x) && pred(y)

vs

Point(pred(var x), pred(var y))

Maurizio