- Glasgow-haskell-users

Were usage types ever in GHC
by Philip Dexter 22 Jan '16

22 Jan '16

I've recently been digging around to see if there has ever been any attempt to perform any sort of data reuse optimization in functional languages. Along with many other papers, I've come across `Once upon a type' as well as `Once upon a polymorphic type'. They both mention a desire to include a similar system in GHC. Then in `Playing by the rules: rewriting as a practical optimization technique in GHC' I see usage types mentioned in section 5.3: """ To express this, GHC adds extra usage type arguments to map, both at its definition and at its call sites. Once this is done, a specialised version of map can be compiled for the case when the usage-type argument is “once”, and a rule generated to match such calls, in exactly the same way as for specialising overloading. """ I can't tell if this is simply a hypothetical optimization or if this really happened at one point in the history of GHC. I was hoping somebody could shed some light on this topic Was a usage type system or something similar (e.g. linear type system) ever present in GHC? If it was then why was it taken out (unless I'm missing something, this optimization is not happening today)? I could guess at this and say that the gains weren't worth the overhead, but perhaps there's another reason. If it was never present, why not? There was obviously at least some interest in this sort of optimization at some point in the Haskell community and I'd be curious as to why it was never tested in GHC. Thanks! Philip Dexter

2 1

suppress warning "Defined but not used: type variable ‘x’" in GHC-8.0
by Henning Thielemann 18 Jan '16

18 Jan '16

GHC-8.0 emits several new warnings of this kind: Defined but not used: type variable ‘x’ for declarations like type instance Snd x y = y Enthusiastically, I started to replace unused type function arguments by underscores, only to find out that older GHC versions do not accept that. With what option can I disable this warning? Or can it be removed from -Wall for now?

7 10

Warnings, -Wall, and versioning policy
by Simon Marlow 13 Jan '16

13 Jan '16

Hi folks, We haven't described what guarantees GHC provides with respect to -Wall behaviour across versions, and as a result there are some differing expectations around this. It came up in this weeks' GHC meeting, so we thought it would be a good idea to state the policy explicitly. Here it is: We guarantee that code that compiles with no warnings with -Wall ("Wall-clean") and a particular GHC version, on a particular platform, will be Wall-clean with future minor releases of the same major GHC version on the same platform. (we plan to put this text in the User's Guide for future releases) There are no other guarantees. In particular: - In a new major release, GHC may introduce new warnings into -Wall, and/or change the meaning of existing warnings such that they trigger (or not) under different conditions. - GHC may generate different warnings on different platforms. (examples of this are -fwarn-overflowed-literals and -fwarn-unsupported-calling-conventions) Some rationale: - We consider any change to the language that GHC accepts to be a potentially code-breaking change, and subject to careful scrutiny. To extend this to warnings would be a *lot* of work, and would make it really difficult to introduce new warnings and improve the existing ones. - Warnings can be based on analyses that can change in accuracy over time. The -fwarn-unused-imports warning has changed a lot in what it rejects, for example. - We often introduce new warnings that naturally belong in -Wall. If -Wall was required to be a fixed point, we would have to start introducing new flags, and versioning, etc. and even keep the old implementation of warnings when they change. It would get really messy. There are some consequences to this. -Wall -Werror is useful for keeping your code warning-clean when developing, but shipping code with these options turned on in the build system is asking for trouble when building your code with different GHC versions and platforms. Keep those options for development only. Hackage already rejects packages that include -Wall for this reason. One reason we're raising this now is that it causes problems for the 3-release policy (https://prime.haskell.org/wiki/Libraries/3-Release-Policy) which requires that it be possible to write code that is Wall-clean with 3 major releases of GHC. GHC itself doesn't guarantee this, so it might be hard for the core libraries committee to provide this guarantee. I suggest this requirement be dropped from the policy. Cheers, Simon

3 4

Re: Optimization of IORefs and STRefs - comparison to g++
by Henning Thielemann 09 Jan '16

09 Jan '16

How about just using alloca, peek and poke - like C guys do in order to get C's speed?

1 0

RFC: explicit support for GADTs in Template Haskell
by Jan Stolarek 21 Dec '15

21 Dec '15

GHC Users, I am working on adding proper support for GADTs in Template Haskell. By proper I mean that GADTs data constructors will no longer be encoded using H98 data constructors, but will be represented explicity. GADTs allow to declare several constructors with the same signature: data T where MkT1, MkT2 :: T The question is whether to represent such constructors in TH syntax as: (1) GadtC [Name] [StrictType] Name [Type] -- or: (2) GadtC Name [StrictType] Name [Type] Note the difference in first field. (1) is closer to the original syntax, as it stores the list of all names in a single declaration, as was originally written in the source code. (2) requires to have a separate `GadtC` for each constructor even if constructors were declared together, as in the example above. I would like to hear from TH users which of these two representations you prefer. At the moment I have implemented (1) as it directly represents source syntax. The downside of (1) is that information whether several data constructors were declared together is not recoverable during reification, and so reifying T will yield: data T where MkT1 :: T MkT2 :: T 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.

1 0

Discovery of source dependencies without --make
by Lars Hupel 14 Dec '15

14 Dec '15

(cross-posted from [haskell-cafe]) Hi, I've got a problem in our – admittedly complex – build process. We're running an automated grading system for student-submitted homework exercises. The compilation proceeds in stages: 1) Compile a library file, marked as trustworthy 2) Compile student submissions using Safe Haskell, able to access a whitelisted set of packages and the previously compiled library files 3) Compile the test suite 4) Link everything together into an executable The invocation is similar to this: ghc -c -outputdir "$OUT" -XTrustworthy Library.hs ghc -c -outputdir "$OUT" -i"$OUT" -XSafe "$SUBMISSION" ghc -c -outputdir "$OUT" -i"$OUT" Test_Suite.hs ghc -outputdir "$OUT" -i"$OUT" -o "$OUT/runner" The second stage works well under the assumption that there's just one single submitted file. If there's more than one, I need to specify them in topological order wrt their module dependencies. Consider two simple modules: A.hs > module A where > > import B > import Library B.hs > module B where Invoking GHC with "A.hs" "B.hs" will fail: A.hs:3:1: Failed to load interface for ‘B’ My naive attempt at solving that problem was to just insert "--make" into the compiler flags. No luck, because according to [1, §4.7.3], "--make" will only look at source files and will ignore the "Library.hi" file from the previous compilation stage. If I give the path to "Library.hs" as well, GHC insists on recompiling it with changed flags ("-XSafe" instead of "-XTrustworthy"). Reading a bit further, I discovered the '-M' flag, however, not only does it output Makefile-formatted output, it also ignores .hi files. Is there any way to get the dependency discovery of '--make' without the rest? I know I could probably make it work if I made a package out of the first build stage, but I really want to avoid that in order to not increase the build complexity even further. Cheers Lars [1] <https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/separate-com…>

8 15

Optimization of IORefs and STRefs - comparison to g++
by Mateusz Kłoczko 11 Dec '15

11 Dec '15

Hello! I've performed a few simple tests using Haskell and C++ on primitives. I've compilled all Haskell programs with -O2 optimizations, and C++ ones with -O3 ghc version - 7.10.2, gcc version : 5.1.1 I'm sending the codes in the zip file. *Problem1* - 100 000 000 iterations. Time of execution (in seconds): *Int pure tail recursion*: 6.911011299962411e-2 *Int# pure tail recursion *: 4.587398100011342e-2 *IORef for loop* 1.1533970820000832 *IORef 'tail' recursion* 1.0696569040001123 *STRef for loop* 1.1545546840006864 *STRef tail recursion* 1.1110019479992843 *C++ *: 2.7e-07 The llvm version could be as fast as C++ one in this problem. Buuut... then there's *problem 2* (using if or case) - 100 000 000 iterations: *Int# tail recursion* 1.315346227000191 *IORef for loop*: 2.6442542390004746 *STRef for loop*: 2.669217500999366 *C++*: 0.158056 Here haskell is about 9 times slower than C++. *Problem 4* - executing the same functionality using bit operations - 100 000 000 iterations: *Int# tail recursion:* 0.12361123500068061 *C++:* 0.131141 So, Haskell here is as fast as C++. My question is: can IORefs and STRefs be optimized ? I would like very much to rely on them, but I would like to achieve great speeds. Also, is can one achieve good speeds of execution when using cases or ifs ? If not, what is the other way to do it ? Compiler flags, Cmm optimizations - they are all welcome. And the final question - how hard would it be to implement such optimizations in ghc compiler? Regards, Mateusz Kłoczko

3 2

[ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
by Ben Gamari 10 Dec '15

10 Dec '15

Hello everyone, We are pleased to announce the release of GHC 7.10.3: https://downloads.haskell.org/~ghc/7.10.3/ There can be found source tarballs and binary distributions for 64-bit and 32-bit modern Linux (GMP 5.0 or later), CentOS (GMP 4.0), Windows, and 64-bit Mac OS X platforms. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x97DB64AD). Significant fixes in release include changes to the simplifier's treatment of rules, the handling of Mac OS X frameworks, and support for response files to work around the restrictive command line length limit on Windows. As always, a full accounting of the changes present in this release can be found in the release notes [1]. The previous release, 7.10.2, 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. A notable exception is the upgrade of the Windows compiler toolchain to GCC 5.2. Typically we would refrain from making such large changes in a point release but Windows users have been long suffering at the hand of the old toolchain (e.g. lack of response file support, #8596, and lack of SEH support). We expect that this change should fix far more than breaks. Unfortunately, due to some oversights in the release process there are two source tarballs for this release. The first, ghc-7.10.3-src.tar.{bz2,xz}, does not include the release notes in the users guide. This is fixed in the second patchlevel release, ghc-7.10.3a-src.tar.{bz2,xz}. It is recommended that users wanting a source release use the ghc-7.10.3a-src tarballs. GHC 7.10.3 will very likely be the last release in the GHC 7 series. In the coming weeks we will be beginning the release process for GHC 8.0, which will include a number of exciting features including the merger of kinds with types, injective type families, imporved DWARF debugging information, applicative-do syntax, a Strict language extension synonyms mechanism, and more. See the GHC 8.0.1 status page for details [2]. Happy compiling! Cheers, - Ben [1] http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide//release-7-1… [2] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

5 5

Re: [Haskell-cafe] [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
by Ben Gamari 09 Dec '15

09 Dec '15

Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> writes: > On 9 December 2015 at 23:17, Ben Gamari <ben(a)well-typed.com> wrote: >> >> >> [1] http://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide//release-7-1… > > The links to Trac issues in that page seem to redirect to the same page. > Indeed, I'm trying to work out what went wrong here. I am quite looking forward to being able to drop DocBook in 8.0. Cheers, - Ben

1 0

build ghc without ghci libraries?
by Jeremy 07 Dec '15

07 Dec '15

I'm currently removing *.o after building ghc to save space (I don't need them for what I'm doing). Is there a straightforward way to tell GHC not to build them in the first place, such as --disable-library-for-ghci does for cabal, instead of deleting them after the fact? (I do need ghci support for template haskell.) To clarify, I'm building GHC itself, not using GHC to build a package. -- View this message in context: http://haskell.1045720.n5.nabble.com/build-ghc-without-ghci-libraries-tp582… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

2 2