January 2014 - Glasgow-haskell-users

RFC: include a cabal-install executable in future GHC releases
by Carter Schonwald 04 May '14

04 May '14

Hey everyone, I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install (aka cabal) executable, but not include the library deps of cabal-install that aren't already distributed with ghc.(unless ghc should have those deps baked in, which theres very very good reasons not to do.). currently if someone wants just a basic haskell install of the freshest ghc they have to install a ghc bindist, then do a boostrap build of cabal-install by hand (if they want to actually get anything done :) ). This is not a human friendly situation for folks who are new to haskell tooling, but want to try out haskell dev on a server style vm or the like! point being: It'd be great for haskell usability (and egads amounts of config time, even by seasoned users) the ghc bindists / installers included a cabal-install binary thoughts? -Carter

15 32

Static values language extension proposal
by Facundo Domínguez 30 Jan '14

30 Jan '14

Hello, With the support of Tweag I/O, Mathieu and I have been assembling a design proposal for the language extension for Static values that will take Cloud Haskell a big step forward in usability. Please, find the proposal inlined below. We are looking forward to discuss its feasibility and features with the community. Best, Facundo -- In these notes we discuss a design of the language extension proposed in [1] for Cloud Haskell. That is, support from the compiler to produce labels that can be used to identify Haskell top-level bindings across processes in a network. Static values ========= Following [1], the extension consists of a new syntactic form `static e`, along with a type constructor `StaticRef` and a function unstatic :: StaticRef a -> a The idea is that values of type `StaticRef a` uniquely identify a value that can be referred to by a global name rather than serialized over the network between processes that are instances of a single binary, because all such processes share the same top-level bindings. Generating static references ==================== We start by introducing global names. A `GlobalName` is a symbol bound in the top-level environment. It is much like global names in Template Haskell, but `GlobalNames` always refer to terms, and they include a package version. data GlobalName = GlobalName PkgName PkgVersion ModName OccName `GlobalNames` can be used as references to static values. newtype StaticRef a = StaticRef GlobalName `StaticRef a` is to `GlobalName` what `Ptr a` is to `Addr#`: a wrapper with a phantom type parameter that keeps track of the type of the value that is referenced. The special form static e is an expression of type `StaticRef a` where `e :: a` is a closed expression (meaning any free variables in `e` are bound in the top-level environment). If `e` is an identifier, `static e` just refers to it. Otherwise, the compiler needs to introduce a new top-level binding with a fresh name and the expression used as right-hand side, and the static reference would point to this top-level binding instead. Looking up static references ==================== `unstatic` is implemented as a function which finds a top-level value from the `GlobalName`, otherwise it raises an exception. It crucially relies on leveraging the system’s dynamic linker, so out-of-the-box only works with dynamically linked binaries (but see below). `unstatic` proceeds as follows: * Determines the name of the shared library from the package name and the package version. * Determines the symbol of the value by Z-Encoding the package name, the module name and the value name. * Uses the system’s dynamic linker interface to obtain the address of the symbol. * Converts the symbol to a haskell value with `GHC.Prim.addrToAny#` In principle, only symbols in shared libraries can be found. However, the dynamic linker is able to find symbols in modules that are linked statically if GHC is fed with the option -optl-Wl,--export-dynamic. A future enhancement could be to have GHC warn the user when modules using the extension are linked statically and this option is not used during linking. GHC only defines symbols for exported definitions in modules. So unstatic won’t be able to find the private bindings of a module. For this sake, the implementation of static should in addition ensure that the bindings it gets will appear in the symbol table when they are not exported by their defining modules. Template Haskell support ================== The static keyword needs to be made available in Template Haskell so the distributed-static package can benefit from this language extension. Rationale ======= We want the language extension to meet the following requirements: 1. It must be a practical alternative to the remoteTable functions in the distributed-static package. 2. It must not change the build scheme used for Haskell programs. A collection of .o files produced from Haskell source code should still be possible to link with the system linking tools. 3. It must not restrict all communicating processes using the extension to be launched from the same binary. 4. It must not significantly increase the binary size. (1) is addressed by replacing remote tables with the symbol tables produced by the compiler. Additionally, Template Haskell support is included so that the existing distributed-static package can be adapted and extended to include this extension. (2) is addressed by choosing a scheme which does not require the linker to perform any extension-specific procedure to collect the static values in various modules. There’s a trade off here though, since symbols in statically linked modules cannot be accessed unless -optl-Wl,--export-dynamic is supplied during linking. (3) is addressed by allowing programs to exchange static values for any bindings found in the modules they share. (4) is addressed by reusing the symbol tables produced by the compiler in object files rather than creating separate remote tables. About the need for using different binaries ============================== While using distributed-process we found some use cases for supporting communicating closures between multiple binaries. One of these use cases involved a distributed application and a monitoring tool. The monitoring tool would need to link in some graphics libraries to display information on the screen, none of which were required by the monitored application. Conversely, the monitored application would link in some modules that the monitoring application didn’t need. Crucially, both applications are fairly loosely coupled, even if they both need to exchange static values about bindings in some modules they shared. An analogous use case involved the distributed application and a control application that would be used to change dynamic settings of the former. Further Work ========== As the application depends on shared libraries, now a tool to collect these libraries would be required so they can be distributed together with the executable binary when deploying a Cloud Haskell application in a cluster. We won’t delve further into this problem. Another possible line of work is extending this approach so a process can pull shared objects from a remote peer, when this remote peer sends a static value that is defined in a shared object not available to the process. Integration with distributed-static ======================= The package distributed-static could either adopt this extension as the only implementation of static values, or it could support many notions of static references, say by using a type class to overload `unstatic`. class Static st s | s -> st where unstatic :: st -> s a -> Either String a where the class parameter `st` is provided for backwards compatibility with the existing scheme to provide context-dependent information. The extension we present here does not depend on this parameter, so `()` could be used for the `StaticRef` instance. instance Static () StaticRef where ... References ======== [1] Jeff Epstein, Andrew P. Black, and Simon Peyton-Jones. Towards Haskell in the cloud. SIGPLAN Not., 46(12):118–129, September 2011. ISSN 0362-1340.

9 24

GHC iOS ARMv7/ARMv7s fat support completed
by Luke Iannini 26 Jan '14

26 Jan '14

Hi folks, Happy to report that I've finished an approach to armv7/armv7s fat compilation, just in time for 7.8's imminent release. You'll find the necessary scripts here: https://github.com/ghc-ios/ghc-ios-scripts and the latest instructions for building GHC for iOS usage here: https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS I've also added support for a perf-cross BuildFlavour, which will give a higher-performance and profiling-ready build that matches what we'll be putting together as the official 7.8 GHC iOS binaries: https://ghc.haskell.org/trac/ghc/ticket/8700 Cheers Luke

2 1

Parallel building multiple targets
by Sami Liedes 23 Jan '14

23 Jan '14

Hi, I have a Haskell project where a number of executables are produced from mostly the same modules. I'm using a Makefile to enable parallel builds. I received advice[1] that ghc -M is broken, but that there is parallel ghc --make in HEAD. As far as I can tell, ghc --make does not allow building several binaries in one run, so I think it may not still be a full replacement for Makefiles. However I have a question about ghc --make that is also relevant without parallel ghc --make: If I have two main modules, prog1.hs and prog2.hs, which have mutual dependencies (for example, both import A from A.hs), is it safe to run "ghc --make prog1" in parallel with "ghc --make prog2"? IOW, is there some kind of locking to prevent both from building module A at the same time and interfering with each other? Is there a good way (either in current releases or HEAD) to build multiple binaries partially from the same sources in parallel? Sami [1] http://stackoverflow.com/questions/20938894/generating-correct-link-depende…

4 7

Re: RFC: include a cabal-install executable in future GHC releases
by Herbert Valerio Riedel 22 Jan '14

22 Jan '14

On 2014-01-22 at 10:08:02 +0100, Henning Thielemann wrote: > Am 22.01.2014 09:57, schrieb Herbert Valerio Riedel: >> On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote: >>> I feel this blurs the roles of GHC and the Platform. >> >> IMO, that's a weak argument, as the roles are already blurred: > >> GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be >> provided by the HP instead. > > At least haddock is bound to the specific GHC version. When I look at http://hackage.haskell.org/package/haddock, there are multiple versions, 2.12.0 and the 4 versions of 2.13.*, which are all declared to work with ghc == 7.6.*, that is, 5 haddock versions compatible with 3 released versions of GHC 7.6. So while it may be bound to a major version of the GHC API, haddock can obviously have more releases than GHC has releases (otherwise it could just carry GHC's version), and can therefore be updated.

2 1

--split-objs
by harry 20 Jan '14

20 Jan '14

The documentation for --split-objs states that "this only makes sense for libraries". How is an executable compiled against a split-objs library? According to https://github.com/haskell/cabal/issues/1611#issuecomment-30750655, this isn't happening by default. -- View this message in context: http://haskell.1045720.n5.nabble.com/split-objs-tp5741209.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

4 6

Re: RFC: include a cabal-install executable in future GHC releases
by Carter Schonwald 20 Jan '14

20 Jan '14

indeed, after thinking a wee bit more, yes, it'd be AMAZING if cabal devs made binaries visibly available to the community! (also, it does seem like cabal / cabal-install docs aren't super discoverable for some people) On Mon, Jan 20, 2014 at 12:24 AM, Oren Ben-Kiki <haskell-oren(a)ben-kiki.org>wrote: > Hear hear! This would be most welcome. > > > On Mon, Jan 20, 2014 at 2:14 AM, Carter Schonwald < > carter.schonwald(a)gmail.com> wrote: > >> that still requires some discovery though! The idea (i'd hope) would be >> to make the "my first ghc install on a vm" (for experts and new folks both) >> >> go from >> >> #install ghc via whatever mechanism, eg wget, guntar, cd blah ; make >> install PREFIX=yah >> #figure out how to install cabal, eg discover wget and then ./bootstrap >> # cabal install thingsIwannaTry >> >> to >> # install ghc via some wget and make >> #cabal install nice things >> >> >> On Sun, Jan 19, 2014 at 7:11 PM, Mikhail Glushenkov < >> the.dead.shall.rise(a)gmail.com> wrote: >> >>> Hi, >>> >>> On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald >>> <carter.schonwald(a)gmail.com> wrote: >>> > >>> > point being: It'd be great for haskell usability (and egads amounts of >>> > config time, even by seasoned users) the ghc bindists / installers >>> included >>> > a cabal-install binary >>> >>> For Windows, we provide a stand-alone cabal.exe on the Cabal site [1]. >>> I guess we could do the same for Linux and OS X. >>> >>> [1] http://www.haskell.org/cabal/download.html >>> >>> -- >>> () ascii ribbon campaign - against html e-mail >>> /\ www.asciiribbon.org - against proprietary attachments >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> >

1 0

GADT records revisited
by "Philip K.F. Hölzenspies" 17 Jan '14

17 Jan '14

Dear all, I was playing around with GADT-records again and ran into behaviour that I'm not sure is intentional. Given this program: {-#LANGUAGE GADTs #-} data FooBar x a where Foo :: { fooBar :: a } -> FooBar Char a Bar :: { fooBar :: a } -> FooBar Bool a GHC tells me this: foo.hs:3:1: Constructors Foo and Bar have a common field `fooBar', but have different result types In the data declaration for `FooBar' Failed, modules loaded: none. The user guide does say (section 7.4.7): "However, for GADTs there is the following additional constraint: every constructor that has a field f must have the same result type (modulo alpha conversion)." So this behaviour is documented in the user guide. However, it seems reasonable that in the case above, where all the relevant variables are exposed in the result type of both constructors, this should be perfectly typeable. In other words, shouldn't GHC be able to derive a type that is simply: fooBar :: FooBar x a -> a ? Is this something that was simply never implemented, but could be, or is this not decidable or prohibitively computationally complex? Regards, Philip

3 2

Enabling TypeHoles by default
by Krzysztof Gogolewski 15 Jan '14

15 Jan '14

Hello, As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by default. Rationale: (1) This way holes are far easier to use; just entering "_" allows to check type of a subexpression, no need of adding "-XTypeHoles". (2) This affects error messages only; i.e. the set of programs that compile stays the same - Haskell 2010. The only exception is that if you use -fdefer-type-errors, then a program with a hole compiles, but this seems fine with philosophy of -fdefer-type-errors. If so: would you like it to be in 7.8 or wait a cycle? My preference is 7.8, two people (John and Richard) suggested 7.10. -KG

14 24

Feature request: Vacuous/error constraint (related to 7.7 closed type families regression)
by Merijn Verstraaten 14 Jan '14

14 Jan '14

I was trying to fix one of my closed type families examples for the new syntax, and run into an unfortunate issue. Due to a kind error in my code one of my constraints was being silently discarded (see ticket: https://ghc.haskell.org/trac/ghc/ticket/8669) The main reason I resorted to this (in hindsight) ill-kinded hack is the lack of a vacuous (i.e. never holding) constraint to produce type errors. I would love to be able to explicitly force GHC into realising "this constraint can never hold", if I had the ability to pass along a String/Symbol to be reported to the user, that would be even better. Cheers, Merijn

3 2