- ghc-devs - Haskell.org

How is account sign-up supposed to work?
by Tom Ellis 12 Dec '23

12 Dec '23

Hello GHC devs, It is hard for new users to understand how to get their new Gitlab accounts approved by an administrator. See, for example, these messages, both in the last ten days: * https://discourse.haskell.org/t/why-isalpha-can-parse-some-non-alphabetic-u… * https://old.reddit.com/r/haskell/comments/18ge6vj/access_to_ghc_gitlab_for_… The Wiki doesn't seem to provide any guidance in the "Contributing" or "Newcomers" sections. Nor does ghc.dev. Perhaps that's understandable; GHC is not the Gitlab instance. * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#newcomers-to-ghc * https://ghc.dev/ So how is a new user supposed to know how to get their accounts approved? It would be nice to make the process super clear. This is a longstanding issue. Tom

3 3

Build GHC in GHC2021
by Arnaud Spiwack 11 Dec '23

11 Dec '23

Dear GHC devs, Year 2024 is upon us. GHC2021 was released 2 years ago, in GHC 9.2. I think it's time for the base language for GHC to be GHC2021. What do we think? PS: I don't actually know where the base language for GHC is specified. I couldn't find it with a cursory search PPS: if someone makes an MR, bonus points for clearing up hundreds of lines of now-unnecessary extension on top of files. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

5 6

"Merge-buddy" response
by Alan & Kim Zimmerman 04 Dec '23

04 Dec '23

Hi all If you recall I asked a while back for people to help me get my exact print annotation re-work stack merged. I had a number of people step up to offer their help (Brandon Allbery, Zubin Duggal, Ben Gamari and Alexandre Baldé). Of these, Brandon Allbery really stepped up to the plate. We got into a daily rhythm and have now landed 37 Merge Requests, completing my initial rework. Thank you very much. There has been further discussion of next steps at https://gitlab.haskell.org/ghc/ghc/-/issues/23447, and I will be starting on the further simplification we have discussed there. Thanks again all. Alan

1 0

Annotating instances
by Jaro Reinders 04 Dec '23

04 Dec '23

Hi GHC devs, I'm working on a GHC plugin which implements a custom instance resolution mechanism: https://github.com/noughtmare/transitive-constraint-plugin Currently, I need to place instances in a specific order in a specific file to recognize them and use them in my plugin. I think my life would be a lot easier if I could put annotations on instances. I imagine a syntax like this: data MyInstanceTypes = Refl | Trans deriving Eq class f <= g where inj :: f x -> g x instance {-# ANN instance Refl #-} f <= f where inj = id instance {-# ANN instance Trans #-} forall f g h. (f <= g, g <= h) => f <= h where inj = inj @g @h . inj @f @g Using this information I should be able to find the right instances in a more reliable way. One more thing I was thinking about is to make it possible to remove these instances from the normal resolution algorithm and only allow them to be used by my plugin. Do you think this would be easy to implement and useful? Or are there other ways to achieve this? Cheers, Jaro

3 7

Problems building cabal-install?
by Viktor Dukhovni 26 Nov '23

26 Nov '23

I am having a rather unexpected difficulty building older versions of cabal-install. The invariably run into conflicts between "Cabal" and "Cabal-syntax". The latter shows up as a dependency of "Cabal" on hackage, but not in the upstream Git repo. Is there is there some sort of problem with the hackage metadata for Cabal 3.0, 3.2, 3.4, ... It is odd for these to have "Cabal-syntax 3.10.*" as a dependency, with conflicting definitions. -- Viktor.

2 6

Upcoming GHC 9.6.4 release
by Zubin Duggal 24 Nov '23

24 Nov '23

Hi all, We are planning a release in the 9.6 series before Christmas, with a preliminary ETA of 15th December. Release tracking ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/24017 Please use this ticket to request any submodule bumps or for any other discussion related to the release. If you would like any patches to be considered for inclusion in this release please ensure that the corresponding Merge Requests are marked with the ~"backport needed:9.6" label. The current set of all MRs being considered for inclusion can be viewed at https://gitlab.haskell.org/ghc/ghc/-/merge_requests?scope=all&state=all&lab… Cheers, Zubin

2 3

Docs for RTS option -I
by Bryan Richter 22 Nov '23

22 Nov '23

The original docs are here: https://downloads.haskell.org/ghc/latest/docs/users_guide/runtime_control.h… They raised more questions than answers for me, so I took a stab at rewriting them, and sprinkled in some questions where I need better understanding. Anyone care to fill in my blanks? ----------------- Set the amount of idle time which must pass before an idle GC is performed. Setting -I0 disables the idle GC. The idle GC only affects the threaded and SMP versions of the RTS (see -threaded, Options affecting linking). When the idle GC is enabled, a major GC is automatically performed if the runtime has been idle (i.e., no Haskell computation has been running) for the specified period of time. For an interactive application, it is probably a good idea to use the idle GC, because this will allow finalizers to run and deadlocked threads to be detected in the idle time when no Haskell computation is happening. [Why is this a good thing? What happens when the idle GC is disabled?] Also, it will mean that a GC is less likely to happen when the application is busy, so application responsiveness may be improved. However, if the amount of live data in the heap is particularly large, then the idle GC can cause a significant penalty to responsiveness. [Why? Is it because the idle GC was delayed by waiting for some idle time, and thus has more work to do?]. Conversely, too small of an interval could adversely affect interactive responsiveness [How? And how is this worse than having idle GC disabled? What is the actual behavior when it's disabled, anyway?] The idle period timer only resets after some activity by a Haskell thread. Therefore, once an idle GC is triggered, another one won't be scheduled until more work is performed. This is an experimental feature. Please let us know if it causes problems and/or could benefit from further tuning.

2 3

Account Approval
by Matthew Hammond 20 Nov '23

20 Nov '23

Hello everyone, I’ve been working on my own Haskell interpreter and found a strange case that GHC seems to hang on until it overflows, where I would expect a proper error. I’m fairly new to Haskell, and completely new to the GHC codebase, but I figured I might as well give it a shot! I’ve made an account on the GitLab, and I’m requesting approval please. Thanks, Matthew Hammond.

2 1

Re: Support conversion from (UArray i Word8) to ShortByteString?
by Matthew Craven 14 Nov '23

14 Nov '23

Viktor, Your proposed `arrayToByteArray` seems plausible. Your proposed `byteArrayToShort` is just the newtype-constructor `ShortByteString` which is exposed from Data.ByteString.Short since bytestring-0.12.0.0. > An alternative is to add a tailored version of the UArray and STUArray > APIs to 'MutableByteArray' by extending the rather limited API of > 'Data.Array.Byte': How does this compare to the interface provided by primitive:Data.Primitive.ByteArray? Their `runByteArray` is your `runMutableByteArray`. > The 'ShortByteString' type in the "bytestring" package has seen some > singnificant improvement recently, and yet its API is still noticeably > limited in comparison to its pinned, I/O friendly 'ByteString' elder > sibling. > > One of the limitations is that that there are fewer ways to construct a > 'ShortByteString' object. One often has to restort to constructing a > pinned ByteString, and then copy. (There no "ST" Builders that write > to resizable MutableByteArrays instead of raw memory pointers). > > Meanwhile, under-the covers, both the "UArray i Word8" type and > 'ShortByteString' hold an immutable 'ByteArray', and the STUArray API > provides a flexible "UArray" construction interface. > > Would it be reasonable to "bridge" the two APIs: > > Data.Array.Unboxed: (re-export from Data.Array.Base) > import Data.Array.Byte > > arrayToByteArray :: UArray i Word8 -> ByteArray > arrayToByteArray (UArray _ _ _ ba#) = ByteArray ba# > {-# INLINE arrayToByArrray #-} > > Data.ByteString.Short: (re-export from Data.ByteString.Short.Internal) > byteArrayToShort :: ByteArray -> ShortByteString > byteArrayToShort = coerce > {-# INLINE byteArrayToShort #-} > > It would then be possible to write: > > short = byteArrayToShort $ arrayToByteArray $ runSTUArray m > where > m = do > a <- newArray (0, last) 0 -- zero fill > sequence_ [ writeArray a ix e | (ix, e) <- generator ] > > and generate the bytes of a 'ShortByteString' from an arbitrary > computation, possibly merging multiple inputs into some bytes by using > the recently introduced "modifyArray" (or explicit read/modify/write). > > Any thoughts about the wisdom or lack thereof of this proposal? > > An alternative is to add a tailored version of the UArray and STUArray > APIs to 'MutableByteArray' by extending the rather limited API of > 'Data.Array.Byte': > > runMutableByteArray :: (forall s. ST s (MutableByteArray s)) > -> ByteArray > runMutableByteArray m = runST $ m >>= freezeMutableByteArray > > freezeMutableByteArray (MutableByteArray mba#) = > ST $ \s -> case unsafeFreezeByteArray# mba# s of > (# s', ba# #) -> (# s', ByteArray ba# #) > > Since "Data.Array.Byte" is an "array" (rather than string) interface, it > could have a richer set of indexed read/write/modify primitives along > the lines of those found in "Data.Array.STUArray", but specialised to > 'Word8' elements and implicit zero-based integer indexing. > > The flexible construction I seek would then be via "Data.Array.Bytes", > rather than the somewhat too general index and value types from UArray. > > short = byteArrayToShort $ runMutableByteArray m > where > m = do > a <- newByteArray size 0 -- 0 fill > sequence_ [ writeByteArray a ix e | (ix, e) <- generator ] > > In this scenario, the indexed-mutation of ShortByteStrings under > construction, or indexed-mutation of copies for various transformations, > could live in Data.Array.Byte, with ShortByteString and various > applications leveraging the random-access mutation (and resizing, ...) > to implement higher level operations. > > -- > Viktor.

2 1

Support conversion from (UArray i Word8) to ShortByteString?
by Viktor Dukhovni 11 Nov '23

11 Nov '23

The 'ShortByteString' type in the "bytestring" package has seen some singnificant improvement recently, and yet its API is still noticeably limited in comparison to its pinned, I/O friendly 'ByteString' elder sibling. One of the limitations is that that there are fewer ways to construct a 'ShortByteString' object. One often has to restort to constructing a pinned ByteString, and then copy. (There no "ST" Builders that write to resizable MutableByteArrays instead of raw memory pointers). Meanwhile, under-the covers, both the "UArray i Word8" type and 'ShortByteString' hold an immutable 'ByteArray', and the STUArray API provides a flexible "UArray" construction interface. Would it be reasonable to "bridge" the two APIs: Data.Array.Unboxed: (re-export from Data.Array.Base) import Data.Array.Byte arrayToByteArray :: UArray i Word8 -> ByteArray arrayToByteArray (UArray _ _ _ ba#) = ByteArray ba# {-# INLINE arrayToByArrray #-} Data.ByteString.Short: (re-export from Data.ByteString.Short.Internal) byteArrayToShort :: ByteArray -> ShortByteString byteArrayToShort = coerce {-# INLINE byteArrayToShort #-} It would then be possible to write: short = byteArrayToShort $ arrayToByteArray $ runSTUArray m where m = do a <- newArray (0, last) 0 -- zero fill sequence_ [ writeArray a ix e | (ix, e) <- generator ] and generate the bytes of a 'ShortByteString' from an arbitrary computation, possibly merging multiple inputs into some bytes by using the recently introduced "modifyArray" (or explicit read/modify/write). Any thoughts about the wisdom or lack thereof of this proposal? An alternative is to add a tailored version of the UArray and STUArray APIs to 'MutableByteArray' by extending the rather limited API of 'Data.Array.Byte': runMutableByteArray :: (forall s. ST s (MutableByteArray s)) -> ByteArray runMutableByteArray m = runST $ m >>= freezeMutableByteArray freezeMutableByteArray (MutableByteArray mba#) = ST $ \s -> case unsafeFreezeByteArray# mba# s of (# s', ba# #) -> (# s', ByteArray ba# #) Since "Data.Array.Byte" is an "array" (rather than string) interface, it could have a richer set of indexed read/write/modify primitives along the lines of those found in "Data.Array.STUArray", but specialised to 'Word8' elements and implicit zero-based integer indexing. The flexible construction I seek would then be via "Data.Array.Bytes", rather than the somewhat too general index and value types from UArray. short = byteArrayToShort $ runMutableByteArray m where m = do a <- newByteArray size 0 -- 0 fill sequence_ [ writeByteArray a ix e | (ix, e) <- generator ] In this scenario, the indexed-mutation of ShortByteStrings under construction, or indexed-mutation of copies for various transformations, could live in Data.Array.Byte, with ShortByteString and various applications leveraging the random-access mutation (and resizing, ...) to implement higher level operations. -- Viktor.

1 0