- ghc-devs - Haskell.org

Trying to resurrect nofib/fibon
by Gracjan Polak 22 Dec '16

22 Dec '16

Hi all, I went into the rabbit hole that starts here https://ghc.haskell.org/trac/ghc/ticket/11501 So far I know that: 1. fibon is not built regularly by any CI and it bitrotted significantly. 2. Makefile's for fibon use undefined variables like INPLACE_HSC2HS_PGM. Probably those were sourced from ghc/mk/*.mk, but not now. 3. Haskell courses are pre-AMP (this is easiest to fix). 4. Makefile's build object files one by one and that fails in case modules depend on each other. ghc-paths.mk sorts objects and that gives wrong compile order. Does anybody know a commit-hash or date when it did compile last time? Knowing that this module (fibno) wasn't used for so long does it make sense to fix it? How about removing it? -- Gracjan

1 0

Retro-Haskell: can we get seq somewhat under control?
by David Feuer 22 Dec '16

22 Dec '16

In the Old Days (some time before Haskell 98), `seq` wasn't fully polymorphic. It could only be applied to instances of a certain class. I don't know the name that class had, but let's say Seq. Apparently, some people didn't like that, and now it's gone. I'd love to be able to turn on a language extension, use an alternate Prelude, and get it back. I'm not ready to put up a full-scale proposal yet; I'm hoping some people may have suggestions for details. Some thoughts: 1. Why do you want that crazy thing, David? When implementing general-purpose lazy data structures, a *lot* of things need to be done strictly for efficiency. Often, the easiest way to do this is using either bang patterns or strict data constructors. Care is necessary to only ever force pieces of the data structure, and not the polymorphic data a user has stored in it. 2. Why does it need GHC support? It would certainly be possible to write alternative versions of `seq`, `$!`, and `evaluate` to use a user-supplied Seq class. It should even be possible to deal with strict data constructors by hand or (probably) using Template Haskell. For instance, data Foo a = Foo !Int !a would translate to normal GHC Haskell as data Foo a = Seq a => Foo !Int !a But only GHC can extend this to bang patterns, deal with the interactions with coercions, and optimize it thoroughly. 3. How does Seq interact with coercions and roles? I believe we'd probably want a special rule that (Seq a, Coercible a b) => Seq b Thanks to this rule, a Seq constraint on a type variable shouldn't prevent it from having a representational role. The downside of this rule is that if something *can* be forced, but we don't *want* it to be, then we have to hide it a little more carefully than we might like. This shouldn't be too hard, however, using a newtype defined in a separate module that exports a pattern synonym instead of a constructor, to hide the coercibility. 4. Optimize? What? Nobody wants Seq constraints blocking up specialization. Today, a function foo :: (Seq a, Foldable f) => f a -> () won't specialize to the Foldable instance if the Seq instance is unknown. This is lousy. Furthermore, all Seq instances are the same. The RTS doesn't actually need a dictionary to force something to WHNF. The situation is somewhat similar to that of Coercible, *but more so*. Coercible sometimes needs to pass evidence at runtime to maintain type safety. But Seq carries no type safety hazard whatsoever--when compiling in "production mode", we can just *assume* that Seq evidence is valid, and erase it immediately after type checking; the worst thing that could possibly happen is that someone will force a function and get weird semantics. Further, we should *unconditionally* erase Seq evidence from datatypes; this is necessary to maintain compatibility with the usual data representations. I don't know if this unconditional erasure could cause "laziness safety" issues, but the system would be essentially unusable without it. 4. What would the language extension do, exactly? a. Automatically satisfy Seq for data types and families. b. Propagate Seq constraints using the usual rules and the special Coercible rule. c. Modify the translation of strict fields to add Seq constraints as required. David Feuer

3 3

Confused about the sub-modules
by Erik de Castro Lopo 22 Dec '16

22 Dec '16

Hi all, I'm a bit confused about how the GHC dev tree handles submodules like libraries/Cabal, libraries/process, libraries/directory and libraries/containers. All of these libraries/submodules seem to have their own github projects where people can submit PRs, but once the commits have been made there, what is the process to get submodules updated in the GHC tree? Any light people can shed on this process would be appreciated. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

6 8

Improving DeriveTraversable
by David Feuer 22 Dec '16

22 Dec '16

The role system is not currently able to use GND to derive Traversable instances. While we wait for future research to solve that problem, I think it would be nice to address a problem that can arise with DeriveTraversable: when newtypes stack up, fmaps also stack up. I've come up with a trick that I think could help solve the problem in at least some important cases. There may be a nicer solution (perhaps using associated types?), but I haven't found it yet. What I don't know is whether this arrangement works for all important "shapes" of newtypes, or what might be involved in automating it. -- Represents a traversal that may come up with a type that's -- a bit off, but not too far off. If you think about Coyoneda, this type -- might make more sense. Whereas Coyoneda builds up larger and -- larger *function compositions*, we just keep changing the coercion -- types. data Trav t b where Trav :: Coercible x (t b) => (forall f a . Applicative f => (a -> f b) -> t a -> f x) -> Trav t b class (Foldable t, Functor t) => Traversable t where traverse :: Applicative f => (a -> f b) -> t a -> f (t b) -- This new method is not intended to be exported by Data.Traversable, -- but only by some ghc-special module. trav :: Trav t b trav = Trav traverse {-# INLINE trav #-} Here are some sample newtype instances. -- Convenience function from Data.Profunctor.Unsafe (#.) :: Coercible b c => (b -> c) -> (a -> b) -> a -> c _ #. g = coerce g {-# INLINE (#.) #-} -- Convenience function for changing a Trav type retrav :: Coercible u t => (forall a . u a -> t a) -> Trav t b -> Trav u b retrav extr (Trav t) = Trav ((. extr) #. t) -- Function for defining traverse proper. Note that this should -- *only* be used to define traverse for newtype wrappers; -- for other types, it will add an unnecessary fmap. travTraverse :: forall f t a b . (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b) travTraverse = case trav :: Trav t b of Trav t -> \f xs -> fmap coerce (t f xs) {-# INLINE travTraverse #-} -- Sample types newtype F t x = F {getF :: t x} deriving (Functor, Foldable) newtype G t x = G {getG :: t x} deriving (Functor, Foldable) newtype H f x = H {getH :: F (G f) x} deriving (Functor, Foldable) instance Traversable t => Traversable (F t) where traverse = travTraverse trav = retrav getF trav instance Traversable t => Traversable (G t) where traverse = travTraverse trav = retrav getG trav instance Traversable t => Traversable (H t) where traverse = travTraverse trav = retrav getH trav With these instances, traversing H t a will perform one fmap instead of three. David Feuer

1 0

Re: Help needed: Restrictions of proc-notation with RebindableSyntax
by Edward Kmett 21 Dec '16

21 Dec '16

The S&D parser I was referring to was based on tracking FIRST sets, and provided a nice linear time parsing bound for (infinite) LL(1) grammars. (You can't really compute FOLLOW sets without knowing the grammar has a finite number of productions, but FIRST sets work perfectly well with infinite grammars.) By doing so you can transform parsing into more or less a series of map lookups for dispatch. You need to carry a set of all characters that a parser will consume in the case of legal parses, and whether or not the parser accepts the empty parse. http://www.cse.chalmers.se/~rjmh/afp-arrows.pdf mentions this style of FIRST-set tracking parser as the original motivation for arrows. Of course, they didn't see fit to stop puttering around with parsers after 1998, so referring to "the S&D parser" is quite ambiguous! =) -Edward On Wed, Dec 21, 2016 at 4:00 AM, Henrik Nilsson < Henrik.Nilsson(a)nottingham.ac.uk> wrote: > Hi Edward, > CC Others, > > On 12/21/2016 05:15 AM, Edward Kmett wrote: > >> Arrows haven't seen much love for a while. In part this is because many >> of the original applications for arrows have been shown to be perfectly >> suited to being handled by Applicatives. e.g. the Swiestra/Duponcheel >> parser that sort of kickstarted everything. >> > > Thanks for a very thorough reply. > > A quick side-remark: a parser library due to Sweistra (and maybe > Dupncheel, I can't remember) used an applicative structure a long time > before applicatives became apkicatives and even idioms. (I used a > variation of this library myself for the Freja compiler around 1995. > Freja was part of my PhD work and was close to what Haskell looked like at > the time.) > > I've never used arrows for parsing, or seen the need for arrows in that > context, but find arrows a very good fit for many EDSLs, including > stream-processing/FRP/Yampa of course, along with other circuit-like > abstractions, which I'd say were the original motivation for arrows. > Altenkirch have also used arrow-like notions in the context of quantum > computation. More recently for probabilistic programming and > Bayesian inference. Except then that the current hard-wired "pseudo- > product" in particular often gets in the way. Along with the fact > that there is no good support for constrained arrows (or monads). > > Best, > > /Henrik > > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > >

1 0

Reading source annotations during type checking
by Alejandro Serrano Mena 20 Dec '16

20 Dec '16

Dear GHC devs, Is there a way to retrieve "source annotations" (as defined by https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_g…) during type checking. In particular, I am interested in reading them in TcExpr and TcCanonical. Regards, Alejandro

3 3

Will directory 1.3.0.0 be shipped with GHC 8.0.2?
by Andrés Sicard-Ramírez 20 Dec '16

20 Dec '16

Dear all, I got directory 1.3.0.0 after installing GHC 8.0.2 RC2 (which hasn't been announced) using: $ git clone http://git.haskell.org/ghc.git $ cd ghc $ git checkout ghc-8.0.2-rc $ git submodule update --init $ perl boot $ ./configure $ make $ make install Will GHC 8.0.2 do a major version bump of directory? Best, -- Andrés La información contenida en este correo electrónico está dirigida únicamente a su destinatario y puede contener información confidencial, material privilegiado o información protegida por derecho de autor. Está prohibida cualquier copia, utilización, indebida retención, modificación, difusión, distribución o reproducción total o parcial. Si usted recibe este mensaje por error, por favor contacte al remitente y elimínelo. La información aquí contenida es responsabilidad exclusiva de su remitente por lo tanto la Universidad EAFIT no se hace responsable de lo que el mensaje contenga. The information contained in this email is addressed to its recipient only and may contain confidential information, privileged material or information protected by copyright. Its prohibited any copy, use, improper retention, modification, dissemination, distribution or total or partial reproduction. If you receive this message by error, please contact the sender and delete it. The information contained herein is the sole responsibility of the sender therefore Universidad EAFIT is not responsible for what the message contains.

2 1

haskell.org not sending intermediate certs
by Edward Z. Yang 19 Dec '16

19 Dec '16

See: https://www.sslshopper.com/ssl-checker.html#hostname=www.haskell.org This is causing curl to fail to download it: ezyang@sabre:~/Downloads$ curl https://www.haskell.org/cabal/release/cabal-install-1.24.0.0/cabal-install-… curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. Apologies if this is the wrong list. Thanks, Edward

3 3

Re: Help needed: Restrictions of proc-notation with RebindableSyntax
by Richard Eisenberg 19 Dec '16

19 Dec '16

> On Dec 17, 2016, at 9:19 AM, Ross Paterson <R.Paterson(a)city.ac.uk> wrote: > > On Tue, Nov 29, 2016 at 12:41:53PM +0000, Simon Peyton Jones wrote: >> Type checking and desugaring for arrow syntax has received Absolutely >> No Love for several years. I do not understand how it works very well, >> and I would not be at all surprised if it is broken in corner cases. >> >> It really needs someone to look at it carefully, document it better, and >> perhaps refactor it – esp by using a different data type rather than >> piggy-backing on HsExpr. > > HsCmd was split from HsExpr in 2012. It still re-uses MatchGroup, Stmt, > etc, though. > > The desugaring is made more complicated by doing a lot of analysis that > might be better done in the renamer. And -- unrelated to the original post in this thread -- these complications in desugarer (specifically, the use of fixM) are making my incoming levity-polymorphism update much harder (see https://phabricator.haskell.org/D2852) Even if you don't have time to make the edits yourself, if you could give a 10,000 ft view as to how to remove fixM from the desugarer, I'd be very grateful. I've not looked deeply at this, mostly because it's hard for me to make anything but very local changes to code I don't understand. Thanks! Richard

1 0

Patch for time repository
by Edward Z. Yang 18 Dec '16

18 Dec '16

Hi all, I'd like to push the following patch (see bottom of email) to GHC's time repository, but I do not seem to have permissions. Upstream has already taken the fix but the version we currently have in the repo is quite a bit older than upstream. Can someone do it for me / give me bits? Thanks. Edward commit 44c23839f964592946c889626f8acbd1f4f72e55 Author: Edward Z. Yang <ezyang(a)cs.stanford.edu> Date: Sat Dec 17 20:05:11 2016 -0800 Remove useless internal library version bounds. These bounds never do anything, and in Cabal HEAD cause errors which cause GHC's build system to choke. Signed-off-by: Edward Z. Yang <ezyang(a)cs.stanford.edu> diff --git a/time.cabal b/time.cabal index 4a6eb02..28f2c21 100644 --- a/time.cabal +++ b/time.cabal @@ -100,7 +100,7 @@ test-suite ShowDefaultTZAbbreviations ghc-options: -Wall -fwarn-tabs build-depends: base, - time == 1.6.0.1 + time main-is: ShowDefaultTZAbbreviations.hs test-suite tests @@ -122,7 +122,7 @@ test-suite tests build-depends: base, deepseq, - time == 1.6.0.1, + time, QuickCheck >= 2.5.1, test-framework >= 0.8, test-framework-quickcheck2 >= 0.3,

1 1