- ghc-devs - Haskell.org

Ampere A1 instances for builder/marge?
by Karel Gardas 26 May '21

26 May '21

Hi, just to pass https://www.servethehome.com/oracle-cloud-giving-away-ampere-arm-a1-instanc… -- oracle seems to be giving some "always free" Ampere/ARM based instances. Looks like they even have some RAM and cores so perhaps they may be usable for marge/builder for arm/linux platform? BTW: Not tested myself, not trust Oracle, but sometimes man can get some good even from ... well... Oracle... Thanks, Karel

1 0

Productivity Tip from mpickering
by Matthew Pickering 26 May '21

26 May '21

Hi, I am now using a new flavour combination which is proving *very* nice as a compromise between fast recompiles and passing tests. My normal build command is now: ./hadrian/build --flavour=default+no_profiled_libs+omit_pragmas --freeze1 -j This has the effect of * base libraries are compiled with optimisation * Profiling libraries are not built * Stage 1 compiler is compiled with -O + -fomit-interface-pragmas, so recompilation behaviour is much better. The end result is a nearly clean testsuite run (I think there are two failures) but much faster iterations when modifying `compiler/*`. Cheers, Matt

3 2

Coding style: Using StandaloneKindSignatures in GHC
by Baldur Blöndal 25 May '21

25 May '21

Discussion to permit use of StandaloneKindSignatures in the GHC coding style guide. I believe it increases the clarity of the code, especially as we move to fancier kinds. It is the only way we have for giving full signatures to type synonyms, type classes, type families and others. An example: type Cat :: Type -> Type type Cat ob = ob -> ob -> Type type Category :: forall ob. Cat ob -> Constraint class Category cat where id :: cat a a .. type Proxy :: forall k. k -> Type data Proxy a = Proxy type Some :: forall k. (k -> Type) -> Type data Some f where Some :: f ex -> Some f -- | The regular function type type (->) :: forall {rep1 :: RuntimeRep} {rep2 :: RuntimeRep}. TYPE1 rep1 -> TYPE rep2 -> Type type (->) = FUN 'Many This is in line with function definitions that are always given a top-level, standalone type signature (1) and not like we currently define type families/synonyms (2) by annotating each argument or not at all. Using -XStandaloneKindSignatures (3) matches (1) -- (1) curry :: ((a, b) -> c) -> (a -> b -> c) curry f x y = f (x, y) -- (2) type Curry (f :: (a, b) -> c) (x :: a) (y :: b) = f '(x, y) :: c -- (3) type Curry :: ((a, b) -> c) -> (a -> b -> c) type Curry f x y = f '(x, y) It covers an edgecase that `KindSignatures` don't. The only way for deriving to reference datatype arguments is if they are quantified by the declaration head -- `newtype Bin a ..`. StandaloneKindSignatures allows us to still provide a full signature. We could write `newtype Bin a :: Type -> Type` without it but not `newtype Bin :: Type -> Type -> Type` type Bin :: Type -> Type -> Type newtype Bin a b = Bin (a -> a -> b) deriving (Functor, Applicative) via (->) a `Compose` (->) a Let me know what you think

10 15

GHC head, profiling with -O2 does not work
by Harendra Kumar 24 May '21

24 May '21

Hi, I am trying to build a small program with profiling using a ghc built from haskell gitlab master branch. When I use -O2 I run into: $ ghc/inplace/bin/ghc-stage2 --make -O2 -prof -fprof-auto -rtsopts Main.hs Linking Main ... ./StreamD.o(.text+0x1b9f2): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' ./MArray.o(.text+0xbe83): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' Main.o(.text+0x6fdb): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' collect2: error: ld returned 1 exit status `cc' failed in phase `Linker'. (Exit code: 1) It builds fine without the -O2 option. On ghc-8 it builds fine even with -O2. Is that a bug in the head GHC or just something to do with how I built it? Thanks, Harendra

2 1

Darwin CI Status
by Matthew Pickering 20 May '21

20 May '21

Hi all, The darwin pipelines are gumming up the merge pipeline as they are taking over 4 hours to complete on average. I am going to disable them - https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5785 Please can someone give me access to one of the M1 builders so I can debug why the tests are taking so long. Once I have fixed the issue then I will enable the pipelines. Cheers, Matt

2 2

Second Call for Talks: Haskell Implementors' Workshop @ ICFP'21
by Ningning Xie 16 May '21

16 May '21

Call for Talks ACM SIGPLAN Haskell Implementors' Workshop https://icfp21.sigplan.org/home/hiw-2021 Virtual, 22 Aug, 2021 Co-located with ICFP 2021 https://icfp21.sigplan.org/ Important dates --------------- Deadline: Wednesday, 30 June, 2021 (AoE) Notification: Wednesday, 14 July, 2021 Workshop: Sunday, 22 August, 2021 The 13th Haskell Implementors' Workshop is to be held alongside ICFP 2021 this year virtually. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and lightning short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2021. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw21.hotcrp.com/ We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Program Committee ----------------- * Dominique Devriese (Vrije Universiteit Brussel) * Daan Leijen (Microsoft Research) * Andres Löh (Well-Typed LLP) * Julie Moronuki (Typeclass Consulting) * John Wiegley (DFINITY) * Ningning Xie (the University of Hong Kong) * Edward Z. Yang (Facebook AI Research) Contact ------- * Ningning Xie <xnning at hku.hk>

1 0

an issue tracker for better error messages
by Richard Eisenberg 13 May '21

13 May '21

Hi devs, I've just posted https://discourse.haskell.org/t/proposal-an-issue-tracker-for-better-error-… <https://discourse.haskell.org/t/proposal-an-issue-tracker-for-better-error-…>, a description of an idea to create an issue tracker dedicated only to error messages. My hope is that the tracker is used to boil issues users have with error messages down to a concrete suggestion for a wording change -- and that only when we have that concrete suggestion will a ticket be made on the GHC tracker. What do we think here of this idea? If you have a thought about the overall idea, I invite you to comment on Discourse; if you have a thought about GHC's response to this, this list seems like the best venue. Thanks, Richard

1 0

ZuriHac 2021 - GHC Track - Call for Contributions
by Andreas Herrmann 11 May '21

11 May '21

Dear GHC developers, This year's ZuriHac 2021 [1], online Friday 18th June to Sunday 20th June, will again feature a dedicated GHC track to foster contributions to GHC and teach newcomers how to participate in GHC's development. For that we need your help: We would like to invite you to organize a session in the GHC track. This could be in form of a presentation, a workshop, or a hack session with topics centered around GHC. For some inspiration, these are the subjects from last year's track: - Write a GHC extension in 30 minutes, by Richard Eisenberg - A tour of linear types and linear base, by Divesh Otwani - QualifiedDo: customizable 'do' syntax without fuss, by Facundo Dominguez - On "simple" constraints for typechecker plugins, by Nicolas Frisby Please let us know if you'd be interested in leading a session or a workshop. You can contact either Niklas or myself, on this list or by private message. Best, Andreas and Niklas ZuriHac 2021 GHC track coordinators [1]: https://zfoh.ch/zurihac2021/

2 2

Warnings
by Simon Peyton Jones 04 May '21

04 May '21

If 'transformers' purposely has orphan instances, shouldn't we switch off the warnings about them? Simon "/opt/ghc/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -package-db libraries/bootstrapping.conf -this-unit-id transformers-0.5.6.2 -hide-all-packages -package-env - -i -ilibraries/transformers/. -ilibraries/transformers/dist-boot/build -Ilibraries/transformers/dist-boot/build -ilibraries/transformers/dist-boot/build/./autogen -Ilibraries/transformers/dist-boot/build/./autogen -Ilibraries/transformers/. -optP-include -optPlibraries/transformers/dist-boot/build/./autogen/cabal_macros.h -package-id base-4.14.1.0 -XHaskell98 -no-user-package-db -rtsopts -fno-warn-unused-matches -fno-warn-unused-imports -fno-warn-deprecated-flags -outputdir libraries/transformers/dist-boot/build -c libraries/transformers/./Control/Applicative/Lift.hs -o libraries/transformers/dist-boot/build/Control/Applicative/Lift.o libraries/transformers/Control/Monad/Trans/Error.hs:98:1: warning: [-Worphans] Orphan instance: instance [safe] Error e => Alternative (Either e) To avoid this move the instance declaration to the module of the class or of the type, or wrap the type with a newtype and declare the instance on the new type. | 98 | instance (Error e) => Alternative (Either e) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... libraries/transformers/Control/Monad/Trans/Error.hs:103:1: warning: [-Worphans] Orphan instance: instance [safe] Error e => MonadPlus (Either e) To avoid this move the instance declaration to the module of the class or of the type, or wrap the type with a newtype and declare the instance on the new type. | 103 | instance (Error e) => MonadPlus (Either e) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...

2 1

structured error messages
by Richard Eisenberg 03 May '21

03 May '21

Hi all, Alfredo and I are hard at work redesigning GHC's error-message system. It is time for more input, though, from clients of the system -- those writing IDEs and other tooling on top of GHC. The key question: How would you like your errors served? Right now, errors are served well-done: fully cooked into structureless strings that can be easily given to users. The problem with this is that IDEs cannot easily intervene between GHC and the users, as all the nutrition (that is, detailed information) has been cooked away. The new design allows for *structured errors*, where error messages are represented by elements of some error type. Different messages have different constructors of this type, and these constructors can carry auxiliary information. GHC will store these errors raw and cook them (that is, turn them into readable strings) only right before printing them. If the raw messages were somehow passed to IDEs, then IDEs could handle them non-uniformly. (For example, if a module name and a file name are different, the IDE could just present a dialog to the user asking whether the user would like to change one automatically.) There are a few open questions: * In what vessel shall the raw messages be served? In other words, how do IDEs expect to interact with this new system? - One route would be to pass e.g. -fjson-errors, which means that GHC presents the raw messages in a JSON format, for IDEs to parse. That's OK, but it still means that IDEs would have to have their own raw error message types to parse into. - Another route would be for the IDE to link against GHC itself, and then invoke the compiler via a function call that returns the raw messages directly. - Another route is some kind of middle ground, where the IDE passes e.g. -fbinary-errors=<filename> instructing GHC to write out a binary encoding of its messages to some file (or pipe, I suppose). These could then be deserialized back into GHC's own error types, but running in a separate process (linked against GHC, once again). - I'm sure you can come up with other interaction strategies. * What will an IDE do with these messages? It might have special handling for some, but GHC has a lot of different messages, and I imagine IDEs will want many just to be printed to the user. If an IDE has only the raw message, then the IDE is forced to do all the cooking -- no good. So there must be a way to take a raw message and render it into a user-readable string. - Maybe the above methods produce both the raw error and the rendered one? Then the IDE can choose which it prefers to use. - GHC could easily export its pretty-printing functions that take in the raw messages and produce rendered ones. But that (again) requires linking against GHC. Note that we are not (here, yet) discussing errors served at points between raw and well-done, though I would like to do so. Such an error would be rendered into a format where textual bits are interleaved with more structured bits, which would enable e.g. clicking on expressions within error messages to get their types. That (important feature) comes separately. So: what do consumers want here? Preview: You can take a look at some raw error messages from the driver in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533>. Thanks! Richard

3 3