Re: Deriving mechanisms in GHC

[Simon Peyton Jones]

> I am also curious if there is a recommended way to check the GHC API
changes across different versions.

The difficulty is that we don't *have* a published, well designed GHC API
for clients to use, and for GHC devs to strive to maintain stable.  You
aren't the only one to find this problem see these tickets
.
You might want to turn this thread into a new ticket, so you get included
in that list.

There is a project to design the API, but it is stalled
https://discourse.haskell.org/t/charting-a-course-toward-a-stable-api-for-ghc/7646

It would be fantastic if someone, or a small group, was willing to take the
lead here.

Simon


On Wed, 3 Jul 2024 at 20:02, Yao Li  wrote:

> Ah that looks like the reason. Thank you for catching that! Thanks for the
> pointers to the specific commit in GHC as well as the example!
>
> I am also curious if there is a recommended way to check the GHC API
> changes across different versions. We use GHC APIs extensively in hs-to-coq
> and there seem to be a number of changes between 8.4 and 8.10, so it's
> possible that we will run into other similar issues at some point, or when
> we update hs-to-coq to newer GHC versions in the future... Or are there any
> community recommendations on the best way to maintain our code base, which
> relies on GHC APIs?
>
> Thanks,
> Yao
>
> On Wed, Jul 3, 2024 at 7:46 AM Ryan Scott  wrote:
>
>> (Disclaimer: I have never used hs-to-coq before, so everything below is
>> merely an educated guess.)
>>
>> Looking at the source code for hs-to-coq, I see this [1]:
>>
>> addDerivedInstances :: GhcMonad m => TypecheckedModule -> m
>>> TypecheckedModule
>>> addDerivedInstances tcm = do
>>> let Just (hsgroup, a, b, c) = tm_renamed_source tcm
>>>
>>> (_gbl_env, inst_infos, _rn_binds) <- initTcHack tcm $ do
>>> let tcg_env = fst (tm_internals_ tcm)
>>> tcg_env_hack = tcg_env { tcg_mod = fakeDerivingMod,
>>> tcg_semantic_mod = fakeDerivingMod }
>>> -- Set the module to make it look like we are in GHCi
>>> -- so that GHC will allow us to re-typecheck existing
>>> instances
>>> setGblEnv tcg_env_hack $
>>> #if __GLASGOW_HASKELL__ >= 810
>>> tcInstDeclsDeriv [] (hs_derivds hsgroup)
>>> #else
>>> tcInstDeclsDeriv [] (hs_tyclds hsgroup >>= group_tyclds)
>>> (hs_derivds hsgroup)
>>> #endif
>>
>>
>> If I understand this code correctly, it is using the GHC API to produce
>> deriving-generated code and typecheck it, which seems reasonable. The
>> part that confuses me is the #if __GLASGOW_HASKELL__ >= 810 bit. Prior
>> to GHC 8.10, this code would obtain deriving-related information from
>> two places:
>>
>>1. The deriving clauses of data type declarations (i.e., the hs_tyclds
>>)
>>2. Standalone deriving declarations (i.e., the hs_derivds)
>>
>> In GHC 8.10 and later, however, the code only obtains deriving-related
>> information from standalone deriving declarations. This means that you'll
>> completely skip over any derived instances that arise from deriving
>> clauses, which is likely the source of the trouble you're encountering.
>>
>> In order to give advice on what you *should* be doing, let me briefly
>> describe why the type of tcInstDeclsDeriv changed in GHC 8.10. The
>> commit that changed tcInstDeclsDeriv is [2]. Prior to that commit,
>> tcInstDeclsDeriv would obtain information related to deriving clauses
>> via its first two arguments:
>>
>>1. The first argument (of type [DerivInfo]) contained all of the
>>deriving clauses for data family instances. (Note that hs-to-coq uses an
>>empty list, so this means that hs-to-coq will always skip over data
>>family instances, before or after GHC 8.10. I'm not sure if this should be
>>considered as a separate bug.)
>>2. The second argument (of type [LTyClDecl GhcRn]) contained all of
>>the data type definitions, which might have deriving clauses attached to
>>them.
>>
>> The linked commit changes things so that *all* deriving clause–related
>> information (both for ordinary data types as well as data family instances)
>> is passed as a [DerivInfo] list. This means that hs-to-coq needs to
>> produce those DerivInfo values somehow. As inspiration, you might want
>> to look at how GHC calls tcInstDeclsDeriv here [3]. GHC first calls the
>> tcTyAndClassDecls function to produce the DerivInfo values, and then it
>> passes the DerivInfo values to tcInstDeclsDeriv. I would hope that
>> something similar would work for hs-to-coq.
>>
>> Best,
>>
>> Ryan
>> -
>> [1]
>> https://github.com/plclub/hs-to-coq/blob/03e823972fc7c5f85a300e554c691563f89a3e5f/src/lib/HsToCoq/Util/GHC/Deriving.hs#L50-L64
>> [2]
>> https://gitlab.haskell.org/ghc/ghc/-/commit/679427f878e50ba5a9981bac4c2f9c76f4de3c3c#4c1af4850cb90ab2963edb06b69b57e87ccdf9c1
>> [3]
>> 

CountDeps

[Simon Peyton Jones]

Does anyone know what the CountDeps test does?

I'm getting the failure below in my branch. Should I just accept it?

I think it's because GHC.Core.FamInstEnv now depends on
GHC.Builtin.Types.Literals, a very reasonable dependency

Thanks

Simon

+++ "/builds/ghc/ghc/tmp/ghctest-su6yq239/test
spaces/testsuite/tests/count-deps/CountDepsAst.run/CountDepsAst.run.stdout.normalised"
2024-07-01 18:37:33.372548372 +
@@ -2,6 +2,7 @@
GHC.Builtin.Names
GHC.Builtin.PrimOps
GHC.Builtin.Types
+GHC.Builtin.Types.Literals
GHC.Builtin.Types.Prim
GHC.Builtin.Uniques
GHC.ByteCode.Types
--- "/builds/ghc/ghc/tmp/ghctest-su6yq239/test
spaces/testsuite/tests/count-deps/CountDepsParser.run/CountDepsParser.stdout.normalised"
2024-07-01 18:37:33.393548751 +
+++ "/builds/ghc/ghc/tmp/ghctest-su6yq239/test
spaces/testsuite/tests/count-deps/CountDepsParser.run/CountDepsParser.run.stdout.normalised"
2024-07-01 18:37:33.393548751 +
@@ -2,6 +2,7 @@
GHC.Builtin.Names
GHC.Builtin.PrimOps
GHC.Builtin.Types
+GHC.Builtin.Types.Literals
GHC.Builtin.Types.Prim
GHC.Builtin.Uniques
GHC.ByteCode.Types
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Annotating instances

[Simon Peyton Jones]

Ah, so returning to my original question:

Where is this described/documented?   All I can see here
> <https://github.com/ndmitchell/hlint#readme>is...
>

E.g. is there a HLint user guide?  I'm interested in what the annotations
can and cannot be.  E.g. perhaps ANN could shortcircuit the TH stuff in
some common cases?

Simon



On Mon, 4 Dec 2023 at 12:15, Moritz Angermann 
wrote:

> I see. That’s where the confusion comes from. Hlint uses them to allow
> ignoring specific Hlint warnings:
>
> {-# ANN module "HLint: ignore Use string literal" #-}
>
> {- HLINT ignore "Use string literal" -}
>
> and similar. One could maybe argue they should have never been ANN pragmas
> to begin with.
>
> Examples taken from this SO question:
>
> https://stackoverflow.com/questions/19237695/haskell-how-to-tell-hlint-not-to-warning-use-string-literal
>
> On Mon, 4 Dec 2023 at 8:07 PM, Simon Peyton Jones <
> simon.peytonjo...@gmail.com> wrote:
>
>> > I don’t think they do anything specific.
>>
>> Now I am truly baffled!  If they don't do anything, why would they be a
>> module at all!  Surely they do something?
>>
>> Simon
>>
>> On Mon, 4 Dec 2023 at 11:58, Moritz Angermann 
>> wrote:
>>
>>> I don’t think they do anything specific. They just function as a marker
>>> to Hlint to find when parsing the source files. Here is one of the original
>>> issues we had:
>>> https://github.com/ndmitchell/hlint/issues/1251
>>>
>>> Simply by not being ANN, it doesn’t trigger the Templar Haskell
>>> machinery and thus does not cause compilation slowdowns or iserv needs
>>> (e.g. render the module impossible to cross compiler for stage1 cross
>>> compilers with not TH support).
>>>
>>> On Mon, 4 Dec 2023 at 7:45 PM, Simon Peyton Jones <
>>> simon.peytonjo...@gmail.com> wrote:
>>>
>>>> Luckily Hlint also support HLINT instead which removed the TH pipeline.
>>>>>
>>>>
>>>> Where is this described/documented?   All I can see here
>>>> <https://github.com/ndmitchell/hlint#readme>is
>>>>
>>>>> For {-# HLINT #-} pragmas GHC may give a warning about an
>>>>> unrecognised pragma, which can be suppressed with
>>>>> -Wno-unrecognised-pragmas.
>>>>>
>>>> which mentions HLINT pragmas but says nothing about what they do.
>>>>
>>>> Simon
>>>>
>>>> On Mon, 4 Dec 2023 at 09:05, Moritz Angermann <
>>>> moritz.angerm...@gmail.com> wrote:
>>>>
>>>>> Any ANN annotation triggers the TH pipeline and makes them really
>>>>> painful to work with, in non-stage2 settings. Lots of Hlint annotations 
>>>>> use
>>>>> ANN and then you have iserv be triggered for each module that has an ANN
>>>>> annotation.
>>>>>
>>>>> Luckily Hlint also support HLINT instead which removed the TH pipeline.
>>>>>
>>>>> That alone is enough for me personally to recommend against using ANN
>>>>> if there is an alternator option to anyone who asks me.
>>>>>
>>>>> On Mon, 4 Dec 2023 at 5:01 PM, Simon Peyton Jones <
>>>>> simon.peytonjo...@gmail.com> wrote:
>>>>>
>>>>>> The whole ANN mechanism
>>>>>> <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/extending_ghc.html?highlight=ann#source-annotations>is,
>>>>>> at root, a good idea. It is pretty generan, and allows annotations to be
>>>>>> arbitrary expressions, provided they are in Typable and Data.  And they 
>>>>>> are
>>>>>> serialised across modules.
>>>>>>
>>>>>> In practice though, I'm not sure how widely used they are. I'm not
>>>>>> sure why. I'd love to hear of counter-examples.
>>>>>>
>>>>>> Only top level binders can be annotated; but there is no reason in
>>>>>> principle that you should not annotate instance declarations.  I don't
>>>>>> think it'd be too hard to implement.
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>> On Sat, 2 Dec 2023 at 14:51, Jaro Reinders 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi GHC devs,
>>>>>>>
>>>>>>> I'm working on a GHC plugin which implements a custom instance
>>>>>>> resolution
>

Re: Annotating instances

[Simon Peyton Jones]

> I don’t think they do anything specific.

Now I am truly baffled!  If they don't do anything, why would they be a
module at all!  Surely they do something?

Simon

On Mon, 4 Dec 2023 at 11:58, Moritz Angermann 
wrote:

> I don’t think they do anything specific. They just function as a marker to
> Hlint to find when parsing the source files. Here is one of the original
> issues we had:
> https://github.com/ndmitchell/hlint/issues/1251
>
> Simply by not being ANN, it doesn’t trigger the Templar Haskell machinery
> and thus does not cause compilation slowdowns or iserv needs (e.g. render
> the module impossible to cross compiler for stage1 cross compilers with not
> TH support).
>
> On Mon, 4 Dec 2023 at 7:45 PM, Simon Peyton Jones <
> simon.peytonjo...@gmail.com> wrote:
>
>> Luckily Hlint also support HLINT instead which removed the TH pipeline.
>>>
>>
>> Where is this described/documented?   All I can see here
>> <https://github.com/ndmitchell/hlint#readme>is
>>
>>> For {-# HLINT #-} pragmas GHC may give a warning about an unrecognised
>>> pragma, which can be suppressed with -Wno-unrecognised-pragmas.
>>>
>> which mentions HLINT pragmas but says nothing about what they do.
>>
>> Simon
>>
>> On Mon, 4 Dec 2023 at 09:05, Moritz Angermann 
>> wrote:
>>
>>> Any ANN annotation triggers the TH pipeline and makes them really
>>> painful to work with, in non-stage2 settings. Lots of Hlint annotations use
>>> ANN and then you have iserv be triggered for each module that has an ANN
>>> annotation.
>>>
>>> Luckily Hlint also support HLINT instead which removed the TH pipeline.
>>>
>>> That alone is enough for me personally to recommend against using ANN if
>>> there is an alternator option to anyone who asks me.
>>>
>>> On Mon, 4 Dec 2023 at 5:01 PM, Simon Peyton Jones <
>>> simon.peytonjo...@gmail.com> wrote:
>>>
>>>> The whole ANN mechanism
>>>> <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/extending_ghc.html?highlight=ann#source-annotations>is,
>>>> at root, a good idea. It is pretty generan, and allows annotations to be
>>>> arbitrary expressions, provided they are in Typable and Data.  And they are
>>>> serialised across modules.
>>>>
>>>> In practice though, I'm not sure how widely used they are. I'm not sure
>>>> why. I'd love to hear of counter-examples.
>>>>
>>>> Only top level binders can be annotated; but there is no reason in
>>>> principle that you should not annotate instance declarations.  I don't
>>>> think it'd be too hard to implement.
>>>>
>>>> Simon
>>>>
>>>> On Sat, 2 Dec 2023 at 14:51, Jaro Reinders 
>>>> wrote:
>>>>
>>>>> 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
>>>>> ___
>>>>> 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: Annotating instances

[Simon Peyton Jones]

>
> Luckily Hlint also support HLINT instead which removed the TH pipeline.
>

Where is this described/documented?   All I can see here
<https://github.com/ndmitchell/hlint#readme>is

> For {-# HLINT #-} pragmas GHC may give a warning about an unrecognised
> pragma, which can be suppressed with -Wno-unrecognised-pragmas.
>
which mentions HLINT pragmas but says nothing about what they do.

Simon

On Mon, 4 Dec 2023 at 09:05, Moritz Angermann 
wrote:

> Any ANN annotation triggers the TH pipeline and makes them really painful
> to work with, in non-stage2 settings. Lots of Hlint annotations use ANN and
> then you have iserv be triggered for each module that has an ANN annotation.
>
> Luckily Hlint also support HLINT instead which removed the TH pipeline.
>
> That alone is enough for me personally to recommend against using ANN if
> there is an alternator option to anyone who asks me.
>
> On Mon, 4 Dec 2023 at 5:01 PM, Simon Peyton Jones <
> simon.peytonjo...@gmail.com> wrote:
>
>> The whole ANN mechanism
>> <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/extending_ghc.html?highlight=ann#source-annotations>is,
>> at root, a good idea. It is pretty generan, and allows annotations to be
>> arbitrary expressions, provided they are in Typable and Data.  And they are
>> serialised across modules.
>>
>> In practice though, I'm not sure how widely used they are. I'm not sure
>> why. I'd love to hear of counter-examples.
>>
>> Only top level binders can be annotated; but there is no reason in
>> principle that you should not annotate instance declarations.  I don't
>> think it'd be too hard to implement.
>>
>> Simon
>>
>> On Sat, 2 Dec 2023 at 14:51, Jaro Reinders 
>> wrote:
>>
>>> 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
>>> ___
>>> 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: Annotating instances

[Simon Peyton Jones]

The whole ANN mechanism
is,
at root, a good idea. It is pretty generan, and allows annotations to be
arbitrary expressions, provided they are in Typable and Data.  And they are
serialised across modules.

In practice though, I'm not sure how widely used they are. I'm not sure
why. I'd love to hear of counter-examples.

Only top level binders can be annotated; but there is no reason in
principle that you should not annotate instance declarations.  I don't
think it'd be too hard to implement.

Simon

On Sat, 2 Dec 2023 at 14:51, Jaro Reinders  wrote:

> 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
> ___
> 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: Nofib

[Simon Peyton Jones]

Thank you.  I could try that but I'm totally submerged at the moment.

Is it possible that someone might feel up to actioning this?  It's
unrelated to my work -- it's just a bug in HEAD.

Simon

On Fri, 10 Nov 2023 at 13:02, Hécate via ghc-devs 
wrote:

> Hi Simon,
>
> To modify nofib, simply submit a merge request to
> https://gitlab.haskell.org/ghc/nofib with the appropriate change.
> Once it's integrated, run `git submodule update --remote` in the GHC repo
> to update the submodule and push the update as part of your work.
>
> Cheers,
> Hécate
> Le 10/11/2023 à 13:34, Simon Peyton Jones a écrit :
>
> Dear devs
>
> Building 'nofib' with HEAD fails with
>
> real/scs/Parse.hs:40:19: error: [GHC-87543]
> Ambiguous occurrence ‘List’.
> It could refer to
>either ‘Data.List.List’,
>   imported from ‘Data.List’ at real/scs/Parse.hs:4:1-16
>   (and originally defined in ‘GHC.Types’),
>or ‘Types.List’,
>   imported from ‘Types’ at real/scs/Parse.hs:8:1-12.
>|
> 40 | list:: Parser List
>|   
>
> This is because of a change in the export list of Data.List.  The fix is
> easy (hide the import of List).
>
> But I don't know how to update nofib and the subdmodule magic to make HEAD
> pick the new version.
>
> Could anyone possible execute on this?  Thanks
>
> Simon
>
> ___
> ghc-devs mailing 
> listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> --
> Hécate ✨
> : @TechnoEmpress
> IRC: Hecate
> WWW: https://glitchbra.in
> RUN: BSD
>
> ___
> 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

Nofib

[Simon Peyton Jones]

Dear devs

Building 'nofib' with HEAD fails with

real/scs/Parse.hs:40:19: error: [GHC-87543]
Ambiguous occurrence ‘List’.
It could refer to
   either ‘Data.List.List’,
  imported from ‘Data.List’ at real/scs/Parse.hs:4:1-16
  (and originally defined in ‘GHC.Types’),
   or ‘Types.List’,
  imported from ‘Types’ at real/scs/Parse.hs:8:1-12.
   |
40 | list:: Parser List
   |   

This is because of a change in the export list of Data.List.  The fix is
easy (hide the import of List).

But I don't know how to update nofib and the subdmodule magic to make HEAD
pick the new version.

Could anyone possible execute on this?  Thanks

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

Re: Type-level sized Word literals???

[Simon Peyton Jones]

I'm pretty cautious about attempting to replicate type classes (or a weaker
version thereof) at the kind level.  An alternative would be to us
*non-overloaded* literals.

Simon

On Mon, 30 Oct 2023 at 08:20, Vladislav Zavialov via ghc-devs <
ghc-devs@haskell.org> wrote:

> > I am working on some code where it is useful to have types indexed by a
> 16-bit unsigned value.
>
> This is great to hear. I've always wanted to make it possible to
> promote all numeric types: Natural, Word8, Word16, Word32, Word64,
> Integer, Int8, Int16, Int32, Int64. (Then, as the next step, even the
> floating-point types Float and Double). I see it as a step towards
> universal promotion, i.e. being able to use any data type as a kind.
>
> The problem is that such a change would require a GHC proposal, and I
> don't have a strong motivating use case to write one. But you seem to
> have one! If you'd like to co-author a GHC proposal and if the
> proposal gets accepted, I can implement the feature.
>
> Here's how I imagine it could work.
>
> 1. Currently, a type-level literal like `15` is inferred to have kind
> `Nat` (and `Nat` is a synonym for `Natural` nowadays). At the
> term-level, however, the type of `15` is `forall {a}. Num a => a`. I'd
> like to follow the term-level precedent as closely as possible, except
> we don't have type class constraints in kinds, so it's going to be
> simply `15 :: forall {k}. k`.
>
> 2. The desugaring should also follow the term-level precedent. `15`
> actually stands for `fromInteger (15 :: Integer)`, and I expect no
> less at the type level, where we could introduce a type family
> `FromInteger :: Integer -> k`, with the following instances
>
>type instance FromInteger @Natural n = NaturalFromInteger n
>type instance FromInteger @Word8 n = Word8FromInteger n
>type instance FromInteger @Word16 n = Word16FromInteger n
>...
>
>The helper type families `NaturalFromInteger`, `Word8FromInteger`,
> `Word16FromInteger` etc. are partial, e.g. `NaturalFromInteger (10 ::
> Integer)` yields `10 :: Natural` whereas `NaturalFromInteger (-10)` is
> stuck.
>
> I have a fairly good idea of what it'd take to implement this (i.e.
> the changes to the GHC parser, type checker, and libraries), and the
> change has been on my mind for a while. The use case that you have
> might be the last piece of the puzzle to get this thing rolling.
>
> Can you tell more about the code you're writing? Would it be possible
> to use it as the basis for the "Motivation" section of a GHC proposal?
>
> Vlad
>
> On Mon, Oct 30, 2023 at 6:06 AM Viktor Dukhovni 
> wrote:
> >
> > I am working on some code where it is useful to have types indexed by a
> > 16-bit unsigned value.
> >
> > Presently, I am using type-level naturals and having to now and then
> > provide witnesses that a 'Nat' value I am working with is at most 65535.
> >
> > Also, perhaps there's some inefficiency here, as Naturals have two
> > constructors, and so a more complex representation with (AFAIK) no
> > unboxed forms.
> >
> > I was wondering what it would take to have type-level fixed-size
> > Words (Word8, Word16, Word32, Word64) to go along with the Nats?
> >
> > It looks like some of the machinery (KnownWord16, SomeWord16, wordVal16,
> > etc.) can be copied straight out of GHC.TypeNats with minor changes, and
> > that much works, but the three major things that are't easily done seem
> > to be:
> >
> > - There are it seems no TypeReps for types of Kind Word16, so one
> can't
> >   have (Typeable (Foo w)) with (w :: Word16).
> >
> > - There are no literals of a promoted Word16 Kind.
> >
> > type Foo :: Word16 -> Type
> > data Foo w = MkFoo Int
> >
> > -- 1 has Kind 'Natural' (a.k.a. Nat)
> > x = MkFoo 13 :: Foo 1 -- Rejected,
> >
> > -- The new ExtendedLiterals syntax does not help
> > --
> > x = MkFoo 13 :: Foo (W16# 1#Word16) -- Syntax error!
> >
> > - There are unsurprisingly also no built-in 'KnownWord16' instances
> >   for any hypothetical type-level literals of Kind Word16.
> >
> > Likely the use case for type-level fixed-size words is too specialised
> > to rush to shoehorn into GHC, but is there something on the not too
> > distant horizon that would make it easier and reasonable to have
> > fixed-size unsigned integral type literals available?
> >
> > [ I don't see a use-case for unsigned versions, they can trivially be
> >   represented by the unsigned value of the same width. ]
> >
> > With some inconvenience, in many cases I can perhaps synthesise Proxies
> > for types of Kind Word16, and just never use literals directly.
> >
> > --
> > Viktor.
> > ___
> > 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
> 

Re: "Merge-buddy" request

[Simon Peyton Jones]

I hope someone responds to Alan's call.   Simplifying exact-print
annotations is a noble goal, and Alan has been working hard on it.

I hope someone feels able to support him.  I don't think you need to be an
exact-print expert. I'm sure Alan would be happy to teach you.  And that
learning journey might be very useful in itself, because it'll tell you
want extra documentation (especially overview notes) is needed.

Big thanks to Alan

Simon

On Thu, 26 Oct 2023 at 18:11, Alan & Kim Zimmerman 
wrote:

> Hi all
>
> I have been landing a series of MRs to simplify the exact print
> annotations.
> They are split into pieces so each change is not too big.
> I still have quite a number of them to land, but am finding the process
> slow, as I
>
> - make the MR
> - wait for CI to go green
> - wait for a review, or ping people on chat to do the review
> - once approved, land it.
>
> I don't want to loudly shout for reviewers each time, and become a general
> irritant.
>
> Is there anyone (ideally with an interest in the exact print annotations)
> that would like to be my "merge buddy" that I can easily ask to do the
> reviews?
>
> I am happy for each one to take a couple of days, so it is not a high
> pressure thing, I just want to get into a cadence on them.
>
> My current one is
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11496.  Admittedly
> only one reviewer requested, and he is always busy, and I do not want to
> make him even more so.
>
> Alan
>
> ___
> 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: Reinstallable - base

[Simon Peyton Jones]

>
> A very large proportion of libraries, and virtually all end-user
> applications, transitively depend on Template Haskell. Whether they use
> Template Haskell directly or not. So if we're saying “base is
> reinstallable, except when you have Template Haskell somewhere”, we're
> effectively saying “base is not reinstallable”. Now, it could be a good
> stepping-stone, from an engineering standpoint, but I don't think we could
> deliver this and be satisfied that we've accomplished anything.
>

No one has yet answered my naive question (from 3 days ago) asking why
Template Haskell stops base being reinstallable.  I'll quote it here for
completeness.

Let's say that
>

   - An old library mylib (which uses TH) depends on base-4.7.
   - A new GHC, say GHC 9.10, depends on a newer version of base-4.9, which
   in turn depends on ghc-internal-9.10.
   - At the same time, though, we release base-4.7.1, which depends on
   ghc-internal-9.10, and exposes the base-4.7 API.

At this point we use ghc-9.10 to compile L, against base-4.7.1.   (Note
that the ghc-9.10 binary includes a compiled form of `base-4.9`.)


   - That produces compiled object files, such as, mylib:M.o.
   - To run TH we need to link them with the running binary
   - So we need to link the compiled `base-4.7.1` as well.  No problem: it
   contains very little code; it is mostly a shim for ghc-internal-9.10

So the only thing we need is the ability to have a single linked binary
that includes (the compiled form for) two different versions/instantiations
of `base`.   I think that's already supported: each has a distinct
"installed package id".

(End of quote)

What am I missing?

Simon

On Fri, 20 Oct 2023 at 08:57, Arnaud Spiwack 
wrote:

> A very large proportion of libraries, and virtually all end-user
> applications, transitively depend on Template Haskell. Whether they use
> Template Haskell directly or not. So if we're saying “base is
> reinstallable, except when you have Template Haskell somewhere”, we're
> effectively saying “base is not reinstallable”. Now, it could be a good
> stepping-stone, from an engineering standpoint, but I don't think we could
> deliver this and be satisfied that we've accomplished anything.
>
> On Thu, 19 Oct 2023 at 13:47, Oleg Grenrus  wrote:
>
>> For what it worth, `template-haskell` itself depends on a `base`. So if
>> `base` if different base is used, different `template-haskell` is to be
>> used.
>>
>> In my opinion is not *too unfair* to require that if you actually splice
>> in (i.e. the code not only provides template-haskell combinators to
>> create/modify splices) then you must have base and template-haskell
>> versions aligned with host GHC used versions.
>>
>> The same restriction is GHC plugins, isn't it, except `template-haskell`
>> is replaced with `ghc`?
>>
>> - Oleg
>>
>> On 17.10.2023 18.54, Adam Gundry wrote:
>> > Hi Simon,
>> >
>> > Thanks for starting this discussion, it would be good to see progress
>> > in this direction. As it happens I was discussing this question with
>> > Ben and Matt over dinner last night, and unfortunately they explained
>> > to me that it is more difficult than I naively hoped, even once
>> > wired-in and known-key things are moved to ghc-internal.
>> >
>> > The difficulty is that, as a normal Haskell library, ghc itself will
>> > be compiled against a particular version of base. Then when Template
>> > Haskell is used (with the internal interpreter), code will be
>> > dynamically loaded into a process that already has symbols for ghc's
>> > version of base, which means it is not safe for the code to depend on
>> > a different version of base. This is rather like the situation with TH
>> > and cross-compilers.
>> >
>> > Adam
>> >
>> >
>> >
>> > On 17/10/2023 11:08, Simon Peyton Jones wrote:
>> >> Dear GHC devs
>> >>
>> >> Given the now-agreed split between ghc-internal and base
>> >> <https://github.com/haskellfoundation/tech-proposals/pull/51>, what
>> >> stands in the way of a "reinstallable base"?
>> >>
>> >> Specifically, suppose that
>> >>
>> >>   * GHC 9.8 comes out with base-4.9
>> >>   * The CLC decides to make some change to `base`, so we get base-4.10
>> >>   * Then GHC 9.10 comes out with base-4.10
>> >>
>> >> I think we'd all like it if someone could use GHC 9.10 to compile a
>> >> library L that depends on base-4.9 and either L doesn't work at all
>> >> with base-4.10, or L's dependency bounds have not yet been

Re: Reinstallable - base

[Simon Peyton Jones]

(Meta-question: on reflection, would this discussion perhaps be better on a
ticket? But where?  GHC's repo?  Or HF's?)

The difficulty is that, as a normal Haskell library, ghc itself will be
> compiled against a particular verson of base. Then when Template Haskell is
> used (with the internal interpreter), code will be dynamically loaded into
> a process that already has symbols for ghc's version of base, which means
> it is not safe for the code to depend on a different version of base.


I'm not understanding the difficulty yet.

Let's say that

   - An old library mylib (which uses TH) depends on base-4.7.
   - A new GHC, say GHC 9.10, depends on a newer version of base-4.9, which
   in turn depends on ghc-internal-9.10.
   - At the same time, though, we release base-4.7.1, which depends on
   ghc-internal-9.10, and exposes the base-4.7 API.

At this point we use ghc-9.10 to compile L, against base-4.7.1.   (Note the
the ghc-9.10 binary includes a compiled form of `base-4.9`.

   - That produces compiled object files, such as, mylib:M.o.
   - To run TH we need to link them with the running binary
   - So we need to link the compiled `base-4.7.1` as well.  No problem: it
   contains very little code; it is mostly a shim for ghc-internal-9.10

So the only thing we need is the ability to have a single linked binary
that includes (the compiled form for) two different versions/instantiations
of `base`.   I think that's already supported: each has a distinct
"installed package id".

What am I missing?

Simon



On Tue, 17 Oct 2023 at 16:54, Adam Gundry  wrote:

> Hi Simon,
>
> Thanks for starting this discussion, it would be good to see progress in
> this direction. As it happens I was discussing this question with Ben
> and Matt over dinner last night, and unfortunately they explained to me
> that it is more difficult than I naively hoped, even once wired-in and
> known-key things are moved to ghc-internal.
>
> The difficulty is that, as a normal Haskell library, ghc itself will be
> compiled against a particular version of base. Then when Template
> Haskell is used (with the internal interpreter), code will be
> dynamically loaded into a process that already has symbols for ghc's
> version of base, which means it is not safe for the code to depend on a
> different version of base. This is rather like the situation with TH and
> cross-compilers.
>
> Adam
>
>
>
> On 17/10/2023 11:08, Simon Peyton Jones wrote:
> > Dear GHC devs
> >
> > Given the now-agreed split between ghc-internal and base
> > <https://github.com/haskellfoundation/tech-proposals/pull/51>, what
> > stands in the way of a "reinstallable base"?
> >
> > Specifically, suppose that
> >
> >   * GHC 9.8 comes out with base-4.9
> >   * The CLC decides to make some change to `base`, so we get base-4.10
> >   * Then GHC 9.10 comes out with base-4.10
> >
> > I think we'd all like it if someone could use GHC 9.10 to compile a
> > library L that depends on base-4.9 and either L doesn't work at all with
> > base-4.10, or L's dependency bounds have not yet been adjusted to allow
> > base-4.10.
> >
> > We'd like to have a version of `base`, say `base-4.9.1` that has the
> > exact same API as `base-4.9` but works with GHC 9.10.
> >
> > Today, GHC 9.10 comes with a specific version of base, /and you can't
> > change it/. The original reason for that was, I recall, that GHC knows
> > the precise place where (say) the type Int is declared, and it'll get
> > very confused if that data type definition moves around.
> >
> > But now we have `ghc-internal`, all these "things that GHC magically
> > knows" are in `ghc-internal`, not `base`.
> >
> > *Hence my question: what (now) stops us making `base` behave like any
> > other library*?  That would be a big step forward, because it would mean
> > that a newer GHC could compile old libraries against their old
> dependencies.
> >
> > (Some changes would still be difficult.  If, for example, we removed
> > Monad and replaced it with classes Mo1 and Mo2, it might be hard to
> > simulate the old `base` with a shim.  But getting 99% of the way there
> > would still be fantastic.)
> >
> > Simon
>
> --
> 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
>
> ___
> 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

Reinstallable - base

[Simon Peyton Jones]

Dear GHC devs

Given the now-agreed split between ghc-internal and base
, what stands
in the way of a "reinstallable base"?

Specifically, suppose that

   - GHC 9.8 comes out with base-4.9
   - The CLC decides to make some change to `base`, so we get base-4.10
   - Then GHC 9.10 comes out with base-4.10

I think we'd all like it if someone could use GHC 9.10 to compile a library
L that depends on base-4.9 and either L doesn't work at all with base-4.10,
or L's dependency bounds have not yet been adjusted to allow base-4.10.

We'd like to have a version of `base`, say `base-4.9.1` that has the exact
same API as `base-4.9` but works with GHC 9.10.

Today, GHC 9.10 comes with a specific version of base, *and you can't
change it*. The original reason for that was, I recall, that GHC knows the
precise place where (say) the type Int is declared, and it'll get very
confused if that data type definition moves around.

But now we have `ghc-internal`, all these "things that GHC magically knows"
are in `ghc-internal`, not `base`.

*Hence my question: what (now) stops us making `base` behave like any other
library*?  That would be a big step forward, because it would mean that a
newer GHC could compile old libraries against their old dependencies.

(Some changes would still be difficult.  If, for example, we removed Monad
and replaced it with classes Mo1 and Mo2, it might be hard to simulate the
old `base` with a shim.  But getting 99% of the way there would still be
fantastic.)

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

Library module naming

[Simon Peyton Jones]

Friends

I am keen to complete discussion on

HF tech proposal 53


which is about the naming convention for modules in base, ghc-experimental,
ghc-internal, etc.

I think it's done.  Any views?

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

Re: Configure errors

[Simon Peyton Jones]

But the other tests look like

checking for gnutar... no
checking for gtar... no
checking for tar... /usr/bin/tar
checking for gpatch... no
checking for patch... /usr/bin/patch
checking for autoreconf... /usr/bin/autoreconf

Can't you say

checking for -Qunused-arguments... no

You can explain this to me, now, and that helps me, today.  But I'm trying
to save you from having to explain it to many future GHC devs, and/or save
them time in hunting for answers to the same question.

No rush

Simon

On Mon, 7 Aug 2023 at 11:07, Rodrigo Mesquita 
wrote:

> The trace is akin to the configure trace — it shows invocations of the
> toolchain in trying to determine properties of said toolchain e.g. which
> flags are supported.
>
> For example
>
>   checking for -Qunused-arguments support...
>   Entering: checking for -Qunused-arguments support
> Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o
> /tmp/tmp0/test.o.c
> Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o
> /tmp/tmp0/test.o.c
> Exited with code 1
>
>   found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath =
> "/usr/bin/gcc", prgFlags = []}}
>
>
> Is the trace of invoking the C compiler with -Qunused-arguments, checking
> whether the C compiler supports such an option.
> That command exited with code 1 likely because the compiler doesn’t indeed
> support -Qunused-arguments.
> That’s fine, it means we won’t pass -Qunused-arguments to your C compiler.
>
> Rodrigo
>
> On 7 Aug 2023, at 10:50, Simon Peyton Jones 
> wrote:
>
> Rodrigo
>
> I'm getting lots of errors from ./configure, see below.
>
> Seems to be something to do with your toolchain stuff?  I'm lost.  Should
> I worry? If not, could they be made to look less alarming somehow?
>
> Simon
>
> Entering: checking for C compiler
>   checking for -Qunused-arguments support...
>   Entering: checking for -Qunused-arguments support
> Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o
> /tmp/tmp0/test.o.c
> Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o
> /tmp/tmp0/test.o.c
> Exited with code 1
>
>   found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath =
> "/usr/bin/gcc", prgFlags = []}}
>   checking whether Cc supports --target...
>   Entering: checking whether Cc supports --target
> Execute: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o
> /tmp/tmp0/test.o /tmp/tmp0/test.o.c
> Command failed: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c
> -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c
> Exited with code 1
>
>   found whether Cc supports --target: Cc {ccProgram = Program {prgPath =
> "/usr/bin/gcc", prgFlags = []}}
>   checking whether Cc works...
>   Entering: checking whether Cc works
> Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c
>   found whether Cc works: ()
>   checking for C99 support...
>   Entering: checking for C99 support
> Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c
>   found for C99 support: ()
>   checking whether cc supports extra via-c flags...
>   Entering: checking whether cc supports extra via-c flags
> Execute: /usr/bin/gcc -c -fwrapv -fno-builtin -Werror -x c -o
> /tmp/tmp0/test.o /tmp/tmp0/test.c
>   found whether cc supports extra via-c flags: ()
> found for C compiler: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc",
> prgFlags = []}}
> checking for C++ compiler...
> Entering: checking for C++ compiler
>   x86_64-unknown-linux-g++ not found in search path
>   x86_64-unknown-linux-clang++ not found in search path
>   x86_64-unknown-linux-c++ not found in search path
>   checking whether C++ supports --target...
>   Entering: checking whether C++ supports --target
> Execute: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o
> /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp
> Command failed: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c
> -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp
> Exited with code 1
>
>   found whether C++ supports --target: Cxx {cxxProgram = Program {prgPath
> = "/usr/bin/g++", prgFlags = []}}
>   Execute: /usr/bin/g++ -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp
> found for C++ compiler: Cxx {cxxProgram = Program {prgPath =
> "/usr/bin/g++", prgFlags = []}}
> checking for C preprocessor...
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Configure errors

[Simon Peyton Jones]

>
> At the end of the configure step there might be a message that starts with
> “Don’t worry! This will not affect your build in any way”. That’s as less
> alarming as I could make it :).
>

I do see that message, but apparently it refers only to the immediately
preceding warning, namely

> configure: WARNING:
> There are some differences between the toolchain configured by "configure"
> (hadrian/cfg/default.target) and the toolchain configured by the
> "ghc-toolchain" program (hadrian/cfg/default.target.ghc-toolchain).
>

It did nothing to reassure me about earlier errors in the configure stuff;
it seemed to be about something different.

Suggestion

   - Instead of "This will not affect..." say "This difference in toolchain
   output won't affect...", so the target of "This" is clearer.
   - Suppress these gcc errors.  You can switch them on in your build!

Simon



On Mon, 7 Aug 2023 at 10:57, Rodrigo Mesquita 
wrote:

> Thanks for pointing this out, Simon
>
> What you’ve pasted is the trace of the ghc-toolchain program.
> We should probably lower the verbosity after !10976 lands, but in the
> meantime it’s just useful to debug mostly CI.
>
> At the end of the configure step there might be a message that starts with
> “Don’t worry! This will not affect your build in any way”. That’s as less
> alarming as I could make it :).
>
> If you do see the warning, it’s due to a discrepancy between the output
> produced by configure and the one produced by ghc-toolchain:
> We’re fixing all the discrepancies caught by CI in !10976 — after which
> we’ll always validate these discrepancies in CI, to ensure ghc-toolchain is
> kept up to date with configure, while configure still configures toolchains.
>
> I’ve also been busy writing the blog about this. It should come out soon
> enough.
>
> Rodrigo
>
> On 7 Aug 2023, at 10:50, Simon Peyton Jones 
> wrote:
>
> Rodrigo
>
> I'm getting lots of errors from ./configure, see below.
>
> Seems to be something to do with your toolchain stuff?  I'm lost.  Should
> I worry? If not, could they be made to look less alarming somehow?
>
> Simon
>
> Entering: checking for C compiler
>   checking for -Qunused-arguments support...
>   Entering: checking for -Qunused-arguments support
> Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o
> /tmp/tmp0/test.o.c
> Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o
> /tmp/tmp0/test.o.c
> Exited with code 1
>
>   found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath =
> "/usr/bin/gcc", prgFlags = []}}
>   checking whether Cc supports --target...
>   Entering: checking whether Cc supports --target
> Execute: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o
> /tmp/tmp0/test.o /tmp/tmp0/test.o.c
> Command failed: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c
> -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c
> Exited with code 1
>
>   found whether Cc supports --target: Cc {ccProgram = Program {prgPath =
> "/usr/bin/gcc", prgFlags = []}}
>   checking whether Cc works...
>   Entering: checking whether Cc works
> Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c
>   found whether Cc works: ()
>   checking for C99 support...
>   Entering: checking for C99 support
> Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c
>   found for C99 support: ()
>   checking whether cc supports extra via-c flags...
>   Entering: checking whether cc supports extra via-c flags
> Execute: /usr/bin/gcc -c -fwrapv -fno-builtin -Werror -x c -o
> /tmp/tmp0/test.o /tmp/tmp0/test.c
>   found whether cc supports extra via-c flags: ()
> found for C compiler: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc",
> prgFlags = []}}
> checking for C++ compiler...
> Entering: checking for C++ compiler
>   x86_64-unknown-linux-g++ not found in search path
>   x86_64-unknown-linux-clang++ not found in search path
>   x86_64-unknown-linux-c++ not found in search path
>   checking whether C++ supports --target...
>   Entering: checking whether C++ supports --target
> Execute: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o
> /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp
> Command failed: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c
> -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp
> Exited with code 1
>
>   found whether C++ supports --target: Cxx {cxxProgram = Program {prgPath
> = "/usr/bin/g++", prgFlags = []}}
>   Execute: /usr/bin/g++ -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp
> found for C++ compiler: Cxx {cxxProgram = Program {prgPath =
> "/usr/bin/g++", prgFlags = []}}
> checking for C preprocessor...
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Configure errors

[Simon Peyton Jones]

Rodrigo

I'm getting lots of errors from ./configure, see below.

Seems to be something to do with your toolchain stuff?  I'm lost.  Should I
worry? If not, could they be made to look less alarming somehow?

Simon

Entering: checking for C compiler
  checking for -Qunused-arguments support...
  Entering: checking for -Qunused-arguments support
Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o
/tmp/tmp0/test.o.c
Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o
/tmp/tmp0/test.o.c
Exited with code 1

  found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath =
"/usr/bin/gcc", prgFlags = []}}
  checking whether Cc supports --target...
  Entering: checking whether Cc supports --target
Execute: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o
/tmp/tmp0/test.o /tmp/tmp0/test.o.c
Command failed: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c
-o /tmp/tmp0/test.o /tmp/tmp0/test.o.c
Exited with code 1

  found whether Cc supports --target: Cc {ccProgram = Program {prgPath =
"/usr/bin/gcc", prgFlags = []}}
  checking whether Cc works...
  Entering: checking whether Cc works
Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c
  found whether Cc works: ()
  checking for C99 support...
  Entering: checking for C99 support
Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c
  found for C99 support: ()
  checking whether cc supports extra via-c flags...
  Entering: checking whether cc supports extra via-c flags
Execute: /usr/bin/gcc -c -fwrapv -fno-builtin -Werror -x c -o
/tmp/tmp0/test.o /tmp/tmp0/test.c
  found whether cc supports extra via-c flags: ()
found for C compiler: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc",
prgFlags = []}}
checking for C++ compiler...
Entering: checking for C++ compiler
  x86_64-unknown-linux-g++ not found in search path
  x86_64-unknown-linux-clang++ not found in search path
  x86_64-unknown-linux-c++ not found in search path
  checking whether C++ supports --target...
  Entering: checking whether C++ supports --target
Execute: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o
/tmp/tmp0/test.o /tmp/tmp0/test.o.cpp
Command failed: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c
-o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp
Exited with code 1

  found whether C++ supports --target: Cxx {cxxProgram = Program {prgPath =
"/usr/bin/g++", prgFlags = []}}
  Execute: /usr/bin/g++ -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp
found for C++ compiler: Cxx {cxxProgram = Program {prgPath =
"/usr/bin/g++", prgFlags = []}}
checking for C preprocessor...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Getting all variables in scope in CoreM

[Simon Peyton Jones]

>
> My question is then “How can I get all variables in scope in the module
> underlying this CoreM computation, to pass in the LintConfig?”.
>

What do you have in your hand?  A [CoreBinding]?  If so, just do
`bindersOfBinds`.

You only need the LocalIds.  You don't need (imported) GlobalIds

Simon

On Sun, 6 Aug 2023 at 11:02, Rodrigo Mesquita 
wrote:

> Dear GHC devs,
>
> I’m trying to invoke the GHC.Core.Lint linting functions from a Core GHC
> plugin.
> These functions take a LintConfig that can mostly be constructed from
> DynFlags,
> the exception being
>
> * l_vars :: ![Var]* — ^ Ids that should be treated as being in scope
>
> My question is then “How can I get all variables in scope in the module
> underlying this CoreM computation, to pass in the LintConfig?”.
>
> My ultimate goal is to run LintM to determine the usage environment of a
> given core expression.
> In that sense, the “Id out of scope” errors aren’t that important to me,
> but they do make the linting action fail.
>
> Thanks in advance!
> Rodrigo
> ___
> 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: NamedDefaults and relaxed defaults?

[Simon Peyton Jones]

No: I don't know of anyone planning to implement this proposal -- indeed I
had forgotten about it -- so it's waiting for someone to take it on.

There are some slightly tricky loose ends around defaulting that it'd be
good to nail down first: https://gitlab.haskell.org/ghc/ghc/-/issues/20686

Simon

On Wed, 26 Jul 2023 at 11:00, Benjamin Redelings <
benjamin.redeli...@gmail.com> wrote:

> Hi,
>
> If I understand correctly, the traditional defaulting rules prevent
> defaulting variables with constraints like (Num a, Convertible a
> Double), but the NamedDefaults proposal would allow defaulting a ~
> Double in this case due to the relaxed defaulting rules in section 2.5
> of the proposal:
>
>
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst#id2
>
> 1. Is there any plan to start implementing NamedDefaults?  I saw the
> comment from Simon P-J that it would not be fun to implement because it
> might require orphan default declarations... so perhaps there's no plan
> to implement this?
>
> 2. Would it be worth adding a separate LANGUAGE option that just
> implements the relaxed defaulting rules in section 2.5? Specifically (a)
> allowing variables with multiparameter constraints and (b) allowing
> variables with constraints that are not in the Prelude.
>
> 3. Am I correct in assuming that the relaxed defaulting rules require
> NamedDefaults to be enabled in the importing module, and not just in the
> imported model?
>
> -BenRI
> ___
> 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: Why do the reverse binder swap transformation?

[Simon Peyton Jones]

Consider

f x = letrec go y = case x of z { (a,b) -> ...(expensive z)... }
in ...

If we do the reverse binder-swap we get

f x = letrec go y = case x of z { (a,b) -> ...(expensive x)... }
in ...

and now we can float out:

f x = let t = expensive x
in letrec go y = case x of z { (a,b) -> ...(t)... }
in ...

Now (expensive x) is computed once, rather than once each time around the
'go' loop..

Would you like to elaborate the Note to explain this better?

Simon


On Fri, 14 Jul 2023 at 16:30, Rodrigo Mesquita 
wrote:

> Dear GHC devs,
>
> I’m wondering about the reverse binder swap transformation, the one in
> which we substitute occurrences of the case binder by occurrences of the
> scrutinee (when the scrut. is a variable):
>
> case x of z { r -> e }
> ===>
> case x of z { r -> e[x/z] }
>
> My question is: why do we do this transformation? An example in which this
> transformation is beneficial would be great too.
>
> The Note I’ve found about it, Note [Binder-swap during float-out], wasn’t
> entirely clear to me:
>
> 4. Note [Binder-swap during float-out]
>~~~
>In the expression
> case x of wild { p -> ...wild... }
>we substitute x for wild in the RHS of the case alternatives:
> case x of wild { p -> ...x... }
>This means that a sub-expression involving x is not "trapped"
> inside the RHS.
>And it's not inconvenient because we already have a
> substitution.
>
>   Note that this is EXACTLY BACKWARDS from the what the simplifier
> does.
>   The simplifier tries to get rid of occurrences of x, in favour
> of wild,
>   in the hope that there will only be one remaining occurrence of
> x, namely
>   the scrutinee of the case, and we can inline it.
>
> Many thanks,
> Rodrigo
>
> ___
> 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: Exact-print info in the the HsSyn syntax tree

[Simon Peyton Jones]

Thanks Jakob -- but would it be possible to comment *on the ticket*, not
here?   (I should have said that more clearly.)

Simon

On Thu, 13 Jul 2023 at 13:31, Jakob Brünker 
wrote:

> Having written the MonadicBang plugin somewhat recently, where I don't
> care about the exact-print annotations, I do have some snippets in my code
> that look like this:
>
> AsPat xa name tok pat -> do
>   tellName name
>   AsPat xa name tok <$> traverse (liftMaybeT . evacPats) pat
>
> where the `tok` variable only exists to pass along the exact-print
> annotations unchanged. So in that context, I would have a slight preference
> for the exact-print annotations being hidden away in the extension points.
> However, I think this also illustrates that the cost to clients is quite
> manageable. Adding this one variable doesn't make the code unreadable - of
> course, that's assuming exact-print annotations remain special and not just
> the first in a long list of properties to eventually be added to each node.
>
> Of course, the cost *is* multiplied by the number of pattern matches on
> AST nodes you have, which could be a lot given the amount of constructors
> the types have. In my case, it was very few, because I was able to handle
> the vast majority of constructors generically via the Data.Data instance.
>
> Jakob
>
> On Thu, Jul 13, 2023 at 1:23 PM Simon Peyton Jones <
> simon.peytonjo...@gmail.com> wrote:
>
>> Dear GHC developers
>>
>> Could you please look at #23447 Where should "tokens" live
>> <https://gitlab.haskell.org/ghc/ghc/-/issues/23447>?
>>
>> In brief, the question is whether we want to have:
>>
>> data HsExpr p = 
>>| HsLet (XLet p) (HsLocalBinds p) (LHsExpr p)
>> or
>>
>> data HsExpr p = 
>>| HsLet (XLet p) (HsToken "let" p)
>>(HsLocalBinds p) (HsToken "in" p) (LHsExpr p)
>>
>>
>> In the former, if a client wants HsTokes to track the precise source
>> locations of the "let" and "in" keywords, they'd have to put it in the TTG
>> extension field; in the latter, this information is in *every* syntax
>> tree.
>>
>> At the moment we have some of each, which is not satisfactory. We need to
>> decide a policy and stick to it.  If you use HsSyn, HsExpr, HsPat etc, in
>> any way, you should have an opinion.  Please do express it. At the moment
>> we have only a few voices so we risk deciding without enough evidence and
>> use-cases.
>>
>> Comments with specific use-cases and examples would be particularly
>> helpful.
>>
>> 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

Exact-print info in the the HsSyn syntax tree

[Simon Peyton Jones]

Dear GHC developers

Could you please look at #23447 Where should "tokens" live
?

In brief, the question is whether we want to have:

data HsExpr p = 
   | HsLet (XLet p) (HsLocalBinds p) (LHsExpr p)
or

data HsExpr p = 
   | HsLet (XLet p) (HsToken "let" p)
   (HsLocalBinds p) (HsToken "in" p) (LHsExpr p)


In the former, if a client wants HsTokes to track the precise source
locations of the "let" and "in" keywords, they'd have to put it in the TTG
extension field; in the latter, this information is in *every* syntax tree.

At the moment we have some of each, which is not satisfactory. We need to
decide a policy and stick to it.  If you use HsSyn, HsExpr, HsPat etc, in
any way, you should have an opinion.  Please do express it. At the moment
we have only a few voices so we risk deciding without enough evidence and
use-cases.

Comments with specific use-cases and examples would be particularly helpful.

Thanks!

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

Re: Can't build nofib

[Simon Peyton Jones]

>
> I would recommend —allow-newer rather than rebuilding with 9.4. In
> retrospect, 9.4 implies base == 4.17, but nofib seems to only allow < 4.17,
> which would leave 9.4 out.


Oh wow -- so there is *no* version of GHC that works as a bootstrap GHC.
That seems bad.  Very bad.

I see a patch from Andreas -- maybe that fixes it?

Meanwhile, --allow-newer I guess.

Simon

On Wed, 12 Jul 2023 at 12:50, Rodrigo Mesquita 
wrote:

> I would recommend —allow-newer rather than rebuilding with 9.4. In
> retrospect, 9.4 implies base == 4.17, but nofib seems to only allow < 4.17,
> which would leave 9.4 out.
>
> Rodrigo
>
> On 12 Jul 2023, at 12:48, Simon Peyton Jones 
> wrote:
>
> Thanks.  That is very unfortunate: ./configure does not issue any
> complaint.
>
> I upgraded from 9.2 because GHC won't compile with 9.2 any more.  But now
> you are saying that nofib won't build with 9.6?  So that leaves 9.4 only.
>
> Well I can install 9.4 and rebuild everything.  But really, it would be
> good if configure complained if you are using a boot compiler that won't
> work.  That's what configure is for!
>
> Simon
>
> On Wed, 12 Jul 2023 at 12:41, Rodrigo Mesquita <
> rodrigo.m.mesqu...@gmail.com> wrote:
>
>> From the error message it looks like you’re using ghc-9.6(and base 4.18)
>> while nofib requires base < 4.17.
>> I’d say as a temporary workaround you can likely run your invocation
>> additionally with —allow-newer, and hope that doesn’t break. Otherwise you
>> could downgrade to 9.4 or bump the version manually in the cabal file of
>> nofib?
>>
>> Rodrigo
>>
>> On 12 Jul 2023, at 12:38, Simon Peyton Jones 
>> wrote:
>>
>> Friends
>>
>> With a clean HEAD I can't build nofib.  See below.  What should I do?
>>
>> Thanks
>>
>> Simon
>>
>> (cd nofib; cabal v2-run -- nofib-run
>> --compiler=`pwd`/../_build/stage1/bin/ghc --output=`date -I`)
>> Resolving dependencies...
>> Error: cabal: Could not resolve dependencies:
>> [__0] trying: nofib-0.1.0.0 (user goal)
>> [__1] next goal: base (dependency of nofib)
>> [__1] rejecting: base-4.18.0.0/installed-4.18.0.0 (conflict: nofib =>
>> base>=4.5 && <4.17)
>> [__1] skipping: base-4.18.0.0, base-4.17.1.0, base-4.17.0.0 (has the same
>> characteristics that caused the previous version to fail: excluded by
>> constraint '>=4.5 && <4.17' from 'nofib')
>> [__1] rejecting: base-4.16.4.0, base-4.16.3.0, base-4.16.2.0,
>> base-4.16.1.0,
>> base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0,
>> base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, base-4.11.1.0,
>> base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0,
>> base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1,
>> base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0,
>> base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2,
>> base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2,
>> base-3.0.3.1 (constraint from non-upgradeable package requires installed
>> instance)
>> [__1] fail (backjumping, conflict set: base, nofib)
>> After searching the rest of the dependency tree exhaustively, these were
>> the
>> goals I've had most trouble fulfilling: base, nofib
>>
>> make: *** [/home/simonpj/code/Makefile-spj:39: nofib] Error 1
>>
>> ___
>> 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: Can't build nofib

[Simon Peyton Jones]

Thanks.  That is very unfortunate: ./configure does not issue any complaint.

I upgraded from 9.2 because GHC won't compile with 9.2 any more.  But now
you are saying that nofib won't build with 9.6?  So that leaves 9.4 only.

Well I can install 9.4 and rebuild everything.  But really, it would be
good if configure complained if you are using a boot compiler that won't
work.  That's what configure is for!

Simon

On Wed, 12 Jul 2023 at 12:41, Rodrigo Mesquita 
wrote:

> From the error message it looks like you’re using ghc-9.6(and base 4.18)
> while nofib requires base < 4.17.
> I’d say as a temporary workaround you can likely run your invocation
> additionally with —allow-newer, and hope that doesn’t break. Otherwise you
> could downgrade to 9.4 or bump the version manually in the cabal file of
> nofib?
>
> Rodrigo
>
> On 12 Jul 2023, at 12:38, Simon Peyton Jones 
> wrote:
>
> Friends
>
> With a clean HEAD I can't build nofib.  See below.  What should I do?
>
> Thanks
>
> Simon
>
> (cd nofib; cabal v2-run -- nofib-run
> --compiler=`pwd`/../_build/stage1/bin/ghc --output=`date -I`)
> Resolving dependencies...
> Error: cabal: Could not resolve dependencies:
> [__0] trying: nofib-0.1.0.0 (user goal)
> [__1] next goal: base (dependency of nofib)
> [__1] rejecting: base-4.18.0.0/installed-4.18.0.0 (conflict: nofib =>
> base>=4.5 && <4.17)
> [__1] skipping: base-4.18.0.0, base-4.17.1.0, base-4.17.0.0 (has the same
> characteristics that caused the previous version to fail: excluded by
> constraint '>=4.5 && <4.17' from 'nofib')
> [__1] rejecting: base-4.16.4.0, base-4.16.3.0, base-4.16.2.0,
> base-4.16.1.0,
> base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0,
> base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, base-4.11.1.0,
> base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0,
> base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1,
> base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0,
> base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2,
> base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2,
> base-3.0.3.1 (constraint from non-upgradeable package requires installed
> instance)
> [__1] fail (backjumping, conflict set: base, nofib)
> After searching the rest of the dependency tree exhaustively, these were
> the
> goals I've had most trouble fulfilling: base, nofib
>
> make: *** [/home/simonpj/code/Makefile-spj:39: nofib] Error 1
>
> ___
> 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

Can't build nofib

[Simon Peyton Jones]

Friends

With a clean HEAD I can't build nofib.  See below.  What should I do?

Thanks

Simon

(cd nofib; cabal v2-run -- nofib-run
--compiler=`pwd`/../_build/stage1/bin/ghc --output=`date -I`)
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] trying: nofib-0.1.0.0 (user goal)
[__1] next goal: base (dependency of nofib)
[__1] rejecting: base-4.18.0.0/installed-4.18.0.0 (conflict: nofib =>
base>=4.5 && <4.17)
[__1] skipping: base-4.18.0.0, base-4.17.1.0, base-4.17.0.0 (has the same
characteristics that caused the previous version to fail: excluded by
constraint '>=4.5 && <4.17' from 'nofib')
[__1] rejecting: base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, base-4.16.1.0,
base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0,
base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, base-4.11.1.0,
base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0,
base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1,
base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0,
base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2,
base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2,
base-3.0.3.1 (constraint from non-upgradeable package requires installed
instance)
[__1] fail (backjumping, conflict set: base, nofib)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, nofib

make: *** [/home/simonpj/code/Makefile-spj:39: nofib] Error 1
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Usage of Template Haskell quotes in GHC source tree vs. usage of GHC as a library

[Simon Peyton Jones]

Gergo

I'm not close enough to this to have a well-formed opinion, but it looks
like a good question to me, esp if the new dependence on TH is optional.

Would you like to transfer the text into a GHC ticket?

Simon

On Wed, 12 Jul 2023 at 04:40, Gergő Érdi  wrote:

> Hi,
>
>
>
> A recent commit 983ce55815f2dd57f84ee86eee97febf7d80b470 starts using
> TemplateHaskellQuotes in the GHC codebase. It seems this is at odds with
> using GHC as a library, a la ghc-lib.
>
>
>
> The `ghc-lib` approach is to basically take the module hierarchy from the
> `compiler/` subtree, and compile it as a completely vanilla Haskell
> library, with no direct attachment to the host GHC version. This enables
> using e.g. GHC 9.4 to compile a program using the GHC 9.6 API, and so on.
> In particular, it also makes it very easy to apply patches to the version
> of GHC used as a library, since in this setup it doesn’t need to be able to
> bootstrap.
>
>
>
> So what is the problem with using TemplateHaskellQuotes? The problem is
> the dependency on the template-haskell package. When a module inside
> GHC-as-a-library containing TH quotes is compiled, the quotes are
> translated into applications of the constructors defined by the *host*
> GHC’s TH package. But because GHC is tightly coupled to the TH support
> library, GHC-as-a-library needs to ship with its own internal version of
> the library. So the code that tries to process the results of these quotes
> is using the *target* GHC’s TH definitions. And that leads to a conflict:
> code like
>
>
>
> leftName :: Namel
>
> leftName = ‘Left
>
>
> is now a type mismatch between the type of `’Left` being
> template-haskell-2.19.0.0:Language.Haskell.TH.Syntax.Name (example when
> using GHC 9.4.5 as the host) and the type of `leftName` being
> ghc-lib-9.9.20230712:Language.Haskell.TH.Syntax.Name (example when the
> target version is built from recent `master`).
>
>
>
> Currently, `ghc-lib-gen` has a pre-processing step on the GHC source tree
> that replaces these quotations with applications containing direct
> references to the target TH constructors:
> https://github.com/digital-asset/ghc-lib/blob/ab01fb2b4d1e3a9338390e9c10ccd769bbf37aeb/ghc-lib-gen/src/Ghclibgen.hs#L419-L467
> but I am worried that this is very fragile.
>
>
>
> So any ideas on how to tackle this situation better?
>
>
>
> Thanks,
>
> Gergo
> ___
> 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: I can't build HEAD

[Simon Peyton Jones]

>
> Upgrade your bootstrap compiler to >= 9.4. We have now bumped HEAD's
> version to 9.8, which means that 9.4 is the earliest possible bootstrap
> compiler (which `text` now takes advantage of, as you see here). I have
>

Aha.  I'll do that.

You have to admit, the error message is not helpful :-).  A suggestion for
the future: when bumping the minimum bootstrap compiler, it would be
possible (in the same commit) to fix configure to complain about too-early
versions?

Anyway I'm now building with 9.6, and doubtless that will be fine.  Thanks.

Simon



On Sun, 9 Jul 2023 at 18:49, Ben Gamari  wrote:

> Simon Peyton Jones  writes:
>
> > in a clean HEAD build, including "git submodule update", I get this.
> >
> > Can anyone help?
> >
> Upgrade your bootstrap compiler to >= 9.4. We have now bumped HEAD's
> version to 9.8, which means that 9.4 is the earliest possible bootstrap
> compiler (which `text` now takes advantage of, as you see here). I have
> a patch bumping the `configure` check stewing in my 9.8 preparation
> branch.
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

I can't build HEAD

[Simon Peyton Jones]

in a clean HEAD build, including "git submodule update", I get this.

Can anyone help?

Simon

| Run Ar Pack (Stage0 InTreeLibs):
_build/stage0/libraries/ghc-heap/build/cmm/cbits/HeapPrim.o (and 15 more)
=> _build/stage0/libraries/ghc-heap/build/libHSghc-heap-9.9-inplace.a
ar: creating
_build/stage0/libraries/ghc-heap/build/libHSghc-heap-9.9-inplace.a
/-\
| Successfully built library 'ghc-heap' (Stage0 InTreeLibs, way v).
  |
| Library:
_build/stage0/libraries/ghc-heap/build/libHSghc-heap-9.9-inplace.a |
| Library synopsis: Functions for walking GHC's heap.
  |
\-/
]0;Running for 2m35s [2621/2966], predicted 47s (77%) ]0;Running for 2m40s
[2621/2966], predicted 47s (77%) ]0;Running for 2m45s [2621/2966],
predicted 47s (77%) | Run Ghc CompileHs (Stage0 InTreeLibs):
libraries/containers/containers/src/Data/Sequence/Internal/Sorting.hs =>
_build/stage0/libraries/containers/containers/build/Data/Sequence/Internal/Sorting.o
| Run GhcPkg Unregister (Stage0 GlobalLibs): process => none
| Run GhcPkg Update (Stage0 InTreeLibs):
_build/stage0/libraries/exceptions/inplace-pkg-config => none
| Copy package 'exceptions'
# cabal-copy (for
_build/stage0/lib/package.conf.d/exceptions-0.10.7-inplace.conf)
# cabal-configure (for _build/stage0/libraries/text/setup-config)
| Run GhcPkg Recache (Stage0 InTreeLibs): none => none
hadrian: Encountered missing or private dependencies:
data-array-byte >=0.1 && <0.2

]0;Finished in 2m47s ExitFailure 1
Build failed.
make: *** [/home/simonpj/code/Makefile-spj:10: all] Error 1
simonpj@CDW-8FABODHF0V5:~/code/HEAD$
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Distinct closure types vs. known infotables for stack frames

[Simon Peyton Jones]

> The decisions here seem fairly arbitrary. But perhaps there is some
method to the madness, or perhaps someone prefers one approach over the
others, in which case I would like to hear it! And if not, well, at least
I’ll know. :)

I suspect it's all just happenstance.   Maybe @Ben Gamari
 knows.

One you've had all responses, perhaps document your conclusions in a Note
somewhere, and point to it copiously.



On Tue, 27 Jun 2023 at 22:53, Alexis King  wrote:

> On Tue, Jun 27, 2023 at 4:13 AM Simon Peyton Jones <
> simon.peytonjo...@gmail.com> wrote:
>
>> In short, why are the design considerations for stack frames different to
>> heap objects?  I think of a stack frame simply as a heap object that
>> happens to be allocated on the stack
>>
>
> I agree with this perspective—I think it is generally an accurate one.
> Indeed, I think it may very well be true that what I’ve described largely
> applies to heap objects as well as stack frames, and working on
> continuations just means I’ve much more time thinking about stacks. Perhaps
> if I were working on the garbage collector I would be asking the same
> question about heap objects.
>
> For example, we have MVAR_CLEAN and MVAR_DIRTY, but each of those types is
> only used by one statically-allocated infotable, as far as I can tell. In
> some parts of the code, we check that the closure type is MVAR_CLEAN or
> MVAR_DIRTY, but in other places, we check whether the infotable is
> stg_MVAR_CLEAN_info or stg_MVAR_DIRTY_info. Meanwhile, we have both
> stg_TVAR_CLEAN_info and stg_TVAR_DIRTY_info, but they share the same TVAR
> closure type!
>
> The decisions here seem fairly arbitrary. But perhaps there is some method
> to the madness, or perhaps someone prefers one approach over the others, in
> which case I would like to hear it! And if not, well, at least I’ll know. :)
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: SSH on Gitlab

[Simon Peyton Jones]

Thanks for following up.

I came home from hospital, and it was fine at home.  Maybe there was
something strange in their Wifi.   If I was there for longer I'd have had
to investigate more (somehow) but it was a thankfully brief stay.

Simon

On Tue, 27 Jun 2023 at 07:29, Bryan Richter 
wrote:

> Hi Simon,
>
> Did this, in fact, work itself out?
>
> On Thu, 22 Jun 2023 at 18:43, Ben Gamari  wrote:
>
>> Simon Peyton Jones  writes:
>>
>> > Is SSH working on gitlab.haskell.org?  I'm getting this
>> >
>> > simonpj@CDW-8FABODHF0V5:~$ ssh -v g...@gitlab.haskell.org
>> > OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f  31 Mar 2020
>> > debug1: Reading configuration data /home/simonpj/.ssh/config
>> > debug1: Reading configuration data /etc/ssh/ssh_config
>> > debug1: /etc/ssh/ssh_config line 19: include
>> /etc/ssh/ssh_config.d/*.conf
>> > matched no files
>> > debug1: /etc/ssh/ssh_config line 21: Applying options for *
>> > debug1: Connecting to gitlab.haskell.org [145.40.64.137] port 22.
>> > debug1: Connection established.
>> > debug1: identity file /home/simonpj/.ssh/id_rsa type 0
>> > debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1
>> > debug1: identity file /home/simonpj/.ssh/id_dsa type 1
>> > debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk-cert type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ed25519 type 3
>> > debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ed25519_sk type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ed25519_sk-cert type -1
>> > debug1: identity file /home/simonpj/.ssh/id_xmss type -1
>> > debug1: identity file /home/simonpj/.ssh/id_xmss-cert type -1
>> > debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4
>> >
>> > At this point it hangs.  Stackoverflow suggests
>> > <
>> https://superuser.com/questions/1374076/what-does-it-mean-if-ssh-hangs-after-connection-established
>> >a
>> > server fault.  But I'm on a new WLAN so I suppose there could be some
>> > bizarre filtering?
>> >
>> I suspect this may be a filtering issue. Like Tom, I am able to connect
>> without issue. A Wireshark trace [1] may help shed light on the
>> situation. Happy to have a call to debug if this would be helpful.
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://www.wireshark.org/
>> ___
>> 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: Improving Merge Request review processes

[Simon Peyton Jones]

>
> The majority of contributors don't have the rights to modify labels on
> merge requests. It might be good to add a few words of advice for that
> group: What should *they* do if their MR needs attention?
>

Oh!  That is bad.  It's no good us saying "add label X" if they can't add a
label.  Can we give everyone rights to modify labels?

Also: I have noticed that many MRs (hilariously including !10709) start
with "Thank you for your contribution to GHC".  That always irritates me:
it suggests that the author has not really bothered to write a proper MR
description.   The template isn't really a template: it's more *guidance *about
how to submit a MR, which we also supply at
https://gitlab.haskell.org/ghc/ghc/-/wikis/Contributing-a-Patch.(And if
the template is widely used, as it seems to be though I don't know how
people find it initially, it should point to that wiki page.)

I'm not quite sure how to resolve this.  Maybe make the template be truly a
template, and point to the wiki page for all content?

Simon

On Tue, 27 Jun 2023 at 06:53, Bryan Richter 
wrote:

> The majority of contributors don't have the rights to modify labels on
> merge requests. It might be good to add a few words of advice for that
> group: What should *they* do if their MR needs attention?
>
> Thanks for this effort! The vast, vast majority of GHC contributors are
> the ones who haven't even heard of it yet, or aren't even born yet. High
> quality information on how things work and how to get started will be the
> key to growing the ranks of GHC experts over time.
>
> On Fri, 23 Jun 2023 at 18:40, Matthew Pickering <
> matthewtpicker...@gmail.com> wrote:
>
>> I have modified the MR template -
>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10709
>>
>> and updated the wiki page that simon points out.
>>
>> Matt
>>
>> On Fri, Jun 23, 2023 at 11:25 AM Simon Peyton Jones
>>  wrote:
>> >
>> > Terrific.
>> >
>> > We just need to add some guidance for contributors about when and how
>> to use the new tag.
>> >
>> > Where should that guidance live?  We have the Contributing to GHC wiki
>> page.  It in turn (not very prominently) points to Contributing a patch.
>> Are these our primary pages?  If so, perhaps the latter is the one to edit?
>> >
>> > Simon
>> >
>> >
>> >
>> > On Fri, 23 Jun 2023 at 11:14, Matthew Pickering <
>> matthewtpicker...@gmail.com> wrote:
>> >>
>> >> We discussed this in the meeting on Tuesday.
>> >>
>> >> The conclusion was that
>> >>
>> >> * We now have a new label "Blocked on Review", which people can add to
>> >> merge requests if they are blocked waiting for a review.
>> >> * The "Reviewer Group" is taken to be the same as the "GHC Team" (see
>> >> https://gitlab.haskell.org/ghc/ghc-hq/-/tree/main), hence people
>> >> trusted to be part of the GHC team are expected to perform review as
>> >> well.
>> >> * We will take up some of the time on the Tuesday meeting by talking
>> >> about merge requests which are blocked and assigning them to people
>> >> for review.
>> >>
>> >> Cheers,
>> >>
>> >> Matt
>> >>
>> >> On Mon, Jun 19, 2023 at 10:03 PM Matthew Pickering
>> >>  wrote:
>> >> >
>> >> > Hi all,
>> >> >
>> >> > Recently there has been some discussion about better systems and
>> >> > processes for keeping the flow of merge requests going smoothly
>> >> > through the review process. It has become clear that we need to be a
>> >> > bit more deliberate in handling merge requests in order to make sure
>> >> > we can correctly triage, review and merge the many fantastic
>> >> > contributions we get to GHC on a daily basis.
>> >> >
>> >> > Therefore we are proposing to introduce a "GHC Reviewer Group" whose
>> >> > members will share collective responsibility for ensuring that MRs
>> >> > make their way smoothly from creation to merge.
>> >> >
>> >> > The description of the role and responsibility for this group can be
>> >> > read and commented on here:
>> >> >
>> >> >
>> https://docs.google.com/document/d/1FK9mryjC82DM6e5yxP7BOgu94As2bXccb55L8OrjPf4/edit?usp=sharing
>> >> >
>> >> > The motivation for this proposal is two-fold.
>> >> >
>> >> > * Ensuring that MRs are reviewed and triaged in a timely manner.
>> >> > * Documenting where the responsibility for MR reviewing
>> >> >
>> >> > We welcome any discussion about this document and other ideas about
>> >> > how to improve the systems in this regard.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Matt
>> >> ___
>> >> 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: Distinct closure types vs. known infotables for stack frames

[Simon Peyton Jones]

Thanks for a clear writeup, Alexis.

My instinct is to do it all with closure types, not pointer comparison.
-
>
> Con: Adding more closure types unnecessarily pollutes code that branches
> on closure types, like the garbage collector.
>
-
>
> Con: Adding more closure types unnecessarily pollutes code that branches
> on closure types, like the garbage collector.
>
- I don't get this.  Different stack frames might have different layouts
(e.g a catch frame has a fixed size with with exactly two (or whatever)
pointers, etc).   This isn't pollution.  Just as every heap closure has a
closure type that describes its layout, so does every stack frame.

Perhaps you mean that in fact all stack frames share a single layout, with
a bitmap to describe it?  That seems sub-optimal for these special frames
where we statically know the entire shape!

Perhaps you mean that many stack frames share a common layout, so that the
case analysis on closure type might have many cases all pointing to the
same GC code.  But if so, isn't that true for heap closures too? If we are
concerned about that, we could have two "type" fields in the info table,
one exclusively concerned with layout, so that the GC could just branch on
that and only have a few cases to consider, and one with a finer
granularity.

In short, why are the design considerations for stack frames different to
heap objects?  I think of a stack frame simply as a heap object that
happens to be allocated on the stack

Simon


On Mon, 26 Jun 2023 at 21:21, Alexis King  wrote:

> Hello all,
>
> I am tinkering with the RTS again while trying to fix #23513
> , and every time I
> touch the exceptions/continuations code, I find myself waffling about
> whether to introduce more closure types. I’d like to get a second opinion
> so I can stop changing my mind!
>
> Currently, we have distinct closure types for certain special stack
> frames, like CATCH_FRAME, ATOMICALLY_FRAME, and UNDERFLOW_FRAME. However,
> there are other special stack frames that *don’t* get their own closure
> types: there is no MASK_ASYNC_EXCEPTIONS_FRAME or PROMPT_FRAME. Instead,
> when code needs to recognize these frames on the stack, it just looks for a
> known infotable pointer. That is, instead of writing
>
> if (frame->header.info->i.type == PROMPT_FRAME) { ... }
>
> we write
>
> if (*frame == _prompt_frame_info) { ... }
>
> which works out because there’s only one info table that’s used for all
> prompt frames.
>
> There are a handful of stack frames that are recognized in this way by
> some part of the RTS, but the criteria used to determine which frames get
> their own types and which don’t is not particularly clear. For some frames,
> like UPDATE_FRAME, the closure type is necessary because it is shared
> between several infotables. But other types, like CATCH_FRAME and
> UNDERFLOW_FRAME, are only ever used by precisely one infotable.
>
> I think one can make the following arguments for/against using separate
> closure types for these stack frames:
>
>-
>
>Pro: It’s helpful to have separate types for particularly special
>frames like UNDERFLOW_FRAME because it makes it easier to remember
>which special cases to handle when walking the stack.
>-
>
>Pro: Branching on stack frame closure types using switch is easier to
>read than comparing infotable pointers.
>-
>
>Con: Adding more closure types unnecessarily pollutes code that
>branches on closure types, like the garbage collector.
>-
>
>Con: Using special closure types for these frames might make it seem
>like they have some special layout when in fact they are just ordinary
>stack frames.
>
> Does anyone have any opinions about this? I’m personally okay with the
> status quo, but the inconsistency makes me constantly second-guess whether
> someone else might feel strongly that I ought to be doing things the other
> way!
>
> Thanks,
> Alexis
> ___
> 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: Improving Merge Request review processes

[Simon Peyton Jones]

Terrific.

We just need to add some guidance for contributors about when and how to
use the new tag.

Where should that guidance live?  We have the Contributing to GHC wiki page
.  It in turn (not
very prominently) points to Contributing a patch
.  Are
these our primary pages?  If so, perhaps the latter is the one to edit?

Simon



On Fri, 23 Jun 2023 at 11:14, Matthew Pickering 
wrote:

> We discussed this in the meeting on Tuesday.
>
> The conclusion was that
>
> * We now have a new label "Blocked on Review", which people can add to
> merge requests if they are blocked waiting for a review.
> * The "Reviewer Group" is taken to be the same as the "GHC Team" (see
> https://gitlab.haskell.org/ghc/ghc-hq/-/tree/main), hence people
> trusted to be part of the GHC team are expected to perform review as
> well.
> * We will take up some of the time on the Tuesday meeting by talking
> about merge requests which are blocked and assigning them to people
> for review.
>
> Cheers,
>
> Matt
>
> On Mon, Jun 19, 2023 at 10:03 PM Matthew Pickering
>  wrote:
> >
> > Hi all,
> >
> > Recently there has been some discussion about better systems and
> > processes for keeping the flow of merge requests going smoothly
> > through the review process. It has become clear that we need to be a
> > bit more deliberate in handling merge requests in order to make sure
> > we can correctly triage, review and merge the many fantastic
> > contributions we get to GHC on a daily basis.
> >
> > Therefore we are proposing to introduce a "GHC Reviewer Group" whose
> > members will share collective responsibility for ensuring that MRs
> > make their way smoothly from creation to merge.
> >
> > The description of the role and responsibility for this group can be
> > read and commented on here:
> >
> >
> https://docs.google.com/document/d/1FK9mryjC82DM6e5yxP7BOgu94As2bXccb55L8OrjPf4/edit?usp=sharing
> >
> > The motivation for this proposal is two-fold.
> >
> > * Ensuring that MRs are reviewed and triaged in a timely manner.
> > * Documenting where the responsibility for MR reviewing
> >
> > We welcome any discussion about this document and other ideas about
> > how to improve the systems in this regard.
> >
> > Cheers,
> >
> > Matt
> ___
> 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

SSH on Gitlab

[Simon Peyton Jones]

Is SSH working on gitlab.haskell.org?  I'm getting this

simonpj@CDW-8FABODHF0V5:~$ ssh -v g...@gitlab.haskell.org
OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /home/simonpj/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf
matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to gitlab.haskell.org [145.40.64.137] port 22.
debug1: Connection established.
debug1: identity file /home/simonpj/.ssh/id_rsa type 0
debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1
debug1: identity file /home/simonpj/.ssh/id_dsa type 1
debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1
debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1
debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/simonpj/.ssh/id_ed25519 type 3
debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1
debug1: identity file /home/simonpj/.ssh/id_ed25519_sk type -1
debug1: identity file /home/simonpj/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/simonpj/.ssh/id_xmss type -1
debug1: identity file /home/simonpj/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4

At this point it hangs.  Stackoverflow suggests
a
server fault.  But I'm on a new WLAN so I suppose there could be some
bizarre filtering?

Thanks

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

Re: help migrating a tool that uses the ghc api

[Simon Peyton Jones]

I'm sorry you've been having such a torrid time, Sam.

We (the GHC developers) are acutely aware of the difficulties surrounding
the GHC API.  It was discussed quite a bit at the Haskell Implementers
Meeting at last year's ICFP.

The difficulty is that there simply *is *no defined GHC API.  GHC defines
many thousands of functions spread across over 700 modules.  Of course, we
change them all the time!  And GHC API users simply reach out and use the
most convenient function for them -- but of course we don't know which
functions they are using, and so we may change them without warning.  And
they may be entirely inappropriate "seeing too much of the internals"
functions anyway.

What we need is

   - An API for GHC that is *designed *and *actively curated*.
   - Which clients use with confidence
   - And GHC devs respect and try to change as little as possible
   - If a client needs a function that is not in the API, they can bid for
   it to be added (we'd need a process and, yes, a committee); or they can
   just reach around and grab one from GHC, but thereby expose themselves to
   un-managed changes in that function.

Even if we had all that, I'd expect the API to shift quite rapidly.  For
example, the new error-message infrastructure was developed specifically in
response to client needs (esp HLS) but those changes necessarily affect all
clients, yourself included.  At least, with a defined API and process, you
might get more warning and migration advice.

But to achieve that we need a group of people with the expertise and
commitment to create and curate that API.  It is possible that the Haskell
Foundation will help with this, but meanwhile I'm just sharing the need
again in case anyone says "oh I'd love to help with that".  This is how
open source works: we work together towards common goals.  But it does need
volunteers, and everyone is busy.

Everyone: if you'd like to contribute to a GHC API design and curation
process, please do say.   Even if you don't feel able to lead it, saying
"I'd be happy to help" is a big thing.

I know this isn't helping Sam much in the short term -- apologies for that.

Simon

On Fri, 19 May 2023 at 03:15, Vaibhav Sagar  wrote:

> Hi Sam,
>
> I have some experience with GHCI API version migrations from maintaining
> IHaskell (https://github.com/IHaskell/IHaskell/). During my
> maintainership I've upgraded to every release of GHC from 8.2 to 9.6 (9
> unless I'm counting incorrectly). In my experience, doing an incremental
> version upgrade takes me a relaxed weekend or less each time (for a project
> of IHaskell's size), but I can see it being incredibly frustrating if you
> put your code down for enough time that you have to jump multiple versions.
> I have a workflow that I'm pretty happy with, which I outline in
> https://vaibhavsagar.com/blog/2021/05/02/updating-ihaskell-newer-ghc/
> (mostly so I don't forget how I did things 6 months later).
>
> I'm personally happy with the pace of GHC development and refactors and I
> see the breaking changes as the necessary cost of improving the codebase
> and fixing (sometimes long-standing) issues.
>
> I think you are asking a lot of the compiler developers here. I don't
> think that merely consuming an API brings with it an expectation that the
> API developers should proactively fix your code when they make breaking
> changes (unless that is clearly outlined at the beginning, which I don't
> think it ever has been for GHC), and I think this would introduce a lot of
> friction into the development process which I personally would not want. I
> think a "community build" would be a great idea, but only for a small
> handful of projects that have outsized importance to the Haskell ecosystem
> (e.g. Pandoc, ShellCheck, HLS etc.) which excludes my project (and IMHO
> yours).
>
> I'm sure there are people who are qualified to help you keep your project
> up-to-date without impacting GHC development or including your project in
> the codebase.
>
> Thanks,
> Vaibhav
>
> On Fri, May 19, 2023 at 7:04 AM Sam Halliday 
> wrote:
>
>> Hi all,
>>
>> A few years ago I wrote a tool (under a pseudonym) that uses the ghc
>> api. I have not been working in Haskell and I've found that it's
>> bitrotted since the 8.10.x series that I was most recently using.
>>
>> The impact of refactors to the ghc codebase have hit me really badly,
>> and with the help of Sylvain, I've been able to get it to the point
>> where it compiles with 9.0.2 and 9.2.7. I'm currently working my way
>> through 9.4.5 support but this is becoming extremely time consuming and
>> draining, so I'm asking for help from anybody who has been involved in
>> these refactors if they could help further. There's only so much git
>> pickaxe can help with, when functions names, types and parameters are
>> moved around in a way that is hard to keep track of. Especially with the
>> changes impacting the way packages, units, errors, and compiler
>> invocation all work.
>>
>> The code is 

Re: Performance of small allocations via prim ops

[Simon Peyton Jones]

> We are emitting a more efficient code when the size of the array is
smaller. And the threshold is governed by a compiler flag:

It would be good if this was documented.  Perhaps in the Haddock for
`newByteArray#`?  Or where?

S

On Fri, 7 Apr 2023 at 07:07, Harendra Kumar 
wrote:

> Little bit of grepping in the code gave me this:
>
> emitPrimOp cfg primop =
>   let max_inl_alloc_size = fromIntegral (stgToCmmMaxInlAllocSize cfg)
>   in case primop of
>   NewByteArrayOp_Char -> \case
> [(CmmLit (CmmInt n w))]
>   | asUnsigned w n <= max_inl_alloc_size --
> <--- see this line
>   -> opIntoRegs  $ \ [res] -> doNewByteArrayOp res (fromInteger n)
> _ -> PrimopCmmEmit_External
>
> We are emitting a more efficient code when the size of the array is
> smaller. And the threshold is governed by a compiler flag:
>
>   , make_ord_flag defGhcFlag "fmax-inline-alloc-size"
>   (intSuffix (\n d -> d { maxInlineAllocSize = n }))
>
> This means allocation of smaller arrays is extremely efficient and we can
> control it using `-fmax-inline-alloc-size`, the default is 128. That's a
> new thing I learnt today.
>
> Given this new finding, my original question now applies only to the case
> when the array size is bigger than this configurable threshold, which is a
> little less motivating. And Ben says that the call is not expensive, so we
> can leave it there.
>
> -harendra
>
> On Fri, 7 Apr 2023 at 11:08, Harendra Kumar 
> wrote:
>
>> Ah, some other optimization seems to be kicking in here. When I increase
>> the size of the array to > 128 then I see a call to stg_newByteArray# being
>> emitted:
>>
>>  {offset
>>c1kb: // global
>>if ((Sp + -8) < SpLim) (likely: False) goto c1kc; else goto
>> c1kd;
>>c1kc: // global
>>R1 = Main.main1_closure;
>>call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8;
>>c1kd: // global
>>I64[Sp - 8] = c1k9;
>>R1 = 129;
>>Sp = Sp - 8;
>>call stg_newByteArray#(R1) returns to c1k9, args: 8, res: 8,
>> upd: 8;
>>
>> -harendra
>>
>> On Fri, 7 Apr 2023 at 10:49, Harendra Kumar 
>> wrote:
>>
>>> Thanks Ben and Carter.
>>>
>>> I compiled the following to Cmm:
>>>
>>> {-# LANGUAGE MagicHash #-}
>>> {-# LANGUAGE UnboxedTuples #-}
>>>
>>> import GHC.IO
>>> import GHC.Exts
>>>
>>> data M = M (MutableByteArray# RealWorld)
>>>
>>> main = do
>>>  _ <- IO (\s -> case newByteArray# 1# s of (# s1, arr #) -> (# s1, M
>>> arr #))
>>>  return ()
>>>
>>> It produced the following Cmm:
>>>
>>>  {offset
>>>c1k3: // global
>>>Hp = Hp + 24;
>>>if (Hp > HpLim) (likely: False) goto c1k7; else goto c1k6;
>>>c1k7: // global
>>>HpAlloc = 24;
>>>R1 = Main.main1_closure;
>>>call (stg_gc_fun)(R1) args: 8, res: 0, upd: 8;
>>>c1k6: // global
>>>I64[Hp - 16] = stg_ARR_WORDS_info;
>>>I64[Hp - 8] = 1;
>>>R1 = GHC.Tuple.()_closure+1;
>>>call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
>>>  }
>>>
>>> It seems to be as good as it gets. There is absolutely no scope for
>>> improvement in this.
>>>
>>> -harendra
>>>
>>> On Fri, 7 Apr 2023 at 03:32, Ben Gamari  wrote:
>>>
 Harendra Kumar  writes:

 > I was looking at the RTS code for allocating small objects via prim
 ops
 > e.g. newByteArray# . The code looks like:
 >
 > stg_newByteArrayzh ( W_ n )
 > {
 > MAYBE_GC_N(stg_newByteArrayzh, n);
 >
 > payload_words = ROUNDUP_BYTES_TO_WDS(n);
 > words = BYTES_TO_WDS(SIZEOF_StgArrBytes) + payload_words;
 > ("ptr" p) = ccall allocateMightFail(MyCapability() "ptr", words);
 >
 > We are making a foreign call here (ccall). I am wondering how much
 overhead
 > a ccall adds? I guess it may have to save and restore registers.
 Would it
 > be better to do the fast path case of allocating small objects from
 the
 > nursery using cmm code like in stg_gc_noregs?
 >
 GHC's operational model is designed in such a way that foreign calls are
 fairly cheap (e.g. we don't need to switch stacks, which can be quite
 costly). Judging by the assembler produced for newByteArray# in one
 random x86-64 tree that I have lying around, it's only a couple of
 data-movement instructions, an %eax clear, and a stack pop:

   36:   48 89 cemov%rcx,%rsi
   39:   48 89 c7mov%rax,%rdi
   3c:   31 c0   xor%eax,%eax
   3e:   e8 00 00 00 00  call   43
 
   43:   48 83 c4 08 add$0x8,%rsp

 The data movement operations in particular are quite cheap on most
 microarchitectures where GHC would run due to register renaming. I doubt
 that this overhead would be noticable in anything but a synthetic
 

CI

[Simon Peyton Jones]

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

Re: Buy-in for technical proposal 47 which affect GHC devs

[Simon Peyton Jones]

Thanks Laurent,

In fact this fits with our thinking in
https://github.com/haskell/core-libraries-committee/issues/105.   We'll
discuss and Ben/Matthew will get back to you.

Simon

On Sun, 12 Mar 2023 at 13:39, Laurent P. René de Cotret <
laurent.decot...@outlook.com> wrote:

> Dear GHC developers,
>
> In recent weeks, John Ericson has fine-tuned a Haskell Foundation
> Technical Proposal to split `base` into two libraries: `ghc-base` and
> `base`, the latter simply re-exporting everything for `ghc-base` (for now).
> You can read about the rationale and specifics more in details in the
> proposal itself:
> https://github.com/haskellfoundation/tech-proposals/pull/47
>
> Note that this proposal has recently been streamlined into a form which is
> more focused than its initial state, and might be worth a re-read.
>
> The Haskell Foundation Technical Working Group has reached a consensus
> that this work will benefit the Haskell community. Moreover, the Haskell
> Foundation has agreed to spend some of its resources to implement this
> proposal, which would start by ensuring the completion of MR7898 (
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7898).
>
> This work will affect GHC developers. Therefore, the Technical Working
> Group would like to get buy-in from the GHC developers before formally
> accepting this proposal.
>
> Best regards,
> Laurent P. René de Cotret
> on behalf of the Haskell Foundation Technical Working Group
> ___
> 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

[Simon Peyton Jones]

Ah.

rm utils/hpc
git submodule update

does the job.  Who would have guessed that?  Maybe this thread will help
others.

Could hadrian have avoided this, perhaps?

Anyway, I'm rolling again, thanks

Simon

On Wed, 15 Mar 2023 at 12:54, Simon Peyton Jones <
simon.peytonjo...@gmail.com> wrote:

> Oh I didn't know you had to say "--init".  Anyway that fails
>
> git submodule update --init
> Submodule 'utils/hpc' (https://gitlab.haskell.org/hpc/hpc-bin.git)
> registered for path 'utils/hpc'
> fatal: destination path '/home/simonpj/code/HEAD-15/utils/hpc' already
> exists and is not an empty directory.
> fatal: clone of 'https://gitlab.haskell.org/hpc/hpc-bin.git' into
> submodule path '/home/simonpj/code/HEAD-15/utils/hpc' failed
> Failed to clone 'utils/hpc'. Retry scheduled
> fatal: destination path '/home/simonpj/code/HEAD-15/utils/hpc' already
> exists and is not an empty directory.
> fatal: clone of 'https://gitlab.haskell.org/hpc/hpc-bin.git' into
> submodule path '/home/simonpj/code/HEAD-15/utils/hpc' failed
> Failed to clone 'utils/hpc' a second time, aborting
> simonpj@LHR-WD-22561:~/code/HEAD-15$
>
> Simon
>
> On Wed, 15 Mar 2023 at 12:46, Sam Derbyshire 
> wrote:
>
>> Perhaps even `git submodule update --init`.
>>
>> On Wed, 15 Mar 2023 at 13:41, Matthew Pickering <
>> matthewtpicker...@gmail.com> 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

Re: Help! Can't build HEAD

[Simon Peyton Jones]

Oh I didn't know you had to say "--init".  Anyway that fails

git submodule update --init
Submodule 'utils/hpc' (https://gitlab.haskell.org/hpc/hpc-bin.git)
registered for path 'utils/hpc'
fatal: destination path '/home/simonpj/code/HEAD-15/utils/hpc' already
exists and is not an empty directory.
fatal: clone of 'https://gitlab.haskell.org/hpc/hpc-bin.git' into submodule
path '/home/simonpj/code/HEAD-15/utils/hpc' failed
Failed to clone 'utils/hpc'. Retry scheduled
fatal: destination path '/home/simonpj/code/HEAD-15/utils/hpc' already
exists and is not an empty directory.
fatal: clone of 'https://gitlab.haskell.org/hpc/hpc-bin.git' into submodule
path '/home/simonpj/code/HEAD-15/utils/hpc' failed
Failed to clone 'utils/hpc' a second time, aborting
simonpj@LHR-WD-22561:~/code/HEAD-15$

Simon

On Wed, 15 Mar 2023 at 12:46, Sam Derbyshire 
wrote:

> Perhaps even `git submodule update --init`.
>
> On Wed, 15 Mar 2023 at 13:41, Matthew Pickering <
> matthewtpicker...@gmail.com> 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

Re: Help! Can't build HEAD

[Simon Peyton Jones]

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:  I forgot to say -- I always do `git submodule update`. On
  this occasion it's a no op S [...] 

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
(simon.peytonjones[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 ---
I forgot to say -- I always do `git submodule update`.

On this occasion it's a no op

S

On Wed, 15 Mar 2023 at 12: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
--- End Message ---

Help! Can't build HEAD

[Simon Peyton Jones]

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

Re: Installing GHC on my MacBook Air

[Simon Peyton Jones]

Redirecting this query to ghc-devs.  Can anyone help William?  Thanks!

Will GHC run on my new MacBook Air? After installing the compiler, my
> laptop said its processor was wrong for the binary distribution I chose. If
> there is a dmg file for MacOS 12.5.1, please please link your reply to it.
>

Simon

On Tue, 14 Mar 2023 at 23:33, William McEnaney 
wrote:

> Dear Dr. Jones,
>
> Will GHC run on my new MacBook Air? After installing the compiler, my
> laptop said its processor was wrong for the binary distribution I chose. If
> there is a dmg file for MacOS 12.5.1, please please link your reply to it.
>
> Thanks for your help.
>
> Best,
> Bill
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Slow downloads

[Simon Peyton Jones]

I'm getting very low transfer rates on Git operations.  Like 16 kb/s.
Things that usually take a second or two are still going 10 minutes later.
See below

My internet connection appears to be solid at 100Mb/s upload and download.

Any ideas?

Simon


[image: image.png]
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Searching tickets

[Simon Peyton Jones]

>
> I belive that the search bar at the top of
> https://gitlab.haskell.org/ghc/ghc/-/issues/ only searches the issues'
> title and description.
>

That is ... disappointing to say the least.

It is possible to search in comments via
> https://gitlab.haskell.org/search?group_id=2_id=1=notes.
>

Alas that interface has no way to sort by date or anything else -- as you
say, not very useful.

Sadly, searching for "Haskeline" here turns up over 300 results and none
> of which are the ticket you are looking for
>

very very sadly

These days, search is basically a solved problem.  I wonder if Gitlab have
any interest in picking up a solution and deploying it?  It seems deeply
sad that Gitlab should be so deficient here.  When you have 20,000 tickets,
search isn't optional  any more .. it's a key tool.

I tend to use google with the extra keyword site:
> gitlab.haskell.org/ghc/ghc/-/issues, as it often has better search
> results than gitlab itself. It doesn't work too well for very recent
> tickets though
>

Yes: site:gitlab.haskell.org/ghc/ghc/-/issues haskeline
-fspecialize-aggressively doesn't find it.  Not working well for recent
tickets (this one is 2 weeks old) is a huge drawback.

Boo.  Thanks for responses though

Simon

On Tue, 24 Jan 2023 at 18:21, Ben Gamari  wrote:

> Simon Peyton Jones  writes:
>
> > I keep finding that 'search' in Gitlab misses things.
> >
> > Example
> > https://gitlab.haskell.org/ghc/ghc/-/issues/22715 mentions "Haskeline"
> > (just look on that page)
> >
> > Yet when I go to
> > https://gitlab.haskell.org/ghc/ghc/-/issues/
> > and search for "Haskeline", this ticket isn't reported.
> >
> > What am I doing wrong?
> >
> I belive that the search bar at the top of
> https://gitlab.haskell.org/ghc/ghc/-/issues/ only searches the issues'
> title and description. However, in this particular ticket Haskeline is
> only mentioned in a comment.
>
> It is possible to search in comments via
> https://gitlab.haskell.org/search?group_id=2_id=1=notes.
> Sadly, searching for "Haskeline" here turns up over 300 results and none
> of which are the ticket you are looking for; I'm sure that the ticket is
> in the returned results somewhere, but I don't think this would be an
> efficient way to find it (although being able to sort the result set by
> date would make this much easier).
>
> For this reason I routinely edit issue labels and descriptions to ensure
> that they mention useful keywords. However, even then locating tickets
> can be challenging.
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Searching tickets

[Simon Peyton Jones]

I keep finding that 'search' in Gitlab misses things.

Example
https://gitlab.haskell.org/ghc/ghc/-/issues/22715 mentions "Haskeline"
(just look on that page)

Yet when I go to
https://gitlab.haskell.org/ghc/ghc/-/issues/
and search for "Haskeline", this ticket isn't reported.

What am I doing wrong?

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

Re: Implementors for deprecated exports?

[Simon Peyton Jones]

Just to say: this is part of an effort (by the Stability Working Group) to
help us, as a community, walk the line between stability (which is
essential for Haskell to be useful) and dynamism (which is essential for
Haskell to be truly alive).

It's not an easy line to walk (you can see meeting notes here)
, but
there are quite a few things we can do to avoid unnecessary breakage and
ease transitions.

Everything takes work, though, hence this invitation for contributions.
Please consider helping.   But in a wider sense, if you have ideas relevant
to the scope of the Working Group
, do talk to us.

Thanks!

Simon

On Tue, 29 Nov 2022 at 20:50, David Christiansen 
wrote:

> Dear GHC developers,
>
> The HF's Stability Working Group (
> https://github.com/haskellfoundation/stability) has been looking into
> ways to help Haskell developers maintain their code in the face of changes
> to the language and libraries.
>
> Out of the ideas we found, one is already an accepted GHC proposal, just
> waiting for implementation! This is adding the ability to deprecate an
> export, rather than just a definition, which would allow a function to be
> moved to a new home, with the old location re-exporting it under a
> deprecation warning for a few releases.
>
> We're wondering: do any of you feel inspired to implement this?  If you
> did, we'd do our best to make sure that you are supported with design
> advice and code review. This is probably not a good first contribution to
> GHC; you'll need some familiarity with GHC and how to build it.
>
> The accepted proposal is here:
> https://github.com/ghc-proposals/ghc-proposals/pull/134
>
> The GHC ticket that it emerged from is here:
> https://gitlab.haskell.org/ghc/ghc/-/issues/4879
>
> All the best,
> David and Simon
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab slow?

[Simon Peyton Jones]

It is fast again now...

Simon

On Mon, 14 Nov 2022 at 16:35, Ben Gamari  wrote:

> Bryan Richter via ghc-devs  writes:
>
> > I find it very slow, as well. :(
> >
> > Eventually I want to be able to help out with these problems, but
> > right now my priorities are different and I don't have the bandwidth.
> > We rely on Ben still. (I am at least relieving him of other tasks that
> > would be competing for his time!)
> >
> Hmm, interesting. I'm not seeing anything particularly concerning with
> the load times. According to Firefox's network profiler
> https://gitlab.haskell.org/ghc/ghc/-/issues/22451 takes about 3 seconds
> to load, with the DOM being loaded with 500ms. While this isn't fast per
> se, it's about in line with what I would expect.
>
> Are either of you seeing significantly longer load times?
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Gitlab slow?

[Simon Peyton Jones]

Is it just me, or is GitLab taking an unusually long time to serve up pages
when looking at GHC tickets?

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

Re: Status of Stream Fusion?

[Simon Peyton Jones]

Jaro

1. Is the ‘concatMap’ problem really the only problem left on the way to
> using stream fusion instead of foldr/build fusion in base?
>

Can you say precisely what you mean by "using stream fusion instead of
foldr/build fusion in base"?   For example, do you have a prototype library
that demonstrates what you intend, all except concatMap?

  concatMap (λx → Stream next (f x)) = concatMap' next f
>

If it was lined up nicely like that it'd be easy. But what about

concatMap (\x. Stream next (x*2 +x))

Then you want matching to succeed, with the substitution
f :->  (\p. p*2 +p)

This is called "higher order matching" and is pretty tricky.  You could
start with this paper

.

My comment on
#22361 also refers to the potential usefulness of higher order matching.

Simon

On Mon, 14 Nov 2022 at 09:47, J. Reinders  wrote:

> Dear GHC devs,
>
> I’m interested in stream fusion and would like to see what it takes to fix
> the remaining issues, so that it can replace foldr/build fusion in base.
>
> First of all I would like to know what exactly the challenges are that are
> left. I believe one of the main remaining problems is the fusion of
> ‘concatMap’. Is that really the only thing?
>
> Secondly, I would like to know what has already been tried. I know
> Sebastian Graf has spent a lot of effort trying to get SpecConstr to work
> on lambda arguments without success. I’ve read that Sebastian now considers
> the static argument transformation more promising.
>
> However, Duncan Coutts proposed in his thesis to make rewrite rules
> slightly more powerful and use the rewrite rule:
>
> concatMap (λx → Stream next (f x)) = concatMap' next f
>
> Has that ever been tried? If so, what is the problem with this rewrite
> rule approach? I can understand that the `f x` function application is
> usually in a more reduced form, but it seems relatively easy to make the
> rewrite rule matcher smart enough to see through beta-reductions like that.
>
> So my main questions are:
>
> 1. Is the ‘concatMap’ problem really the only problem left on the way to
> using stream fusion instead of foldr/build fusion in base?
>
> 2. Has the rewrite rule approach to solving the ‘concatMap’ problem ever
> been tried?
>
> Any other information about the current status of stream fusion is also
> much appreciated.
>
> Cheers,
>
> Jaro Reinders
>
> ___
> 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

Pushing to nofib

[Simon Peyton Jones]

Friends

How do I push to the nofib/ repository?  I just wanted to add some
documentation. I'm on branch 'master' and tried to push.  Got this below.
What next?

Thanks

Simon

bash$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 24 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 543 bytes | 543.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: GitLab: You are not allowed to push code to protected branches on
this project.
To gitlab.haskell.org:ghc/nofib.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'g...@gitlab.haskell.org:ghc/nofib.git'
simonpj@LHR-WD-22561:~/code/HEAD-1/nofib$
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GItlab search

[Simon Peyton Jones]

Friends

I'm struggling with GitLab search.

eg I was looking for #22200

I wen to https://gitlab.haskell.org/ghc/ghc/-/issues, and put "-DEEBUG" and
"slow" in the search box.  No #22200.  Yet both of those strings appear in
the title of the ticket.

Looking for DEBUG or *DEBUG also fails. I find that DDEBUG succeeds.  What
are the rules?

Thanks

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

Warnings in RTS

[Simon Peyton Jones]

Whenever I compile the RTS I get these warnings.  Are they necessary?

Simon

In file included from rts/Schedule.c:16:0: error:
rts/Schedule.c: In function ‘schedule’:

rts/Schedule.h:143:1: error:
 warning: inlining failed in call to ‘appendToRunQueue’: call is
unlikely and code size would grow [-Winline]
  143 | appendToRunQueue (Capability *cap, StgTSO *tso)
  | ^~~~
|
143 | appendToRunQueue (Capability *cap, StgTSO *tso)
| ^

rts/Schedule.c:1226:9: error:
 note: called from here
 1226 | appendToRunQueue(cap,t);
  | ^~~
 |
1226 | appendToRunQueue(cap,t);
 | ^

In file included from rts/Schedule.c:16:0: error:

rts/Schedule.h:164:1: error:
 warning: inlining failed in call to ‘pushOnRunQueue’: call is unlikely
and code size would grow [-Winline]
  164 | pushOnRunQueue (Capability *cap, StgTSO *tso)
  | ^~
|
164 | pushOnRunQueue (Capability *cap, StgTSO *tso)
| ^

rts/Schedule.c:1228:9: error:
 note: called from here
 1228 | pushOnRunQueue(cap,t);
  | ^
 |
1228 | pushOnRunQueue(cap,t);
 | ^
rts/Schedule.c: At top level:
cc1: warning: unrecognized command line option
‘-Wno-nonportable-include-path’
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Tier 1 architectures

[Simon Peyton Jones]

Ben, Matthew, Moritz, and friends

Is this wiki page about architectures still accurate?
https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms

For example, ARM is not Tier 1, or "apple silicon".

Yet I know some of our developers have invested lots of effort in other
architectures, so maybe those efforts are not reflected here.

Relevant is Moritz's post about 32-bit architectures

.

We should in due course add Javascript and Web Assembly as Tier 1 back ends?

Are we saying "if your customer bases uses Tier 2 architectures, you can't
rely on GHC from one release to the next"?  I wonder if there are companies
for which Tier-2 architectures are mission-critical.  Mis-aligned
expectations cause upset.

I mention all this because it is relevant to our stability guarantees.
Every time we release we should point to this list.

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

Re: Alternative to isTypeLevPoly

[Simon Peyton Jones]

>
> The type argument to LitRubbish should be a fixed RuntimeRep. If it is
> not, you can file a bug
>

Yes!  Please file a bug if you find this.

On Thu, 15 Sept 2022 at 16:36, Krzysztof Gogolewski <
krz.gogolew...@gmail.com> wrote:

> The type argument to LitRubbish should be a fixed RuntimeRep. If it is
> not, you can file a bug. I have fixed a related bug in f435d55fe969e7.
>
> Krzysztof
>
> On Thu, Sep 15, 2022 at 1:12 PM Csaba Hruska 
> wrote:
> >
> > I've investigated a bit more. You are right `typeHasFixedRuntimeRep`
> works fine, the panic was caused by querying the representation type of
> `LitRubbish` type argument. In some cases `getRuntimeRep` causes GHC panic
> for `LitRubbish` type arguments.
> > I did solve the issue with special casing the LitRubbish type argument
> handling by using only the `runtimeRepPrimRep` function. In the general
> case I tested the type with `isUnboxedTupleType` and `isUnboxedSumType`
> which rely on `getRuntimeRep`.
> > Thanks for the tips and feedback.
> > Regards,
> > Csaba
> >
> > On Wed, Sep 14, 2022 at 6:44 PM Sam Derbyshire 
> wrote:
> >>
> >> 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
> ___
> 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

Haskell program coverage

[Simon Peyton Jones]

Matthias, David,

David Binder apparently
has some PRs for GHC's HPC program coverage stuff that have somehow
languished un-merged for some time.   David, can you point us to them, so
we can look?

Matthias wants to extend HPC in a number of
ways.  See here
and here
.

Maybe you want to talk to each other?  You are both here at ICFP!

And it would be great to have a little team that cared about HPC more
generally, and could look after it.

Thanks.  Apologies if I have misunderstood anyone.

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

GHC compiler perf CI

[Simon Peyton Jones]

Dear devs

I used to use the build *x86_64-linux-deb10-int_native-validate* as the
place to look for compiler/bytes-allocated changes in perf/compiler.  But
now it doesn't show those results any more, only runtime/bytes-allocated in
perf/should_run.


   - Should we not run perf/compiler in every build?
   - Why has it gone from the build above
   - Which build should I look at to see perf/compiler data

Thanks

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

Re: Unix library apparently broken

[Simon Peyton Jones]

Thanks Sam.  As you'll see on !8750 pointing to the right commit seems to
have fixed !8750.  I think I must have inadvertently committed a wrong
unix-library submodule change.

I'm not very clear on

   - Given a particular 'master' commit C from the main GHC repo (e.g. I've
   rebased my patch on C)
   - How do I identify the 'unix' commit that C needs?  It might not be the
   head of the unix repo.

Simon

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

> Thanks, good to know. Yes, I did git submodule update.  I'll look again
> tomorrow
>
> S
>
> On Tue, 6 Sept 2022 at 17:27, Sam Derbyshire 
> wrote:
>
>> Hi Simon,
>>
>> This is due to my patch 4786acf7
>> <https://gitlab.haskell.org/ghc/ghc/-/commit/4786acf758ef064d3b79593774d1672e294b0afb>
>> 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
>> <https://gitlab.haskell.org/ghc/ghc/-/commit/4786acf758ef064d3b79593774d1672e294b0afb>
>> .
>>
>> 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 -

Re: Unix library apparently broken

[Simon Peyton Jones]

Thanks, good to know. Yes, I did git submodule update.  I'll look again
tomorrow

S

On Tue, 6 Sept 2022 at 17:27, Sam Derbyshire 
wrote:

> Hi Simon,
>
> This is due to my patch 4786acf7
> <https://gitlab.haskell.org/ghc/ghc/-/commit/4786acf758ef064d3b79593774d1672e294b0afb>
> 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
> <https://gitlab.haskell.org/ghc/ghc/-/commit/4786acf758ef064d3b79593774d1672e294b0afb>
> .
>
> 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

Unix library apparently broken

[Simon Peyton Jones]

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

Re: possible regression in GHC 9.2.4: hang in simplifier (?) when building a test executable

[Simon Peyton Jones]

Maybe open GHC ticket?

How can I repro with a *particular* GHC, for example my build of HEAD?

And how can I find the command line that finally hung, so I can try it
repeatedly?

Simon

On Tue, 6 Sept 2022 at 14:02, Doug Burke  wrote:

> I have a test executable which will build with ghc 9.2.3 (and many
> older versions) but which appears to hang with GHC 9.2.4. I have
> exhausted what little I know of in debugging this, so any help in
> identifying the problem would be appreciated. Unfortunately it's a
> relatively large application, so the following reproducer requires
> some time/disk space.
>
> Thanks fo ryour time,
> Doug
>
>
> -
>
> I am on a linux machine (ubuntu 22.04) and have seen this with builds
> either with stack or nix.
>
> % git clone https://gitlab.com/dburke/swish temp
> % cd temp
> % git rev-parse HEAD
> 09c92e0fbbea9be86cac5c8e273e1d5915a9eeae
>
> Added to get the timings, but it's not strictly necessary:
>
> % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal
>
> First a check of a successful build (with stack, GHC 9.0.2):
>
> % stack test --resolver lts-19.22 :test-rdfproof
> ... wait a while
> [2 of 2] Compiling Main
> *** Parser [Main]:
> Parser [Main]: alloc=27576560 time=8.702
> *** Renamer/typechecker [Main]:
> Renamer/typechecker [Main]: alloc=61957416 time=85.052
> *** Desugar [Main]:
> Desugar [Main]: alloc=19485576 time=16.095
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=1024590752 time=937.479
> *** Specialise [Main]:
> Specialise [Main]: alloc=49779464 time=30.480
> *** Float out(FOS {Lam = Just 0,
>Consts = True,
>OverSatApps = False}) [Main]:
> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False})
> [Main]: alloc=243444904 time=287.934
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=959971736 time=844.707
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=816465992 time=727.244
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=914290184 time=835.805
> Float inwards [Main]: alloc=17448 time=0.007
> Called arity analysis [Main]: alloc=19288 time=0.008
> *** Float inwards [Main]:
> *** Called arity analysis [Main]:
> *** Simplifier [Main]:
> *** Demand analysis [Main]:
> Simplifier [Main]: alloc=492772800 time=396.191
> Demand analysis [Main]: alloc=435384136 time=234.248
> *** Constructed Product Result analysis [Main]:
> Constructed Product Result analysis [Main]: alloc=67395816 time=27.498
> *** Worker Wrapper binds [Main]:
> Worker Wrapper binds [Main]: alloc=10456160 time=10.538
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=675869616 time=624.538
> Exitification transformation [Main]: alloc=20416 time=0.007
> *** Exitification transformation [Main]:
> *** Float out(FOS {Lam = Just 0,
>Consts = True,
>OverSatApps = True}) [Main]:
> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True})
> [Main]: alloc=212059304 time=172.872
> Common sub-expression [Main]: alloc=18768 time=0.008
> Float inwards [Main]: alloc=17448 time=0.006
> *** Common sub-expression [Main]:
> *** Float inwards [Main]:
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=430634768 time=397.868
> *** Demand analysis [Main]:
> Demand analysis [Main]: alloc=144629272 time=70.451
> *** CoreTidy [Main]:
> CoreTidy [Main]: alloc=48438688 time=44.112
> *** CorePrep [Main]:
> *** CodeGen [Main]:
> CorePrep [Main]: alloc=15032 time=0.012
> CodeGen [Main]: alloc=1738308168 time=1051.197
> *** systool:as:
> systool:as: alloc=118376 time=0.481
> *** initializing unit database:
> initializing unit database: alloc=15393080 time=21.985
> *** initializing unit database:
> initializing unit database: alloc=3745512 time=2.507
> *** Chasing dependencies:
> *** systool:cpp:
> systool:cpp: alloc=213016 time=0.552
> Chasing dependencies: alloc=11345152 time=5.353
> Linking
> .stack-work/dist/x86_64-linux-tinfo6/Cabal-3.4.1.0/build/test-rdfproof/test-rdfproof
> ...
> ...
> ... then it goes on to run the test
> ...
>
> With 9.2.4 it will not build
>
> %
> ... similar to above but with some information about the versions not
> ... fully tested with stack
> ...
> *** Parser [Main]:
> Parser [Main]: alloc=24346008 time=8.730
> *** Renamer/typechecker [Main]:
> Renamer/typechecker [Main]: alloc=58415776 time=44.077
> *** Desugar [Main]:
> Desugar [Main]: alloc=22148416 time=15.693
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=651048904 time=530.123
> *** Specialise [Main]:
> Specialise [Main]: alloc=44412080 time=31.885
> *** Float out(FOS {Lam = Just 0,
>Consts = True,
>OverSatApps = False}) [Main]:
> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False})
> [Main]: alloc=207753368 time=259.238
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=599788216 time=548.107
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=562910904 

Tags

[Simon Peyton Jones]

I love emacs' tags-query-replace function, which allows me to do a
search-and-replace across an entire repo.  But to do that I need a TAGS
file that, at least, lists all the Hsakell files in GHC.

What is the approved way to construct a TAGS file for a bunch of Haskell
modules?  Is this documented anywhere?

Thanks

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

Updating haddock

[Simon Peyton Jones]

Dear devs

I'm working on !8750, which has some knock-on changes that are needed on
the Haddock repo.   So

   - in the main repo I have wip/T21623
   - in the utils/haddock repo have branch wip/spj-T21623

Periodically I need to rebase on master.

Question: what is the Blessed Sequence of Commands that I should use to
push the right changes to haddock?  I think it is something like:


   1. In the main GHC repo, on branch wip/T21623
   1. git fetch
  2. git rebase origin/master
   2. In utils/haddock,
   1. identify the set of patches P1..Pn between the trunk and my haddock
  tip, the changes that I need to haddock.
  2. Somehow check out the haddock commit K that corresponds to
  origin/master
  3. Apply P1..Pn on top of K
  4. Force-push to origin/wip/spj-T21623
  3. Move to the main GHC repo
  1. git add utils/haddock
  2. Create a patch for that change
  3. Push to main repo


But I am not sure how to do step 2.2, nor what is an efficient way to do
2.3.

I would welcome very precise instructions.  Thank you!

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

CI failures

[Simon Peyton Jones]

Matthew, Ben, Bryan

CI is failing in in "lint-ci-config"..

See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8916
or https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7847

What's up?

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

Re: Partial type synonyms -- first-class!

[Simon Peyton Jones]

Richard writes

I think the route you're taking is a reasonable route to your destination,
> but I'm not yet convinced it's a destination I want GHC to travel to.
>

I'm in the same boat -- not yet convinced.  To me it seems like quite a bit
of implementation complexity to hit a pretty narrow use-case.  But maybe
you have convincing use-cases to offer, when you write a proposal. (Maybe
Edward can help with some.)

In any case, it's not me or Richard you need to convince, it's the GHC
Steering Committee via the proposals process.  You are doing a great job of
working out an implementation before submitting a proposal (which few
people do), but that doesn't, in and of itself, make the design more
attractive.  Yet it must be very attractive to you if you are contemplating
maintaining a fork in the medium term.   Maybe you can convince everyone!

Simon

On Fri, 12 Aug 2022 at 04:05, Gergő Érdi  wrote:

> That's great to hear because it looks like this will need all the support
> it can get to ever be allowed into upstream...
>
> On Fri, Aug 12, 2022, 10:43 Edward Kmett  wrote:
>
>> FWIW, Gergo, I've been following what you've been doing pretty closely,
>> so there's at least two of us tracking it in the background. =) I might
>> have some clever(?) (ab)uses for it in the future in my linear haskell code.
>>
>> -Edward
>>
>> On Thu, Aug 11, 2022 at 10:33 PM ÉRDI Gergő  wrote:
>>
>>> Hi Richard,
>>>
>>> Thanks for getting back to me! My replies are inline below.
>>>
>>> On Thu, 11 Aug 2022, Richard Eisenberg wrote:
>>>
>>> > You want a third:
>>> >
>>> > C. invisible parameters that are filled in with a fresh wildcard.
>>> >
>>> > We would need to have some way of writing out the type of such a thing
>>> > (i.e. what kind would `Syn` have?), but I presume this is possible.
>>>
>>> I think there's a tension between this and your suggestion to only add
>>> implicit parameters as a new `TyConBndrVis`, but more on that below.
>>>
>>> >> 2. Using partial type synonyms
>>> >>
>>> >>
>>> >
>>> > This bit also makes sense, but I think users will want more
>>> > functionality. Specifically, what if a user does not want a wildcard
>>> > inserted, because they know that the right choice is `Int`? Or maybe
>>> > they want a *named* wildcard inserted. My experience is that once
>>> > something can be done implicitly, folks will soon find good reasons to
>>> > do it explicitly on occasion.
>>>
>>> Good point, but I think we can punt on this and not close any doors
>>> ahead.
>>> So today, you would only be able to write `Syn T` to mean `Syn {_} T`,
>>> and
>>> then in the future we can add typechecker support (and new surface
>>> syntax!) for `Syn {S} T`, without causing any compatibility problems
>>> with
>>> any existing code that doesn't give explicit args for implicit params.
>>>
>>> >> 3. Implementation
>>> >>
>>> >>
>>> >>  * When typechecking a type application, implicit arguments get
>>> >>filled with the result of `tcAnonWildCardOcc`.
>>> >
>>> > What about named wildcards? Even if they're not passed in, perhaps
>>> someone wants
>>> >
>>> > type SomeEndo = _t -> _t
>>> >
>>> > where the two types are known to be the same, but we don't know what.
>>>
>>> This would be something to support when typechecking the definition, not
>>> a
>>> given application. Your example would still elaborate to
>>>
>>>  type SomeEndo {t} = t -> t
>>>
>>> it would just use the same implicitly-bound type parameter `t` twice on
>>> the right-hand side. But when you use `SomeEndo`, the usage would still
>>> elaborate into a (single) anonymous wildcard argument, i.e.
>>> `SomeEndo {_}`.
>>>
>>> My current implementation doesn't support your example, but I think it's
>>> only because the renamer rejects it. I think if I get it through the
>>> renamer, it should already work because that `_t` will typecheck into a
>>> wildcard `TauTv`.
>>>
>>> >> 3. Similar to #1, I started just pushing all the way through GHC a
>>> >> change to `AnonArgFlag` that adds a third `ImplArg` flag.
>>> >
>>> > I don't love adding a new constructor to AnonArgFlag, because that's
>>> > used in terms. Instead, it would be great to localize this new
>>> extension
>>> > to tycon binders somehow.
>>>
>>> OK so while I'd love to get away with only changing `TyConBndrVis`, this
>>> is the part of your email that I don't understand how to do :/
>>>
>>> First, when a type application is typechecked, we only have the kind of
>>> the type constructor, not its binders (and that makes sense, since we
>>> could be applying something more complex than directly a defined type
>>> constructor). So if I only add a new `TyConBndrVis` constructor, then I
>>> have no way of representing this in the `tyConKind` and so no way of
>>> finding out that I need to put in implicit args in `tcInferTyApps`.
>>>
>>> Second, you ask what the kind of `Syn` in e.g. `type Syn a = TC _ a` is.
>>> I
>>> think (supposing `TC :: K -> L -> M`) its kind should be (stealing
>>> syntax
>>> from Agda) 

Re: Advice for implementing GADTs?

[Simon Peyton Jones]

>
> 3.1: OK, so if the case branch introduces type-class constraints, but not
> equality constraints, then the unification variables from an outer level
> are still touchable?  Presumably because the type-class constraints don't
> interact with the equality constraints?
>

Yes, but the check is a bit conservative. Look at `inert_given_eqs` in
`InertCans`, and `updateGivenEqs`.

* implication constraints like (a ~ Int ==> a ~ Int) are never created.
>
I may be assuming that GHC runs the solver for each GADT pattern match
> before creating implication constraints.
>
That's not right.  They can be created, but then get solved, by solving the
Wanted from the Given.

3.3: Also, is there a standard way to pretty-print implication
> constraints?  The OutsideIn paper uses LaTeX \supset I think, but there
> isn't an obvious ASCII character to use to for \supset...
>

Well there is a `Outputable` instance.  It uses `=>`.

Simon

On Mon, 15 Aug 2022 at 20:00, Benjamin Redelings <
benjamin.redeli...@gmail.com> wrote:

> Thanks a bunch for this!
> On 8/4/22 3:45 PM, Simon Peyton Jones wrote:
>
> QUESTION 1: Are there any obviously important resources that I've
> overlooked?
> That's a good list.  Ningning's thesis https://xnning.github.io/ is also
> good stuff.
>
> Thanks!
>
>
> QUESTION 2: if my quick scan is correct, none of the papers mention the
> GHC technique of determining untouchability by assigning "levels" to type
> variables.  Is there any written paper (outside the GHC sources) that
> discusses type levels?
> It is disgracefully undocumented, I'm afraid.  Sorry.  Didier Remy used
> similar ideas, in some INRIA papers I think.
>
> OK, that was my impression, just checking.  I think I get the basic idea...
>
>
> QUESTION 3: My impression is that:
>
> (a) type variable levels were introduced in order to clarify which
> MetaTyVars are "untouchable", but
>
> (b) levels now also check that type variables do not escape their
> quantification scope.
>
> (c) levels can also be used to figure out which variables are free in the
> type environment, and therefore should not be generalized over.
>
> Does this sound right?  I suspect that I might be wrong about the last
> one...
>
>
> Correct about all three.
>
> Good to know!
>
> Except that a unification variable is only untouchable if it comes from an
> outer level *and* there are some intervening Given equalities.   If there
> are no equalities it's not untouchable.  E.b.
>f = \x -> case x of
> Just y -> 3::Int
>
> Here the (3::Int) can affect the result type of the function because the
> Just pattern match does not bind any Given equalities (in a GADT like way).
>
> 3.1: OK, so if the case branch introduces type-class constraints, but not
> equality constraints, then the unification variables from an outer level
> are still touchable?  Presumably because the type-class constraints don't
> interact with the equality constraints?
>
> 3.2: The OutsideIn paper talks about creating implication constraints,
> which then bubble UP to the level where the solver is applied.  Maybe only
> at the outermost level?
>
> However, it sounds like GHC pushes given constraints from a GADT pattern
> match DOWN into the case branch.  Implication constraints would only be
> created if the wanted constraints bubble up to a GADT pattern match, and
> are not entailed by the givens.  So
>
> * implication constraints like (a ~ Int ==> a ~ Int) are never created.
>
> * however, implication constraints like (a ~ Int ==> b ~ Int) could be
> created.
>
> I may be assuming that GHC runs the solver for each GADT pattern match
> before creating implication constraints.
>
> Does that sound right?
>
> 3.3: Also, is there a standard way to pretty-print implication
> constraints?  The OutsideIn paper uses LaTeX \supset I think, but there
> isn't an obvious ASCII character to use to for \supset...
>
>
> I keep meaning to write an updated version of Practical type inference
> for arbitrary rank types
> <https://www.microsoft.com/en-us/research/publication/practical-type-inference-for-arbitrary-rank-types/>,
> but failing to get around to it!
>
> That would be great, if you find the time!  Are you thinking of adding
> practical steps for handling equality constraints to it?  Or, removing the
> deep-subsumption language?  Or something else?  It has already been quite
> helpful.
>
> -BenRI
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Advice for implementing GADTs?

[Simon Peyton Jones]

QUESTION 1: Are there any obviously important resources that I've
overlooked?
That's a good list.  Ningning's thesis https://xnning.github.io/ is also
good stuff.

QUESTION 2: if my quick scan is correct, none of the papers mention the GHC
technique of determining untouchability by assigning "levels" to type
variables.  Is there any written paper (outside the GHC sources) that
discusses type levels?
It is disgracefully undocumented, I'm afraid.  Sorry.  Didier Remy used
similar ideas, in some INRIA papers I think.


QUESTION 3: My impression is that:

(a) type variable levels were introduced in order to clarify which
MetaTyVars are "untouchable", but

(b) levels now also check that type variables do not escape their
quantification scope.

(c) levels can also be used to figure out which variables are free in the
type environment, and therefore should not be generalized over.

Does this sound right?  I suspect that I might be wrong about the last
one...


Correct about all three. Except that a unification variable is only
untouchable if it comes from an outer level *and* there are some
intervening Given equalities.   If there are no equalities it's not
untouchable.  E.b.
   f = \x -> case x of
Just y -> 3::Int

Here the (3::Int) can affect the result type of the function because the
Just pattern match does not bind any Given equalities (in a GADT like way).

I keep meaning to write an updated version of Practical type inference for
arbitrary rank types
,
but failing to get around to it!


Simon

On Fri, 29 Jul 2022 at 17:08, Benjamin Redelings <
benjamin.redeli...@gmail.com> wrote:

> Hi,
>
> I've been working on implementing the Haskell type system for my
> specialized Haskell interpreter.  I have now constructed a system that can
> type-check and run Haskell code that contains explicit type signatures,
> type constraints, and arbitrary-rank types.
>
> I'm now thinking that I may need to implement GADTs -- i.e. constructors
> that introduce local constraints, including equality constraints.  I'm
> looking at the paper "OutsideIn(X): Modular type inference with local
> assumptions" from 2011.  I have three questions about implementing GADTs --
> I'd be grateful for answers to any of them.
>
>
> QUESTION 1: Are there any obviously important resources that I've
> overlooked?
>
> The 2011 OutsideIn paper mentions several previous papers that seem quite
> helpful:
>
> * Peyton Jones el at 2006. Simple Unification-based type inference for
> GADTs
>
> * Schrijvers etal 2007. Towards open type functions for Haskell
>
> * Peyton Jones et al 2004. Wobbly Types: etc.
>
> * Schrijvers et al 2008. Type checking with open type functions.
>
> * Shrijvers et al 2009. Complete and decidable type inference for GADTs
>
> * Vytiniotis et al 2010. Let should not be generalized.
>
> And of course the GHC source code.  (I'm not looking at coercions at the
> present time, because my type-checker translates to the plain lambda
> calculus without type annotations, not system F or F_C.  Hopefully I can
> remedy this later...)
>
>
> QUESTION 2: if my quick scan is correct, none of the papers mention the
> GHC technique of determining untouchability by assigning "levels" to type
> variables.  Is there any written paper (outside the GHC sources) that
> discusses type levels?
>
>
> QUESTION 3: My impression is that:
>
> (a) type variable levels were introduced in order to clarify which
> MetaTyVars are "untouchable", but
>
> (b) levels now also check that type variables do not escape their
> quantification scope.
>
> (c) levels can also be used to figure out which variables are free in the
> type environment, and therefore should not be generalized over.
>
> Does this sound right?  I suspect that I might be wrong about the last
> one...
>
>
> Thanks again, and sorry for the long e-mail.
> -BenRI
>
>
> On 1/18/22 8:55 PM, Benjamin Redelings wrote:
>
> Hi,
>
> 1. I think I have clarified my problem a bit.  It is actually not related
> to pattern bindings. Here's an example:
>
> h = let f c   i = if i > 10 then c else g c 'b'
> g 'a' w = f 'b' 10
> g z   w = z
> in (f 'a' (1::Int), f 'a' (1.0::Double))
>
> If I am understanding the Haskell type system correctly,
>
> * the definitions of f and g form a recursive group
>
> * the monomorphism restriction is not invoked
>
> * the inner binding (to f and g) leads to a local value environment (LVE):
>
> { f :: Char -> a -> Char; g :: Char -> Char -> Char }
>
> with predicates (Num a, Ord a)
>
> 2. In this situation, Typing Haskell in Haskell suggests that we should
> NOT apply the predicates to the environment because the type for g does not
> contain 'a', and would become ambiguous (section 11.6.2).  Instead, we
> should only apply predicates to the environment if their type variables are
> present in ALL types in the current declaration group.
>
> Since the predicates 

Re: Test suite

[Simon Peyton Jones]

>
> There are tests that depend upon haddock in the testsuite, so we need to
> build them to run those tests. Like Cheng says, passing `--docs=none`
> will avoid those tests.
>

But looking at `ps` I see an invocation of haddock that was running for 20
minutes!  This can't be right.

Adding --docs=none apparently didn't work.  I get zillions of failures.

But then it turned out that this failed because I also added -VV, in the
hope of seeing what is going on.  So this works
hadrian/build test --docs=none --only=T13199
But this does not (log below)
hadrian/build test --docs=none --only=T13199 -VV

I thought -VV controlled verbosity only!

Simon

=> T13199(normal) 1 of 1 [0, 0, 0]
cd "/tmp/ghctest-6yc58m02/test   spaces/testsuite/tests/printer/T13199.run"
&& $MAKE --no-print-directory T13199   <
]0;T13199(normal) 1 of 1 [0, 0, 0] Actual stdout output differs from
expected:
diff -uw "/dev/null" "/tmp/ghctest-6yc58m02/test
spaces/testsuite/tests/printer/T13199.run/T13199.run.stdout.normalised"<
--- /dev/null 2022-07-28 08:52:58.41998 +0100
+++ "/tmp/ghctest-6yc58m02/test
spaces/testsuite/tests/printer/T13199.run/T13199.run.stdout.normalised"
2022-07-28 16:04:06.479419465 +0100
@@ -0,0 +1,2 @@
+/home/simonpj/code/HEAD-1/_build/test/bin/check-ppr
"`'/home/simonpj/code/HEAD-1/_build/stage1/bin/ghc' -dcore-lint -dstg-lint
-dcmm-lint -fno-dump-with-ways -no-user-package-db -rtsopts
 -fno-warn-missed-specialisations -fshow-warning-groups
-fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
-dno-debug-output --print-libdir | tr -d '\r'`" T13199.hs
+/home/simonpj/code/HEAD-1/_build/test/bin/check-exact
"`'/home/simonpj/code/HEAD-1/_build/stage1/bin/ghc' -dcore-lint -dstg-lint
-dcmm-lint -fno-dump-with-ways -no-user-package-db -rtsopts
 -fno-warn-missed-specialisations -fshow-warning-groups
-fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
-dno-debug-output --print-libdir | tr -d '\r'`" T13199.hs
*** unexpected failure for T13199(normal)

Performance Metrics (test environment: local):


None collected.


Unexpected results from:
TEST="T13199"

SUMMARY for test run started at Thu Jul 28 16:04:05 2022
0:00:00.845518 spent to go through
   1 total tests, which gave rise to
   7 test cases, of which
   6 were skipped
   0 had missing libraries

   0 expected passes
   0 expected failures

   0 caused framework failures
   0 caused framework warnings
   0 unexpected passes
   1 unexpected failures
   0 unexpected stat failures
   0 fragile tests

Unexpected failures:
   /tmp/ghctest-6yc58m02/test   spaces/testsuite/tests/printer/T13199.run
 T13199 [bad stdout] (normal)

On Thu, 28 Jul 2022 at 15:23, Zubin Duggal  wrote:

> There are tests that depend upon haddock in the testsuite, so we need to
> build them to run those tests. Like Cheng says, passing `--docs=none`
> will avoid those tests.
>
> On 22/07/28 14:47, Simon Peyton Jones wrote:
> >Doing *hadrian/build test*
> >takes absolutely ages.   It seems that it is building haddock, running
> >haddock, building check_exact, and other things.  Eg right now it is doing
> >Run Haddock BuildPackage: libraries/parsec/src/Text/Parsec.hs (and 24
> more)
> >=> _build/doc/html/libraries/parsec-3.1.15.0/parsec.haddock
> >
> >But I didn't ask to do Haddock. I just wanted to run the testsuite.   How
> >can I do that?
> >
> >I would prefer never to build haddock.
> >
> >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

Test suite

[Simon Peyton Jones]

Doing *hadrian/build test*
takes absolutely ages.   It seems that it is building haddock, running
haddock, building check_exact, and other things.  Eg right now it is doing
Run Haddock BuildPackage: libraries/parsec/src/Text/Parsec.hs (and 24 more)
=> _build/doc/html/libraries/parsec-3.1.15.0/parsec.haddock

But I didn't ask to do Haddock. I just wanted to run the testsuite.   How
can I do that?

I would prefer never to build haddock.

Thanks

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

Gitlab labels

[Simon Peyton Jones]

Whenever I try to add a label to a ticket I get "an error occurred while
updating labels".  See below.

When I repeat the exact same sequence, it works.

If I add another label, again the error; repeating again works.

This is tiresome and peculiar.  Does anyone have any ideas?

Simon

[image: image.png]
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Wildcards in type synonyms

[Simon Peyton Jones]

n the type arguments. Now, of course, this can't possibly
> work as soon as I have more than one occurrence of `MySyn` due to the
> interference between the wildcard metavars, but if I only have one, then
> the program typechecks. So to me this suggests I'm doing things mostly
> right, except that the metavar returned by `newMetaTyVarX` is not fit for
> my use case.
>
> What should I use instead of `newMetaTyVarX` to instantiate / "refresh"
> the (wildcard-originating) type metavariables in my "macro type template"?
>
> Thanks,
> Gergo
>
>
> On Mon, 25 Jul 2022, Simon Peyton Jones wrote:
>
> > I'm afraid I don't understand, but it sounds delicate.  By all means try!
> >
> > Simon
> >
> > On Mon, 25 Jul 2022 at 11:04, ÉRDI Gergő  wrote:
> >   On Mon, 25 Jul 2022, Simon Peyton Jones wrote:
> >
> >   >   Do we have an existing way of substituting types over type
> >   variables, *in
> >   >   HsType instead of Core Type*?
> >   >
> >   >
> >   > I'm afraid not. Currently HsType is not processed much -- just
> renamed
> >   and typechecked
> >   > into a Type.
> >
> >   I wonder if, instead, I could expand the rhs, typecheck it
> "abstractly"
> >   (i.e. in the context of the synonym's binders), and THEN do the
> >   substitution. If I typecheck the rhs for every occurrence, I
> should get
> >   fresh metavars for each wildcard, which is pretty much what I
> want. I just
> >   have to make sure I don't zonk before the substitution.
> >
> >   Does this make sense?
> >
> >
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Wildcards in type synonyms

[Simon Peyton Jones]

>
> It sounds awfully special-case to store these type macros in a new field
> of `TcGblEnv` instead of as just another kind of `TyCon`.
>

But all this is just in your personal fork of GHC, so you can be as
special-case as you like.  I'd just plough ahead and do the easiest thing.
If you make a proposal, and persuade the committee, we can look again.
Until then it's probably not worth us spending a lot of time making the
implementation beautiful.

Simon

On Tue, 26 Jul 2022 at 04:14, ÉRDI Gergő  wrote:

> On Mon, 25 Jul 2022, Richard Eisenberg wrote:
>
> > I see this substitution as happening before any type-checking, so
> zonking shouldn't be an issue. That is, I would expect a
> >
> > substHsTy :: UniqFM Name (HsType GhcRn) -> HsType GhcRn -> HsType GhcRn
> >
> > to do the work, entirely before type-checking.
>
> If I were to do this fully during renaming, how do I even find out that a
> `Name` refers to a type macro? During typechecking I can look up the
> `TyThing`,
> see if it's a `MacroTyCon`, and get the rhs from that. But I don't think
> we store
> anything about already-renamed declarations during renaming the same way
> we store info about already-typechecked things during typechecking in
> `tcg_type_env`.
>
> It sounds awfully special-case to store these type macros in a new field
> of `TcGblEnv` instead of as just another kind of `TyCon`.
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Wildcards in type synonyms

[Simon Peyton Jones]

>
> Do we have an existing way of substituting types over type variables, *in
> HsType instead of Core Type*?
>

I'm afraid not. Currently HsType is not processed much -- just renamed and
typechecked into a Type.

The nearest we have is Note [Handling overloaded and rebindable
constructs], in the renamer.  That doesn't do what you want, but the
HsExpansion idea is close

S

On Mon, 25 Jul 2022 at 10:18, ÉRDI Gergő  wrote:

> On Fri, 22 Jul 2022, Simon Peyton Jones wrote:
>
> >   So it seems that instead of shoehorning it into the existing type
> >   synonyms, a better bet would be to branch off to a separate path
> quite
> >   early (maybe as soon as during renaming), expand them during
> >   typechecking, and *not* touch how/when existing "normal" type
> synonyms
> >   are resolved.
> >
> >
> > That sounds plausible, yes.
>
> Do we have an existing way of substituting types over type variables, *in
> HsType instead of Core Type*?
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Wildcards in type synonyms

[Simon Peyton Jones]

>
> So it seems that instead of shoehorning it into the existing type
> synonyms, a better bet would be to branch off to a separate path quite
> early (maybe as soon as during renaming), expand them during
> typechecking, and *not* touch how/when existing "normal" type synonyms
> are resolved.
>

That sounds plausible, yes.

Simon

On Fri, 22 Jul 2022 at 09:50, Gergő Érdi  wrote:

> Thanks Simon, these are very useful hints. My plan is to just push
> ahead on a separate fork, with this "macro semantics", and maybe if it
> comes out nicer than I'd hope, I'll propose it.
>
> So it seems that instead of shoehorning it into the existing type
> synonyms, a better bet would be to branch off to a separate path quite
> early (maybe as soon as during renaming), expand them during
> typechecking, and *not* touch how/when existing "normal" type synonyms
> are resolved.
>
> On Fri, Jul 22, 2022 at 4:14 PM Simon Peyton Jones
>  wrote:
> >
> > Hi Gergo
> >
> >> I'd like to implement type synonyms containing wildcards. The idea is
> >> that if you have `type MySyn a = MyType a _ Int`, then during
> >> typechecking, every occurrence of `MySyn T` would be expanded into
> >> `MyType T w123 Int`, with a fresh type (meta)variable `w123`.
> >
> >
> > I imagine you mean that if you then write
> > f :: MySyn a -> a -> Int
> > then it's exactly as if you wrote (using PartialTypeSignatures)
> > f :: MyType a _ Int -> a -> Int
> > today.   So if I understand it right, you intend that these type
> synonyms are second-class citizens: they can occur precisely (and only)
> where wildcards are allowed to occur today.  For example, as Iavor
> suggests, you'd reject
> > data T a = MkT (MySyn a)
> >
> > If you want to do this in a fork of GHC, that's obviously fine. If you
> want to offer it as a language extension, the best thing would be to write
> a GHC Proposal.  Also you'd get a lot of useful design feedback that way,
> which might save you implementation cycles.
> >
> >> What is the reason for this? I would have expected type synonyms to be
> >> only relevant during typechecking, and then fully resolved in the
> >> elaborated Core output.
> >
> >
> > In GHC an Id has only one type.   It does not have a "source type" and a
> "Core type".  So we allow Core types to contain synonyms so that when we
> export that Id the importing scope (e.g. GHCi, and type error messages) can
> see it.  Synonyms can also allow types to take less space. E.g.  we have
> Type, where (if we fully expanded) we'd have to have (TYPE LiftedRep).  One
> could imagine a different design.
> >
> > I would expect that, by the time typechecking is over, all your wildcard
> synonyms are gone.  They really are second class.
> >
> > Just to mention too that the entire "wildcards in type signatures" story
> is (I think) jolly useful, but it also turned out to be pretty tricky to
> implement.  If you just macro-expand your new synonyms, you won't disturb
> the wildcard story, but I just wanted to advertise that it's a tricky area.
> >
> > Simon
> >
> > On Fri, 22 Jul 2022 at 07:30, ÉRDI Gergő  wrote:
> >>
> >> Hi,
> >>
> >> I'd like to implement type synonyms containing wildcards. The idea is
> >> that if you have `type MySyn a = MyType a _ Int`, then during
> >> typechecking, every occurrence of `MySyn T` would be expanded into
> >> `MyType T w123 Int`, with a fresh type (meta)variable `w123`.
> >>
> >> One worrying thing I noticed in my initial exploration of the GHC
> >> codebase is that the Core representation of `Type`s can still contain
> >> type synonym occurrences. And this doesn't seem like just an artefact
> >> of sharing the `Type` representation with `TcType`, since the
> >> `coreView` function also has code to look through type synonyms.
> >>
> >> What is the reason for this? I would have expected type synonyms to be
> >> only relevant during typechecking, and then fully resolved in the
> >> elaborated Core output. If that were the case, then a new version of
> >> `expand_syn` could live in `TcM` and take care of making these fresh
> >> metavariables.
> >>
> >> Beside this concrete question, taking a step back, I would also like
> >> to hear from people who know their way around this part of GHC, what
> >> they think about this and how they'd approach implementing it.
> >>
> >> Thanks,
> >>  Gergo
> >> ___
> >> 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: Wildcards in type synonyms

[Simon Peyton Jones]

Hi Gergo

I'd like to implement type synonyms containing wildcards. The idea is
> that if you have `type MySyn a = MyType a _ Int`, then during
> typechecking, every occurrence of `MySyn T` would be expanded into
> `MyType T w123 Int`, with a fresh type (meta)variable `w123`.
>

I imagine you mean that if you then write
f :: MySyn a -> a -> Int
then it's exactly as if you wrote (using PartialTypeSignatures)
f :: MyType a _ Int -> a -> Int
today.   So if I understand it right, you intend that these type synonyms
are second-class citizens: *they can occur precisely (and only) where
wildcards are allowed to occur today*.  For example, as Iavor suggests,
you'd reject
data T a = MkT (MySyn a)

If you want to do this in a fork of GHC, that's obviously fine. If you want
to offer it as a language extension, the best thing would be to write a GHC
Proposal.  Also you'd get a lot of useful design feedback that way, which
might save you implementation cycles.

What is the reason for this? I would have expected type synonyms to be
> only relevant during typechecking, and then fully resolved in the
> elaborated Core output.
>

In GHC *an Id has only one type*.   It does not have a "source type" and a
"Core type".  So we allow Core types to contain synonyms so that when we
export that Id the importing scope (e.g. GHCi, and type error messages) can
see it.  Synonyms can also allow types to take less space. E.g.  we have
Type, where (if we fully expanded) we'd have to have (TYPE LiftedRep).  One
could imagine a different design.

I would expect that, by the time typechecking is over, all your wildcard
synonyms are gone.  They really are second class.

Just to mention too that the entire "wildcards in type signatures" story is
(I think) jolly useful, but it also turned out to be pretty tricky to
implement.  If you just macro-expand your new synonyms, you won't disturb
the wildcard story, but I just wanted to advertise that it's a tricky area.

Simon

On Fri, 22 Jul 2022 at 07:30, ÉRDI Gergő  wrote:

> Hi,
>
> I'd like to implement type synonyms containing wildcards. The idea is
> that if you have `type MySyn a = MyType a _ Int`, then during
> typechecking, every occurrence of `MySyn T` would be expanded into
> `MyType T w123 Int`, with a fresh type (meta)variable `w123`.
>
> One worrying thing I noticed in my initial exploration of the GHC
> codebase is that the Core representation of `Type`s can still contain
> type synonym occurrences. And this doesn't seem like just an artefact
> of sharing the `Type` representation with `TcType`, since the
> `coreView` function also has code to look through type synonyms.
>
> What is the reason for this? I would have expected type synonyms to be
> only relevant during typechecking, and then fully resolved in the
> elaborated Core output. If that were the case, then a new version of
> `expand_syn` could live in `TcM` and take care of making these fresh
> metavariables.
>
> Beside this concrete question, taking a step back, I would also like
> to hear from people who know their way around this part of GHC, what
> they think about this and how they'd approach implementing it.
>
> Thanks,
>  Gergo
> ___
> 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: GHC development asks too much of the host system

[Simon Peyton Jones]

This is a great thread.  I would love it to conclude with some concrete
actions, rather than just petering out.

I think one underexplored approach to addressing the build-time problem
> is to look not at the full-build time but rather look for common tasks
> where we could *avoid* doing a full build (e.g. updating documentation,
> typechecking `base`, running a "good enough" subset of the testsuite)
> and find ways to make those workflows more efficient.
>

This is a great example of a concrete step.

   - Identify common tasks
   - Write done the procedure for doing that task

I suspect that much waiting time is just because we are building too much.
e.g. if all you want to do is typeset Haddock docs, you probably don't need
the RTS build in threaded-debug way (or even at all).

As to the testsuite, 99% of them run fast.  If there are some slow culprits
that are causing genuine pain, let's identify them.

Simon

On Tue, 19 Jul 2022 at 20:11, Ben Gamari  wrote:

> Hécate  writes:
>
> > Hello ghc-devs,
> >
> > I hadn't made significant contributions to the GHC code base in a while,
> > until a few days ago, where I discovered that my computer wasn't able to
> > sustain running the test suite, nor handle HLS well.
> >
> > Whether it is my OS automatically killing the process due to oom-killer
> > or just the fact that I don't have a war machine, I find it too bad and
> > I'm frankly discouraged.
>
> Do you know which process was being killed? There is one testsuite tests
> that I know of which does have quite a considerable memory footprint
> (T16992) due to its nature; otherwise I would expect a reasonably recent
> machine to pass the testsuite without much trouble. It's particularly
> concerning if this is a new regression; is this the first time you have
> observed this particular failure?
>
> > This is not the first time such feedback emerges, as the documentation
> > task force for the base library was unable to properly onboard some
> > people from third-world countries who do not have access to hardware
> > we'd consider "standard" in western Europe or some parts of North
> > America. Or at least "standard" until even my standard stuff didn't cut
> > it anymore.
> >
> > So yeah, I'll stay around but I'm afraid I'm going to have to focus on
> > projects for which the feedback loop is not on the scale of hours , as
> > this is a hobby project.
> >
> > Hope this will open some eyes.
> >
> Hi Hécate,
>
> I would reiterate that the more specific feedback you can offer, the
> better.
>
> To share my some of my own experience: I have access to a variety of
> hardware,
> some of which is quite powerful. However, I find that I end up doing
> much of my development on my laptop which, while certainly not a slouch
> (being a Ryzen 4750U), is also not a monster. In particular, while a
> fresh build takes nearly twice as long on my laptop than some of the
> other hardware I have, I nevertheless find ways to make it worthwhile
> (due to the ease of iteration compared to ssh). If you routinely have
> multi-hour iteration times then something isn't right.
>
> In particular, I think there are a few tricks which make life far
> easier:
>
>
>  * Be careful about doing things that would incur
>significant amounts of rebuilding. This includes:
>
> * After modifying, e.g., `compiler/ghc.cabal.in` (e.g. to add a new
>   module to GHC), modify `compiler/ghc.cabal` manually instead of
>   rerunning `configure`.
>
> * Be careful about pulling/rebase. I generally pick a base commit to
>   build off of and rebase sparingly: Having to stop what I'm doing to
>   wait for full rebuild is an easy way to lose momentum.
>
> * Avoid switching branches; I generally have a GHC tree per on-going
>   project.
>
>  * Take advantage of Hadrian's `--freeze1` flag
>
>  * Use `hadrian/ghci` to typecheck changes
>
>  * Use the stage1 compiler instead of stage2 to smoke-test changes when
>possible. (specifically, using the script generated by Hadrian's
>`_build/ghc-stage1` target)
>
>  * Use the right build flavour for the task at hand: If I don't need a
>performant compiler and am confident that I can get by without
>thorough testsuite validation, I use `quick`. Otherwise, plan ahead
>for what you need (e.g. `default+assertions+debug_info` or
>`validate`)
>
>  * Run the fraction of the testsuite that is relevant to your change.
>Hadrian's `--test-way` and `--only` flags are your friends.
>
>  * Take advantage of CI. At the moment we have a fair amount of CI
>capacity. If you think that your change is close to working, you can
>open an MR and start a build locally. If it fails, iterate on just the
>failing testcases locally.
>
>  * Task-level parallelism. Admittedly, this is harder when you are
>working as a hobby, but I often have two or three projects on-going
>at a time. While one tree is building I try to make progress on
>another.
>
> I don't use HLS so 

Re: GHC development asks too much of the host system

[Simon Peyton Jones]

That's bad Hecate. We need GHC to be fun to work with, not a pain.

Can you be (much) more specific?  The more concrete the problem, the more
likely we can address it.

e.g. What if you don't use HLS?  Or maybe Hadrian is building much more
than you need? It would be super helpful to have more information.  There
may be things we can't reasonably address (e.g. make a small, light,
non-optimising compiler instead, throwing away most of the code base) but I
bet that sheer size isn't the only factor.

Thanks!

Simon

On Tue, 19 Jul 2022 at 17:21, Hécate  wrote:

> Hello ghc-devs,
>
> I hadn't made significant contributions to the GHC code base in a while,
> until a few days ago, where I discovered that my computer wasn't able to
> sustain running the test suite, nor handle HLS well.
>
> Whether it is my OS automatically killing the process due to oom-killer
> or just the fact that I don't have a war machine, I find it too bad and
> I'm frankly discouraged.
> This is not the first time such feedback emerges, as the documentation
> task force for the base library was unable to properly onboard some
> people from third-world countries who do not have access to hardware
> we'd consider "standard" in western Europe or some parts of North
> America. Or at least "standard" until even my standard stuff didn't cut
> it anymore.
>
> So yeah, I'll stay around but I'm afraid I'm going to have to focus on
> projects for which the feedback loop is not on the scale of hours , as
> this is a hobby project.
>
> Hope this will open some eyes.
>
> Cheers,
> Hécate
>
> --
> Hécate ✨
> : @TechnoEmpress
> IRC: Hecate
> WWW: https://glitchbra.in
> RUN: BSD
>
> ___
> 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

Hadrian problem

[Simon Peyton Jones]

I'm in a GHC tree, built with Hadrian, I'm getting this red problem.  But
compilation has got way past compiling base.

why is it looking in my .ghc/... directory?   It should be looking in my
build tree.

Simon

bash$ ~/code/HEAD-1/_build/ghc-stage1 -c Foo.hs
Loaded package environment from
/home/simonpj/.ghc/x86_64-linux-9.5.20220628/environments/default
: cannot satisfy -package-id base-4.17.0.0
(use -v for more information)

bash$ cat ~/code/HEAD-1/_build/ghc-stage1
"/home/simonpj/code/HEAD-1/_build/stage0/bin/ghc" "-no-global-package-db"
"-package-db /home/simonpj/code/HEAD-1/_build/stage1/lib/package.conf.d"
"$@"
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Hadrian

[Simon Peyton Jones]

OK.  So it's a bug.  Do we have an open Hadrian ticket to track it?  If
not, might you open one?

Make *already *no longer exists, incidentally.   Nowadays we need ghc-9.2
to build HEAD, and make doesn't work with ghc-9.2 for some reason.   So I
believe that make is dead for HEAD at least.

Simon

On Mon, 11 Jul 2022 at 16:36, Zubin Duggal  wrote:

> Yes, but as Sylvain noted, the configure step (which generates ghc.cabal
> and so is particularly sensitive to changes in module structure) is not
> tracked by hadrian at the moment. We could in principle fix this, and
> as also noted by Sylvain this will become much easier once Make no longer
> exists.
>
> On 22/07/11 16:25, Simon Peyton Jones wrote:
> >>
> >> It is advisable to do this after
> >> rebasing, especially if the rebase involves changes to the module
> >> structure or build system.
> >
> >
> >But *any* commit could involve such a change.  Isn't it a goal of Hadrian
> >to respond to, well, changes?   For example, it is clever enough to
> rebuild
> >Hadrian itself when it changes.
> >
> >It's a bit unsatisfying to say "it'll usually work, but if anything
> strange
> >happens, just make clean and try again".  Understandable perhaps, but not
> >satisfying.
> >
> >Simon
> >
> >On Mon, 11 Jul 2022 at 16:19, Sylvain Henry  wrote:
> >
> >> Hi Simon,
> >>
> >> You have to re-run `./configure` in cases like this. It's because
> >> `compiler/ghc.cabal` is generated from `compiler/ghc.cabal.in` by
> >> `./configure`. This isn't tracked by Hadrian.
> >>
> >> >Surely that should not happen? I'll try make clean; but isn't this a
> bug?
> >>
> >> Hopefully when `make` build system will be removed it should be easy to
> >> make Hadrian (instead of `./configure`) generate and track this file. In
> >> fact I already did this in a MR more than a year ago but it was blocked
> on
> >> make-removal.
> >>
> >> Sylvain
> >>
> >>
> >> On 11/07/2022 17:09, Simon Peyton Jones wrote:
> >>
> >> (apols for premature send)
> >>
> >> I am working on a branch of GHC, actually on !8210.  I have rebased on
> >> master.  Then I say
> >> hadrian/build
> >> and I get the log below.  It falls over saying
> >> No generator for _build/stage0/compiler/build/GHC/Unit/Module/Name.hs.
> >>
> >> Surely that should not happen?
> >>
> >> I'll try make clean; but isn't this a bug?
> >>
> >> Simon
> >>
> >> ___
> >> ghc-devs mailing listghc-devs@haskell.orghttp://
> 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
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Hadrian

[Simon Peyton Jones]

>
> It is advisable to do this after
> rebasing, especially if the rebase involves changes to the module
> structure or build system.


But *any* commit could involve such a change.  Isn't it a goal of Hadrian
to respond to, well, changes?   For example, it is clever enough to rebuild
Hadrian itself when it changes.

It's a bit unsatisfying to say "it'll usually work, but if anything strange
happens, just make clean and try again".  Understandable perhaps, but not
satisfying.

Simon

On Mon, 11 Jul 2022 at 16:19, Sylvain Henry  wrote:

> Hi Simon,
>
> You have to re-run `./configure` in cases like this. It's because
> `compiler/ghc.cabal` is generated from `compiler/ghc.cabal.in` by
> `./configure`. This isn't tracked by Hadrian.
>
> >Surely that should not happen? I'll try make clean; but isn't this a bug?
>
> Hopefully when `make` build system will be removed it should be easy to
> make Hadrian (instead of `./configure`) generate and track this file. In
> fact I already did this in a MR more than a year ago but it was blocked on
> make-removal.
>
> Sylvain
>
>
> On 11/07/2022 17:09, Simon Peyton Jones wrote:
>
> (apols for premature send)
>
> I am working on a branch of GHC, actually on !8210.  I have rebased on
> master.  Then I say
> hadrian/build
> and I get the log below.  It falls over saying
> No generator for _build/stage0/compiler/build/GHC/Unit/Module/Name.hs.
>
> Surely that should not happen?
>
> I'll try make clean; but isn't this a bug?
>
> Simon
>
> ___
> ghc-devs mailing 
> listghc-devs@haskell.orghttp://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: Hadrian

[Simon Peyton Jones]

 (apols for premature send)

I am working on a branch of GHC, actually on !8210.  I have rebased on
master.  Then I say
hadrian/build
and I get the log below.  It falls over saying
No generator for _build/stage0/compiler/build/GHC/Unit/Module/Name.hs.

Surely that should not happen?

I'll try make clean; but isn't this a bug?

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

Hadrian

[Simon Peyton Jones]

I am working on a branch of GHC, actually on !8210.  I have rebased on
master.  Then I say
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Type vs Constraint

[Simon Peyton Jones]

Dear GHC devs and Core Libraries folk

The tension between Type and Constraint (are they equal or not?) has
plaugued GHC for years.

This GHC proposal #518
 suggests how to
fix it.

Please do offer your thoughts.

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

Re: GitLab bullets

[Simon Peyton Jones]

Thank you.  Looks nice again!

S

On Fri, 10 Jun 2022 at 16:01, Ben Gamari  wrote:

> Simon Peyton Jones  writes:
>
> > Ben
> >
> > GitLab's rendering has become broken.  See this ticket
> > https://gitlab.haskell.org/ghc/ghc/-/issues/20686
> >
> >- look under "Common ground...".   The bullets all have a newline
> after
> >them
> >- Ditto the numbered points under "Generalisation"
> >- But some bullets under "Generalisation" are OK.
> >- Bullets have a handle that seems to let you drag the bullet around.
> >But if you do so, it messa up the format  completely!
> >
> > Ben, can you revert this Gitlab change?
> >
> Indeed I also noticed this. I sneakily updated to 15.0.2 this morning,
> which indeed seems to have fixed the regression.
>
> Do let me know if anything else looks amiss.
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GitLab bullets

[Simon Peyton Jones]

Ben

GitLab's rendering has become broken.  See this ticket
https://gitlab.haskell.org/ghc/ghc/-/issues/20686

   - look under "Common ground...".   The bullets all have a newline after
   them
   - Ditto the numbered points under "Generalisation"
   - But some bullets under "Generalisation" are OK.
   - Bullets have a handle that seems to let you drag the bullet around.
   But if you do so, it messa up the format  completely!

Ben, can you revert this Gitlab change?

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

Type vs Constraint

[Simon Peyton Jones]

Dear GHC devs and core libraries committee

Can I draw your attention to

https://gitlab.haskell.org/ghc/ghc/-/issues/21623

This ticket makes specific proposals for how to move forward on the
long-standing, and increasingly painful issue of *whether or not Constraint
and Type are equal in GHC's type system*.

We'd love to know what you think.  Please respond on the ticket.  The
changes affect only GHC internals, so we aren't planning a GHC proposal,
but the ticket is essentially a full proposal anyway.  It affects only GHC
internals, but there are some users who rely on GHC internals, which is why
we are seeking your opinions.

Thanks

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

Re: Extra file in GHC repo

[Simon Peyton Jones]

OK so I should delete the file -- and then the error should not re-occur,
correct?

thanks

Simon

On Fri, 13 May 2022 at 13:37, Matthew Pickering 
wrote:

> The docs/index.html used to be generated by configure (and now it's
> not). So you get this error when you have a dirty tree and try to
> checkout a newer commit where the generated version will get
> overwritten by the new non-generated version.
>
> Matt
>
> On Fri, May 13, 2022 at 11:46 AM Simon Peyton Jones
>  wrote:
> >
> > Hi devs
> >
> > I've started to get this a lot
> >
> > bash$ git rebase origin/master
> > First, rewinding head to replay your work on top of it...
> > error: The following untracked working tree files would be overwritten
> by checkout:
> > docs/index.html
> > Please move or remove them before you switch branches.
> > Aborting
> > fatal: Could not detach HEAD
> >
> > Removing docs/index.html makes things work again.  What am I doing wrong?
> >
> > 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

Extra file in GHC repo

[Simon Peyton Jones]

Hi devs

I've started to get this a lot

bash$ git rebase origin/master
First, rewinding head to replay your work on top of it...
error: The following untracked working tree files would be overwritten by
checkout:
docs/index.html
Please move or remove them before you switch branches.
Aborting
fatal: Could not detach HEAD

Removing docs/index.html makes things work again.  What am I doing wrong?

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

Re: Gitlab problem

[Simon Peyton Jones]

Thanks.  It has mysteriously started working again now...   Sorry for the
noise.

Simon

On Tue, 10 May 2022 at 17:01, Matthew Pickering 
wrote:

> Hi Simon,
>
> I can't reproduce this locally.. still broken for you?
>
> Matt
>
> On Tue, May 10, 2022 at 4:32 PM Simon Peyton Jones
>  wrote:
> >
> > Friends
> >
> > I am abruptly unable to push or pull to the GHC repo.  E.g. 'git fetch'
> just hangs.
> >
> > Yet ssh g...@gitlab.haskell.org seems to succeed with
> > PTY allocation request failed on channel 0
> > Welcome to GitLab, @simonpj!
> > Connection to gitlab.haskell.org closed.
> >
> > How could I debug this?  I'm on WSL.  My network appears to be fine.
> >
> > Thanks.  I'm totally stalled.
> >
> > 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

Gitlab problem

[Simon Peyton Jones]

Friends

I am abruptly unable to push or pull to the GHC repo.  E.g. 'git fetch'
just hangs.

Yet ssh g...@gitlab.haskell.org seems to succeed with
PTY allocation request failed on channel 0
Welcome to GitLab, @simonpj!
Connection to gitlab.haskell.org closed.

How could I debug this?  I'm on WSL.  My network appears to be fine.

Thanks.  I'm totally stalled.

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

Re: [External] Re: Specialising NOINLINE functions

[Simon Peyton Jones]

>
> I can look into this, sure, but it wouldn’t exactly solve my original
> problem, which is that I would like to turn this on wholesale, not
> definition by definition.
>

What is "this" that you want to turn on, precisely?

why would I ever not want to specialize a definition
>

I think the only downside is compilation time and code bloat.


I think you are concerned about cross-module specialisation.  There are two
things in play:

   1. Whether the defining module exposes the definition
   2. Whether the importing module specialises the thus-exposed definition

For (1) there are two choices:

   - (1a) Currently INLINEABLE captures the RHS of the function *exactly as
   the user wrote it*, and allows that to be specialised.
   - (1b) On the other hand, -fexpose-all-unfoldings does not attempt to
   capture the functions the user wrote; instead, it exposes the
*post-optimisation
   *RHSs of all functions, regardless of per-function pragmas.

I believe that (1b) is closer to what you want.

For (2) one might wonder whether to

   - (2a) specialise every imported (type-class-overloaded) function whose
   unfolding we can see
   - (2b) specialise only imported functions with a SPECIALISABLE pragma
   - (2c) specialise imported functions only with -fspecialise-aggressively

I think GHC currently does (2c).

Maybe this taxonomy helps you a bit?

Simon

On Mon, 9 May 2022 at 02:38, Erdi, Gergo  wrote:

> PUBLIC
>
>
>
> I can look into this, sure, but it wouldn’t exactly solve my original
> problem, which is that I would like to turn this on wholesale, not
> definition by definition. It seems that all past discussion about this was
> in the context of a per-definition pragma (and sadly, a large part of that
> was bikeshedding over the name of the pragma…). But is the reason for that
> spelled out explicitly somewhere? In other words, what is the cost of
> specialisation, why would I ever not want to specialize a definition
> (inlinable or not)? I’d like to understand this first before reviving the
> proposal.
>
>
>
> *From:* ghc-devs  *On Behalf Of *Simon
> Peyton Jones
> *Sent:* Friday, May 6, 2022 5:26 PM
> *To:* Oleg Grenrus ; ÉRDI Gergő 
> *Cc:* GHC developers 
> *Subject:* [External] Re: Specialising NOINLINE functions
>
>
>
> There is a (stale) ghc-proposal for that,
> https://github.com/ghc-proposals/ghc-proposals/pull/357
> <https://clicktime.symantec.com/3NuNFMzg65dA5k5kXHX5U196xU?u=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F357>
>
>
>
> So there is!  Thank you.
>
>
>
> Gergo: would you like to take over this proposal, revise it if necessary
> in the light of the comments, and submit it?
>
>
>
> Simon
>
>
>
> On Fri, 6 May 2022 at 10:08, Oleg Grenrus  wrote:
>
> There is a (stale) ghc-proposal for that,
> https://github.com/ghc-proposals/ghc-proposals/pull/357
> <https://clicktime.symantec.com/3NuNFMzg65dA5k5kXHX5U196xU?u=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F357>
>
> - Oleg
>
> On 6.5.2022 12.04, Simon Peyton Jones wrote:
> > Dear devs
> >
> > At the moment the INLINEABLE pragma means "capture my right-hand side,
> > regardless of how big it is, so that it can be type-class-specialised,
> > including in other modules".  But it /also /says "feel free to inline
> me".
> >
> > Some users (eg Gergo) want to say NOINLINE on some functions. But for
> > these they'd still like to generate type-class-specialised versions.
> > After all, if we aren't going to inline them, specialising is the next
> > best thing.
> >
> > But we have no way to say both "specialise me" and "don't inline me",
> > because you can't say both INLINEABLE and NOINLINE.  (That would look
> > silly.)
> >
> > I think we should probably just bite the bullet and add a
> > SPECIALISABLE pragma, /orthogonal to INLINE/NOINLNE/, which say
> > "capture my right-hand side, regardless of how big it is, so that it
> > can be type-class-specialised, including in other modules".  It
> > behaves exactly like INLINEABLE except that  you can specify it along
> > with INLINE/NOINLINE.
> >
> > Any thoughts?  Do you think this needs a GHC proposal?
> >
> > See #21036 <
> https://gitlab.haskell.org/ghc/ghc/-/issues/21036#note_407930
> <https://clicktime.symantec.com/3SB6vTf6r7gWFXH7FGMko9a6xU?u=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F21036%23note_407930>
> >
> >
> >
> > Simon
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/

Re: Specialising NOINLINE functions

[Simon Peyton Jones]

>
> There is a (stale) ghc-proposal for that,
> https://github.com/ghc-proposals/ghc-proposals/pull/357
>

So there is!  Thank you.

Gergo: would you like to take over this proposal, revise it if necessary in
the light of the comments, and submit it?

Simon

On Fri, 6 May 2022 at 10:08, Oleg Grenrus  wrote:

> There is a (stale) ghc-proposal for that,
> https://github.com/ghc-proposals/ghc-proposals/pull/357
>
> - Oleg
>
> On 6.5.2022 12.04, Simon Peyton Jones wrote:
> > Dear devs
> >
> > At the moment the INLINEABLE pragma means "capture my right-hand side,
> > regardless of how big it is, so that it can be type-class-specialised,
> > including in other modules".  But it /also /says "feel free to inline
> me".
> >
> > Some users (eg Gergo) want to say NOINLINE on some functions. But for
> > these they'd still like to generate type-class-specialised versions.
> > After all, if we aren't going to inline them, specialising is the next
> > best thing.
> >
> > But we have no way to say both "specialise me" and "don't inline me",
> > because you can't say both INLINEABLE and NOINLINE.  (That would look
> > silly.)
> >
> > I think we should probably just bite the bullet and add a
> > SPECIALISABLE pragma, /orthogonal to INLINE/NOINLNE/, which say
> > "capture my right-hand side, regardless of how big it is, so that it
> > can be type-class-specialised, including in other modules".  It
> > behaves exactly like INLINEABLE except that  you can specify it along
> > with INLINE/NOINLINE.
> >
> > Any thoughts?  Do you think this needs a GHC proposal?
> >
> > See #21036 <
> https://gitlab.haskell.org/ghc/ghc/-/issues/21036#note_407930>
> >
> >
> > 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
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Specialising NOINLINE functions

[Simon Peyton Jones]

Dear devs

At the moment the INLINEABLE pragma means "capture my right-hand side,
regardless of how big it is, so that it can be type-class-specialised,
including in other modules".  But it *also *says "feel free to inline me".

Some users (eg Gergo) want to say NOINLINE on some functions. But for these
they'd still like to generate type-class-specialised versions.  After all,
if we aren't going to inline them, specialising is the next best thing.

But we have no way to say both "specialise me" and "don't inline me",
because you can't say both INLINEABLE and NOINLINE.  (That would look
silly.)

I think we should probably just bite the bullet and add a SPECIALISABLE
pragma, *orthogonal to INLINE/NOINLNE*, which say "capture my right-hand
side, regardless of how big it is, so that it can be
type-class-specialised, including in other modules".  It behaves exactly
like INLINEABLE except that  you can specify it along with INLINE/NOINLINE.

Any thoughts?  Do you think this needs a GHC proposal?

See #21036 


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

Re: Extending call_args when specialising DFuns

[Simon Peyton Jones]

Looking at the code in Specialise, there are only two differences in the
way that UnspecArg and UnspecType are treated differently:
* In specHeader, small differences
* In ppr_call_key_ty, when generating the name of the RULE

So we could collapse them into SpecArg, and fix the small differences some
other way.

But 'd have thought it was easier just to get the right SpecArg/SpecType
for the padding for DFuns.  That's not hard. Something like
```
do { let all_call_args | is_dfun   = call_args ++ map
mk_extra_dfun_arg (dropList call_args rhs_bndrs)
   | otherwise = call_args
   -- See Note [Specialising DFuns]
  mk_extra_dfun_arg bndr  | isTyVar bndrs = UnspecType
   | otherwise
= UnspecArg
 ```
This is really a GHC bug already, albeit one that is hard to provoke.
Would you like to open a ticket and add the fix?

Simon

On Sat, 30 Apr 2022 at 10:27, ÉRDI Gergő  wrote:

> Hi,
>
> In GHC.Core.Opt.Specialise.specCalls, when specialising a DFun call, GHC
> extends the call_args with dummy UnspecArg elements, to make it trivially
> fully saturated. There's a Note describing this behaviour:
>
> """
> Note [Specialising DFuns]
> ~
> DFuns have a special sort of unfolding (DFunUnfolding), and these are
> hard to specialise a DFunUnfolding to give another DFunUnfolding
> unless the DFun is fully applied (#18120).  So, in the case of DFunIds
> we simply extend the CallKey with trailing UnspecArgs, so we'll
> generate a rule that completely saturates the DFun.
>
> There is an ASSERT that checks this, in the DFunUnfolding case of
> GHC.Core.Unfold.specUnfolding.
> """
>
> (note that the reference in the second paragraph is stale; it should point
> to GHC.Core.Unfold.Make.specUnfolding)
>
> So my question is, why UnspecArgs instead of UnspecTypes? Unless I'm
> missing something, a DFun can't have any term parameters, only type and
> dictionary ones. Changing the padding from UnspecArg to UnspecType doesn't
> break validate, which suggests that it is hard to even exercise this code
> path.
>
> I'm bringing this up because on the GHC fork that I'm working on, I have
> the specializer do more than vanilla GHC: on my fork, specialization of
> higher-kinded type variables is just as useful as specializing
> dictionaries. With that change, I can get GHC panics when padding DFun
> calls with UnspecArgs, but not when padding with UnspecTypes. Yes, this is
> a very weak argument for this change; what I'm looking for here is a
> discussion on what the padding should be, in vanilla GHC, from first
> principles.
>
> Thanks,
> Gergo
> ___
> 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: Markup language/convention for Notes?

[Simon Peyton Jones]

I'm open-minded, but I *really* want the text to be readily readable *in
the original source file*.  So
* Back-ticks are much better than `@` signs; the latter are too noisy.
* For code, backticks add clutter.  Maybe just intentend text can be
code?   (Unless it's part of a bulleted list.)


On Wed, 13 Apr 2022 at 21:45, Ben Gamari  wrote:

> "Sebastian Graf"  writes:
>
> > Hi Devs,
> >
> > When writing Notes, I find myself using markdown-inspired or
> > haddock-inspired features. The reason is that I keep telling myself
> >
> > > In 5 years time, we'll surely have an automated tool that renders
> > > Notes referenced under the cursor in a popup in our IDE
> >
>
> I tell myself a similar tale. true. In particular, I would like to see
> Haddock gain support for Note-like documentation. When I wrote the Note
> linter I was surprised by how simple and robust the parser was despite
> the rather ad-hoc choice of syntax. This makes me hopeful that this goal
> can be realized.
>
> Concretely, I suspect that something like
> https://github.com/haskell/haddock/issues/193 might be a reasonable
> approximation of what we need.
>
> > And I might not be completely wrong about that, after all the strong
> > conventions about Note declaration syntax allow me to do
> > jump-to-definition on Note links in my IDE already (thanks to a shell
> > script written by Zubin!).
> >
> > Still, over the years I kept drifting between markdown and haddock
> > syntax, sometimes used `backticked inline code` or haddock 'ticks' to
> > refer to functions in the compiler (sometimes even
> > 'GHC.Fully.Qualified.ticks') and for code blocks I used all of the
> > following forms:
> >
> I am quite guilty of the same.
>
> > I know that at least Simon was thrown off in the past about my use of
> > "tool-aware markup", perhaps also because I kept switching the targetted
> > tool. I don't like that either. So I wonder
> > Do you think it is worth optimising Notes for post-processing by an
> > external tool?I think it's only reasonable if we decide for a target
> > syntax. Which syntax should it be?
>
> Yes, we should decide on a direction and document it. My sense is that
> Haddock is probably the best option when it comes to integrating with
> "normal" Haskell workflows. Happily, backticks are valid Haddock syntax
> so at least this particular bit of muscle-memory can be retained [1].
>
> Incidentally, I suspect that ```-style code blocks would be a
> valuable addition to Haddock for syntax-highlighted blocks of code in
> languages other than Haskell.
>
> On the other hand, there is talk [2] of Haddock gaining a Markdown
> frontend, so Markdown may be more of a viable option than I'm giving it
> credit for.
>
> Cheers,
>
> - Ben
>
>
> [1]
> https://haskell-haddock.readthedocs.io/en/latest/markup.html#hyperlinked-identifiers
> [2] https://github.com/haskell/haddock/issues/794#issuecomment-1018884773
> ___
> 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: Re: Shadowing in toIface* output

[Simon Peyton Jones]

>
> OK, I must be doing something wrong then. I am now looking at Tidy (not
> Prep) output, and I see Core like this:
>
>
>
>   showsPrec :: forall a. Show a => Int -> a -> ShowS
>
>   [GblId[ClassOp],
>
>Arity=1,
>
>Caf=NoCafRefs,
>
>Str=,
>
>RULES: Built in rule for showsPrec: "Class op showsPrec"]
>
>   showsPrec
>
> = \ (@a_a1G3) (v_B1 :: Show a_a1G3) ->
>
> case v_B1 of v_B1 { C:Show v_B2 v_B3 v_B4 -> v_B2 }
>
>
>
> so if I’m reading this right, these vs are still shadowing.
>

That looks very odd.  If that gets serialised into a .hi file it won't work
at all.

If you can repro this with GHC, can you open a ticket for it.

It is true (as I discovered when spelunking as a result of this thread)
that Tidy does not tidy the "implicit bindings"  See this code in
GHC.Iface.Tidy:

  -- See Note [Injecting implicit bindings]
  all_tidy_binds = implicit_binds ++ tidy_binds'

I think we must be assuming (without documenting it) that implicit_binds
already satisfies the (undocumented) output invariants of Tidy.

See https://gitlab.haskell.org/ghc/ghc/-/issues/21333, where I suggest
improving this documentation, incl this implicit_binds assumption.  Zubin
may be doing this.

I can't account for what you are seeing though.

Simon

On Tue, 5 Apr 2022 at 05:08, Erdi, Gergo  wrote:

> PUBLIC
>
>
>
> Ah, it seems Tidy doesn’t traverse the bindings that are created for
> typeclass methods. I guess the idea is that I should be able to recreate
> them from the typeclass declaration? So how do I know 1. which bindings
> exactly should be saved to reconstruct my original full desugared module
> and 2. How do I fill in these missing pieces during reconstruction?
>
>
>
>
>
>
>
> *From:* ghc-devs  *On Behalf Of *Erdi,
> Gergo via ghc-devs
> *Sent:* Tuesday, April 5, 2022 11:09 AM
> *To:* Simon Peyton Jones ; Gergo Érdi <
> ge...@erdi.hu>
> *Cc:* GHC Devs 
> *Subject:* [External] RE: Re: Shadowing in toIface* output
>
>
>
> OK, I must be doing something wrong then. I am now looking at Tidy (not
> Prep) output, and I see Core like this:
>
>
>
>   showsPrec :: forall a. Show a => Int -> a -> ShowS
>
>   [GblId[ClassOp],
>
>Arity=1,
>
>Caf=NoCafRefs,
>
>Str=,
>
>RULES: Built in rule for showsPrec: "Class op showsPrec"]
>
>   showsPrec
>
> = \ (@a_a1G3) (v_B1 :: Show a_a1G3) ->
>
> case v_B1 of v_B1 { C:Show v_B2 v_B3 v_B4 -> v_B2 }
>
>
>
> so if I’m reading this right, these vs are still shadowing.
>
>
>
> I am using tidyProgram on the output of hscSimplify, and then taking the
> cg_binds of its result. What else should I do to get tidy (heh) Tidy
> output?
>
>
>
>
>
> *From:* ghc-devs  *On Behalf Of *Simon
> Peyton Jones
> *Sent:* Monday, April 4, 2022 4:28 PM
> *To:* Gergő Érdi 
> *Cc:* GHC Devs 
> *Subject:* [External] Re: Shadowing in toIface* output
>
>
>
> So does that mean Tidy produces unique `occNameFS`s, and then `Prep`
> breaks them?
>
>
>
> Tidy does not produce unique OccNames.  Rather, it avoids *shadowing*, so
> that if you delete all the uniques and print out the program (which is
> precisely what happens in an .hi file) you'll still get something sensible.
>
>
>
> I'm not sure whether or not Prep maintains this invariant.  There is no
> particular reason it should.  It might, but it is not (currently) a goal.
>
>
>
> Simon
>
>
>
> On Sat, 2 Apr 2022 at 04:35, Gergő Érdi  wrote:
>
> So does that mean Tidy produces unique `occNameFS`s, and then `Prep`
> breaks them?
>
> On Fri, Apr 1, 2022 at 10:35 PM Josh Meredith
>  wrote:
> >
> > Hi,
> >
> > I encountered this when we used that for Plutus. I'll have to dig up the
> details, but IIRC `toIfaceExpr` expects GHC to have already tidied the
> output, which deals with this issue of overlapping variable names.
> >
> > Cheers,
> > Josh
> >
> > On Sat, 2 Apr 2022 at 01:26, ÉRDI Gergő  wrote:
> >>
> >> Hi,
> >>
> >> I'm trying to save (Prep'd) Core bindings right next to the serialized
> >> `ModIface` (so basically `put_`ing them into the same bytestream, after
> the
> >> `ModIface`), and that's exactly what the functions in `GHC.CoreToIface`
> >> seem to be for, so I expected it to Just Work. However, I noticed that I
> >> very frequently get problems with shadowing. For example, Core that
> looks
> >> like `\v{u1} v{u2} -> v{u1}` would get translated to `\v v -> v`, which
> is
> >> disastrous since thes

Re: Git problem

[Simon Peyton Jones]

Thanks Viktor -- I'll try that

Simon

On Thu, 7 Apr 2022 at 01:37, Viktor Dukhovni  wrote:

> On Wed, Apr 06, 2022 at 10:55:09PM +0100, Simon Peyton Jones wrote:
>
> > I see this
> > bash$ git status
> > On branch wip/romes/ttg-splices-improvements
> > Your branch is up to date with
> 'origin/wip/romes/ttg-splices-improvements'.
> >
> > modified   libraries/Cabal
> > +Subproject commit d638e33dbc056048b393964286c7fe394b2730d7-dirty
> > modified   libraries/unix
> > +Subproject commit 1f72ccec55c1b61299310b994754782103a617f5-dirty
> >
> > How can I get my submodules in sync with this branch?
>
> ( cd libraries/Cabal && { git clean -xdf .; git checkout .; } )
> ( cd libraries/unix && { git clean -xdf .; git checkout .; } )
>
> --
> Viktor.
> ___
> 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: Warning about glomming

[Simon Peyton Jones]

It's a warning directed solely at compiler authors (hence -DDEBUG).  If a
lot of glomming is happening, it might be due to some scoping or dependency
analysis bug -- e.g. perhaps OccAnal isn't putting bindings in proper
dependency order, or perhaps some plugin is gratuitously scrambling the
order of the top level definitions.   Or it might be legitimate, as in your
case.

Perhaps adding a Note with the code that generates the warning (or wherever
you looked -- where was that?) would be better.  I always like to look for
ways to reply not just to Gergo but to all the future Gergos who stumble
over this.

Gergo might you offer a patch?

Simon

On Thu, 7 Apr 2022 at 07:47, Gergő Érdi  wrote:

> Using -DDEBUG, I see a warning about glomming from OccurAnal. Having
> read the relevant Note, the situation is exactly what's described
> here: since I'm using cross-module specializations, the specializer
> will generate rewrite rules that replace external references with
> local forward references.
>
> But the one thing the Note doesn't explicitly state is why this is
> reported as a warning. It sounds like OccurAnal is well equipped to
> fix this problem. So is glomming a sign of a problem or is it not? If
> I see that warning, does that point to a problem in how I use the GHC
> API, a problem in the code that I'm trying to compile, or neither?
> ___
> 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

Git problem

[Simon Peyton Jones]

Friends

I see this
bash$ git status
On branch wip/romes/ttg-splices-improvements
Your branch is up to date with 'origin/wip/romes/ttg-splices-improvements'.

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)
modified:   libraries/Cabal (modified content)
modified:   libraries/unix (modified content)

But I don't want those library changes, whatever they are.  They look like
Unstaged changes (2)
modified   libraries/Cabal
@@ -1 +1 @@
-Subproject commit d638e33dbc056048b393964286c7fe394b2730d7
+Subproject commit d638e33dbc056048b393964286c7fe394b2730d7-dirty
modified   libraries/unix
@@ -1 +1 @@
-Subproject commit 1f72ccec55c1b61299310b994754782103a617f5
+Subproject commit 1f72ccec55c1b61299310b994754782103a617f5-dirty

*But using git submodule update does nothing.*

How can I get my submodules in sync with this branch?

Thanks

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

Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings

[Simon Peyton Jones]

OK.  As I said earlier, the 'OtherCon []' unfoldings are unexpected to me.
But if

   - We can't reproduce it without a lot of effort
   - It's not important to you any more

then let's just let it lie.

Simon

On Wed, 6 Apr 2022 at 08:51, Erdi, Gergo  wrote:

> PUBLIC
>
>
>
> Please see this question in my previous email:
>
>
>
>- Unfortunately, I am unable to reproduce this from the command line
>using the GHC executable, so before I put in the effort of making a minimal
>example of using the GHC API to get this result, I would first like to know
>if this is even an interesting case, or if there is some explanation for
>why one of these two would have an unfolding when the other doesn't, in
>certain cases.
>
>
>
> So I can NOT reproduce it with just a GHC command line, only with my
> program (that uses GHC as a library). So it will require extra effort to
> get something you or others can just run, hence my question: is there
> anything here that is worth pursuing at all? Or who cares, since I’m not
> using unfoldings anymore (I’ve switched over to storing IfaceExprs
> directly), and it works in GHC-the-program?
>
>
>
> *From:* Simon Peyton Jones 
> *Sent:* Wednesday, April 6, 2022 3:37 PM
> *To:* Erdi, Gergo 
> *Cc:* Gergo Érdi ; GHC Devs ;
> clash-langu...@googlegroups.com
> *Subject:* [External] Re: Avoiding `OtherCon []` unfoldings, restoring
> definitions from unfoldings
>
>
>
> Hi Gergo
>
>
>
> If you think GHC has a but, can you open a ticket about this?   It's all
> getting lost in a maze of emails.
>
>
>
> Can you also give precise repro instructions?  In an attempt to reproduce,
> I have just compiled this module (the code you gave)
>
>
>
> {-# OPTIONS_GHC -fexpose-all-unfoldings #-}
>
> module Foo where
>
> nonEmptySubsequences :: [a] -> [[a]]
> nonEmptySubsequences [] = []
> nonEmptySubsequences (x:xs) = [x] : foldr f [] (nonEmptySubsequences xs)
>where
>  f ys r = ys : (x:ys) : r
>
> subsequences:: [a] -> [[a]]
> subsequences xs =  [] : nonEmptySubsequences xs
>
>
>
> with HEAD, and -O.  Unlike you, I see both unfoldings in the interface
> file.  So clearly you and I are doing different things -- but I can't work
> out what is different without more precision about what you are doing.
> (It would be harder if it only happens when you use GHC as a library, but I
> think you are seeing this behaviour in regular GHC.)
>
>
>
> Thanks
>
>
>
> Simon
>
>
>
> On Wed, 6 Apr 2022 at 03:05, Erdi, Gergo  wrote:
>
> PUBLIC
>
> Just so this isn't prematurely all lost, I went back and looked for this
> example. With the following two definitions:
>
> subsequences:: [a] -> [[a]]
> subsequences xs =  [] : nonEmptySubsequences xs
>
> nonEmptySubsequences :: [a] -> [[a]]
> nonEmptySubsequences []  =  []
> nonEmptySubsequences (x:xs)  =  [x] : foldr f [] (nonEmptySubsequences xs)
>   where f ys r = ys : (x : ys) : r
>
> If I save the interface, load it back and look at the unfoldings, I see
> that `subsequences` has a useful unfolding:
>
>   subsequences Unf{Src=, TopLvl=True, Value=True,
>ConLike=True, WorkFree=True, Expandable=True,
>Guidance=IF_ARGS [0] 30 10}
>
> Whereas `nonEmptySubsequenes` has a trivial one:
>
> nonEmptySubsequences OtherCon []
>
> The interface I save is created from the ModDetails returned by
> tidyProgram. ExposeAllUnfoldings is set.
>
> Unfortunately, I am unable to reproduce this from the command line using
> the GHC executable, so before I put in the effort of making a minimal
> example of using the GHC API to get this result, I would first like to know
> if this is even an interesting case, or if there is some explanation for
> why one of these two would have an unfolding when the other doesn't, in
> certain cases.
>
> -Original Message-
> From: ghc-devs  On Behalf Of Gergo Érdi
> Sent: Saturday, April 2, 2022 11:31 AM
> To: Simon Peyton Jones 
> Cc: GHC Devs ; clash-langu...@googlegroups.com
> Subject: [External] Re: Avoiding `OtherCon []` unfoldings, restoring
> definitions from unfoldings
>
>
> I'm using Prep's output (mostly so that it's in ANF) in my full
> compilation pipeline, so ideally I would save Prep'd Core in my
> .hi-equivalents so that I don't have to rerun Prep on them every time I use
> them.
>
> I'll get back to you with some concrete examples of `OtherCon []` vs.
> meaningful unfoldings next week.
>
> Merging with my other question about shadowing problems with `toIface*`,
> in summary it seems that what I really shou