From ben at well-typed.com  Wed Jun  8 15:24:54 2022
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 08 Jun 2022 11:24:54 -0400
Subject: Two-factor authentication enforced on gitlab.haskell.org
Message-ID: <87fskf41qo.fsf@smart-cactus.org>

Hi all,

Due to a recent up-tick in spam activity, we have started enforcing
two-factor authentication on gitlab.haskell.org. We hope that this isn't
too much of a burden, but do let us know if so and we can evaluate other
options.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20220608/bbd0885f/attachment.sig>

From ben at well-typed.com  Wed Jun  8 23:37:27 2022
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 08 Jun 2022 19:37:27 -0400
Subject: Two-factor authentication enforced on gitlab.haskell.org
In-Reply-To: <87fskf41qo.fsf@smart-cactus.org>
References: <87fskf41qo.fsf@smart-cactus.org>
Message-ID: <87zgim3ext.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Hi all,
>
> Due to a recent up-tick in spam activity, we have started enforcing
> two-factor authentication on gitlab.haskell.org. We hope that this isn't
> too much of a burden, but do let us know if so and we can evaluate other
> options.
>
Hi all,

Due to user response we have reverted the two-factor authentication
requirement and will instead manually review new account creations for
now. Do feel free to ping either Matt, Andreas, or I via IRC or email if
you attempt to create an account and your request sits unapproved for
more than an hour or two.

Hopefully in the near term we will be able to able to find less onerous
way of dealing with the growing spam problem.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20220608/8c68969b/attachment.sig>

From clintonmead at gmail.com  Tue Jun 21 14:09:56 2022
From: clintonmead at gmail.com (Clinton Mead)
Date: Wed, 22 Jun 2022 00:09:56 +1000
Subject: Can I create a representation polymorphic datatype?
Message-ID: <CAFDVgwFr6MCEnCrPd5pamyOvstWeVCvFDJ_h09aOa6AhDTHumg@mail.gmail.com>

Hi All

I can make a list of unboxed ints like below:

{-# LANGUAGE MagicHash #-}

import GHC.Exts (Int#, Float#)

data IntList = IntTail | IntNode Int# IntList

intListLength :: IntList -> Int
intListLength IntTail = 0
intListLength (IntNode _ rest) = 1 + intListLength rest

I can then make a list of unboxed floats similarly:

data FloatList = FloatTail | FloatNode Int# FloatList

floatListLength :: FloatList -> Int
floatListLength FloatTail = 0
floatListLength (FloatNode _ rest) = 1 + floatListLength rest

But as you can see, this is getting a bit copy-pasta, which is not good. So
instead, lets try this:

newtype GeneralList (a :: l) = Tail | Node a (GeneralList a)

This is not allowed here, I believe because `GeneralList` is expected to
have one representation for all `a`, instead of a representation which
depends on `a`. This is so that if one writes a function:

generalListLength :: GeneralList a -> Int
generalListLength Tail = 0
generalListLength (Node _ rest) = 1 + generalListLength rest

You can't actually compile this into one function, because the relative
location of the "next" pointer can change based on the size of `a`
(assuming `a` is stored first).

However, I can achieve what I want with copy pasting or Template Haskell
hackery.

Is there a way to get GHC to do the copy pasting for me? Or do I have to
make a choice between extra runtime indirection and avoiding ugly code or
having ugly code but avoiding the runtime indirection? A representation
polymorphic list here is something that languages like C++, Rust, and even
C# will handle happily, so Haskell seems behind here unless I'm missing
something,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20220622/b45fe557/attachment.html>

From ben at well-typed.com  Fri Jun 24 20:56:33 2022
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 24 Jun 2022 16:56:33 -0400
Subject: GHC 9.4.1-alpha3 now available
Message-ID: <878rpl3hn7.fsf@smart-cactus.org>


The GHC developers are happy to announce the availability of the third
alpha release of the GHC 9.4 series. Binary distributions, source
distributions, and documentation are available at 
[downloads.haskell.org](https://downloads.haskell.org/ghc/9.4.1-alpha3).

This major release will include:

 - A new profiling mode, `-fprof-late`, which adds automatic cost-center
   annotations to all top-level functions *after* Core optimisation has
   run. This incurs significantly less performance cost while still
   providing informative profiles.

 - A variety of plugin improvements including the introduction of a new
   plugin type, *defaulting plugins*, and the ability for typechecking
   plugins to rewrite type-families.

 - An improved constructed product result analysis, allowing unboxing of
   nested structures, and a new boxity analysis, leading to less reboxing.

 - Introduction of a tag-check elision optimisation, bringing
   significant performance improvements in strict programs.

 - Generalisation of a variety of primitive types to be levity
   polymorphic. Consequently, the `ArrayArray#` type can at long last be
   retired, replaced by standard `Array#`.

 - Introduction of the `\cases` syntax from [GHC proposal 0302]

 - A complete overhaul of GHC's Windows support. This includes a
   migration to a fully Clang-based C toolchain, a deep refactoring of
   the linker, and many fixes in WinIO.

 - Support for multiple home packages, significantly improving support
   in IDEs and other tools for multi-package projects.

 - A refactoring of GHC's error message infrastructure, allowing GHC to
   provide diagnostic information to downstream consumers as structured
   data, greatly easing IDE support.

 - Significant compile-time improvements to runtime and memory consumption.

 - On overhaul of our packaging infrastructure, allowing full
   traceability of release artifacts and more reliable binary
   distributions.

 - ... and much more. See the [release notes] for a full accounting.

Note that, as 9.4.1 is the first release for which the released
artifacts will all be generated by our Hadrian build system, it's possible that there
will be packaging issues. If you enounter trouble while using a binary
distribution, please open a [ticket]. Likewise, if you are a downstream
packager, do consider migrating to [Hadrian] to run your build; the
Hadrian build system can be built using `cabal-install`, `stack`, or the
in-tree [bootstrap script].

We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk
stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
contributors whose on-going financial and in-kind support has
facilitated GHC maintenance and release management over the years.
Finally, this release would not have been possible without the hundreds
of open-source contributors whose work comprise this release.

As always, do give this release a try and open a [ticket] if you see
anything amiss.

Happy testing,

- Ben


[GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst 
[ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
[bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md
[Hadrian]: 
https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian
[release notes]: https://downloads.haskell.org/~ghc/9.4.1-alpha3/docs/users_guide/9.4.1-notes.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20220624/58344447/attachment.sig>

From lists at richarde.dev  Wed Jun 29 14:23:35 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Wed, 29 Jun 2022 14:23:35 +0000
Subject: Can I create a representation polymorphic datatype?
In-Reply-To: <CAFDVgwFr6MCEnCrPd5pamyOvstWeVCvFDJ_h09aOa6AhDTHumg@mail.gmail.com>
References: <CAFDVgwFr6MCEnCrPd5pamyOvstWeVCvFDJ_h09aOa6AhDTHumg@mail.gmail.com>
Message-ID: <010f0181afd8960e-a7e0f553-4460-4a52-ac0c-3ce8394b0848-000000@us-east-2.amazonses.com>

Hi Clinton,

Sadly, GHC does not support what you want. I don't really have much more to add to your post, which accurately describes the problem and correctly describes why we can't have one compiled function that works at multiple representations.

The canonical ticket for this kind of feature is https://gitlab.haskell.org/ghc/ghc/-/issues/14917. I, for one, would welcome further improvements in this direction, but I don't have the capacity to drive them myself.

Richard

> On Jun 21, 2022, at 10:09 AM, Clinton Mead <clintonmead at gmail.com> wrote:
> 
> Hi All
> 
> I can make a list of unboxed ints like below:
> 
> {-# LANGUAGE MagicHash #-}
> 
> import GHC.Exts (Int#, Float#)  
> 
> data IntList = IntTail | IntNode Int# IntList
> 
> intListLength :: IntList -> Int
> intListLength IntTail = 0
> intListLength (IntNode _ rest) = 1 + intListLength rest 
> 
> I can then make a list of unboxed floats similarly:
> 
> data FloatList = FloatTail | FloatNode Int# FloatList
> 
> floatListLength :: FloatList -> Int
> floatListLength FloatTail = 0
> floatListLength (FloatNode _ rest) = 1 + floatListLength rest 
> 
> But as you can see, this is getting a bit copy-pasta, which is not good. So instead, lets try this:
> 
> newtype GeneralList (a :: l) = Tail | Node a (GeneralList a)
> 
> This is not allowed here, I believe because `GeneralList` is expected to have one representation for all `a`, instead of a representation which depends on `a`. This is so that if one writes a function:
> 
> generalListLength :: GeneralList a -> Int
> generalListLength Tail = 0
> generalListLength (Node _ rest) = 1 + generalListLength rest
> 
> You can't actually compile this into one function, because the relative location of the "next" pointer can change based on the size of `a` (assuming `a` is stored first).
> 
> However, I can achieve what I want with copy pasting or Template Haskell hackery. 
> 
> Is there a way to get GHC to do the copy pasting for me? Or do I have to make a choice between extra runtime indirection and avoiding ugly code or having ugly code but avoiding the runtime indirection? A representation polymorphic list here is something that languages like C++, Rust, and even C# will handle happily, so Haskell seems behind here unless I'm missing something, 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20220629/c08c98ef/attachment.html>

From gershomb at gmail.com  Wed Jun 29 23:06:48 2022
From: gershomb at gmail.com (Gershom B)
Date: Wed, 29 Jun 2022 19:06:48 -0400
Subject: Heads up on mailing list stability
Message-ID: <CAM8RHpFC+PocjpUS850dAyZq4GFZROuOsG7Au5JhP5csLA625w@mail.gmail.com>

Hi all!

We're incrementally transitioning some of our mail sending to a new
server. This list is one of the first being migrated to be relayed
through the new server (we're also moving the ghc steering-committee
list). If sending or receiving is dodgier than usual, please let me
know!

--Gershom