- ghc-devs - Haskell.org

Support for colors in ghci
by Никита Нежевский 23 Mar '16

23 Mar '16

Hello I'm newcomer in GHC. I'd like to realize native support for colors in ghci (this feature was described in https://ghc.haskell.org/trac/ghc/ticket/10073 ). Is it possible to realize inside ghci? If possible i'd like to understand how to start implementation and how it might look in ghci? Best regards, Nikita Nezhevskii.

2 1

lookupRdrNameInModuleForPlugins with constructors
by Conal Elliott 23 Mar '16

23 Mar '16

I'm trying to construct a dictionary in a GHC plugin. I'm stuck on finding the constructor for the dictionary. When I use `-ddump-simpl` on the module that defines the class, I see "Circat.Rep.C:HasRep". To try finding that constructor, I say > lookupRdrNameInModuleForPlugins hsc_env > (mkModuleName "Circat.Rep") (mkVarUnqual "C:HasRep") However, I keep getting `Nothing` as a result. (Same without the "C:".) I've also had this same difficulty when looking up constructors for algebraic data types and when looking up TyCons. For regular value Ids, lookup succeeds. What am I missing? Thanks, - Conal

3 6

VisibleTypeApplication and AllowAmbiguousTypes
by Andrew Martin 22 Mar '16

22 Mar '16

I'm posting this because Richard said it would be the best place to raise this issue. I know it's a little bit late in the GHC8 development process, but I would like to get the idea out there. To my knowledge, in GHC8, turning on VisibleTypeApplication will also turn on AllowAmbiguousTypes. I think that a better behavior for most end users would be to not have this happen. I need AllowAmbiguousTypes turned on in modules where I want to declare functions that are presently uncalled. At a call site though, I only need VisibleTypeApplication, not both extensions. The only reason I bring this up is because having AllowAmbiguousTypes on is usually bad. It makes it possible to write functions that don't work, but you don't learn that until you get to the call site. If I write libraries that require VisibleTypeAppliaction to call certain functions, I don't want users accidentally ending up turning on AllowAmbiguousTypes in their own code. -- -Andrew Thaddeus Martin

5 6

Could we promote unlifted tuples?
by David Feuer 21 Mar '16

21 Mar '16

At present, currying and uncurrying at the type level doesn't seem to work terribly well. In particular, the kinds (a, b) -> c and a -> b -> c aren't really isomorphic, because (a, b) can be stuck. This makes some things (like expressing Atkey-style indexed functors in terms of McBride-style ones) rather awkward, and difficult or impossible to really get quite right. The thought came to me that maybe we could allow unlifted tuples to be promoted. Then something of the kind (# a, b #) would unconditionally unify with '(# a, b #). The restrictions on how values of unlifted tuple types can be used would presumably translate directly to restrictions on how types of unlifted tuple kind can be used. David Feuer

2 1

Issue using StrictData
by Andrés Sicard-Ramírez 20 Mar '16

20 Mar '16

Hi, I know this isn't a convenient issue report because the "test case" isn't easily reproducible. Since I don't understand the issue, I don't know how to create a smaller test case, sorry. My OS is Ubuntu 12-04 (64 bits) and I'm using the following programs: Agda master branch on commit https://github.com/agda/agda/commit/181a954a40b137c8deb1df801a8ee55fdbc19116 GHC ghc-8.0 branch on commit https://git.haskell.org/ghc.git/commit/a96933017470d03a1c9414c9c90dfd5c0f09… $ cabal --version cabal-install version 1.23.0.0 compiled using version 1.23.1.0 of the Cabal library (compiled with GHC 7.10.3) $ alex --version Alex version 3.1.7, (c) 2003 Chris Dornan and Simon Marlow $ happy --version Happy Version 1.19.5 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow After adding `extensions: StrictData` to Agda.cabal, I'm getting the following errors: $ cabal install ... Installing library in /home/asr/.cabal/lib/x86_64-linux-ghc-8.0.0.20160316/Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU Installing executable(s) in /home/asr/.cabal/bin Generating Agda library interface files... agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Primitive! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Bool! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Char! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Coinduction! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Equality! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Float! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.FromNat! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.FromNeg! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.FromString! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.IO! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Int! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.List! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Nat! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Reflection! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Size! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Strict! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.String! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.TrustMe! agda: Internal Happy error CallStack (from HasCallStack): error, called at templates/GenericTemplate.hs:288:17 in Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser WARNING: Failed to typecheck Agda.Builtin.Unit! Registering Agda-2.5.0... cabal: Leaving directory '.' Installed Agda-2.5.0 Best, -- Andrés

2 2

Updatable, single entry, one-short thunks and lambda
by Joachim Breitner 17 Mar '16

17 Mar '16

Dear list, in the literature, the code and the comments, I often find these notions: * updatable * single-entry * one-shot applied to thunks, functions, closures and lambda expressions on various levels I have the impression that these are indeed plain synonyms (resp. antinyms) when it comes to thunks and other closures, and indicate whether a dynamic instance of this closure is going to be entered once or more than once, while "one-shot", when applied to a lambda expression (or, by extension function argument), indicates that this lambda expression is _called_ at most once for every _evaluation_ of it. Is that about right, or are there more pitfalls around? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 2

Syntax changes due to TypeInType
by Matthew Pickering 16 Mar '16

16 Mar '16

Hello, I'm trying to update the haskell-src-exts parser for the syntax changes in GHC 8 but I'm struggling to find information about what exactly the kind equalities patch has changed. Could someone please give me a brief overview about what changes were made to the parser? I was waiting for the manual entry (D1995) but whilst it is illuminating about the semantic changes, the syntactic changes are a bit less clear to me. A very high-level overview would be helpful so I can then look at the diff to find the finer details. Matt

2 1

RE: Semantics of IORefs in GHC
by Simon Peyton Jones 14 Mar '16

14 Mar '16

Maclan I’m glad you enjoyed the awkward squad paper. I urge you to write to the Haskell Café mailing list and/or ghc-devs. Lots of smart people there. Ryan Newton is working on this kind of stuff; I’ve cc’d him. But my rough answer would be: IORefs are really only meant for single-threaded work. Use STM for concurrent communication. That’s not to say that we are done! The Haskell community doesn’t have many people like you, who care about the detail of the memory model. So please do help us :). For example, perhaps we could guarantee a simple sequential memory model without much additional cost? Simon From: Madan Musuvathi Sent: 11 March 2016 19:35 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Semantics of IORefs in GHC Dear Simon, I really enjoyed reading your awkward squad paper<http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/…>. Thank you for writing such an accessible paper. My current understanding is that the implementation of IORefs in GHC breaks the simple semantics you develop in this paper. In particular, by not inserting sufficient fences around reads and writes of IORefs, a Haskell program is exposed to the weak-memory-consistency effects of the underlying hardware and possibly the backend C compiler. As a result, the monadic bind operator no longer has the simple semantics of sequential composition. Is my understanding correct? This is very troublesome as this weaker semantics can lead to unforeseen consequences even in pure functional parts of a program. For example, when a reference to an object is passed through an IORef to another thread, the latter thread is not guaranteed to see the updates of the first thread. So, it is quite possible for some (pure functional) code to be processing objects with broken invariants or partially-constructed objects. In the extreme, this could lead to type-unsafety unless the GHC compiler is taking careful precautions to avoid this. (Many of these problems are unlikely to show up on x86 machines, but will be common on ARM.) I am sure the GHC community is addressing these problems one way or the other. But, my question is WHY? Why can’t GHC tighten the semantics of IORefs so that the bind operation simply means sequential composition? Given that Haskell has a clean separation between pure functional parts and “awkward” parts of the program, the overheads of these fenced IORefs should be acceptable. My coauthors and I wrote a recent SNAPL article<http://research.microsoft.com/apps/pubs/default.aspx?id=252150> about this problem for other (“less-beautiful” :)) imperative languages like C# and Java. I really believe we should support sequential composition in our programming languages. madan

3 2

Loading GHC into GHCi (reprise)
by Erik de Castro Lopo 14 Mar '16

14 Mar '16

Hi all, Recently Richard showed us how to load GHC into CHCi which ended up being documented here: https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler That very useful for some things, but doesn't give you access to symbols and types that have not been exported. Specifically, I'm interested in some of the inner workings of the file `compiler/llvmGen/LlvmCodeGen.hs` and I've even managed to load it into GHCi using the command line: inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci -fobject-code \ -DSTAGE=1 -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen \ -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn \ -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen \ -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename \ -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn \ -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils \ -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen \ -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/. \ -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -XHaskell2010 \ compiler/llvmGen/LlvmCodeGen.hs and it loads all the modules require, but then seems to mess up the symbol table so that it can't even find top level functions in the module it has just loaded. Prelude LlvmCodeGen> :t LlvmCodeGen.cmmDataLlvmGens <interactive>:1:1: error: Not in scope: ‘LlvmCodeGen.cmmDataLlvmGens’ No module named ‘LlvmCodeGen’ is imported. I even tied adding `-icompiler/llvmGen` to the above command line (from hell) before I noticed that it was already present. Anyone have any idea why this doesn't work? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

4 6

Fwd: Reducing boilerplate
by Sylvain Henry 14 Mar '16

14 Mar '16

Hi devs, I would like to add the support for the following automatic instance-deriving extension: module M where class G a where doG :: a -> Int class P a where doP :: a -> Int doP _ = 10 deriving instance G a where -- automatically derived instance doG = doP data X = X instance P X -- derive G X automatically print (doG X) -- print 10 See the forwarded mail below for the real context. This extension has been proposed by someone before as InstanceTemplates: https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates I have modified the parser and the renamer accordingly to get: class M.G a_awb where M.doG :: a_awb -> Int class M.P a_ap6 where M.doP :: a_ap6 -> Int M.doP _ = 10 instance M.G a_ap6 where M.doG = M.doP I am new to the compiler part of GHC, so I have a few questions before I continue: 1a) does it make sense to store the renamed class instance declaration in an interface file? (supposing it only uses exported methods/types; we could check that) 1b) will it be possible to create a new instance declaration in another module by just doing the substitution [a_ap6 -> X] in it? (i.e. when we parse "instance P X", do we know that it means [a_ap6 -> X] in class P (and not [a -> X])?) 2) maybe I should go a different way and store only the derived instance methods as we store class default methods? Any insight appreciated! Thanks, Sylvain ---------- Forwarded message ---------- From: Sylvain Henry <hsyl20(a)gmail.com> Date: 2016-03-05 14:56 GMT+01:00 Subject: Reducing boilerplate To: Haskell Cafe <haskell-cafe(a)haskell.org> Hi, To write FFI bindings, I use c-storable-deriving [1] to automatically derive CStorable instances for many data types (the only difference between Storable and CStorable is that CStorable provides default methods for types that have Generic instances): {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DeriveAnyClass #-} ... data X = X { fieldStatus :: Vector 24 Word8 , fieldPadding :: Word8 } deriving (Generic, CStorable) However I also need a Storable instance, hence I have to write (the "c*" methods are provided by CStorable): instance Storable X where peek = cPeek poke = cPoke alignment = cAlignment sizeOf = cSizeOf Is there a way to automatically generate this instance for every data that has an instance of CStorable? Ideally, I would like to say once and for all: instance CStorable a => Storable a where peek = cPeek poke = cPoke alignment = cAlignment sizeOf = cSizeOf As I don't think it is currently possible, would it be sensible to add the support for automatically derived instances attached to classes (as a GHC extension)? Regards, Sylvain [1] https://hackage.haskell.org/package/c-storable-deriving

3 4