- ghc-devs - Haskell.org

Call for Talks: Haskell Implementors' Workshop
by Ningning Xie 22 Mar '21

22 Mar '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

GitLab is down: urgent
by Simon Peyton Jones 22 Mar '21

22 Mar '21

GHC's GitLab seems to be down. Ben? (I just get 502's) Simon

10 21

Post-mortem for last-night's GitLab outage
by Ben Gamari 19 Mar '21

19 Mar '21

Hi everyone, It appears that gitlab.haskell.org's GitLab services went down around nine hours ago (around midnight EST). Surprisingly, the outage appears to be entirely unrelated to yesterday's upgrade. Rather, the problem was merely that the docker repository had grown to fill the entirety of the server's data volume. I have fixed this (and prevented future occurrences of the same issue) by moving our Docker images to a new volume. Services should be now once again fully operational. Disk usage is something that we have struggled with in the past, in part due the relatively small local disk capacity of our servers and previous unreliability of our hosting provider's iSCSI block storage infrastructure. The latter has previously prompted us to avoid using iSCSI volumes for operation-critical data, while the former has meant that we had to keep bulk data size like Docker images in careful check, lest we run out of local storage. At this point, it has been over half a year since we have experienced any trouble with iSCSI. For this reason, I have moved the Docker images back to iSCSI. This should eliminate this failure mode in the future. Meanwhile the GitLab database remains on local storage, also minimizing the potential for downtime due to future iSCSI failures. Cheers, - Ben

1 0

GitLab upgrade soon
by Ben Gamari 19 Mar '21

19 Mar '21

Hi all, I will be performing a GitLab upgrade starting in approximately one hour. While I generally try to do this with more notice and out of working hours, in this case there is an exploitable GitLab vulnerability that deserves swift action. Thank you for you patience. Cheers, - Ben

2 2

Pull request to editline
by Oleg Grenrus 18 Mar '21

18 Mar '21

Hi Judah, I'm sending your an email, in case you haven't noticed GitHub notifications. I have a PR https://github.com/judah/haskeline/pull/153 (now opened for two months). It's blocking work on Data.List specialization. Also Ben have pinged you on https://github.com/judah/haskeline/issues/154 to make releases for 9.0.1 and 9.0.2. It would be very great if my patch could be merged and released, that should make editline ready for 9.2 and maybe even 9.4 (I think we are too late with refactor of Data.List for 9.2). - Oleg

2 2

Is referring to GHC-proposals in GHC user manual bad practice or not?
by Oleg Grenrus 17 Mar '21

17 Mar '21

I have a following question: My lexer rules related proposal was recently accepted. The biggest part of getting it in is writing documentation for it. While looking at Divergence from Haskell 98 and Haskell 2010 section of the user manual, in particular Lexical syntax, it already has See "GHC Proposal #229 for the precise rules.". Can I just the same? (I think there was an implicit acceptance of that practice in e.g. https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1664#note_238759) However, I think that referring to proposals text for "essential" bits of information is a bad practice. Because GHC proposals are sometimes amended, one have to look into GitHub history to find out what were there for a particular time point of a GHC release. Very laborous. --- Currently there is 23 references to about a dozen of proposals. An example are passages like In 9.0, the behavior of this extension changed, and now we require that a negative literal must not be preceded by a closing token (see `GHC Proposal #229 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-w…>`__ for the definition of a closing token). or a future release will be turned off by default and then possibly removed. The reasons for this and the deprecation schedule are described in `GHC proposal #30 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0030-r…>`__. And there are better examples, which are references for more information, not essential one, like See the proposal `DuplicateRecordFields without ambiguous field access <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0366-n…>`_ and the documentation on :extension:`DuplicateRecordFields` for further details. (I'd put the internal user manual link first), or But these automatic eta-expansions may silently change the semantics of the user's program, and deep skolemisation was removed from the language by `GHC Proposal #287 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-s…>`__. This proposal has many more examples. --- So to boil down my question, can I write Lexical syntax of identifiers and decimal numbers differs slightly from the Haskell report. See GHC Proposal #403 for the precise rules and differences. - Oleg

5 7

Generalising KnowNat/Char/Symbol?
by Sylvain Henry 16 Mar '21

16 Mar '21

Hi, I would like to have a KnownWord constraint to implement a type-safe efficient sum type. For now [1] I have: data V (vs :: [Type]) = Variant !Word Any where Word is a tag used as an index in the vs list and Any a value (unsafeCoerced to the appropriate type). Instead I would like to have something like: data V (vs :: [Type]) = Variant (forall w. KnownWord w => Proxy w -> Index w vs) Currently if I use KnownNat (instead of the proposed KnownWord), the code isn't very good because Natural equality is implemented using `naturalEq` which isn't inlined and we end up with sequences of comparisons instead of single case-expressions with unboxed literal alternatives. I could probably implement KnownWord and the required stuff (axioms and whatnot), but then someone will want KnownInt and so on. So would it instead make sense to generalise the different "Known*" we currently have with: class KnownValue t (v :: t) where valueSing :: SValue t v newtype SValue t (v :: t) = SValue t litVal :: KnownValue t v => proxy v -> t type KnownNat = KnownValue Natural type KnownChar = KnownValue Char type KnownSymbol = KnownValue String type KnownWord = KnownValue Word Thoughts? Sylvain [1] https://hackage.haskell.org/package/haskus-utils-variant-3.1/docs/Haskus-Ut…

3 2

Build failure -- missing dependency? Help!
by Simon Peyton Jones 15 Mar '21

15 Mar '21

I'm getting this (with 'sh validate -legacy'). Oddly * It does not happen on HEAD * It does happen on wip/T19495, a tiny patch with one innocuous change to GHC.Tc.Gen.HsType I can't see how my patch could possible cause "missing files" in ghc-bignum! I'm guessing that there is a missing dependency that someone doesn't show up in master, but does in my branch, randomly. There's something funny about ghc-bignum; it doesn't seem to be a regular library Can anyone help? Thanks Simon "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id base-4.16.0.0 -hide-all-packages -package-env - -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-bignum-1.0 -package-id ghc-prim-0.8.0 -package-id rts -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -O -dcore-lint -ticky -Wwarn -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -outputdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/Exception/Type.hs-boot -o libraries/base/dist-install/build/GHC/Exception/Type.o-boot -dyno libraries/base/dist-install/build/GHC/Exception/Type.dyn_o-boot Failed to load interface for 'GHC.Num.Integer' There are files missing in the 'ghc-bignum' package, try running 'ghc-pkg check'. Use -v (or `:set -v` in ghci) to see a list of the files searched for. make[1]: *** [libraries/base/ghc.mk:4: libraries/base/dist-install/build/GHC/Exception/Type.o-boot] Error 1 make[1]: *** Waiting for unfinished jobs....

4 7

GSOC Idea: Bytecode serialization and/or Fat Interface files
by Zubin Duggal 13 Mar '21

13 Mar '21

Hi all, This is following up on this recent discussion on the list concerning fat interface files: https://mail.haskell.org/pipermail/ghc-devs/2020-October/019324.html Now that we have been accepted as a GSOC organisation, I think it would be a good project idea for a sufficiently motivated and advanced student. This is a call for mentors (and students as well!) who would be interested in this project The problem is the following: Haskell Language Server (and ghci with `-fno-code`) have very fast startup times for codebases which don't make use of Template Haskell, and thus don't require any code-gen to typecheck. This is because they can simply read the cached iface files generated by a previous compile and don't need to re-invoke the typechecker. However, as soon as TH is involved, we are forced to retypecheck and compile files, since it is not possible to restart the code-gen process starting with only a iface file. I can think of two ways to address this problem: 1. Allow bytecode to be serialized 2. Serialize desugared Core into iface files (fat interfaces), so that (byte)code-gen can be restarted from this point and doesn't need (1) might be challenging, but offers a few more advantages over (2), in that we can reduce the work done to load TH-heavy codebases to just a load of the cached bytecode objects from disk, and could make the load process (and times) for these codebases directly comparable to their TH-free cousins. It would also make ghci startup a lot faster with a warm cache of bytecode objects, bringing ghci startup times in line with those of -fno-code However (2) might be much easier to achieve and offers many of the same advantages, in that we would not need to re-run the compiler frontend or core-to-core optimisation phases. There is also already a (slightly bitrotted) implementation of (2) thanks to the work of Edward Yang. If any of this sounds exciting to you as a student or a mentor, please get in touch. In particular, I think (2) is a feasible project that can be completed with minimal mentoring effort. However, I'm only vaguely familiar with the details of the byte code generator, so if (1) is a direction we want to pursue, we would need a mentor familiar with the details of this part of GHC. Cheers, Zubin

5 5

GHC Exactprint merge process
by Alan & Kim Zimmerman 12 Mar '21

12 Mar '21

I have been running a branch in !2418[1] for just over a year to migrate the ghc-exactprint functionality directly into the GHC AST[2], and I am now satisfied that it is able to provide all the same functionality as the original. This is one of the features intended for the impending 9.2.1 release, and it needs to be reviewed to be able to land. But the change is huge, as it mechanically affects most files that interact with the GHC AST. So I have split out a precursor !5158 [3] with just the new types that are used to represent the annotations, so it can be a focal point for discussion. It is ready for review, please comment if you have time and interest. Regards Alan [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2418 [2] https://gitlab.haskell.org/ghc/ghc/-/issues/17638 [3] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5158

3 4