Acknowledgement of CI instability

[Sam Derbyshire]

Hi all,

The GHC team would like to acknowledge some ongoing CI instabilities in the
GHC project:

  - regular failures of the i386 job, possibly related to the bump to
debian 12

(although the job still failed occasionally before this),
  - flakiness of the MultiLayerModulesDefsGhciReload test causing the
fedora33-release job to fail,
  - lack of availability of darwin runners, causing aarch64-darwin and
x86_64-darwin jobs to time out.

These issues are currently causing a string of marge batch failures,
holding up several MRs.

We are currently short on resources for addressing problems with CI, so
please bear with us while we sort the situation out. In the meantime, feel
free to let us know of any other CI issues that are impacting your work on
GHC.

Best,

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha2 is now available

[Sam Derbyshire]

... and by that, you presumably mean s/TypeApplications/TypeAbstractions.

On Tue, 22 Aug 2023 at 14:30, Arnaud Spiwack 
wrote:

> Thanks Ben.
>
> For the sake of the future announcements, the first item should have
> s/TypeApplications/TypeApplications/
>
>
> On Thu, 10 Aug 2023 at 17:09, Ben Gamari  wrote:
>
>>
>> The GHC developers are very pleased to announce the availability of the
>> second alpha prerelease of GHC 9.8.1. Binary distributions, source
>> distributions, and documentation are available at
>>
>>https://downloads.haskell.org/ghc/9.8.1-alpha2
>>
>> GHC 9.8 will bring a number of new features and improvements, including:
>>
>>  * Preliminary support the `TypeApplications` language extension
>> [type-binders],
>>allowing types to be bound in type declarations.
>>
>>  * Support for the `ExtendedLiterals` extension, providing syntax for
>>non-word-sized numeric literals in the surface language
>>[extended-literals]
>>
>>  * Improved rewrite rule matching behavior, allowing limited matching of
>>higher-order patterns
>>
>>  * Better support for user-defined warnings by way of the `WARNING`
>> pragma [warnings]
>>
>>  * The introduction of the new `GHC.TypeError.Unsatisfiable`
>>constraint, allowing more predictable user-defined type errors
>> [unsatisfiable]
>>
>>  * Implementation of the export deprecation proposal, allowing module
>>exports to be marked with `DEPRECATE` pragmas [deprecated-exports]
>>
>>  * The addition of build semaphore support for parallel compilation;
>>with coming support in `cabal-install` this will allow better use of
>>parallelism in multi-package builds [jsem]
>>
>>  * More efficient representation of info table provenance information,
>>reducing binary sizes by over 50% in some cases when
>>`-finfo-table-map` is in use
>>
>> A full accounting of changes can be found in the [release notes].
>> This alpha includes around two dozen bug-fixes relative to alpha 1.
>>
>> We would like to thank GitHub, IOG, the Zw3rk stake pool,
>> Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell
>> Foundation, 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 compiling,
>>
>> ~ Ben
>>
>>
>> [type-binders]:
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst
>> [extended-literals
>> ]:
>>
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst
>> [unsatisfiable]:
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst
>> [warnings]:
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst
>> [deprecated-exports
>> ]:
>>
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst
>> [jsem]:
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst
>> [release notes]:
>> https://downloads.haskell.org/ghc/9.8.1-alpha2/docs/users_guide/9.8.1-notes.html
>> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
>> ___
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Coercing a `ByteArray#` into a `MutableByteArray#`

[Sam Derbyshire]

Indeed, this is what the `primitive` package provides to thaw a
`ByteArray#` without copying:

https://hackage.haskell.org/package/primitive-0.8.0.0/docs/src/Data.Primitive.ByteArray.html#unsafeThawByteArray

On Mon, 24 Jul 2023, 20:17 chessai,  wrote:

> Hi Adithya,
>
> The representations are the same. You can do this. I do this somewhat
> often. Just avoid mutating in places where it could result in funky stuffs.
> This is usually pretty easy to spot.
>
> Cheers,
> chessai
>
> On Mon, Jul 24, 2023, 12:59 Adithya Kumar 
> wrote:
>
>> Hello all,
>>
>> I have a use-case where I want to convert `ByteArray#` to
>> `MutableByteArray#`
>> without the copy overhead.
>>
>> Is the underlying memory structure of `ByteArray#` and
>> `MutableByteArray#` the
>> same?
>>
>> If I can guarantee that I won't mutate my `MutableByteArray#`, can I use
>> `unsafeCoerce#` on `ByteArray#` and treat it as `MutableByteArray#`?
>>
>> Best,
>> Adithya
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: CI

[Sam Derbyshire]

I think there's a problem with jobs restarting, on my renamer MR
 there were 5
full pipelines running at once. I had to cancel some of them, but also it
seems some got cancelled by some new CI pipelines restarting.

On Sat, 18 Mar 2023 at 13:59, Simon Peyton Jones <
simon.peytonjo...@gmail.com> wrote:

> All GHC CI pipelines seem stalled, sadly
>
> e.g. https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10123/pipelines
>
> Can someone unglue it?
>
> Thanks!
>
> Simon
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Help! Can't build HEAD

[Sam Derbyshire]

Spam detection software, running on the system "mail.haskell.org", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Perhaps even `git submodule update --init`. On Wed, 15 Mar
   2023 at 13:41, Matthew Pickering  wrote: > You
   need to run `git submodule update` I think. > > On Wed, Mar 15, 2023 at 
12:36 PM
   Simon Peyton Jones >  wrote: > > > > Aargh!
  I can't build HEAD! > > > > I get this: > > ./hadrian/build > > Up to date
   > > ]0;Starting... ]0;Finished in 0.04s Error, file does not exist and no
   > rule available: > > utils/hpc/hpc-bin.cabal > > Build failed. > > > > >
   > This is after > > hadrian/build clean > > ./boot > > ./configure > > >
  > I'm very stalled. All my trees are borked. Can anyone help? > > > > Simon
   > > ghc-devs mailing list > ghc-devs@haskell.org > 
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
   > [...] 

Content analysis details:   (5.8 points, 5.0 required)

 pts rule name  description
 -- --
 0.0 FREEMAIL_FROM  Sender email is commonly abused enduser mail 
provider
(sam.derbyshire[at]gmail.com)
 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language
 0.0 HTML_MESSAGE   BODY: HTML included in message
 0.8 BAYES_50   BODY: Bayes spam probability is 40 to 60%
[score: 0.5000]
 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid

The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.

--- Begin Message ---
Perhaps even `git submodule update --init`.

On Wed, 15 Mar 2023 at 13:41, Matthew Pickering 
wrote:

> You need to run `git submodule update` I think.
>
> On Wed, Mar 15, 2023 at 12:36 PM Simon Peyton Jones
>  wrote:
> >
> > Aargh!  I can't build HEAD!
> >
> > I get this:
> > ./hadrian/build
> > Up to date
> > ]0;Starting... ]0;Finished in 0.04s Error, file does not exist and no
> rule available:
> >   utils/hpc/hpc-bin.cabal
> > Build failed.
> >
> >
> > This is after
> > hadrian/build clean
> > ./boot
> > ./configure
> >
> > I'm very stalled.  All my trees are borked.  Can anyone help?
> >
> > Simon
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--- End Message ---

Re: Alternative to isTypeLevPoly

[Sam Derbyshire]

Hmm, that's strange, both isTypeLevPoly and typeHasFixedRuntimeRep have the
same precondition: the kind of the type is of the form TYPE rep. So they
should panic in the same circumstances. Can you give a bit more
information? What panics are you running into?

On Wed, 14 Sept 2022 at 18:40, Csaba Hruska  wrote:

> Hi,
> Thanks for the tip, I've tried it and it behaves differently than
> isTypeLevPoly. I can get panic when querying the reptype for fixed
> reptypes. That means isTypeLevPoly semantically is not the same as the
> negated result of typeHasFixedRuntimeRep.
>
> On Wed, 14 Sep 2022, 18:19 Sam Derbyshire, 
> wrote:
>
>> Hi Csaba,
>>
>> I think you want the function typeHasFixedRuntimeRep from GHC.Core.Type.
>>
>> Best,
>>
>> Sam
>>
>> On Wed, 14 Sept 2022 at 18:12, Csaba Hruska 
>> wrote:
>>
>>> Hello GHC Devs,
>>>
>>> I've noticed that the `isTypeLevPoly` function has been removed from GHC
>>> since 9.4.
>>> I used it to decide the validity of querying the representation type of
>>> every value in the STG IR.
>>> It was mandatory to prevent GHC panics, because there are a lot of
>>> partial functions in GHC.
>>> Is there an alternative to `isTypeLevPoly` in GHC 9.4?
>>>
>>> Best regards,
>>> Csaba Hruska
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Alternative to isTypeLevPoly

[Sam Derbyshire]

Hi Csaba,

I think you want the function typeHasFixedRuntimeRep from GHC.Core.Type.

Best,

Sam

On Wed, 14 Sept 2022 at 18:12, Csaba Hruska  wrote:

> Hello GHC Devs,
>
> I've noticed that the `isTypeLevPoly` function has been removed from GHC
> since 9.4.
> I used it to decide the validity of querying the representation type of
> every value in the STG IR.
> It was mandatory to prevent GHC panics, because there are a lot of partial
> functions in GHC.
> Is there an alternative to `isTypeLevPoly` in GHC 9.4?
>
> Best regards,
> Csaba Hruska
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Unix library apparently broken

[Sam Derbyshire]

Hi Simon,

This is due to my patch 4786acf7

landing, which means GHC does better at recognising the redundant pattern
match.
That MR also updated the unix submodule, in order to suppress that pattern
match warning.

So I would guess that you have not updated the unix submodule after
rebasing your MR; perhaps try "git submodule update"?
The unix submodule is currently on commit 2a6079a2

.

Hope that helps,

Sam

On Tue, 6 Sept 2022 at 17:52, Simon Peyton Jones <
simon.peytonjo...@gmail.com> wrote:

> My !8750 builds are failing in the Unix library with the "pattern match is
> redundant" message below.
>
> And indeed the pattern match is redundant.  Here's the .hs version of the
> file
>
> unpackRLimit :: CRLim -> ResourceLimit
> unpackRLimit (18446744073709551615)  = ResourceLimitInfinity
> {-# LINE 101 "libraries/unix/System/Posix/Resource.hsc" #-}
> unpackRLimit other
>
> {-# LINE 103 "libraries/unix/System/Posix/Resource.hsc" #-}
> | ((18446744073709551615) :: CRLim) /= (18446744073709551615) &&
> {-# LINE 104 "libraries/unix/System/Posix/Resource.hsc" #-}
>   other == (18446744073709551615) = ResourceLimitUnknown
> {-# LINE 105 "libraries/unix/System/Posix/Resource.hsc" #-}
>
> {-# LINE 106 "libraries/unix/System/Posix/Resource.hsc" #-}
>
> {-# LINE 107 "libraries/unix/System/Posix/Resource.hsc" #-}
> | ((18446744073709551615) :: CRLim) /= (18446744073709551615) &&
> {-# LINE 108 "libraries/unix/System/Posix/Resource.hsc" #-}
>   other == (18446744073709551615) = ResourceLimitUnknown
> {-# LINE 109 "libraries/unix/System/Posix/Resource.hsc" #-}
>
> {-# LINE 110 "libraries/unix/System/Posix/Resource.hsc" #-}
> | otherwise = ResourceLimit (fromIntegral other)
>
> The red line means that the blue lines will fail.
>
> So the warning looks correct.  But it's stopping my CI from working.  I
> have no idea why this doesn't happen in HEAD.   Can anyone help?
>
> Thanks
>
> Simon
>
>
> Command line: _build/stage0/bin/aarch64-linux-gnu-ghc -Wall -Wcompat
> -fdiagnostics-color=never -dynamic-too -hisuf hi -osuf o -hcsuf hc -static
> -hide-all-packages -no-user-package-db '-package-env -' '-package-db
> _build/stage1/lib/package.conf.d' '-this-unit-id unix-2.7.2.2' '-package-id
> base-4.17.0.0' '-package-id bytestring-0.11.3.1' '-package-id time-1.12.2'
> -i -i/builds/ghc/ghc/_build/stage1/libraries/unix/build
> -i/builds/ghc/ghc/_build/stage1/libraries/unix/build/autogen
> -i/builds/ghc/ghc/libraries/unix -Irts/include
> -I_build/stage1/libraries/unix/build
> -I_build/stage1/libraries/unix/build/include -Ilibraries/unix/include
> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/time-1.12.2/include
> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/bytestring-0.11.3.1/include
> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/base-4.17.0.0/include
> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/ghc-bignum-1.3/include
> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/rts-1.0.2/include
> -optP-include
> -optP_build/stage1/libraries/unix/build/autogen/cabal_macros.h -outputdir
> _build/stage1/libraries/unix/build -Wnoncanonical-monad-instances
> -optc-Wno-error=inline -optP-Wno-nonportable-include-path -c
> _build/stage1/libraries/unix/build/System/Posix/Resource.hs -o
> _build/stage1/libraries/unix/build/System/Posix/Resource.o
> -fllvm-fill-undef-with-garbage -dno-debug-output -Wall -XHaskell2010
> -no-global-package-db
> -package-db=/builds/ghc/ghc/_build/stage1/lib/package.conf.d
> -ghcversion-file=rts/include/ghcversion.h
> -ghcversion-file=rts/include/ghcversion.h -O -Wno-deprecated-flags -Werror
> -dlint
> ===> Command failed with error code: 1
> libraries/unix/System/Posix/Resource.hsc:107:7: error:
> [-Woverlapping-patterns, -Werror=overlapping-patterns]
> Pattern match is redundant
> In an equation for ‘unpackRLimit’:
> unpackRLimit other | ((18446744073709551615) :: CRLim)
> /= (18446744073709551615)
> && other == (18446744073709551615) = ...
> |
> 107 | | ((#const RLIM_SAVED_CUR) :: CRLim) /= (#const RLIM_INFINITY) &&
> | ^^^...
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to exploit ./hadrian/ghci to find errors quickly?

[Sam Derbyshire]

The Binary runGet issue usually means that your build tree is out of date.
It's probably worth deleting and building from scratch again.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: meaning of title of merge request on gitlab?

[Sam Derbyshire]

As far as I understand, WIP and Draft are equivalent.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab

[Sam Derbyshire]

Yes, when visiting gitlab.haskell.org, but it seems to be OK again now.

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab

[Sam Derbyshire]

I'm also getting error 500 now.

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab

[Sam Derbyshire]

It's working for me at the moment.

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

[RFC] TcPlugin changes in GHC 9.4: what would you like to see?

[Sam Derbyshire]

Hi all,

As you may recall, the API for type-checking plugins is changing (ever so
slightly) in GHC 9.4. It was pointed out to me that this might be a good
opportunity to make further changes to accommodate other needs of
type-checking plugin authors.

For the moment, I have one concrete change in mind: changing the
TcPluginSolveResult datatype to be a flat record, where one can separately
return solved constraints, new constraints and insoluble constraints. This
allows plugin authors to return contradictions at the same time as they
return solved constraints, which (I have been told) can significantly
improve the quality of the error messages.
Pattern synonyms can be provided for compatibility, so the impact to plugin
authors should be very minimal.

I would love to hear other suggestions for improvements. Note however that
I believe it is best if we keep the GHC API quite sparse, leaving more
elaborate design choices to libraries.

Thanks,

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 9.2.1-rc1 now available

[Sam Derbyshire]

> Have array and reference types and primos been updated to be
> BoxedRep-polymorphic, or is it still just expensive scaffolding?
>

Not at the moment. A few primops have been updated for GHC 9.4 (e.g.
pointer equality, keepAlive) , but nothing pertaining to arrays yet (MR
!5218 ).

Cheers,

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Rewriting plugins: request for feedback

[Sam Derbyshire]

Hi everyone,

I've uploaded the new type-checking plugin API to Hackage:
https://hackage.haskell.org/package/ghc-tcplugin-api.

Let me know how you get on. It should be much easier to iterate on the
design and add new functionality, now that the API isn't tied to GHC.

Thanks,

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Rewriting plugins: request for feedback

[Sam Derbyshire]

>
> FYI the Inria paper link in the readme seems to not be correct?
>

The HAL-Inria server seems to be down at the moment.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Rewriting plugins: request for feedback

[Sam Derbyshire]

Hi all,

I have now written a much more substantial type-checking plugin, which I
used to typecheck an intrinsically typed implementation of System F. I've
added the example to the repository (
https://github.com/sheaf/ghc-tcplugin-api), see the readme.

This uncovered several bugs in the implementation of the aforementioned
compatibility layer for GHC 9.0 and 9.2, which have all been fixed. I can
now in good conscience recommend that type-checking plugin authors try it
out for themselves!
There are slight inconsistencies in behaviour around emitting additional
constraints when rewriting a type-family application (which I hope to iron
out soon), but I expect the impact of this to be very minimal. Other than
that, you can expect feature and behaviour parity with the native
implementation.

Please let me know how you get on, and which pain points you would like to
see addressed. My current ideas for improvement are as follows:

  - Functionality that would perform all the name resolution necessary in
the plugin initialisation. The user would provide a record of the types to
look up (a TyCon named ... in module ..., a Class named ... in module ...),
and the library would look up everything. This would be quite
straightforward with a library such as barbies, but I don't necessarily
want to impose that cognitive overhead on users who are not familiar with
it.
  - An interface for handling type family rewritings that provides a type
system that kind checks everything. For instance, instead of manually
calling splitTyConAppMaybe, we could feasibly instead use a pattern with
existential variables (matching on this pattern would introduce the kinds),
and then use a smart constructor instead of mkTyConApp (which would
kind-check the application). I certainly would have appreciated something
like this when writing my System F plugin, as handling all the kinds
explicitly was rather tiresome and error prone.
  - Functionality for recognising that a type has a certain form, making
use of Givens. For example, it can be quite annoying to find out whether a
given type is a type family application, as one needs to look through the
Givens to go through levels of indirection. For instance, one might come
across a variable "x" (ostensibly not a type family application), but have
Givens [G] y ~ x, [G] F a ~ y. (This happens often with flattening skolems.)

Please let me know if you have any other ideas, or suggestions on how to
tackle the above. Thanks.

Best,

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Rewriting plugins: request for feedback

[Sam Derbyshire]

Hello everyone,

I'm happy to report that I have implemented a compatibility layer in the
ghc-tcplugin-api library which provides type-family rewriting functionality
on GHC 9.0 and 9.2.
This means that plugin authors should now be able to use the exact same API
from GHC 9.0 onwards (and in particular, without waiting for a version of
GHC containing the new implementation of type-family rewriting plugins).

To refresh your memory, writing a type-checking plugin with this library
currently consists of the provision of a record

data TcPlugin = forall s. TcPlugin
  { tcPluginInit:: TcPluginM Init s
  , tcPluginSolve   :: s -> TcPluginSolver
  , tcPluginRewrite :: s -> UniqFM TyCon TcPluginRewriter
  , tcPluginStop:: s -> TcPluginM Stop ()
  }

with the following type synonyms:

type TcPluginSolver
  =  [GHC.Ct] -- ^ Givens
  -> [GHC.Ct] -- ^ Wanteds
  -> TcPluginM Solve TcPluginSolveResult

Note that Deriveds are no longer passed explicitly. (It is possible to
retrieve the Derived constraints from the TcPluginM Solve monad; as they
are not commonly used, it made sense to make them less conspicuous.)

type TcPluginRewriter
  =  [GHC.Ct] -- ^ Givens
  -> [GHC.Type]   -- ^ Type family arguments (saturated)
  -> TcPluginM Rewrite TcPluginRewriteResult


On GHC 9.0 and 9.2, the tcPluginRewrite function will get hooked in as a
pre-pass of the user-supplied tcPluginSolve function.
There are small differences in behaviour that arise from solver plugins not
always getting a chance to run when GHC can solve the wanteds on its own,
but I expect this to have minimal impact.
On top of this, I expect (but have not measured) a performance degradation
compared to the "native" plugin type-family rewriting functionality, as the
solver plugin must traverse all constraints to find type-family
applications.

I have not tested this compatibility layer extensively, so I welcome all
feedback from plugin authors.

Note that I have also reduced the amount of re-exported datatype
constructors and accessors in an attempt to improve cross compatibility.
Please let me know of any difficulties that you encounter as a consequence,
and I will endeavour to re-export cross-compatible non-internal definitions.

Thanks,

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Rewriting plugins: request for feedback

[Sam Derbyshire]

Hi everyone,

Just a short message to let authors of type-checking plugins know that I've
updated the ghc-tcplugin-api library with backwards compatibility for GHC
9.0 and 9.2.
The functionality for rewriting type family applications will obviously not
be present on those versions, but I hope this will allow plugin authors to
try out the API for themselves and see what they think.

It shouldn't be much different from what you are used to; mostly a change
from "TcPluginM a" to MTL-style "MonadTcPlugin m => m a", or explicit
solver monad  "TcPluginM Solve a".
The main improvements that this library offers in its current state are, in
my opinion, as follows:
  - Decoupling from GHC, which has several upsides:
- needs of plugin authors can be addressed rapidly without needing to
wait for new GHC releases (of course, this doesn't apply to the changes
which require commensurate changes to GHC),
- cross-compatibility across GHC versions, hopefully lightening the CPP
burden on plugin authors.
  - More extensive documentation that should help people get started with
typechecking plugins. The haddocks remain available at the same page:
https://sheaf.github.io/ghc-tcplugin-api/GHC-TcPlugin-API.html

The library is available on the GitHub repository as before:
https://github.com/sheaf/ghc-tcplugin-api
I will upload the library to Hackage soon.

Thanks all,

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Error message degradation for (<= :: Nat -> Nat -> Constraint) in GHC 9.2+

[Sam Derbyshire]

Hi Christiaan,

As far as I'm concerned that's a worrying regression, and I think you
should file a ticket on the GHC tracker about it.
I believe GHC already contains logic to avoid expanding type synonyms in
error messages in certain situations, but it apparently doesn't apply here.
Hopefully someone more knowledgeable about this can chime in.

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Rewriting plugins: request for feedback

[Sam Derbyshire]

Hey everyone,

I've put up some haddocks for this new type-checking plugin API, see here:
https://sheaf.github.io/ghc-tcplugin-api/GHC-TcPlugin-API.html.
(The page is mainly meant to be navigated using the contents pane.)

I hope this might be a more welcoming point of entry for people who are
interested in learning about GHC typechecker plugins.

Let me know what you think,

Thanks,

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Rewriting plugins: request for feedback

[Sam Derbyshire]

Hi again everyone,


I've been making some more adjustments to the API of type-checking plugins.
Following a suggestion by Richard, the mechanism for reporting errors while
rewriting type family applications now consists of emitting a wanted
constraint with a custom type error message. There are several technical
reasons for this, which I will not get into.
This means there are now only two constructors of TcPluginRewriteResult:
TcPluginNoRewrite and TcPluginRewriteTo. Both of these now take an extra
argument: additional wanted constraints, which will be processed and
emitted by GHC.


Coming back to the type-checking plugin API as a whole (not just the
rewriting of type family applications), I've come to the realisation that
it is probably best to keep GHC's interface as simple as possible, to allow
library authors to write their own APIs.
After all, most of the API doesn't need to live within the GHC codebase,
and instead (in my opinion) belongs in libraries that simply import the ghc
package (which thankfully doesn't hide any exports one might want to use).
This means we don't have to tie any experimentation with type-checking
plugin APIs to the GHC release schedule.

To that end, I have concluded that one single non-backwards-compatible
change seems important: changing the TcPluginM monad from being isomorphic
to "ReaderT EvBindsVar TcM" to simply being a newtype around TcM. Then, we
instead pass an EvBindsVar as an extra argument to tcPluginSolve.
This avoids all the silly business with functions whose documentation said
"only call this within tcPluginSolve or it will cause a crash" (a situation
which was only made worse by the addition of rewriting plugins). It's also
less opinionated: library authors can use a ReaderT wrapper in their API if
they desire, but are not forced to do so.
Please note that I don't make this change lightly, as I know it is already
time-consuming enough to maintain type-checking plugins, especially as much
more significant changes abound (removal of flattening variables in GHC
9.2, removal of derived constraints (possibly in GHC 9.4)). I hope
nevertheless that you might find this acceptable.


Finally, facilitated by the above, I have started implementing a library
providing a simple API for type-checking plugins; see here
https://github.com/sheaf/ghc-tcplugin-api.
An example of a not-totally-trivial rewriting plugin is given here:
https://github.com/sheaf/ghc-tcplugin-api/blob/ad6ca964c3b27c28bb27392d7ba406cfac82176d/examples/RewriterPlugin/plugin/RewriterPlugin.hs
.
Note that I barely had to import anything from the ghc package; I hope this
can remain true for more involved plugins (up to a point).
Please let me know what you think, in particular if you think certain
important functions are missing from the API.

For this library specifically, I have added back ReaderT layers (but only
in the appropriate situations, to avoid reintroducing the aforementioned
problem with "only call this in tcPluginSolve"), and provided MTL-style
typeclasses for operations that work with multiple different phases of the
plugin.
Other design options are of course possible; at any rate, I think it is
preferable to be making these API choices outside of GHC itself whenever
possible.
I've also included helpers for creating custom type errors within
type-checking plugins, as that was unnecessarily cumbersome. (One still
needs to provide a CtLoc to inform GHC of the source location of the error;
one can get this from a constraint fed to the plugin in a solver plugin, or
from the rewriting environment in a rewriter plugin).


Note that this all still depends on the WIP GHC MR 5909, available at
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5909.


I look forward to your feedback,

Thanks,

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Rewriting plugins: request for feedback

[Sam Derbyshire]

Hi everyone,

Recent refactors to the constraint solver have complicated the story for
authors of type-checking plugins. Following a suggestion by Christiaan
Baaij, and aided by Richard Eisenberg, I'm working on adding the ability
for type-checking plugins to rewrite type family applications directly
(hooking straight into GHC's type-family rewriting code). The goal is to
ease migration for the plugin authors, hopefully simplifying the common
operation of rewriting type family applications.


Let me now describe the current API for this new functionality, for which I
would like feedback.

--

A new field is added to the TcPlugin data type, namely

tcPluginRewrite :: s -> UniqFM TyCon TcPluginRewriter

Here s is the existential plugin state that users can choose as they wish
for their own plugin.
Plugins thus register which type family TyCons they are interested in
rewriting, like so:

myTcPluginRewrite :: MyPluginState -> UniqFM TyCon TcPluginRewriter
myTcPluginRewrite s@(MyPluginState {myFam1TyCon, myFam2TyCon}) =
  listToUFM [ (myFam1TyCon, myFam1Rewriter s), (myFam2TyCon, myFam2Rewriter
s) ]

For each type family TyCon, the plugin should provide a rewriting function
(corresponding to myFam1Rewriter and myFam2Rewriter above), of type

type TcPluginRewriter = [Ct] -> [TcType] -> TcPluginM TcPluginRewriteResult

This means that a rewriting function is supplied with the current Given
constraints and the arguments of the (guaranteed to be saturated)
type-family application, and should return a result of type:

data TcPluginRewriteResult where
  TcPluginRewriteError
:: (Diagnostic a, Typeable a) => a -> TcPluginRewriteResult
  TcPluginNoRewrite
:: TcPluginRewriteResult
  TcPluginRewriteTo
:: { rewriteTo :: TcType
   , rewriteEvidence :: TcCoercion }
-> TcPluginRewriteResult

That is, the plugin can specify what the type-family application should be
rewritten to, throw an error, or do nothing.

--

I'm hoping that the components of existing type-checking plugins concerned
with type-family applications can instead use this mechanism and achieve
more robust results by doing so, with less effort.

I would like to hear from plugin authors whether this API suits their
needs. If you know of someone not on this list that might be interested,
please invite them to join the conversation.

The current state of this patch can be found in the GHC MR 5909:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5909

Thanks,

Sam
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs