- ghc-devs - Haskell.org

Implicit reboxing of unboxed tuple in let-patterns
by Spiwack, Arnaud 07 Sep '20

07 Sep '20

Dear all, I discovered the hard way, yesterday, that lazy let pattern matching is allowed on unboxed tuples. And that it implicitly reboxes the pattern. Here is how the manual describes it, from the relevant section <https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts…> : You can have an unboxed tuple in a pattern binding, thus f x = let (# p,q #) = h x in ..body.. If the types of p and q are not unboxed, the resulting binding is lazy like any other Haskell pattern binding. The above example desugars like this: f x = let t = case h x of { (# p,q #) -> (p,q) } p = fst t q = snd t in ..body.. Indeed, the bindings can even be recursive. Notice how h x is lazily bound, hence won’t necessarily be run when body is forced. as opposed to if I had written, for instance, let u = hxin ..body.. My question is: are we happy with this? I did find this extremely surprising. If I’m using unboxed tuples, it’s because I want to guarantee to myself a strict, unboxed behaviour. But a very subtle syntactic detail seems to break this expectation for me. My expectation would be that I would need to explicitly rebox things before they get lazy again. I find that this behaviour invites trouble. But you may disagree. Let me know!

8 20

COMPLETE pragmas
by Richard Eisenberg 03 Sep '20

03 Sep '20

Hi Sebastian, I enjoyed your presentation last week at ICFP! This thread (https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-…) played out before you became so interested in pattern-match coverage. I'd be curious for your thoughts there -- do you agree with the conclusions in the thread? My motivation for asking is https://github.com/conal/linalg/pull/54 (you don't need to read the whole thing), which can be boiled down to a request for a COMPLETE pragma that works at a polymorphic result type. (Or a COMPLETE pragma written in a module that is not the defining module for a pattern synonym.) https://gitlab.haskell.org/ghc/ghc/-/issues/14422 describes a similar, but even more challenging scenario. Do you see any ways forward here? Thanks! Richard

5 8

GHC Logo
by Ben Gamari 02 Sep '20

02 Sep '20

Hi everyone, Recently a sponsor asked for a logo for our project. As far as I know, GHC doesn't really have a consistent logo; the closest that we have had is the stylized "GHC" on the top of ghc.haskell.org. To accomodate the request, I took a few minutes and reworked the typography of the Thompson-Wheeler Haskell logo for use by GHC. I couldn't positively identify the typeface used for the "Haskell" text, but I believe that the extra-bold Cantarell face that I chose in the GHC variant has a similar feel to the Haskell logo and is free to use. I've posted the logo on the Wiki for future reference [1]. Feedback is very much welcome. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo

13 22

Creative ideas on how to debug heap corruption
by Moritz Angermann 02 Sep '20

02 Sep '20

Hi there! as some of you may know, I've been working on an aarch64 native code generator. Now I've hit a situation where my stage2 compiler somehow corrupts my heap. Initially I thought this would likely be missing memory barriers, however they are emitted. This doesn't mean it can't be, but at least it's not as simple as "they are just missing". The crashes I see are non deterministic, in fact I sometimes even manage to compile a Hello World module, without crashes. Other times it crashes with unknown closure errors or it just crashes. But it always crashes during GC. Changing the nursery size make it crasha bit more frequent, but nothing obvious sticks out yet. If anyone has some create ideas, I'd love to hear them. I've been wondering if just logging allocations (offset, range, type) would help figuring out what we expected to be there; and then maybe try to break on the allocation, (and subsequent writes). I'm sure some have been down this road before. Cheers, Moritz

5 7

HsPragTick
by Alan & Kim Zimmerman 02 Sep '20

02 Sep '20

I am working through the API Annotations, and have come across HsPragTick. In source it appears as c = {-# GENERATED "foobar" 1 : 2 - 3 : 4 #-} 0.00 But it does not seem to be used anywhere. It is passed through for renaming and type checking, and Coverage.hs uses it as addTickHsExpr (HsPragE _ HsPragTick{} (L pos e0)) = do e2 <- allocTickBox (ExpBox False) False False (locA pos) $ addTickHsExpr e0 return $ unLoc e2 So if it is used at all, the contents are ignored. Can it be removed? Alan

2 1

Re: HsPragTick
by Ryan Scott 31 Aug '20

31 Aug '20

I think that HsPragTick is unused as of [1]. In fact, I was under the impression that [1] removed HsPragTick entirely (as the commit message) would suggest, but upon further inspection, that doesn't appear to be the case. Vlad, do you recall why HsPragTick was kept around? Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2154

3 2

Parsing funny arrows
by Csongor Kiss 29 Aug '20

29 Aug '20

Hello devs, I am trying to modify GHC's parser to allow the following syntax in types: a -> @m b but my naive attempt was unsuccessful: type :: { LHsType GhcPs } : btype { $1 } | btype '->' PREFIX_AT btype ctype ... For example when I try to parse the following code (and turn on the lexer debug log): test :: a -> @m b test = undefined I get the following token: ITvarid "test" token: ITdcolon NormalSyntax token: ITvarid "a" token: ITrarrow NormalSyntax token: ITtypeApp token: ITvarid "m" token: ITvarid "b" token: ITsemi Parse.hs:2:1: error: parse error (possibly incorrect indentation or mismatched brackets) | 2 | test = undefined I don't have much experience with hacking on the parser so I'm likely missing something obvious. Could someone please point at what I might be doing wrong? Thanks in advance. Cheers, Csongor

4 8

Perf baselines
by Simon Peyton Jones 25 Aug '20

25 Aug '20

Ben CI is saying (on !3889) Missing Baseline Metrics these metrics trivially pass because a baseline (expected value) cannot be recovered from previous git commits. This may be due to HEAD having new tests or having expected changes, the presence of expected changes since the last run of the tests, and/or the latest test run being too old. T18223 T12425 T13253 Now it's true that T18223 is new, but T12425 and T13253 are not. What's wrong? Thanks Simon

1 0

Haskell Implementors' Workshop lightning talks
by Ben Gamari 24 Aug '20

24 Aug '20

Hello everyone, The Haskell Implementors' Workshop will be held this Friday, August 28th, colocated with virtual ICFP. As usual, we will have a number of slots for lightning-talks. These are five-minute-long talks where you can present libraries, language extension ideas, plugins, tools... anything that the Haskell implementor community might find interesting. We are collecting talk submissions via Google Forms [1] and will notify speakers of their slots on August 27th. We are looking forward to seeing you there! Cheers, - Ben [1] https://forms.gle/a8sZQNRRMe9H9YnX8

1 0

Breakage on master
by Ben Gamari 19 Aug '20

19 Aug '20

Hi all, It seems that a patch breaking master for DEBUG-enabled builds has snuck into `master`. I'm currently working on fixing the issue but in the meantime the issue can be worked around by reverting accbc242e555822a2060091af7188ce6e9b0144e. Cheers, - Ben

3 6