- ghc-devs - Haskell.org

Type class for sanity
by David Feuer 25 Jan '16

25 Jan '16

Since type families can be stuck, it's sometimes useful to restrict things to sane types. At present, the most convenient way I can see to do this in general is with Typeable: type family Foo x where Foo 'True = Int class Typeable (Foo x) => Bar x where blah :: proxy x -> Foo x This will prevent anyone from producing the bogus instance instance Bar 'False where blah _ = undefined Unfortunately, the Typeable constraint carries runtime overhead. One possible way around this, I think, is with a class that does just sanity checking and nothing more: class Sane (a :: k) instance Sane Int instance Sane Char instance Sane 'False instance Sane 'True instance Sane '[] instance Sane '(:) instance Sane (->) instance Sane 'Just instance Sane 'Nothing instance (Sane f, Sane x) => Sane (f x) To really do its job properly, Sane would need to have instances for all sane types and no more. An example of an insane instance of Sane would be instance Sane (a :: MyKind) which would include stuck types of kind MyKind. Would it be useful to add such an automatic-only class to GHC? David

3 5

Re: Type class for sanity
by David Feuer 25 Jan '16

25 Jan '16

See https://typesandkinds.wordpress.com/2015/09/09/what-are-type-families/ for some discussion. A type family application is stuck if it can't reduce further and has not reached a proper type. Given the aforementioned type family Foo, the application Foo 'False is stuck. It's a type of kind *, and it's uninhabited (but not as nicely uninhabited as Void--it offers no ex falso). This actually turns out to be useful for some things. GHC offers type family Any :: k where {} which is, at least, 1. A safe intermediate target for unsafeCoerce 2. An utterly unsatisfiable constraint (see the definition of Bottom in the GitHub master of the reflection package) But sometimes you want to know something's *not* a stuck type family. See the issue I filed earlier today at https://github.com/kwf/ComonadSheet/issues/6 for an example--the code tries to make a certain instance impossible to produce, but the possibility of stuckness defeats it as its currently written. On Jan 25, 2016 1:01 AM, "Jeffrey Brown" <jeffbrown.the(a)gmail.com> wrote: > "Stuck type" is proving difficult to Google. Do you recommend any > references? > > On Sun, Jan 24, 2016 at 1:24 PM, David Feuer <david.feuer(a)gmail.com> > wrote: > >> Since type families can be stuck, it's sometimes useful to restrict >> things to sane types. At present, the most convenient way I can see to >> do this in general is with Typeable: >> >> type family Foo x where >> Foo 'True = Int >> >> class Typeable (Foo x) => Bar x where >> blah :: proxy x -> Foo x >> >> This will prevent anyone from producing the bogus instance >> >> instance Bar 'False where >> blah _ = undefined >> >> Unfortunately, the Typeable constraint carries runtime overhead. One >> possible way around this, I think, is with a class that does just >> sanity checking and nothing more: >> >> class Sane (a :: k) >> instance Sane Int >> instance Sane Char >> instance Sane 'False >> instance Sane 'True >> instance Sane '[] >> instance Sane '(:) >> instance Sane (->) >> instance Sane 'Just >> instance Sane 'Nothing >> instance (Sane f, Sane x) => Sane (f x) >> >> To really do its job properly, Sane would need to have instances for >> all sane types and no more. An example of an insane instance of Sane >> would be >> >> instance Sane (a :: MyKind) >> >> which would include stuck types of kind MyKind. >> >> Would it be useful to add such an automatic-only class to GHC? >> >> David >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > > -- > Jeffrey Benjamin Brown >

1 0

Options -Wmissed-specialisations, -Wall-missed-specialisations and -Werror
by Andrés Sicard-Ramírez 23 Jan '16

23 Jan '16

Dear all, In GHC 8 RC 1, the `-Wmissed-specialisations` and `-Wall-missed-specialisations` options generate a warning instead of an error when using `-Werror`. Is it the expected behaviour? Best, -- Andrés

2 1

Fwd: Fwd: Host-Oriented Template Haskell
by Ericson, John 23 Jan '16

23 Jan '16

Oops, Sent just to Edward by mistake. ---- That all sounds good to me---I think what I was thinking all along in fact, unless I am still missing some nuance :). My idea of using a multi-target compiler was to avoid needing stage0 to be the same version as stage1 (or adding a new stage, stage1 as in your alternative). The cross compiler is multi-target so it doesn't need to link another compiler to load plugins / run "host-oriented Template Haskell". I mentioned the usecase of trying to build a stage2 which needs plugins / Host-Oriented Template Haskell, but it could well apply to building anything else with the need for those to things (and not normal TH, which cannot be built with a cross compiler) In diagrams, rather than: > stage0 (version foo, platform-x -> platform-x) > ==> stage1 (version foo, platform-x -> platform-y) > ==> some program (with plugins, with host-oriented TH, without normal TH) or > stage0 (version bar, platform-x -> platform-x) > ==> stage1 (version foo, platform-x -> platform-x) -> > ==> stage2 (version foo, platform-x -> platform-y) -> > ==> some program (with plugins, with host-oriented TH, without normal TH) do just > stage0 (version bar, platform-x -> platform-x) > ==> stage1 (version foo, platform-x -> {platform-x, platform-y}) > ==> some program (with plugins, with host-oriented TH, without normal TH) Now it may be that building such a multi-target compiler today is just as arduous as making sure one has a native compiler of the same version before building the cross compiler, so my idea is of no practical value. But if so, I hope in the long term that could be fixed. John On Wed, Jan 20, 2016 at 8:37 PM, Edward Z. Yang <ezyang(a)mit.edu> wrote: > Hello John, > > Almost! > > As you point out, if you just want a cross-compiler, you don't > need to build stage2. The real problem is that we want stage0 > to be *the same version* as stage1, so that stage0 has the correct > API in order to load stage0 libraries which are going to be used > for TH, plugins, etc. (Alternately, build a non-cross-compiler > stage1, and then a cross-compiler stage2--NOT a cross compiled > stage 2.) > > Edward > > Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800: >> From #11378: >> >> > Can we actually link against the old version of ghc? Yes we can! All we need is >> > (1) for it to have been built with a different IPID, and >> > (2) to use module renaming to rename the relevant modules to a different >> > module name, so that we can import them without a conflict. >> >> >> If I understand this, you are saying stage1 links stage0 (the normal, >> non-cross-compiler used to build stage1), to build stage2? I agree >> that should work, but if stage1 is multi-target isn't that level of >> complexity not even needed? I'm not too familiar with GHC or its build >> system, but a multi-target compiler that doesn't support normal TH >> doesn't seem that hard to build in principle. >> >> John >> >> On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John <john_ericson(a)brown.edu> wrote: >> > Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-} >> > imports is precisely equivalent to what I propose. I find a clean >> > separation with that and normal TH useful, however, precisely so the >> > stage2 compiler's source can include such a thing. >> > >> > On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang <ezyang(a)mit.edu> wrote: >> >> Hello John >> >> >> >> You may find this implementation ticket of interest: >> >> https://ghc.haskell.org/trac/ghc/ticket/11378 >> >> >> >> Edward >> >> >> >> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800: >> >>> Cross-posting this as was suggested on the Haskell-Cafe list. While I >> >>> envision this as normal feature that anyone can use, in practice its >> >>> biggest consumers would be GHC devs. >> >>> >> >>> John >> >>> >> >>> ---------- Forwarded message ---------- >> >>> From: Ericson, John <john_ericson(a)brown.edu> >> >>> Date: Tue, Jan 19, 2016 at 1:17 PM >> >>> Subject: Host-Oriented Template Haskell >> >>> To: Haskell-Cafe <haskell-cafe(a)haskell.org> >> >>> >> >>> >> >>> As is well known, TH and cross-compiling do not get along. There are >> >>> various proposals on how to make this interaction less annoying, and I >> >>> am not against them. But as I see it, the problem is largely inherent >> >>> to the design of TH itself: since values can (usually) be lifted from >> >>> compile-time to run-time, and normal definitions from upstream modules >> >>> to downstream modules' TH, TH and normal code must "live in the same >> >>> world". >> >>> >> >>> Now this restriction in turn bequeaths TH with much expressive power, >> >>> and I wouldn't advocate getting rid of it. But many tasks do not need >> >>> it, and in some cases, say in bootstrapping compilers[1] themselves, >> >>> it is impossible to use TH because of it, even were all the current >> >>> proposals implemented. >> >>> >> >>> For these reason, I propose a new TH variant which has much harsher >> >>> phase separation. Normal definitions from upstream modules can not be >> >>> used, lifting values is either not permitted or is allowed to fail >> >>> (because of missing/incompatible definitions), and IO is defined to >> >>> match the behavior of the host, not target, platform (in the cross >> >>> compiling case). The only interaction between the two phases is that >> >>> quoted syntax is resolved against the the run-time phase's definitions >> >>> (just like today). >> >>> >> >>> Some of you may find this a shoddy substitute for defining a subset of >> >>> Haskell which behaves identically on all platforms, and optionally >> >>> constraining TH to it. But the big feature that my proposal offers and >> >>> that one doesn't is to be able to independently specify compile-time >> >>> dependencies for the host-oriented TH---this is analogous to the >> >>> newish `Setup.hs` dependencies. That in turns leads to what I think is >> >>> the "killer app" for Host-Oriented TH: exposing the various >> >>> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, >> >>> and side-stepping any need for "executable dependencies" in Cabal. >> >>> Note also that at least hsc2hs additionally requires host-IO---there >> >>> may not even exist a C compiler on the target platform at all. >> >>> >> >>> Finally, forgive me if this has been brought up before. I've been >> >>> thinking about this a while, and did a final pass over the GHC wiki to >> >>> make sure it wasn't already proposed, but I could have missed >> >>> something (this is also my first post to the list). >> >>> >> >>> John >> >>> >> >>> [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Intern… >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs(a)haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

3 4

Phabricator upgrade - CI will be down for a short time
by Austin Seipp 21 Jan '16

21 Jan '16

Hi *, TL;DR Phabricator will go down for about 5 minutes later today, but the CI will be off for a while longer. I wanted to alert everyone: I'll be upgrading Phabricator shortly this morning, after doing a bunch of testing to make sure our upgrade will go smoothly. Luckily, it will go quite smoothly. The upgrade on the database backup I performed went without a hitch, and everything still seems to work quite well. You shouldn't really notice a huge difference in day-to-day usage... However, it will require redoing some pieces of the CI system, so when I do the upgrade, _Harbormaster won't work for a short time_. That means your patches won't get built - do not be alarmed by this. I tested this before, but we'll have to do some other changes to make it happen 'for real' this time (including some CDN fiddling). Ben also recently rewrote the terrible build script I originally wrote, so I'd like to deploy it instead if possible. Thomas has also rightfully prodded me about some of the current CI complaints, so hopefully these can be sorted out too. This upgrade has been long in the tooth, but luckily you shouldn't notice much beyond a minor hitch here, and CI being gone for a little while. Hopefully it should be done by the end of the day. In the mean time, I'll give Ben access to the newer (20 core) buildbot, so he'll be able to validate your changes quite quickly for integration. I'll reply to this email with updates. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 3

Re: Special treatment of family and role in the parser
by Jan Stolarek 21 Jan '16

21 Jan '16

I'll take a look at the parser, see if we can do better. > I also suggest that keywords introduced by GHC extensions should be lexed as keywords regardless > of whether extension is enabled or not: this way users won't get spurious errors if they > suddenly enable extension and it turns out that some of their identifiers have become keywords. I would be cautious here. Patch I am working on right now will use "kind" as a reserved identifier. It will only be allowed after `data` keyword. Making it a reserved word everywhere would be a major issue as many people doing type-level programming have variables named "kind". You ar right that problem would be much smaller if the keyword was "datakind" but somehow I am reluctant to seeing things like "datakindmember", "typeinstance", etc. What others think about this proposal? Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

3 3

RE: GHC 8.0.1 RC 1 and the -fwarn-monomorphism-restriction option
by Simon Peyton Jones 21 Jan '16

21 Jan '16

No, if that answers your question, good. Ben: is this change in the release notes? Simon | -----Original Message----- | From: andres.sicard.ramirez(a)gmail.com | [mailto:andres.sicard.ramirez@gmail.com] On Behalf Of Andrés Sicard- | Ramírez | Sent: 21 January 2016 13:25 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Cc: Thomas Miedema <thomasmiedema(a)gmail.com> | Subject: Re: GHC 8.0.1 RC 1 and the -fwarn-monomorphism-restriction | option | | On 21 January 2016 at 08:11, Simon Peyton Jones | <simonpj(a)microsoft.com> wrote: | > Can you give a small concrete test case, showing the different | behaviour? | | I received this answer from Thomas Miedema: | | Thomas Miedema <thomasmiedema(a)gmail.com> wrote: | > Reinstate monomorphism-restriction warnings | > | > This patch is driven by Trac #10935, and reinstates the | > -fwarn-monomorphism-restriction warning. It was first lost in | 2010: | > d2ce0f52d "Super-monster patch implementing the new typechecker | -- at | > last" | > | > I think the existing documentation is accurate; it is not even | > turned on by -Wall. | > | > I added one test. | | It was exactly what I was looking for. Do you still need a concrete | test case? | | -- | Andrés

2 2

GHC 8.0.1 RC 1 and the -fwarn-monomorphism-restriction option
by Andrés Sicard-Ramírez 21 Jan '16

21 Jan '16

Dear all, On 13 January 2016 at 10:43, Ben Gamari <ben(a)well-typed.com> wrote: > The GHC Team is very pleased to announce the first release candidate of > the Glasgow Haskell Compiler 8.0.1 release. For compiling Agda we use the -fwarn-monomorphism-restriction option. Using GHC 7.6.3, 7.8.4 and 7.10.3 we don't get any warning, but using GHC 8.0.1 RC 1 this option generates warnings in 103 files. Could someone give me some information about this new behaviour? Best, -- Andrés

1 0

Fwd: Host-Oriented Template Haskell
by Ericson, John 21 Jan '16

21 Jan '16

Cross-posting this as was suggested on the Haskell-Cafe list. While I envision this as normal feature that anyone can use, in practice its biggest consumers would be GHC devs. John ---------- Forwarded message ---------- From: Ericson, John <john_ericson(a)brown.edu> Date: Tue, Jan 19, 2016 at 1:17 PM Subject: Host-Oriented Template Haskell To: Haskell-Cafe <haskell-cafe(a)haskell.org> As is well known, TH and cross-compiling do not get along. There are various proposals on how to make this interaction less annoying, and I am not against them. But as I see it, the problem is largely inherent to the design of TH itself: since values can (usually) be lifted from compile-time to run-time, and normal definitions from upstream modules to downstream modules' TH, TH and normal code must "live in the same world". Now this restriction in turn bequeaths TH with much expressive power, and I wouldn't advocate getting rid of it. But many tasks do not need it, and in some cases, say in bootstrapping compilers[1] themselves, it is impossible to use TH because of it, even were all the current proposals implemented. For these reason, I propose a new TH variant which has much harsher phase separation. Normal definitions from upstream modules can not be used, lifting values is either not permitted or is allowed to fail (because of missing/incompatible definitions), and IO is defined to match the behavior of the host, not target, platform (in the cross compiling case). The only interaction between the two phases is that quoted syntax is resolved against the the run-time phase's definitions (just like today). Some of you may find this a shoddy substitute for defining a subset of Haskell which behaves identically on all platforms, and optionally constraining TH to it. But the big feature that my proposal offers and that one doesn't is to be able to independently specify compile-time dependencies for the host-oriented TH---this is analogous to the newish `Setup.hs` dependencies. That in turns leads to what I think is the "killer app" for Host-Oriented TH: exposing the various prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, and side-stepping any need for "executable dependencies" in Cabal. Note also that at least hsc2hs additionally requires host-IO---there may not even exist a C compiler on the target platform at all. Finally, forgive me if this has been brought up before. I've been thinking about this a while, and did a final pass over the GHC wiki to make sure it wasn't already proposed, but I could have missed something (this is also my first post to the list). John [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Intern…

2 4

ghci and unfoldings?
by Conal Elliott 21 Jan '16

21 Jan '16

I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci to speed up development. I'm able to do so, except that my plugin critically needs access to unfoldings, which appear to be unavailable in ghci. A little experimenting with ghc shows me that "-O" is the key, but "-O" is incompatible with "--interactive" (as in ghci). Is there any way to persuade ghci to make unfoldings available? Thanks, - Conal

5 11