February 2016 - ghc-devs

Improving trac notifications
by Matthew Pickering 13 Feb '17

13 Feb '17

I subscribe to the ghc-tickets[1] mailing list which provides updates to all trac tickets. This is very useful, however when a ticket description is updated the whole description is included in the email which makes it hard to see what actually changed. The web interface shows a nice diff[2] of the changes, I think it would be good if emails could also include a diff rather than the current quite useless output. After a bit of investigation, it appears that the easiest way to achieve this is apply a simple patch to our copy of trac. The current format is hard coded on line 558 in this module, it seems easy to modify this section to instead provide a diff. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.ticket.notification-pys… There is also already a module which has the diff operations implemented which could be used. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.versioncontrol.diff-mod… Another option would be to use something like the `AnnouncerPlugin`[3] but that seems like much more work and would still require someone to write a custom formatter. Any thoughts? Matt [1]: https://mail.haskell.org/mailman/listinfo/ghc-tickets [2]: https://ghc.haskell.org/trac/ghc/ticket/10873?action=diff&version=6 [3]: https://trac-hacks.org/wiki/AnnouncerPlugin

3 8

RE: vectorisation code?
by Simon Peyton Jones 13 Sep '16

13 Sep '16

Austin, (or anyone else) Manuel says: | > Would it be ok if we left it in the repo, but CPP'd it out so that | we | > didn't compile everything? (The DPH library is in the same state at | > the moment.) | > | > It might suffer bit-rot, but it’d still be there for resurrection. | | Sure, that’s ok. Could you action this? Just avoid compiling anything in 'vectorise/', using (I suppose) cpp to create a stub where necessary. Leave enough comments to explain! Simon | | I hope everything is fine in Cambridge! | Manuel | | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | > | Manuel M T Chakravarty | > | Sent: 16 January 2015 02:58 | > | To: Richard Eisenberg | > | Cc: ghc-devs(a)haskell.org Devs | > | Subject: Re: vectorisation code? | > | | > | [Sorry, sent from the wrong account at first.] | > | | > | We currently don’t have the resources to work on DPH. I would | > | obviously prefer to leave the code in, in the hope that we will be | > | able to return to it. | > | | > | Manuel | > | | > | > Richard Eisenberg <eir(a)cis.upenn.edu>: | > | > | > | > Hi devs, | > | > | > | > There's a sizable number of modules in the `vectorise` | > | subdirectory of GHC. I'm sure these do all sorts of wonderful | > | things. But what, exactly? And, does anyone make use of these | wonderful things? | > | > | > | > A quick poking through the code shows a tiny link between the | > | vectorise code and the rest of GHC -- the function `vectorise` | > | exported from the module `Vectorise`, which is named in exactly | one | > | place from SimplCore. From what I can tell, the function will be | > | called only when `-fvectorise` is specified, and then it seems to | > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE | > | #-}` doesn't appear in the manual at all, and `-fvectorise` is | > | given only a cursory explanation. It seems these work with DPH... | > | which has been disabled, no? Searching online finds several hits, | > | but nothing more recent than 2012. | > | > | > | > I hope this question doesn't offend -- it seems that | > | vectorisation probably has amazing performance gains. Yet, the | > | feature also seems unloved. In the meantime, compiling (and | > | recompiling, and | > | recompiling...) the modules takes time, as does going through | them | > | to propagate changes from elsewhere. If this feature is truly | > | orphaned, unloved, and unused at the moment, is it reasonable to | > | consider putting it on furlough? | > | > | > | > Thanks, | > | > Richard | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs(a)haskell.org | > | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs

13 35

Re: New type of ($) operator in GHC 8.0 is problematic
by Ryan Scott 28 Mar '16

28 Mar '16

Hi Chris, The change to ($)'s type is indeed intentional. The short answer is that ($)'s type prior to GHC 8.0 was lying a little bit. If you defined something like this: unwrapInt :: Int -> Int# unwrapInt (I# i) = i You could write an expression like (unwrapInt $ 42), and it would typecheck. But that technically shouldn't be happening, since ($) :: (a -> b) -> a -> b, and we all know that polymorphic types have to live in kind *. But if you look at unwrapInt :: Int -> Int#, the type Int# certainly doesn't live in *. So why is this happening? The long answer is that prior to GHC 8.0, in the type signature ($) :: (a -> b) -> a -> b, b actually wasn't in kind *, but rather OpenKind. OpenKind is an awful hack that allows both lifted (kind *) and unlifted (kind #) types to inhabit it, which is why (unwrapInt $ 42) typechecks. To get rid of the hackiness of OpenKind, Richard Eisenberg extended the type system with levity polymorphism [1] to indicate in the type signature where these kind of scenarios are happening. So in the "new" type signature for ($): ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b The type b can either live in kind * (which is now a synonym for TYPE 'Lifted) or kind # (which is a synonym for TYPE 'Unlifted), which is indicated by the fact that TYPE w is polymorphic in its levity type w. Truth be told, there aren't that many Haskell functions that actually levity polymorphic, since normally having an argument type that could live in either * or # would wreak havoc with the RTS (otherwise, how would it know if it's dealing with a pointer or a value on the stack?). But as it turns out, it's perfectly okay to have a levity polymorphic type in a non-argument position [2]. Indeed, in the few levity polymorphic functions that I can think of: ($) :: forall (w :: Levity) a (b :: TYPE w). (a -> b) -> a -> b error :: forall (v :: Levity) (a :: TYPE v). HasCallStack => [Char] -> a undefined :: forall (v :: Levity) (a :: TYPE v). HasCallStack => a The levity polymorphic type never appears directly to the left of an arrow. The downside of all this is, of course, that the type signature of ($) might look a lot scarier to beginners. I'm not sure how you'd want to deal with this, but for 99% of most use cases, it's okay to lie and state that ($) :: (a -> b) -> a -> b. You might have to include a disclaimer that if they type :t ($) into GHCi, they should be prepared for some extra information! Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds [2] https://ghc.haskell.org/trac/ghc/ticket/11473

20 53

'lub' and 'both' on strictness - what does it mean for products to have different arity?
by Ömer Sinan Ağacan 05 Mar '16

05 Mar '16

I was looking at implementations of LUB and AND on demand signatures and I found this interesting case: lubStr (SProd s1) (SProd s2) | length s1 == length s2 = mkSProd (zipWith lubArgStr s1 s2) | otherwise = HeadStr The "otherwise" case is interesting, I'd expect that to be an error. I'm trying to come up with an example, let's say I have a case expression: case x of P1 -> RHS1 P2 -> RHS2 and y is used in RHS1 with S(SS) and in RHS2 with S(SSS). This seems to me like a type error leaked into the demand analysis. Same thing applies to `bothDmd` too. Funnily, it has this extra comment on this same code: bothStr (SProd s1) (SProd s2) | length s1 == length s2 = mkSProd (zipWith bothArgStr s1 s2) | otherwise = HyperStr -- Weird Does "Weird" here means "type error and/or bug" ? Should I try replacing these cases with panics and try to validate?

3 7

Re: Questions concerning the LLVM backend - i.e. 'proc point splitting'
by David Spitzenberg 04 Mar '16

04 Mar '16

Simon > | Could you explain the need of further info-tables for 'inner' > | proc-points (those, which are not the entry-block of a function) to > | me, please? > > The main purpose of inner info tables is this. Given (case e of blah) we push a return address (for 'blah') on the stack and evaluate 'e'. During evaluation of 'e', garbage collection may take place. So the garbage collector needs to walk the stack to follow live pointers. Who knows what pointers are live? Answer: the code for 'blah' clearly knows what pointers are alive in the current stack frame, because it is going to access them. So the return address gets an info table that makes that implicit knowledge explicit, as a bitmap describing the liveness/pointer-hood of the stack frame. > > Addresses that are only jumped to don’t need info tables. > > It would be great if, as you learn about this stuff, you could add to the Commentary > https://ghc.haskell.org/trac/ghc/wiki/Commentary > to capture what you have learned. Thank you very much! In cases I find the current description imprecise or incomplete I can add what I've learned to the Commentary of course. > | The documentation states, that proc-point splitting is only required > | by the LLVM backend (see [2]). Does the cmm-pipeline perform proc- > | point splitting even when using the native code generator? > > I'm not certain, but I don't think so. > > | As stated above, the major problem of LLVM seems to be inferring > | control flow when it comes to call proc-points. As it's hard to avoid > | proc-point splitting, we leave the cmm-pipeline 'as-is'. We modify the > > I regard the whole proc-point thing as a major wart. I think we should work hard to eliminate it. So: another line of thought might be: how could we influence LLVM so that we didn't need proc-point splitting? I totally agree with you here. However, determining how LLVM needs to be influenced to eliminate proc-point splitting is a thing I won't be capable of doing mid term because of my current knowledge and lack of time. > | To make control flow more apparent to LLVM, they came up with the > | following idea. Remark before showing the idea: I know that it greatly > > I'm sorry to say that I didn't really understand the idea. Maybe someone else did? David Terei? My apologies for being imprecise. I hope to find the time to work out a little demonstration during the upcoming holidays. I'm currently fully occupied by university because of upcoming exams this week. > If you are seriously about investing effort in the back end, I'd be happy to help; in that case a Skype call is probably the best way. That is a great idea. Due to the above mentioned time constraints I propose that we follow up in January. Regards, David > Simon > > | interferes with CPS. It leaves parts of the continuation-handling to > | the implicit LLVM call-stack. Further, this does not solve the problem > | of proc-point splitting at all. It is more a workaround than a > | solution. > | But it would greatly increase LLVM's possibilities to optimize code > | later on. That's why I found this idea worth mentioning. Especially > | because after reading your answer, Ben, I'm somewhat convinced that > | solving the problem of proc-point splitting is nearly impossible with > | the capabilities of LLVM IR available at the moment. Now back to the > | idea. > | > | As stated above, the major problem of LLVM seems to be inferring > | control flow when it comes to call proc-points. As it's hard to avoid > | proc-point splitting, we leave the cmm-pipeline 'as-is'. We modify the > | code, llvmGen produces when it comes to call proc-points instead. All > | other types of proc-points remain unchanged. > | > | Initial situation in pseudo cmm: > | > | foo() { > | ... > | call bar() returns to cont // bar defined externally > | > | cont: > | ... > | } > | > | After proc-point splitting, this is converted into LLVM IR similar to > | the following: > | > | @foo() { > | ... > | store @cont(), %Sp ; push continuation on the stack tail call @bar() ; > | @bar defined externally } > | > | @cont() { > | ... > | } > | > | To fix the above issue, we introduce a method, which restores the > | pointers Sp, Hp and the register R1 (among everything else, what has > | to be restored) and 'fakes' the continuation. Note, that '@restore' > | returns without calling into the continuation. This way, the call into > | the continuation can be made direct. The above code would be > | transformed into something similar to the following: > | > | @foo() { > | ... > | store @restore(), %Sp ; 'fake' continuation call @bar() ; br label > | restore > | > | restore: > | %Sp = load (getelementptr @environment 0, 0) ; restore what has to be > | ... ; restored tail call @cont() } > | > | @cont() { > | ... > | } > | > | @restore(%Sp, %Hp, %R1, ...) { > | store %Sp, (getelementptr @environment 0, 0) ; store everything into > | ... ; global variable ret void } > | > | @environment ; structure of type similar to {i64*, i64*, i64*, i64, > | i64, ..} > | > | As an alternative, the above transformation could be done by a LLVM > | pass. llvmGen could then annotate the continuation of calls call cite. > | This would greatly simplify the detection of the correct continuation. > | > | What do you think about this idea? Especially when thinking about the > | interference with CPS? > | > | Regards, > | > | David > | > | > | > | > | [1] > | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GeneratedCod > | e#Importantconceptsinthemachine > | > | [2] > | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CodeGen#Seco > | ndstage:theCmmpipeline > | > | > | > | > | On 11/21/2015 12:00 AM, Ben Gamari wrote: > | > Simon Peyton Jones <simonpj(a)microsoft.com> writes: > | > > | >> David > | >> > | >> All this stuff is terribly paged-out for me. But I'd love someone > | to > | >> pay attention to some of this back-end stuff, so if you'd like to > | >> work there, I'd like to help you. > | >> > | >> David Terei was also thinking of getting rid of proc point > | splitting > | >> for LLVM (see attached email and the notes attached to it) > | >> > | >> Simon Marlow also was thinking about this; see his attached email. > | >> > | >> The main *reason* for establishing a proc-point is so that, when > | >> generating C code (which we don't do any more) you can take its > | >> address. E.g. > | >> > | >> foo() { ... Push &bar onto the stack (effectively a return address) > | >> Jump to thingumpy } > | >> > | >> bar() { ... } > | >> > | >> Really bar is part of foo, but we have make it a separate top level > | >> thing so that we can take the address of bar and push it on the > | stack. > | >> > | >> The trouble is that if there is a label inside bar that foo wants > | to > | >> jump to (i.e. without pushing &bar etc) then we have to make that > | >> label too into a proc-point, so that both foo and bar can see it. > | >> Urgh. > | >> > | >> In LLVM this probably is not true; presumably you can take the > | >> address of any label? > | >> > | > This is true. While labels themselves have function-local scope in > | > LLVM, there is an expression, `blockaddress`, which allows you to > | take > | > an address to a label in another function [1]. That being said, in > | > reading through the documentation it's not at all clear to me that > | it > | > would be safe to jump to such an address. In fact, given that the > | > instruction that this expression is supposed to be used with, > | > `indirectbr`, can only be used for local blocks, I suspect it is > | not. > | > More information about this feature can be found here [2]. > | > > | > The jump issue aside, I don't know how you would deal with > | > tables-next-to-code. The prefix data support that currently > | available > | > in LLVM is attached to functions and I unfortunately don't see that > | > changing any time soon. > | > > | > Ultimately it seems that trying to refer to labels defined in other > | > functions is using LLVM against the way it was intended. One > | > alternative would be to teach llvmGen to merge mutually recusive > | > top-level functions into a single LLVM function during code > | > generation. Otherwise I'm afraid you are stuck with either the > | status > | > quo or attempting to improve on LLVM's own cross-procedure > | optimization ability. > | > > | > That being said, it sounds as though eliminating proc-point > | splitting > | > would make for quite a nice project in the native code generator. > | > > | > Cheers, > | > > | > - Ben > | > > | > > | > [1] > | > > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fllvm.o > | > rg%2fdocs%2fLangRef.html%23addresses-of-basic- > | blocks&data=01%7c01%7csi > | > > | monpj%40064d.mgd.microsoft.com%7c7fdbfda0b4514a098c4d08d2f74448f1%7c72 > | > > | f988bf86f141af91ab2d7cd011db47%7c1&sdata=nKVLgmZezUdEYL%2fma1exMMPLbcT > | > RkaE1JrvVaR1EesY%3d [2] > | > > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fblog.l > | > lvm.org%2f2010%2f01%2faddress-of-label-and-indirect- > | branches.html&data > | > > | =01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c7fdbfda0b4514a098c4d08d2 > | > > | f74448f1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BTMdZESwYS4tZa5W > | > sOAqyFutoI5xNNFDe0b%2bdKC3ODs%3d [3] > | > > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fllvm.o > | > rg%2fdocs%2fLangRef.html%23prefix- > | data&data=01%7c01%7csimonpj%40064d.m > | > > | gd.microsoft.com%7c7fdbfda0b4514a098c4d08d2f74448f1%7c72f988bf86f141af > | > > | 91ab2d7cd011db47%7c1&sdata=rdo4ZLjjE%2bWxNykVL%2bSuToWioY6nzQpflSk296E > | > 8W70%3d > | > >

3 4

Generalising the demand analysis to sum types
by José Manuel Calderón Trilla 04 Mar '16

04 Mar '16

Hello ghc-devs, Apologies for the longish email. I'm looking to generalise GHC's demand analysis to work on sum types. This is in connection with the work on unboxed sums. The idea is that if the strictness analysis tells us that a sum type is strict in all the fields of all of its constructors, it is safe to unbox that sum automatically. We hope for this to feed into a worker/wrapper like transformation for sum types. I am new to the GHC codebase and wanted to make sure that my plan of attack seemed sensible to you all. GHC's current type representing demand is StrDmd, which is defined as follows: data StrDmd = HyperStrict | SCall StrDmd | SProd [ArgStr] | HeadStr I believe that adding sum types will be as simple as adding a single new constructor for Sums: data StrDmd = HyperStrict | SCall StrDmd | SProd [ArgStr] | SSum [(Tag, StrDmd)] | HeadStr We need the constructor tag so that we can analyze each branch of a case expression independently before combining the results of each branch. Since we only care if all fields are strict for all constructors, we won't actually use the tag information except in the analysis itself. Projection-based strictness analysis on sum types is not new (though sum types + higher-order seems to be). That being said, all previous treatments of the subject that I'm aware of forbid polymorphic recursion. Luckily for us we aren't trying to unbox recursive types, so for now [1] we will not attempt to analyze recursive types, hence no SMu or SRec constructor above. With the analysis accepting sum types we will be able to analyze functions with sum types as parameters, as a trivial example: fromMaybe2 x y = case x of Just v -> v Nothing -> y You would get a demand signature like: Str=Dmdtype <S[("Just", <S,U>), ("Nothing", <>)],U><L,U> Which says that the function is strict in its first argument and that if the value is a 'Just' then its field is used strictly, if the value is a 'Nothing' then there is no further demand (a nullary product). For those with more experience in these matter, does this seem to be a sensible approach? Thanks in advance for any insight, Jose [1]: Those of you who saw my Haskell Symposium talk on implicit parallelism last year might remember that we will need the analysis to work on recursive types in order to automatically generate parallel strategies, but that's for later (I've spoken with Ilya Sergey about working on that).

4 8

Patches/proposals waiting for review
by Thomas Miedema 02 Mar '16

02 Mar '16

Hi Simon, the following issues are waiting for your review: * https://phabricator.haskell.org/D1762 "Fix #11348 handle instance dependencies" by Alexander Vieth * https://phabricator.haskell.org/D1896 "Improve printing of pattern synonym types" by Rik Steenkamp * https://ghc.haskell.org/trac/ghc/wiki/ShorterImportSyntax by Anthony Cowley Maybe others, they should show up under "Blocking Others" when you go to https://phabricator.haskell.org/ Thanks, Thomas

5 4

GHC 8.0.1 status
by Ben Gamari 01 Mar '16

01 Mar '16

tl;dr. Stabilizing the ghc-8.0 is taking a bit longer than was anticipated. The release schedule is being pushed back a bit. Hello everyone, As you likely know we are currently in the depths of the 8.0 release. In fact, under more ideal circumstances I would probably be cutting another release candidate right now instead of writing this email, in preparation for a final release next week or so. However, our world is far from ideal as evidenced by the number [1] of significant bugs present on the 8.0 branch. This isn't altogether unexpected; we knew we were taking a bit of a risk in merging so many high-impact patches in one release. However, we thought that given a longer-than-usual period between first-candidate and the final release, we'd have enough time to smooth out the wrinkles. Sadly, this has taken a bit longer than we anticipated. Of course, the last thing we want is to push a known buggy release out the door. Consequently, we won't be delivering the 8.0.1 release next week as originally planned. Instead, we'll be pushing the release back by about three weeks. This will give developers a bit more breathing room in which to work out the remaining issues. Hopefully in a few weeks the tree will be in such a state that we can push out yet another candidate which, with luck, will be the last before the release. If you'd like to expedite the process (and have fun in the process), you could do worse than to having a look at Trac [1], choosing a bug of your liking, and trying your hand at solving it. Thanks to everyone who has contributed to this effort thusfar. If you have any questions about the release process or how you can help, don't hesistate to ask. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

3 4

Change in demand analysis results between 7.10.2 and RC1 (not fixed in RC2 and HEAD)
by Ömer Sinan Ağacan 01 Mar '16

01 Mar '16

Hi all, While working on demand analyzer today we realized that there has been some changes in demand analysis results between GHC 7.10.2 and 8.0-rc2. Here's a minimal example: {-# LANGUAGE BangPatterns #-} module Main where data Prod a = Prod !a !a addProd :: Prod Int -> Prod Int -> Prod Int addProd (Prod i1 i2) (Prod i3 i4) = Prod i1 (i2 + i4) main = return () Compiled with 7.10.2: addProd :: Prod Int -> Prod Int -> Prod Int [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType <S(SS),1*U(U,U(U))><S(SS),1*U(1*H,U(U))>m, ...}}}}] addProd = \ (ds_dzH :: Prod Int) (ds1_dzI :: Prod Int) -> case ds_dzH of _ [Occ=Dead] { Prod i1_an2 i2_an3 -> case i2_an3 of _ [Occ=Dead] { GHC.Types.I# x_s2B4 -> case ds1_dzI of _ [Occ=Dead] { Prod i3_an4 i4_an5 -> case i4_an5 of _ [Occ=Dead] { GHC.Types.I# y_s2B7 -> Main.Prod @ Int i1_an2 (GHC.Types.I# (GHC.Prim.+# x_s2B4 y_s2B7)) } } } } Compiled with 8.0-rc2: -- RHS size: {terms: 20, types: 17, coercions: 0} addProd :: Prod Int -> Prod Int -> Prod Int [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType <S(SS),1*U(U,U(U))><S(LS),1*U(A,U(U))>m, ...}}}}] addProd = \ (ds_dQL :: Prod Int) (ds1_dQM :: Prod Int) -> case ds_dQL of _ [Occ=Dead] { Prod i1_avS i2_avT -> case i2_avT of _ [Occ=Dead] { GHC.Types.I# x_s1vO -> case ds1_dQM of _ [Occ=Dead] { Prod i3_avU i4_avV -> case i4_avV of _ [Occ=Dead] { GHC.Types.I# y_s1vR -> Main.Prod @ Int i1_avS (GHC.Types.I# (GHC.Prim.+# x_s1vO y_s1vR)) } } } } To highlight the difference, GHC 7.10.2: <S(SS),1*U(U,U(U))><S(SS),1*U(1*H,U(U))> GHC 8.0-rc2: <S(SS),1*U(U,U(U))><S(LS),1*U(A,U(U))> (NOTE: Also tried with HEAD and rc1 just now, the results are the same as rc2) The demand put on the second argument is more strict in GHC 7.10. Was that an intentional change? Any ideas on why this might be happening? In our case, we prefer the result in 7.10.2 of course, because that's a more precise demand and it gives us more opportunities for optimizations. But I guess this could potentially reveal itself in some other situations and make some programs slower? Any ideas? Thanks..

3 4

CoreLint check for case with no alts
by Ömer Sinan Ağacan 01 Mar '16

01 Mar '16

Hi all, CoreLint has a check that, when seeing a case expression with empty list of alternatives, checks whether the scrutinee is bottom. This "bottom-ness" check is, however, very simple and returning many false negatives. For example, when it sees a case expression, all it does is: go _ (Case _ _ _ alts) = null alts Which is just too simple for some cases. (it could check if all the RHSs are bottom, or if the scrutinee is bottom etc.) I guess this makes sense, since it's OK to generate unreachable code, but it's not OK to not generate a code in a reachable path. But in my case this is becoming problem as it's rejecting my seemingly valid program. One of the relevant parts in my code is this: case ww_s4C3 of ww_X4Fb { (#_||#) ww_s4Ce -> case case ww_s4Ce of ww_s4F1 { (# ww_s4F2, ww_s4F3 #) -> lvl_s4F4 ww_s4F3 ww_s4F2 } of wild_00 { -- empty }; lvl_s4F4 :: Int# -> String -> Var [LclId, Arity=2, Str=DmdType (args: <L,U><L,U>) (res: x)] lvl_s4F4 = \ (ww_s4F3 :: Int#) (ww_s4F2 :: String) -> lvl_s3V4 (TyVar ww_s4F2 ww_s4F3) lvl_s3V4 :: Var -> Var [LclId, Arity=1, CallArity=1, Str=DmdType (args: <B,1*H>) (res: x)] lvl_s3V4 = \ (i_a1vO :: Var) -> lvl_s4EZ i_a1vO lvl_s4EZ :: Var -> Var [LclId, Arity=1, Str=DmdType (args: <L,U>) (res: x)] lvl_s4EZ = \ (i_a1vO :: Var) -> error ... The scrutinee part of the case expression in the alternative is clearly bottom, but this expression is rejected by the linter. One easy solution is to implement a more precise test and use it in linter. But I thought maybe the current implementation is deliberately so. Maybe the code generator doesn't support that type of code etc. so I wanted to ask: Is there a restriction on what kind empty case expressions are supported by the code generator or can I just improve the lint check and assume that the code will be handled by the code generator correctly? Thanks.

2 3