- ghc-devs - Haskell.org

Decorating exceptions with backtrace information
by Ben Gamari 14 May '20

14 May '20

Hi everyone, After a nice discussion on IRC about the unfortunate state of error reporting in Haskell, I felt compelled to write down some long-lingering thoughts regarding backtraces on exceptions. The result is GHC proposal #330 [1]. I think the approach is viable and perhaps even straightforward. I have the sketch of an implementation here [2]. Please have a look at the proposal and leave your comments. If there is consensus it is possible that we could have this done for 8.12. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/330 [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236

8 19

[HiW'20] Call for Talks
by Ben Gamari 14 May '20

14 May '20

Hello everyone, Haskell Implementors Workshop is calling for talk proposals. Co-located with ICFP, HiW is an ideal place to describe a Haskell library, a Haskell extension, compiler, works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. The deadline for submissions is July 2nd 2020. Call for Talks ============== The 12th Haskell Implementors’ Workshop is to be held alongside ICFP 2020 this year in New Jersey. 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 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 2020. 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, optimization 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 can be made via HotCRP at https://icfp-hiw20.hotcrp.com/ until July 2nd (anywhere on earth). 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 --------- We recognize the on-going threat that COVID-19 poses to our participants' safety. While August is nearly half a year away, we must account for the possibility that the virus continues to pose a significant threat into the summer. For this reason, we are investigating options that would allow remote presentations this year. In light of this, we urge potential presenters not to be discouraged from submitting and encourage participants to keep time open in their calendars, regardless of the on-going COVID situation. Rest assured that the conference organizers are working to ensure that the Implementors Workshop can be held safely and productively, regardless of how the COVID-19 situation evolves. Program Committee ----------------- - Andrey Mokhov (Newcastle University) - Ben Gamari (Well-Typed LLP) - Christian Baaij (QBayLogic) - George Karachalias (Tweag I/O) - Klara Marntirosian (KU Leuven) - Matthew Pickering (Univeristy of Bristol) - Ryan Scott (Indiana University Bloomington) Best wishes, Ben

1 1

A future for the Windows packaging situation.
by Hécate 14 May '20

14 May '20

Dear GHC devs, dear maintainers, Following a discussion that took place on #ghc, I wish to spread it to the whole mailing-list, in order to receive some feedback, and plan for the future now that it has become clear that the present is rather bleak. As some of you may have seen from the long threads in haskell-cafe@, countless steps of various difficulty for Windows users (excluding power-users) need to be taken in order to have a proper working GHC / Haskell installation on their machine. Moreover, some defiance against Chocolatey has come to our ears, due to the mailing-list registration form that appears when one desires to download this package manager. I shall speak for myself by saying that I do not wish the that the Windows Haskell developers need to become a special combo of Chocolatey maintainers and Windows power users. Some GNU/Linux distributions such as Exherbo have made this their creed, the major difference being that they actually give the tools to make such a thing possible. The point of my email to you all is the following: I suggest that Haskell.org, the 501(c)(3) established in NY which, If I am not mistaken, holds the funds from various individual donations, the Amazon Smile programme and Software in the Public Interest grants, hires a company to establish a strong technological basis regarding Windows packaging. I am not talking of delegating the maintaining task to an external entity, but to provide the foundations upon which volunteers will be able to keep things running. Training in such matters would also be beneficial, so that newcomers can learn on the spot how to best interact with this. Their contract would involve the initial setup of CI tasks able to produce MSIX packages, while the people in charge of the haskell.org landing page would ease the user experience by providing clearer ways to install GHC on various platforms. Ideally we could have a GUI to install libraries easily, like many GNU/Linux package managers offer. That being said, I was also suggested the idea of a grant and/or sponsorship. What we need is less a capitalist framework around that task and more of an incentive to invest a serious amount of work and quality so that it becomes, at last, the non-issue it should have always been. The important thing to keep in mind is that the GNU/Linux and macOS users *cannot* hold the Windows users to the same standards in terms of CLI usability. I cannot weigh in my opinion on the most recent iterations of PowerShell, but Windows XP's cmd.exe was excruciating, to say the least. Now, I know some of you will prefer to have this task handled by competent volunteers, but I am under the moral obligation to say that expecting salvation and better tomorrows from people who have yet to make their presence known in the thirty years of existence of our dear language, is at best mild delusion, at worse folly that will only widen the gap between what is needed to get Haskell up and running smoothly on the Windows platform and the average skill of Windows users. I am not suggesting that my email is The True Way to follow so that everything is fixed forever, and if we can, as a community, arrive to some satisfying workflow that would benefit rather than alienate our Windows user base, this would would be wonderful. Thank you for reading until the end. Cheers, Hécate. PS: I am in no way trying to berate anyone for their implied incompetence, or imply that Windows users are stupid and/or technologically impaired. This would be misinterpreting my words and lead nowhere but to another OS war on another mailing-list. PPS: I am serious. Please stay on-topic. PPPS: I hold no share, no money or any other form of capital in any Windows packaging company we might or might not end up hiring for the task. I am speaking of experience, for my company used an external contractor to work on our landing (non-product) page, while all hands were on deck to support the product development effort. This allowed us to have a strong foundation to iterate on, and bought us countless hours of development time.

3 3

Inclusion of the parser refactor in 8.12
by Karpov, Mark 12 May '20

12 May '20

Hello, I'd like to mention that it would be nice if this patch https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2377 could be included in 8.12. Right now we have a few issues that Ormolu users have reported which stem from how Haddocks are parsed by GHC (e.g. that issue when a file starts with haddock it must have a module header). I originally planned to work on those myself, but today I discovered that Vlad is already working on it. Best, Mark

2 1

Removal of UniqMap module
by Matthew Pickering 10 May '20

10 May '20

Hi, I noticed that the UniqMap module was removed from the tree See 1c7c6f1afc8e7f7ba5d256780bc9d5bb5f3e7601 Why was it removed? I needed it today and now I am unsure what the suitable replacement is. As a general point, please can we stop with these annoying refactorings which delete unused code and move around definitions for no clear purpose. The amount of churn on the code base has wasted me a lot of time recently. Cheers, Matt

3 2

Re: [Haskell-cafe] Decorating exceptions with backtrace information
by Michal J Gajda 09 May '20

09 May '20

Ben, I agree with you that is a great idea! I can add a few more real world examples: * we get exception from a foreign library that we bound, * we get an exception from a platform (I believe Windows supports throwing exceptions to programs), * user presses CTRL-C and we want to know where our program hanged. * we get infamous <<loop>>, because in theory nobody wants non-terminating programs, but in practice everybody gets them sometimes. I also use `ExceptT`, `EitherT` for processing large sets of data, because that allows me to contain the errors efficiently. However from time to time, I get an error to blow up **and I cannot even locate which library was guilty**. It would be nice to extract them automatically and put them into error database before they are prioritized. -- Cheers Michał

1 0

Unique invariants: GHC invocation vs scope?
by Csaba Hruska 08 May '20

08 May '20

Hello, What are the intended invariants of Unique values? So far I thought that it is always gives a unique identity to things during a whole GHC invocation. However this is not true. I.e. eta expansion breaks this assumption. Here is a snippet from the STG IR of GHC.PrimopWrappers: extendInt8# [InlPrag=NOINLINE] :: Int8# -> Int# [GblId, Arity=1, Unf=OtherCon []] = \r [eta_B1] extendInt8# [eta_B1]; ord# [InlPrag=NOINLINE] :: Char# -> Int# [GblId, Arity=1, Unf=OtherCon []] = \r [eta_B1] ord# [eta_B1]; Where eta_B1 is redefined, so it is only unique in the scope. Is this intentional? Thanks, Csaba Hruska

2 1

[RFC] Compiler pipeline timings visualization
by Sergej Jaskiewicz 06 May '20

06 May '20

tl;dr: I propose adding a new GHC flag for generating a log that allows visualizing how much time each stage in the compiler pipleline took, similar to Clang's -ftime-trace. Hello, everyone. I'd like to tell you about a feature I've been working on recently, namely, the ability to generate and visualize how long each stage of the compilation pipeline takes to complete. This is basically about the same as the -ftime-trace flag that has landed in Clang several months ago [1]. The initial motivation for this feature was the desire to understand why compilation times are so long when using LLVM as backend. But later I realized that this functionality is useful on its own for end users, not just GHC devs, so it would make sense to add a new flag -ddump-time-trace. Since not only does Haskell have complex type system, but also there is a variety of language extensions, we, the Haskell users, often experience very long compilation times. For instance, the usage of the TypeFaimilies extension can considerably slow down the compilation process [2]. It is useful to understand how you can fix your code so that it compiles faster. There are two options for that right now: - Building GHC from source for profiling and using the just-built GHC for compiling your problem code. - Building the compiler from source with event log support [3]. The former option just doesn't do it, since the output would be "which GHC function calls took how much time", but there'd be no information about which part of the user code was being compiled. The latter option is much closer to what we need. If we link the GHC executable with the -eventlog flag, then various significant events will be written to a special log file. For example, "Parser began parsing the Main.hs file after 5 ms since GHC has started, and ended parsing it 3 ms after that". The resulting log file can be parsed with the ghc-events library [4], and also visualized using the ThreadScope app [5]. Bu this approach has its disadvantages. Firstly, if the user wants visualization, they'd have to install ThreadScope. Some companies' internal policies prohibit installing third-party apps from the internet. It would be good if we could generate a log that could be visualized on any computer with a browser. For that we could use the Chrome Trace Event format [6]. This is an ordinary JSON file with a specific structure that can be viewed in the Chrome browser by going to the chrome://tracing page, or on https://speedscope.app. A file in exactly this format would be generated by Clang if you passed it the -ftime-trace flag. Secondly, the event log contains many events that are not relevant to the end user, for example, thread creation, memory allocation, etc. As an initial proof of concept, I've developed a command line tool for transforming event log files to Chrome Trace Event files [7]. Thirdly, in order for the event log to be generated, you'd still have to build GHC from source. The majority of the GHC users won't go this way. Not only would it require some basic understanding of the GHC building process, but also building itself takes quite some time. It would be great if the needed functionality came with GHC out of the box. This is why I've added support for generating Trace Event files into my fork of GHC [8], and I would like to propose including this feature into the mainline GHC. (Note that my implementation is still a bit buggy, for example, it only works in -j mode. This will be fixed.) You can now execute the following command: ghc -ddump-to-file -ddump-file-prefix="Main." -ddump-time-trace -j -O3 Main.hs And receive this image [9]. Here, we've compiled two modules, one of which depends on the other. One more difference from event log is that now various metadata (like file and module names) are emitted as a separate JSON attribute, instead of being encoded in the name of an event. For example, parsing the Main.hs file and parsing the QSort.hs file in one compilation are events with the same name, but different metadata. We can group them together if we want to know how much time the parsing took overall. The event log format doesn't allow us to do it. So, we can now generate a Trace Event file from a single GHC invocation. However, most projects use build systems that invoke the compiler many times. It would be good if we could form a log for the whole project. This is solved by merging logs. However, there is one subtlety: the events in logs use relative timestamps (the number of microseconds since the process has started). To combine logs from multiple processes, we add a clock synchronization point into each trace log in the form of an additional 'beginningOfTime' JSON attribute that contains the absolute time when the proccess has started. There is a Python script that performs the actual merging [10]. This is how it looks like with multiple processes [11]. Also, I've implemented generation of the 'beginningOfTime' attribute in LLVM [12], so build systems could take advantage of that and combine GHC trace logs with llc/opt trace logs when GHC uses LLVM as backend. Thoughts? Sergej. [1] https://aras-p.info/blog/2019/01/16/time-trace-timeline-flame-chart-profile… [2] https://gitlab.haskell.org/ghc/ghc/issues/8095 [3] https://gitlab.haskell.org/ghc/ghc/-/wikis/event-log [4] http://hackage.haskell.org/package/ghc-events [5] https://wiki.haskell.org/ThreadScope [6] https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchN… [7] https://github.com/broadwaylamb/ghc-eventlog-chrome [8] https://gitlab.haskell.org/broadwaylamb/ghc/-/commits/timetrace-better-meta… [9] https://user-images.githubusercontent.com/16309982/79079705-39775e00-7d19-1… [10] https://github.com/broadwaylamb/merge_trace_events [11] https://user-images.githubusercontent.com/16309982/79080338-ad673580-7d1c-1… [12] https://github.com/llvm/llvm-project/commit/2899103108d38215af8aae377cd0e54…

7 6

[8.12] Documentation plans
by Hécate 06 May '20

06 May '20

Hello ghc-devs For everyone who doesn't know me (yet), I am Hécate, and I coordinate the the Haskell Docs initiative. You may have seen me on various community channels and on social media to recruit lost souls^W^Wmotivated volunteers to help improve the documentation of the `base` library. It can be a daunting task, hence this page that I set up to guide newcomers and track ongoing work[0] The point of my message is the following: If there are any modules you would like to see prioritised for the next release (8.12), please contact us. Current efforts are very organic and stem from personal hardships with the docs, but if you feel that some parts of the docs have been left too long on their own, give us a heads-up. If you want to personally take on a module whose documentation you deem lacking, feel free to join us on #Haskell-docs[1] , so we can coordinate and avoid multiple people working at the same time in an uncoordinated manner towards the same goal. And finally if you do not wish to get involved but still wish to support, we communicate on Twitter[2] and the Fediverse[3]. I would like to end this email by thanking Ben and Carter for their support and guidance. The Core Libraries Committee has been instrumental to the development of these efforts. Cheers, and take care. [0]: https://gitlab.haskell.org/ghc/ghc/issues/17929 [1]: https://webchat.freenode.net/ (enter #Haskell-docs in the 'channel' field) [2]: twitter.com/search?q=%23HaskellDocs [3]: https://search.social/?q=%23haskelldocs -- Hécate IRC: Uniaika Twitter: @TechnoEmpress Fediverse: @hecate@pleroma.fr

3 3

Re: Connecting the Wolfram Language to Haskell
by Compl Yue 05 May '20

05 May '20

Hi, If you are already running atop the Jupyter technology stack, IHaskel [1] may be very straight forward to be incorporated from technical aspect (while licensing aspect is out of my expertise). But still I would like take this opportunity to have more/further evaluation from you, about [2] , with by far my implementation [3] and application [4]. Once a frontend plugin can be injected into a GHCi session, and hooked up to some interactive UI, a new door is opened to allow much easier setup & use of GHC API interactively, like demonstrated in Hadui [4]. Currently there are too many different ways to setup a GHC API session, HIE has tried hard to unify them, but itself is yet under transition. I see the frontend interface being a proper abstraction even extended to WebUI/GUI applications, making interactions perfectly decoupled from how the underlying artifacts are organized, thus worth further consideration. While IHaskell is more powerful and better established as with Jupyter notebook, I chose the frontend route because IHaskell didn't come to today's maturity when I needed something like Hadui, and ZeroMQ seems bloating to my cases, even for now. Cheers, Compl [1] https://github.com/gibiansky/IHaskell [2] https://gitlab.haskell.org/ghc/ghc/issues/17348 [3] https://gitlab.haskell.org/complyue/ghc/tree/ghc-8.6-ife [4] https://github.com/complyue/hadui On 2020/5/1 上午5:13, Ben Gamari wrote: Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> <ghc-devs(a)haskell.org> writes: Friends Short summary: can someone familiar with using the GHC API offer advice on getting the Wolfram Language connected to Haskell? Hi Todd, et al., This sounds like a great project. I have fond memories of Mathematica from my studies. ... We have the following basic line of code for evaluating a string of Haskell code: r <- liftIO $ runInterpreter $ do { setImports ["Prelude"]; eval strToEvaluate} The problem is that this is a one-shot evaluation, and we want a long-lived interactive Haskell session, to which a series of inputs can be directed. We have been told that we have to use GHCi for that, but we don't know how to do it. It appears that you are using the `hint` library [1] for evaluation. I'll admit that I've not used hint; it looks quite sensible but I do not know what limitations you might encounter. It looks like its approach to error handling may leave something to be desired. Nevertheless, we can work with it for now; if we run into its limitations then the alternative is to use the GHC API directly, as suggested by Simon. The basic flow of our functionality is as follows: 1) User calls StartExternalSession["LanguageName"] to launch an interpreter for the language. This process remains running and can be used for multiple calls. 2) User calls ExternalEvaluate[session, "some code"] to execute the given code in the external language and return a result converted into native Wolfram Language types (strings, numbers, lists, associations, etc.) Sure. ... We have attached a simple file of Haskell code that one of our engineers has successfully used to get a basic evaluation of Haskell code from the Wolfram Language, but it uses the single-shot evaluation code that was given above, and so is not suitable. We would appreciate any help that you can give us, or developers or resources you can point us at, to assist in integrating Haskell into our ExternalEvaluate system. It looks like you will want to push the `runInterpreter` out of the `forever`. Afterall, you want the interpreter session to persist over multiple requests. Doing this isn't difficult but does require some monad transformer shuffling, which may be unfamiliar to someone coming from another language. I've put up a cleaned up version of your program here [1]; hopefully this is enough to get you started. Do note that this requires a patched version of zeromq4-haskell due to a minor bug [2] which I have fixed [3]. Do note that there is a related effort, iHaskell [4], which provides a Haskell kernel for Jupyter Notebook. This might be a place to draw inspiration from. Let us know how things go and don't hesitate to be in touch if you have questions regarding the GHC API. Cheers, - Ben [1] https://github.com/bgamari/zeromq-hint [2] https://gitlab.com/twittner/zeromq-haskell/-/issues/66 [3] https://gitlab.com/twittner/zeromq-haskell/-/merge_requests/6 [4] https://github.com/gibiansky/IHaskell _______________________________________________ ghc-devs mailing listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0