- ghc-devs - Haskell.org

Problems with cabal
by Эдгар Жаворонков 10 Nov '15

10 Nov '15

Hi, everyone! I have a strange problems with building GHC from sources. I cloned git repo as said in newcomers' page, but i have that kind of error: Cloning into 'libraries/Cabal'... fatal: repository 'https://github.com/ghc/packages/Cabal.git/' not found Clone of 'http://github.com/ghc/packages/Cabal.git' into submodule path 'libraries/Cabal' failed What am i doing wrong? --- С уважением, Жаворонков Эдгар Best regards, Edgar A. Zhavoronkov

2 3

Re: Questions on the RTS C API regarding threads and tasks
by Nicola Gigante 09 Nov '15

09 Nov '15

Il giorno 05 nov 2015, alle ore 05:27, Edward Z. Yang <ezyang(a)mit.edu> ha scritto: > > Excerpts from Nicola Gigante's message of 2015-11-04 11:12:39 -0800: >> I’ve started delving into the ghc runtime API to understand >> if everything we need is exposed to the world or if we >> have to modify the runtime itself (which I would avoid if possible). > > I agree with this goal in principle, but: > > (1) Depending on what you want to do, it may be quite difficult to > do this, and > > (2) The RTS is actually quite hackable (as long as you are not > changing any of the interfaces with generated Haskell code, you > could even build your own RTS and have users link against that.) > > Something to keep in mind. > Edward, thanks for the quick reply! Yes, I see that the source code is clear and well documented! :) However, this project is something we would eventually want to publish on hackage, not something of internal use. This means we'd have to contribute the runtime changes upstream, which would be cool but I assumed GHC as a project doesn't accept every experimental new feature that come across, and we don't have the energy to guarantee maintenance of this eventual contribution. An external solution would be better. > > Not easily. If you make a safe foreign call, the capability is given up > before the C code executes, so you actually lose ownership of the > capability and TSO by the time you're running C code. The only > way to write a foreign call to properly suspend the thread that called > it is a primop function (e.g. stg_putMVar), and the operation is quite > delicate and you will probably want to use some existing (internal) > code in the RTS to do it. > > But if you just need to sleep/awake threads, why not just use an MVar? We don't have measurements, but we ruled out this possibility for performance reasons. Our idea is to make a thin Haskell wrapper around a tiny bit of highly optimized C code. What's the performance of locking on MVars? While we are at it: are primops callable directly from C? I suppose calling conventions are different. A question comes to mind: you mentioned "safe" calls. Are unsafe calls different regarding the detaching of the capability? Also: would a patch to make this possible be accepted? In particular: - add a way to make a "ultraunsafe" foreign call that do not loose the ownership of the calling thread. - add a BlockedOnExplicitSleep flag for tso->why_blocked (And in turn this means managing a different blocking queue, right?) - export something to reliably put in sleep and resume threads in this way. Is this feasible? Would it be a good idea? > > Edward Thank you again, Greetings, Nicola

3 4

Re: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang
by George Colpitts 09 Nov '15

09 Nov '15

redid with just make rather than make -j5. I get ... chmod +x libraries/integer-gmp2/gmp/ln # Their cmd invocation only works on msys. On cygwin it starts # a cmd interactive shell. The replacement works in both environments. mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o igncr; export SHELLOPTS; \ PATH=`pwd`:$PATH; \ export PATH; \ cd gmpbuild && \ CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ --enable-shared=no \ --host=x86_64-apple-darwin --build=x86_64-apple-darwin /bin/sh: SHELLOPTS: readonly variable checking build system type... /bin/sh: SHELLOPTS: readonly variable /bin/sh: SHELLOPTS: readonly variable x86_64-apple-darwin checking host system type... /bin/sh: SHELLOPTS: readonly variable /bin/sh: SHELLOPTS: readonly variable x86_64-apple-darwin checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes /bin/sh: SHELLOPTS: readonly variable checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking ABI=64 checking whether clang is gcc... yes checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro alpha ev6 char spilling checking ABI=32 checking whether clang is gcc... yes *checking compiler clang -m32 -O2 -pedantic -fPIC -fomit-frame-pointer ... no, gnupro alpha ev6 char spilling* *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... no, gnupro alpha ev6 char spilling* *configure: error: could not find a working compiler, see config.log for details* *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* *make: *** [all] Error 2* On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari <ben(a)smart-cactus.org> wrote: > George Colpitts <george.colpitts(a)gmail.com> writes: > > > I get > > > > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > It looks like the build failed somewhere before this point. Could you > provide a more complete log? > > Cheers, > > - Ben > > >

1 0

Printing local Var(Id) types(in Outputable outputs)
by Ömer Sinan Ağacan 07 Nov '15

07 Nov '15

Hi all, I'm considering getting into the trouble of implementing this: A flag for printing types of local Ids. To be more specific, I'd like to see types of local Ids and binders in case expression alternatives etc. I may name it -dshow-local-id-types or something like that. An example output would be like this. Instead of: case ds_dPC of _ [Occ=Dead] { C1 l_avq -> ... C2 r_avr -> ... } It would print: case ds_dPC of _ [Occ=Dead] { C1 (l_avq :: Type1) -> ... C2 (r_avr :: Type2) -> ... } So my questions are: * Do we already have something like this? (I can't see it in man page) * Do you think, for some reason, this would be useless? (maybe there's some workaround etc. that has a similar effect) Thanks.

3 2

Implied GHC extensions (in HEAD)
by Gabor Greif 06 Nov '15

06 Nov '15

Hi devs, when compiling a snippet of code (which I have written using GHC HEAD) with GHC 7.10.2 (from the platform) I got errors about missing extension pragmas. I had to add two: > {-# LANGUAGE ViewPatterns, KindSignatures, GADTs, PolyKinds, StandaloneDeriving, FlexibleContexts, FlexibleInstances, ScopedTypeVariables, TypeFamilies, PatternSynonyms, FunctionalDependencies, RankNTypes, UndecidableInstances #-} > {-# LANGUAGE DataKinds, TypeOperators #-} -- 7.10?? Looks like the implications have been extended in 7.11. I guess PolyKinds now implies DataKinds, but cannot think of what implies TypeOperators. Was this change by design or by accident? Any ideas? Cheers, Gabor

1 0

Evaluating types and determining instantiability of an instance
by Jan Bracker 06 Nov '15

06 Nov '15

Hello, I am trying to write a type checker plugin and I noticed that I keep trying to reimplement functionality that GHC type system already implements, but I can't seem to find a way to access the functionality. Part of these features I already asked in another (previous) email [1] to the mailing list and I am sorry if this will duplicate part of that discussion. 1. Is there a function in the type system which I can use to evaluate type functions and expand type synonyms (including associated instances)? Ideally I would want something that looks like this 'Type -> TcM Type'. I know that this kind of evaluation is not necessarily possible (e.g. type variables that can't be matched against in a type function application), but it would be helpful if the function could at least evaluate/expand as far as is possible in the current context. That way I don't have to manually lookup type family instances or type synonyms and make mistakes by doing so. This would also ease the support for the different type system extensions available, which I currently have to manually reimplement. 2. If I have an instance and a number of type arguments for that instance, is there an easy way to check if that instance is instantiated by those arguments? Something of the form '[Ct] -> ClsInst -> [Type] -> TcM (Maybe EvTerm)' would be useful. This function would take the given and derived constraints and deliver evidence for the instantiation if it is possible or return nothing if it is not. Again, if there are some open type variables I know this is not always possible in general and I am aware that this, in its full generality, requires a call to the constraint solver. But currently I am manually walking through the instance constraints to check if they are instantiated given the arguments [3] and then I also manually produce evidence [2]. In that process I ignore type equalities, type synonym and type families, because that would require me to implement question 1. I suspect this kind of functionality should exists somewhere within the GHC API. I would want this function to work with type arguments, whose only type variables already occur in the given and derived constraints. I think in that case it should always be possible to determine if the instance is instantiated. Best regards, Jan Bracker [1] https://mail.haskell.org/pipermail/ghc-devs/2015-November/010342.html [2] https://github.com/jbracker/polymonad-plugin/blob/master/src/Control/Polymo… [3] https://github.com/jbracker/polymonad-plugin/blob/master/src/Control/Polymo…

3 2

Type Checker Plugin: Producing the correct evidence
by Jan Bracker 05 Nov '15

05 Nov '15

Hello, I am using type checker plugins to select specific instances in a program. My current problem concerns the following instance: class Polymonad m n p where (>>=) :: m a -> (a -> n b) -> p b instance ( Effect m, E.Inv m f (Unit m), f ~ Plus m f (Unit m)) => Polymonad (m (f :: [*])) Identity (m (f :: [*])) where ma >>= f = ma E.>>= (E.return . runIdentity . f) 'E', 'Unit' and 'Plus' refer to the module 'Control.Effect' [5] from the 'effect-monad' package. At some point in my example program [2] GHC is uncertain which instance to use for the '>>=' operator. The wanted constraint is: [W] $dPolymonad_a5Qp :: Polymonad (State '[n :-> (a :! 'W)]) Identity (State '[n :-> (a :! 'W)]) (CNonCanonical) To select the instance above I produce the following evidence: $fPolymonadmIdentitym @[State, '[n :-> (a :! 'W)]] [$fEffect[]State @[] []] 'State' is from the module 'Control.Effect.State' [4]. This works so far, but during the core-lint phase I get the following error message: <no location info>: Warning: [RHS of $dPolymonad_a5Qp :: Polymonad (State '[n_a5PL :-> (a_a5PM :! 'W)]) Identity (State '[n_a5PL :-> (a_a5PM :! 'W)])] The type of this binder doesn't match the type of its RHS: $dPolymonad_a5Qp Binder's type: Polymonad (State '[n_a5PL :-> (a_a5PM :! 'W)]) Identity (State '[n_a5PL :-> (a_a5PM :! 'W)]) Rhs type: (Inv State '[n_a5PL :-> (a_a5PM :! 'W)] (Unit State), '[n_a5PL :-> (a_a5PM :! 'W)] ~ Plus State '[n_a5PL :-> (a_a5PM :! 'W)] (Unit State)) => Polymonad (State '[n_a5PL :-> (a_a5PM :! 'W)]) Identity (State '[n_a5PL :-> (a_a5PM :! 'W)]) Which I parse as a missing proof that the instance constraints are fulfilled by the evidence. >From this I have a few questions: 1. Why doesn't the type checker prove these type equality constraints for me? (or how can I get the type checker to do so?) I checked them on paper and the constraints are solvable and the equalities are true. 2. If I can't get the type checker to solve this for me, how do I produce appropriate evidence? 3. Another issue I see is that I would need to expand the type synonym 'E.Inv' to see what constraints it contains. I there an easy way to do so in GHC? I could not find appropriate functionality. It would be very useful for me if there was a function 'Type -> TcM Type' that evaluates the type as far as possible (by evaluate I mean expand synonyms, evaluate type functions and remove equalities that hold). The example program [2] and the plugin I am developing can be found [1] on GitHub (Commit fefc149ec6e1c1a3c3c2597c66d176854b94287d ). This is how I produce the evidence for my selected instance [3]. I hope this abstract description of my problem is enough. Best regards, Jan Bracker [1] https://github.com/jbracker/polymonad-plugin [2] https://github.com/jbracker/polymonad-plugin/blob/master/examples/effect/Ma… [3] https://github.com/jbracker/polymonad-plugin/blob/master/src/Control/Polymo… [4] http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-S… [5] http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect.h…

1 0

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1
by Peter Trommler 05 Nov '15

05 Nov '15

Sent from the wrong account the first time around. > On 04.11.2015, at 17:18, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > > > On Nov 4, 2015, at 11:12 AM, Peter Trommler <Peter.Trommler(a)th-nuernberg.de> wrote: > >> It looks like a bug to me. > > I'm taking your "it" here to mean the fact that GHC is looking for readelf on a Mac OS platform. Yes. That's correct. Peter

3 3

Status of OverloadedRecordFields [Was: Re: Proposal: Dot as Postfix Function Apply]
by Adam Gundry 05 Nov '15

05 Nov '15

[copying ghc-devs as the following is perhaps more relevant there] On 04/11/15 10:44, Jeremy wrote: > Dot as Postfix Function Apply > (https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordField…) > was originally part of ORF, but dropped to keep the scope/discussion more > manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot > postfix syntax. I'm going to stay out of the discussion over the proposed syntax extension, but I feel like I should do some expectation management about ORF in GHC 8.0. As the wiki page [1] makes clear, ORF has been divided into three components, and so far only one of these is in GHC HEAD. The first part is a language extension, DuplicateRecordFields, which allows field names to be duplicated provided they are unambiguous. (It does not allow any kind of polymorphism over record fields.) This is already in HEAD. The second part is another language extension, OverloadedLabels, which introduces a new syntax #x for an identifier whose type is inferred and may depend on the text of the identifier. This is implemented and up on Phabricator [2], but not yet in HEAD. It should make GHC 8.0, but I'm wary about giving cast-iron guarantees. The third part, which is necessary for the OverloadedLabels syntax to be used for polymorphism over record fields, involves typeclass constraints that capture when a type has a particular field, with the instances provided automatically by GHC. This is not yet implemented in the intended form, and is unlikely to make GHC 8.0 (barring me having a sudden outbreak of free time...). Adam [1] https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields [2] https://phabricator.haskell.org/D1331 -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

[ANNOUNCE] GHC 7.10.3 release candidate 1
by Ben Gamari 04 Nov '15

04 Nov '15

We are pleased to announce the first (and hopefully only) release candidate for GHC 7.10.3: https://downloads.haskell.org/~ghc/7.10.3-rc1/ This includes the source tarball and bindists for 64-bit and 32-bit modern Linux (GMP 5.0 or later) and Windows. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x97DB64AD). As always, our content delivery network tends to be a bit slow on the uptake. If you see an empty directory at this URL just add a few superfluous slashes to the end; this is typically enough to fool it. The 7.10.2 release was well-behaved save a couple notable bugs; while we have merged a good number of bug fixes in 7.10.3 they were were largely low risk and so we expect that this release should be similiarly stable. The one exception to this is an upgrade of the Windows compiler toolchain to GCC 5.2. Windows users have been long suffering at the hand of our old toolchain (e.g. lack of response file support, #8596, and lack of SEH support) so we expect that this change should fix far more than breaks. We plan to make the 7.10.3 release sometime next week. Please test this as much as possible; bugs are much cheaper if we find them before the release and this will ideally be the last release of the 7.10 series. Happy testing, - Ben

9 12