- ghc-devs - Haskell.org

Help implementing Multiline String Literals
by Brandon Chinn 08 Feb '24

08 Feb '24

Hello! I'm trying to implement #24390 <https://gitlab.haskell.org/ghc/ghc/-/issues/24390>, which implements the multiline string literals proposal <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-m…> (existing work done in wip/multiline-strings <https://gitlab.haskell.org/ghc/ghc/-/compare/master...wip%2Fmultiline-strin…>). I originally suggested adding HsMultilineString to HsLit and translating it to HsString in renaming, then Matthew Pickering suggested I translate it in desugaring instead. I tried going down this approach, but I'm running into two main issues: Escaped characters and Overloaded strings. Apologies in advance for a long email. *TL;DR* - The best implementation I could think of involves a complete rewrite of how strings are lexed and modifying HsString instead of adding a new HsMultilineString constructor. If this is absolutely crazy talk, please dissuade me from this :) ===== Problem 1: Escaped characters ===== Currently, Lexer.x resolves escaped characters for string literals. In the Note [Literal source text], we see that this is intentional; HsString should contain a normalized internal representation. However, multiline string literals have a post-processing step that requires distinguishing between the user typing a newline vs the user typing literally a backslash + an `N` (and other things like knowing if a user typed in `\&`, which currently goes away in lexing as well). Fundamentally, the current logic to resolve escaped characters is specific to the Lexer monad and operates on a per-character basis. But the multiline string literals proposal requires post-processing the whole string, then resolving escaped characters all at once. Possible solutions: (1.1) Duplicate the logic for resolving escaped characters * Pro: Leaves normal string lexing untouched * Con: Two sources of truth, possibly divergent behaviors between multiline and normal strings (1.2) Stick the post-processed string back into P, then rerun normal string lexing to resolve escaped characters * Pro: Leaves normal string lexing untouched * Con: Seems roundabout, inefficient, and hacky (1.3) Refactor the resolve-escaped-characters logic to work in both the P monad and as a pure function `String -> String` * Pro: Reuses same escaped-characters logic for both normal + multiline strings * Con: Different overall behavior between the two string types: Normal string still lexed per-character, Multiline strings would lex everything * Con: Small refactor of lexing normal strings, which could introduce regressions (1.4) Read entire string (both normal + multiline) with no preprocessing (including string gaps or anything, except escaping quote delimiters), and define all post-processing steps as pure `String -> String` functions * Pro: Gets out of monadic code quickly, turn bulk of string logic into pure code * Pro: Processes normal + multiline strings exactly the same * Pro: Opens the door for future string behaviors, e.g. raw string could do the same "read entire string" logic, and just not do any post-processing. * Con: Could be less performant * Con: Major refactor of lexing normal strings, which could introduce regressions I like solution 1.4 the best, as it generalizes string processing behavior the best and is more pipeline-style vs the currently more imperative style. But I recognize possible performance or behavior regressions are a real thing, so if anyone has any thoughts here, I'd love to hear them. ===== Problem 2: Overloaded strings ===== Currently, `HsString s` is converted into `HsOverLit (HsIsString s)` in the renaming phase. Following Matthew's suggestion of resolving multiline string literals in the desugar step, this would mean that multiline string literals are post-processed after OverloadedStrings has already been applied. I don't like any of the solutions this approach brings up: * Do post processing both when Desugaring HsMultilineString AND when Renaming HsMultilineString to HsOverLit - seems wrong to process multiline strings in two different phases * Add HsIsStringMultiline and post process when desugaring both HsMultilineString and HsIsStringMultiline - would ideally like to avoid adding a variant of HsIsStringMultiline Instead, I propose we throw away the HsMultilineString idea and reuse HsString. The multiline syntax would still be preserved in the SourceText, and this also leaves the door open for future string features. For example, if we went with HsMultilineString, then adding raw strings would require adding both HsRawString and HsMultilineRawString. Here are two possible solutions for reusing HsString: (2.1) Add a HsStringType parameter to HsString * HsStringType would define the format of the FastString stored in HsString: Normal => processed, Multiline => stores raw string, needs post-processing * Post processing could occur in desugaring, with or without OverloadedStrings * Pro: Shows the parsed multiline string before processing in -ddump-parsed * Con: HsString containing Multiline strings would not contain the normalized representation mentioned in Note [Literal source text] * Con: Breaking change in the GHC API (2.2) Post-process multiline strings in lexer * Lexer would do all the post processing (for example, in conjunction with solution 1.4) and just return a normal HsString * Pro: Multiline string is immediately desugared and behaves as expected for OverloadedStrings (and any other behaviors of string literals, existing or future) for free * Pro: HsString would still always contain the normalized representation * Con: No way of inspecting the raw multiline parse output before processing, e.g. via -ddump-parsed I'm leaning towards solution 2.1, but curious what people's thoughts are. ===== Closing remarks ===== Again, sorry for the long email. My head is spinning trying to figure out this feature. Any help would be greatly appreciated. As an aside, I last worked on GHC back in 2020 or 2021, and my goodness. The Hadrian build is so much smoother (and faster!? Not sure if it's just my new laptop though) than what it was last time I touched the codebase. Huge thanks to the maintainers, both for the tooling and the docs in the wiki. This is a much more enjoyable experience. Thanks, Brandon

4 6

Why is mixing profiling and dynamic linking unsupported?
by Alexis King 02 Feb '24

02 Feb '24

Hello all, GHC does not support combining -prof and -dynamic. Various places note that these are incompatible, but I have never managed to find a rationale for this incompatibility. I am sure there a good reasons exists, but I am not sure what it is. Does anyone know the reason? And, even better, is the reason written down somewhere? I’d love to understand this better. Thanks, Alexis

2 1

GHC 9.10 release
by Ben Gamari 02 Feb '24

02 Feb '24

Hi all, I am currently in the midst of planning the GHC 9.10 release [1], which we hope to fork on 23 Feb 2024. If you have a major patch that you would like to see included in 9.10, please be in touch. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/milestones/380

9 8

Upcoming GHC 9.8.2 release
by Zubin Duggal 29 Jan '24

29 Jan '24

Hello all, We are currently in the process of preparing the 9.8.2 release, which should be released mid-February. If you would like any patches to be considered for inclusion into this release, please ensure that the corresponding MRs are marked with the ~"backport needed:9.8" label. Any submodule bumps that have made it into previous releases like 9.6.4 will also be backported to 9.8.2. Requests for additional submodule updates should be made on the release tracking ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/24079 Cheers, Zubin

1 0

GHC Steering Committee Call for Nominations
by Adam Gundry 28 Jan '24

28 Jan '24

Dear Haskellers, The GHC Steering Committee is seeking nominations for new members. The committee scrutinizes, debates and eventually decides to accept or reject proposals to change the language or major features supported by GHC. Our processes are described in the GitHub repository where proposals are submitted (https://github.com/ghc-proposals/ghc-proposals) In particular, please have a look at the committee bylaws (https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst) We are looking for members who have the ability to: - understand GHC proposals (e.g. for new language extensions), - find holes and missing corner cases in the specifications, - foresee the interaction with other language or compiler features, - comment constructively and improve proposals through engagement with others, - judge the cost/benefit ratio of changes, and - come to a justifiable conclusion. Ideally, committee members should: - have substantial experience of writing or teaching Haskell; - have a track record of active contributions to the Haskell community; or - have expertise in language design and implementation, in either Haskell or related languages. It is our aim that this committee be diverse; by representing different viewpoints, we will make decisions that benefit larger segments of our community. Even if you are uncertain whether your background qualifies you for the role, you are warmly encouraged to apply. The committee's work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. To nominate yourself, please send an email to me (as the committee secretary) at adam(a)well-typed.com by February 16th 2024, briefly summarising your background and relevant experience. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. Self-nominations are the norm. You can nominate someone else, but please obtain their explicit consent to do so. (We don't want to choose someone who turns out to be unable to serve.) On behalf of the committee, Adam Gundry -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

1 0

How to disable the simple optimizer
by Facundo Domínguez 26 Jan '24

26 Jan '24

Dear devs, I noticed that GHC sometimes inlines bindings during desugaring, e.g foo = z where z = z1 + z2 z1 = 42 z2 = 1 is desugared to foo = 42 + 1 This inlining is problematic when using a plugin like Liquid Haskell, which wants to analyse in Core the local bindings provided by the user. Until ghc-9.6 LH didn't experience the inlining when using the GHC API. And this is despite the fact that using ghc from the command line would seem to always inline during desugaring, even when using -O0. When using ghc-9.8.1 though, even the output of the GHC API started having the bindings inlined. Some debugging with -ddump-ds and -ddump-ds-preopt shows that inlining must be happening in the simple optimizer. Is there anything one could do to disable the optimizations? Thanks in advance, Facundo -- All views and opinions expressed in this email message are the personal opinions of the author and do not represent those of the organization or its customers.

3 3

Help needed with optimization
by Tom Ellis 24 Jan '24

24 Jan '24

Hello GHC devs, I'm trying to understand why my code is not being optimized in the way I would expect. I'm completely stuck and I think I need the advice of an expert. I'm writing an effect system on top of transformers. The effect system wraps monad transformers in a newtype that encodes the composition structure of the transformers at the type level. Because it's a newtype all of the class members are inherited directly from the underlying type using coerce. When I implement something using this effect system I would expect to generate exactly the same code as if I had written it using transformers directly. However, it generates significantly worse code, even in a very simple case. Firstly, a case where I do get the same code. All of these compile to the constant 1. Hooray! https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02… Secondly, a simple cases where I do not get the same code. `mySumMTL` and `mySumNewtype` yield the same code, as expected. After all, `mySumNewtype` does exactly the same thing as `mySumMTL`, it's just wrapped in some newtypes. However, `mySumEff` yields worse code, despite *also* being the same thing as `mySumMTL` just wrapped in some newtypes. https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02… You can compare the generated loops at: https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02… Does anyone have a clue what's going wrong in the optimizer here? I don't think the singleton that I pass around to access the type level index at runtime has anything to do with it. That seems to be optimized away by inlining. Is the simplifier confused by all the coercions? Thanks for any help anyone may be able to shed, Tom

2 2

Google Summer of Code Ideas
by Aaron Allen 24 Jan '24

24 Jan '24

Hello, Haskell will be applying for the Google Summer of Code 2024 program and it would be great to have some project ideas involving GHC. If anything comes to mind, you can submit an idea proposal using the instructions found here: https://summer.haskell.org/ideas.html. Kind Regards, Aaron

1 0

GHC Weekly call
by Simon Peyton Jones 23 Jan '24

23 Jan '24

Dear GHC developers Every week (2pm London time, Tuesdays) we hold a call for people to share what they are working on GHC-land. Would you like to come? The call is open to *any member of the GHC Team. *And *the GHC Team is inclusive*: if you are working on GHC you are a member of the Team: see here for details <https://gitlab.haskell.org/ghc/ghc-hq#2-the-ghc-team>. Why come? - It gives you a window into what is happening in GHC land - It gives you a chance to influence what is happening - It builds community -- you get face-to-face contact with others working on GHC If you'd like to come, drop a line to Matthew Pickering matthew(a)well-typed.com See you there! Simon

1 0

Do you use stack to build hadrian?
by Bryan Richter 19 Jan '24

19 Jan '24

If nobody uses stack to build hadrian, (or even if a few people do), there's talk of removing that option because very few people do use it. Feel free to weigh in at https://gitlab.haskell.org/ghc/ghc/-/issues/24274#note_541913 -Bryan

1 0