- Haskell-Cafe - Haskell.org

Source code for Control.Parallel.Strategies
by Edward Grutman 12 Feb '16

12 Feb '16

Unable to find source code for Control.Parallel.Strategies module in the libraries folder of the latest ghc ( downloaded from GitHub two weeks ago. ).

2 1

Why do we want levity polymorphism?
by David Menendez 11 Feb '16

11 Feb '16

For context, there’s currently a big thread about the type of ($), which is going to be more complicated in GHC 8.0 due to levity/runtime rep polymorphism. As I understand it, the intention is that this more complex type will be hidden unless a levity polymorphism flag is active. From my perspective, makes the question of whether this type is too complicated for beginners moot. What puzzles me is that I still don’t understand what this feature is *for*. According to [1], levity polymorphism is a more principled replacement for OpenKind, which was a bit of hack. Fine. [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds OpenKind exists because developers wanted to use ($), undefined, and error with unboxed types. That’s understandable, but it doesn’t seem worth all this effort. Surely, having to use error# instead of error when working with unboxed or unlifed types is a small thing next to all the other differences. OpenKind is also used when doing type inference, because arguments to functions might be * or #. That’s more compelling, but doesn’t seem like something that needs to be exposed to the programmer. So, is that it? Are there less-trivial levity-polymorphic functions? Is this a step on a road to new features, like [2]? Is there an article or something that makes the case for this? [2] https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

2 1

Re: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)
by Richard Eisenberg 11 Feb '16

11 Feb '16

I have made a ticket #11549 (https://ghc.haskell.org/trac/ghc/ticket/11549) requesting a -fshow-runtime-rep flag (recalling that the name levity will soon be outdated) as described in this thread. I will make sure this gets in for the release of 8.0. Other points: - You're quite right that (.) could be generalized. But I'll wait for someone to really want this. - I don't have a non-contrived example of the use of ($) with unlifted types. It's quite possible that when adding the dirty runST hack, it was observed that an unlifted type would be OK. At that point, the type of ($) didn't need to become so elaborate. And now we're just trying not to change old (but perhaps unrequested) behavior. - For the record, this debate is entirely unrelated to the runST impredicativity hack. (Except, as noted above, perhaps in history.) That hack remains, basically unchanged. - On Feb 6, 2016, at 9:55 AM, Roman Cheplyaka <roma(a)ro-che.info> wrote: > > I would call this a simplification rather than a lie. This is a very convincing argument. - Thanks, also, for the voice of support. What I love about the Haskell community is that we can have an impassioned debate full of strong opinions, and it all very rarely devolves into a proper flame war. All the posts I've seen in this thread have been constructive and helpful. Thanks. Richard

3 4

Re: [Haskell-cafe] tighter bounds for Data.Map operations (using min(n.m))?
by Johannes Waldmann 10 Feb '16

10 Feb '16

See also https://github.com/haskell/containers/issues/177 (which I found only now) - J.W.

1 0

tighter bounds for Data.Map operations (using min(n.m))?
by Johannes Waldmann 10 Feb '16

10 Feb '16

Dear Cafe, I wonder if some of the resource bounds in https://hackage.haskell.org/package/containers-0.5.7.1/docs/Data-Map-Strict… can be improved. I do not mean "improve the implementation", but "improve the (stated) bounds". For example, I am interested in intersection(With). Bound is stated as O(n+m) (*) This is a fine worst case bound - but I certainly use this function with the implied assumption that it will not visit both trees completely - in the case that one of them is small. So, what can we say in terms of min(n,m) ? Is it linear in that parameter? Perhaps with an additional factor log(max(n,m)) ? (for looking up the keys of the smaller tree in the larger one) The paper linked from the docs has this (p 18 before 9.3) "the running time of union is better for fortuitous inputs, for example, similar sized disjoint ranges, and trees which differ greatly in size" but does not make a formal statement. This is about union, not intersection, and not hedge_union, but it's the closest this paper gets to what I have in mind. Oh, and after that, same question for Data.IntMap. - J.W. (*) with the usual neglect for alphabetic order...

1 0

Hackage: Tarball and package description of package mtl differ
by Björn Peemöller 10 Feb '16

10 Feb '16

Hi Cafe, I just wanted to install the mtl package for GHC 8.0.1-rc2, but installation failed with Setup: Encountered missing dependencies: transformers ==0.4.* Taking a look at the package description [1], it specifies build-depends: base < 6, transformers >= 0.4 && < 0.6 but the Cabal description in the tarball [2] says build-depends: base < 6, transformers == 0.4.* Strangely, if I execute $ cabal unpack mtl-2.2.1 I obtain a version with the same specification as [1]. Does anybody has an explanation for this? Regards, Björn [1]: http://hackage.haskell.org/package/mtl-2.2.1/mtl.cabal [2]: http://hackage.haskell.org/package/mtl-2.2.1/mtl-2.2.1.tar.gz

2 2

Postdoctoral position in Functional, Constraint and/or Logic Programming
by Tom Schrijvers 10 Feb '16

10 Feb '16

Prof. Tom Schrijvers invites applications for a postdoctoral position in the area of functional, constraint and logic programming. The position revolves around domain-specific languages (DSLs) embedded in Haskell for constraint programming. It is part of the EU project GRACeFUL whose overarching theme is tools for collective decision making. Responsibilities You will work closely with prof. Schrijvers and his PhD students at KU Leuven, as well as with the GRACeFUL project partners across Europe, in order to conduct research activities for the GRACeFUL project. For more details: https://icts.kuleuven.be/apps/jobsite/vacatures/53613023 -- prof. dr. ir. Tom Schrijvers Research Professor KU Leuven Department of Computer Science Celestijnenlaan 200A 3001 Leuven Belgium Phone: +32 16 327 830 http://people.cs.kuleuven.be/~tom.schrijvers/

1 0

Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)
by Richard Eisenberg 10 Feb '16

10 Feb '16

It may come as a surprise to many of you that I, too, am very worried about Haskell becoming inaccessible to newcomers. If we can't induct new people into our ranks, we will die. It is for this reason that I have always been unhappy with the FTP. But that ship has sailed. I fully agree with George's suggestion below that the default Prelude should be the beginner's Prelude. I believe I have argued this stance in the past, but louder voices prevailed. Perhaps I was wrong in branding: we should have a proper Prelude as the default, and make available a super whiz-bang advanced Prelude as well. I'm never very good about branding. I'd lend strong support to someone who articulates a concrete move in this direction, but I don't have the bandwidth to spearhead it myself. Despite the various arguments saying that the bits in Java are easier to understand than the bits in ($), I'm quite unconvinced. (Particularly about `static`. Even `class` is hard for true beginners.) And the boxed/unboxed distinction does come up early in Java: just try to write an ArrayList<int> and now you need to know about boxed types and unboxed ones. Chris's point that "it's not about the name" is valid. The Levity --> RuntimeRep change is not about the name, but about the functionality. Levity distinguished only between lifted and unlifted; RuntimeRep distinguishes between boxed/lifted, boxed/unlifted, and all the unboxed types with their different widths. I'm just clarifying that it's not simply a cosmetic name-change. The old type of ($) was always a lie. -XMagicHash just changes the parser, allowing the # suffix. It is only by convention that most (all?) unlifted things end in #. The old type of ($) was perhaps a harmless lie, but a lie nonetheless. Are we comfortable with lying? (Believe me, I'm not trying to impose some moral dimension to simplifying output!) In my mind, lying about types like this is in the same space as having a beginner's Prelude. And people will constantly discover that we're lying and get very confused. Having a whole host of flags that tell GHC to lie less is somewhat like having two versions of the language... only the differences manifest only in output instead of input. If we are comfortable with lying in this way: as I've offered, I can hide the type of ($) (and other representation-polymorphic things) behind a flag. Easy to do. Another great question that has come up is about Haddock output (Hackage). I think Haddock needs to add a facility where library authors can include specializations of an overly general type. This can be done in commentary, but it's not as prominent. Such a new feature would address the ($) problem, as ($) :: forall (a :: *) (b :: *). (a -> b) -> a -> b is a specialization of its real type. It would also help a great deal with FTP-related generalizations. I also want to respond directly to Kyle's comments: > I think its important to identify who you want your "customers" to be. If you only want the most advanced type theorists to use the language, that is perfectly fine, but what you lose are thousands of developers that can benefit the Haskell community without having to know advanced Typing. Rest assured, I want my "customers" to be everyone who wants to program. I've volunteered to teach a bit of Haskell to high schoolers, and I'd love a shot at a course where I teach it to people who have never programmed. > > Needing a "Beginners" mode in a language is *not* a feature, its a fundamental design flaw. It shows that the language was not sufficiently thought out and designed for everyone. On an intuitive level, this rings true for me. But when I think about the details, I'm less convinced. For example, take Scratch (scratch.mit.edu) which is wonderfully easy to learn and gives kids (and adults!) a great deal of fun. Yet it's painful to use when you know more. And the Racket folks have invested a lot of time in coming up with a curriculum to go with their language, and they explicitly have expertise levels. Needing these levels may just be part of the game. So, rest assured, I remain very receptive to these concerns. And I'd love concrete help in putting them to rest. Richard On Feb 5, 2016, at 6:30 PM, George Colpitts <george.colpitts(a)gmail.com> wrote: > +1 for Christopher's email > Richard, I disagree with "But it could indeed be explained to an intermediate programmer in another language just learning Haskell." Your explanation is good but it assumes you have already explained "types of kind *" and the boxed vs unboxed distinction. Admittedly the latter should be understood by most Java programmers but I doubt that intermediate programmers in other languages do. If I did have to explain "$" I would say, for now think of it in terms of it's pre 8.0 type. Alternatively avoid mentioning "$" to beginners. I don't believe it is in Hutton's book or any of Bird's although I might be wrong. > > Most intermediate programmers in another language struggle a lot with learning monads, witness all the monad tutorials. Absorbing monads is central, there is a lot that has to be explained before that. Minimizing that material would be a good thing. > > I have mixed feelings about a beginner's prelude best summarized by saying the proposed beginner's prelude should be the standard prelude and the current one should be an advanced prelude. If we have a beginner's prelude I feel we are saying that this is a hard to understand research language and we hope that someday you have enough education, energy and tenacity to get to the point where you understand it. If we do it the other way we are saying you have what you need but if you want more there is lots! > > On Fri, Feb 5, 2016 at 3:05 PM, Christopher Allen <cma(a)bitemyapp.com> wrote: > Changing the name doesn't fix the issue. The issue is the noise and the referent, not the referrer. There's a habit of over-focusing on names in programming communities. I think it'd be a mistake to do that here and risk missing the point. > > You can make all of the keywords in the Java example salient early on, but you cannot make the implementation details you're exposing in the type of ($) relevant unless they already have a year or two of Haskell under their belts. Listing out the keywords: > > 1. public > > 2. class > > 3. (class name) > > 4. static > > 5. void > > 6. (method name) > > 7. (method arguments) > > Explaining public, class, static, and void usually happens pretty soon after the basics in a Java course. Importantly, they're things you _need_ to know to get things done properly in Java. The same is not true of what is mentioned in the type of ($). > > The implicit prenex form and forall are irrelevant for learners until they get to Rank2/RankN which is very much beyond, "I am learning Haskell" and into, "I am designing an API in Haskell for other people to use". * vs. # is something many working and hobbyist Haskellers I've known will scarcely know anything about. > > There is a big difference, to my mind, between what is being exposed here in Java versus what is being exposed in the type ($). Consider that the boxed/unboxed distinction exists in Java but needn't come up in any beginner tutorials. > > >Types of kind * have values represented by pointers. This is the vast majority of data in Haskell, because almost everything in Haskell is boxed. > > We can't assume Haskell learners know what pointers are. This, again, creates unnecessary noise for learners by forcing exposure to things that are irrelevant for a very long time. > > > On Fri, Feb 5, 2016 at 12:13 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > Perhaps it will aid the discussion to see that the type of ($) will, for better or worse, be changing again before 8.0. > > The problem is described in GHC ticket #11471. The details of "why" aren't all that important for this discussion, but the resolution might be. The new (hopefully final!) type of ($) will be: > > > ($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a -> b > > Once again, it's easy enough to tweak the pretty-printer to hide the complexity. But perhaps it's not necessary. The difference as far as this conversation is concerned is that Levity has been renamed to RuntimeRep. I think this is an improvement, because now it's not terribly hard to explain: > > --- > 1. Types of kind * have values represented by pointers. This is the vast majority of data in Haskell, because almost everything in Haskell is boxed. > 2. But sometimes, we don't care how a value is represented. In this case, we can be polymorphic in the choice of representation, just like `length` is polymorphic in the choice of list element type. > 3. ($) works with functions whose result can have any representation, as succinctly stated in the type. Note that the argument to the function must be boxed, however, because the implementation of ($) must store and pass the argument. It doesn't care at all about the result, though, allowing for representation-polymorphism. > > In aid of this explanation, we can relate this all to Java. The reference types in Java (e.g., Object, int[], Boolean) are all like types of kind *. The primitive types in Java (int, boolean, char) do not have kind *. Java allows type abstraction (that is, generics) only over the types of kind *. Haskell is more general, allowing abstraction over primitive types via representation polymorphism. > --- > > Could this all be explained to a novice programmer? That would be a struggle. But it could indeed be explained to an intermediate programmer in another language just learning Haskell. > > For point of comparison, Java is widely used as a teaching language. And yet one of the simplest programs is > > public class HelloWorld > { > public static void main(String[] args) > { > System.out.println("Hello, world!"); > } > } > > When I taught Java (I taught high-school full time for 8 years), I would start with something similar to this and have to tell everyone to ignore 90% of what was written. My course never even got to arrays and `static`! That was painful, but everyone survived. This is just to point out that Haskell isn't the only language with this problem. Not to say we shouldn't try to improve! > > We're in a bit of a bind in all this. We really need the fancy type for ($) so that it can be used in all situations where it is used currently. The old type for ($) was just a plain old lie. Now, at least, we're not lying. So, do we 1) lie, 2) allow the language to grow, or 3) avoid certain growth because it affects how easy the language is to learn? I don't really think anyone is advocating for (3) exactly, but it's hard to have (2) and not make things more complicated -- unless we have a beginners' mode or other features in, say, GHCi that aid learning. As I've said, I'm in full favor of adding these features. > > Richard > > On Feb 5, 2016, at 12:55 PM, Kyle Hanson <me(a)khanson.io> wrote: > >> I am also happy the discussion was posted here. Although I don't teach Haskell professionally, one of the things I loved to do was show people how simple Haskell really was by inspecting types and slowly putting the puzzle pieces together. >> >> Summary of the problem for others: >> From Takenobu Tani >> Before ghc7.8: >> >> Prelude> :t foldr >> foldr :: (a -> b -> b) -> b -> [a] -> b >> >> Prelude> :t ($) >> ($) :: (a -> b) -> a -> b >> >> Beginners should only understand about following: >> >> * type variable (polymorphism) >> >> >> After ghc8.0: >> >> Prelude> :t foldr >> foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b >> >> Prelude> :t ($) >> ($) >> :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). >> (a -> b) -> a -> b >> >> >> With this change it looks like I will no longer be able to keep `$` in my toolbox since telling a beginner its "magic" goes against what I believe Haskell is good at, being well defined and easy to understand (Not well defined in terms of Types but well defined in terms of ability to precisely and concisely explain and define whats going on). >> >> It looks like where the discussion is going is to have these types show by default but eventually have an Alternative prelude for beginners. >> >> From Richard Eisenberg: >> - It's interesting that the solution to the two problems Takenobu pulls out below (but others have hinted at in this thread) is by having an alternate Prelude for beginners. I believe that having an alternate beginners' Prelude is becoming essential. I know I'm not the first one to suggest this, but a great many issues that teachers of Haskell have raised with me and posts on this and other lists would be solved by an alternate Prelude for beginners. >> I don't like the idea of fragmenting Haskell into "beginners" and "advanced" versions. Its hard enough to get people to believe Haskell is easy. If they see that they aren't using the "real" prelude, Haskell will still be this magic black box that is too abstract and difficult to understand. If they have to use a "dumbed down" version of Haskell to learn, its not as compelling. >> >> There is something powerful about using the same idiomatic tools as the "big boys" and have the tools still be able to be easy to understand.... by default. Adding complexity to the default Haskell runs the risk of further alienating newcomers to the language who have a misconception that its too hard. >> >> Admittedly, I am not well informed of the state of GHC 8.0 development and haven't had time to fully look into the situation. I am very interested to see where this conversation and the default complexity of Haskell goes. >> >> -- >> Kyle >> >> >> On Fri, Feb 5, 2016 at 8:26 AM, Tom Ellis <tom-lists-haskell-cafe-2013(a)jaguarpaw.co.uk> wrote: >> On Fri, Feb 05, 2016 at 05:25:15PM +0100, Johannes Waldmann wrote: >> > > What's changed? >> > >> > I was referring to a discussion on ghc-devs, see >> > https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html >> > and mixed up addresses when replying. >> >> I'm glad you did, because this is the first I've heard of it! >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > -- > Chris Allen > Currently working on http://haskellbook.com > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >

27 59

Combining ST with STM
by Thomas Koster 10 Feb '16

10 Feb '16

Hi friends, I have an STM transaction that needs some private, temporary state. The most obvious way is to simply pass pure state as arguments, but for efficiency, I would like this state to be some kind of mutable array, like STArray. I know, STM has TVars and TArray, but since this state is private to the transaction, I am wondering if using TVars/TArrays for private state might be overkill that will unnecessarily slow down the STM commit process. The private state is, by definition, not shared, so including it in the STM log and commit process is, as far as I can tell, pointless. ST and STArray still appear to be the most appropriate tools for the private state, because STRefs and STArrays really, really are private. So this basically means I want to interleave ST and STM in a "safe" way. That is, if the STM transaction retries, I want the ST state to be vaporised as well. Ideally, I would love to be able to say something like this: -- | Copy the value from the shared TVar into the private STRef. load :: TVar a -> STRef a -> STSTM s () load shared private = do value <- liftSTM (readTVar shared) liftST (writeSTRef private value) Naturally, that STRef must originate from a call to newSTRef earlier in the same transaction and is private to it, just like the real ST monad. As far as I can tell, I am not trying to weaken either ST or STM in any way here. I found the STMonadTrans package on Hackage [1] that claims to implement ST as a monad transformer, STT, which sounds close to what I want. While its documentation does not mention STM, it does say that some monads are unsafe to use as a base monad for STT. Is STMonadTrans safe to use with STM? [1] https://hackage.haskell.org/package/STMonadTrans Thanks, Thomas Koster

4 9

ANNOUNCE: hoppy, qtah
by Bryan Gardiner 10 Feb '16

10 Feb '16

Are you sick and tired of the ease with which Haskell code flows onto the page? Even the thrill of binding to a C library losing its lustre? Look no further! I present to you a tool restoring the good old days of pointer arithmetic, manual memory management, and hours lost to the debugger: Hoppy is a new C++ FFI generator for Haskell. It takes Haskell code that describes a C++ API, and generates C++ and Haskell code to allow the two languages to interact. It supports a good subset of C++, including functions, classes, variables, enums and bitflags, operator overloading, constness, and simple templates. Adding a function takes only a few lines of code, and you normally don't need to write C++ yourself. For example, a definition for std::string is: c_string :: Class c_string = addReqIncludes [includeStd "string"] $ classAddFeatures [Assignable, Comparable, Copyable, Equatable] $ makeClass (ident1 "std" "string") (Just $ toExtName "StdString") [] [ mkCtor "new" [] , mkCtor "newFromCString" [TPtr $ TConst TChar] ] [ mkConstMethod' "at" "at" [TInt] $ TRef TChar , mkConstMethod' "at" "get" [TInt] TChar , mkConstMethod "c_str" [] $ TPtr $ TConst TChar , mkConstMethod "size" [] TSize , mkConstMethod OpAdd [TObj c_string] $ TObj c_string ] Now, writing a FFI generator isn't much fun unless you have a project to use it with. So I am pleased to also announce Qtah, a fresh set of Qt 4/5 bindings. These include portions of QtCore, QtGui, and QtWidgets, and are on the whole wildly incomplete, but are usable for basic tasks so far, and I am working on extending coverage. (On qtHaskell/hsQt: I started Qtah before qtHaskell began being updated in 2015 and I missed when that happened. My hope is that Qtah requires less code and effort to maintain; at least, qtHaskell contains a lot of generated code and I haven't seen where it came from, so please correct me if the generator is in fact available somewhere. Hoppy also doesn't (currently) do many of the fancy things that qtHaskell does, like overloading and garbage collection.) Both Hoppy and Qtah are young, and I am very interested in discussing how to make them most useful for the community. Because of questions such as this[1], their APIs (including those of generated bindings) should be considered experimental at this time. I will be uploading Hoppy to Hackage shortly. Becuase Qtah includes a shared library, I haven't figured out how to get that on Hackage yet, so you'll have to clone the repo yourself. http://khumba.net/projects/hoppy http://khumba.net/projects/qtah Happy hacking! Bryan Gardiner [1] https://gitlab.com/khumba/hoppy/issues/3

2 2