[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pattern Binding



Date: Fri, 29 May 1992 15:32:04 +0200
From: Kevin Hammond <kh@dcs.glasgow.ac.uk>
Sender: haskell-request@dcs.glasgow.ac.uk
To: simonpj@dcs.glasgow.ac.uk
Cc: brian@comp.vuw.ac.nz, haskell@dcs.glasgow.ac.uk, norman@a.cs.okstate.edu
Subject: Re: Pattern Binding

> There are two issues going on here.
> 
> 1. Should pattern variables be permitted in the guard?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Haskell's reply: yes, but the result is always bottom.

Technically, it's only bottom if the pattern variables are evaluated.
This might seem rather subtle.  After all,

	(x,y) | z > 1 || x < 1 = (2,3)
	z = 2

terminates!   Why not

	(x,y) | z > 1 || x < 1 = (2,3)
	z = 0

> 	- you need to evaluate the guard to discover which 
> 		RHS to bind the pattern to
> 	- but you need to choose a particular RHS in order to evaluate
> 		the guard

True, but this is quite a weak argument in favour of the status quo.
It applies equally well to the the translations I gave.

I don't see a problem with my first translation, since a RHS will be
evaluated exactly when a bound value is needed in a guard, or the
guard evaluates to True.  That doesn't seem to change the semantics
of normal pattern bindings:

	(x,y) | z > 2 = (2,3)

==	(x,y) = let x1@(x,y) = (2,3) in if z > 2 then x1 else error

=	(x,y) = if z > 2 then (2,3) else error

[by substitution].  Is there a subtlety that I'm missing?

> 2. If the RHS chosen by the first guard to return True does not match
> the pattern, should the next RHS with a valid guard be tried.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> We didn't consider this during the design process.
> [...]
> I'm far from convinced that this is a feature though.

I'm not convinced myself, but I wanted to show that there was a simple
source translation in case someone wanted to pick this up...

Kevin