Re: [GHC] #2431: Allow empty case analysis
#2431: Allow empty case analysis
---+
Reporter: RalfHinze | Owner:
Type: feature request | Status: closed
Priority: low | Milestone: _|_
Component: Compiler |Version: 6.8.3
Resolution: fixed | Keywords: empty case
analysis
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: deSugar/should_compile/T2431 | Blockedby:
Blocking:|Related:
---+
Changes (by simonpj):
* status: new = closed
* testcase: = deSugar/should_compile/T2431
* resolution: = fixed
Comment:
Here it is:
{{{
commit 3671e674757c8f82ec1f0ea9b7c1ed56340b55bc
Author: Simon Peyton Jones simo...@microsoft.com
Date: Fri Jan 4 10:27:38 2013 +
Allow empty case expressions (and lambda-case) with -XEmptyCase
The main changes are:
* Parser accepts empty case alternatives
* Renamer checks that -XEmptyCase is on in that case
* (Typechecker is pretty much unchanged.)
* Desugarer desugars empty case alternatives, esp:
- Match.matchWrapper and Match.match now accept empty eqns
- New function matchEmpty deals with the empty case
- See Note [Empty case alternatives] in Match
This patch contains most of the work, but it's a bit mixed up
with a refactoring of MatchGroup that I did at the same time
(next commit).
compiler/deSugar/DsExpr.lhs | 13 +---
compiler/deSugar/DsUtils.lhs |2 +-
compiler/deSugar/Match.lhs| 55
-
compiler/deSugar/MatchCon.lhs |3 +-
compiler/deSugar/MatchLit.lhs |2 +-
compiler/main/DynFlags.hs |4 ++-
compiler/parser/Parser.y.pp |2 +
compiler/rename/RnBinds.lhs | 18 ++--
docs/users_guide/glasgow_exts.xml | 38 +
9 files changed, 106 insertions(+), 31 deletions(-)
}}}
but it also needs the follow up
{{{
commit a8941e2a4fe3b000e6c085701e0c015c5316c6ee
Author: Simon Peyton Jones simo...@microsoft.com
Date: Fri Jan 4 10:30:14 2013 +
Refactor HsExpr.MatchGroup
* Make MatchGroup into a record, and use the record fields
* Split the type field into two: mg_arg_tys and mg_res_ty
This makes life much easier for the desugarer when the
case alterantives are empty
A little bit of this change unavoidably ended up in the preceding
commit about empty case alternatives
compiler/deSugar/Coverage.lhs| 12 ++--
compiler/deSugar/DsArrows.lhs| 13 ++---
compiler/deSugar/DsExpr.lhs |8
compiler/deSugar/DsGRHSs.lhs | 14 +++---
compiler/deSugar/DsMeta.hs | 10 +-
compiler/hsSyn/HsExpr.lhs| 28 +---
compiler/hsSyn/HsUtils.lhs |2 +-
compiler/parser/RdrHsSyn.lhs |8
compiler/rename/RnBinds.lhs |4 ++--
compiler/rename/RnExpr.lhs |2 +-
compiler/rename/RnTypes.lhs |2 +-
compiler/typecheck/TcArrows.lhs |9 ++---
compiler/typecheck/TcBinds.lhs |4 ++--
compiler/typecheck/TcHsSyn.lhs |7 ---
compiler/typecheck/TcMatches.lhs | 14 --
15 files changed, 70 insertions(+), 67 deletions(-)
}}}
and
{{{
commit 74d401860d6a28244b9a12fca844fe14a6a04274
Author: Simon Peyton Jones simo...@microsoft.com
Date: Fri Jan 4 10:30:53 2013 +
Switch on -XEmptyCase when renaming derived declarations
Compiler-generated code can have empty cases
---
compiler/typecheck/TcDeriv.lhs |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:14
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: Allow empty case analysis
#2431: Allow empty case analysis +--- Reporter: RalfHinze| Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.3 Keywords: empty case analysis | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | +--- Comment(by simonpj): Oh ok I'll join up the final dots... patch coming. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: Allow empty case analysis
#2431: Allow empty case analysis +--- Reporter: RalfHinze| Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.3 Keywords: empty case analysis | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | +--- Comment(by igloo): What's the status of this? ac230c5ef652e27f61d954281ae6a3195e1f9970 from #6067 sounds like it implements this, but it looks like it only allows it in core, not Haskell? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: Allow empty case analysis (was: allow empty case analysis)
#2431: Allow empty case analysis
+---
Reporter: RalfHinze| Owner:
Type: feature request | Status: new
Priority: low | Milestone: _|_
Component: Compiler | Version: 6.8.3
Keywords: empty case analysis | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
+---
Comment(by simonpj):
I didn't find the above entirely clear, so Richard elaborates: consider:
{{{
data a :~: b where
Refl :: a :~: a
absurd :: True :~: False - a
}}}
Now, I want to write a term binding for `absurd`. Here are two candidates:
{{{
absurd x = error absurd-- (A)
absurd x = case x of {} -- (B)
}}}
I much prefer (B). Why? Because GHC can figure out that `(True :~:
False)` is an empty type. So (B) has no partiality and, (if #3927 is
fixed) I should be able to compile with `-fwarn-incomplete-patterns` and
`-Werror`.
On the other hand (A) looks dangerous, and GHC doesn't check to make sure
that, in fact, the function can never get called.
The bottom line, for me at least, is that I want to avoid the partial
constructs (incomplete patterns, undefined, etc) in Haskell as much as
possible, especially when I'm leveraging the type system to a high degree.
The lack of empty case statements forces me to use undefined where it
isn't really necessary.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:11
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: allow empty case analysis
#2431: allow empty case analysis
+---
Reporter: RalfHinze| Owner:
Type: feature request | Status: new
Priority: low | Milestone: _|_
Component: Compiler | Version: 6.8.3
Keywords: empty case analysis | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
+---
Changes (by goldfire):
* cc: eir@… (added)
* failure: = None/Unknown
Comment:
Now that GHC is getting more dependently typed features, an empty case
seems more useful. For example, I would like to define the following:
{{{
data a :==: b where
Refl :: a :==: a
data EmptySet
type Not a = a - EmptySet
type DecidableEquality (a :: k) (b :: k) = Either (a :==: b) (Not (a :==:
b))
data SBool :: Bool - * where
SFalse :: SBool False
STrue :: SBool True
eqBoolDec :: SBool a - SBool b - DecidableEquality a b
eqBoolDec SFalse SFalse = Left Refl
eqBoolDec STrue STrue = Left Refl
eqBoolDec SFalse STrue = Right (\case {})
eqBoolDec STrue SFalse = Right (\case {})
}}}
Even if empty pattern matches were allowed, I recognize that this would
just produce an (erroneous) incomplete pattern match warning, because of
bug #3927. But, once that is fixed, empty pattern matches would have a new
lease on life.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:10
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: allow empty case analysis
#2431: allow empty case analysis
-+--
Reporter: RalfHinze| Owner:
Type: feature request | Status: new
Priority: low | Milestone: _|_
Component: Compiler |Version: 6.8.3
Severity: minor| Resolution:
Keywords: empty case analysis | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-+--
Comment (by simonmar):
Replying to [comment:6 [EMAIL PROTECTED]:
I tried to think of how parsing might go wrong. Consider the following
(contrived) example:
{{{
case foo of
[] -
case bar of
(x:xs) -
baz
}}}
Did you spot that the second alternative is indented with a tab rather
than spaces, (with editor tab width set to 2 instead of 8)?
I realise the example is contrived, but I don't think we need to consider
it. The Haskell report defines tab stops to be 8 characters apart, so you
should always have your editor set to use 8-character tab stops when
editing Haskell code, because that's how the compiler sees it. Anything
else will cause confusion, in many more ways than just the example above.
If you don't like 8-char tabs then fine: use spaces instead, and `-fwarn-
tabs`, but you should still set your editor to use 8-char tabs so that you
can read other people's code.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:7
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: allow empty case analysis
#2431: allow empty case analysis
-+--
Reporter: RalfHinze| Owner:
Type: feature request | Status: new
Priority: low | Milestone: _|_
Component: Compiler |Version: 6.8.3
Severity: minor| Resolution:
Keywords: empty case analysis | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-+--
Comment (by [EMAIL PROTECTED]):
I tried to think of how parsing might go wrong. Consider the following
(contrived) example:
{{{
case foo of
[] -
case bar of
(x:xs) -
baz
}}}
Did you spot that the second alternative is indented with a tab rather
than spaces, (with editor tab width set to 2 instead of 8)? So although I
_intended_ to have the two alternatives for the outer case, and the inner
case empty, in fact the second pattern is indented further than the first,
and so there is a single alternative for each of the inner and outer
cases?
Well, I did say it was contrived. -fwarn-incomplete-patterns would catch
it.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:6
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: allow empty case analysis
#2431: allow empty case analysis -+-- Reporter: RalfHinze| Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler |Version: 6.8.3 Severity: minor| Resolution: Keywords: empty case analysis | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -+-- Changes (by simonpj): * priority: normal = low * milestone: 6.12 branch = _|_ Comment: OK so I don't like GHC crashing, ever, so I have done the following: * In the renamer and typechecker, I allow empty `HsCase`. * In Core I still don't allow empty `Case`. I have no idea what stuff would break if empty `Case` was allowed; but even finding the type of an expression might become impossible. (Yes, at the moment `Case` records its result type, but with the new FC stuff that's not necessary and I may remove it.) And I see no reason to support it. * In the desugarer, I desguar empty `HsCase` to a call to `error`. (The simplifier already does this if it can figure out that a case is empty; see `Simplify.rebuildCase`.) So now Neil's TH example works instead of crashing. The parser prevents you doing this in source code, so I have not added a flag. To go the full distance we still need: * Parser to accept empty case expressions (currently rejected by parser) * -X flag to control this language extension * Test somewhere (in renamer) to check that empty case only happens when flag is on. * User manual docs * Regresssion tests in test suite. All easy but tiresome. If you care about this, send a patch! I've done the slightly-tricky bits. So I'll leave this bug open at low priority, milestone bottom. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: allow empty case analysis
#2431: allow empty case analysis -+-- Reporter: RalfHinze| Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler |Version: 6.8.3 Severity: minor| Resolution: Keywords: empty case analysis | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -+-- Changes (by igloo): * milestone: = 6.12 branch Comment: Perhaps this would be better proposed for Haskell'? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: allow empty case analysis
#2431: allow empty case analysis
-+--
Reporter: RalfHinze| Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler |Version: 6.8.3
Severity: minor| Resolution:
Keywords: empty case analysis | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-+--
Changes (by simonpj):
* difficulty: = Unknown
Old description:
Using -XEmptyDataDecls I can declare an (almost) empty data type.
data Void
However, I can't use an empty case to discriminate values of the
empty type.
This does not work:
get :: Void - a
Only the type signature, but no body. [This would be useful also
in other circumstances.]
get :: Void - a
get v = case v of { }
An empty case in the body.
New description:
Using -XEmptyDataDecls I can declare an (almost) empty data type.
{{{
data Void
}}}
However, I can't use an empty case to discriminate values of the
empty type.
This does not work:
{{{
get :: Void - a
}}}
Only the type signature, but no body. [This would be useful also
in other circumstances.]
{{{
get :: Void - a
get v = case v of { }
}}}
An empty case in the body.
Comment:
Why is this useful? The only value of type `Void` is bottom.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: allow empty case analysis
#2431: allow empty case analysis
-+--
Reporter: RalfHinze| Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler |Version: 6.8.3
Severity: minor| Resolution:
Keywords: empty case analysis | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-+--
Comment (by NeilMitchell):
This would be somewhat useful for the Derive tool
(http://www.cs.york.ac.uk/fp/darcs/derive), and in general for program
generation. Consider the automatically derived instance for Show, on an
empty data type. What you are likely to get is:
{{{
instance Show Void where
}}}
i.e. the complete absense of anything. If you changed the generator to
make a case statement, you could get:
{{{
instance Show Void where
show x = case x of {}
}}}
Which is a more accurate reflection of what was intended, and I think the
point Ralf is trying to make. Derive probably goes wrong with empty data
types, but if it didn't, this extension would be helpful.
I tried to construct an empty case with Template Haskell, and crashed GHC:
{{{
C:\Neil\Tempghci -fth
GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Prelude :m Language.Haskell.TH
Prelude Language.Haskell.TH $(caseE (litE $ CharL 'a') [])
: panic! (the 'impossible' happened)
(GHC version 6.8.2 for i386-unknown-mingw32):
readFilledBox t_a1b5{tv} [box]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2431: allow empty case analysis
#2431: allow empty case analysis -+-- Reporter: RalfHinze| Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler |Version: 6.8.3 Severity: minor| Resolution: Keywords: empty case analysis | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -+-- Changes (by Isaac Dupree): * cc: [EMAIL PROTECTED] (added) Comment: Of course, with the correct warning flags enabled, empty case of a non- empty type will produce an incomplete pattern match warning: exactly when we want a warning for using this construct. I suppose the effect is to throw a pattern-match error that is independent of the case'd value, as consistent with all patterns of any other case statement failing? (rather than using it if it's _|_, as of course it will be if it's an empty type: because, unlike in GHC Core, source-Haskell 'case' does not introduce strictness) +1, I've occasionally wanted this to be possible -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2431#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
