News aggregator

The GHC Team: GHC 7.10 Prelude: we need your opinion

Planet Haskell - Tue, 02/10/2015 - 9:52am

This post asks for your help in deciding how to proceed with some Prelude changes in GHC 7.10. Please read on, but all the info is also at the survey link, here: ​http://goo.gl/forms/XP1W2JdfpX. Deadline is 21 Feb 2015.

The Core Libraries Committee (CLC) is responsible for developing the core libraries that ship with GHC. This is an important but painstaking task, and we owe the CLC a big vote of thanks for taking it on.

For over a year the CLC has been working on integrating the Foldable and Traversable classes (shipped in base in GHC 7.8) into the core libraries, and into the Prelude in particular. Detailed planning for GHC 7.10 started in the autumn of 2014, and the CLC went ahead with this integration.

Then we had a failure of communication. As these changes affect the Prelude, which is in scope for all users of Haskell, these changes should be held to a higher bar than the regular libraries@ review process. However, the Foldable/Traversable changes were not particularly well signposted. Many people have only recently woken up to them, and some have objected (both in principle and detail).

This is an extremely unfortunate situation. On the one hand we are at RC2 for GHC 7.10, so library authors have invested effort in updating their libraries to the new Prelude. On the other, altering the Prelude is in effect altering the language, something we take pretty seriously. We should have had this debate back in 2014, but here we are, and it is unproductive to argue about whose fault it is. We all share responsibility. We need to decide what to do now. A small group of us met by Skype and we've decided to do this:

  • Push back GHC 7.10's release by at least a month, to late March. This delay also gives us breathing space to address an unrelated show-stopping bug, Trac #9858.
  • Invite input from the Haskell community on which of two approaches to adopt (​this survey). The main questions revolve around impact on the Haskell ecosystem (commercial applications, teaching, libraries, etc etc), so we want to ask your opinion rather than guess it.
  • Ask Simon Marlow and Simon Peyton Jones to decide which approach to follow for GHC 7.10.

Wiki pages have been created summarizing these two primary alternatives, including many more points and counter-points and technical details:

This survey invites your input on which plan we should follow. Would you please

  • Read the details of the alternative plans on the three wiki pages above
  • Add your response to ​the survey

Please do read the background. Well-informed responses will help. Thank you!

DEADLINE: 21 February 2015

Simon PJ

Categories: Offsite Blogs

Why all the tooling woes?

Haskell on Reddit - Tue, 02/10/2015 - 9:05am

I have seen a lot of discussion (and complaints) about the Haskell toolchain on this forum.

One popular area of discussion has to do with resolving dependencies, dealing with breaking changes, and deciding who should maintain backwards compatibility (and how).

This is sort of an umbrella issue for topics like "what's up with Cabal", or, "too much CPP is happening!"

I'm wondering why we seem to discuss these issues so much more within the Haskell community than within, say, the Ruby or Clojure communities.

The too-convenient explanation is to say, "in the Ruby and Clojure universes, it doesn't matter if there are subtle errors in the way dependencies interact, since people can release their code anyway; with Haskell, we reject invalid programs, so this class of programs can't be released"

I imagine that there is some truth to the above explanation; what are the other root causes that force us to debate the aforementioned dependency-resolution-umbrella-issue more than other language communities?

submitted by skatenerd
[link] [7 comments]
Categories: Incoming News

Cross-Compiling GUI Libraries from Linux to Windows

Haskell on Reddit - Tue, 02/10/2015 - 3:23am

I'm not sure this is the best venue for this, but I wanted to gather all of this in one place and I don't have a good place to put it.

I'm not too experienced with Haskell, but I've been wanting to use it for a while. However, most of the projects I want to do are small cross-platform GUI utilities to replace Clojure+Swing to fix: how bad Swing looks, the size of a full Clojure JAR, Clojure's start times, and the need for the JVM. So, I tried to get Gtk2Hs, wxHaskell, and HsQML to work. I'm currently using Fedora 20, so I first tried the MinGW compiler packaged with that. I didn't get too far with that. I turned to the next best thing: Wine (by the time I was done with this, I could have used some of the more drinkable kind). I started by installing the 32-bit Haskell Platform 2014.2.0.0 in Wine and adding that to the path. That worked just fine: I could run wine cabal and wine ghc.

To start, I tried installing wxHaskell. I started by trying to compile wxWidgets, but their directions recommended using MSYS2, which I found doesn't work with Wine. I eventually downloaded wxPack, which is about a gigabyte. While following the wiki page on installing wxHaskell in Windows, I also had to remove the "48" from "lib/gcc48_lib" and "lib/gcc48_dll" in wxPack to make the paths match. Installing wxHaskell 0.91.0.0 from Hackage failed with:

src\cpp\glcanvas.cpp:43:60: error: 'wxGLContext' has not been declared src\cpp\glcanvas.cpp:102:1: error: 'wxGLContext' does not name a type src\cpp\glcanvas.cpp:109:1: error: 'wxGLContext' does not name a type src\cpp\glcanvas.cpp:116:1: warning: '__cdecl__' attribute only applies to function types src\cpp\glcanvas.cpp:116:1: error: 'wxGLContext' was not declared in this scope src\cpp\glcanvas.cpp:116:1: error: 'self' was not declared in this scope src\cpp\glcanvas.cpp:116:1: error: expected primary-expression before 'void' src\cpp\glcanvas.cpp:116:1: error: initializer expression list treated as compound expression src\cpp\glcanvas.cpp:117:1: error: expected ',' or ';' before '{' token

So, I installed from the wxHaskell Git repository by putting "wine" in front of every mention of "cabal" in the bin/mk-cabal script and ran that. Then I compiled a small Hello World program. I copied the appropriate DLLs next to that program and tried running it. That failed with:

err:module:attach_process_dlls "wxc.dll" failed to initialize, aborting

Looking at more verbose debug messages pointed toward an exception being raised while wxc.dll was loading. I really wasn't sure where to go from there, so I gave up on wxHaskell.

Next, I tried HsQML. Fortunately, the directions on that site worked more or less perfectly. I compiled the hsqml-demo-samples to make sure they worked. My first problem was how the directories were arranged by Cabal; since I wanted it to work as a portable application, the executable should be at the root. Running cabal configure --bindir=$prefix --datadir=$prefix/data before building fixed that. Then, I needed to gather the dependencies into the application directory. In the case of the demos, those are:

  • <Qt directory>/qml/QtQuick/ -> ./QtQuick/
  • <Qt>/qml/QtQuick.2/ -> ./QtQuick.2/
  • <Qt>/plugins/platforms/qwindows.dll -> ./platforms/qwindows.dll
  • icudt53.dll (the rest of these are from <Qt>/bin to the executable directory)
  • icuin53.dll
  • icuuc53.dll
  • libgcc_s_dw2-1.dll
  • libstdc++-6.dll
  • Qt5Core.dll
  • Qt5Gui.dll
  • Qt5Network.dll
  • Qt5Qml.dll
  • Qt5Quick.dll
  • Qt5Widgets.dll

My next biggest concern was the size of all of these dependencies, which came out to about 50 MB. First, I stripped everything, which helped a little. Next, I tried UPX, which cut it almost in half. Finally, I found that icudt53.dll, which started out at 22 MB and compressed to about 8 MB, could shrink further by customizing the included ICU data, as described in this forum post, which has a reduced DLL. That pushed all the dependencies down to 16 MB. With the first OpenGL demo as an example app (820 KB compressed), it was possible to put everything needed into a ZIP file of 11 MB while uncompressing to 17 MB. One last note on Qt: while testing in a Windows VM, I found that Qt would not work (failing with errors like unable to resolve `glBindBuffer`) because I needed to upgrade VirtualBox Guest Additions and enable 3D acceleration.

The last one I tried was Gtk2Hs. The directions only talk about GTK+ 2. Following them works fine, but GTK+ 2 didn't look very native. However, following those directions, but substituting the GTK+ 2 bundle for the GTK+ 3 bundle and installing the gtk3 package worked fine. I was able to compile a simple Hello World. For deployment, I copied all of the DLLs from the bin directory of the GTK bundle. I also noticed that the font didn't look native either, which was fixed by adding a etc/gtk-3.0/settings.ini file with the executable containing:

[Settings] gtk-font-name = Tahoma 8

All those DLLs took up 23 MB. Running them through UPX compressed them down to 9 MB. Together with the application (4 MB compressed), a complete distributable ZIP took only 7 MB.

So, after all that work, as well as many failures along the way, I was able to compile Windows executables in Linux using only free software, while avoiding recompiling any of the large GUI toolkits. I was also able to fulfill all my goals. Gtk2Hs was the most painless and the smallest. On the other hand, I've always disliked how GTK looks. HsQML, while immature, gives me Qt, which I think looks better than GTK, while not being much larger, once you use the minimal ICU DLL. More objectively, I think data binding with QML is really convenient and useful, as it enables better separation of concerns.

In summary, I couldn't get wxHaskell to work, Gtk2Hs and HsQML worked, and I think Qt is pretty and cool.

submitted by TJSomething
[link] [5 comments]
Categories: Incoming News

Noam Lewis: Inference of ‘new’ statements, and ambiguous types

Planet Haskell - Tue, 02/10/2015 - 2:16am

To prevent possible name clashes, the name of my type inference engine for JavaScript is now Inferny Infernu . I hope I don’t have to change the name again!

In other news, here is some recent progress:

‘new’ now requires ‘this’ to be a row type

I changed inference of ‘new’ calls, so that the constructed function must have a row type as it’s “this” implicit parameter (nothing else makes sense).

The change to “new” typing made it possible to define the built in String, Number, Boolean type coercion functions in a way that disallows constructing them (e.g. “new String(3)”) which is considered bad practice in JavaScript. The reason is that the constructed values are “boxed” (kind of) so that they don’t equate by reference as normal strings, booleans and numbers do. For example, new String(3) == '3' but at the same time, new String(3) !== '3'.

Ambiguous Types

I added an initial implementation of what I call ambiguous types. These are simple type constraints that limit a type variable to a set of specific types.

The motivation for type constraints is that some JavaScript operators make sense for certain types, but not all types. So having a fully polymorphic type variable would be too weak. For example, the + operator has weird outputs when using all sorts of different input types (NaNNaNNaNNaNNaNNaN….batman!). I would like to constrain + to work only between strings or between numbers.

With the new type constraints, + has the following type:

a = (TNumber | TString) => ((a, a) -> a)

The syntax is reminiscent of Haskell’s type classes, and means: given a type variable “a” that is either a TNumber or a TString, the type of + is: (a, a) -> a

I’m thinking about implementing full-blown type classes, or alternatively, a more powerful form of ambiguous types, to deal with some other more complicated examples.


Tagged: Haskell, Javascript
Categories: Offsite Blogs

Data.Graph nitpicks

libraries list - Tue, 02/10/2015 - 1:15am
Hi folks, I was just using the stronglyConnComp function in Data.Graph and found some minor annoying things: 1. stronglyConnComp takes an out-list as input. On the other hand, none of the other graph algorithms, like dfs, etc do this. stronglyConnComp seems to basically be an algorithm on graphs, so why doesn't it take the graph as input? Can we change stronglyConnComp to take a graph as input? That would make the interface more uniform. 2. Why is stronglyConnComp in a special haddock section whereas all the other algorithms are in the "Algorithms" section? How about we group it with all the other algorithms? 3. Why are there are so few instances of SCC? In particular, why not derive Show and Eq? Cheers, Andi _______________________________________________ Libraries mailing list Libraries< at >haskell.org http://www.haskell.org/mailman/listinfo/libraries
Categories: Offsite Discussion

Fun with fibonacci

Haskell on Reddit - Tue, 02/10/2015 - 12:50am
Categories: Incoming News

Injective type families for GHC

haskell-cafe - Mon, 02/09/2015 - 5:58pm
Haskellers, I am finishing work on adding injective type families to GHC. I know that in the past many people have asked for this feature. If you have use cases for injective type families I would appreciate if you could show them to me. My implementation has some restrictions and I want to see how severe these restrictions are from a practical point of view. Janek --- Politechnika Łódzka 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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

4Yr PostDoc with McBride/Ghani

General haskell list - Mon, 02/09/2015 - 5:06pm
Please forward to anyone you think might be interested cheers neil Salary range: £30434 - £34,233 FTE: 1.0 Term: Fixed Term (4 years) Closing date: 23 February 2015 Applications are invited for a Research Associate to work under the supervision of Professor Neil Ghani and Dr Conor McBride on the EPSRC grant "Homotopy Type Theory: Programming and Verification". Homotopy Type Theory (HoTT) is a revolutionary new approach to type theory where types are interpreted as spaces, terms as points and equalities as paths. Decades of research in homotopy theory has uncovered the structure of such paths and HoTT uses this structure as the basis of a new theory of equality. Excitingly, within homotopy theory, one naturally studies higher homotopies of paths between paths and this gives the higher dimensional structure of equality we previously lacked. The objective of this grant is to translate the advances of HoTT into more concrete programming language and verification tools. You will join a team consis
Categories: Incoming News

Cabal: Missing field in record constructionconfigProf

haskell-cafe - Mon, 02/09/2015 - 3:00pm
L.S., I am trying to install a package with the new GHC 7.10 RC 2 (I recompiled cabal.exe with it, and now "cabal update" finally works again). The install fails, even after renaming the cabal config file: Config file path source is default config file. Config file C:\Users\X\AppData\Roaming\cabal\config not found. Writing default configuration to C:\Users\X\AppData\Roaming\cabal\config Resolving dependencies... Configuring random-1.1... cabal: Distribution\Client\Config.hs:(246,37)-(299,9): Missing field in record construction configProf What does this message mean? How can I correct this? Regards, Henk-Jan van Tuyl
Categories: Offsite Discussion

Philip Wadler: Say no to a Scottish national ID system

Planet Haskell - Mon, 02/09/2015 - 2:39pm
The Scottish government has opened for consultation plans of that would lead to database sharing among a vast range of organisations, and could lead to the introduction of de facto ID cards via the back door. Responses to the consultation are due by 25 February 2015. ORG Scotland writes:

A minor, barely noticed consultation is not the way to make a major change to Scottish citizens’ privacy and their relationship with the state. Creating a national ID register was rejected by the SNP and the UK, and the bare minimum should be for the Scottish Executive to introduce primary legislation whereby the public and MSPs can debate the nature of these changes and whether they are acceptable.

Respond to the consultation quickly, courtesy of ORG.

ORG is planning meetings to discuss how we can stop the Scottish Government's plans in EdinburghGlasgow and Aberdeen, and is tracking developments in their blog.
Here is the original consultation,  and a detailed response by ORG.
Categories: Offsite Blogs

Roman Cheplyaka: Dealing with broken Haskell packages

Planet Haskell - Mon, 02/09/2015 - 2:00pm

As we approach the release of GHC 7.10, there is a new wave of Haskell packages that require trivial fixes to build with the new versions of the compiler and standard libraries, but whose authors/maintainers are not around to apply the fixes. This is especially annoying when there is a pull request on GitHub, and all the maintainer would have to do is to press the green Merge button, and upload the new version on hackage.

If you are a responsible maintainer and don’t want this to happen to your packages in the future, you should appoint backup maintainers for your packages.

But what if you are a user of a package that remains broken on hackage, even though a fix is available? Here I review several ways to deal with this problem, including the new and promising Stackage snapshots.

Building the package locally

If all you care about is to get something installed locally (be it the broken package itself, or something that directly or indirectly depends on it), you can install the fixed version locally.

Non-sandboxed way

Check out the repository or branch with the fix, and cabal-install it:

% git clone -b ghc710 https://github.com/markus1189/feed.git % cabal install ./feed

(I prepend ./ to make sure cabal understands that I mean the directory, and not the package name on hackage.)

Sandboxed way

If you’re installing in the sandbox, then you can use add-source (although the non-sandboxed version will work in this case, too):

% git clone -b ghc710 https://github.com/markus1189/feed.git % cabal sandbox add-source feed % cabal install whatever-you-needed

If the package whatever-you-needed has feed among its transitive dependencies, cabal will automatically install it from the add-source’d directory.

Limitations

This approach doesn’t work well if:

  1. You are a maintainer of a package that depends on the broken library. It’s hard to ask your users to check out and build the fixed version by hand.

  2. You work on an in-house application that your coworkers should be able to build, for the same reason.

Forking the package

You cannot upload the fixed version of a package on hackage bypassing the maintainer. However, you can upload it under a new name. This works well if you are a maintainer of a package that directly depends on the broken package, because you can easily make your package depend on your fork.

Examples of this are tasty depending on regex-tdfa-rc (a fork of regex-tdfa) and tasty-golden depending on temporary-rc (a fork of temporary).

Limitations
  1. This doesn’t work well if there’s a chain of dependencies leading from your package to the broken one. You have to either persuade the other maintainer(s) to depend on your fork or fork the entire chain.

  2. If the broken package becomes actively developed again, you need to either move back to using it or backport the bugfixes from it to your fork. (I only fork packages when I find this scenario unlikely.)

  3. Other packages that depend on the broken package won’t automatically get fixed.

  4. Some people get upset when you fork packages.

Stackage snapshots

Instead of uploading the fixed version to hackage (which you can’t), you can upload it to Stackage instead, by creating a custom snapshot.

The procedure is described in Experimental package releases via Stackage Server. You create four files:

  • The fixed tarball (produced by cabal sdist). You probably want to bump the package’s version, so that it doesn’t conflict with the version already on hackage.
  • Two text files: desc and slug. The first one contains a human-readable description of the snapshot; the second contains an id that will become part of the snapshot’s URL.
  • A text file with the packages to be copied directly from hackage. For the purpose of this article, you probably want to leave this file empty. (I don’t know if it’s ok not to include it at all.)

Then you pack these four files into a tarball (that’s right, it’ll be a tarball with a tarball inside) and upload to stackage (after registering, if you haven’t registered before).

The outcome will be a custom hackage-like repository which will contain the single version of a single package — the one you’ve uploaded. (Of course, you can include multiple packages or versions if you like.)

The Stackage website will give you the remote-repo line that you can put into your cabal.config along with the hackage or stackage repos that are already there.

In contrast to building packages locally, you can easily tell your users or coworkers to add that repo as well.

Limitations
  1. If the new hackage release of the broken package will get the same version number as your stackage version, there will be a conflict. (I actually don’t know what happens in that case; my guess is that cabal will silently pick one of the two available versions.)

  2. If the package you maintain (which depends on the broken package) is a small one, or is deep down the dependency chain, it may be hard to tell your users to add the repository. If, on the other hand, you maintain a major web framework or other such thing, it would probably work.

Taking over a package

There’s a procedure for taking over a package described on the wiki. You’ll need to contact the current maintainer; wait an indefinite amount of time (there’s no consensus about it; estimates vary from 2 weeks to 6-12 months); ask again on the mailing list and wait again; finally ask Hackage admins to grant you the rights.

Limitations
  1. Since this procedure takes a long time, it’s almost never sufficient by itself, and you’ll need to resort to one of the other strategies until you’re given the upload rights.

  2. It’s not clear how long you actually need to wait.

  3. I find it odd that you need to jump through all these hoops in order to do a service to the community.

Categories: Offsite Blogs

GHC-7.8.4 for Mac OS X

haskell-cafe - Mon, 02/09/2015 - 1:36pm
Hi, Does anyone plan to put a binary release of GHC-7.8.4 for OS X? There isn't one here: https://www.haskell.org/ghc/download_ghc_7_8_4 Cheers! Ozgur _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

Help me develop tutorials for building Haskell applications.

Haskell on Reddit - Mon, 02/09/2015 - 1:33pm

I started working on Haskell projects (I am a product manager working for FP Complete) with developers and a pattern is emerging which is there isn't enough tutorials and samples teaching how to build an end-to-end Haskell application!

If you have an application that you developed in Haskell, I would love to hear from you and we can together make it into a tutorial to teach others and share the knowledge promoting and encouraging more developers to use Haskell for commercial applications.

Got an app? Let me know!

submitted by saldaoud
[link] [29 comments]
Categories: Incoming News

Use of STM in business?

haskell-cafe - Mon, 02/09/2015 - 1:19pm
From associate of mine: "I am quite curious if anyone actually uses Haskell (esp STM) successfully in business." Of course I can anwser the general question about usage of Haskell in business, but I don't know much about STM specifically. Can anyone provide me with any references to where STM has been used in production in a business setting? Thanks, Tom
Categories: Offsite Discussion

Welcome To LambdaCms-org!

del.icio.us/haskell - Mon, 02/09/2015 - 1:07pm
Categories: Offsite Blogs