Re: success on a slightly modified version of your suggestion for 21506
that matches my experience, namely that i've successfully installed ghc 9.2.2 on osx 12.4 aka monterey a few times On Sun, Jul 24, 2022 at 12:59 PM George Colpitts wrote: > Hi Ben > > Thanks for the quick responses particularly on the weekend before your > vacation. > > you wrote: > > What happens > if you try to install to do something like (in the extracted binary > distribution), > > > $ ./configure --prefix=`pwd`/tmp > $ make install# this will fail > $ xattr -rc . > $ make install# perhaps this will finish successfully? > # tmp/bin/ghc --version # GHC should be usable > > > success on both my machines using a slightly modified version of your > suggestion above for 21506: > > ./configure --prefix=`pwd`/tmp# specifying ./tmp seems to be critical > > xattr -rc .# seems to be necessary > also > > sudo make install # seems to works , output ends > with "recache" > > ./tmp/bin/ghc --version # success , although admittedly > the smallest smoke test possible > > You wrote: > > > > Ultimately I think we may just need to bite the bullet and start > properly notarising/codesigning releases (resolving #17418). At this point > we have > spent more time trying to avoid the notarisation requirement than > it would likely take to satisfy it. Unfortunately, this will require > that I find an Apple device somewhere which may take a few weeks. > > > I'm afraid I am on holiday next week but I would quite grateful if we > could arrange for a chat after I return such that we can debug this in > realtime. > > > Sure, we can chat when you return from your vacation. > > Not sure if it is worth trying to fix the release on the basis of what I > write above. My opinion is: it is if we can get reports of at least one > other person having this issue. I am fine with not doing this for 9.4.1 > > I agree that we should raise the priority of "notarising/codesigning > releases (resolving #17418)". My opinion is that it is not worth delaying > 9.4.1 for this. > > Have a great vacation. > > Cheers > George > > > > > > > On Sun, Jul 24, 2022 at 11:33 AM Ben Gamari wrote: > >> George Colpitts writes: >> >> > +Kazu Yamamoto >> > >> > Hi Ben >> > >> > My 2 machines also have: >> > >> > $ spctl --status >> > assessments enabled >> > >> Hmm, interesting. Then I am truly perplexed. >> >> > Speculations: >> > >> > >> /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib >> > is created after xattr -rc . was run so it doesn't have the necessary >> > attributes. Is it possible that ghc developers and/or the test machines >> > have this file on another of the paths in the error message and that is >> why >> > it works for them? >> > >> I'm not sure where this would be but at this point anything is possible. >> What happens >> if you try to install to do something like (in the extracted binary >> distribution), >> >> $ ./configure --prefix=`pwd`/tmp >> $ make install# this will fail >> $ xattr -rc . >> $ make install# perhaps this will finish successfully? >> # tmp/bin/ghc --version # GHC should be usable >> >> > I hope I didn't offend you by asking if the fix had been tested; I >> assume >> > it had been but I thought it was important to rule that out. >> > >> Not to worry; it's a very reasonable question to ask given the >> circumstances. >> >> > More than happy to test. I really appreciate all the work you and others >> > have put into GHC ! >> > >> Ultimately I think we may just need to bite the bullet and start >> properly notarising/codesigning releases (resolving #17418). At this >> point we have >> spent more time trying to avoid the notarisation requirement than >> it would likely take to satisfy it. Unfortunately, this will require >> that I find an Apple device somewhere which may take a few weeks. >> >> I'm afraid I am on holiday next week but I would quite grateful if we >> could arrange for a chat after I return such that we can debug this in >> realtime. >> >> Cheers, >> >> - Ben >> > ___ > Glasgow-haskell-users mailing list > glasgow-haskell-us...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Wildcards in type synonyms
(TL;DR: `newMetaTyVarX` gives me type metavars that behave weirdly and I
don't understand why. What shoudl I use instead?)
OK so I have two half-done implementations now:
* Doing `HsType`-level substitution in the middle of `tc_infer_hs_type`
(see my exchange with Richard on why this needs to happen in
`tc_infer_hs_type` instead of `rnHsTyKi`)
* Doing Core `Type`-level substitution in the middle of `tc_infer_hs_type`
The advantage of the first one is that it works :) The disadvantage is
that it involves storing a `HsType` in a `TyCon`, which in turn means
making it work inter-module will require an `Iface` representation for
`HsType`s.
Hence the second attempt. I think that would be a more principled solution
anyway. This approach is based on typechecking the macro's right-hand side
into a core `Type`, and storing that, and the list of wildcard-originating
`TyVar`s, in the `TyCon`. At every occurrence site, I take this core
`Type` and apply a substitution on it that is the composition of the
following two:
* A substitution from macro type synonym type parameters to the type
arguments
* An instantiation of each wildcard variable into a fresh metavariable
Unfortunately, it is this second step that is tripping me up. If I use
`newMetaTyVarX` to make these "refreshing" metavars, then while the
substitution looks OK when eyeballing it, the resulting
*type* metavariables seem to be handled by GHC as if they were *kind*
metavariables?!
Here's an example. The source input is:
```
{-# LANGUAGE NoPolyKinds, NoStarIsType #-} -- Makes it easier to see how it
goes wrong
data MyData a b c = MkMyData a b c
type MySyn a = MyData a _ Int
f1 :: MyData a b c -> b
f1 (MkMyData _ x _) = x
f2 :: MySyn a -> Double
f2 = f1
```
I start with the following "macro type template" (using `-dppr-debug` format):
```
TySynWildcard.MyData{tc r3}
(a{tv auq} Nothing [sk:1] :: GHC.Types.Type{(w) tc 32Q})
((w_awX{tv} Nothing [tau:0] :: (k_awW{tv} Nothing [tau:0] ::
GHC.Types.Type{(w) tc 32Q}))
|> {(co_awY{v} Just 'GHC.Types.Many{(w) d 65I} [lid[CoVarId]] ::
GHC.Prim.~#{(w) tc 31I}
GHC.Types.Type{(w) tc 32Q}
GHC.Types.Type{(w) tc 32Q}
(k_awW{tv} Nothing [tau:0] :: GHC.Types.Type{(w) tc 32Q})
GHC.Types.Type{(w) tc 32Q})})
GHC.Types.Int{(w) tc 3u}
```
The substitution applied:
```
[TCvSubst
In scope: InScope {a{tv auu} k_awW{tv} w_axc{tv}}
Type env: [auq :-> (a{tv auu} Nothing [sk:2] :: (k_ax9{tv} Nothing [tau:2]
:: GHC.Types.Type{(w) tc 32Q})),
awX :-> (w_axc{tv} Nothing [tau:2] :: (k_awW{tv} Nothing
[tau:0] :: GHC.Types.Type{(w) tc 32Q}))]
Co env: []]
```
Note that the second type substitution, (w_awX :: k_awW) :-> (w_axc :: k_awW) is the
one that should take care of instantiating the wildcard metavariable. And
the result of applying this substitution still looks OK:
```
TySynWildcard.MyData{tc r3}
(a{tv auu} Nothing [sk:2] :: (k_ax9{tv} Nothing [tau:2] ::
GHC.Types.Type{(w) tc 32Q}))
((w_axc{tv} Nothing [tau:2] :: (k_awW{tv} Nothing [tau:0] ::
GHC.Types.Type{(w) tc 32Q}))
|> {(co_awY{v} Just 'GHC.Types.Many{(w) d 65I} [lid[CoVarId]] ::
GHC.Prim.~#{(w) tc 31I}
GHC.Types.Type{(w) tc 32Q}
GHC.Types.Type{(w) tc 32Q}
(k_awW{tv} Nothing [tau:0] :: GHC.Types.Type{(w) tc 32Q})
GHC.Types.Type{(w) tc 32Q})})
GHC.Types.Int{(w) tc 3u}
```
But soon after, typechecking fails:
```
• Couldn't match type ‘Type’ with ‘Double’
Expected: MyData a Type Int -> Double
Actual: MyData a Type Int -> Type
• In the expression: f1
In an equation for ‘f2’: f2 = f1
```
So this is weird. Instead of unification solving `w_axc ~ Double`, it
seems `w_axc` is left unrestricted, and then `NoPolyKinds` picks it up as
a kind variable (why?) and defaults it to `Type`.
As an experiment, I have also tried *not* refreshing `w_awX`, only
substituting in 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
