#3822: pattern guards in arrow notation (Arrows extension) case statement cause
compiler panic
--+-
Reporter: StephenBlackheath | Owner:
Type: bug
#3822: pattern guards in arrow notation (Arrows extension) case statement cause
compiler panic
--+-
Reporter: StephenBlackheath | Owner:
Type: bug
-time crash
--+-
Changes (by ross):
* keywords: arrows pattern guards case panic = arrows guards case panic
* os: Linux = Unknown/Multiple
* architecture: x86_64 (amd64) = Unknown/Multiple
--
Ticket URL: http
#2017: Normal Guards are internally spliced as Pattern Guards causing compiler
warnings
--+-
Reporter: fons | Owner: igloo
Type: merge | Status: closed
Priority: normal
#2017: Normal Guards are internally spliced as Pattern Guards causing compiler
warnings
--+-
Reporter: fons | Owner: igloo
Type: merge | Status: new
Priority: normal
Greetings!
We've been working to add pattern guards to the Haskell' report, and
doing some cleanup work on the repository. Not all of the emails are
making it to the list, sadly, but here's a list of recent changes from
the report.
You can view the report itself here (I couldn't think
Thu Jan 11 15:51:14 PST 2007 [EMAIL PROTECTED]
* update pattern binding translation for pattern guards (with Iavor's help!)
M ./report/decls.verb -7 +9
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman
account of types, and read every
((e :: Bool) :: Monad m = m _)
in a statement of a do block as a shorthand for
(guard (e :: Bool) :: Monad m = m ())
(b) missing return in pattern guards
this could be made to fit the general pattern, if we had (return == id
Donald Bruce Stewart [EMAIL PROTECTED] wrote:
The joy of pattern guards
reveals once you have more conditions.
I wrote:
Of course, this is not really the joy of
pattern guards. It is the joy of monads,
with perhaps a few character strokes
saved by a confusing overloading of (-).
Philippa
On Wed, 13 Dec 2006, Yitzchak Gale wrote:
Yitzchak Gale wrote:
Of course, this is not really the joy of
pattern guards. It is the joy of monads,
with perhaps a few character strokes
saved by a confusing overloading of (-).
Philippa Cowderoy wrote:
I don't find it any more
On Wed, 13 Dec 2006, Yitzchak Gale wrote:
Philippa Cowderoy wrote:
I don't find it any more confusing than the overloading
of -.
I wrote:
You mean that it is used both for lambda abstractions
and for functional dependencies? True, but those
are so different that there is no
Philippa Cowderoy wrote:
This is what I get for replying straight away!
Oh, no, I'm happy that you responded quickly.
I think my point is that I'm not aware of many people
who actually think this is a problem or get confused.
Well, I don't mean that this is something that experienced
Hi,
I am not clear why you think the current notation is confusing...
Could you give a concrete example? I am thinking of something along
the lines: based on how - works in list comprehensions and the do
notation, I would expect that pattern guards do XXX but instead, they
confusingly do YYY
Iavor Diatchki wrote:
I am not clear why you think the current notation is confusing...
Could you give a concrete example? I am thinking of something along
the lines: based on how - works in list comprehensions and the do
notation, I would expect that pattern guards do XXX but instead
I am not clear why you think the current notation is confusing...
Could you give a concrete example? I am thinking of something along
the lines: based on how - works in list comprehensions and the do
notation, I would expect that pattern guards do XXX but instead, they
confusingly do YYY. I
Hi
in spite of their similarity, all of these constructs handle some of the
monadic aspects differently. the translations of pattern guards not only
embed statements in guard, they also embed the right hand sides of
generators in return. translations of list comprehensions only lift
statements
Yitzchak Gale writes:
Philippa Cowderoy wrote:
I don't find it any more confusing than the overloading
of -.
I wrote:
You mean that it is used both for lambda abstractions
and for functional dependencies? True, but those
are so different that there is no confusion.
Oh, and case.
Donald Bruce Stewart [EMAIL PROTECTED] writes:
The joy of pattern guards
reveals once you have more conditions.
Of course, this is not really the joy of
pattern guards. It is the joy of monads,
with perhaps a few character strokes
saved by a confusing overloading of (-).
But some people do
On Wed, 13 Dec 2006, Yitz Gale wrote:
Donald Bruce Stewart [EMAIL PROTECTED] writes:
The joy of pattern guards
reveals once you have more conditions.
Of course, this is not really the joy of
pattern guards. It is the joy of monads,
with perhaps a few character strokes
saved
[EMAIL PROTECTED] wrote:
suggestion: undo removal of guards from lambdas, especially
(but not only) if pattern guards make it into the language.
See the existing proposals
http://hackage.haskell.org/trac/haskell-prime/wiki/LambdaCase
http://hackage.haskell.org/trac/haskell-prime/wiki
On Thu, Oct 19, 2006 at 12:55:48PM +0100, Simon Marlow wrote:
As for extending lambda to allow multiple guards and/or multiple pattern
matches, I don't think we need that either. Lambda is a quiet syntax
and will be lost at the beginning of a sequence of pattern
matches/guards; it's best used
Claus Reinke [EMAIL PROTECTED] wrote:
since Pattern Guards appear to be popular with the committee,
I suggest to revisit the decision to drop guards from lambdas:
suggestion: undo removal of guards from lambdas, especially
(but not only) if pattern guards make it into the language.
See
suggestion: undo removal of guards from lambdas, especially
(but not only) if pattern guards make it into the language.
See the existing proposals
http://hackage.haskell.org/trac/haskell-prime/wiki/LambdaCase
http://hackage.haskell.org/trac/haskell-prime/wiki/MultiWayIf
thanks. I'm
Hello Claus,
Wednesday, October 18, 2006, 2:44:29 PM, you wrote:
(\ arms ) x
this looks great. smth like:
proc $ \[x] - x*2
\[x,y] - x*y
\[]- 0
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
since Pattern Guards appear to be popular with the committee,
I suggest to revisit the decision to drop guards from lambdas:
(a) http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg00353.html
(b) http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg00382.html
1. I disagree
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 returns.
Note that it is very much this issue of 'monadic choice
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 returns.
Note that it is very much this issue of 'monadic choice
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 compositional structure behind pattern guards is of course
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
|
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 compositional structure behind pattern guards is of course
(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 function-level instead),
and finally spliced back (turning explicit into implicit match
failure) using fromJust or suchlike. Adding pattern guards
Brandon Moore [EMAIL PROTECTED] wrote in his answer to my PMC syntax
proposal:
Maybe the '\' could be reiterated to introduce the layout group:
take' = \
0 _ - []
n \[] - []
(x:x) - x : take (pred n) xs
Definitely not, since the lambda gets us back into expressions,
destroying the
and improving pattern guards with PMC syntax
In-Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
...
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
I wrote:
...the main monad at work here is the Exit monad.
Ross Paterson wrote:
...if we define
exitMaybe :: Exit e () - Maybe e
exitMaybe (Continue _) = Nothing
exitMaybe (Exit e) = Just e
then we have
runExit m = fromJust (exitMaybe m)
exitMaybe (x
,
and restricted to something like the exit monad you
mention in pattern guards. They are all consistent
uses of (-).
No, they are not the same. Bind in a list comprehension
translates to the exact same bind in do notation.
I cannot think of any translation of pattern guards for
which the same thing
On Mon, Oct 02, 2006 at 11:58:44PM +0200, Yitzchak Gale wrote:
Ross Paterson wrote:
...if we define
exitMaybe :: Exit e () - Maybe e
exitMaybe (Continue _) = Nothing
exitMaybe (Exit e) = Just e
Maybe monads quit on failure and
continue on success. We want the
(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 function-level instead),
and finally spliced back (turning explicit into implicit match
failure) using fromJust or suchlike. Adding pattern guards
[EMAIL PROTECTED] wrote:
...
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.
I think with some alterations your syntax would blend
---
the confluence 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
On Sun, Oct 01, 2006 at 02:08:35AM +0200, Yitzchak Gale wrote:
An important clarification: the main monad at work
here is the Exit monad. The bind notation in a
pattern guard is just an obfuscated Exit monad.
However, in many simple examples, the Maybe monad
can be used as a special case of
Claus Reinke wrote:
If it wasn't for those pesky returns/guards, one might claim the
translations
to be as concise as the originals. As it stands, the results of the
translation
are rather more awkward but -and this is the important point- pattern
guards do not add new functionality.
Well
is incomplete... This
translation does not appear to address programs
with multiple left-hand sides, exploiting
fall-through from match (hence guard) failure
Quite right, sorry. That is easy to fix. A
corrected proof is at the bottom of this message.
David Roundy wrote:
If all your pattern guards
Conor McBride wrote:
Claus Reinke wrote:
...the results of the translation are rather
more awkward but -and this is the important
point- pattern guards do not add new
functionality.
Well, neither do Boolean guards nor even basic
pattern matching... one simply should not need
to clutter
On 10/1/06, Yitzchak Gale [EMAIL PROTECTED] wrote:
Conor McBride wrote:
Claus Reinke wrote:
...the results of the translation are rather
more awkward but -and this is the important
point- pattern guards do not add new
functionality.
Well, neither do Boolean guards nor even basic
I would like to suggest a correction to ticket #56,
Pattern Guards.
It is easy to show that every expression written
using pattern guards can also be written in
Haskell 98 in a way that is essentially
equivalent in simplicity. (Proof below.)
In my opinion, the Haskell 98 version below is
more
On Thu, Sep 28, 2006 at 04:40:30PM +0300, Yitzchak Gale wrote:
Now given any function binding using pattern guards:
funlhs
| qual11, qual12, ..., qual1n = exp1
| qual21, qual22, ..., qual2n = exp2
...
we translate the function binding into Haskell 98 as:
funlhs = runExit $ do
Hi
Yitzchak Gale wrote:
I would like to suggest a correction to ticket #56,
Pattern Guards.
It is easy to show that every expression written
using pattern guards can also be written in
Haskell 98 in a way that is essentially
equivalent in simplicity. (Proof below.)
Whether or not your
Hello,
I think that pattern guards are a nice generalization of ordinary
guards and they should be added to the language. Of course, as you
point out, we can encode them using the Maybe monad, but the same is
true for nested patterns, and I don't think that they should be
removed from Haskell
Hello Conor,
Thursday, September 28, 2006, 10:30:46 PM, you wrote:
gcd x y | compare x y -
LT = gcd x (y - x)
GT = gcd (x - y) y
gcd x _ = x
or some such. I wish I could think of a better example without too much
context, but such a thing escapes me for the moment. In general,
Hello,
This particular example we can do with pattern guards
(although it seems that a simple 'case' is more appropriate for this example)
On 9/28/06, Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Conor,
Thursday, September 28, 2006, 10:30:46 PM, you wrote:
gcd x y | compare x y -
LT
On Fri, Sep 29, 2006 at 02:59:49AM +0300, Yitzchak Gale wrote:
Iavor Diatchki wrote:
I think that the benefit of adding pattern guards is... it provides
a concise notation
Not significantly more concise than existing notation.
That's just not true. If all your pattern guards happen
Matthew Cox wrote:
One example given in this discussion is:
clunky env var1 var1 = case lookup env var1 of
Nothing - fail
Just val1 - case lookup env var2 of
Nothing - fail
Just val2 - val1 + val2
where
fail = val1 + val2
this needs to be fixed to:
clunky env var1 var1 = case
One example given in this discussion is:
clunky env var1 var1 = case lookup env var1 of
Nothing - fail
Just val1 - case lookup env var2 of
Nothing - fail
Just val2 - val1 + val2
where
fail = val1 + val2
this needs to be fixed to:
clunky env var1 var1 = case lookup env var1 of
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]
very
On Mon, Mar 28, 2005 at 02:17:46PM +0200, Yitzchak Gale wrote:
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
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 (fail s
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
(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 case statements i.e.:
runRandom = \ last max
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-syntax' (or pattern guards) gets
desugared (by the pattern
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 - snd new
* * * 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 reply
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: Illegal
* * * 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
Prelude let f x |
08:58
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: pattern guards
|
|
| Hi Simon,
|
| I dimly recall that ghc once supported pattern guards, which
| was (if I
| remember correctly) some way to bind variables in the guard of a
| pattern match. Is this feature still available
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 this would also be t
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 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 largely redundant? (I think you
| 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
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
Yes, of course it
Simon wrote:
For example, in this case we could write (rather less elegantly)
g2 a | (x:xs) - h a, (y:ys) - h x = if y0 then e1
else if y0 then e2
else e3
To avoid this difficulty with functions like g2...
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)
++
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 Simon's:
CONCLUSION: "let" should be allowed, but should introduce mul
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'
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 my way round the p
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
|
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 the spirit
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
79 matches
Mail list logo
