December 2015 - Glasgow-haskell-users

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 13 Dec '15

13 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 09 Dec '15

09 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

Re: [Haskell-beginners] DOOM rewritten in the Haskell programming language.
by Alexander Berntsen 07 Dec '15

07 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 David, I think it would be more valuable to make a DOOM-like game than to remake DOOM. Especially if you are going to aim for funding. The free software community has had this problem for years, where we point to remakes of old games as evidence to viability. It isn't. Nobody will be swayed by Haskell DOOM. (Although I would, personally, think it interesting.) Good luck with your project. - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWZWV0AAoJENQqWdRUGk8B0bMQAKu/4hBeS7Iz23IMIatrc5Jd hkWm/bG8FRCtiLyETiH9NtUL5RPtmS+s3+o05h6fZZ1VFFfzucygsmOTw27kWApc ZpZiypv22y7uJsrbyxFgXVp2w6vfp6rrdA+vRSOUp/dmJ+vnn7jVeGUInnlAKX50 WAsEUPx0q4IhGnF/2O3kBuKw/baGvp2kne2IjrgdAJ5qptVEvVoAEpIG3WveTnlP LQMBwTLrB+TkdTIZWTYUT/e8MYZorU5x6LN+GtKuO28PEEG0jS2IgfNeUnzZjalF p37Av84UCiIhTQD3LV6Eq1sQThQMVMm/S+qkqZrNL3I/+TbS3Ztf6q7u7zDRCsnr vum2JR0f9vtGfpd5j3hGVXjQTd0jU3uFdY1kHM0ISGTSKYrOGYs4qsCL/VxPubo8 Lh7YfCltXY+LQkz/Q2FElcd9eM9xYWSOBhPhiudXZ3f+PnkBNRwH03eWk/LHgmhB MByAdf2WCAU4DK7xpJKkCVsyOlsC17t8CtKDIfnt/RkPUr8108i6KOh6zvDR94Du lJyQWuCbL7FFb7uXVO7cKTeWJFejd/K5GrQBTBpVEy3xA15c8Kj+9ALWrdJAlion ktS85eEcp/3IzrNpPby8lhjJvujwzbzny+a9Jdn8ZcybBwpF3+IRSARnb7lJ4Yba Ca972BfXJnFZXiYARfov =mGnp -----END PGP SIGNATURE-----

2 1

Re: [Haskell-cafe] [Haskell-beginners] DOOM rewritten in the Haskell programming language.
by Oliver Charles 07 Dec '15

07 Dec '15

On Sun, Dec 6, 2015 at 5:19 PM Henk-Jan van Tuyl <hjgtuyl(a)chello.nl> wrote: > On Sun, 06 Dec 2015 16:21:15 +0100, David Blubaugh > <davidblubaugh2000(a)yahoo.com> wrote: > > > TO ALL, > > Hello My name is David Allen Blubaugh. I am currently considering > > starting a kick-starter project in redeveloping the DOOM source code > > with the Haskell Programming language using the power of > > functional-oriented programming...... > > I know that John Carmack was interested in the Haskell programming > > language and had even recreated wolfenstein 3D using the Haskell > > programming language. Does anybody have a copy of John Carmack's > > recreation of wolfenstein 3D using haskell ??? Also would anybody enjoy > > working with this project ??? What benefits would DOOM have enjoyed had > > ID software created the DOOM source code in 1993 with Haskell or some > > other functional-oriented programming language instead of C/assembly > > programming languages ??? Thanks, > > David Allen BlubaughElectrical EngineerATR Associate > > I don't know about his source code, but the Games page[0] lists: > - hadoom > A clone of Doom, using reactive-banana, GTK, and the "diagrams" > library. > https://github.com/ocharles/hadoom Possibly worth noting that hadoom is not a source-port of Doom - it's inspired by Doom's approach to level editing (2.5D), but beyond that there isn't much cross over. For example, I use full triangulation for rendering via OpenGL, rather than building my own rendering engine. The level format is also different from WAD. <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> Ollie

1 0

Segfault when doing hs_init()/hs_exit() multiple times
by Alp Mestanogullari 02 Dec '15

02 Dec '15

Hello everyone, I'm currently calling Haskell code from C. My goal is to apply a Haskell function to each element of some dataset that I get from outside Haskell-land. For now, before I make this fancier and more efficient, the plan is to just bring the RTS up with hs_init, call my Haskell function (exporter to C with 'foreign export ccall [...]') on the element and finally shut the RTS down, doing this for every element. When running this, I realized the RTS was running into a segfault when calling the Haskell function on the second element. This led me to believe it wasn't possible to call hs_init()/hs_exit() multiple times in the same program. But then I checked the Haskell 2010 report, FFI section [1], and it says: *The function hs_init() initialises the Haskell system and provides it with the available command line arguments. Upon return, the arguments solely intended for the Haskell runtime system are removed (i.e., the values that argc and argv point to may have changed). This function must be called during program startup before any Haskell function is invoked; otherwise, the system behaviour is undefined. Conversely, the Haskell system is deinitialised by a call to hs_exit(). Multiple invocations of hs_init() are permitted, provided that they are followed by an equal number of calls to hs_exit() and that the first call to hs_exit() is after the last call to hs_init(). In addition to nested calls to hs_init(), the Haskell system may be de-initialised with hs_exit() and be re-initialised with hs_init() at a later point in time. This ensures that repeated initialisation due to multiple libraries being implemented in Haskell is covered. * Which means, if I understand correctly, that what I want, while very inefficient, should work fine. I've put together a minimal example that exhibits the problem, which can be found at https://github.com/alpmestan/simple-c-export : - https://github.com/alpmestan/simple-c-export/blob/master/run-haskell.c shows the C code that brings the RTS up and down, with some printf statements to show what's going on. - https://github.com/alpmestan/simple-c-export/blob/master/Foo.hs shows the trivial Haskell function I'm exposing. - https://github.com/alpmestan/simple-c-export/blob/master/simple-c-export.ca… contains the build options I'm compiling the code with When running this on my machine (OS X, ghc 7.8.3 and 7.10.2), I always get: $ cabal run simple-c Preprocessing executable 'simple-c' for simple-c-export-0.1... Linking dist/build/simple-c/simple-c ... Running simple-c... #0 - Launching RTS... #0 - RTS started! Calling Haskell function... 0 #0 - Killing RTS now... #0 - RTS killed! #1 - Launching RTS... #1 - RTS started! Calling Haskell function... Segmentation fault: 11 Is there something special I should do to make this work, that I'm overlooking? Or is this a bug (that I should report on Trac, I guess) ? Thanks in advance for any clarification on this. -- Alp Mestanogullari

2 3

ghci - running functions defined in a where clause
by Harendra Kumar 01 Dec '15

01 Dec '15

In ghci, is there a way to address and run functions defined in the where clause of a function? I do not see those functions available in the scope. Is this supported? I can imagine two classes of functions in a where clause. Functions which refer to the bindings in the surrounding scope and those which do not refer to any outside bindings. I guess the latter should be easier to support if we can refer to it or bring it in the current scope somehow. Thanks, harendra

1 0