[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