The discussion about pattern guards has raised two interesting and
(I think) independent questions:
- Nested guards
- Maybes and monads
Here are my thoughts on these things, typed 30,000 feet above Utah!
Simon
Nested guards
~~
Several people have pointed out
Simon wrote:
> For example, in this case we could write (rather less elegantly)
>
> g2 a | (x:xs) <- h a, (y:ys) <- h x = if y<0 then e1
>else if y>0 then e2
>else e3
>
> To avoid this difficulty with functions li
Simon L Peyton Jones writes:
> The discussion about pattern guards has raised two interesting and
> (I think) independent questions:
I think these questions are independent to some degree, but not entirely
unrelated. I have written a few sentences on this in an earlier message,
but perha
| > For example, in this case we could write (rather less elegantly)
| >
| > g2 a | (x:xs) <- h a, (y:ys) <- h x = if y<0 then e1
| >else if y>0 then e2
| >else e3
| >
| > To avoid this difficulty with functions l
| > f c | (i,j) <- Just (toRect c) = ...
|
| I'm afraid this example suffers from the same problem as my "simplify"
| example did: It does not perform a test and can thus be replaced by
|
| f c = ...
| where (i,j) = toRect c
True. I can think of two non-contrived ways in which this
Hi all. Was there ever any sort of consensus about whether pattern
guards ought to be "nestable", or not?
And if not, was there some semantic objection to this, was the syntax
just considered to Unspeakable to be spoken of, or is the feature
just largely redundant? (I think you
I am having a little trouble following the two discussions on pattern
guards and monads, due to some (probably minor) confusing pieces of
syntax. Would anyone like to clarify these for me? It would help me
to understand the underlying issues. Thanks.
On pattern guards, Simon PJ writes
> Now, for monads, Phil Wadler writes a law:
> > m >>= \x -> k x ++ h x = m >>= k ++ n >>= k
>
> in which 'h' appears on the lhs but not the rhs, and 'n' on the rhs but
> not the lhs. ... perhaps the equation should read as follows?
> m >>= \x -> k x ++ h x = m >>= k ++ m >>= h
| On pattern guards, Simon PJ writes:
| > f (x:xs) | x<0 = e1
| > | x>0 = e2
| > | otherwise = e3
|
| then
| > g a | (x:xs) <- h a, x<0 = e1
| > | (x:xs) <- h a, x>0 = e1
| > | otherwise = e3
|
| Am i right in thinking th
of off the top of my head are: taste
and decency; and perhaps heavy reliance on the offside rule,
which might be a bad thing if equation groups get infeasibly large.
> The beauty of flat pattern guards is
> that they have the same syntax as qualifiers in list comprehensions.
Surely thi
> Hi all. Was there ever any sort of consensus about whether pattern
> guards ought to be "nestable", or not?
>
> And if not, was there some semantic objection to this, was the syntax
> just considered to Unspeakable to be spoken of, or is the feature
> just larg
I posted a link to the following on the HaskellTwo
wiki page. Please comment.
I would like to suggest that PatternGuards NOT be included
in HaskellTwo.
While I enjoyed Simon Peyton Jones' well-written
note on pattern guards
[http://research.microsoft.com/Users/simonpj/Haskell/guards.html]
know where I could
get a copy of this proposal?
> I would really welcome feedback on this proposal
Here goes, ...
Reaction to Pattern Guards
==
* I am sure that I have been nobbled by the lack of pattern guards
regularly but have got used to clunking m
I can see the arguments for the pattern guard extension and the syntax
seem reasonable.
I also agree with Chris on the shortcomings of if-then-else. (I have
disliked it in any language where I've seen it, and it "feels"
un-Haskell-like to me.) On the other hand, the suggested
case
| ..
> runRandom last max num
> | num > 1 = runRandom (fst new) max (num-1)
> | otherwise = snd new
> What's the difference between the pipe-syntax, and a case statement,
> i.e. writing the function as
>runRandom last max num = case num of
> 1 -> runRandom
> otherwise -> sn
list comprehensions being 'do' notation limited to the
list monad and pattern guards being the 'do' notation limited to the
identity monad.
> Furthermore, the new syntax confuses the semantics of existing constructs.
>
> Referring to Simon's principal exa
John Meacham <[EMAIL PROTECTED]> writes:
> Oddly enough, I was looking over the old Haskell discussions, and
> pattern guards were supposed to make it into Haskell 98 according to the
> decision. Any idea what happened? did someone just forget to write them
> up or was there
> Now generalize it to more than two cases, or one where the second case
> needs to pattern match too. The magic of pattern guards is not in a
> single guarding expression, but in a function with many different cases
> which use pattern guards.
MonadPlus is your friend, especially if
>I have longstanding dislike of Haskell's expression conditional:
> The problem comes when several conditions are
> present, provoking a rightward march. In this case I use
>
> if test1 then
> part1
> else if test2 then
>
Thanks for feedback about pattern guards. Here are some quick responses.
1. Several people have suggested something along the lines of being
able to backtrack half way through a pattern guard. I considered this
but (a) I couldn't see a nice syntax for it and
(b) it's against
Tommy Thorn writes:
> My only worry is that Haskell (if not already) is turning into the C++
> of functional languages, ie. feature upon feature. Haskell is already
> quite a mouthfull to learn.
This worries me too. Not least is the problem that <- is not a
particularly natural syntax for this
ds to
existing Haskell if/boolean case functionality. But this doesn't, and
can't be made to, do any sort of pattern-binding, so it's not possible
to express pattern guards like this. (Or reduce them to such in the
same style of translation as Chris gave.)
Brian Boutel comments on Simo
> 3. I think it's quite important to use "<-" rather than "=".
> a) it means that the syntax is precisely that of list comprehensions
> b) there's an "=" in the definition already, as Andy points out:
> simplify (Plus e e') | let (Val 0) = s = s'
>
I think Herbert's monadic version of "clunky" is really satisfactory :
>clunky env var1 var2 = fromJust (do val1 <- lookup var1 env
> val2 <- lookup var2 env
> return (var1 + var2)
> ++
>
Errata:
in my previous mail, the text "a la Hoare" should be replaced by "a la
Dijkstra".
Fidel.
At 15:33 17/06/04 -0700, John Meacham wrote:
I think it was a couple things, Pattern guards were introduced which
were conceptually a whole lot simpler and provided a way to do many of
the things views did.
http://research.microsoft.com/~simonpj/Haskell/guards.html
I like that proposal.
In
uence proof has been mechanised using Isabelle.
So far I never considered it important to devise a concrete syntax for PMC,
but triggered by the current pattern guards thread on haskell-prime,
I now try to give a PMC syntax that blends well with Haskell.
PMC ``automatically'' includes
the ``e
t match failure) can be represented as do-blocks:
lhs->rhs ==> \x->do { lhs <- return x; return rhs } (1)
and then be composed (the examples I gave moved the \s to
the front instead and used "mplus" to compose matchings, but
we could also lift the compositions to functi
quot;sugar" become
> part of Haskell's core, which thus becomes more complex,
> without offering sufficient compensation in terms of expressiveness.
I agree. The pattern matching problem is best solved by supplying sugar
which either is compositional or fundamental.
The composi
I see that <= is already used... Let's take <~ (tilde) instead.
A "pseudo-sugared" version in plain Haskell for
f (Right (Right p)) = p
f (Left p) = p
f p = p
that is
f p = fromJust $
| Right q <~ p
| Right r <~ q = r
| Left q <~ p = q
compose matchings, but we could also lift
the compositions to function-level instead), and finally "spliced"
back (turning explicit into implicit match failure) using fromJust or
suchlike. Adding pattern guards into this translation was
straightforward - they simply go between the two
(Apologies, I forgot to change the subject)
Laszlo Nemeth <[EMAIL PROTECTED]> writes:
> * * * Ketil Malde <[EMAIL PROTECTED]> wrote:
> There is no difference. The 'pipe-syntax' (or pattern guards) gets
> desugared (by the pattern matching compiler) to cas
> But if you want to be really weird you can write something
> like (I haven't typed this in):
>
> f x | (Foo _) == x =
> f x | (Bar _) == x =
no, you can't, e. g. hugs (Feb 2000) says
Prelude> let f x | Just 4 == x = 0 in f (Just 4)
0
Prelude> let f x | Just _ == x = 0 in f (Just 4)
ERROR: I
* * * Johannes Waldmann wrote:
> > But if you want to be really weird you can write something
> > like (I haven't typed this in):
> >
> > f x | (Foo _) == x =
> > f x | (Bar _) == x =
>
> no, you can't, e. g. hugs (Feb 2000) says
>
> Prelude> let f x | Just 4 == x = 0 in f (Just 4)
> 0
> Prel
On Thu, Mar 01, 2001 at 09:40:48AM +0100, Ketil Malde wrote:
>
> (Apologies, I forgot to change the subject)
>
> Laszlo Nemeth <[EMAIL PROTECTED]> writes:
>
> > * * * Ketil Malde <[EMAIL PROTECTED]> wrote:
>
> > There is no difference. The 'pipe
* * * Ketil Malde <[EMAIL PROTECTED]> wrote:
> ut - the converse is not true, is it? I can write
>
> ... = case foo of
>(Foo f) -> ...
>(Bar b) -> ...
>
> ut I can't express that as a pattern-guarded expression, can I?
You probably have already seen John's
Thu, 1 Mar 2001 20:25:28 +0900 (KST), Laszlo Nemeth <[EMAIL PROTECTED]> pisze:
> > Prelude> let f x | Just _ == x = 0 in f (Just 4)
> > ERROR: Illegal `_' in expression
>
> So it works with (Just 4), but it doesn't with (Just _)?
'Just _ == x' must be an exppression. '_' is a pattern but not an
37 matches
Mail list logo
