Re: Cannot build `master`, tries to use GHC 9.2?!
OK so it turns out there were two issues at play here: * I had `_build` as a symlink, and that's no bueno since Hadrian passes some relative paths like `_build/../libraries` to some command lines. This isn't ideal but is not a dealbreaker. * It turns out Hadrian recently was broken with regard to Hadrian-building vs. GHC-bootstrapping Haskell compilers. I've filed this as https://gitlab.haskell.org/ghc/ghc/-/issues/25076. On Wed, 10 Jul 2024, ÉRDI Gergő wrote: By playing around with GHC versions, Stack resolvers, and trying `hadrian/build` instead of `hadrian/build-stack`, I now got somewhat further: Error: hadrian: Missing dependency on a foreign library: * Missing (or bad) header file: HsBase.h But `HsBase.h` should come from the GHC source tree itself, right? So it's not an unresolved external dependency. It's very much possible that this is all because of some local configuration problem on my machine, but I'm still going to need some hints on where to even start looking. Thanks, Gerg On Mon, 8 Jul 2024, ÉRDI Gergő wrote: Hi, I'm trying to build GHC 5b1aefb70edbd54ac899896df39d8f3d6c579518 but I'm running into a weird problem. Using `hadrian/build-stack`, it fails quite early on with: | Run Ghc CompileCWithGhc (Stage0 GlobalLibs): utils/hsc2hs/cbits/utils.c => _build/stageBoot/utils/hsc2hs/build/c/cbits/utils.o Command line: ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stageBoot/inplace/package.conf.d' '-this-unit-id hsc2hs-0.68.10-inplace' '-this-package-name hsc2hs' '-package-id base-4.16.4.0' '-package-id containers-0.6.5.1' '-package-id directory-1.3.6.2' '-package-id filepath-1.4.2.2' '-package-id process-1.6.16.0' -i -i/home/cactus/prog/haskell/ghc/ghc.master/_build/stageBoot/utils/hsc2hs/build -i/home/cactus/prog/haskell/ghc/ghc.master/_build/stageBoot/utils/hsc2hs/build/hsc2hs/autogen -i/home/cactus/prog/haskell/ghc/ghc.master/utils/hsc2hs/src/ -I_build/stageBoot/utils/hsc2hs/build -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/process-1.6.16.0/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/unix-2.7.2.2/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/time-1.11.1.1/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/bytestring-0.11.4.0/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/base-4.16.4.0/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/ghc-bignum-1.2/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/include -optP-include -optP_build/stageBoot/utils/hsc2hs/build/hsc2hs/autogen/cabal_macros.h -optP-DIN_GHC_TREE -outputdir _build/stageBoot/utils/hsc2hs/build -fdiagnostics-color=always -Wall -XHaskell2010 -optc-I_build/stageBoot/utils/hsc2hs/build -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/process-1.6.16.0/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/unix-2.7.2.2/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/time-1.11.1.1/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/bytestring-0.11.4.0/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/base-4.16.4.0/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/ghc-bignum-1.2/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/include -optc-Wno-error=inline -c utils/hsc2hs/cbits/utils.c -o _build/stageBoot/utils/hsc2hs/build/c/cbits/utils.o -O -H32m ===> Command failed with error code: 1 ghc: unrecognised flag: -this-package-name hsc2hs I don't know where all those references to GHC 9.2.8 come from. I've run `configure` with GHC 9.10.1 on the $PATH and it correctly reports it as the bootstrapping version: Bootstrapping using : ghc which is version : 9.10.1 What am I doing wrong? Gergo -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---'___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Cannot build `master`, tries to use GHC 9.2?!
By playing around with GHC versions, Stack resolvers, and trying `hadrian/build` instead of `hadrian/build-stack`, I now got somewhat further: Error: hadrian: Missing dependency on a foreign library: * Missing (or bad) header file: HsBase.h But `HsBase.h` should come from the GHC source tree itself, right? So it's not an unresolved external dependency. It's very much possible that this is all because of some local configuration problem on my machine, but I'm still going to need some hints on where to even start looking. Thanks, Gerg On Mon, 8 Jul 2024, ÉRDI Gergő wrote: Hi, I'm trying to build GHC 5b1aefb70edbd54ac899896df39d8f3d6c579518 but I'm running into a weird problem. Using `hadrian/build-stack`, it fails quite early on with: | Run Ghc CompileCWithGhc (Stage0 GlobalLibs): utils/hsc2hs/cbits/utils.c => _build/stageBoot/utils/hsc2hs/build/c/cbits/utils.o Command line: ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stageBoot/inplace/package.conf.d' '-this-unit-id hsc2hs-0.68.10-inplace' '-this-package-name hsc2hs' '-package-id base-4.16.4.0' '-package-id containers-0.6.5.1' '-package-id directory-1.3.6.2' '-package-id filepath-1.4.2.2' '-package-id process-1.6.16.0' -i -i/home/cactus/prog/haskell/ghc/ghc.master/_build/stageBoot/utils/hsc2hs/build -i/home/cactus/prog/haskell/ghc/ghc.master/_build/stageBoot/utils/hsc2hs/build/hsc2hs/autogen -i/home/cactus/prog/haskell/ghc/ghc.master/utils/hsc2hs/src/ -I_build/stageBoot/utils/hsc2hs/build -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/process-1.6.16.0/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/unix-2.7.2.2/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/time-1.11.1.1/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/bytestring-0.11.4.0/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/base-4.16.4.0/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/ghc-bignum-1.2/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/include -optP-include -optP_build/stageBoot/utils/hsc2hs/build/hsc2hs/autogen/cabal_macros.h -optP-DIN_GHC_TREE -outputdir _build/stageBoot/utils/hsc2hs/build -fdiagnostics-color=always -Wall -XHaskell2010 -optc-I_build/stageBoot/utils/hsc2hs/build -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/process-1.6.16.0/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/unix-2.7.2.2/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/time-1.11.1.1/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/bytestring-0.11.4.0/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/base-4.16.4.0/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/ghc-bignum-1.2/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/include -optc-Wno-error=inline -c utils/hsc2hs/cbits/utils.c -o _build/stageBoot/utils/hsc2hs/build/c/cbits/utils.o -O -H32m ===> Command failed with error code: 1 ghc: unrecognised flag: -this-package-name hsc2hs I don't know where all those references to GHC 9.2.8 come from. I've run `configure` with GHC 9.10.1 on the $PATH and it correctly reports it as the bootstrapping version: Bootstrapping using : ghc which is version : 9.10.1 What am I doing wrong? Gergo -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---'___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Cannot build `master`, tries to use GHC 9.2?!
Hi, I'm trying to build GHC 5b1aefb70edbd54ac899896df39d8f3d6c579518 but I'm running into a weird problem. Using `hadrian/build-stack`, it fails quite early on with: | Run Ghc CompileCWithGhc (Stage0 GlobalLibs): utils/hsc2hs/cbits/utils.c => _build/stageBoot/utils/hsc2hs/build/c/cbits/utils.o Command line: ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stageBoot/inplace/package.conf.d' '-this-unit-id hsc2hs-0.68.10-inplace' '-this-package-name hsc2hs' '-package-id base-4.16.4.0' '-package-id containers-0.6.5.1' '-package-id directory-1.3.6.2' '-package-id filepath-1.4.2.2' '-package-id process-1.6.16.0' -i -i/home/cactus/prog/haskell/ghc/ghc.master/_build/stageBoot/utils/hsc2hs/build -i/home/cactus/prog/haskell/ghc/ghc.master/_build/stageBoot/utils/hsc2hs/build/hsc2hs/autogen -i/home/cactus/prog/haskell/ghc/ghc.master/utils/hsc2hs/src/ -I_build/stageBoot/utils/hsc2hs/build -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/process-1.6.16.0/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/unix-2.7.2.2/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/time-1.11.1.1/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/bytestring-0.11.4.0/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/base-4.16.4.0/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/ghc-bignum-1.2/include -I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/include -optP-include -optP_build/stageBoot/utils/hsc2hs/build/hsc2hs/autogen/cabal_macros.h -optP-DIN_GHC_TREE -outputdir _build/stageBoot/utils/hsc2hs/build -fdiagnostics-color=always -Wall -XHaskell2010 -optc-I_build/stageBoot/utils/hsc2hs/build -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/process-1.6.16.0/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/unix-2.7.2.2/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/time-1.11.1.1/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/bytestring-0.11.4.0/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/base-4.16.4.0/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/ghc-bignum-1.2/include -optc-I/home/cactus/.ghcup/ghc/9.2.8/lib/ghc-9.2.8/include -optc-Wno-error=inline -c utils/hsc2hs/cbits/utils.c -o _build/stageBoot/utils/hsc2hs/build/c/cbits/utils.o -O -H32m ===> Command failed with error code: 1 ghc: unrecognised flag: -this-package-name hsc2hs I don't know where all those references to GHC 9.2.8 come from. I've run `configure` with GHC 9.10.1 on the $PATH and it correctly reports it as the bootstrapping version: Bootstrapping using : ghc which is version : 9.10.1 What am I doing wrong? Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: How to implement type-level list concatenation as a GHC primitive type family
I know this is not exactly what you're asking, but in similar situations I've had very good results from implementing my type family as a type checker plugin. Unfortunately it's not code that I can share, but it roughly goes like this: 1. Declare a closed type family without defining any clauses: type family Append (xs :: [k]) (ys :: [k]) :: [k] where 2. Create a typechecker plugin that in `tcPluginInit` looks up this `Append` tyfam's tycon, and in `tcPluginRewrite` maps it to a `TcPluginRewriter` 3. Inside the `TcPluginRewriter`, you have a `[TcType]` which are your arguments (so the two type-level lists that are concatenated in your example). If you can compute your tyfam result from that, you can then return a `TcPluginRewriteTo` with the "trust-me" coercion `UnivCo`. This is what really helps with performance vs. a native Haskell-defined tyfam, since it avoids Core passing around huge coercion terms corresponding to every reduction step. (https://gitlab.haskell.org/ghc/ghc/-/issues/8095 https://gitlab.haskell.org/ghc/ghc/-/issues/22323 and many more) The only tricky part is that in step 3, you have to be prepared to handle pratially meta arguments. For example, if your arguments are `String : Double : []` and `Int : Bool : α` (with some typechecker metavariable `α`), you can of course reduce that to `String : Double : Int : Bool : α`. But if they are flipped, you can either bail out until `α` is solved, or make partial progress to `Int : Bool : Append α (String : Double : [])`. I don't know which is the right choice in general, since bailing out might expose less info to type inference, but partial progressing means your coercion terms will grow, since you're restoring some of that step-by-step representation. Let me know if any of this makes sense, I've got the flu atm so the above might be too rambly :) Bye, Gergo On Wed, 3 Jul 2024, Hécate via ghc-devs wrote: Hi GHC devs, I was wondering recently, considering that type family evaluation is notoriously slow, how one would implement type-level list concatenation directly within GHC in a way that is much less expensive to run. So I am looking for pointers, as this part of GHC is fairly unknown to me. Thinking about it, I'm actually unsure where the tyfam evaluation is happening. Any advice would be appreciated. Cheers, Hécate -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---'___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Is Prep supposed to keep thing in (reverse) dependency order?
Hi,
I was under the impression that the Prep'd Core is still in reverse
dependency order, i.e. if definition A refers to intra-module definition
B, then A's binding will always be preceding B's binding. I've been
exploiting this (hopefully not made-up and accidental!) property in my
work so far.
However, for the following input:
```
$s$fFunctorFun_$sfmap
:: forall a b.
(a -> b)
-> Fun '[AnnexType, CSASource, Currency, String] a
-> Fun '[AnnexType, CSASource, Currency, String] b
$s$fFunctorFun_$sfmap
= (\ (@a)
(@b)
(f :: a -> b)
(g :: Fun '[AnnexType, CSASource, Currency, String] a)
(x1 :: AnnexType) ->
let {
g1 :: TFun '[CSASource, Currency, String] a
g1
= (g `cast` ) x1 } in
(\ (x2 :: CSASource) ->
$s$fApplicativeFun_$s$fFunctorFun2
@Currency
@a
@b
f
(((g1 `cast` ) x2)
`cast` )
`cast` )
`cast` )
```
I am getting the following output from Prep:
```
sat_s2iCp
:: forall a b.
(a -> b)
-> Fun '[AnnexType, CSASource, Currency, String] a
-> Fun '[AnnexType, CSASource, Currency, String] b
sat_s2iCp
= (\ (@a)
(@b)
(f :: a -> b)
(g :: Fun '[AnnexType, CSASource, Currency, String] a)
(x1 :: AnnexType) ->
let {
g1 :: TFun '[CSASource, Currency, String] a
g1
= (g `cast` ) x1 } in
let {
sat_s2iCo :: CSASource -> Currency -> Fun '[String] b
sat_s2iCo
= \ (x2 :: CSASource) ->
$s$fApplicativeFun_$s$fFunctorFun2
@Currency
@a
@b
f
(((g1 `cast` ) x2) `cast` ) } in
sat_s2iCo
`cast` )
`cast`
$s$fFunctorFun_$sfmap
:: forall a b.
(a -> b)
-> Fun '[AnnexType, CSASource, Currency, String] a
-> Fun '[AnnexType, CSASource, Currency, String] b
$s$fFunctorFun_$sfmap
= \ (@a)
(@b)
(eta_B0 :: a -> b)
(eta_B1 :: Fun '[AnnexType, CSASource, Currency, String] a) ->
sat_s2iCp @a @b eta_B0 eta_B1
```
Note that the body of `$s$fFunctorFun_$sfmap` has been lifted out to
`sat_s2iCp`, but the binding of `sat_s2iCp` precedes the binding of
`$s$fFunctorFun_$sfmap`.
Is this expected, for some reason, or is this a GHC bug? If the latter,
I'm happy to file a ticket but I can't promise an actual end-to-end
compilable reproducer...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reducing all type family applications as far as possible
Hi, Is there a way to have GHC reduce all (reducable) type familiy applications? For example, if I have ``` type family Id x where Id x = x foo :: Bool -> Id Bool foo x = x ``` then I would like the `Id` of `foo` to have type `Bool -> Bool`, and the generated Core should be either `foo = \x -> x` or, if that's asking for too much, at least something like `foo = \x -> x |> (somePossiblyOvercomplicatedCoercion :: Bool ~ Bool)`. Is there already some functionality for this in GHC? If not, how messy would it be to implement it as a separate `CoreProgram` transformation just after desugaring? It'd need to be immediately after desugaring because I would like e.g. the specialiser to already specialise in terms of these reduced types. Thanks, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Release Timelines
On Tue, 18 Oct 2022, Matthew Pickering wrote: * 9.4.3 (End of October) - Critical correctness fix for AArch64 code generation - Fixes to performance regressions introduced in 9.4.2. - Fix to interface file determinism How about https://gitlab.haskell.org/ghc/ghc/-/issues/22272, a regression from GHC 9.2 with a fix inflight? ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Partial type synonyms -- first-class!
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) something like `{K} -> L -> M`, i.e. a function kind with
domain `K`, codomain `L -> M`, and a new kind of visibility on the arrow
itself. But that means it's not just the binder of the implicit parameter
that has a new visibility, but the arrow as well. And isn't that what
`AnonArgFlag` is for?
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. As I hint above, I think the feature would have to be
expanded somewhat to cover its likely use cases, and yet I worry that it
will not be widely enough used to make its specification and
implementation worthwhile. I'm happy to be convinced otherwise, though.
Fair enough. Although I was hoping that with Dependent Haskell, we would
have more situations where unification can give useful solutions, and so
we would want the feature of implicit arguments (even for terms!).
But if there's no appetite from GHC for partial type synonyms, what would
help me a lot in keeping this maintainable / avoiding churn in chasing
`master` would be if I can upstream two refactorings that are enablers
for my implementation but don't actually change any existing behaviour:
* Adding "does it come from a wildcard" flag to `TauTv`
(https://gitlab.haskell.org/cactus/ghc/-/commit/e8be2cb2b1093275385467741b1297ce91ef7547)
* Changing `isCompleteHsSig` to run in `TcM`, so that its result can
depend on type constructor details
(https://gitlab.haskell.org/cactus/ghc/-/commit/49f60ef13ad7f63f91519ca88cd8095db0781c92)
* Maybe a third one, depending on what we come up with for the
representation of these implicit binders
What do you think about this?
Thanks,
Gergo
Partial type synonyms -- first-class!
As I mentioned at the end of the original thread (but probably no one
was interested in this enough to read that far), after a breakthrough
idea I have now started working on partial type synonyms that are NOT
just defined using macro expansion semantics, and indeed can be a
first-class abstraction. I think if I can iron out the wrinkles
detailed at the bottom of this message, this would be good for a GHC
proposal.
1. Defining partial type synonyms
The idea is to typecheck the type synonym declaration
type Syn a = MyType _ [a] Int
into a type synonym that has some implicit (invisible) type parameters:
type Syn {w1} a = MyType w1 [a] Int
We don't need to come up with any new design for "what this means":
this means exactly the same as
type Syn w1 a = MyType w1 [a] Int
which is something you can already write today. The only difference is
how `w1` is given at use sites.
2. Using partial type synonyms
When a partial type synonym is applied, its argument list is expanded
by adding wildcard arguments for the invisible parameters. So this use
site:
Syn Double
is typececked into the type application
Syn {_} Double
Again, we don't need to come up with any new design for "what this
means": this is the same as writing `Syn _ Double` into the same
position, it's just the `_` is not written in the surface syntax.
In particular:
* The level of the type variable conjured for the `_` is determined
fully by where the `Syn Double` occurs, and not at all by the
definition of `Syn`
* Using the type synonym `Syn` is only valid where a wildcard
occurrence would be valid. In particular, using `Syn` in a type
signature causes the signature itself to be regarded as partial
(`isCompleteHsSig` returns `False` for it).
3. Implementation
I have a proof-of-concept implementation at
https://gitlab.haskell.org/cactus/ghc/-/compare/master...cactus%2Fpartial-tysyns?from_project_id=1117
I tried to make it as small a change as I could. Its key points are:
* In the renamer, we allow wildcards in `TySynCtx` context
* In `tcTySynRhs`, we allow wildcards in the right-hand side,
retrieve them from the result of typechecking, and intersperse
them with the "normal" type parameters to get a well-scoped
telescope.
* About a third of the lines changed is just a boring refactoring of
`isCompleteHsSig` to be able to look up type synonym
`TyCon`s. This is needed because a type signature referring to
partial type synonyms will be partial itself once those type
synonym applications are elaborated.
* When typechecking a type application, implicit arguments get
filled with the result of `tcAnonWildCardOcc`.
Now, my questions about the problems I've encountered along the way. I
hope these questions are concrete enough that I can get concrete
answers to them from this list:
1. How do I find the wildcard-originating tyvars robustly? Currently,
I am using `candidateQTyVarsWithBinders` but that picks up "regular"
out-of-scope tyvars as well. I believe this causes a regression of
#17567; furthermore, it means if the user writes `type Syn a = Foo b` it
is handled the same as if they wrote `type Syn a = Foo _`, but it would
be better to reject it instead.
2. What should the `Role` of these implicit type parameters be? For
now, I've went with `Nominal` for lack of a better answer.
3. When typechecking a type application, I need to insert wildcards
for these implicit arguments. I am currently using `AnonTCB InvisArg`
binders to represent these implicit type parameters, which means by
the time I get to `tcInferTyApps`, they would get passed through
`instantiate` to `tcInstInvisibleTyBinder`. I currently have a
horrible kuldge here to check, before calling
`tcInstInivisibleTyBinder`, that the invisible binder's kind doesn't
meet the preconditions of it; and if it doesn't, I create a wildcard
instead. But of course, it would be nicer if I could put something in
the `TcTyConBinder` that identifies these binders properly.
Thanks in advance,
Gergo
--
.--= ULLA! =-.
\ http://gergo.erdi.hu \
`---= ge...@erdi.hu =---'
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Wildcards in type synonyms
In case anyone's still interested, Atze Dijkstra and I have come up with
an alternative approach to implementing this which requires changing much
fewer moving parts.
The idea is to internally regard `type MySyn a = T[_, a, _]` as
`type MySyn w1 w2 a = T[w1, a, w2]`, recording in `SynTyCon` that we'll
need to synthesize 2 wildcard argument; then, during typechecking of
occurrences, `MySyn` gets expanded into `MySyn _ _`. This is basically a
simplified version of what languages with implicit parameters do --
in Agda syntax, we'd have
MySyn : {w1 : Type} {w2 : Type} (a : Type) -> Type
and the application `MySyn A` is short-hand for `MySyn {w1 = _} {w2 = _} A`.
Of course, for a robust implementation, we can't just put all these
implicit parameters up front, because they can form a telescope with
other parameters; but, because type synonym applications need to be
saturated anyway, I think even that could be implemented without
complicated impredicativity decisions, simply by storing a bit more than
just a single natural number as the extra info in `SynTyCon`.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Wildcards in type synonyms
On Thu, 28 Jul 2022, Simon Peyton Jones wrote: You need to be super-careful about the *level* of wildcards. That is a tricky bit about the whole wildcard implementation. Indeed! Ensuring the fresh metavars are at `topTcLevel` seems to have fixed my problem. My goal doesn't include support higher-rank types at all, anyway, so this should be good enough for now. Thanks, this was the key to all my troubles.___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Wildcards in type synonyms
On Thu, 28 Jul 2022, Simon Peyton Jones wrote:
Wild guess: you aren't instantiating the kinds of the meta-tyvars to something
sensible, so kinds don't line up. Eg. where are k_ax9 and k_awW bound?
`a_auu :: k_ax9` is the result of typechecking my type argument (the `a`
in the source type `MySyn a`), so I would expect its kind to work because
it is computed by parts of GHC that I am not changing.
`w_awX :: k_awW` is the metavariable created during the typechecking of
the right-hand side of my type macro `type MySyn a = MyData a _ Int`. This
kind is then kept for the fresh metavariable that I try to replace `w_awX`
with, since I have `w_axc :: k_awW`.
The part that confuses me the most is that the right-hand side seems to
work just fine on its own:
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 I have two versions of my code returning two types from
`tc_infer_hs_type` that only differ in containing either `w_awX :: k_awW`
or `w_axc :: k_awW`, and one of them typechecks while the other causes a
type error.
Typechecks (as long as only used once of course):
```
TySynWildcard.MyData{tc r3}
(a{tv auu} Nothing [sk:2] :: (k_ax9{tv} Nothing [tau:2] ::
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}
```
Doesn't typecheck:
```
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}
```
What is the difference?___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Wildcards in type synonyms
resh" 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
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
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
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
On Fri, 22 Jul 2022, Iavor Diatchki wrote: I've implemented such a feature in Cryptol, not GHC, so it is quite doable, but I think the implementation would be easier if you decided on the overall design of the feature first. I'm hoping the details pretty much fall out from what it would mean if I used the existing PartialTypeSignatures extension to write 'MyData T _ Int` at those places. Some things to consider: * these kind of "existential" variable make sense in other type signatures, not just type synonyms * there might be some contexts where you may want to disallow such wildcards (e. g., in a data declaration) * you have to be careful with the scoping of type variables. For example, you should not unify an existential/wildcard variable with a type that refers to variables that are not in scope of the wildcard. I don't remember if GHC already has a system for such things, but in Cryptol we implanted this by having each unification variable keep track of the quantified variables that it may depend on.___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Wildcards in type synonyms
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
Re: Migration guide for multiple home units
On Thu, 16 Jun 2022, Erdi, Gergo via ghc-devs wrote:
Is there a migration guide for GHC API clients for the new “multiple home units”
feature?
OK so in concrete terms, please see my attached program which is a heavily
cut-down, standalone version of my real program. On commit
fd42ab5fa1df847a6b595dfe4b63d9c7eecbf400^ (i.e.
3219610e3ba6cb6a5cd1f4e32e2b4befea5bd384) it compiles and works as
expected. On commit fd42ab5fa1df847a6b595dfe4b63d9c7eecbf400 onwards, two
problems pop up:
1. `extendMG` has changed and now requires manually specifying outgoing
dependency edges. I thought the whole point of `summariseFile` was to
collect this information? The reason I need to `extendMG` at that point is
to get intra-unit orphan instances working.
2. `modifyUnitState` and its two uses (`addUnit` and `registerModule`)
need to be updated to the new API. I think it makes sense that these need
changing, since they touch exactly on the issue of which units are being
compiled right now. However, I don't know how to update these. Also, I
guess `setHomeUnit` should change the `CurrentUnit` instead of the
`HomeUnit` now?
Thanks,
Gergo{-# LANGUAGE BlockArguments, RecordWildCards #-}
module Main where
import qualified Paths_ghc_lib as GHC
import GHC
import GHC.Core
import GHC.Core.FamInstEnv
import GHC.Core.InstEnv
import GHC.Core.Rules
import GHC.Core.TyCon
import GHC.CoreToStg.Prep
import GHC.Data.FastString
import GHC.Data.IOEnv
import GHC.Data.StringBuffer
import GHC.Driver.Env
import GHC.Driver.Errors.Types
import GHC.Driver.Main (hscSimplify)
import GHC.Driver.Make
import GHC.Driver.Monad
import GHC.Driver.Phases
import GHC.Driver.Session
import GHC.Iface.Make
import GHC.Iface.Tidy (tidyProgram)
import GHC.Tc.Types
import GHC.Tc.Utils.Monad
import GHC.Types.Annotations
import GHC.Types.Error
import GHC.Types.SourceError
import GHC.Types.SourceFile
import GHC.Types.TypeEnv
import GHC.Types.Unique.FM
import GHC.Unit.Env
import GHC.Unit.External
import GHC.Unit.Home
import GHC.Unit.Home.ModInfo
import GHC.Unit.Info
import GHC.Unit.Module.Env
import GHC.Unit.Module.Graph
import GHC.Unit.Module.ModDetails
import GHC.Unit.Module.ModGuts
import GHC.Unit.Module.ModSummary
import GHC.Unit.Module.Name
import GHC.Unit.State
import GHC.Unit.Types
import Data.Version
import qualified Data.Map as M
import Data.Foldable (for_)
import Control.Monad.Writer hiding ((<>))
import System.FilePath
import Data.Time
fooUnitId, barUnitId :: UnitId
fooUnitId = UnitId $ fsLit "foo"
barUnitId = UnitId $ fsLit "bar"
fooUnit, barUnit :: Unit
fooUnit = RealUnit $ Definite fooUnitId
barUnit = RealUnit $ Definite barUnitId
fooUnitInfo, barUnitInfo :: UnitInfo
fooUnitInfo = fakeUnitInfo fooUnitId []
barUnitInfo = fakeUnitInfo barUnitId []
main :: IO ()
main = do
let mods = [ (fooUnitId, mkModuleName "A")
, (barUnitId, mkModuleName "B")
, (mainUnitId, mkModuleName "C")
]
libDir <- liftIO $ GHC.getDataDir
runGhcT (Just libDir) do
setup
mapM_ (modifySession . addUnit)
[ fooUnitInfo
, barUnitInfo
]
for_ mods \(unitId, modName) -> do
target <- mkTarget unitId $ "input" moduleNameSlashes modName <.> "mu"
(ms, deps) <- prepareModule modName target
liftIO $ print (modName, deps)
let mod = ms_mod ms
modifySession $ setHomeUnit $ toUnitId . moduleUnit $ mod
(core, details, iface) <- compileToCore ms
registerModule details iface
return ()
compileToCore
:: (GhcMonad m)
=> ModSummary
-> m (CoreProgram, ModDetails, ModIface)
compileToCore ms = do
dmod <- desugarModule =<< typecheckModule =<< parseModule ms
let mguts = coreModule dmod
env <- getSession
mguts' <- liftIO $ hscSimplify env [] mguts
(cg_guts, details) <- liftIO $ tidyProgram env mguts'
let types = md_types details
tycons = typeEnvTyCons types
data_tycons = filter isDataTyCon tycons
let partial_iface = mkPartialIface env details ms mguts'
iface <- liftIO $ mkFullIface env partial_iface Nothing
let tidy_binds = cg_binds cg_guts
binds <- liftIO $ corePrepPgm env mod modLoc tidy_binds data_tycons
return (binds, details, iface)
where
mod = ms_mod ms
modLoc = ms_location ms
prepareModule :: (GhcMonad m) => ModuleName -> Target -> m (ModSummary, [ModuleName])
prepareModule modName target = do
env <- getSession
env <- return $ setHomeUnit (toUnitId unit) env
mems <- liftIO $ summariseFile env [] file mb_phase fileContents
case mems of
Left err -> do
reportErrors [fmap GhcDriverMessage err]
error $ unwords ["prepareModule/lookupModuleEnv", unitString unit, moduleNameString . moduleName $ mod]
Right ems -> do
let ms = emsModSummary ems
deps = ms_textual_imps ms
when (unit == mainUnit) $
Re: Extending call_args when specialising DFuns
On Mon, 2 May 2022, Simon Peyton Jones wrote: 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? I'm happy to provide a patch (and also fix the comment referencing GHC.Core.Unfold.specUnfolding), but I don't think I'll be able to provide a test case for it, because, like you said, it's hard to provoke.___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Extending call_args when specialising DFuns
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
Re: Warning about glomming
On Thu, 7 Apr 2022, Simon Peyton Jones wrote: Gergo might you offer a patch? https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7964 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Re: Shadowing in toIface* output
On Thu, 7 Apr 2022, Simon Peyton Jones wrote: If you can repro this with GHC, can you open a ticket for it. https://gitlab.haskell.org/ghc/ghc/-/issues/21363 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Shadowing in toIface* output
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 these locally bound `Var`s are represented as just their
`getOccFS` (i.e. the `FastString` `"v"`).
But this can't be right: if `toIfaceExpr` would fail this blatently,
then the unfoldings couldn't be saved & restored, which is something GHC
itself does as part of normal `.hi` file handling. So clearly I must be
doing something wrong.
So I guess my question could be, what could be causing `toIfaceExpr` (a
pure function!) to behave this way for my Cores? But then, if I look at
the implementation of `toIface*`, I can see that it really doesn't do
anything smarter than just storing `getOccFS` in the interface (no
uniques in sight)-- so maybe my *real* question is, what is GHC itself
doing so that it doesn't have this same problem?
Thanks,
Gergo
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [clash-language] Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings
On Fri, 1 Apr 2022, Sylvain Henry wrote: The unfolding is present if you add `-fno-omit-interface-pragmas` and dump with `-ddump-simpl`. CorePrep drops unfoldings, see Note [Drop unfoldings and rules] in GHC.CoreToStg.Prep. Thanks, I forgot to mention that I am already using `NoOmitInterfacePragmas`, but I wasn't aware that the Prep stage drops unfoldings (and in fact, I am using Prep output in my real program). But if that's the case, how come most of my Ids still have unfoldings, and only a couple of them are missing? ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [clash-language] Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings
This doesn't quite match my experience. For example, the following
toplevel definition gets an `OtherCon []` unfolding:
nonEmptySubsequences :: [a] -> [[a]]
nonEmptySubsequences [] = []
nonEmptySubsequences (x:xs) = [x] : foldr f [] (nonEmptySubsequences xs)
where
f ys r = ys : (x:ys) : r
as can be seen with:
$ ghc -fforce-recomp -fexpose-all-unfoldings -ddump-prep -dsuppress-uniques A.hs
-- RHS size: {terms: 37, types: 55, coercions: 0, joins: 0/6}
A.nonEmptySubsequences [Occ=LoopBreaker] :: forall a. [a] -> [[a]]
[GblId, Arity=1, Unf=OtherCon []]
A.nonEmptySubsequences
= \ (@ a) (ds [Occ=Once1!] :: [a]) -> ...
So this is not a lifted `case`-bound variable, but a bonafide
user-originating toplevel definition. And its value also isn't bottom.
On Fri, 1 Apr 2022, Christiaan Baaij wrote:
So if I understand correctly, OtherCon is only created
here:https://gitlab.haskell.org/ghc/ghc/-/blob/a952dd80d40bf6b67194a44ff71d7bf75957d29e/co
mpiler/GHC/Core/Opt/Simplify.hs#L3071-3077
simplAlt env _ imposs_deflt_cons case_bndr' cont' (Alt DEFAULT bndrs rhs)
= assert (null bndrs) $
do { let env' = addBinderUnfolding env case_bndr'
(mkOtherCon imposs_deflt_cons)
-- Record the constructors that the case-binder *can't* be.
; rhs' <- simplExprC env' rhs cont'
; return (Alt DEFAULT [] rhs') }
What you should know is that in Core case-expressions are actually more like:
case scrut as b of alts
where `b` binds the evaluated result of `scrut.
So if I am to understand the `simplAlt` code correctly, `case_bndr'` is the
binder for
the evaluated result of `scrut`.
And what is recorded in the unfolding is that once we get to the DEFAULT
pattern, we
know that `case_bndr'` cannot be the constructors in `imposs_deflt_cons`
(probably the
constructor matched by the other alternatives).
Now... there's also a FloutOut pass, which might have floated that `case_bndr'`
to the
TopLevel.
And I think that is what you're seeing, and I think you can simply ignore them.
Also... another thing that you should know is that -fexpose-all-unfoldings
doesn't
actually expose *all* unfoldings.
Bottoming bindings are never exposed.
That's why in the Clash compiler we have the following code when loading
core-expressions from .hi
fileshttps://github.com/clash-lang/clash-compiler/blob/cb93b418865e244da50e1d2bc85fbc01bf7
61f3f/clash-ghc/src-ghc/Clash/GHC/LoadInterfaceFiles.hs#L473-L481
loadExprFromTyThing :: CoreSyn.CoreBndr -> GHC.TyThing -> Maybe CoreSyn.CoreExpr
loadExprFromTyThing bndr tyThing = case tyThing of
GHC.AnId _id | Var.isId _id ->
let _idInfo = Var.idInfo _id
unfolding = IdInfo.unfoldingInfo _idInfo
in case unfolding of
CoreSyn.CoreUnfolding {} ->
Just (CoreSyn.unfoldingTemplate unfolding)
CoreSyn.DFunUnfolding dfbndrs dc es ->
Just (MkCore.mkCoreLams dfbndrs (MkCore.mkCoreConApps dc es))
CoreSyn.NoUnfolding
#if MIN_VERSION_ghc(9,0,0)
| Demand.isDeadEndSig $ IdInfo.strictnessInfo _idInfo
#else
| Demand.isBottomingSig $ IdInfo.strictnessInfo _idInfo
#endif
-> do
let noUnfoldingErr = "no_unfolding " ++ showPpr unsafeGlobalDynFlags
bndr
Just (MkCore.mkAbsentErrorApp (Var.varType _id) noUnfoldingErr)
_ -> Nothing
_ -> Nothing
i.e. when we encounter a NoUnfolding with a bottoming demand signature, we
conjure an
absentError out of thin air.
On Fri, 1 Apr 2022 at 10:05, ÉRDI Gergő wrote:
Hi,
I'm CC-ing the Clash mailing list because I believe they should have
encountered the same problem (and perhaps have found a solution to it
already!).
I'm trying to use `.hi` files compiled with `ExposeAllUnfoldings` set to
reconstruct full Core bindings for further processing. By and large, this
works, but I get tripped up on identifiers whose unfolding is only given
as `OtherCon []`. It is unclear to me what is causing this -- some of them
are recursive bindings while others are not.
The problem, of course, is that if all I know about an identifier is that
it is `OtherCon []`, that doesn't allow me to restore its definition. So
is there a way to tell GHC to put "full" unfoldings everywhere in
`ExposeAllUnfoldings` mode?
Thanks,
Gergo
--
You received this message because you are subscribed to the Google Groups
"Clash - Hardware Description Language" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clash-language+unsubscr...@googlegroups.com.
To view this discussion on the web
visithttps://groups.google.com/d/msgid/clash-language/alpine.DEB.2.22.394.2204011556570.31
83073%40galaxy.
--
.--= ULLA! =-.
\ http://gergo.erdi.hu \
`---= ge...@erdi.hu =---'___
Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings
Hi, I'm CC-ing the Clash mailing list because I believe they should have encountered the same problem (and perhaps have found a solution to it already!). I'm trying to use `.hi` files compiled with `ExposeAllUnfoldings` set to reconstruct full Core bindings for further processing. By and large, this works, but I get tripped up on identifiers whose unfolding is only given as `OtherCon []`. It is unclear to me what is causing this -- some of them are recursive bindings while others are not. The problem, of course, is that if all I know about an identifier is that it is `OtherCon []`, that doesn't allow me to restore its definition. So is there a way to tell GHC to put "full" unfoldings everywhere in `ExposeAllUnfoldings` mode? Thanks, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Where do I put the *definition* of a DFunId?
On Fri, 11 Feb 2022, ÉRDI Gergő wrote: Presumably you must also be generating these bindings (in a `ModGuts` perhaps?) and generating code for them that will ultimately be linked into the program to run. BTW, I thought that linking is done on the object file level, i.e. I thought it is perfectly kosher to reference a term-level thing only by Id, with no definition around, as long as later there will be an object file that provides a suitably name-mangled symbol? Is this not true and GHC requires to see the definitions of all referenced Ids?___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Where do I put the *definition* of a DFunId?
On Fri, 11 Feb 2022, Simon Peyton Jones wrote: A `ModDetails` gives the type signatures for everything, but no actual code. For example if you have `f :: Int -> Int` in the `md_types`, the `ModDetails` doesn't include the binding `f = rhs` for `f`. Yes, this on its own makes sense. Presumably you must also be generating these bindings (in a `ModGuts` perhaps?) and generating code for them that will ultimately be linked into the program to run. I am not generating a `ModGuts`. My intention is to use these instances from "normal" (hand-written) source input to GHC. GHC should use the `DFunUnfolding`s during specialization to get rid of overloaded code, after which I should have inlined-due-to-specialization versions of my definitions. Well, put the `DFunId` binding in the same place, alongside `f`. For the sake of argument, suppose that I did make a `ModGuts`. In that case, what kind of internal state would be updated based on the contents of that `ModGuts` such that references to my `DFunId` would work?___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*)
On Fri, 22 Oct 2021, Matthew Pickering wrote: If there is a ticket then I can look into it next week. Thanks! I've added it as https://gitlab.haskell.org/ghc/ghc/-/issues/20556 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
CI build failures
Hi, I'm seeing three build failures in CI: 1. On perf-nofib, it fails with: == make boot -j --jobserver-fds=3,4 --no-print-directory; in /builds/cactus/ghc/nofib/real/smallpt /builds/cactus/ghc/ghc/bin/ghc -M -dep-suffix "" -dep-makefile .depend -osuf o -O2 -Wno-tabs -Rghc-timing -H32m -hisuf hi -packageunboxed-ref -rtsopts smallpt.hs : cannot satisfy -package unboxed-ref (use -v for more information) (e.g. https://gitlab.haskell.org/cactus/ghc/-/jobs/743141#L1465) 2. On validate-x86_64-darwin, pretty much every test fails because of the following extra stderr output: + +: +warning: Couldn't figure out C compiler information! + Make sure you're using GNU gcc, or clang (e.g. https://gitlab.haskell.org/cactus/ghc/-/jobs/743129#L3655) 3. On validate-x86_64-linux-deb9-integer-simple, T11545 fails on memory consumption: Unexpected stat failures: perf/compiler/T11545.run T11545 [stat decreased from x86_64-linux-deb9-integer-simple-validate baseline @ 5f3991c7cab8ccc9ab8daeebbfce57afbd9acc33] (normal) This one is interesting because there is already a commit that is supposed to fix this: commit efaad7add092c88eab46e00a9f349d4675bbee06 Author: Matthew Pickering Date: Wed Jul 21 10:03:42 2021 +0100 Stop ug_boring_info retaining a chain of old CoreExpr [...] - Metric Decrease: T11545 - But still, it's failing. Can someone kick these build setups please? -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---' ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Using overloaded syntax to avoid `base` dependency (RE: Marking ParsedModule fragments as non-user-originating)
On Fri, 16 Jul 2021, Simon Peyton Jones via ghc-devs wrote: Yes, it would be much better to use the extension field. That would stop the (GHC-independent) Language.Haskell.Syntax needing to talk about “witnesses”. Here it is: https://gitlab.haskell.org/ghc/ghc/-/issues/20151___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Loading a typechecked module and then using it immediately as a package
On Fri, 25 Jun 2021, Matthew Pickering wrote: Hi Gergo, Please see a minimal example in this gist. https://gist.github.com/mpickering/5029c7f244c484c91d665bcbc6bc6406 Thanks for the quick reply! Unfortunately, I won't be able to try it out until Monday. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Inlining of `any @[]` vs `elem @[]`
On Fri, 12 Mar 2021, Simon Peyton Jones wrote: I'm not sure... you could investigate, but I'm inclined just to declare victory! That's easy for you to say, but here I am stuck with Stack not supporting GHC 9.0... https://github.com/commercialhaskell/stack/issues/5486 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Inlining of `any @[]` vs `elem @[]`
On Fri, 12 Mar 2021, ÉRDI Gergő wrote: I wonder why that is? What changed between GHC 8.10.3 and 9.0.1? Was the definition of `elem` changed in `base`? Oh, I've found this commit: ``` commit f10d11fa49fa9a7a506c4fdbdf86521c2a8d3495 Author: Andreas Klebinger Date: Wed Jan 29 15:25:07 2020 +0100 Fix "build/elem" RULE. An redundant constraint prevented the rule from matching. Fixing this allows a call to elem on a known list to be translated into a series of equality checks, and eventually a simple case expression. [...] ```___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Inlining of `any @[]` vs `elem @[]`
On Thu, 11 Mar 2021, Simon Peyton Jones wrote: With HEAD, and -O, I get the exact same (good code) for these two functions: f x = any (x ==) [1, 5, 7::Int] g x = elem x [2, 6, 9 :: Int] Maybe this is fixed? If you think not, maybe open a ticket? OK, so initially I tried it on GHC 8.10.3, which is where `elem @[]` is not optimized. I have now tried on GHC 9.0.1, where, just like you see on HEAD, indeed it gets it right. I wonder why that is? What changed between GHC 8.10.3 and 9.0.1? Was the definition of `elem` changed in `base`? Thanks, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: What changed between GHC 8.8 and 8.10 that could cause this?
Thanks Matthew and Julian! Unfortunately, trying out GHC before/after this change didn't turn out to be as easy as I hoped: to do my testing, I need to build a given GHC commit, and then use that via Stack to install ~140 dependencies so that I can then test the problem I have initially seen. And it turns out doing that with a random GHC commit is quite painful because in any given Stackage snapshot there will be packages with which the GHC-bundled libraries are incompatible... :/ On Thu, 4 Mar 2021, Julian Leviston wrote: Hi,I don’t know enough about what Clash does to comment really, but it sounds like it’s to do with my work on enabling multiple linker instances in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/388 — maybe reading through that or the plan I outlined at https://gitlab.haskell.org/ghc/ghc/-/issues/3372 might help, though I’m not sure. Strange, though, as this work was to isolate state in GHC — to change it from using a global IORef to use a per-process MVar . But it definitely did change the way state is handled, so it might be the related to these issues somehow? I realise this isn’t much help, but maybe it points you in a direction where you can begin to understand some more. Julian On 4 Mar 2021, at 10:55 pm, ÉRDI Gergő wrote: Hi, I'm trying to figure out a Clash problem and managed to track it down to a GHC upgrade; specifically, a given Clash version, when based on GHC 8.8, has no problem synthesizing one module after another from one process; but the same Clash version with GHC 8.10 fails with link-time errors on the second compilation. The details are at https://github.com/clash-lang/clash-compiler/issues/1686 but for now I'm just hoping that some lightbulb will go off for someone if some handling of internal state has changed in GHC that could mean that the symbol tables of loaded modules could persist between GHC invocations from the same process. So, does this ring a bell for anyone? Thanks, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---' I tried to commit suicide once by taking over 1,000 aspirin. But after I took 2, I felt better!___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Inlining of `any @[]` vs `elem @[]`
Hi,
The inlining behaviour of `any @[]` and `elem @[]` differs in a way that I
am not sure is intentional, and it is affecting Clash (see
https://github.com/clash-lang/clash-compiler/issues/1691). I would think
that if it is a good idea to inline `any` then inlining `elem` would be
just as good an idea, or vice versa.
However, `any` is defined polymorphically over `Foldable`, via `foldMap`
using `foldr`, with all steps between (and `foldr @[]`!) marked as
`INLINE`. The result is that if you use `any (x ==) [1, 5, 7]` you get the
following beautiful Core:
```
topEntity
= \ (x_agAF :: Int) ->
case x_agAF of { GHC.Types.I# y_ahao ->
case y_ahao of {
__DEFAULT -> GHC.Types.False;
1# -> GHC.Types.True;
5# -> GHC.Types.True;
7# -> GHC.Types.True
}
}
```
As the kids these days would say: *chef's kiss*.
`elem`, on the other hand, is a typeclass method of `Foldable`, with a
default implementation in terms of `any`, but overridden for lists with the
following implementation:
```
GHC.List.elem :: (Eq a) => a -> [a] -> Bool
GHC.List.elem _ [] = False
GHC.List.elem x (y:ys) = x==y || GHC.List.elem x ys
{-# NOINLINE [1] elem #-}
{-# RULES
"elem/build"forall x (g :: forall b . Eq a => (a -> b -> b) -> b -> b)
. elem x (build g) = g (\ y r -> (x == y) || r) False
#-}
```
This is marked as non-inlineable until phase 1 (so that `elem/build` has a
chance of firing), but it seems that when build fusion doesn't apply
(since `[1, 5, 7]` is, of course, not built via `build`), no inlining
happens AT ALL, even in later phases, so we end up with this:
```
topEntity
= \ (x_agAF :: Int) ->
GHC.List.elem
@ Int
GHC.Classes.$fEqInt
x_agAF
(GHC.Types.:
@ Int
(GHC.Types.I# 1#)
(GHC.Types.:
@ Int
(GHC.Types.I# 5#)
(GHC.Types.: @ Int (GHC.Types.I# 7#) (GHC.Types.[] @ Int
```
So not only does it trip up Clash, it would also result in less efficient
code in software when using "normal" GHC.
Is this all intentional? Wouldn't it make more sense to mark
`GHC.List.elem` as `INLINE [1]` instead of `NOINLINE [1]`, so that any
calls remaining after build fusion would be inlined?
Thanks,
Gergo
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
What changed between GHC 8.8 and 8.10 that could cause this?
Hi, I'm trying to figure out a Clash problem and managed to track it down to a GHC upgrade; specifically, a given Clash version, when based on GHC 8.8, has no problem synthesizing one module after another from one process; but the same Clash version with GHC 8.10 fails with link-time errors on the second compilation. The details are at https://github.com/clash-lang/clash-compiler/issues/1686 but for now I'm just hoping that some lightbulb will go off for someone if some handling of internal state has changed in GHC that could mean that the symbol tables of loaded modules could persist between GHC invocations from the same process. So, does this ring a bell for anyone? Thanks, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC Logo
The Cat's name should be Hask. On Wed, Sep 2, 2020, 22:39 Richard Eisenberg wrote: > On Sep 2, 2020, someone wrote to me privately saying: > > > I was thinking Cats for some reason. > > Ooh. I'm picturing a cat with its tail wrapped around a lambda, or > something like that. And Simon PJ does have a cat named Haskell who could > perhaps be the model. :) > > Richard > > On Sep 2, 2020, at 10:16 AM, Richard Eisenberg wrote: > > I'm oddly drawn to the idea of a turtle -- except that turtles are slow. > But animals are cute. Maybe something involving a fox, given that foxes can > be clever? Octopuses are also known to be very clever, but maybe GitHub has > octopuses covered. > > On Sep 1, 2020, at 8:42 PM, Carter Schonwald > wrote: > > Ben, what if we have someone draw a cartoony version of your box turtle? i > feel like that would be a pretty cute logo! totally ahistorical, but would > certainly be cute! > > On Tue, Sep 1, 2020 at 7:51 PM Daneel Yaitskov > wrote: > >> Hi, >> >> Is it a contest for picking up a new logo? >> As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here >> means Haskell. >> >> So logo should be GλC. >> >> Best Regards, >> Daniil. >> >> On Sat, Aug 15, 2020, 8:50 AM Ben Gamari wrote: >> >>> Hi everyone, >>> >>> Recently a sponsor asked for a logo for our project. As far as I know, >>> GHC doesn't really have a consistent logo; the closest that we have had >>> is the stylized "GHC" on the top of ghc.haskell.org. >>> >>> To accomodate the request, I took a few minutes and reworked the >>> typography of the Thompson-Wheeler Haskell logo for use by GHC. I >>> couldn't positively identify the typeface used for the "Haskell" text, >>> but I believe that the extra-bold Cantarell face that I chose in the GHC >>> variant has a similar feel to the Haskell logo and is free to use. >>> >>> I've posted the logo on the Wiki for future reference [1]. Feedback is >>> very much welcome. >>> >>> Cheers, >>> >>> - Ben >>> >>> >>> >>> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo >>> ___ >>> 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 > > > ___ > 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: Class op rules
As a workaround, can you try this?
https://stackoverflow.com/a/32133083/477476
On Fri, Mar 6, 2020, 23:23 Christiaan Baaij
wrote:
> Hello,
>
> The other day I was experimenting with RULES and got this warning:
>
> src/Clash/Sized/Vector.hs:2159:11: warning: [-Winline-rule-shadowing]
> Rule "map Pack" may never fire
> because rule "Class op pack" for ‘pack’ might fire first
> Probable fix: add phase [n] or [~n] to the competing rule
> |
> 2159 | {-# RULES "map Pack" map pack = id #-}
>
> The warning seems to suggests two things:
> 1. "Class op" -> "dictionary projection" are implemented as rewrite rules
> and executed the same way as other user-defined RULES
> 2. These rules run first, and you cannot run anything before them
>
> Now my question is, is 1. actually true? or is that warning just a (white)
> lie?
> If 1. is actually true, would there be any objections to adding a "-1"
> phase: where RULES specified to start from phase "-1" onward fire before
> any of the Class op rules.
> I'm quite willing to implement the above if A) Class op rules are actually
> implemented as builtin RULES; B) there a no objections to this "-1" phase.
>
> Thanks,
> Christiaan
>
> ___
> 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: Record syntax for pattern synonyms
Record field updates via patsyns looks very weird to me (and, as just a
user, it would be unexpected). Can't we do just matchers and builders for
now, and add field updaters as a second step, if there's concensus that
it's a Good Idea?
Bye,
Gergo
On 11 Aug 2015 07:11, Matthew Pickering matthewtpicker...@gmail.com
wrote:
I was looking at implementing #8582 but before I got too far I thought
it best to clear up a few design points.
A summary can be found below and a more fleshed out version with some
examples can be found on the wiki page[1].
My main question is about how best to deal with record updates. Say
that Foo is a record pattern synonym then how would we expect the
following program to behave?
```
foo a@Foo{..} = a {bar = baz}
```
Then say that `pattern Foo{bar} = Just bar`, how should the following
two programs behave? Is this partiality any different to that caused
by ordinary use of pattern synonyms? (At least partiality in patterns
is warned but how comprehensive is the coverage?)
```
foo :: Maybe a - Maybe Int
foo x = x {bar = 5}
-- error as `bar` unique determines that we need Foo
bar = Nothing {bar = 5}
```
Abandoning record updates seems to make record syntax for pattern
synonyms far less useful and confusing to users. Is this design how
others have imagined it? I have cced Gergő who originally implemented
the extension and created #8582.
Matt
Unidirectional patterns
* Provide the same ability to match as normal records (RecordWildcards etc)
* Provide selector functions
Bidirectional patterns
* Provide the constructor which can be used as normal record constructors
Record Updates - unclear
* Generalise update syntax to arbitrary expressions?
[1]:
https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#RecordPatternSynonyms
___
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: Triggering a Harbourmaster build on a given commit
Thanks! On Dec 22, 2014 11:53 PM, Austin Seipp aus...@well-typed.com wrote: Bah, this is some bunk permission error. I'll try to fix it shortly. In the mean time, I ran it for you: https://phabricator.haskell.org/B2742 On Mon, Dec 22, 2014 at 9:44 AM, Dr. ERDI Gergo ge...@erdi.hu wrote: Hi, Thanks for the detailed instructions -- it looks like something that should be on some wiki somewhere! However, I got stuck on step 4: it says I do not have permission to manage Harbormaster build plans and I need an adult^Wadministrator. How do I proceed? Thanks, Gergo On Mon, 22 Dec 2014, Austin Seipp wrote: Unfortunately it's a bit hidden in the UI. I'll try to explain: 1) Go to https://phabricator.haskell.org/harbormaster 2) On the left side, click on 'Manage Build Plans' 3) Click on 'Plan 2 - GHC Continuous Integration', which builds commits 4) On the right-hand side, click 'Run Plan Manually' 5) In the box, enter the 'object name'. NOTE: the object name is DIFFERENT than the raw commit SHA1. In Phabricator, a 'commit object' is identified fully by the repository callsign plus the SHA1. In your case, you want to test commit 20acaa7785. Therefore, the full object name would be 'rGHC20acaa785', just like it appears in the URL you posted. This should do the job. Hope that helps! On Sun, Dec 21, 2014 at 6:47 AM, Dr. ERDI Gergo ge...@erdi.hu wrote: Hi, Given a concrete commit on a non-master branch (e.g. https://phabricator.haskell.org/rGHC20acaa7785d910d36d46c4eae9e9cce4000635d1 ), how do I manually trigger a Harbourmaster build + validation? Thanks, Gergo -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---' A man's best friend is his dogma. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---' Óvakodj a kliséktől: tizenkettő belőlük egy tucat! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]
It is clear to everyone that all it would change is the *output* of GHCi's :info and Haddock-generated docs, right? There's no change whatsoever to what programs are accepted by GHC, or what they mean. On Dec 2, 2014 5:44 AM, Simon Peyton Jones simo...@microsoft.com wrote: The issue is not so much timing for 7.8.4 (it's a modes change to pretty-printing only) but rather that it would make 7.8.4 behave differently to 7.8.3 (although similarly to 7.10). We typically do not do that. And the same would be true of 7.8.5. Simon | -Original Message- | From: Gabor Greif [mailto:ggr...@gmail.com] | Sent: 01 December 2014 15:53 | To: Dr. ERDI Gergo | Cc: Simon Peyton Jones; ghc-devs@haskell.org | Subject: Re: Back-porting pattern synonym type signature syntax for GHC | 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] | | Gergö, | | even if it might be too late for 7.8.4, don't give up hope for 7.8.5 :-) | | Gabor | | | On 11/29/14, Dr. ERDI Gergo ge...@erdi.hu wrote: | On Wed, 26 Nov 2014, Simon Peyton Jones wrote: | | My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie. | But what do others think? | | Just to give an idea of how limited the scope of this change would be, | I've went and implemented it, on the 'wip/pattern-synonym-sig-backport' | branch (of both GHC and Haddock). | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]
With enough intellectual dishonesty, sure... On Dec 2, 2014 7:29 AM, Gabor Greif ggr...@gmail.com wrote: So it could be regarded as a bugfix? Em terça-feira, 2 de dezembro de 2014, Dr. ÉRDI Gergő ge...@erdi.hu escreveu: It is clear to everyone that all it would change is the *output* of GHCi's :info and Haddock-generated docs, right? There's no change whatsoever to what programs are accepted by GHC, or what they mean. On Dec 2, 2014 5:44 AM, Simon Peyton Jones simo...@microsoft.com wrote: The issue is not so much timing for 7.8.4 (it's a modes change to pretty-printing only) but rather that it would make 7.8.4 behave differently to 7.8.3 (although similarly to 7.10). We typically do not do that. And the same would be true of 7.8.5. Simon | -Original Message- | From: Gabor Greif [mailto:ggr...@gmail.com] | Sent: 01 December 2014 15:53 | To: Dr. ERDI Gergo | Cc: Simon Peyton Jones; ghc-devs@haskell.org | Subject: Re: Back-porting pattern synonym type signature syntax for GHC | 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1] | | Gergö, | | even if it might be too late for 7.8.4, don't give up hope for 7.8.5 :-) | | Gabor | | | On 11/29/14, Dr. ERDI Gergo ge...@erdi.hu wrote: | On Wed, 26 Nov 2014, Simon Peyton Jones wrote: | | My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie. | But what do others think? | | Just to give an idea of how limited the scope of this change would be, | I've went and implemented it, on the 'wip/pattern-synonym-sig-backport' | branch (of both GHC and Haddock). | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Explicitly bidirectional pattern synonyms for 7.8.3?
It... fixes the bug of... a missing feature? ... I'll take that as a no. :) On Jul 8, 2014 10:40 PM, Carter Schonwald carter.schonw...@gmail.com wrote: 7.8.3 is a bug fix release, is this a bug fix? :-) On Tuesday, July 8, 2014, Dr. ERDI Gergo ge...@erdi.hu wrote: Hi, I've spent the last couple evenings implementing explicitly-bidirectional pattern synonyms, partly while waiting for someone to help out with #9023. Explicitly-bidirectional pattern synonyms are described in #8581. My question is: now that I have this mostly working, is this something that could be added to 7.8.3, or is this too much of a new feature for a point release? I'd like to know because then I can prioritize finishing the work (it still needs some tests added and also someone to review the changes). Thanks, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Help needed: parsing pattern synonym contexts
OK I've uploaded the code to wip/T9023 It's pushed to wip/T9023 on the GHC git repo. On Jul 3, 2014 2:32 AM, Simon Peyton Jones simo...@microsoft.com wrote: How can I reproduce? Is this on your wip/pattern-synonyms branch? Simon | -Original Message- | From: Dr. ERDI Gergo [mailto:ge...@erdi.hu] | Sent: 02 July 2014 12:45 | To: Simon Marlow | Cc: Simon Peyton Jones; GHC Devs | Subject: Re: Help needed: parsing pattern synonym contexts | | Hi, | | On Tue, 1 Jul 2014, Simon Marlow wrote: | | The s/r conflicts can also be a problem, depending on what you're | trying to | parse. It's generally a good idea to get rid of them if you can, but | at the | least you should understand why they exist (use happy --info) and | document | them in Parser.y.pp. | | OK I've uploaded the code to wip/T9023 and the happy --info report to | http://unsafePerform.IO/files/Parser.y.happy-info.gz | | Loads of shift/reduce conflicts come from state 214. Looking at them, I | would have thought that the solution would be to parse pattern synonym | definitions like we parse data constructors as types: by parsing it as a | single pattern and then splitting it. A quick shortcut to this should be | to just disable the parsing rule for infix pattern synonyms; so I tried | that. | | As expected, this cuts down on the number of shift/reduce conflicts in | that state considerably. The rest then seems to be coming from state 570: | | patsyn_context - forall . (rule 157) | patsyn_context - forall . context '=' (rule 158) | | Unfortunately, I don't have a quick workaround for that one yet. | | Thanks, | Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pretty printing
Hi, I'm getting it done later today. Bye, Gergo On Mar 19, 2014 1:36 AM, Simon Peyton Jones simo...@microsoft.com wrote: Gergo I'm a bit out of date... did you update those test results etc to get to clean validate? S ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: -ddump-types vs -fprint-explicit-foralls, and symbol-ness of worker/wrapper names [Re: [commit: ghc] master: Pretty-print the following TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom
Exactly, the problem is precisely that $foo is regarded as an infix operator in that code path, so with my change, it would be classified as prefix. On Mar 17, 2014 10:10 PM, Simon Peyton Jones simo...@microsoft.com wrote: Do they show up in -ddump-simpl? It would be nice to keep that output as readable as possible, as there are quite a few of us that read it on a regular basis. I don't think so (because -ddump-simpl doesn't print **any** operators in parens) but I could be wrong, and I agree that would be bad. Does that mean that any operator that starts with $ will now not be considered infix for printing purposes? No, I believe that Gergo's suggestion is that a function be considered infix operator (for display purposes) only if all its characters are operator chars, rather than just the first one. Simon *From:* Johan Tibell [mailto:johan.tib...@gmail.com] *Sent:* 17 March 2014 14:00 *To:* Simon Peyton Jones *Cc:* Dr. ERDI Gergo; GHC Devs *Subject:* Re: -ddump-types vs -fprint-explicit-foralls, and symbol-ness of worker/wrapper names [Re: [commit: ghc] master: Pretty-print the following TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike (065c35a) (fwd)] On Mon, Mar 17, 2014 at 2:45 PM, Simon Peyton Jones simo...@microsoft.com wrote: | The one interesting case is T4306 which fails because the generated name | $wupd is regarded as an infix name, and thus with my new code is | rendered as | |($wupd) :: GHC.Prim.Double# - GHC.Prim.Double# | | instead of the old | |$wupd :: GHC.Prim.Double# - GHC.Prim.Double# I think it'd also be ok just to accept this output too. These $wxx names are generated by GHC and won't show up in user output. It doesn't much matter displaying them in parens. Do they show up in -ddump-simpl? It would be nice to keep that output as readable as possible, as there are quite a few of us that read it on a regular basis. But changing isLexVarSym is probably equally fine too. I think (worth a check) that it's only called for display purposes, and not in any performance-critical parts. Whichever you choose, add a Note with isLexVarSym to explain the issue and the choice. Does that mean that any operator that starts with $ will now not be considered infix for printing purposes? -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Pretty-print the following TyThings via their IfaceDecl counterpart: * AnId * ACoAxiom * AConLike (065c35a)
Yes:-(
I'll unbreak them later today.
On Mar 14, 2014 4:16 AM, Johan Tibell johan.tib...@gmail.com wrote:
Could these changes be related to the validate failures I just posted
about on the mailing list?
On Thu, Mar 13, 2014 at 2:21 PM, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/065c35a9d6d48060c8fac8d755833349ce58b35b/ghc
---
commit 065c35a9d6d48060c8fac8d755833349ce58b35b
Author: Dr. ERDI Gergo ge...@erdi.hu
Date: Thu Mar 13 21:18:39 2014 +0800
Pretty-print the following TyThings via their IfaceDecl counterpart:
* AnId
* ACoAxiom
* AConLike
---
065c35a9d6d48060c8fac8d755833349ce58b35b
compiler/iface/IfaceSyn.lhs |2 +-
compiler/iface/MkIface.lhs | 10 +++-
compiler/main/PprTyThing.hs | 59
++-
3 files changed, 23 insertions(+), 48 deletions(-)
diff --git a/compiler/iface/IfaceSyn.lhs b/compiler/iface/IfaceSyn.lhs
index 8ca8582..7484b37 100644
--- a/compiler/iface/IfaceSyn.lhs
+++ b/compiler/iface/IfaceSyn.lhs
@@ -1100,7 +1100,7 @@ pprIfaceDecl (IfaceClass {ifCtxt = context, ifName
= clas, ifTyVars = tyvars,
sep (map ppr sigs)])
pprIfaceDecl (IfaceAxiom {ifName = name, ifTyCon = tycon, ifAxBranches =
branches })
- = hang (ptext (sLit axiom) + ppr name colon)
+ = hang (ptext (sLit axiom) + ppr name dcolon)
2 (vcat $ map (pprAxBranch $ Just tycon) branches)
pprIfaceDecl (IfacePatSyn { ifName = name, ifPatHasWrapper = has_wrap,
diff --git a/compiler/iface/MkIface.lhs b/compiler/iface/MkIface.lhs
index 0af9af6..51df08c 100644
--- a/compiler/iface/MkIface.lhs
+++ b/compiler/iface/MkIface.lhs
@@ -1461,7 +1461,7 @@ tyThingToIfaceDecl (AnId id) = idToIfaceDecl id
tyThingToIfaceDecl (ATyCon tycon) = tyConToIfaceDecl emptyTidyEnv tycon
tyThingToIfaceDecl (ACoAxiom ax) = coAxiomToIfaceDecl ax
tyThingToIfaceDecl (AConLike cl) = case cl of
-RealDataCon dc - pprPanic toIfaceDecl (ppr dc) -- Should be
trimmed out earlier
+RealDataCon dc - dataConToIfaceDecl dc -- for ppr purposes only
PatSynCon ps - patSynToIfaceDecl ps
--
@@ -1477,6 +1477,14 @@ idToIfaceDecl id
ifIdInfo= toIfaceIdInfo (idInfo id) }
--
+dataConToIfaceDecl :: DataCon - IfaceDecl
+dataConToIfaceDecl dataCon
+ = IfaceId { ifName = getOccName dataCon,
+ ifType = toIfaceType (dataConUserType dataCon),
+ ifIdDetails = IfVanillaId,
+ ifIdInfo= NoInfo }
+
+--
patSynToIfaceDecl :: PatSyn - IfaceDecl
patSynToIfaceDecl ps
= IfacePatSyn { ifName = getOccName . getName $ ps
diff --git a/compiler/main/PprTyThing.hs b/compiler/main/PprTyThing.hs
index 27e7390..fb92b5a 100644
--- a/compiler/main/PprTyThing.hs
+++ b/compiler/main/PprTyThing.hs
@@ -23,20 +23,18 @@ module PprTyThing (
) where
import TypeRep ( TyThing(..) )
-import ConLike
import DataCon
-import PatSyn
import Id
import TyCon
import Class
-import Coercion( pprCoAxiom, pprCoAxBranch )
+import Coercion( pprCoAxBranch )
import CoAxiom( CoAxiom(..), brListMap )
import HscTypes( tyThingParent_maybe )
-import HsBinds( pprPatSynSig )
import Type( tidyTopType, tidyOpenType, splitForAllTys, funResultTy )
import Kind( synTyConResKind )
import TypeRep( pprTvBndrs, pprForAll, suppressKinds )
import TysPrim( alphaTyVars )
+import MkIface ( tyThingToIfaceDecl )
import TcType
import Name
import VarEnv( emptyTidyEnv )
@@ -44,7 +42,6 @@ import StaticFlags( opt_PprStyle_Debug )
import DynFlags
import Outputable
import FastString
-import Data.Maybe
--
-
-- Pretty-printing entities that we get from the GHC API
@@ -76,7 +73,7 @@ pprTyThingLoc tyThing
-- | Pretty-prints a 'TyThing'.
pprTyThing :: TyThing - SDoc
-pprTyThing thing = ppr_ty_thing showAll thing
+pprTyThing thing = ppr_ty_thing (Just showAll) thing
-- | Pretty-prints a 'TyThing' in context: that is, if the entity
-- is a data constructor, record selector, or class method, then
@@ -88,7 +85,7 @@ pprTyThingInContext thing
where
go ss thing = case tyThingParent_maybe thing of
Just parent - go (getName thing : ss) parent
-Nothing - ppr_ty_thing ss thing
+Nothing - ppr_ty_thing (Just ss) thing
-- | Like 'pprTyThingInContext', but adds the defining location.
pprTyThingInContextLoc :: TyThing - SDoc
@@ -100,21 +97,17 @@ pprTyThingInContextLoc tyThing
-- the function is equivalent to 'pprTyThing' but for type constructors
-- and classes it prints only the
Re: Pattern synonyms for 7.8?
Hi, Sorry, I wasn't aware running validate was not enough. I'll check out the problems in ~10 hours. Bye, Gergo On Jan 30, 2014 7:41 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 05/01/14 12:16, Dr. ERDI Gergo wrote: Hi, When I started working on pattern synonyms (#5144) back in August, it seemed the GHC 7.8 freeze was imminent, so I was planning for a first version in 7.10/8.0 (whatever it will be called). However, since not much has happened re: 7.8 since then (at least not much publicly visible), and on the other hand, my implementation of pattern synonyms is ready, I am now starting to wonder if it could be squeezed into 7.8. What are your thoughts on this? Thanks, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs Hi again, We've ran into some trouble over at #ghc regarding Haddock updates to do with PatternSynonyms. You have updated Haddock accordingly but at the same time, you haven't checked that you haven't broken it. This means that when we were trying to quickly fix a bug today, the Haddock tests came up as failing. There at least two faults that I've spotted: * Single space added in front of every function name. This isn't visible by the user but is visible by the test-suite and would require that we update every test file for no good reason. After a long while, I narrowed it down to the line leader + ppTypeSig summary occnames pp_typ unicode as it seems that 'leader' is empty for a lot of time and the (+) function adds a single space. It'd be an easy fix if it was only this but... * Data types using infix notations are now parenthesised Haddock now renders 'data a :- b' as 'data a (:-) b'. This is a problem. I don't know what else is broken but I can't go on trying to fix this because you haven't added any tests for the features you put in! I have no idea what I'm breaking in PatternSynonyms when making changes. For now we have to revert some of the Haddock changes, namely the XHtml back-end stuff you added. The proposed revert is currently at [1] and will probably be put into the 7.8 RC very soon because the documentation for 'base' has to be generated. Please have a look and see what you can fix in the XHtml back-end for your feature. This includes making sure that the existing tests pass (you do this by running 'cabal test', just running validate for GHC is _not_ enough) and adding new tests for the things you add (you're going to be interested in adding test cases in html-test/src and adding the expected test results in html-test/ref). Thanks [1]: https://github.com/Fuuzetsu/haddock/tree/codeblockfix -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Fwd: Re: Pattern synonyms for 7.8?
Hi, How do I get permissions to push to my wip branch? Thanks, Gergo -- Forwarded message -- From: Dr. ERDI Gergo ge...@erdi.hu Date: Jan 13, 2014 8:12 PM Subject: Re: Pattern synonyms for 7.8? To: aus...@well-typed.com Cc: Gabor Greif ggr...@gmail.com (removing Mateusz and ghc-devs from the recipient list) Hi, On Mon, 13 Jan 2014, Gabor Greif wrote: From what I understood, you *should* have all permissions to push to wip/ branches. If not, please contact the admins. (IIRC Austin did this previously). OK, I think this was the missing information that got me confused. What repo are we talking about? I tried the mirror on GitHub (g...@github.com:ghc/ghc.git) but that one doesn't seem to work: ERROR: Permission to ghc/ghc.git denied to gergoerdi. fatal: Could not read from remote repository. I also tried the Haskell.org repo of ssh://g...@git.haskell.org/ghc, but that doesn't work either (which is unsurprising since I don't remember ever sending my SSH public key to haskell.org): 20:10:02 [cactus@galaxy ghc]$ git push -u origin wip/pattern-synonyms Permission denied (publickey). Please advise. Thanks, Gergo -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---' Ki volt Casper, mielôtt meghalt? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pattern synonyms for 7.8?
Hi, please don't commit it just yet, I'd like the eventual single commit to also include the user documentation. Thanks, Gergo On Jan 8, 2014 10:46 PM, Austin Seipp ase...@pobox.com wrote: Oh, to be honest, I was just going to squash it into a single Big Commit, with you set as the author, Gergo. This seems to be the general way we do it for new features. If you'd like I can just go ahead and do this for you. On Wed, Jan 8, 2014 at 8:33 AM, Dr. ERDI Gergo ge...@erdi.hu wrote: On Wed, 8 Jan 2014, Simon Peyton Jones wrote: It'd be good if what we finally commit to HEAD has a sensible history Yes, of course. I'll clean that up next week. I just have to run now. -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---' Ha paranoiásokkal akarsz megismerkedni, kezdd el követni ôket. -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pattern synonyms for 7.8?
Hi, Wow, so, I thought there would be some back-and-forth, then a decision, then I would go and walk the last mile and then formally submit the patch for review - and now I see that in 2 days all that has passed... Of course I'll make validate pass, I just didn't even know about it. Likewise, I needed the carrot of 7.8 inclusion dangling before me to start writing the user docs. One problem, though, is that I'll be on holiday from tomorrow, so I'll only have time to look into this tonight before next weekend. I'll try my best to fix up validate tonight, and I'll write the docs (which I hope will mostly be an editing job on the wiki) next week. How does that sound? Thanks, Gergo On Jan 8, 2014 3:41 AM, Austin Seipp ase...@pobox.com wrote: Hi Gergo, Thanks for rebasing your changes. Unfortunately, they do not compile cleanly with ./validate, which we really need to have working for all incoming patches. In particular, ./validate enables -Werror and a slew of warnings that you won't normally see during development, which greatly aids in keeping the code clean. One, for example, is that some of your commits introduce tabs - we ban tabs and validate errors on them! Another: the problem is that in https://github.com/gergoerdi/ghc/commit/afefa7ac948b1d7801d622824fbdd75ade2ada3f , you added a Monoid instance for UniqSet - but this doesn't work correctly. The problem is that UniqSet is just an alias for UniqFM (type UniqSet a = UniqFM a), so the instance is technically seen as an orphan. Orphan instances cause -Werror failures with ./validate (unless you disable them for that module, but here we really shouldn't.) The fix is to write the Monoid instance for UniqFM directly in UniqFM.hs instead. Likewise, here's a real bug that -Werror found in your patch in the renamer (by building with ./validate): compiler/rename/RnBinds.lhs:744:1: Warning: Pattern match(es) are non-exhaustive In an equation for `renameSig': Patterns not matched: _ (PatSynSig _ _ _ _ _) Indeed, renameSig in RnBinds doesn't check the PatSynSig case! The missing instance looks straightforward to implement, but this could have been a nasty bug waiting. If you could please take the time to clean up the ./validate failures, I'd really appreciate it. I imagine it'll take very little time, and it will make merging much easier for me. An easy way to do it is just to check out your pattern-synonyms branches, then say: $ CPUS=X sh ./validate where 'X' is the number of cores, similar to 'make -jX' If it fails, you can make a change, and keep going with: $ CPUS=X sh ./validate --no-clean and rinse and repeat until it's done. Note the --no-clean is required, since `./validate` will immediately run `make distclean` by default if you do not specify it. On Tue, Jan 7, 2014 at 5:50 AM, Dr. ERDI Gergo ge...@erdi.hu wrote: On Mon, 6 Jan 2014, Carter Schonwald wrote: as long as we clearly communicate that there may be refinements / breaking changes subsequently, i'm all for it, unless merging it in slows down 7.8 hitting RC . (its taken long enough for RC to happen... don't want to drag it out further) If that helps, I've updated the version at https://github.com/gergoerdi/ghc (and the two sister repos https://github.com/gergoerdi/ghc-testsuite and https://github.com/gergoerdi/ghc-haddock) to be based on top of master as of today. Bye, Gergo -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---' Elvis is dead and I don't feel so good either. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Pattern synonyms for 7.8?
Of course. That's how I've been keeping up with GHC proper all along. On Jan 8, 2014 7:09 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 07/01/14 23:05, Dr. ÉRDI Gergő wrote: Hi, Wow, so, I thought there would be some back-and-forth, then a decision, then I would go and walk the last mile and then formally submit the patch for review - and now I see that in 2 days all that has passed... Of course I'll make validate pass, I just didn't even know about it. Likewise, I needed the carrot of 7.8 inclusion dangling before me to start writing the user docs. One problem, though, is that I'll be on holiday from tomorrow, so I'll only have time to look into this tonight before next weekend. I'll try my best to fix up validate tonight, and I'll write the docs (which I hope will mostly be an editing job on the wiki) next week. How does that sound? Thanks, Gergo Hi Erdi, I'm hoping to push in some stuff for Haddock in few hours (or rather, have someone do it for me) but I know you have changed a few things in it for the pattern synonyms stuff. I looked at the changes and they weren't big and shouldn't clash. Is it fine with you to push the changes on our side and then have you merge on top of that or would you prefer to have it done another way? Thanks -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: 7.8 Feature window
I've updated the Wiki page to better match what I'm implementing. Apart from reorganizing the page slightly, all I really had to change was the paragraph on exporting/importing. Should I explicitly mark parts of the page that are not yet implemented? I'd think the page should stay to be about what we aim for, not what we happen to have as of some random date. On Aug 22, 2013 12:09 AM, Simon Peyton-Jones simo...@microsoft.com wrote: How long does the patch review process usually take? Just so I can factor that in when thinking of getting this into 7.8.0. There are two issues: **1. **Is the design good? Does the additional language complexity pay its way? Is the implementation reasonably simple, or unreasonably complicated? **2. ** Is the actual patch good (well-implemented, well-documented, etc) ** ** (2) is relatively straightforward, but this feature is a “big” one. I’d like to get a bit of feedback from our community. ** ** The Trac page sketches the design, but I bet you have come across some subtleties as you implemented it. (Exports for one.) Would you be willing to expand the design specification (as seen by the programmer) to be as complete as possible? Include some examples. This would best be done on the Trac wiki rather than in the ticket itself. Most of text can come from the existing writeup, but I expect you have more to add. (Or maybe not... maybe it all turned out to be very simple.) ** ** Once we have that we can send email to ghc-users pointing to the spec and asking what they think. Lots of smart people there who may well have Good Ideas. ** ** My gut feel is that, rather than rushing to throw this into 7.8, we should take a little while to think about it. Everything else we are planning for 7.8 has been in gestation for much longer. ** ** Any opinions from other ghc-devs? http://ghc.haskell.org/trac/ghc/ticket/5144 ** ** Talk later this week. Simon ** ** ** ** ** ** *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Dr. ÉRDI Gergo *Sent:* 21 August 2013 01:56 *To:* Austin Seipp *Cc:* ghc-devs@haskell.org *Subject:* Re: 7.8 Feature window ** ** On Aug 21, 2013 1:05 AM, Austin Seipp ase...@pobox.com wrote: * ERDI was working on pattern synonyms. I believe you were having some trouble with the implementation. Can someone help him if necessary? Hi, I've updated the Trac ticket with the latest status of my work. There are only two loose ends remaining, and my hope is that the second one will turn out to be some trivial oversight on my part. How long does the patch review process usually take? Just so I can factor that in when thinking of getting this into 7.8.0. Bye, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8 Feature window
On Aug 21, 2013 1:05 AM, Austin Seipp ase...@pobox.com wrote: * ERDI was working on pattern synonyms. I believe you were having some trouble with the implementation. Can someone help him if necessary? Hi, I've updated the Trac ticket with the latest status of my work. There are only two loose ends remaining, and my hope is that the second one will turn out to be some trivial oversight on my part. How long does the patch review process usually take? Just so I can factor that in when thinking of getting this into 7.8.0. Bye, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Instantiating a type with fresh, flexi type variables
Hi Simon,
Here's what I wrote earlier about this to someone who contacted me in
private (name withheld because I don't know why he contacted me off-list):
So the code in question is this:
https://github.com/gergoerdi/ghc/commit/f874f8#L5R749
and the part that feels fishy to me is tcInstTypes, both the implementation
and the fact that I have to take care of this manually. I guess the right
solution would involve doing something differently in
https://github.com/gergoerdi/ghc/commit/244b9#L3R43
so that the types in rhs_ty and args are correctly generalized. But I
haven't been able to find out how that would be done.
I'm replying to your other questions in a separate, private mail.
Thanks,
Gergo
On Aug 20, 2013 6:14 AM, Simon Peyton-Jones simo...@microsoft.com wrote:
I'm a bit puzzled that you don't have a *quantified* type, something like
forall abc. ty1 - ... - tyn - ty
to instantiate. I'm a bit suspicious about instantiating all the random
free variables of a type (or types). We should talk now I'm back in
circulation. What time zone are you in? What's your skype id? (Mine is
simonpj0)
simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Dr.
ERDI
| Gergo
| Sent: 08 August 2013 18:37
| To: ghc-devs@haskell.org
| Subject: Instantiating a type with fresh, flexi type variables
|
| For my pattern-synonyms branch (see prev. email) I had to write the
| following function, incl. making TcValidity.fvTypes public:
|
| tcInstTypes :: [TcType] - TcM [TcType]
| tcInstTypes tys
| = do { let tvs = fvTypes tys
| ; (_, _, subst) - tcInstTyVars tvs
| ; return $ map (substTy subst) tys }
|
| I'm surprised I had to write this myself, and this made me wonder if
| there's a much better way to handle cases where I have some kind of
| definition which has some inferred type, and then various use sites
| of that definition must all have types that can be unified with this
| original inferred type.
| Is there?
|
| Thanks,
| Gergo
|
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
