From gnuk0001 at gmail.com Tue Apr 1 01:21:36 2014 From: gnuk0001 at gmail.com (Renzo Carbonara) Date: Mon, 31 Mar 2014 22:21:36 -0300 Subject: [Haskell-cafe] Towards a better time library (announcing tz) In-Reply-To: <20140331181543.GA20036@cs.elte.hu> References: <20140331181543.GA20036@cs.elte.hu> Message-ID: I'm currently a user of the `timezone-olson` and `timezone-series` libraries, so I can understand the requirement for better time zone representations than the one offered by `time`. I think it would be best for the community if your work and the one in `timezone-olson` and `timezone-series` could be integrated somehow, as there doesn't seem to be a need to have two different implementations for parsing the Olson file format. As far as I know, Yitzchak is willing to improve his libraries, I CC him here. Given that you are shipping a timezone database with your package, as a user I'd really prefer `loadTZFromDB` to be `String -> Maybe TZ` instead of `String -> IO TZ` so that it can be used in pure code. You'd probably need to hardcode the contents of the `*.zone` files you are including within a Haskell module, but that could be done automatically using some script. Moreover, an idea I've been toying with is writing a program that parses the tzdata information files and generates a type-safe pure API for interacting with the tz data in memory. For example, given the tzdata information files you would generate types, values and pure functions such as the following: data TimeZone = Europe__Paris | America__Buenos_Aires | ... timeZoneName :: TimeZone -> Text timeZoneName Europe__Paris = "Europe/Paris" timeZoneName America__Buenos_Aires = "America/Buenos_Aires" timeZoneName ... = ... timeZoneFromName :: Text -> Maybe TimeZone timeZoneFromName "Europe/Paris" = Just Europe__Paris timeZoneFromName "America/Buenos_Aires" = Just America__Buenos_Aires timeZoneFromName ... = ... timeZoneFromName _ = Nothing timeZoneInfo :: TimeZone -> TZ timeZoneInfo Europe_Paris = ... some hardcoded value (the `TZ` in your library) ... timeZoneInfo ... = ... As a minor tidbit: If one is going to do this, I think a good idea is to devise a package versioning system that's somewhat follows the tz database versions. This is what I had in mind for the `tzdata` package I was planning to create (unless someone else does it first): The version number of the package is always @YYYYMMDD.B.C@, where @YYYYMMDD@ are the year (@YYYY@), the month (@MM@) and the day (@DD@) of the @tzdata@ release this particular version was designed for. For example, @tzdata 2013i@ was officially released on @2013-12-17@, so a version of this package that was designed for @tzdata 2013i@ will carry the version number @20131217.B.C at . However, that doesn't mean that this library won't work with versions of the @tzdata@ library different than @2013i@, it's just that support for new or old data (say, the name of a new time zone that was introduced) can be missing. The @B@ and @C@ values in the version number of this library as treated as the /major/ and /minor/ versions respectively, as suggested in the /Haskell Package Version Policy/ page: http://www.haskell.org/haskellwiki/Package_versioning_policy Maybe the `timezone-olson`, `timezone-series`, this `tzdata` idea and `tz` could all live together; with `tz` depending on the others? Just a thought :) Regards, Renzo Carbonara. On Mon, Mar 31, 2014 at 3:15 PM, Mihaly Barasz wrote: > > I would like to propose reforming the 'time' [1] library. > > > Initially, I was just planning to announce my new 'tz' [2] library, but > realized that I have a more important agenda. Namely: Haskell needs a > better time library! > > Let me summarize what are ? in my view ? the biggest deficiencies of > 'time': > > 1. Inefficient data structures and implementations. > > 2. Ad-hoc API which is hard to remember and frustrating to work with. > > 3. Conceptually wrong representations and/or missing concepts. > > The wonderful thyme [3] package (by Liyang HU) improves a lot on #1 by > choosing better data structures and careful implementations and on #2 > by lensifying the API. > > But, it was the #3 that caused me the most frustration lately; most > importantly the time zone handling. > > There is a TimeZone data type in 'time', but it is a misnomer, it > basically represents a fixed time difference (with a label and a DST > flag). 'time' basically adapts the broken approach from libc: you can > work with one time zone at a time, which is defined globally for your > program (via the TZ environment variable). So, the transformation > between UTCTime and LocalTime which should have been a pure > function can only be done in IO now. Like this: > > do tz <- getTimeZone ut > return $ utcToLocalTime tz ut > > > Oh, and just to hammer down on the point #1 from the list above. This > code runs in about 6100 ns on my machine. The drop-in replacement from > tz: utcToLocalTimeTZ [4] (which is actually pure) runs in 2300 ns. > While this is a significant improvement, it's easy to miss the point > where the bulk of the inefficiency comes from the data structures. In > my main project we represent times as Int64 (raw nanoseconds since > UNIX epoch; and similar representation for zoned times). And to > convert those to and from different time zones we need 40 ns. That's > right, a 150 _times_ improvement! (There are many other interesting > benchmark results that I could mention. An exciting bottom line: we > can actually beat the libc in many use-cases!) > > The 'tz' package is still very much in flux. I will try to solidify > the API soon, but until then it should be considered more of a proof > of concept. There is some missing functionality, for example. On the > other hand, there are the 'timezone-series' [5] and 'timezone-olson' > [6] packages that together provide about the same functionality as > 'tz' (minus the efficiency), and I'd like to explore if we could > remove some of the overlap. But, all kind of suggestions and requests > are welcome! > > More importantly, I'd like to hear the opinions of the community about > the general issue of a better time library! Do we need one? How > should we proceed about it? I think, Haskell could potentially have > one of the best time libraries, but the current de-facto standard is > mediocre at best. Unfortunately, designing a good time library is very > far from trivial, as many existing examples demonstrate. And I > definitely don't know enough for it. (I understand time zone info > files, now that I wrote tz, but that's just a tiny fraction of what's > needed.) So, if you think you can contribute to the design (have > important use-cases in mind, know good examples of API, have some > experience working with dates and time, etc. etc.) ? speak up! > > > Mihaly > > > Footnotes: > > [1] http://hackage.haskell.org/package/time > [2] http://hackage.haskell.org/package/tz > [3] http://hackage.haskell.org/package/thyme > [4] http://hackage.haskell.org/package/tz-0.0.0.1/docs/Data-Time-Zones.html#v:utcToLocalTimeTZ > [5] http://hackage.haskell.org/package/timezone-series > [6] http://hackage.haskell.org/package/timezone-olson > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iQEVAwUBUzmwz/i5FOsZqz9DAQJGcAgAhPF4JLWnL4ApJ2qxqAwHqXcIPqRpVb5A > TH2LERH2A/6b3xXCRYsPgyD43j2CzqZGffRvINSw9fGoJYWuRmis5dCf9hwPiKtg > hK1wUCz9AsKlKBZztR9eLxROqM/xXMH4HaFydr/YOVffDVY6fUIK9fPbRFJBVCBq > UwtoemQSVLUIIRxZyg5pdL+dxadnttm7bGC+UuQJHtSSBRweEh3unr8dcNm4idC3 > nxWOMclbo2hyMdwzDo1bqugugq2xCGPiGrL550aF1lCGD2pf2vQO1feW/5XyMaCR > Oj6gI+eHo8SuhUx30Dokv1kx8Ssay0aVmmASCJKnR8Bwv1J9AKWo3A== > =Bp64 > -----END PGP SIGNATURE----- > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From patrick.john.wheeler at gmail.com Tue Apr 1 01:52:26 2014 From: patrick.john.wheeler at gmail.com (Patrick Wheeler) Date: Mon, 31 Mar 2014 20:52:26 -0500 Subject: [Haskell-cafe] [ANN] network-transport-zeromq-0.1. In-Reply-To: References: Message-ID: > Our vision is that send/expect should work according to the default distributed-process semantics, but one ought to be allowed to vary the semantics of channel-based communication (as opposed to actor-based) according to what is relevant to the application. E.g. an application ought to be able to give up reliability for better latency/throughput on a channel-by-channel basis. That pretty exciting. I will have to put aside some time to tryout Cloud Haskell on top of your ZeroMQ layer. I would love to see a simple example of how this would work with different reliability settings in a ping-pong example. On Mon, Mar 31, 2014 at 1:34 PM, Edsko de Vries wrote: > Hi Mathieu, > > That sounds great! It's great to see that the redesign of Cloud Haskell > with a pluggable Network.Transport layer is in fact being used. Good stuff! > > Edsko > > -- > You received this message because you are subscribed to the Google Groups > "parallel-haskell" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to parallel-haskell+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Patrick Wheeler Patrick.John.Wheeler at gmail.com Patrick.J.Wheeler at rice.edu Patrick.Wheeler at colorado.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From lykahb at gmail.com Tue Apr 1 03:07:20 2014 From: lykahb at gmail.com (lykahb at gmail.com) Date: Mon, 31 Mar 2014 20:07:20 -0700 (PDT) Subject: [Haskell-cafe] Groundhog - Given entity, how to retrieve autokey value? In-Reply-To: References: Message-ID: Hi Ross, The primary key if it is generated by a database is not part of the entity. However, you can store it in your entity if you supply it yourself. It is a good approach if your entity has a natural primary key (like username). Only default key can be auto-incremented. Here is more detailed description of how keys work in Groundhog https://www.fpcomplete.com/user/lykahb/groundhog#keys-and-references Also you may want to use project instead of select. For example, "project (AutoKeyField, MyConstructor) $ MyField ==. myValue" would return id and the entity. Thank you, Boris Lykah On Sunday, March 30, 2014 12:41:40 AM UTC-4, Ross Pokorny wrote: > > Hello, > > I am trying to build a RESTful web application using Groundhog for > persistence. In order to generate URLs for my entities (e.g. for the > Location HTTP header), I need a way, given that I have an entity, to obtain > its id (its AutoKey). From what I've gathered so far, in normal Groundhog > usage, the primary key is not part of the actual entity datatype. The only > place where I've seen it returned is from the 'insert' functions in > Database.Groundhog. I need the id in cases where I have retrieved an > already-existing entity using 'select', but I cannot find a way to obtain > it. > > I gather that this might not be possible with the current API, and that > instead, I may need to explicitly define a field on the entity type to > store the id instead of using the auto-generated field that Groundhog > normally provides. In that case, my question is how do I set up that field > to be an auto-incrementing key, and not simply a value with a unique > constraint. Also, would Groundhog recognize that field as the AutoKey, and > would it return it from 'insert' calls? > > Thanks, > > Ross Pokorny > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Tue Apr 1 03:13:08 2014 From: jwlato at gmail.com (John Lato) Date: Mon, 31 Mar 2014 20:13:08 -0700 Subject: [Haskell-cafe] groupBy without Ord? In-Reply-To: <53393513.9020803@web.de> References: <532DBFAB.7080908@web.de> <533824E0.5010001@web.de> <20140330141232.GM29562@weber> <533883AE.100@web.de> <20140330211556.GQ29562@weber> <53393513.9020803@web.de> Message-ID: On Mar 31, 2014 5:28 AM, "martin" wrote: > > Am 03/30/2014 11:15 PM, schrieb Tom Ellis: > > > >> groupEq :: Eq a => [a] -> [[a]] > >> groupEq [] = [] > >> groupEq (a:rest) = (a:as) : groupEq bs > >> where (as,bs) = partition (==a) rest > > > > This is O(n^2). > > I understood, that you suggested to go ahead and sort the list, instead of just aligning equal elements next to each > other. So far all my attempts to prove you wrong failed. None of your attempts have addressed the major criticism, I.e. your algorithm has higher complexity than Ord-based solutions. That doesn't mean your algorithm won't work well for your use case, but it does mean that it will work less well for some (many?) use cases. Have you tried "groupEq [1..1000000::Int]" ? Is the performance of that acceptable? Does that impact your use case? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Tue Apr 1 04:19:42 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 1 Apr 2014 11:19:42 +0700 Subject: [Haskell-cafe] Haskell Weekly News In-Reply-To: <20140331211558.GA7886@seas.upenn.edu> References: <1396251370106-5746682.post@n5.nabble.com> <20140331083126.GA7206@sniper> <20140331211558.GA7886@seas.upenn.edu> Message-ID: On Tue, Apr 1, 2014 at 4:15 AM, Brent Yorgey wrote: > Don't forget Joe Fredette who also did it for a year! Notwithstanding the valuative opinions expressed therein, let me emend the earlier motion of thanks to everyone who has ever served as HWN editor. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Tue Apr 1 04:37:00 2014 From: gershomb at gmail.com (Gershom Bazerman) Date: Tue, 01 Apr 2014 00:37:00 -0400 Subject: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond Message-ID: <533A426C.5070108@gmail.com> There's been lots of exciting work going into the forthcoming GHC 7.8.1 release. But even with all these new features, our language is far from complete and I wouldn't want the GHC team to rest on their laurels. Especially with so much renewed community involvement in GHC development, it seems appropriate to share some ideas some of us have been discussing for future releases, and take a poll of community consensus regarding which ones people might be excited to jump in and help out with, or might find particularly helpful. One important area that needs work is exceptions. These are famously difficult, and many libraries have been written to provide checked exceptions, or unify error and exceptions in various ways. It seems to me that the problem, all along, has been that we've decided to give Haskell _imprecise exceptions_ with special semantics. It would alleviate a great deal of confusion if we implemented a -fprecise-exceptions flag that remedied this. Additionally, while we have long known that Haskell is not a "lazy" language but a "non-strict" one, our leading compiler only rarely takes advantage of this. It is well known that for every program there is a reduction strategy that preserves non-strict semantics while using as few reductions as possible. This is known as the "optimal reduction" strategy, and it is calculable and well understood. We should put some work into a -foptimal-reduction flag. Another important area of research is quantum computation. The D-Wave Two, with 512 qbits, is a commercially available quantum computer now deployed in a few leading institutions. As more and more people begin to purchase D-Wave systems for home hacking, every language worth its salt will need to be able to target this system. Now that cross compilation is more fully supported, it would be good to start putting work into a dwave backend. We've also seen a lot of interest in distribution and cloud computing. From the articles I've read, efficient concurrent programming involves using node.js, so I think we should put some work into writing a new-new-new-IO Manager built on top of this technology. Furthermore, it's ridiculous that while Haskell allows simple concurrent and distributed programming, it offers no simple way to set up a distributed environment. Work should be put into a compiler mode that provisions cloud resources automatically and distributes the target binary among them, with a flag such as: -fvia-s3 _credit_card_number_ There are a few cases where a good idea in GHC can be taken further, and I don't know why we haven't tried already. For example, we've found that despite introducing some occasional problems, the state hack also has drastically improved performance. Since it works so well, we should provide a dual to -fno-state-hack, -fmore-state-hack, for those who really need every last drop of performance. Similarly, now we have type holes that let us see what types should be inserted in various spots. -fvalue-holes is the next logical step, to tell us what terms we should be writing. Also, while we've put so much emphasis on correctness, we've also loosened the bolts optionally the other way, with flags such as -XIncoherentInstances. Along the same lines, I would like to introduce -XImpossibleInstances to let us express such useful things as "instance Int String," "instance IO Comonad," and "instance data if". -fdefer-type-errors allows us to defer type errors to runtime. Having spent some time with JavaScript lately, I think this doesn't go nearly far enough. It would be good to run programs with other sorts of problems as well, for educational purposes and for quick hacking. So work should be put into a -fdefer-scope-errors flag, as well as -fon-error-resume-next, which has done wonders for the resilience of Visual Basic code (see also the wildly useful ability to set the top level error handler in PHP). With all these features put together, we have a powerful new way to approach Haskell programming, and it would be good to enable them by default on .ilhs files (illiterate haskell). It also was pointed out to me recently by Jason Dagit that while we have had debates and confusion over closed and open type families and functions for years, topologists have solved this problem elegantly. With some basic point set topology under one's belt, a -XClopenTypeFamilies extension seems almost trivial to implement. Finally, I'm very sorry to see that my proposal for youtube syntax has languished, and I hope it can be revived: http://www.haskell.org/pipermail/haskell-cafe/2012-April/100527.html HTH HAND, Gershom -------------- next part -------------- An HTML attachment was scrubbed... URL: From elliot.robinson at argiopetech.com Tue Apr 1 04:53:01 2014 From: elliot.robinson at argiopetech.com (Elliot Robinson) Date: Tue, 1 Apr 2014 00:53:01 -0400 Subject: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond In-Reply-To: <533A426C.5070108@gmail.com> References: <533A426C.5070108@gmail.com> Message-ID: I am highly in favour of all the features mentioned in this document, and I wish to subscribe to your newsletter. I also suggest we fire some Windows developers from the GHC team. Said group is currently far too productive. --- Elliot Robinson -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Tue Apr 1 05:07:03 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue, 01 Apr 2014 14:07:03 +0900 (JST) Subject: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond In-Reply-To: <533A426C.5070108@gmail.com> References: <533A426C.5070108@gmail.com> Message-ID: <20140401.140703.1346190877164591597.kazu@iij.ad.jp> Hi Gershom, > We've also seen a lot of interest in distribution and cloud computing. > From the articles I've read, efficient concurrent programming involves > using node.js, so I think we should put some work into writing a > new-new-new-IO Manager built on top of this technology. As a member of Mio developers, I don't understand this sentence. Would you concretely explain what kind of node.js technologies should be taken into new-new-new-IO Manager? --Kazu From fuuzetsu at fuuzetsu.co.uk Tue Apr 1 05:17:02 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 01 Apr 2014 06:17:02 +0100 Subject: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond In-Reply-To: <20140401.140703.1346190877164591597.kazu@iij.ad.jp> References: <533A426C.5070108@gmail.com> <20140401.140703.1346190877164591597.kazu@iij.ad.jp> Message-ID: <533A4BCE.7040407@fuuzetsu.co.uk> On 01/04/14 06:07, Kazu Yamamoto (????) wrote: > Hi Gershom, > >> We've also seen a lot of interest in distribution and cloud computing. >> From the articles I've read, efficient concurrent programming involves >> using node.js, so I think we should put some work into writing a >> new-new-new-IO Manager built on top of this technology. > > As a member of Mio developers, I don't understand this sentence. Would > you concretely explain what kind of node.js technologies should be > taken into new-new-new-IO Manager? > > --Kazu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Check the date, Kazu. This joke doesn't work too well on lists with people with timezones all over ;). -- Mateusz K. From michael at snoyman.com Tue Apr 1 05:28:08 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 1 Apr 2014 08:28:08 +0300 Subject: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond In-Reply-To: <20140401.140703.1346190877164591597.kazu@iij.ad.jp> References: <533A426C.5070108@gmail.com> <20140401.140703.1346190877164591597.kazu@iij.ad.jp> Message-ID: On Tue, Apr 1, 2014 at 8:07 AM, Kazu Yamamoto wrote: > Hi Gershom, > > > We've also seen a lot of interest in distribution and cloud computing. > > From the articles I've read, efficient concurrent programming involves > > using node.js, so I think we should put some work into writing a > > new-new-new-IO Manager built on top of this technology. > > As a member of Mio developers, I don't understand this sentence. Would > you concretely explain what kind of node.js technologies should be > taken into new-new-new-IO Manager? > > It's really simple: node.js is webscale, Mio is not. I'm sorry, but you simply didn't do a good enough job making sure that random packets were lost when sending network traffic, or that writing data to disk may sporadically fail. Better luck next time. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.doel at gmail.com Tue Apr 1 06:54:14 2014 From: dan.doel at gmail.com (Dan Doel) Date: Tue, 1 Apr 2014 02:54:14 -0400 Subject: [Haskell-cafe] Eta Reduction Message-ID: In the past year or two, there have been multiple performance problems in various areas related to the fact that lambda abstraction is not free, though we tend to think of it as so. A major example of this was deriving of Functor. If we were to derive Functor for lists, we would end up with something like: instance Functor [] where fmap _ [] = [] fmap f (x:xs) = f x : fmap (\y -> f y) xs This definition is O(n^2) when fully evaluated,, because it causes O(n) eta expansions of f, so we spend time following indirections proportional to the depth of the element in the list. This has been fixed in 7.8, but there are other examples. I believe lens, [1] for instance, has some stuff in it that works very hard to avoid this sort of cost; and it's not always as easy to avoid as the above example. Composing with a newtype wrapper, for instance, causes an eta expansion that can only be seen as such at the core level. The obvious solution is: do eta reduction. However, this is not operationally sound currently. The problem is that seq is capable of telling the difference between the following two expressions: undefined \x -> undefined x The former causes seq to throw an exception, while the latter is considered defined enough to not do so. So, if we eta reduce, we can cause terminating programs to diverge if they make use of this feature. Luckily, there is a solution. Semantically one would usually identify the above two expressions. While I do believe one could construct a semantics that does distinguish them, it is not the usual practice. This suggests that there is a way to not distinguish them, perhaps even including seq. After all, the specification of seq is monotone and continuous regardless of whether we unify ? with \x -> ? x or insert an extra element for the latter. The currently problematic case is function spaces, so I'll focus on it. How should: seq : (a -> b) -> c -> c act? Well, other than an obvious bottom, we need to emit bottom whenever our given function is itself bottom at every input. This may first seem like a problem, but it is actually quite simple. Without loss of generality, let us assume that we can enumerate the type a. Then, we can feed these values to the function, and check their results for bottom. Conal Elliot has prior art for this sort of thing with his unamb [2] package. For each value x :: a, simply compute 'f x `seq` ()' in parallel, and look for any successes. If we ever find one, we know the function is non-bottom, and we can return our value of c. If we never finish searching, then the function must be bottom, and seq should not terminate, so we have satisfied the specification. Now, some may complain about the enumeration above. But this, too, is a simple matter. It is well known that Haskell programs are denumerable. So it is quite easy to enumerate all Haskell programs that produce a value, check whether that value has the type we're interested in, and compute said value. All of this can be done in Haskell. Thus, every Haskell type is programatically enumerable in Haskell, and we can use said enumeration in our implementation of seq for function types. I have discussed this with Russell O'Connor [3], and he assures me that this argument should be sufficient even if we consider semantic models of Haskell that contain values not denoted by any Haskell program, so we should be safe there. The one possible caveat is that this implementation of seq is not operationally uniform across all types, so the current fully polymorphic type of seq may not make sense. But moving back to a type class based approach isn't so bad, and this time we will have a semantically sound backing, instead of just having a class with the equivalent of the current magic function in it. Once this machinery is in place, we can eta reduce to our hearts' content, and not have to worry about breaking semantics. We'd no longer put the burden on programmers to use potentially unsafe hacks to avoid eta expansions. I apologize for not sketching an implementation of the above algorithm, but I'm sure it should be elementary enough to make it into GHC in the next couple versions. Everyone learns about this type of thing in university computer science programs, no? Thoughts? Comments? Questions? Cheers, -- Dan [1] http://hackage.haskell.org/package/lens [2] http://hackage.haskell.org/package/unamb [3] http://r6.ca/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Tue Apr 1 07:08:07 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue, 01 Apr 2014 16:08:07 +0900 (JST) Subject: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond In-Reply-To: <533A4BCE.7040407@fuuzetsu.co.uk> References: <533A426C.5070108@gmail.com> <20140401.140703.1346190877164591597.kazu@iij.ad.jp> <533A4BCE.7040407@fuuzetsu.co.uk> Message-ID: <20140401.160807.1385637785828516169.kazu@iij.ad.jp> > Check the date, Kazu. X-( --Kazu From ivan.miljenovic at gmail.com Tue Apr 1 07:34:33 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 1 Apr 2014 18:34:33 +1100 Subject: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond In-Reply-To: <20140401.160807.1385637785828516169.kazu@iij.ad.jp> References: <533A426C.5070108@gmail.com> <20140401.140703.1346190877164591597.kazu@iij.ad.jp> <533A4BCE.7040407@fuuzetsu.co.uk> <20140401.160807.1385637785828516169.kazu@iij.ad.jp> Message-ID: On 1 April 2014 18:08, Kazu Yamamoto wrote: >> Check the date, Kazu. > > X-( Yeah, I didn't realise that when I first read it, because it came in the afternoon for me, so _of course_ all the jokes were over... > > --Kazu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From pierreetienne.meunier at gmail.com Tue Apr 1 09:21:27 2014 From: pierreetienne.meunier at gmail.com (=?windows-1252?Q?Pierre-=C9tienne_Meunier?=) Date: Tue, 1 Apr 2014 11:21:27 +0200 Subject: [Haskell-cafe] Problems with Network/MVar Message-ID: Hello cafe, I?m trying to run a server to synchronize a bunch of machines, and one of the threads keeps crashing every ~50 hours. One of the threads is an HTTP server and stays alive forever, so it?s not a Unix signal problem. I don?t have much information on its stdout/stderr, and the bug is not very reproducible, since it can happen even though very few of its maximum ~200 clients are connected. Is there a reason why the following can stop after some time? server::Config -> MVar State -> IO () server config state=withSocketsDo $ do installHandler sigPIPE Ignore Nothing threads<-Sem.new $ maxThreads config forever $ do E.catch (bracket (listenOn $ port config)) sClose $ \sock->forever $ do (s,a,_)<-accept sock wait threads forkIO $ (reply state s a)`finally`(signal threads)`E.catch`(\e->let _=e::IOException in return ()) (\e->let _=e::IOException in return ()) threadDelay 100000 This was compiled with GHC 7.6.3, -threaded and run on Debian Jessie (I have not tested other settings), and Config and State are both record types. Thanks, Pierre From greg at gregorycollins.net Tue Apr 1 09:29:51 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Tue, 1 Apr 2014 11:29:51 +0200 Subject: [Haskell-cafe] Problems with Network/MVar In-Reply-To: References: Message-ID: On Tue, Apr 1, 2014 at 11:21 AM, Pierre-?tienne Meunier < pierreetienne.meunier at gmail.com> wrote: > Hello cafe, > > I?m trying to run a server to synchronize a bunch of machines, and one of > the threads keeps crashing every ~50 hours. > You seem to be throwing away the exception messages so it will be difficult to diagnose why. server::Config -> MVar State -> IO () > server config state=withSocketsDo $ do > installHandler sigPIPE Ignore Nothing > threads<-Sem.new $ maxThreads config > forever $ do > E.catch (bracket (listenOn $ port config)) sClose $ > \sock->forever $ do > (s,a,_)<-accept sock > There is a race condition here, you can get an asynchronous exception any time after accepting the socket that would cause it to leak open. I'm guessing you might running out of file descriptors. This whole section should be run under "mask" and you should only unmask async exceptions when you know you've installed a signal handler to clean up afterwards. > wait threads > forkIO $ (reply state s a)`finally`(signal > threads)`E.catch`(\e->let _=e::IOException in return ()) > Try "forkIOWithUnmask", same advice applies in the child thread. G -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlepptop at henning-thielemann.de Tue Apr 1 09:34:56 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Tue, 01 Apr 2014 11:34:56 +0200 Subject: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond In-Reply-To: <533A426C.5070108@gmail.com> References: <533A426C.5070108@gmail.com> Message-ID: <533A8840.5030501@henning-thielemann.de> These are indeed great ideas! I like especially this one: Am 01.04.2014 06:37, schrieb Gershom Bazerman: > Another important area of research is quantum computation. The D-Wave > Two, with 512 qbits, is a commercially available quantum computer now > deployed in a few leading institutions. As more and more people begin to > purchase D-Wave systems for home hacking, every language worth its salt > will need to be able to target this system. Now that cross compilation > is more fully supported, it would be good to start putting work into a > dwave backend. I think quantum support would justify to give the compiler an according name like QHC. Or if it is released on days like today, AHC would also be a good name. From klao at nilcons.com Tue Apr 1 09:55:57 2014 From: klao at nilcons.com (Mihaly Barasz) Date: Tue, 1 Apr 2014 11:55:57 +0200 Subject: [Haskell-cafe] Towards a better time library (announcing tz) In-Reply-To: References: <20140331181543.GA20036@cs.elte.hu> Message-ID: On Tue, Apr 1, 2014 at 3:21 AM, Renzo Carbonara wrote: > I'm currently a user of the `timezone-olson` and `timezone-series` > libraries, so I can understand the requirement for better time zone > representations than the one offered by `time`. I think it would be > best for the community if your work and the one in `timezone-olson` > and `timezone-series` could be integrated somehow, as there doesn't > seem to be a need to have two different implementations for parsing > the Olson file format. As far as I know, Yitzchak is willing to > improve his libraries, I CC him here. It seems that we have quite different views on things. :) But of course, I agree that one good solution is much better than two half-baked ones, I'm just not exactly sure how to proceed. I think, it's best if we give it some time and slowly figure out a way to compromise and cooperate. > Given that you are shipping a timezone database with your package, as > a user I'd really prefer `loadTZFromDB` to be `String -> Maybe TZ` > instead of `String -> IO TZ` so that it can be used in pure code. > You'd probably need to hardcode the contents of the `*.zone` files you > are including within a Haskell module, but that could be done > automatically using some script. This is in the working, I just didn't get to it yet. One problem with this is that once you use the module providing this pure interface, _all_ of the time zone definitions will be compiled into your binary, increasing its size substantially (few hundred kilobytes). It's not a problem for many uses, but this is why I don't want it as the only mechanism. > Moreover, an idea I've been toying with is writing a program that > parses the tzdata information files and generates a type-safe pure API > for interacting with the tz data in memory. For example, given the > tzdata information files you would generate types, values and pure > functions such as the following: > > data TimeZone > = Europe__Paris > | America__Buenos_Aires > | ... > > timeZoneName :: TimeZone -> Text > timeZoneName Europe__Paris = "Europe/Paris" > timeZoneName America__Buenos_Aires = "America/Buenos_Aires" > timeZoneName ... = ... > > timeZoneFromName :: Text -> Maybe TimeZone > timeZoneFromName "Europe/Paris" = Just Europe__Paris > timeZoneFromName "America/Buenos_Aires" = Just America__Buenos_Aires > timeZoneFromName ... = ... > timeZoneFromName _ = Nothing > > timeZoneInfo :: TimeZone -> TZ > timeZoneInfo Europe_Paris = ... some hardcoded value (the `TZ` in > your library) ... > timeZoneInfo ... = ... Interesting idea, I have to think about it a bit more, but right now I don't see why not. > As a minor tidbit: If one is going to do this, I think a good idea is > to devise a package versioning system that's somewhat follows the tz > database versions. This is what I had in mind for the `tzdata` package > I was planning to create (unless someone else does it first): > > The version number of the package is always @YYYYMMDD.B.C@, where > @YYYYMMDD@ are the year (@YYYY@), the month (@MM@) and the day (@DD@) > of the @tzdata@ release this particular version was designed for. For > example, @tzdata 2013i@ was officially released on @2013-12-17@, so a > version of this package that was designed for @tzdata 2013i@ will > carry the version number @20131217.B.C at . However, that doesn't mean > that this library won't work with versions of the @tzdata@ library > different than @2013i@, it's just that support for new or old data > (say, the name of a new time zone that was introduced) can be missing. > The @B@ and @C@ values in the version number of this library as > treated as the /major/ and /minor/ versions respectively, as suggested > in the /Haskell Package Version Policy/ page: > http://www.haskell.org/haskellwiki/Package_versioning_policy Hmm, I see the reasoning behind this, but I think it would be annoying for most of the users. Or not? If we separate only the data in a separate package (on which `tz` depends), then very few people would want to explicitly specify its version... Yeah, this might work. :) Mihaly > > Maybe the `timezone-olson`, `timezone-series`, this `tzdata` idea and > `tz` could all live together; with `tz` depending on the others? Just > a thought :) > > > Regards, > > Renzo Carbonara. > > > On Mon, Mar 31, 2014 at 3:15 PM, Mihaly Barasz wrote: >> >> I would like to propose reforming the 'time' [1] library. >> >> >> Initially, I was just planning to announce my new 'tz' [2] library, but >> realized that I have a more important agenda. Namely: Haskell needs a >> better time library! >> >> Let me summarize what are - in my view - the biggest deficiencies of >> 'time': >> >> 1. Inefficient data structures and implementations. >> >> 2. Ad-hoc API which is hard to remember and frustrating to work with. >> >> 3. Conceptually wrong representations and/or missing concepts. >> >> The wonderful thyme [3] package (by Liyang HU) improves a lot on #1 by >> choosing better data structures and careful implementations and on #2 >> by lensifying the API. >> >> But, it was the #3 that caused me the most frustration lately; most >> importantly the time zone handling. >> >> There is a TimeZone data type in 'time', but it is a misnomer, it >> basically represents a fixed time difference (with a label and a DST >> flag). 'time' basically adapts the broken approach from libc: you can >> work with one time zone at a time, which is defined globally for your >> program (via the TZ environment variable). So, the transformation >> between UTCTime and LocalTime which should have been a pure >> function can only be done in IO now. Like this: >> >> do tz <- getTimeZone ut >> return $ utcToLocalTime tz ut >> >> >> Oh, and just to hammer down on the point #1 from the list above. This >> code runs in about 6100 ns on my machine. The drop-in replacement from >> tz: utcToLocalTimeTZ [4] (which is actually pure) runs in 2300 ns. >> While this is a significant improvement, it's easy to miss the point >> where the bulk of the inefficiency comes from the data structures. In >> my main project we represent times as Int64 (raw nanoseconds since >> UNIX epoch; and similar representation for zoned times). And to >> convert those to and from different time zones we need 40 ns. That's >> right, a 150 _times_ improvement! (There are many other interesting >> benchmark results that I could mention. An exciting bottom line: we >> can actually beat the libc in many use-cases!) >> >> The 'tz' package is still very much in flux. I will try to solidify >> the API soon, but until then it should be considered more of a proof >> of concept. There is some missing functionality, for example. On the >> other hand, there are the 'timezone-series' [5] and 'timezone-olson' >> [6] packages that together provide about the same functionality as >> 'tz' (minus the efficiency), and I'd like to explore if we could >> remove some of the overlap. But, all kind of suggestions and requests >> are welcome! >> >> More importantly, I'd like to hear the opinions of the community about >> the general issue of a better time library! Do we need one? How >> should we proceed about it? I think, Haskell could potentially have >> one of the best time libraries, but the current de-facto standard is >> mediocre at best. Unfortunately, designing a good time library is very >> far from trivial, as many existing examples demonstrate. And I >> definitely don't know enough for it. (I understand time zone info >> files, now that I wrote tz, but that's just a tiny fraction of what's >> needed.) So, if you think you can contribute to the design (have >> important use-cases in mind, know good examples of API, have some >> experience working with dates and time, etc. etc.) - speak up! >> >> >> Mihaly >> >> >> Footnotes: >> >> [1] http://hackage.haskell.org/package/time >> [2] http://hackage.haskell.org/package/tz >> [3] http://hackage.haskell.org/package/thyme >> [4] http://hackage.haskell.org/package/tz-0.0.0.1/docs/Data-Time-Zones.html#v:utcToLocalTimeTZ >> [5] http://hackage.haskell.org/package/timezone-series >> [6] http://hackage.haskell.org/package/timezone-olson >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> >> iQEVAwUBUzmwz/i5FOsZqz9DAQJGcAgAhPF4JLWnL4ApJ2qxqAwHqXcIPqRpVb5A >> TH2LERH2A/6b3xXCRYsPgyD43j2CzqZGffRvINSw9fGoJYWuRmis5dCf9hwPiKtg >> hK1wUCz9AsKlKBZztR9eLxROqM/xXMH4HaFydr/YOVffDVY6fUIK9fPbRFJBVCBq >> UwtoemQSVLUIIRxZyg5pdL+dxadnttm7bGC+UuQJHtSSBRweEh3unr8dcNm4idC3 >> nxWOMclbo2hyMdwzDo1bqugugq2xCGPiGrL550aF1lCGD2pf2vQO1feW/5XyMaCR >> Oj6gI+eHo8SuhUx30Dokv1kx8Ssay0aVmmASCJKnR8Bwv1J9AKWo3A== >> =Bp64 >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> From chriswarbo at googlemail.com Tue Apr 1 10:23:54 2014 From: chriswarbo at googlemail.com (Chris Warburton) Date: Tue, 01 Apr 2014 11:23:54 +0100 Subject: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond In-Reply-To: <533A8840.5030501@henning-thielemann.de> (Henning Thielemann's message of "Tue, 01 Apr 2014 11:34:56 +0200") References: <533A426C.5070108@gmail.com> <533A8840.5030501@henning-thielemann.de> Message-ID: <861txhfiv9.fsf@gmail.com> Henning Thielemann writes: > These are indeed great ideas! > > I like especially this one: > > > Am 01.04.2014 06:37, schrieb Gershom Bazerman: > >> Another important area of research is quantum computation. The D-Wave >> Two, with 512 qbits, is a commercially available quantum computer now >> deployed in a few leading institutions. As more and more people begin to >> purchase D-Wave systems for home hacking, every language worth its salt >> will need to be able to target this system. Now that cross compilation >> is more fully supported, it would be good to start putting work into a >> dwave backend. > > I think quantum support would justify to give the compiler an > according name like QHC. Or if it is released on days like today, AHC > would also be a good name. GHC has supported quantum computing from the start, via "lazy" evaluation. Specifically, variables don't have a value until you look at them ('collapsing the thunk'). I think this justifies changing the name to "LHC". Regards, Chris From P.Achten at cs.ru.nl Tue Apr 1 11:07:53 2014 From: P.Achten at cs.ru.nl (Peter Achten) Date: Tue, 01 Apr 2014 13:07:53 +0200 Subject: [Haskell-cafe] [TFP2014] First Call for Participation Message-ID: <533A9E09.40107@cs.ru.nl> --------------------------------- 1ST CALL FOR PARTICIPATION --------------------------------- ======== TFP 2014 =========== 15th Symposium on Trends in Functional Programming May 26-28, 2014 Utrecht University Soesterberg, The Netherlands http://www.cs.uu.nl/wiki/TFP2014/WebHome Registration is now open for the symposium on Trends in Functional Programming (TFP). It is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results. Submission for TFP is now closed, and the complete programme (29 presentations and two invited talks) for TFP can be perused here: http://www.cs.uu.nl/wiki/TFP2014/PresentationSchedule TFP 2014 will be the main event of a pair of functional programming events. The other is the International Workshop on Trends in Functional Programming in Education (TFPIE). TFPIE will take place on May 25th. Its website is located at http://www.cs.uwyo.edu/~jlc/tfpie14/ . The submission deadline for TFPIE is April 21, 2014. INVITED SPEAKERS TFP is pleased to announce talks by the following two invited speakers: John Hughes of Chalmers, Goteborg, Sweden, is well-known as author of Why Functional Programming Matters, and as one of the designers of QuickCheck (together with Koen Claessen); the paper on QuickCheck won the ICFP Most Influential Paper Award in 2010. Currently he divides his time between his professorship and Quviq, a company that performs property-based testing of software with a tool implemented in Erlang. Geoffrey Mainland received his PhD from Harvard University where he was advised by Greg Morrisett and Matt Welsh. After a two year postdoc with the Programming Principles and Tools group at Microsoft Research Cambridge, he is now an assistant professor at Drexel University. His research focuses on high-level programming language and runtime support for non-general purpose computation. IMPORTANT DATES Early registration: April 14, 2014 Late registration: May 15, 2014 TFPIE Workshop: May 25, 2014 TFP Symposium: May 26-28, 2014 Registrations can be made at the following URL: http://www.cs.uu.nl/wiki/TFP2014/Register This page will also point you to the web page of the venue where you can arrange for your stay. hoping to see you there. Jurriaan Hage (General Chair) From pierreetienne.meunier at gmail.com Tue Apr 1 11:35:20 2014 From: pierreetienne.meunier at gmail.com (=?windows-1252?Q?Pierre-=C9tienne_Meunier?=) Date: Tue, 1 Apr 2014 13:35:20 +0200 Subject: [Haskell-cafe] Problems with Network/MVar In-Reply-To: References: Message-ID: Em 01/04/2014, ?(s) 11:29, Gregory Collins escreveu: > On Tue, Apr 1, 2014 at 11:21 AM, Pierre-?tienne Meunier wrote: >> Hello cafe, >> >> I?m trying to run a server to synchronize a bunch of machines, and one of the threads keeps crashing every ~50 hours. >> > You seem to be throwing away the exception messages so it will be difficult to diagnose why. You?re right, that was really stupid. It is my first time dealing with (exceptions+threads+network) in Haskell. >> server::Config -> MVar State -> IO () >> server config state=withSocketsDo $ do >> installHandler sigPIPE Ignore Nothing >> threads<-Sem.new $ maxThreads config >> forever $ do >> E.catch (bracket (listenOn $ port config)) sClose $ >> \sock->forever $ do >> (s,a,_)<-accept sock >> > There is a race condition here, you can get an asynchronous exception any time after accepting the socket that would cause it to leak open. I'm guessing you might running out of file descriptors. This whole section should be run under "mask" and you should only unmask async exceptions when you know you've installed a signal handler to clean up afterwards. Is this the same as using ?bracket accept hClose $ blabla? (modulo correct types)? >> wait threads >> forkIO $ (reply state s a)`finally`(signal threads)`E.catch`(\e->let _=e::IOException in return ()) >> > Try "forkIOWithUnmask", same advice applies in the child thread. Thanks. Let?s see how it goes in two days. Pierre From greg at gregorycollins.net Tue Apr 1 12:05:36 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Tue, 1 Apr 2014 14:05:36 +0200 Subject: [Haskell-cafe] Problems with Network/MVar In-Reply-To: References: Message-ID: On Tue, Apr 1, 2014 at 1:35 PM, Pierre-?tienne Meunier < pierreetienne.meunier at gmail.com> wrote: > Is this the same as using ?bracket accept hClose $ blabla? (modulo correct > types)? Sort of (and you could turn this pattern into a similar combinator), except here you want to accept the socket and hand it off to a child thread. In order to make that pattern safe you have to use mask: foo = mask $ \unmask -> do (s, a, _) <- unmask $ accept sock -- here async exceptions are blocked which gives you time to install a signal -- handler, you only unmask exceptions once the handler is installed forkIOWithUnmask $ \restore -> ((restore $ reply state s a) `catch` handler) `finally` (cleanup s a) -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Tue Apr 1 13:17:31 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 1 Apr 2014 06:17:31 -0700 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: Message-ID: I think this is a great idea and should become a top priority. I would probably start by switching to a type-class-based seq, after which perhaps the next step forward would become more clear. John L. On Apr 1, 2014 2:54 AM, "Dan Doel" wrote: > In the past year or two, there have been multiple performance problems in > various areas related to the fact that lambda abstraction is not free, > though we > tend to think of it as so. A major example of this was deriving of > Functor. If we > were to derive Functor for lists, we would end up with something like: > > instance Functor [] where > fmap _ [] = [] > fmap f (x:xs) = f x : fmap (\y -> f y) xs > > This definition is O(n^2) when fully evaluated,, because it causes O(n) eta > expansions of f, so we spend time following indirections proportional to > the > depth of the element in the list. This has been fixed in 7.8, but there are > other examples. I believe lens, [1] for instance, has some stuff in it that > works very hard to avoid this sort of cost; and it's not always as easy to > avoid > as the above example. Composing with a newtype wrapper, for instance, > causes an > eta expansion that can only be seen as such at the core level. > > The obvious solution is: do eta reduction. However, this is not > operationally > sound currently. The problem is that seq is capable of telling the > difference > between the following two expressions: > > undefined > \x -> undefined x > > The former causes seq to throw an exception, while the latter is considered > defined enough to not do so. So, if we eta reduce, we can cause terminating > programs to diverge if they make use of this feature. > > Luckily, there is a solution. > > Semantically one would usually identify the above two expressions. While I > do > believe one could construct a semantics that does distinguish them, it is > not > the usual practice. This suggests that there is a way to not distinguish > them, > perhaps even including seq. After all, the specification of seq is > monotone and > continuous regardless of whether we unify ? with \x -> ? x or insert an > extra > element for the latter. > > The currently problematic case is function spaces, so I'll focus on it. How > should: > > seq : (a -> b) -> c -> c > > act? Well, other than an obvious bottom, we need to emit bottom whenever > our > given function is itself bottom at every input. This may first seem like a > problem, but it is actually quite simple. Without loss of generality, let > us > assume that we can enumerate the type a. Then, we can feed these values to > the > function, and check their results for bottom. Conal Elliot has prior art > for > this sort of thing with his unamb [2] package. For each value x :: a, > simply > compute 'f x `seq` ()' in parallel, and look for any successes. If we ever > find > one, we know the function is non-bottom, and we can return our value of c. > If we > never finish searching, then the function must be bottom, and seq should > not > terminate, so we have satisfied the specification. > > Now, some may complain about the enumeration above. But this, too, is a > simple > matter. It is well known that Haskell programs are denumerable. So it is > quite > easy to enumerate all Haskell programs that produce a value, check whether > that > value has the type we're interested in, and compute said value. All of > this can > be done in Haskell. Thus, every Haskell type is programatically enumerable > in > Haskell, and we can use said enumeration in our implementation of seq for > function types. I have discussed this with Russell O'Connor [3], and he > assures > me that this argument should be sufficient even if we consider semantic > models > of Haskell that contain values not denoted by any Haskell program, so we > should > be safe there. > > The one possible caveat is that this implementation of seq is not > operationally > uniform across all types, so the current fully polymorphic type of seq may > not > make sense. But moving back to a type class based approach isn't so bad, > and > this time we will have a semantically sound backing, instead of just > having a > class with the equivalent of the current magic function in it. > > Once this machinery is in place, we can eta reduce to our hearts' content, > and > not have to worry about breaking semantics. We'd no longer put the burden > on > programmers to use potentially unsafe hacks to avoid eta expansions. I > apologize > for not sketching an implementation of the above algorithm, but I'm sure it > should be elementary enough to make it into GHC in the next couple > versions. > Everyone learns about this type of thing in university computer science > programs, no? > > Thoughts? Comments? Questions? > > Cheers, > -- Dan > > [1] http://hackage.haskell.org/package/lens > [2] http://hackage.haskell.org/package/unamb > [3] http://r6.ca/ > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Apr 1 13:28:23 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 1 Apr 2014 09:28:23 -0400 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: Message-ID: Can we throw some whole program partial evaluation with a termination decision oracle into the mix? On Tuesday, April 1, 2014, John Lato wrote: > I think this is a great idea and should become a top priority. I would > probably start by switching to a type-class-based seq, after which perhaps > the next step forward would become more clear. > > John L. > On Apr 1, 2014 2:54 AM, "Dan Doel" > > wrote: > >> In the past year or two, there have been multiple performance problems in >> various areas related to the fact that lambda abstraction is not free, >> though we >> tend to think of it as so. A major example of this was deriving of >> Functor. If we >> were to derive Functor for lists, we would end up with something like: >> >> instance Functor [] where >> fmap _ [] = [] >> fmap f (x:xs) = f x : fmap (\y -> f y) xs >> >> This definition is O(n^2) when fully evaluated,, because it causes O(n) >> eta >> expansions of f, so we spend time following indirections proportional to >> the >> depth of the element in the list. This has been fixed in 7.8, but there >> are >> other examples. I believe lens, [1] for instance, has some stuff in it >> that >> works very hard to avoid this sort of cost; and it's not always as easy >> to avoid >> as the above example. Composing with a newtype wrapper, for instance, >> causes an >> eta expansion that can only be seen as such at the core level. >> >> The obvious solution is: do eta reduction. However, this is not >> operationally >> sound currently. The problem is that seq is capable of telling the >> difference >> between the following two expressions: >> >> undefined >> \x -> undefined x >> >> The former causes seq to throw an exception, while the latter is >> considered >> defined enough to not do so. So, if we eta reduce, we can cause >> terminating >> programs to diverge if they make use of this feature. >> >> Luckily, there is a solution. >> >> Semantically one would usually identify the above two expressions. While >> I do >> believe one could construct a semantics that does distinguish them, it is >> not >> the usual practice. This suggests that there is a way to not distinguish >> them, >> perhaps even including seq. After all, the specification of seq is >> monotone and >> continuous regardless of whether we unify ? with \x -> ? x or insert an >> extra >> element for the latter. >> >> The currently problematic case is function spaces, so I'll focus on it. >> How >> should: >> >> seq : (a -> b) -> c -> c >> >> act? Well, other than an obvious bottom, we need to emit bottom whenever >> our >> given function is itself bottom at every input. This may first seem like a >> problem, but it is actually quite simple. Without loss of generality, let >> us >> assume that we can enumerate the type a. Then, we can feed these values >> to the >> function, and check their results for bottom. Conal Elliot has prior art >> for >> this sort of thing with his unamb [2] package. For each value x :: a, >> simply >> compute 'f x `seq` ()' in parallel, and look for any successes. If we >> ever find >> one, we know the function is non-bottom, and we can return our value of >> c. If we >> never finish searching, then the function must be bottom, and seq should >> not >> terminate, so we have satisfied the specification. >> >> Now, some may complain about the enumeration above. But this, too, is a >> simple >> matter. It is well known that Haskell programs are denumerable. So it is >> quite >> easy to enumerate all Haskell programs that produce a value, check >> whether that >> value has the type we're interested in, and compute said value. All of >> this can >> be done in Haskell. Thus, every Haskell type is programatically >> enumerable in >> Haskell, and we can use said enumeration in our implementation of seq for >> function types. I have discussed this with Russell O'Connor [3], and he >> assures >> me that this argument should be sufficient even if we consider semantic >> models >> of Haskell that contain values not denoted by any Haskell program, so we >> should >> be safe there. >> >> The one possible caveat is that this implementation of seq is not >> operationally >> uniform across all types, so the current fully polymorphic type of seq >> may not >> make sense. But moving back to a type class based approach isn't so bad, >> and >> this time we will have a semantically sound backing, instead of just >> having a >> class with the equivalent of the current magic function in it. >> >> Once this machinery is in place, we can eta reduce to our hearts' >> content, and >> not have to worry about breaking semantics. We'd no longer put the burden >> on >> programmers to use potentially unsafe hacks to avoid eta expansions. I >> apologize >> for not sketching an implementation of the above algorithm, but I'm sure >> it >> should be elementary enough to make it into GHC in the next couple >> versions. >> Everyone learns about this type of thing in university computer science >> programs, no? >> >> Thoughts? Comments? Questions? >> >> Cheers, >> -- Dan >> >> [1] http://hackage.haskell.org/package/lens >> [2] http://hackage.haskell.org/package/unamb >> [3] http://r6.ca/ >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Apr 1 14:32:27 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 1 Apr 2014 10:32:27 -0400 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: Message-ID: John, Check the date and consider the process necessary to "enumerate all Haskell programs and check their types". -Edward On Tue, Apr 1, 2014 at 9:17 AM, John Lato wrote: > I think this is a great idea and should become a top priority. I would > probably start by switching to a type-class-based seq, after which perhaps > the next step forward would become more clear. > > John L. > On Apr 1, 2014 2:54 AM, "Dan Doel" wrote: > >> In the past year or two, there have been multiple performance problems in >> various areas related to the fact that lambda abstraction is not free, >> though we >> tend to think of it as so. A major example of this was deriving of >> Functor. If we >> were to derive Functor for lists, we would end up with something like: >> >> instance Functor [] where >> fmap _ [] = [] >> fmap f (x:xs) = f x : fmap (\y -> f y) xs >> >> This definition is O(n^2) when fully evaluated,, because it causes O(n) >> eta >> expansions of f, so we spend time following indirections proportional to >> the >> depth of the element in the list. This has been fixed in 7.8, but there >> are >> other examples. I believe lens, [1] for instance, has some stuff in it >> that >> works very hard to avoid this sort of cost; and it's not always as easy >> to avoid >> as the above example. Composing with a newtype wrapper, for instance, >> causes an >> eta expansion that can only be seen as such at the core level. >> >> The obvious solution is: do eta reduction. However, this is not >> operationally >> sound currently. The problem is that seq is capable of telling the >> difference >> between the following two expressions: >> >> undefined >> \x -> undefined x >> >> The former causes seq to throw an exception, while the latter is >> considered >> defined enough to not do so. So, if we eta reduce, we can cause >> terminating >> programs to diverge if they make use of this feature. >> >> Luckily, there is a solution. >> >> Semantically one would usually identify the above two expressions. While >> I do >> believe one could construct a semantics that does distinguish them, it is >> not >> the usual practice. This suggests that there is a way to not distinguish >> them, >> perhaps even including seq. After all, the specification of seq is >> monotone and >> continuous regardless of whether we unify ? with \x -> ? x or insert an >> extra >> element for the latter. >> >> The currently problematic case is function spaces, so I'll focus on it. >> How >> should: >> >> seq : (a -> b) -> c -> c >> >> act? Well, other than an obvious bottom, we need to emit bottom whenever >> our >> given function is itself bottom at every input. This may first seem like a >> problem, but it is actually quite simple. Without loss of generality, let >> us >> assume that we can enumerate the type a. Then, we can feed these values >> to the >> function, and check their results for bottom. Conal Elliot has prior art >> for >> this sort of thing with his unamb [2] package. For each value x :: a, >> simply >> compute 'f x `seq` ()' in parallel, and look for any successes. If we >> ever find >> one, we know the function is non-bottom, and we can return our value of >> c. If we >> never finish searching, then the function must be bottom, and seq should >> not >> terminate, so we have satisfied the specification. >> >> Now, some may complain about the enumeration above. But this, too, is a >> simple >> matter. It is well known that Haskell programs are denumerable. So it is >> quite >> easy to enumerate all Haskell programs that produce a value, check >> whether that >> value has the type we're interested in, and compute said value. All of >> this can >> be done in Haskell. Thus, every Haskell type is programatically >> enumerable in >> Haskell, and we can use said enumeration in our implementation of seq for >> function types. I have discussed this with Russell O'Connor [3], and he >> assures >> me that this argument should be sufficient even if we consider semantic >> models >> of Haskell that contain values not denoted by any Haskell program, so we >> should >> be safe there. >> >> The one possible caveat is that this implementation of seq is not >> operationally >> uniform across all types, so the current fully polymorphic type of seq >> may not >> make sense. But moving back to a type class based approach isn't so bad, >> and >> this time we will have a semantically sound backing, instead of just >> having a >> class with the equivalent of the current magic function in it. >> >> Once this machinery is in place, we can eta reduce to our hearts' >> content, and >> not have to worry about breaking semantics. We'd no longer put the burden >> on >> programmers to use potentially unsafe hacks to avoid eta expansions. I >> apologize >> for not sketching an implementation of the above algorithm, but I'm sure >> it >> should be elementary enough to make it into GHC in the next couple >> versions. >> Everyone learns about this type of thing in university computer science >> programs, no? >> >> Thoughts? Comments? Questions? >> >> Cheers, >> -- Dan >> >> [1] http://hackage.haskell.org/package/lens >> [2] http://hackage.haskell.org/package/unamb >> [3] http://r6.ca/ >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Achten at cs.ru.nl Tue Apr 1 14:36:10 2014 From: P.Achten at cs.ru.nl (Peter Achten) Date: Tue, 01 Apr 2014 16:36:10 +0200 Subject: [Haskell-cafe] [TFPIE2014] final call for papers Message-ID: <533ACEDA.6060108@cs.ru.nl> 3rd International Workshop on Trends in Functional Programming in Education (TFPIE 2014) May 25, 2014 Utrecht University Soesterberg, The Netherlands (http://www.cs.uwyo.edu/~jlc/tfpie14/) The 3rd International Workshop on Trends in Functional Programming in Education, TFPIE 2014, will be co-located with the Symposium on Trends in Functional Programming (TFP 2014) at Soesterberg, at the ?Kontakt der Kontinenten? hotel in the Netherlands on Sunday, May 25th. TFP will follow from May 26-28. The goal of TFPIE is to gather researchers, teachers and professionals that use, or are interested in the use of, functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas and work-in-progress on the use of functional programming in education are discussed. The one-day workshop will foster a spirit of open discussion by having a review process for publication after the workshop. The program chair of TFPIE 2014 will screen submissions to ensure that all presentations are within scope and are of interest to participants. Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 16 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website/wiki. Visitors to the TFPIE 2014 website/wiki will be able to add comments. This includes presenters who may respond to comments and questions as well as provide pointers to improvements and follow-up work. After the workshop, presenters will be invited to submit (a revised version of) their article for review. The PC will select the best articles for publication in the journal Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles not selected for presentation and extended abstracts will not be formally reviewed by the PC. TFPIE workshops have previously been held in St Andrews, Scotland (2012) and in Provo Utah, USA (2013). ** Invited Speaker ** TFPIE is pleased to announce that professor Johan Jeuring of Utrecht University and Open University, both in The Netherlands is giving an invited talk entitled: "Automatic tutoring and assessing functional programs". ** Program Committee ** James Caldwell, (Program Chair) University of Wyoming Peter Achten, Radboud University, Nijmgen Edwin Brady, University of St Andrews, St Andrews Jurriaan Hage, Universiteit Utrecht Philip Holzenspies, University of Twente Daniel R. Licata, Wesleyan University Marco T Morazan, Seton Hall University Christian Skalka, University of Vermont David Van Horn, Northeastern University ** Submission Guidelines ** There will be two types of presentations at TFPIE 2014. Regular papers and ?best lecture? presentations. The best lecture talks are intended to allow for presentations or short lectures of purely pedagogical material. Papers and abstracts can be submitted via easychair at the following link: https://www.easychair.org/conferences/?conf=tfpie2014 ** Papers ** TFPIE 2014 welcomes submissions describing techniques used in the classroom, tools used in and/or developed for the classroom and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: * FP and beginning CS students * FP and Computational Thinking * FP and Artificial Intelligence * FP in Robotics * FP and Music * Advanced FP for undergraduates * FP in graduate education * Engaging students in research using FP * FP in Programming Languages * FP in the high school curriculum * FP as a stepping stone to other CS topics * FP and Philosophy ** Best Lectures ** In addition to papers, this year we are requesting ?best lecture? presentations. What?s your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. ** Important Dates ** * 1 February 2014: TFPIE submissions open on easychair. * 14 April 2014: Early registration for TFP closes * 21 April 2014: Submission deadline for draft TFPIE papers and abstracts * 27 April 2014: Notification of acceptance for presentation * 15 May 2014: Registration for TFPIE closes - as does late registration for TFP * 25 May 2014: Presentations in Soesterberg, Netherlands * 29 June 2014: Full papers for EPTCS proceedings due * 16 August 2014: Notification of acceptance for proceedings * 8 September 2014: Camera ready copy due for EPTCS Submission of an abstract implies no obligation to submit a full paper; abstracts with no corresponding full versions by the full paper deadline will be considered as withdrawn. At least one author from each accepted presentation must attend the workshop. From dagitj at gmail.com Tue Apr 1 15:37:06 2014 From: dagitj at gmail.com (Jason Dagit) Date: Tue, 1 Apr 2014 08:37:06 -0700 Subject: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond In-Reply-To: <533A426C.5070108@gmail.com> References: <533A426C.5070108@gmail.com> Message-ID: On Mon, Mar 31, 2014 at 9:37 PM, Gershom Bazerman wrote: > There's been lots of exciting work going into the forthcoming GHC 7.8.1 > release. But even with all these new features, our language is far from > complete and I wouldn't want the GHC team to rest on their laurels. > Especially with so much renewed community involvement in GHC development, > it seems appropriate to share some ideas some of us have been discussing > for future releases, and take a poll of community consensus regarding which > ones people might be excited to jump in and help out with, or might find > particularly helpful. > Thanks Gershom! I was going to wait till things were more mature before announcing them, but given the enthusiasm generated by your post I think I'll share what we've been working on early. Given the importance of BigData in today's business world and the complexities of writing software to support it, we have started working on an extension to Haskell to make BigData the language of choice for BigData applications. The first hurdle we face is how to represent BigData. Previously, we could work with the data but not give it a consistent or unified type. The data was simply too large! To make the representation as natural and manageable as possible we have introduced -XBigTypes. Note: For technical reasons this also implies -XImpredicativeTypes and allows construction of infinite types. With these sorts of restrictions lifted we are able to construct much larger types than before such as the type of all types and the type a such that `a = [a]`. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgaebel at uwaterloo.ca Tue Apr 1 15:40:37 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Tue, 1 Apr 2014 11:40:37 -0400 Subject: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond In-Reply-To: References: <533A426C.5070108@gmail.com> Message-ID: It's nice how we can easily generalize BigData to InfiniteData. That's part of why I love Haskell! - Clark On Tue, Apr 1, 2014 at 11:37 AM, Jason Dagit wrote: > > > > On Mon, Mar 31, 2014 at 9:37 PM, Gershom Bazerman wrote: > >> There?s been lots of exciting work going into the forthcoming GHC 7.8.1 >> release. But even with all these new features, our language is far from >> complete and I wouldn?t want the GHC team to rest on their laurels. >> Especially with so much renewed community involvement in GHC development, >> it seems appropriate to share some ideas some of us have been discussing >> for future releases, and take a poll of community consensus regarding which >> ones people might be excited to jump in and help out with, or might find >> particularly helpful. >> > > Thanks Gershom! > > I was going to wait till things were more mature before announcing them, > but given the enthusiasm generated by your post I think I'll share what > we've been working on early. > > Given the importance of BigData in today's business world and the > complexities of writing software to support it, we have started working on > an extension to Haskell to make BigData the language of choice for BigData > applications. > > The first hurdle we face is how to represent BigData. Previously, we could > work with the data but not give it a consistent or unified type. The data > was simply too large! To make the representation as natural and manageable > as possible we have introduced -XBigTypes. > > Note: For technical reasons this also implies -XImpredicativeTypes and > allows construction of infinite types. With these sorts of restrictions > lifted we are able to construct much larger types than before such as the > type of all types and the type a such that `a = [a]`. > > Jason > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.solla at gmail.com Tue Apr 1 17:32:54 2014 From: alex.solla at gmail.com (Alexander Solla) Date: Tue, 1 Apr 2014 10:32:54 -0700 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: Message-ID: On Mon, Mar 31, 2014 at 11:54 PM, Dan Doel wrote: > In the past year or two, there have been multiple performance problems in > various areas related to the fact that lambda abstraction is not free, > though we > tend to think of it as so. A major example of this was deriving of > Functor. If we > were to derive Functor for lists, we would end up with something like: > > instance Functor [] where > fmap _ [] = [] > fmap f (x:xs) = f x : fmap (\y -> f y) xs > > This definition is O(n^2) when fully evaluated,, because it causes O(n) eta > expansions of f, so we spend time following indirections proportional to > the > depth of the element in the list. This has been fixed in 7.8, but there are > other examples. I believe lens, [1] for instance, has some stuff in it that > works very hard to avoid this sort of cost; and it's not always as easy to > avoid > as the above example. Composing with a newtype wrapper, for instance, > causes an > eta expansion that can only be seen as such at the core level. > > The obvious solution is: do eta reduction. However, this is not > operationally > sound currently. The problem is that seq is capable of telling the > difference > between the following two expressions: > > undefined > \x -> undefined x > > The former causes seq to throw an exception, while the latter is considered > defined enough to not do so. So, if we eta reduce, we can cause terminating > programs to diverge if they make use of this feature. > > Luckily, there is a solution. > > Semantically one would usually identify the above two expressions. While I > do > believe one could construct a semantics that does distinguish them, it is > not > the usual practice. This suggests that there is a way to not distinguish > them, > perhaps even including seq. After all, the specification of seq is > monotone and > continuous regardless of whether we unify ? with \x -> ? x or insert an > extra > element for the latter. > > The currently problematic case is function spaces, so I'll focus on it. How > should: > > seq : (a -> b) -> c -> c > > act? Well, other than an obvious bottom, we need to emit bottom whenever > our > given function is itself bottom at every input. This may first seem like a > problem, but it is actually quite simple. Without loss of generality, let > us > assume that we can enumerate the type a. Then, we can feed these values to > the > function, and check their results for bottom. Conal Elliot has prior art > for > this sort of thing with his unamb [2] package. For each value x :: a, > simply > compute 'f x `seq` ()' in parallel, and look for any successes. If we ever > find > one, we know the function is non-bottom, and we can return our value of c. > If we > never finish searching, then the function must be bottom, and seq should > not > terminate, so we have satisfied the specification. > Love it. I have always been a fan of "fast and loose" reasoning in Haskell. Abstracting on seq, and treating it as a bottom if it evaluates to one, fits in perfectly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Tue Apr 1 21:26:39 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 1 Apr 2014 14:26:39 -0700 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: Message-ID: Hi Edward, Yes, I'm aware of that. However, I thought Dan's proposal especially droll given that changing seq to a class-based function would be sufficient to make eta-reduction sound, given appropriate instances (or lack thereof). Meaning we could leave the rest of the proposal unevaluated (lazily!). And if somebody were to suggest that on a different day, +1 from me. John On Apr 1, 2014 10:32 AM, "Edward Kmett" wrote: > John, > > Check the date and consider the process necessary to "enumerate all > Haskell programs and check their types". > > -Edward > > > On Tue, Apr 1, 2014 at 9:17 AM, John Lato wrote: > >> I think this is a great idea and should become a top priority. I would >> probably start by switching to a type-class-based seq, after which perhaps >> the next step forward would become more clear. >> >> John L. >> On Apr 1, 2014 2:54 AM, "Dan Doel" wrote: >> >>> In the past year or two, there have been multiple performance problems >>> in >>> various areas related to the fact that lambda abstraction is not free, >>> though we >>> tend to think of it as so. A major example of this was deriving of >>> Functor. If we >>> were to derive Functor for lists, we would end up with something like: >>> >>> instance Functor [] where >>> fmap _ [] = [] >>> fmap f (x:xs) = f x : fmap (\y -> f y) xs >>> >>> This definition is O(n^2) when fully evaluated,, because it causes O(n) >>> eta >>> expansions of f, so we spend time following indirections proportional to >>> the >>> depth of the element in the list. This has been fixed in 7.8, but there >>> are >>> other examples. I believe lens, [1] for instance, has some stuff in it >>> that >>> works very hard to avoid this sort of cost; and it's not always as easy >>> to avoid >>> as the above example. Composing with a newtype wrapper, for instance, >>> causes an >>> eta expansion that can only be seen as such at the core level. >>> >>> The obvious solution is: do eta reduction. However, this is not >>> operationally >>> sound currently. The problem is that seq is capable of telling the >>> difference >>> between the following two expressions: >>> >>> undefined >>> \x -> undefined x >>> >>> The former causes seq to throw an exception, while the latter is >>> considered >>> defined enough to not do so. So, if we eta reduce, we can cause >>> terminating >>> programs to diverge if they make use of this feature. >>> >>> Luckily, there is a solution. >>> >>> Semantically one would usually identify the above two expressions. While >>> I do >>> believe one could construct a semantics that does distinguish them, it >>> is not >>> the usual practice. This suggests that there is a way to not distinguish >>> them, >>> perhaps even including seq. After all, the specification of seq is >>> monotone and >>> continuous regardless of whether we unify ? with \x -> ? x or insert an >>> extra >>> element for the latter. >>> >>> The currently problematic case is function spaces, so I'll focus on it. >>> How >>> should: >>> >>> seq : (a -> b) -> c -> c >>> >>> act? Well, other than an obvious bottom, we need to emit bottom whenever >>> our >>> given function is itself bottom at every input. This may first seem like >>> a >>> problem, but it is actually quite simple. Without loss of generality, >>> let us >>> assume that we can enumerate the type a. Then, we can feed these values >>> to the >>> function, and check their results for bottom. Conal Elliot has prior art >>> for >>> this sort of thing with his unamb [2] package. For each value x :: a, >>> simply >>> compute 'f x `seq` ()' in parallel, and look for any successes. If we >>> ever find >>> one, we know the function is non-bottom, and we can return our value of >>> c. If we >>> never finish searching, then the function must be bottom, and seq should >>> not >>> terminate, so we have satisfied the specification. >>> >>> Now, some may complain about the enumeration above. But this, too, is a >>> simple >>> matter. It is well known that Haskell programs are denumerable. So it is >>> quite >>> easy to enumerate all Haskell programs that produce a value, check >>> whether that >>> value has the type we're interested in, and compute said value. All of >>> this can >>> be done in Haskell. Thus, every Haskell type is programatically >>> enumerable in >>> Haskell, and we can use said enumeration in our implementation of seq for >>> function types. I have discussed this with Russell O'Connor [3], and he >>> assures >>> me that this argument should be sufficient even if we consider semantic >>> models >>> of Haskell that contain values not denoted by any Haskell program, so we >>> should >>> be safe there. >>> >>> The one possible caveat is that this implementation of seq is not >>> operationally >>> uniform across all types, so the current fully polymorphic type of seq >>> may not >>> make sense. But moving back to a type class based approach isn't so bad, >>> and >>> this time we will have a semantically sound backing, instead of just >>> having a >>> class with the equivalent of the current magic function in it. >>> >>> Once this machinery is in place, we can eta reduce to our hearts' >>> content, and >>> not have to worry about breaking semantics. We'd no longer put the >>> burden on >>> programmers to use potentially unsafe hacks to avoid eta expansions. I >>> apologize >>> for not sketching an implementation of the above algorithm, but I'm sure >>> it >>> should be elementary enough to make it into GHC in the next couple >>> versions. >>> Everyone learns about this type of thing in university computer science >>> programs, no? >>> >>> Thoughts? Comments? Questions? >>> >>> Cheers, >>> -- Dan >>> >>> [1] http://hackage.haskell.org/package/lens >>> [2] http://hackage.haskell.org/package/unamb >>> [3] http://r6.ca/ >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Apr 1 21:32:45 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 1 Apr 2014 17:32:45 -0400 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: Message-ID: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> Unfortunately the old class based solution also carries other baggage, like the old data type contexts being needed in the language for bang patterns. :( -Edward > On Apr 1, 2014, at 5:26 PM, John Lato wrote: > > Hi Edward, > > Yes, I'm aware of that. However, I thought Dan's proposal especially droll given that changing seq to a class-based function would be sufficient to make eta-reduction sound, given appropriate instances (or lack thereof). Meaning we could leave the rest of the proposal unevaluated (lazily!). > > And if somebody were to suggest that on a different day, +1 from me. > > John > >> On Apr 1, 2014 10:32 AM, "Edward Kmett" wrote: >> John, >> >> Check the date and consider the process necessary to "enumerate all Haskell programs and check their types". >> >> -Edward >> >> >>> On Tue, Apr 1, 2014 at 9:17 AM, John Lato wrote: >>> I think this is a great idea and should become a top priority. I would probably start by switching to a type-class-based seq, after which perhaps the next step forward would become more clear. >>> >>> John L. >>> >>>> On Apr 1, 2014 2:54 AM, "Dan Doel" wrote: >>>> In the past year or two, there have been multiple performance problems in >>>> various areas related to the fact that lambda abstraction is not free, though we >>>> tend to think of it as so. A major example of this was deriving of Functor. If we >>>> were to derive Functor for lists, we would end up with something like: >>>> >>>> instance Functor [] where >>>> fmap _ [] = [] >>>> fmap f (x:xs) = f x : fmap (\y -> f y) xs >>>> >>>> This definition is O(n^2) when fully evaluated,, because it causes O(n) eta >>>> expansions of f, so we spend time following indirections proportional to the >>>> depth of the element in the list. This has been fixed in 7.8, but there are >>>> other examples. I believe lens, [1] for instance, has some stuff in it that >>>> works very hard to avoid this sort of cost; and it's not always as easy to avoid >>>> as the above example. Composing with a newtype wrapper, for instance, causes an >>>> eta expansion that can only be seen as such at the core level. >>>> >>>> The obvious solution is: do eta reduction. However, this is not operationally >>>> sound currently. The problem is that seq is capable of telling the difference >>>> between the following two expressions: >>>> >>>> undefined >>>> \x -> undefined x >>>> >>>> The former causes seq to throw an exception, while the latter is considered >>>> defined enough to not do so. So, if we eta reduce, we can cause terminating >>>> programs to diverge if they make use of this feature. >>>> >>>> Luckily, there is a solution. >>>> >>>> Semantically one would usually identify the above two expressions. While I do >>>> believe one could construct a semantics that does distinguish them, it is not >>>> the usual practice. This suggests that there is a way to not distinguish them, >>>> perhaps even including seq. After all, the specification of seq is monotone and >>>> continuous regardless of whether we unify ? with \x -> ? x or insert an extra >>>> element for the latter. >>>> >>>> The currently problematic case is function spaces, so I'll focus on it. How >>>> should: >>>> >>>> seq : (a -> b) -> c -> c >>>> >>>> act? Well, other than an obvious bottom, we need to emit bottom whenever our >>>> given function is itself bottom at every input. This may first seem like a >>>> problem, but it is actually quite simple. Without loss of generality, let us >>>> assume that we can enumerate the type a. Then, we can feed these values to the >>>> function, and check their results for bottom. Conal Elliot has prior art for >>>> this sort of thing with his unamb [2] package. For each value x :: a, simply >>>> compute 'f x `seq` ()' in parallel, and look for any successes. If we ever find >>>> one, we know the function is non-bottom, and we can return our value of c. If we >>>> never finish searching, then the function must be bottom, and seq should not >>>> terminate, so we have satisfied the specification. >>>> >>>> Now, some may complain about the enumeration above. But this, too, is a simple >>>> matter. It is well known that Haskell programs are denumerable. So it is quite >>>> easy to enumerate all Haskell programs that produce a value, check whether that >>>> value has the type we're interested in, and compute said value. All of this can >>>> be done in Haskell. Thus, every Haskell type is programatically enumerable in >>>> Haskell, and we can use said enumeration in our implementation of seq for >>>> function types. I have discussed this with Russell O'Connor [3], and he assures >>>> me that this argument should be sufficient even if we consider semantic models >>>> of Haskell that contain values not denoted by any Haskell program, so we should >>>> be safe there. >>>> >>>> The one possible caveat is that this implementation of seq is not operationally >>>> uniform across all types, so the current fully polymorphic type of seq may not >>>> make sense. But moving back to a type class based approach isn't so bad, and >>>> this time we will have a semantically sound backing, instead of just having a >>>> class with the equivalent of the current magic function in it. >>>> >>>> Once this machinery is in place, we can eta reduce to our hearts' content, and >>>> not have to worry about breaking semantics. We'd no longer put the burden on >>>> programmers to use potentially unsafe hacks to avoid eta expansions. I apologize >>>> for not sketching an implementation of the above algorithm, but I'm sure it >>>> should be elementary enough to make it into GHC in the next couple versions. >>>> Everyone learns about this type of thing in university computer science >>>> programs, no? >>>> >>>> Thoughts? Comments? Questions? >>>> >>>> Cheers, >>>> -- Dan >>>> >>>> [1] http://hackage.haskell.org/package/lens >>>> [2] http://hackage.haskell.org/package/unamb >>>> [3] http://r6.ca/ >>>> >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users at haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Wed Apr 2 03:39:39 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 1 Apr 2014 20:39:39 -0700 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> References: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> Message-ID: I'm already uneasy using bang patterns on polymorphic data because I don't know exactly what it will accomplish. Maybe it adds too much strictness? Not enough? Simply duplicates work? Perhaps it's acceptable to remove that feature entirely (although that may require adding extra strictness in a lot of other places). Alternatively, maybe it's enough to simply find a use for that good-for-nothing syntax we already have? On Apr 1, 2014 5:32 PM, "Edward Kmett" wrote: > > Unfortunately the old class based solution also carries other baggage, like the old data type contexts being needed in the language for bang patterns. :( > > -Edward > > On Apr 1, 2014, at 5:26 PM, John Lato wrote: > >> Hi Edward, >> >> Yes, I'm aware of that. However, I thought Dan's proposal especially droll given that changing seq to a class-based function would be sufficient to make eta-reduction sound, given appropriate instances (or lack thereof). Meaning we could leave the rest of the proposal unevaluated (lazily!). >> >> And if somebody were to suggest that on a different day, +1 from me. >> >> John >> >> On Apr 1, 2014 10:32 AM, "Edward Kmett" wrote: >>> >>> John, >>> >>> Check the date and consider the process necessary to "enumerate all Haskell programs and check their types". >>> >>> -Edward >>> >>> >>> On Tue, Apr 1, 2014 at 9:17 AM, John Lato wrote: >>>> >>>> I think this is a great idea and should become a top priority. I would probably start by switching to a type-class-based seq, after which perhaps the next step forward would become more clear. >>>> >>>> John L. >>>> >>>> On Apr 1, 2014 2:54 AM, "Dan Doel" wrote: >>>>> >>>>> In the past year or two, there have been multiple performance problems in >>>>> various areas related to the fact that lambda abstraction is not free, though we >>>>> tend to think of it as so. A major example of this was deriving of Functor. If we >>>>> were to derive Functor for lists, we would end up with something like: >>>>> >>>>> instance Functor [] where >>>>> fmap _ [] = [] >>>>> fmap f (x:xs) = f x : fmap (\y -> f y) xs >>>>> >>>>> This definition is O(n^2) when fully evaluated,, because it causes O(n) eta >>>>> expansions of f, so we spend time following indirections proportional to the >>>>> depth of the element in the list. This has been fixed in 7.8, but there are >>>>> other examples. I believe lens, [1] for instance, has some stuff in it that >>>>> works very hard to avoid this sort of cost; and it's not always as easy to avoid >>>>> as the above example. Composing with a newtype wrapper, for instance, causes an >>>>> eta expansion that can only be seen as such at the core level. >>>>> >>>>> The obvious solution is: do eta reduction. However, this is not operationally >>>>> sound currently. The problem is that seq is capable of telling the difference >>>>> between the following two expressions: >>>>> >>>>> undefined >>>>> \x -> undefined x >>>>> >>>>> The former causes seq to throw an exception, while the latter is considered >>>>> defined enough to not do so. So, if we eta reduce, we can cause terminating >>>>> programs to diverge if they make use of this feature. >>>>> >>>>> Luckily, there is a solution. >>>>> >>>>> Semantically one would usually identify the above two expressions. While I do >>>>> believe one could construct a semantics that does distinguish them, it is not >>>>> the usual practice. This suggests that there is a way to not distinguish them, >>>>> perhaps even including seq. After all, the specification of seq is monotone and >>>>> continuous regardless of whether we unify ? with \x -> ? x or insert an extra >>>>> element for the latter. >>>>> >>>>> The currently problematic case is function spaces, so I'll focus on it. How >>>>> should: >>>>> >>>>> seq : (a -> b) -> c -> c >>>>> >>>>> act? Well, other than an obvious bottom, we need to emit bottom whenever our >>>>> given function is itself bottom at every input. This may first seem like a >>>>> problem, but it is actually quite simple. Without loss of generality, let us >>>>> assume that we can enumerate the type a. Then, we can feed these values to the >>>>> function, and check their results for bottom. Conal Elliot has prior art for >>>>> this sort of thing with his unamb [2] package. For each value x :: a, simply >>>>> compute 'f x `seq` ()' in parallel, and look for any successes. If we ever find >>>>> one, we know the function is non-bottom, and we can return our value of c. If we >>>>> never finish searching, then the function must be bottom, and seq should not >>>>> terminate, so we have satisfied the specification. >>>>> >>>>> Now, some may complain about the enumeration above. But this, too, is a simple >>>>> matter. It is well known that Haskell programs are denumerable. So it is quite >>>>> easy to enumerate all Haskell programs that produce a value, check whether that >>>>> value has the type we're interested in, and compute said value. All of this can >>>>> be done in Haskell. Thus, every Haskell type is programatically enumerable in >>>>> Haskell, and we can use said enumeration in our implementation of seq for >>>>> function types. I have discussed this with Russell O'Connor [3], and he assures >>>>> me that this argument should be sufficient even if we consider semantic models >>>>> of Haskell that contain values not denoted by any Haskell program, so we should >>>>> be safe there. >>>>> >>>>> The one possible caveat is that this implementation of seq is not operationally >>>>> uniform across all types, so the current fully polymorphic type of seq may not >>>>> make sense. But moving back to a type class based approach isn't so bad, and >>>>> this time we will have a semantically sound backing, instead of just having a >>>>> class with the equivalent of the current magic function in it. >>>>> >>>>> Once this machinery is in place, we can eta reduce to our hearts' content, and >>>>> not have to worry about breaking semantics. We'd no longer put the burden on >>>>> programmers to use potentially unsafe hacks to avoid eta expansions. I apologize >>>>> for not sketching an implementation of the above algorithm, but I'm sure it >>>>> should be elementary enough to make it into GHC in the next couple versions. >>>>> Everyone learns about this type of thing in university computer science >>>>> programs, no? >>>>> >>>>> Thoughts? Comments? Questions? >>>>> >>>>> Cheers, >>>>> -- Dan >>>>> >>>>> [1] http://hackage.haskell.org/package/lens >>>>> [2] http://hackage.haskell.org/package/unamb >>>>> [3] http://r6.ca/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Glasgow-haskell-users mailing list >>>>> Glasgow-haskell-users at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Apr 2 07:08:30 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 2 Apr 2014 08:08:30 +0100 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> References: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> Message-ID: <20140402070830.GA3380@weber> On Tue, Apr 01, 2014 at 05:32:45PM -0400, Edward Kmett wrote: > Unfortunately the old class based solution also carries other baggage, > like the old data type contexts being needed in the language for bang > patterns. :( Can you explain why that is so? I don't understand. Tom From ekmett at gmail.com Wed Apr 2 13:51:46 2014 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 2 Apr 2014 09:51:46 -0400 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: <20140402070830.GA3380@weber> References: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> <20140402070830.GA3380@weber> Message-ID: Consider something like data Foo a = Foo !Int !a The data constructor Foo needs to be strict in its arguments, so it'd need Seq Int and Seq a. Seq Int would be resolved by the environment, but Seq a would need to come from somewhere. data Seq a => Foo a = Foo !Int !a gives you Foo :: Seq a => Int -> a -> Foo a so it is available when evaluating the constructor. We're not storing the instance as a slot in the constructor, so this isn't. data Foo a where Foo :: Seq a => Int -> a -> Foo a or equivalently data Foo a = Seq a => Foo !Int !a This is where the data type contexts came from. They were originally motivated by the needs of the no-longer existent Seq class, and then subverted to make Complex less useful than it otherwise could be. ;) -Edward On Wed, Apr 2, 2014 at 3:08 AM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Tue, Apr 01, 2014 at 05:32:45PM -0400, Edward Kmett wrote: > > Unfortunately the old class based solution also carries other baggage, > > like the old data type contexts being needed in the language for bang > > patterns. :( > > Can you explain why that is so? I don't understand. > > Tom > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm.wallace at me.com Wed Apr 2 13:55:45 2014 From: malcolm.wallace at me.com (malcolm.wallace) Date: Wed, 02 Apr 2014 13:55:45 +0000 (GMT) Subject: [Haskell-cafe] Eta Reduction In-Reply-To: Message-ID: In early Haskell (up until 1.2 I think), your "Seq" class existed, and was called "Eval". Regards, Malcolm On 02 Apr, 2014,at 01:52 PM, Edward Kmett wrote: Consider something like? data Foo a = Foo !Int !a The data constructor Foo needs to be strict in its arguments, so it'd need Seq Int and Seq a.?Seq Int would be resolved by the environment, but Seq a?would need to come from somewhere. data Seq a => Foo a = Foo !Int !a gives you Foo :: Seq a => Int -> a -> Foo a so it is available when evaluating the constructor. We're not storing the instance as a slot in the constructor, so this isn't. data Foo a where ? ?Foo :: Seq a => Int -> a -> Foo a or equivalently data Foo a = Seq a => Foo !Int !a This is where the data type contexts came from. They were originally motivated by the needs of the no-longer existent Seq class, and then subverted to make Complex less useful than it otherwise could be. ;) -Edward On Wed, Apr 2, 2014 at 3:08 AM, Tom Ellis wrote: On Tue, Apr 01, 2014 at 05:32:45PM -0400, Edward Kmett wrote: > Unfortunately the old class based solution also carries other baggage, > like the old data type contexts being needed in the language for bang > patterns. ?:( Can you explain why that is so? ?I don't understand. Tom _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Apr 2 14:15:03 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 2 Apr 2014 15:15:03 +0100 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> <20140402070830.GA3380@weber> Message-ID: <20140402141503.GI3380@weber> On Wed, Apr 02, 2014 at 09:51:46AM -0400, Edward Kmett wrote: > Consider something like > > data Foo a = Foo !Int !a > > The data constructor Foo needs to be strict in its arguments, so it'd need Seq > Int and Seq a. Seq Int would be resolved by the environment, but Seq a would > need to come from somewhere. > > data Seq a => Foo a = Foo !Int !a Oh right, I didn't realise that's what you meant by "patterns". I assumed you were talking about let or function definitions. > On Wed, Apr 2, 2014 at 3:08 AM, Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > > On Tue, Apr 01, 2014 at 05:32:45PM -0400, Edward Kmett wrote: > > > Unfortunately the old class based solution also carries other baggage, > > > like the old data type contexts being needed in the language for bang > > > patterns. :( > > > > Can you explain why that is so? I don't understand. From dan.doel at gmail.com Wed Apr 2 15:56:40 2014 From: dan.doel at gmail.com (Dan Doel) Date: Wed, 2 Apr 2014 11:56:40 -0400 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> <20140402070830.GA3380@weber> Message-ID: On Wed, Apr 2, 2014 at 9:51 AM, Edward Kmett wrote: > This is where the data type contexts came from. They were originally > motivated by the needs of the no-longer existent Seq class, and then > subverted to make Complex less useful than it otherwise could be. ;) > This is wrong. Data type contexts existed in the Haskell 1.0 report, and Ratio and Complex used them there. Strict fields didn't exist until 1.3. -- Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From althainz at gmail.com Wed Apr 2 16:20:14 2014 From: althainz at gmail.com (Peter Althainz) Date: Wed, 2 Apr 2014 18:20:14 +0200 Subject: [Haskell-cafe] HGamer3D - 0.3.x - Building Fixed Message-ID: Dear All, I recognized that there were some serious bugs in build code for HGamer3D, which basically prevented building it successfully. I'm very sorry for this! As always there are some explanations how this could happen, but anyhow, I could imagine how frustrating it is to try, spend time and then: no success. This has been fixed now. The detailed build instructions on http://www.hgamer3d.org/Install.html do work, they have been tested on 4 different linux distros and Windows exactly the way described there. regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Apr 2 19:32:11 2014 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 2 Apr 2014 15:32:11 -0400 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> <20140402070830.GA3380@weber> Message-ID: I stand corrected. So they were there all along and then finally briefly had a reason to exist later on. ;) -Edward On Wed, Apr 2, 2014 at 11:56 AM, Dan Doel wrote: > On Wed, Apr 2, 2014 at 9:51 AM, Edward Kmett wrote: > >> This is where the data type contexts came from. They were originally >> motivated by the needs of the no-longer existent Seq class, and then >> subverted to make Complex less useful than it otherwise could be. ;) >> > > This is wrong. Data type contexts existed in the Haskell 1.0 report, and > Ratio and Complex used them there. Strict fields didn't exist until 1.3. > > -- Dan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at nand.wakku.to Wed Apr 2 20:32:36 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Wed, 2 Apr 2014 22:32:36 +0200 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> <20140402070830.GA3380@weber> Message-ID: <20140402223236.GA30194@nanodesu.talocan.mine.nu> On Wed, 2 Apr 2014 09:51:46 -0400, Edward Kmett wrote: > We're not storing the instance as a slot in the constructor, so this isn't. > > data Foo a where > Foo :: Seq a => Int -> a -> Foo a > > or equivalently > > data Foo a = Seq a => Foo !Int !a Why not? Say we define Seq to something like > type family Seq (a :: *) :: Constraint where > Seq (a -> b) = 1 ~ 0 > Seq t = () What would be the drawback in this scenario? From jwlato at gmail.com Wed Apr 2 21:25:55 2014 From: jwlato at gmail.com (John Lato) Date: Wed, 2 Apr 2014 14:25:55 -0700 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: <20140402223236.GA30194@nanodesu.talocan.mine.nu> References: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> <20140402070830.GA3380@weber> <20140402223236.GA30194@nanodesu.talocan.mine.nu> Message-ID: On Apr 2, 2014 4:32 PM, "Niklas Haas" wrote: > > On Wed, 2 Apr 2014 09:51:46 -0400, Edward Kmett wrote: > > We're not storing the instance as a slot in the constructor, so this isn't. > > > > data Foo a where > > Foo :: Seq a => Int -> a -> Foo a > > > > or equivalently > > > > data Foo a = Seq a => Foo !Int !a > > Why not? Say we define Seq to something like > > > type family Seq (a :: *) :: Constraint where > > Seq (a -> b) = 1 ~ 0 > > Seq t = () > > What would be the drawback in this scenario? I think that would be acceptable if we posit the existence of a valid Seq a dictionary. I think that would be possible for all builtin types and anything defined via data. But what about e.g. newtype F = F (forall x. Show x => x-> String) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjwatson at ubuntu.com Wed Apr 2 19:41:46 2014 From: cjwatson at ubuntu.com (Colin Watson) Date: Wed, 2 Apr 2014 20:41:46 +0100 Subject: [Haskell-cafe] Building GHC 7.6 with 7.8 Message-ID: <20140402194146.GS6397@riva.ucam.org> Hi, I'm trying to bootstrap GHC on a new architecture (Linux arm64/aarch64). I've been working with Karel Gardas from https://ghc.haskell.org/trac/ghc/ticket/7942, and with a few of my own na?ve modifications on top of his patch set I've been able to bootstrap my way to a complete working build of the ghc-7.8 git branch (that is, I was able to cross-build on amd64 and then do a complete native build on arm64). arm64 hardware is still pretty rare and emulation is slow, but I have access to some via work, so given help from somebody who knows GHC rather better than I do I'm in a good position to get this done. What I actually want is to see if I can get this support into Ubuntu 14.04 LTS, which is going to be released in about two weeks. I still just about have enough time to do this if I'm quick. However, we currently ship GHC 7.6.3, it's working pretty well, and I don't want to destabilise things by trying to introduce a new version of GHC even just for some architectures. Thus, I've been trying to build 7.6 using 7.8. I know this is not a supported path - it's pretty obvious from the ways it breaks that nobody has spent much time trying to make it work. It seems as though it ought to be possible in theory, though, and cross-building has improved so much in 7.8 that I really don't want to go back and try to cross-build 7.6 - I tried that before and never managed to get anywhere. I've therefore been trying to apply the obvious tweaks like adding imports and adjusting versions in .cabal files. However, I've run into a roadblock, and I hope somebody here might be able to figure out what's going on. I've attached my current work-in-progress patch set; there's some noise from autoreconf, and it also requires putting an updated libffi tarball in place. I've also attached a script(1) log of a failed build attempt. The patch is actually slightly newer than the typescript, in that I realised that the GHC_CONVERT_CPU output needed to be "aarch64" not "arm64" in order for configuring libffi to work properly; this has no material effect on the build failure, though, and I hope it doesn't cause too much confusion. This typescript is from a build of 7.6 with the cross-compiled ghc-stage2. However, I also tried the same build with the native ghc-stage2 build that I'd bootstrapped off that, and the failure looks basically the same to my eye. If anyone thinks the difference might be important then I'd be happy to prepare an updated typescript, but it takes a while. I'd appreciate any suggestions people might have. Thanks, -- Colin Watson [cjwatson at ubuntu.com] -------------- next part -------------- A non-text attachment was scrubbed... Name: ghc.wip.patch Type: text/x-diff Size: 167713 bytes Desc: not available URL: -------------- next part -------------- Script started on Fri May 8 15:52:46 2150 ]0;(t-cjwatson)cjwatson at am1: ~/ghc-7.6.3(t-cjwatson)cjwatson at am1:~/ghc-7.6.3$ debian/rules build dh_testdir dh_autoreconf rm -f mk/build.mk echo "SRC_HC_OPTS += -lffi -optl-pthread" >> mk/build.mk echo "HADDOCK_DOCS := YES" >> mk/build.mk echo "XSLTPROC_OPTS += --nonet" >> mk/build.mk # We also want to build the threaded profiling-enabled debug runtime, # because it does no harm echo 'GhcRTSWays += $(if $(findstring p, $(GhcLibWays)),thr_debug_p,)' >> mk/build.mk # We can't do this with a configure flag in 6.8.1 as libdir is not # defined at the point at which we := it echo 'ghclibdir := ${libdir}/ghc' >> mk/build.mk echo 'bindir := ${ghclibdir}/bin' >> mk/build.mk echo 'ghclibexecdir := ${ghclibdir}/lib' >> mk/build.mk # docdir doesn't have a configure flag, and unfortunately # we also need to explicitly define all of its dependents as they # are set with := echo 'docdir := $(datarootdir)/doc/ghc-doc' >> mk/build.mk echo 'htmldir := $(docdir)' >> mk/build.mk echo 'dvidir := $(docdir)' >> mk/build.mk echo 'pdfdir := $(docdir)' >> mk/build.mk echo 'psdir := $(docdir)' >> mk/build.mk # We want verbose builds echo 'V=1' >> mk/build.mk rm -f config.sub rm -f config.guess ln -s /usr/share/misc/config.sub . ln -s /usr/share/misc/config.guess . ./configure --prefix=/usr \ --with-ghc="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" \ --with-ld=ld.bfd \ --with-llc=llc \ --with-opt=opt checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking version of ghc... 7.8.0.20140331 Bootstrapping GHC is a cross compiler. This probably isn't going to work checking build system type... aarch64-unknown-linux-gnu checking host system type... aarch64-unknown-linux-gnu checking target system type... aarch64-unknown-linux-gnu HOST: aarch64-unknown-linux-gnu Build platform inferred as: arm64-unknown-linux Host platform inferred as: arm64-unknown-linux Target platform inferred as: arm64-unknown-linux GHC build : arm64-unknown-linux GHC host : arm64-unknown-linux GHC target : arm64-unknown-linux configure: Building in-tree ghc-pwd checking for path to top of build tree... /home/cjwatson/ghc-7.6.3 checking for gcc... /usr/bin/gcc checking for nm... /usr/bin/nm checking whether #! works in shell scripts... yes checking for perl... /usr/bin/perl checking if your perl works in shell scripts... yes checking for python... /usr/bin/python checking for gcc... /usr/bin/gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc accepts -g... yes checking for /usr/bin/gcc option to accept ISO C89... none needed checking version of gcc... 4.8.2 checking whether C compiler has an LLVM back end... no checking whether ld understands --hash-size=31... --hash-size=31 checking whether ld understands --reduce-memory-overheads... --reduce-memory-overheads checking Setting up CFLAGS, LDFLAGS, IGNORE_LINKER_LD_FLAGS and CPPFLAGS... done checking Setting up CONF_CC_OPTS_STAGE0, CONF_GCC_LINKER_OPTS_STAGE0, CONF_LD_LINKER_OPTS_STAGE0 and CONF_CPP_OPTS_STAGE0... done checking Setting up CONF_CC_OPTS_STAGE1, CONF_GCC_LINKER_OPTS_STAGE1, CONF_LD_LINKER_OPTS_STAGE1 and CONF_CPP_OPTS_STAGE1... done checking Setting up CONF_CC_OPTS_STAGE2, CONF_GCC_LINKER_OPTS_STAGE2, CONF_LD_LINKER_OPTS_STAGE2 and CONF_CPP_OPTS_STAGE2... done checking for extra options to pass gcc when compiling via C... -fwrapv checking how to run the C preprocessor... /usr/bin/gcc -E checking for .subsections_via_symbols... no checking whether your assembler supports .ident directive... yes checking for GNU non-executable stack support... yes checking for a working context diff... diff -U 1 checking for a BSD-compatible install... /usr/bin/install -c checking for ar... /usr/bin/ar checking whether /usr/bin/ar is GNU ar... yes checking for ar arguments... q checking whether /usr/bin/ar supports @file... yes checking whether ranlib is needed... no checking whether ln -s works... yes checking for gsed... no checking for sed... /bin/sed checking for time... no checking for gnutar... no checking for gtar... no checking for tar... /bin/tar checking for gpatch... no checking for patch... /usr/bin/patch checking for dtrace... no checking for HsColour... no checking for xmllint... /usr/bin/xmllint checking for DocBook DTD... ok checking for xsltproc... /usr/bin/xsltproc checking for DocBook XSL stylesheet... yes checking for dblatex... no configure: WARNING: cannot find dblatex in your PATH, you will not be able to build the PDF and PS documentation checking for ghc-pkg matching /home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2... /home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg checking for happy... no checking for version of happy... checking for alex... no checking for version of alex... checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking bfd.h usability... yes checking bfd.h presence... yes checking for bfd.h... yes checking ctype.h usability... yes checking ctype.h presence... yes checking for ctype.h... yes checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking nlist.h usability... no checking nlist.h presence... no checking for nlist.h... no checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking sys/cpuset.h usability... no checking sys/cpuset.h presence... no checking for sys/cpuset.h... no checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/timeb.h usability... yes checking sys/timeb.h presence... yes checking for sys/timeb.h... yes checking sys/timers.h usability... no checking sys/timers.h presence... no checking for sys/timers.h... no checking sys/times.h usability... yes checking sys/times.h presence... yes checking for sys/times.h... yes checking sys/utsname.h usability... yes checking sys/utsname.h presence... yes checking for sys/utsname.h... yes checking sys/wait.h usability... yes checking sys/wait.h presence... yes checking for sys/wait.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking time.h usability... yes checking time.h presence... yes checking for time.h... yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking windows.h usability... no checking windows.h presence... no checking for windows.h... no checking winsock.h usability... no checking winsock.h presence... no checking for winsock.h... no checking sched.h usability... yes checking sched.h presence... yes checking for sched.h... yes checking whether time.h and sys/time.h may both be included... yes checking for long long... yes checking size of char... 1 checking size of double... 8 checking size of float... 4 checking size of int... 4 checking size of long... 8 checking size of long long... 8 checking size of short... 2 checking size of unsigned char... 1 checking size of unsigned int... 4 checking size of unsigned long... 8 checking size of unsigned long long... 8 checking size of unsigned short... 2 checking size of void *... 8 checking for char... yes checking alignment of char... 1 checking for double... yes checking alignment of double... 8 checking for float... yes checking alignment of float... 4 checking for int... yes checking alignment of int... 4 checking for long... yes checking alignment of long... 8 checking for long long... (cached) yes checking alignment of long long... 8 checking for short... yes checking alignment of short... 2 checking for unsigned char... yes checking alignment of unsigned char... 1 checking for unsigned int... yes checking alignment of unsigned int... 4 checking for unsigned long... yes checking alignment of unsigned long... 8 checking for unsigned long long... yes checking alignment of unsigned long long... 8 checking for unsigned short... yes checking alignment of unsigned short... 2 checking for void *... yes checking alignment of void *... 8 checking for WinExec... no checking for GetModuleFileName... no checking return type of signal handlers... void checking for getclock... no checking for getrusage... yes checking for gettimeofday... yes checking for setitimer... yes checking for siginterrupt... yes checking for sysconf... yes checking for times... yes checking for ctime_r... yes checking for sched_setaffinity... yes checking for setlocale... yes checking whether ctime_r is declared... yes checking for closedir in -lmingwex... no checking for atan in -lm... yes checking for xmalloc in -liberty... no checking for bfd_uncompress_section_contents in -lbfd... no checking for dlopen in -ldl... yes checking for size_t... yes checking for working alloca.h... yes checking for alloca... yes checking for pid_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking for an ANSI C-conforming const... yes checking whether byte ordering is bigendian... no checking whether float word order is big endian... no checking for nlist in -lelf... no checking leading underscore in symbol names... no checking whether ld understands -x... -x checking whether ld is GNU ld... yes checking whether ld understands --build-id... yes checking whether ld understands -no_compact_unwind... yes checking whether __attribute__((visibility("hidden"))) is supported... yes checking for clock_gettime in -lrt... yes checking for clock_gettime... yes checking for timer_create... yes checking for timer_settime... yes checking for a working timer_create(CLOCK_REALTIME)... yes checking for printf$LDBLStub... no checking sys/eventfd.h usability... yes checking sys/eventfd.h presence... yes checking for sys/eventfd.h... yes checking for eventfd... yes checking for pkg-config... /usr/bin/pkg-config checking for PAPI_library_init in -lpapi... no checking papi.h usability... no checking papi.h presence... no checking for papi.h... no checking for __mingw_vfprintf... no configure: creating ./config.status config.status: creating mk/config.mk config.status: creating mk/install.mk config.status: creating mk/project.mk config.status: creating compiler/ghc.cabal config.status: creating ghc/ghc-bin.cabal config.status: creating utils/runghc/runghc.cabal config.status: creating ghc.spec config.status: creating settings config.status: creating docs/users_guide/ug-book.xml config.status: creating docs/users_guide/ug-ent.xml config.status: creating docs/index.html config.status: creating libraries/prologue.txt config.status: creating distrib/ghc.iss config.status: creating distrib/configure.ac config.status: creating mk/config.h config.status: executing mk/stamp-h commands ---------------------------------------------------------------------- Configure completed successfully. Building GHC version : 7.6.3 Build platform : arm64-unknown-linux Host platform : arm64-unknown-linux Target platform : arm64-unknown-linux Bootstrapping using : /home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2 which is version : 7.8.0.20140331 Using GCC : /usr/bin/gcc which is version : 4.8.2 Building a cross compiler : NO Porting to foreign arch : NO Alien script : ld : ld.bfd Happy : () Alex : () Python : /usr/bin/python Perl : /usr/bin/perl dblatex : xsltproc : /usr/bin/xsltproc HsColour was not found; documentation will not contain source links Building DocBook HTML documentation : YES Building DocBook PS documentation : NO Building DocBook PDF documentation : NO ---------------------------------------------------------------------- For a standard build of GHC (fully optimised with profiling), type (g)make. To make changes to the default build configuration, copy the file mk/build.mk.sample to mk/build.mk, and edit the settings in there. For more information on how to configure your GHC build, see http://hackage.haskell.org/trac/ghc/wiki/Building touch configure-stamp dh_testdir /usr/bin/make make[1]: Entering directory `/home/cjwatson/ghc-7.6.3' + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old touch -r mk/config.mk.old mk/config.mk + test -f mk/project.mk.old + cp -p mk/project.mk mk/project.mk.old touch -r mk/project.mk.old mk/project.mk + test -f compiler/ghc.cabal.old + cp -p compiler/ghc.cabal compiler/ghc.cabal.old touch -r compiler/ghc.cabal.old compiler/ghc.cabal ===--- building phase 0 /usr/bin/make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/package-data.mk: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist-boot/package-data.mk: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist-boot/package-data.mk: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist-boot/package-data.mk: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/package-data.mk: No such file or directory compiler/ghc.mk:450: compiler/stage1/package-data.mk: No such file or directory utils/hsc2hs/ghc.mk:14: utils/hsc2hs/dist/package-data.mk: No such file or directory ghc/ghc.mk:106: ghc/stage1/package-data.mk: No such file or directory mkdir inplace mkdir inplace/bin mkdir inplace/lib "rm" -f inplace/bin/mkdirhier echo '#!/bin/sh' >> inplace/bin/mkdirhier cat utils/mkdirhier/mkdirhier.sh >> inplace/bin/mkdirhier chmod +x inplace/bin/mkdirhier "inplace/bin/mkdirhier" utils/ghc-cabal/dist/build/tmp//. "inplace/bin/mkdirhier" bootstrapping/. "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal \ -no-user-package-db \ -Wall \ -DCABAL_VERSION=1,16,0 \ -odir bootstrapping \ -hidir bootstrapping \ -ilibraries/Cabal/Cabal \ -ilibraries/filepath \ -ilibraries/hpc \ [ 1 of 68] Compiling System.FilePath.Posix ( libraries/filepath/System/FilePath/Posix.hs, bootstrapping/System/FilePath/Posix.o ) [ 2 of 68] Compiling System.FilePath.Windows ( libraries/filepath/System/FilePath/Windows.hs, bootstrapping/System/FilePath/Windows.o ) [ 3 of 68] Compiling Distribution.Compat.Exception ( libraries/Cabal/Cabal/Distribution/Compat/Exception.hs, bootstrapping/Distribution/Compat/Exception.o ) [ 4 of 68] Compiling Distribution.Compat.ReadP ( libraries/Cabal/Cabal/Distribution/Compat/ReadP.hs, bootstrapping/Distribution/Compat/ReadP.o ) libraries/Cabal/Cabal/Distribution/Compat/ReadP.hs:91:10: Warning: `P' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. libraries/Cabal/Cabal/Distribution/Compat/ReadP.hs:102:10: Warning: `P' is an instance of MonadPlus but not Alternative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. libraries/Cabal/Cabal/Distribution/Compat/ReadP.hs:142:10: Warning: `Parser' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. [ 5 of 68] Compiling Distribution.ReadE ( libraries/Cabal/Cabal/Distribution/ReadE.hs, bootstrapping/Distribution/ReadE.o ) [ 6 of 68] Compiling Distribution.Simple.PreProcess.Unlit ( libraries/Cabal/Cabal/Distribution/Simple/PreProcess/Unlit.hs, bootstrapping/Distribution/Simple/PreProcess/Unlit.o ) [ 7 of 68] Compiling Distribution.TestSuite ( libraries/Cabal/Cabal/Distribution/TestSuite.hs, bootstrapping/Distribution/TestSuite.o ) [ 8 of 68] Compiling Distribution.GetOpt ( libraries/Cabal/Cabal/Distribution/GetOpt.hs, bootstrapping/Distribution/GetOpt.o ) [ 9 of 68] Compiling System.FilePath ( libraries/filepath/System/FilePath.hs, bootstrapping/System/FilePath.o ) [10 of 68] Compiling Distribution.Compat.TempFile ( libraries/Cabal/Cabal/Distribution/Compat/TempFile.hs, bootstrapping/Distribution/Compat/TempFile.o ) [11 of 68] Compiling Distribution.Compat.CopyFile ( libraries/Cabal/Cabal/Distribution/Compat/CopyFile.hs, bootstrapping/Distribution/Compat/CopyFile.o ) [12 of 68] Compiling Distribution.Verbosity ( libraries/Cabal/Cabal/Distribution/Verbosity.hs, bootstrapping/Distribution/Verbosity.o ) [13 of 68] Compiling Distribution.Text ( libraries/Cabal/Cabal/Distribution/Text.hs, bootstrapping/Distribution/Text.o ) [14 of 68] Compiling Language.Haskell.Extension ( libraries/Cabal/Cabal/Language/Haskell/Extension.hs, bootstrapping/Language/Haskell/Extension.o ) [15 of 68] Compiling Distribution.Version ( libraries/Cabal/Cabal/Distribution/Version.hs, bootstrapping/Distribution/Version.o ) [16 of 68] Compiling Distribution.System ( libraries/Cabal/Cabal/Distribution/System.hs, bootstrapping/Distribution/System.o ) [17 of 68] Compiling Distribution.Package ( libraries/Cabal/Cabal/Distribution/Package.hs, bootstrapping/Distribution/Package.o ) [18 of 68] Compiling Distribution.License ( libraries/Cabal/Cabal/Distribution/License.hs, bootstrapping/Distribution/License.o ) [19 of 68] Compiling Distribution.Compiler ( libraries/Cabal/Cabal/Distribution/Compiler.hs, bootstrapping/Distribution/Compiler.o ) [20 of 68] Compiling Distribution.Simple.InstallDirs ( libraries/Cabal/Cabal/Distribution/Simple/InstallDirs.hs, bootstrapping/Distribution/Simple/InstallDirs.o ) [21 of 68] Compiling Distribution.Simple.Compiler ( libraries/Cabal/Cabal/Distribution/Simple/Compiler.hs, bootstrapping/Distribution/Simple/Compiler.o ) [22 of 68] Compiling Distribution.ModuleName ( libraries/Cabal/Cabal/Distribution/ModuleName.hs, bootstrapping/Distribution/ModuleName.o ) [23 of 68] Compiling Distribution.PackageDescription ( libraries/Cabal/Cabal/Distribution/PackageDescription.hs, bootstrapping/Distribution/PackageDescription.o ) [24 of 68] Compiling Distribution.Simple.Utils ( libraries/Cabal/Cabal/Distribution/Simple/Utils.hs, bootstrapping/Distribution/Simple/Utils.o ) libraries/Cabal/Cabal/Distribution/Simple/Utils.hs:156:1: Warning: Module `System.Cmd' is deprecated: Use "System.Process" instead [25 of 68] Compiling Distribution.PackageDescription.Configuration ( libraries/Cabal/Cabal/Distribution/PackageDescription/Configuration.hs, bootstrapping/Distribution/PackageDescription/Configuration.o ) [26 of 68] Compiling Distribution.PackageDescription.Check ( libraries/Cabal/Cabal/Distribution/PackageDescription/Check.hs, bootstrapping/Distribution/PackageDescription/Check.o ) [27 of 68] Compiling Distribution.Simple.Program.Types ( libraries/Cabal/Cabal/Distribution/Simple/Program/Types.hs, bootstrapping/Distribution/Simple/Program/Types.o ) [28 of 68] Compiling Distribution.Simple.Program.Run ( libraries/Cabal/Cabal/Distribution/Simple/Program/Run.hs, bootstrapping/Distribution/Simple/Program/Run.o ) [29 of 68] Compiling Distribution.Simple.Program.Script ( libraries/Cabal/Cabal/Distribution/Simple/Program/Script.hs, bootstrapping/Distribution/Simple/Program/Script.o ) [30 of 68] Compiling Distribution.Simple.Program.Ld ( libraries/Cabal/Cabal/Distribution/Simple/Program/Ld.hs, bootstrapping/Distribution/Simple/Program/Ld.o ) [31 of 68] Compiling Distribution.Simple.Program.Ar ( libraries/Cabal/Cabal/Distribution/Simple/Program/Ar.hs, bootstrapping/Distribution/Simple/Program/Ar.o ) [32 of 68] Compiling Distribution.Simple.Program.Builtin ( libraries/Cabal/Cabal/Distribution/Simple/Program/Builtin.hs, bootstrapping/Distribution/Simple/Program/Builtin.o ) [33 of 68] Compiling Distribution.Simple.Program.Db ( libraries/Cabal/Cabal/Distribution/Simple/Program/Db.hs, bootstrapping/Distribution/Simple/Program/Db.o ) [34 of 68] Compiling Distribution.Simple.Program ( libraries/Cabal/Cabal/Distribution/Simple/Program.hs, bootstrapping/Distribution/Simple/Program.o ) [35 of 68] Compiling Distribution.Simple.Program.Hpc ( libraries/Cabal/Cabal/Distribution/Simple/Program/Hpc.hs, bootstrapping/Distribution/Simple/Program/Hpc.o ) [36 of 68] Compiling Distribution.ParseUtils ( libraries/Cabal/Cabal/Distribution/ParseUtils.hs, bootstrapping/Distribution/ParseUtils.o ) libraries/Cabal/Cabal/Distribution/ParseUtils.hs:117:10: Warning: `ParseResult' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. [37 of 68] Compiling Distribution.PackageDescription.Parse ( libraries/Cabal/Cabal/Distribution/PackageDescription/Parse.hs, bootstrapping/Distribution/PackageDescription/Parse.o ) libraries/Cabal/Cabal/Distribution/PackageDescription/Parse.hs:598:10: Warning: `StT' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. [38 of 68] Compiling Distribution.InstalledPackageInfo ( libraries/Cabal/Cabal/Distribution/InstalledPackageInfo.hs, bootstrapping/Distribution/InstalledPackageInfo.o ) [39 of 68] Compiling Distribution.Simple.Program.HcPkg ( libraries/Cabal/Cabal/Distribution/Simple/Program/HcPkg.hs, bootstrapping/Distribution/Simple/Program/HcPkg.o ) [40 of 68] Compiling Distribution.Simple.PackageIndex ( libraries/Cabal/Cabal/Distribution/Simple/PackageIndex.hs, bootstrapping/Distribution/Simple/PackageIndex.o ) [41 of 68] Compiling Distribution.Simple.GHC.IPI642 ( libraries/Cabal/Cabal/Distribution/Simple/GHC/IPI642.hs, bootstrapping/Distribution/Simple/GHC/IPI642.o ) [42 of 68] Compiling Distribution.Simple.GHC.IPI641 ( libraries/Cabal/Cabal/Distribution/Simple/GHC/IPI641.hs, bootstrapping/Distribution/Simple/GHC/IPI641.o ) [43 of 68] Compiling Distribution.Simple.Command ( libraries/Cabal/Cabal/Distribution/Simple/Command.hs, bootstrapping/Distribution/Simple/Command.o ) [44 of 68] Compiling Distribution.Simple.Setup ( libraries/Cabal/Cabal/Distribution/Simple/Setup.hs, bootstrapping/Distribution/Simple/Setup.o ) [45 of 68] Compiling Distribution.Simple.LocalBuildInfo ( libraries/Cabal/Cabal/Distribution/Simple/LocalBuildInfo.hs, bootstrapping/Distribution/Simple/LocalBuildInfo.o ) [46 of 68] Compiling Distribution.Simple.Hpc ( libraries/Cabal/Cabal/Distribution/Simple/Hpc.hs, bootstrapping/Distribution/Simple/Hpc.o ) [47 of 68] Compiling Distribution.Simple.Build.Macros ( libraries/Cabal/Cabal/Distribution/Simple/Build/Macros.hs, bootstrapping/Distribution/Simple/Build/Macros.o ) [48 of 68] Compiling Distribution.Simple.Program.GHC ( libraries/Cabal/Cabal/Distribution/Simple/Program/GHC.hs, bootstrapping/Distribution/Simple/Program/GHC.o ) [49 of 68] Compiling Distribution.Simple.BuildPaths ( libraries/Cabal/Cabal/Distribution/Simple/BuildPaths.hs, bootstrapping/Distribution/Simple/BuildPaths.o ) [50 of 68] Compiling Distribution.Simple.UHC ( libraries/Cabal/Cabal/Distribution/Simple/UHC.hs, bootstrapping/Distribution/Simple/UHC.o ) [51 of 68] Compiling Distribution.Simple.NHC ( libraries/Cabal/Cabal/Distribution/Simple/NHC.hs, bootstrapping/Distribution/Simple/NHC.o ) [52 of 68] Compiling Distribution.Simple.LHC ( libraries/Cabal/Cabal/Distribution/Simple/LHC.hs, bootstrapping/Distribution/Simple/LHC.o ) [53 of 68] Compiling Distribution.Simple.JHC ( libraries/Cabal/Cabal/Distribution/Simple/JHC.hs, bootstrapping/Distribution/Simple/JHC.o ) [54 of 68] Compiling Distribution.Simple.GHC ( libraries/Cabal/Cabal/Distribution/Simple/GHC.hs, bootstrapping/Distribution/Simple/GHC.o ) [55 of 68] Compiling Distribution.Simple.Build.PathsModule ( libraries/Cabal/Cabal/Distribution/Simple/Build/PathsModule.hs, bootstrapping/Distribution/Simple/Build/PathsModule.o ) libraries/Cabal/Cabal/Distribution/Simple/Build/PathsModule.hs:210:19: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: PPC PPC64 Sparc Arm ... [56 of 68] Compiling Distribution.Simple.Test ( libraries/Cabal/Cabal/Distribution/Simple/Test.hs, bootstrapping/Distribution/Simple/Test.o ) [57 of 68] Compiling Distribution.Simple.PreProcess ( libraries/Cabal/Cabal/Distribution/Simple/PreProcess.hs, bootstrapping/Distribution/Simple/PreProcess.o ) [58 of 68] Compiling Distribution.Simple.UserHooks ( libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs, bootstrapping/Distribution/Simple/UserHooks.o ) [59 of 68] Compiling Distribution.Simple.SrcDist ( libraries/Cabal/Cabal/Distribution/Simple/SrcDist.hs, bootstrapping/Distribution/Simple/SrcDist.o ) [60 of 68] Compiling Distribution.Simple.Hugs ( libraries/Cabal/Cabal/Distribution/Simple/Hugs.hs, bootstrapping/Distribution/Simple/Hugs.o ) [61 of 68] Compiling Distribution.Simple.Configure ( libraries/Cabal/Cabal/Distribution/Simple/Configure.hs, bootstrapping/Distribution/Simple/Configure.o ) [62 of 68] Compiling Distribution.Simple.Register ( libraries/Cabal/Cabal/Distribution/Simple/Register.hs, bootstrapping/Distribution/Simple/Register.o ) [63 of 68] Compiling Distribution.Simple.Build ( libraries/Cabal/Cabal/Distribution/Simple/Build.hs, bootstrapping/Distribution/Simple/Build.o ) [64 of 68] Compiling Distribution.Simple.Install ( libraries/Cabal/Cabal/Distribution/Simple/Install.hs, bootstrapping/Distribution/Simple/Install.o ) [65 of 68] Compiling Distribution.Simple.Haddock ( libraries/Cabal/Cabal/Distribution/Simple/Haddock.hs, bootstrapping/Distribution/Simple/Haddock.o ) [66 of 68] Compiling Distribution.Simple.Bench ( libraries/Cabal/Cabal/Distribution/Simple/Bench.hs, bootstrapping/Distribution/Simple/Bench.o ) [67 of 68] Compiling Distribution.Simple ( libraries/Cabal/Cabal/Distribution/Simple.hs, bootstrapping/Distribution/Simple.o ) [68 of 68] Compiling Main ( utils/ghc-cabal/Main.hs, bootstrapping/Main.o ) Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal ... "touch" utils/ghc-cabal/dist/build/tmp/ghc-cabal "cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal inplace/bin/ghc-cabal "inplace/bin/mkdirhier" compiler/stage1/build//. "rm" -f compiler/stage1/build/Config.hs Creating compiler/stage1/build/Config.hs ... done. "rm" -f utils/ghc-pkg/Version.hs echo "module Version where" >> utils/ghc-pkg/Version.hs echo "version, targetOS, targetARCH :: String" >> utils/ghc-pkg/Version.hs echo "version = \"7.6.3\"" >> utils/ghc-pkg/Version.hs echo "targetOS = \"linux\"" >> utils/ghc-pkg/Version.hs echo "targetARCH = \"arm64\"" >> utils/ghc-pkg/Version.hs "inplace/bin/mkdirhier" utils/ghc-pkg/dist/build/tmp//. "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread --make utils/ghc-pkg/Main.hs -o utils/ghc-pkg/dist/build/tmp/ghc-pkg \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \ \ -DCABAL_VERSION=1,16,0 \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ -iutils/ghc-pkg \ -XCPP -XExistentialQuantification -XDeriveDataTypeable \ -ilibraries/Cabal/Cabal \ -ilibraries/filepath \ -ilibraries/hpc \ -ilibraries/binary/src \ -ilibraries/bin-package-db [ 1 of 27] Compiling Distribution.Compat.Exception ( libraries/Cabal/Cabal/Distribution/Compat/Exception.hs, bootstrapping/Distribution/Compat/Exception.o ) [flags changed] [ 2 of 27] Compiling System.FilePath.Posix ( libraries/filepath/System/FilePath/Posix.hs, bootstrapping/System/FilePath/Posix.o ) [flags changed] [ 3 of 27] Compiling System.FilePath ( libraries/filepath/System/FilePath.hs, bootstrapping/System/FilePath.o ) [flags changed] [ 4 of 27] Compiling Distribution.Compat.TempFile ( libraries/Cabal/Cabal/Distribution/Compat/TempFile.hs, bootstrapping/Distribution/Compat/TempFile.o ) [flags changed] [ 5 of 27] Compiling Distribution.Compat.CopyFile ( libraries/Cabal/Cabal/Distribution/Compat/CopyFile.hs, bootstrapping/Distribution/Compat/CopyFile.o ) [flags changed] [ 6 of 27] Compiling Distribution.Compat.ReadP ( libraries/Cabal/Cabal/Distribution/Compat/ReadP.hs, bootstrapping/Distribution/Compat/ReadP.o ) [flags changed] libraries/Cabal/Cabal/Distribution/Compat/ReadP.hs:91:10: Warning: `P' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. libraries/Cabal/Cabal/Distribution/Compat/ReadP.hs:102:10: Warning: `P' is an instance of MonadPlus but not Alternative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. libraries/Cabal/Cabal/Distribution/Compat/ReadP.hs:142:10: Warning: `Parser' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. [ 7 of 27] Compiling Distribution.Text ( libraries/Cabal/Cabal/Distribution/Text.hs, bootstrapping/Distribution/Text.o ) [flags changed] [ 8 of 27] Compiling Distribution.Version ( libraries/Cabal/Cabal/Distribution/Version.hs, bootstrapping/Distribution/Version.o ) [flags changed] [ 9 of 27] Compiling Distribution.Package ( libraries/Cabal/Cabal/Distribution/Package.hs, bootstrapping/Distribution/Package.o ) [flags changed] [10 of 27] Compiling Language.Haskell.Extension ( libraries/Cabal/Cabal/Language/Haskell/Extension.hs, bootstrapping/Language/Haskell/Extension.o ) [flags changed] [11 of 27] Compiling Distribution.ReadE ( libraries/Cabal/Cabal/Distribution/ReadE.hs, bootstrapping/Distribution/ReadE.o ) [flags changed] [12 of 27] Compiling Distribution.Verbosity ( libraries/Cabal/Cabal/Distribution/Verbosity.hs, bootstrapping/Distribution/Verbosity.o ) [flags changed] [13 of 27] Compiling Distribution.License ( libraries/Cabal/Cabal/Distribution/License.hs, bootstrapping/Distribution/License.o ) [flags changed] [14 of 27] Compiling Distribution.Compiler ( libraries/Cabal/Cabal/Distribution/Compiler.hs, bootstrapping/Distribution/Compiler.o ) [flags changed] [15 of 27] Compiling Distribution.ModuleName ( libraries/Cabal/Cabal/Distribution/ModuleName.hs, bootstrapping/Distribution/ModuleName.o ) [flags changed] [16 of 27] Compiling Distribution.Simple.Utils ( libraries/Cabal/Cabal/Distribution/Simple/Utils.hs, bootstrapping/Distribution/Simple/Utils.o ) [flags changed] [17 of 27] Compiling Distribution.ParseUtils ( libraries/Cabal/Cabal/Distribution/ParseUtils.hs, bootstrapping/Distribution/ParseUtils.o ) [flags changed] libraries/Cabal/Cabal/Distribution/ParseUtils.hs:117:10: Warning: `ParseResult' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. [18 of 27] Compiling Distribution.InstalledPackageInfo ( libraries/Cabal/Cabal/Distribution/InstalledPackageInfo.hs, bootstrapping/Distribution/InstalledPackageInfo.o ) [flags changed] [19 of 27] Compiling Distribution.Simple.PackageIndex ( libraries/Cabal/Cabal/Distribution/Simple/PackageIndex.hs, bootstrapping/Distribution/Simple/PackageIndex.o ) [flags changed] [20 of 27] Compiling Data.Binary.Builder.Base ( libraries/binary/src/Data/Binary/Builder/Base.hs, bootstrapping/Data/Binary/Builder/Base.o ) [21 of 27] Compiling Data.Binary.Builder ( libraries/binary/src/Data/Binary/Builder.hs, bootstrapping/Data/Binary/Builder.o ) [22 of 27] Compiling Data.Binary.Put ( libraries/binary/src/Data/Binary/Put.hs, bootstrapping/Data/Binary/Put.o ) libraries/binary/src/Data/Binary/Put.hs:97:10: Warning: `PutM' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. [23 of 27] Compiling Data.Binary.Get ( libraries/binary/src/Data/Binary/Get.hs, bootstrapping/Data/Binary/Get.o ) libraries/binary/src/Data/Binary/Get.hs:126:10: Warning: `Get' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. libraries/binary/src/Data/Binary/Get.hs:345:1: Warning: Local definition of `join' clashes with a future Prelude name - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. [24 of 27] Compiling Data.Binary ( libraries/binary/src/Data/Binary.hs, bootstrapping/Data/Binary.o ) [25 of 27] Compiling Distribution.InstalledPackageInfo.Binary ( libraries/bin-package-db/Distribution/InstalledPackageInfo/Binary.hs, bootstrapping/Distribution/InstalledPackageInfo/Binary.o ) [26 of 27] Compiling Version ( utils/ghc-pkg/Version.hs, bootstrapping/Version.o ) [27 of 27] Compiling Main ( utils/ghc-pkg/Main.hs, bootstrapping/Main.o ) [flags changed] utils/ghc-pkg/Main.hs:1298:10: Warning: `Validate' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. utils/ghc-pkg/Main.hs:1422:1: Warning: Defined but not used: `checkFile' utils/ghc-pkg/Main.hs:1423:1: Warning: Defined but not used: `checkDirURL' Linking utils/ghc-pkg/dist/build/tmp/ghc-pkg ... "inplace/bin/mkdirhier" inplace/lib/package.conf.d/. "rm" -f inplace/bin/ghc-pkg echo "#!/bin/sh" >>inplace/bin/ghc-pkg echo "PKGCONF=/home/cjwatson/ghc-7.6.3/inplace/lib/package.conf.d" >>inplace/bin/ghc-pkg echo '/home/cjwatson/ghc-7.6.3/utils/ghc-pkg/dist/build/tmp/ghc-pkg --global-package-db $PKGCONF ${1+"$@"}' >> inplace/bin/ghc-pkg chmod +x inplace/bin/ghc-pkg CROSS_COMPILE="" "inplace/bin/ghc-cabal" configure --with-ghc="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" --with-ghc-pkg="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" --package-db=/home/cjwatson/ghc-7.6.3/libraries/bootstrapping.conf --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --constraint "Cabal == 1.16.0" --constraint "hpc == 0.6.0.0" --constraint "binary == 0.5.1.1" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.9.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" -- dist-boot libraries/Cabal/Cabal Configuring Cabal-1.16.0... "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" update --force --package-db=libraries/bootstrapping.conf libraries/Cabal/Cabal/dist-boot/inplace-pkg-config Reading package info from "libraries/Cabal/Cabal/dist-boot/inplace-pkg-config" ... done. Cabal-1.16.0: Warning: haddock-interfaces: /home/cjwatson/ghc-7.6.3/libraries/Cabal/Cabal/dist-boot/doc/html/Cabal/Cabal.haddock doesn't exist or isn't a file Cabal-1.16.0: cannot find any of ["Distribution/Compiler.hi","Distribution/Compiler.p_hi","Distribution/Compiler.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/InstalledPackageInfo.hi","Distribution/InstalledPackageInfo.p_hi","Distribution/InstalledPackageInfo.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/License.hi","Distribution/License.p_hi","Distribution/License.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Make.hi","Distribution/Make.p_hi","Distribution/Make.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/ModuleName.hi","Distribution/ModuleName.p_hi","Distribution/ModuleName.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Package.hi","Distribution/Package.p_hi","Distribution/Package.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/PackageDescription.hi","Distribution/PackageDescription.p_hi","Distribution/PackageDescription.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/PackageDescription/Configuration.hi","Distribution/PackageDescription/Configuration.p_hi","Distribution/PackageDescription/Configuration.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/PackageDescription/Parse.hi","Distribution/PackageDescription/Parse.p_hi","Distribution/PackageDescription/Parse.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/PackageDescription/Check.hi","Distribution/PackageDescription/Check.p_hi","Distribution/PackageDescription/Check.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/PackageDescription/PrettyPrint.hi","Distribution/PackageDescription/PrettyPrint.p_hi","Distribution/PackageDescription/PrettyPrint.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/ParseUtils.hi","Distribution/ParseUtils.p_hi","Distribution/ParseUtils.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/ReadE.hi","Distribution/ReadE.p_hi","Distribution/ReadE.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple.hi","Distribution/Simple.p_hi","Distribution/Simple.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Build.hi","Distribution/Simple/Build.p_hi","Distribution/Simple/Build.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Build/Macros.hi","Distribution/Simple/Build/Macros.p_hi","Distribution/Simple/Build/Macros.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Build/PathsModule.hi","Distribution/Simple/Build/PathsModule.p_hi","Distribution/Simple/Build/PathsModule.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/BuildPaths.hi","Distribution/Simple/BuildPaths.p_hi","Distribution/Simple/BuildPaths.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Bench.hi","Distribution/Simple/Bench.p_hi","Distribution/Simple/Bench.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Command.hi","Distribution/Simple/Command.p_hi","Distribution/Simple/Command.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Compiler.hi","Distribution/Simple/Compiler.p_hi","Distribution/Simple/Compiler.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Configure.hi","Distribution/Simple/Configure.p_hi","Distribution/Simple/Configure.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/GHC.hi","Distribution/Simple/GHC.p_hi","Distribution/Simple/GHC.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/LHC.hi","Distribution/Simple/LHC.p_hi","Distribution/Simple/LHC.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Haddock.hi","Distribution/Simple/Haddock.p_hi","Distribution/Simple/Haddock.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Hpc.hi","Distribution/Simple/Hpc.p_hi","Distribution/Simple/Hpc.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Hugs.hi","Distribution/Simple/Hugs.p_hi","Distribution/Simple/Hugs.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Install.hi","Distribution/Simple/Install.p_hi","Distribution/Simple/Install.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/InstallDirs.hi","Distribution/Simple/InstallDirs.p_hi","Distribution/Simple/InstallDirs.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/JHC.hi","Distribution/Simple/JHC.p_hi","Distribution/Simple/JHC.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/LocalBuildInfo.hi","Distribution/Simple/LocalBuildInfo.p_hi","Distribution/Simple/LocalBuildInfo.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/NHC.hi","Distribution/Simple/NHC.p_hi","Distribution/Simple/NHC.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/PackageIndex.hi","Distribution/Simple/PackageIndex.p_hi","Distribution/Simple/PackageIndex.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/PreProcess.hi","Distribution/Simple/PreProcess.p_hi","Distribution/Simple/PreProcess.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/PreProcess/Unlit.hi","Distribution/Simple/PreProcess/Unlit.p_hi","Distribution/Simple/PreProcess/Unlit.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Program.hi","Distribution/Simple/Program.p_hi","Distribution/Simple/Program.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Program/Ar.hi","Distribution/Simple/Program/Ar.p_hi","Distribution/Simple/Program/Ar.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Program/Builtin.hi","Distribution/Simple/Program/Builtin.p_hi","Distribution/Simple/Program/Builtin.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Program/Db.hi","Distribution/Simple/Program/Db.p_hi","Distribution/Simple/Program/Db.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Program/GHC.hi","Distribution/Simple/Program/GHC.p_hi","Distribution/Simple/Program/GHC.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Program/HcPkg.hi","Distribution/Simple/Program/HcPkg.p_hi","Distribution/Simple/Program/HcPkg.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Program/Hpc.hi","Distribution/Simple/Program/Hpc.p_hi","Distribution/Simple/Program/Hpc.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Program/Ld.hi","Distribution/Simple/Program/Ld.p_hi","Distribution/Simple/Program/Ld.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Program/Run.hi","Distribution/Simple/Program/Run.p_hi","Distribution/Simple/Program/Run.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Program/Script.hi","Distribution/Simple/Program/Script.p_hi","Distribution/Simple/Program/Script.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Program/Types.hi","Distribution/Simple/Program/Types.p_hi","Distribution/Simple/Program/Types.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Register.hi","Distribution/Simple/Register.p_hi","Distribution/Simple/Register.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Setup.hi","Distribution/Simple/Setup.p_hi","Distribution/Simple/Setup.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/SrcDist.hi","Distribution/Simple/SrcDist.p_hi","Distribution/Simple/SrcDist.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Test.hi","Distribution/Simple/Test.p_hi","Distribution/Simple/Test.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/UHC.hi","Distribution/Simple/UHC.p_hi","Distribution/Simple/UHC.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/UserHooks.hi","Distribution/Simple/UserHooks.p_hi","Distribution/Simple/UserHooks.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/Utils.hi","Distribution/Simple/Utils.p_hi","Distribution/Simple/Utils.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/System.hi","Distribution/System.p_hi","Distribution/System.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/TestSuite.hi","Distribution/TestSuite.p_hi","Distribution/TestSuite.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Text.hi","Distribution/Text.p_hi","Distribution/Text.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Verbosity.hi","Distribution/Verbosity.p_hi","Distribution/Verbosity.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Version.hi","Distribution/Version.p_hi","Distribution/Version.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Compat/ReadP.hi","Distribution/Compat/ReadP.p_hi","Distribution/Compat/ReadP.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Language/Haskell/Extension.hi","Language/Haskell/Extension.p_hi","Language/Haskell/Extension.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/GetOpt.hi","Distribution/GetOpt.p_hi","Distribution/GetOpt.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Compat/Exception.hi","Distribution/Compat/Exception.p_hi","Distribution/Compat/Exception.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Compat/CopyFile.hi","Distribution/Compat/CopyFile.p_hi","Distribution/Compat/CopyFile.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Compat/TempFile.hi","Distribution/Compat/TempFile.p_hi","Distribution/Compat/TempFile.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/GHC/IPI641.hi","Distribution/Simple/GHC/IPI641.p_hi","Distribution/Simple/GHC/IPI641.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Distribution/Simple/GHC/IPI642.hi","Distribution/Simple/GHC/IPI642.p_hi","Distribution/Simple/GHC/IPI642.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["Paths_Cabal.hi","Paths_Cabal.p_hi","Paths_Cabal.dyn_hi"] (ignoring) Cabal-1.16.0: cannot find any of ["libHSCabal-1.16.0.a","libHSCabal-1.16.0.p_a","libHSCabal-1.16.0-ghc7.8.0.20140331.so","libHSCabal-1.16.0-ghc7.8.0.20140331.dylib","HSCabal-1.16.0-ghc7.8.0.20140331.dll"] on library path (ignoring) Writing new package config file... done. CROSS_COMPILE="" "inplace/bin/ghc-cabal" configure --with-ghc="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" --with-ghc-pkg="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" --package-db=/home/cjwatson/ghc-7.6.3/libraries/bootstrapping.conf --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --constraint "Cabal == 1.16.0" --constraint "hpc == 0.6.0.0" --constraint "binary == 0.5.1.1" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.9.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" -- dist-boot libraries/hpc Configuring hpc-0.6.0.0... "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" update --force --package-db=libraries/bootstrapping.conf libraries/hpc/dist-boot/inplace-pkg-config Reading package info from "libraries/hpc/dist-boot/inplace-pkg-config" ... done. hpc-0.6.0.0: Warning: haddock-interfaces: /home/cjwatson/ghc-7.6.3/libraries/hpc/dist-boot/doc/html/hpc/hpc.haddock doesn't exist or isn't a file hpc-0.6.0.0: cannot find any of ["Trace/Hpc/Util.hi","Trace/Hpc/Util.p_hi","Trace/Hpc/Util.dyn_hi"] (ignoring) hpc-0.6.0.0: cannot find any of ["Trace/Hpc/Mix.hi","Trace/Hpc/Mix.p_hi","Trace/Hpc/Mix.dyn_hi"] (ignoring) hpc-0.6.0.0: cannot find any of ["Trace/Hpc/Tix.hi","Trace/Hpc/Tix.p_hi","Trace/Hpc/Tix.dyn_hi"] (ignoring) hpc-0.6.0.0: cannot find any of ["Trace/Hpc/Reflect.hi","Trace/Hpc/Reflect.p_hi","Trace/Hpc/Reflect.dyn_hi"] (ignoring) hpc-0.6.0.0: cannot find any of ["libHShpc-0.6.0.0.a","libHShpc-0.6.0.0.p_a","libHShpc-0.6.0.0-ghc7.8.0.20140331.so","libHShpc-0.6.0.0-ghc7.8.0.20140331.dylib","HShpc-0.6.0.0-ghc7.8.0.20140331.dll"] on library path (ignoring) Writing new package config file... done. CROSS_COMPILE="" "inplace/bin/ghc-cabal" configure --with-ghc="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" --with-ghc-pkg="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" --package-db=/home/cjwatson/ghc-7.6.3/libraries/bootstrapping.conf --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --constraint "Cabal == 1.16.0" --constraint "hpc == 0.6.0.0" --constraint "binary == 0.5.1.1" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.9.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" -- dist-boot libraries/binary Configuring binary-0.5.1.1... "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" update --force --package-db=libraries/bootstrapping.conf libraries/binary/dist-boot/inplace-pkg-config Reading package info from "libraries/binary/dist-boot/inplace-pkg-config" ... done. binary-0.5.1.1: Warning: haddock-interfaces: /home/cjwatson/ghc-7.6.3/libraries/binary/dist-boot/doc/html/binary/binary.haddock doesn't exist or isn't a file binary-0.5.1.1: cannot find any of ["Data/Binary.hi","Data/Binary.p_hi","Data/Binary.dyn_hi"] (ignoring) binary-0.5.1.1: cannot find any of ["Data/Binary/Put.hi","Data/Binary/Put.p_hi","Data/Binary/Put.dyn_hi"] (ignoring) binary-0.5.1.1: cannot find any of ["Data/Binary/Get.hi","Data/Binary/Get.p_hi","Data/Binary/Get.dyn_hi"] (ignoring) binary-0.5.1.1: cannot find any of ["Data/Binary/Builder.hi","Data/Binary/Builder.p_hi","Data/Binary/Builder.dyn_hi"] (ignoring) binary-0.5.1.1: cannot find any of ["Data/Binary/Builder/Internal.hi","Data/Binary/Builder/Internal.p_hi","Data/Binary/Builder/Internal.dyn_hi"] (ignoring) binary-0.5.1.1: cannot find any of ["Data/Binary/Builder/Base.hi","Data/Binary/Builder/Base.p_hi","Data/Binary/Builder/Base.dyn_hi"] (ignoring) binary-0.5.1.1: cannot find any of ["libHSbinary-0.5.1.1.a","libHSbinary-0.5.1.1.p_a","libHSbinary-0.5.1.1-ghc7.8.0.20140331.so","libHSbinary-0.5.1.1-ghc7.8.0.20140331.dylib","HSbinary-0.5.1.1-ghc7.8.0.20140331.dll"] on library path (ignoring) Writing new package config file... done. CROSS_COMPILE="" "inplace/bin/ghc-cabal" configure --with-ghc="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" --with-ghc-pkg="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" --package-db=/home/cjwatson/ghc-7.6.3/libraries/bootstrapping.conf --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --constraint "Cabal == 1.16.0" --constraint "hpc == 0.6.0.0" --constraint "binary == 0.5.1.1" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.9.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" -- dist-boot libraries/bin-package-db Configuring bin-package-db-0.0.0.0... "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" update --force --package-db=libraries/bootstrapping.conf libraries/bin-package-db/dist-boot/inplace-pkg-config Reading package info from "libraries/bin-package-db/dist-boot/inplace-pkg-config" ... done. bin-package-db-0.0.0.0: Warning: haddock-interfaces: /home/cjwatson/ghc-7.6.3/libraries/bin-package-db/dist-boot/doc/html/bin-package-db/bin-package-db.haddock doesn't exist or isn't a file bin-package-db-0.0.0.0: cannot find any of ["Distribution/InstalledPackageInfo/Binary.hi","Distribution/InstalledPackageInfo/Binary.p_hi","Distribution/InstalledPackageInfo/Binary.dyn_hi"] (ignoring) bin-package-db-0.0.0.0: cannot find any of ["libHSbin-package-db-0.0.0.0.a","libHSbin-package-db-0.0.0.0.p_a","libHSbin-package-db-0.0.0.0-ghc7.8.0.20140331.so","libHSbin-package-db-0.0.0.0-ghc7.8.0.20140331.dylib","HSbin-package-db-0.0.0.0-ghc7.8.0.20140331.dll"] on library path (ignoring) Writing new package config file... done. CROSS_COMPILE="" "inplace/bin/ghc-cabal" configure --with-ghc="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" --with-ghc-pkg="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" --package-db=/home/cjwatson/ghc-7.6.3/libraries/bootstrapping.conf --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --constraint "Cabal == 1.16.0" --constraint "hpc == 0.6.0.0" --constraint "binary == 0.5.1.1" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.9.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" -- dist-boot libraries/hoopl Configuring hoopl-3.9.0.0... "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" update --force --package-db=libraries/bootstrapping.conf libraries/hoopl/dist-boot/inplace-pkg-config Reading package info from "libraries/hoopl/dist-boot/inplace-pkg-config" ... done. hoopl-3.9.0.0: Warning: haddock-interfaces: /home/cjwatson/ghc-7.6.3/libraries/hoopl/dist-boot/doc/html/hoopl/hoopl.haddock doesn't exist or isn't a file hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl.hi","Compiler/Hoopl.p_hi","Compiler/Hoopl.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Internals.hi","Compiler/Hoopl/Internals.p_hi","Compiler/Hoopl/Internals.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Wrappers.hi","Compiler/Hoopl/Wrappers.p_hi","Compiler/Hoopl/Wrappers.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Passes/Dominator.hi","Compiler/Hoopl/Passes/Dominator.p_hi","Compiler/Hoopl/Passes/Dominator.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Passes/DList.hi","Compiler/Hoopl/Passes/DList.p_hi","Compiler/Hoopl/Passes/DList.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Checkpoint.hi","Compiler/Hoopl/Checkpoint.p_hi","Compiler/Hoopl/Checkpoint.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Collections.hi","Compiler/Hoopl/Collections.p_hi","Compiler/Hoopl/Collections.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Combinators.hi","Compiler/Hoopl/Combinators.p_hi","Compiler/Hoopl/Combinators.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Dataflow.hi","Compiler/Hoopl/Dataflow.p_hi","Compiler/Hoopl/Dataflow.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Debug.hi","Compiler/Hoopl/Debug.p_hi","Compiler/Hoopl/Debug.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Block.hi","Compiler/Hoopl/Block.p_hi","Compiler/Hoopl/Block.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Graph.hi","Compiler/Hoopl/Graph.p_hi","Compiler/Hoopl/Graph.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Label.hi","Compiler/Hoopl/Label.p_hi","Compiler/Hoopl/Label.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/MkGraph.hi","Compiler/Hoopl/MkGraph.p_hi","Compiler/Hoopl/MkGraph.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Fuel.hi","Compiler/Hoopl/Fuel.p_hi","Compiler/Hoopl/Fuel.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Pointed.hi","Compiler/Hoopl/Pointed.p_hi","Compiler/Hoopl/Pointed.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Shape.hi","Compiler/Hoopl/Shape.p_hi","Compiler/Hoopl/Shape.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Show.hi","Compiler/Hoopl/Show.p_hi","Compiler/Hoopl/Show.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/Unique.hi","Compiler/Hoopl/Unique.p_hi","Compiler/Hoopl/Unique.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["Compiler/Hoopl/XUtil.hi","Compiler/Hoopl/XUtil.p_hi","Compiler/Hoopl/XUtil.dyn_hi"] (ignoring) hoopl-3.9.0.0: cannot find any of ["libHShoopl-3.9.0.0.a","libHShoopl-3.9.0.0.p_a","libHShoopl-3.9.0.0-ghc7.8.0.20140331.so","libHShoopl-3.9.0.0-ghc7.8.0.20140331.dylib","HShoopl-3.9.0.0-ghc7.8.0.20140331.dll"] on library path (ignoring) Writing new package config file... done. CROSS_COMPILE="" "inplace/bin/ghc-cabal" configure --with-ghc="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" --with-ghc-pkg="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" --ghc-option=-DNO_REGS --flags=stage1 --ghc-option=-DSTAGE=1 --package-db=/home/cjwatson/ghc-7.6.3/libraries/bootstrapping.conf --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header " --constraint "Cabal == 1.16.0" --constraint "hpc == 0.6.0.0" --constraint "binary == 0.5.1.1" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.9.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" --disable-library-for-ghci -- stage1 compiler Configuring ghc-7.6.3... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package ghc-7.6.3 requires Cabal-1.16.0 package bin-package-db-0.0.0.0 requires Cabal-1.18.1.3 "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" update --force --package-db=libraries/bootstrapping.conf compiler/stage1/inplace-pkg-config Reading package info from "compiler/stage1/inplace-pkg-config" ... done. ghc-7.6.3: Warning: haddock-interfaces: /home/cjwatson/ghc-7.6.3/compiler/stage1/doc/html/ghc/ghc.haddock doesn't exist or isn't a file ghc-7.6.3: cannot find any of ["Avail.hi","Avail.p_hi","Avail.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["BasicTypes.hi","BasicTypes.p_hi","BasicTypes.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DataCon.hi","DataCon.p_hi","DataCon.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Demand.hi","Demand.p_hi","Demand.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Exception.hi","Exception.p_hi","Exception.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["GhcMonad.hi","GhcMonad.p_hi","GhcMonad.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Id.hi","Id.p_hi","Id.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["IdInfo.hi","IdInfo.p_hi","IdInfo.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Literal.hi","Literal.p_hi","Literal.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Llvm.hi","Llvm.p_hi","Llvm.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Llvm/AbsSyn.hi","Llvm/AbsSyn.p_hi","Llvm/AbsSyn.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Llvm/PpLlvm.hi","Llvm/PpLlvm.p_hi","Llvm/PpLlvm.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Llvm/Types.hi","Llvm/Types.p_hi","Llvm/Types.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["LlvmCodeGen.hi","LlvmCodeGen.p_hi","LlvmCodeGen.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["LlvmCodeGen/Base.hi","LlvmCodeGen/Base.p_hi","LlvmCodeGen/Base.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["LlvmCodeGen/CodeGen.hi","LlvmCodeGen/CodeGen.p_hi","LlvmCodeGen/CodeGen.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["LlvmCodeGen/Data.hi","LlvmCodeGen/Data.p_hi","LlvmCodeGen/Data.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["LlvmCodeGen/Ppr.hi","LlvmCodeGen/Ppr.p_hi","LlvmCodeGen/Ppr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["LlvmCodeGen/Regs.hi","LlvmCodeGen/Regs.p_hi","LlvmCodeGen/Regs.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["LlvmMangler.hi","LlvmMangler.p_hi","LlvmMangler.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["MkId.hi","MkId.p_hi","MkId.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Module.hi","Module.p_hi","Module.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Name.hi","Name.p_hi","Name.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["NameEnv.hi","NameEnv.p_hi","NameEnv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["NameSet.hi","NameSet.p_hi","NameSet.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["OccName.hi","OccName.p_hi","OccName.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RdrName.hi","RdrName.p_hi","RdrName.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SrcLoc.hi","SrcLoc.p_hi","SrcLoc.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["UniqSupply.hi","UniqSupply.p_hi","UniqSupply.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Unique.hi","Unique.p_hi","Unique.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Var.hi","Var.p_hi","Var.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["VarEnv.hi","VarEnv.p_hi","VarEnv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["VarSet.hi","VarSet.p_hi","VarSet.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["BlockId.hi","BlockId.p_hi","BlockId.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CLabel.hi","CLabel.p_hi","CLabel.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Cmm.hi","Cmm.p_hi","Cmm.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmBuildInfoTables.hi","CmmBuildInfoTables.p_hi","CmmBuildInfoTables.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmPipeline.hi","CmmPipeline.p_hi","CmmPipeline.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmCallConv.hi","CmmCallConv.p_hi","CmmCallConv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmCommonBlockElim.hi","CmmCommonBlockElim.p_hi","CmmCommonBlockElim.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmContFlowOpt.hi","CmmContFlowOpt.p_hi","CmmContFlowOpt.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmCvt.hi","CmmCvt.p_hi","CmmCvt.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmExpr.hi","CmmExpr.p_hi","CmmExpr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmInfo.hi","CmmInfo.p_hi","CmmInfo.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmLex.hi","CmmLex.p_hi","CmmLex.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmLint.hi","CmmLint.p_hi","CmmLint.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmLive.hi","CmmLive.p_hi","CmmLive.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmMachOp.hi","CmmMachOp.p_hi","CmmMachOp.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmNode.hi","CmmNode.p_hi","CmmNode.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmOpt.hi","CmmOpt.p_hi","CmmOpt.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmParse.hi","CmmParse.p_hi","CmmParse.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmProcPoint.hi","CmmProcPoint.p_hi","CmmProcPoint.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmRewriteAssignments.hi","CmmRewriteAssignments.p_hi","CmmRewriteAssignments.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmSink.hi","CmmSink.p_hi","CmmSink.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmType.hi","CmmType.p_hi","CmmType.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmUtils.hi","CmmUtils.p_hi","CmmUtils.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmmLayoutStack.hi","CmmLayoutStack.p_hi","CmmLayoutStack.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["MkGraph.hi","MkGraph.p_hi","MkGraph.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["OldCmm.hi","OldCmm.p_hi","OldCmm.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["OldCmmLint.hi","OldCmmLint.p_hi","OldCmmLint.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["OldCmmUtils.hi","OldCmmUtils.p_hi","OldCmmUtils.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["OldPprCmm.hi","OldPprCmm.p_hi","OldPprCmm.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PprBase.hi","PprBase.p_hi","PprBase.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PprC.hi","PprC.p_hi","PprC.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PprCmm.hi","PprCmm.p_hi","PprCmm.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PprCmmDecl.hi","PprCmmDecl.p_hi","PprCmmDecl.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PprCmmExpr.hi","PprCmmExpr.p_hi","PprCmmExpr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Bitmap.hi","Bitmap.p_hi","Bitmap.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgBindery.hi","CgBindery.p_hi","CgBindery.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgCallConv.hi","CgCallConv.p_hi","CgCallConv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgCase.hi","CgCase.p_hi","CgCase.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgClosure.hi","CgClosure.p_hi","CgClosure.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgCon.hi","CgCon.p_hi","CgCon.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgExpr.hi","CgExpr.p_hi","CgExpr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgExtCode.hi","CgExtCode.p_hi","CgExtCode.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgForeignCall.hi","CgForeignCall.p_hi","CgForeignCall.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgHeapery.hi","CgHeapery.p_hi","CgHeapery.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgHpc.hi","CgHpc.p_hi","CgHpc.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgInfoTbls.hi","CgInfoTbls.p_hi","CgInfoTbls.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgLetNoEscape.hi","CgLetNoEscape.p_hi","CgLetNoEscape.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgMonad.hi","CgMonad.p_hi","CgMonad.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgParallel.hi","CgParallel.p_hi","CgParallel.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgPrimOp.hi","CgPrimOp.p_hi","CgPrimOp.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgProf.hi","CgProf.p_hi","CgProf.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgStackery.hi","CgStackery.p_hi","CgStackery.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgTailCall.hi","CgTailCall.p_hi","CgTailCall.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgTicky.hi","CgTicky.p_hi","CgTicky.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CgUtils.hi","CgUtils.p_hi","CgUtils.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmm.hi","StgCmm.p_hi","StgCmm.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmBind.hi","StgCmmBind.p_hi","StgCmmBind.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmClosure.hi","StgCmmClosure.p_hi","StgCmmClosure.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmCon.hi","StgCmmCon.p_hi","StgCmmCon.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmEnv.hi","StgCmmEnv.p_hi","StgCmmEnv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmExpr.hi","StgCmmExpr.p_hi","StgCmmExpr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmForeign.hi","StgCmmForeign.p_hi","StgCmmForeign.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmGran.hi","StgCmmGran.p_hi","StgCmmGran.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmHeap.hi","StgCmmHeap.p_hi","StgCmmHeap.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmHpc.hi","StgCmmHpc.p_hi","StgCmmHpc.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmLayout.hi","StgCmmLayout.p_hi","StgCmmLayout.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmMonad.hi","StgCmmMonad.p_hi","StgCmmMonad.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmPrim.hi","StgCmmPrim.p_hi","StgCmmPrim.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmProf.hi","StgCmmProf.p_hi","StgCmmProf.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmTicky.hi","StgCmmTicky.p_hi","StgCmmTicky.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgCmmUtils.hi","StgCmmUtils.p_hi","StgCmmUtils.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["ClosureInfo.hi","ClosureInfo.p_hi","ClosureInfo.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CodeGen.hi","CodeGen.p_hi","CodeGen.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SMRep.hi","SMRep.p_hi","SMRep.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CoreArity.hi","CoreArity.p_hi","CoreArity.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CoreFVs.hi","CoreFVs.p_hi","CoreFVs.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CoreLint.hi","CoreLint.p_hi","CoreLint.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CorePrep.hi","CorePrep.p_hi","CorePrep.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CoreSubst.hi","CoreSubst.p_hi","CoreSubst.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CoreSyn.hi","CoreSyn.p_hi","CoreSyn.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TrieMap.hi","TrieMap.p_hi","TrieMap.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CoreTidy.hi","CoreTidy.p_hi","CoreTidy.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CoreUnfold.hi","CoreUnfold.p_hi","CoreUnfold.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CoreUtils.hi","CoreUtils.p_hi","CoreUtils.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["ExternalCore.hi","ExternalCore.p_hi","ExternalCore.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["MkCore.hi","MkCore.p_hi","MkCore.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["MkExternalCore.hi","MkExternalCore.p_hi","MkExternalCore.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PprCore.hi","PprCore.p_hi","PprCore.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PprExternalCore.hi","PprExternalCore.p_hi","PprExternalCore.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Check.hi","Check.p_hi","Check.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Coverage.hi","Coverage.p_hi","Coverage.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Desugar.hi","Desugar.p_hi","Desugar.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DsArrows.hi","DsArrows.p_hi","DsArrows.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DsBinds.hi","DsBinds.p_hi","DsBinds.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DsCCall.hi","DsCCall.p_hi","DsCCall.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DsExpr.hi","DsExpr.p_hi","DsExpr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DsForeign.hi","DsForeign.p_hi","DsForeign.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DsGRHSs.hi","DsGRHSs.p_hi","DsGRHSs.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DsListComp.hi","DsListComp.p_hi","DsListComp.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DsMonad.hi","DsMonad.p_hi","DsMonad.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DsUtils.hi","DsUtils.p_hi","DsUtils.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Match.hi","Match.p_hi","Match.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["MatchCon.hi","MatchCon.p_hi","MatchCon.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["MatchLit.hi","MatchLit.p_hi","MatchLit.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HsBinds.hi","HsBinds.p_hi","HsBinds.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HsDecls.hi","HsDecls.p_hi","HsDecls.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HsDoc.hi","HsDoc.p_hi","HsDoc.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HsExpr.hi","HsExpr.p_hi","HsExpr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HsImpExp.hi","HsImpExp.p_hi","HsImpExp.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HsLit.hi","HsLit.p_hi","HsLit.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HsPat.hi","HsPat.p_hi","HsPat.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HsSyn.hi","HsSyn.p_hi","HsSyn.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HsTypes.hi","HsTypes.p_hi","HsTypes.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HsUtils.hi","HsUtils.p_hi","HsUtils.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["BinIface.hi","BinIface.p_hi","BinIface.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["BuildTyCl.hi","BuildTyCl.p_hi","BuildTyCl.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["IfaceEnv.hi","IfaceEnv.p_hi","IfaceEnv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["IfaceSyn.hi","IfaceSyn.p_hi","IfaceSyn.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["IfaceType.hi","IfaceType.p_hi","IfaceType.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["LoadIface.hi","LoadIface.p_hi","LoadIface.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["MkIface.hi","MkIface.p_hi","MkIface.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcIface.hi","TcIface.p_hi","TcIface.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["FlagChecker.hi","FlagChecker.p_hi","FlagChecker.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Annotations.hi","Annotations.p_hi","Annotations.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["BreakArray.hi","BreakArray.p_hi","BreakArray.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CmdLineParser.hi","CmdLineParser.p_hi","CmdLineParser.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CodeOutput.hi","CodeOutput.p_hi","CodeOutput.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Config.hi","Config.p_hi","Config.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Constants.hi","Constants.p_hi","Constants.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DriverMkDepend.hi","DriverMkDepend.p_hi","DriverMkDepend.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DriverPhases.hi","DriverPhases.p_hi","DriverPhases.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DriverPipeline.hi","DriverPipeline.p_hi","DriverPipeline.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DynFlags.hi","DynFlags.p_hi","DynFlags.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["ErrUtils.hi","ErrUtils.p_hi","ErrUtils.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Finder.hi","Finder.p_hi","Finder.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["GHC.hi","GHC.p_hi","GHC.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["GhcMake.hi","GhcMake.p_hi","GhcMake.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["GhcPlugins.hi","GhcPlugins.p_hi","GhcPlugins.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DynamicLoading.hi","DynamicLoading.p_hi","DynamicLoading.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HeaderInfo.hi","HeaderInfo.p_hi","HeaderInfo.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HscMain.hi","HscMain.p_hi","HscMain.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HscStats.hi","HscStats.p_hi","HscStats.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HscTypes.hi","HscTypes.p_hi","HscTypes.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["InteractiveEval.hi","InteractiveEval.p_hi","InteractiveEval.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PackageConfig.hi","PackageConfig.p_hi","PackageConfig.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Packages.hi","Packages.p_hi","Packages.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PprTyThing.hi","PprTyThing.p_hi","PprTyThing.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StaticFlags.hi","StaticFlags.p_hi","StaticFlags.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StaticFlagParser.hi","StaticFlagParser.p_hi","StaticFlagParser.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SysTools.hi","SysTools.p_hi","SysTools.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TidyPgm.hi","TidyPgm.p_hi","TidyPgm.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Ctype.hi","Ctype.p_hi","Ctype.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["HaddockUtils.hi","HaddockUtils.p_hi","HaddockUtils.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["LexCore.hi","LexCore.p_hi","LexCore.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Lexer.hi","Lexer.p_hi","Lexer.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["OptCoercion.hi","OptCoercion.p_hi","OptCoercion.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Parser.hi","Parser.p_hi","Parser.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["ParserCore.hi","ParserCore.p_hi","ParserCore.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["ParserCoreUtils.hi","ParserCoreUtils.p_hi","ParserCoreUtils.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RdrHsSyn.hi","RdrHsSyn.p_hi","RdrHsSyn.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["ForeignCall.hi","ForeignCall.p_hi","ForeignCall.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PrelInfo.hi","PrelInfo.p_hi","PrelInfo.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PrelNames.hi","PrelNames.p_hi","PrelNames.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PrelRules.hi","PrelRules.p_hi","PrelRules.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PrimOp.hi","PrimOp.p_hi","PrimOp.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TysPrim.hi","TysPrim.p_hi","TysPrim.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TysWiredIn.hi","TysWiredIn.p_hi","TysWiredIn.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CostCentre.hi","CostCentre.p_hi","CostCentre.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["ProfInit.hi","ProfInit.p_hi","ProfInit.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SCCfinal.hi","SCCfinal.p_hi","SCCfinal.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RnBinds.hi","RnBinds.p_hi","RnBinds.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RnEnv.hi","RnEnv.p_hi","RnEnv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RnExpr.hi","RnExpr.p_hi","RnExpr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RnHsDoc.hi","RnHsDoc.p_hi","RnHsDoc.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RnNames.hi","RnNames.p_hi","RnNames.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RnPat.hi","RnPat.p_hi","RnPat.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RnSource.hi","RnSource.p_hi","RnSource.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RnTypes.hi","RnTypes.p_hi","RnTypes.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CoreMonad.hi","CoreMonad.p_hi","CoreMonad.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CSE.hi","CSE.p_hi","CSE.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["FloatIn.hi","FloatIn.p_hi","FloatIn.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["FloatOut.hi","FloatOut.p_hi","FloatOut.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["LiberateCase.hi","LiberateCase.p_hi","LiberateCase.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["OccurAnal.hi","OccurAnal.p_hi","OccurAnal.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SAT.hi","SAT.p_hi","SAT.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SetLevels.hi","SetLevels.p_hi","SetLevels.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SimplCore.hi","SimplCore.p_hi","SimplCore.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SimplEnv.hi","SimplEnv.p_hi","SimplEnv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SimplMonad.hi","SimplMonad.p_hi","SimplMonad.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SimplUtils.hi","SimplUtils.p_hi","SimplUtils.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Simplify.hi","Simplify.p_hi","Simplify.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SRT.hi","SRT.p_hi","SRT.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SimplStg.hi","SimplStg.p_hi","SimplStg.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgStats.hi","StgStats.p_hi","StgStats.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["UnariseStg.hi","UnariseStg.p_hi","UnariseStg.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Rules.hi","Rules.p_hi","Rules.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SpecConstr.hi","SpecConstr.p_hi","SpecConstr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Specialise.hi","Specialise.p_hi","Specialise.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CoreToStg.hi","CoreToStg.p_hi","CoreToStg.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgLint.hi","StgLint.p_hi","StgLint.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StgSyn.hi","StgSyn.p_hi","StgSyn.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["DmdAnal.hi","DmdAnal.p_hi","DmdAnal.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["WorkWrap.hi","WorkWrap.p_hi","WorkWrap.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["WwLib.hi","WwLib.p_hi","WwLib.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["FamInst.hi","FamInst.p_hi","FamInst.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Inst.hi","Inst.p_hi","Inst.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcAnnotations.hi","TcAnnotations.p_hi","TcAnnotations.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcArrows.hi","TcArrows.p_hi","TcArrows.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcBinds.hi","TcBinds.p_hi","TcBinds.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcClassDcl.hi","TcClassDcl.p_hi","TcClassDcl.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcDefaults.hi","TcDefaults.p_hi","TcDefaults.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcDeriv.hi","TcDeriv.p_hi","TcDeriv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcEnv.hi","TcEnv.p_hi","TcEnv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcExpr.hi","TcExpr.p_hi","TcExpr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcForeign.hi","TcForeign.p_hi","TcForeign.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcGenDeriv.hi","TcGenDeriv.p_hi","TcGenDeriv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcGenGenerics.hi","TcGenGenerics.p_hi","TcGenGenerics.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcHsSyn.hi","TcHsSyn.p_hi","TcHsSyn.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcHsType.hi","TcHsType.p_hi","TcHsType.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcInstDcls.hi","TcInstDcls.p_hi","TcInstDcls.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcMType.hi","TcMType.p_hi","TcMType.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcMatches.hi","TcMatches.p_hi","TcMatches.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcPat.hi","TcPat.p_hi","TcPat.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcRnDriver.hi","TcRnDriver.p_hi","TcRnDriver.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcRnMonad.hi","TcRnMonad.p_hi","TcRnMonad.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcRnTypes.hi","TcRnTypes.p_hi","TcRnTypes.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcRules.hi","TcRules.p_hi","TcRules.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcSimplify.hi","TcSimplify.p_hi","TcSimplify.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcErrors.hi","TcErrors.p_hi","TcErrors.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcTyClsDecls.hi","TcTyClsDecls.p_hi","TcTyClsDecls.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcTyDecls.hi","TcTyDecls.p_hi","TcTyDecls.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcType.hi","TcType.p_hi","TcType.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcEvidence.hi","TcEvidence.p_hi","TcEvidence.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcUnify.hi","TcUnify.p_hi","TcUnify.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcInteract.hi","TcInteract.p_hi","TcInteract.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcCanonical.hi","TcCanonical.p_hi","TcCanonical.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TcSMonad.hi","TcSMonad.p_hi","TcSMonad.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Class.hi","Class.p_hi","Class.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Coercion.hi","Coercion.p_hi","Coercion.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["FamInstEnv.hi","FamInstEnv.p_hi","FamInstEnv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["FunDeps.hi","FunDeps.p_hi","FunDeps.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["InstEnv.hi","InstEnv.p_hi","InstEnv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TyCon.hi","TyCon.p_hi","TyCon.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Kind.hi","Kind.p_hi","Kind.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Type.hi","Type.p_hi","Type.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TypeRep.hi","TypeRep.p_hi","TypeRep.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Unify.hi","Unify.p_hi","Unify.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Bag.hi","Bag.p_hi","Bag.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Binary.hi","Binary.p_hi","Binary.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["BufWrite.hi","BufWrite.p_hi","BufWrite.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Digraph.hi","Digraph.p_hi","Digraph.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Encoding.hi","Encoding.p_hi","Encoding.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["FastBool.hi","FastBool.p_hi","FastBool.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["FastFunctions.hi","FastFunctions.p_hi","FastFunctions.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["FastMutInt.hi","FastMutInt.p_hi","FastMutInt.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["FastString.hi","FastString.p_hi","FastString.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["FastTypes.hi","FastTypes.p_hi","FastTypes.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Fingerprint.hi","Fingerprint.p_hi","Fingerprint.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["FiniteMap.hi","FiniteMap.p_hi","FiniteMap.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["GraphBase.hi","GraphBase.p_hi","GraphBase.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["GraphColor.hi","GraphColor.p_hi","GraphColor.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["GraphOps.hi","GraphOps.p_hi","GraphOps.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["GraphPpr.hi","GraphPpr.p_hi","GraphPpr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["IOEnv.hi","IOEnv.p_hi","IOEnv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["ListSetOps.hi","ListSetOps.p_hi","ListSetOps.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Maybes.hi","Maybes.p_hi","Maybes.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["MonadUtils.hi","MonadUtils.p_hi","MonadUtils.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["OrdList.hi","OrdList.p_hi","OrdList.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Outputable.hi","Outputable.p_hi","Outputable.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Pair.hi","Pair.p_hi","Pair.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Panic.hi","Panic.p_hi","Panic.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Pretty.hi","Pretty.p_hi","Pretty.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Serialized.hi","Serialized.p_hi","Serialized.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["State.hi","State.p_hi","State.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Stream.hi","Stream.p_hi","Stream.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["StringBuffer.hi","StringBuffer.p_hi","StringBuffer.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["UniqFM.hi","UniqFM.p_hi","UniqFM.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["UniqSet.hi","UniqSet.p_hi","UniqSet.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Util.hi","Util.p_hi","Util.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Builtins/Base.hi","Vectorise/Builtins/Base.p_hi","Vectorise/Builtins/Base.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Builtins/Initialise.hi","Vectorise/Builtins/Initialise.p_hi","Vectorise/Builtins/Initialise.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Builtins.hi","Vectorise/Builtins.p_hi","Vectorise/Builtins.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Monad/Base.hi","Vectorise/Monad/Base.p_hi","Vectorise/Monad/Base.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Monad/Naming.hi","Vectorise/Monad/Naming.p_hi","Vectorise/Monad/Naming.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Monad/Local.hi","Vectorise/Monad/Local.p_hi","Vectorise/Monad/Local.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Monad/Global.hi","Vectorise/Monad/Global.p_hi","Vectorise/Monad/Global.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Monad/InstEnv.hi","Vectorise/Monad/InstEnv.p_hi","Vectorise/Monad/InstEnv.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Monad.hi","Vectorise/Monad.p_hi","Vectorise/Monad.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Utils/Base.hi","Vectorise/Utils/Base.p_hi","Vectorise/Utils/Base.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Utils/Closure.hi","Vectorise/Utils/Closure.p_hi","Vectorise/Utils/Closure.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Utils/Hoisting.hi","Vectorise/Utils/Hoisting.p_hi","Vectorise/Utils/Hoisting.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Utils/PADict.hi","Vectorise/Utils/PADict.p_hi","Vectorise/Utils/PADict.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Utils/Poly.hi","Vectorise/Utils/Poly.p_hi","Vectorise/Utils/Poly.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Utils.hi","Vectorise/Utils.p_hi","Vectorise/Utils.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Generic/Description.hi","Vectorise/Generic/Description.p_hi","Vectorise/Generic/Description.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Generic/PAMethods.hi","Vectorise/Generic/PAMethods.p_hi","Vectorise/Generic/PAMethods.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Generic/PADict.hi","Vectorise/Generic/PADict.p_hi","Vectorise/Generic/PADict.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Generic/PData.hi","Vectorise/Generic/PData.p_hi","Vectorise/Generic/PData.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Type/Env.hi","Vectorise/Type/Env.p_hi","Vectorise/Type/Env.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Type/Type.hi","Vectorise/Type/Type.p_hi","Vectorise/Type/Type.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Type/TyConDecl.hi","Vectorise/Type/TyConDecl.p_hi","Vectorise/Type/TyConDecl.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Type/Classify.hi","Vectorise/Type/Classify.p_hi","Vectorise/Type/Classify.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Convert.hi","Vectorise/Convert.p_hi","Vectorise/Convert.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Vect.hi","Vectorise/Vect.p_hi","Vectorise/Vect.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Var.hi","Vectorise/Var.p_hi","Vectorise/Var.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Env.hi","Vectorise/Env.p_hi","Vectorise/Env.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise/Exp.hi","Vectorise/Exp.p_hi","Vectorise/Exp.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Vectorise.hi","Vectorise.p_hi","Vectorise.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Hoopl/Dataflow.hi","Hoopl/Dataflow.p_hi","Hoopl/Dataflow.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Hoopl.hi","Hoopl.p_hi","Hoopl.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["AsmCodeGen.hi","AsmCodeGen.p_hi","AsmCodeGen.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["TargetReg.hi","TargetReg.p_hi","TargetReg.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["NCGMonad.hi","NCGMonad.p_hi","NCGMonad.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Instruction.hi","Instruction.p_hi","Instruction.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Size.hi","Size.p_hi","Size.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Reg.hi","Reg.p_hi","Reg.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegClass.hi","RegClass.p_hi","RegClass.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PIC.hi","PIC.p_hi","PIC.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["Platform.hi","Platform.p_hi","Platform.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["CPrim.hi","CPrim.p_hi","CPrim.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["X86/Regs.hi","X86/Regs.p_hi","X86/Regs.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["X86/RegInfo.hi","X86/RegInfo.p_hi","X86/RegInfo.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["X86/Instr.hi","X86/Instr.p_hi","X86/Instr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["X86/Cond.hi","X86/Cond.p_hi","X86/Cond.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["X86/Ppr.hi","X86/Ppr.p_hi","X86/Ppr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["X86/CodeGen.hi","X86/CodeGen.p_hi","X86/CodeGen.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PPC/Regs.hi","PPC/Regs.p_hi","PPC/Regs.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PPC/RegInfo.hi","PPC/RegInfo.p_hi","PPC/RegInfo.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PPC/Instr.hi","PPC/Instr.p_hi","PPC/Instr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PPC/Cond.hi","PPC/Cond.p_hi","PPC/Cond.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PPC/Ppr.hi","PPC/Ppr.p_hi","PPC/Ppr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["PPC/CodeGen.hi","PPC/CodeGen.p_hi","PPC/CodeGen.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/Base.hi","SPARC/Base.p_hi","SPARC/Base.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/Regs.hi","SPARC/Regs.p_hi","SPARC/Regs.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/RegPlate.hi","SPARC/RegPlate.p_hi","SPARC/RegPlate.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/Imm.hi","SPARC/Imm.p_hi","SPARC/Imm.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/AddrMode.hi","SPARC/AddrMode.p_hi","SPARC/AddrMode.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/Cond.hi","SPARC/Cond.p_hi","SPARC/Cond.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/Instr.hi","SPARC/Instr.p_hi","SPARC/Instr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/Stack.hi","SPARC/Stack.p_hi","SPARC/Stack.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/ShortcutJump.hi","SPARC/ShortcutJump.p_hi","SPARC/ShortcutJump.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/Ppr.hi","SPARC/Ppr.p_hi","SPARC/Ppr.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/CodeGen.hi","SPARC/CodeGen.p_hi","SPARC/CodeGen.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/CodeGen/Amode.hi","SPARC/CodeGen/Amode.p_hi","SPARC/CodeGen/Amode.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/CodeGen/Base.hi","SPARC/CodeGen/Base.p_hi","SPARC/CodeGen/Base.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/CodeGen/CondCode.hi","SPARC/CodeGen/CondCode.p_hi","SPARC/CodeGen/CondCode.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/CodeGen/Gen32.hi","SPARC/CodeGen/Gen32.p_hi","SPARC/CodeGen/Gen32.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/CodeGen/Gen64.hi","SPARC/CodeGen/Gen64.p_hi","SPARC/CodeGen/Gen64.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/CodeGen/Sanity.hi","SPARC/CodeGen/Sanity.p_hi","SPARC/CodeGen/Sanity.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["SPARC/CodeGen/Expand.hi","SPARC/CodeGen/Expand.p_hi","SPARC/CodeGen/Expand.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Liveness.hi","RegAlloc/Liveness.p_hi","RegAlloc/Liveness.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Graph/Main.hi","RegAlloc/Graph/Main.p_hi","RegAlloc/Graph/Main.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Graph/Stats.hi","RegAlloc/Graph/Stats.p_hi","RegAlloc/Graph/Stats.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Graph/ArchBase.hi","RegAlloc/Graph/ArchBase.p_hi","RegAlloc/Graph/ArchBase.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Graph/ArchX86.hi","RegAlloc/Graph/ArchX86.p_hi","RegAlloc/Graph/ArchX86.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Graph/Coalesce.hi","RegAlloc/Graph/Coalesce.p_hi","RegAlloc/Graph/Coalesce.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Graph/Spill.hi","RegAlloc/Graph/Spill.p_hi","RegAlloc/Graph/Spill.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Graph/SpillClean.hi","RegAlloc/Graph/SpillClean.p_hi","RegAlloc/Graph/SpillClean.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Graph/SpillCost.hi","RegAlloc/Graph/SpillCost.p_hi","RegAlloc/Graph/SpillCost.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Graph/TrivColorable.hi","RegAlloc/Graph/TrivColorable.p_hi","RegAlloc/Graph/TrivColorable.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Linear/Main.hi","RegAlloc/Linear/Main.p_hi","RegAlloc/Linear/Main.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Linear/JoinToTargets.hi","RegAlloc/Linear/JoinToTargets.p_hi","RegAlloc/Linear/JoinToTargets.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Linear/State.hi","RegAlloc/Linear/State.p_hi","RegAlloc/Linear/State.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Linear/Stats.hi","RegAlloc/Linear/Stats.p_hi","RegAlloc/Linear/Stats.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Linear/FreeRegs.hi","RegAlloc/Linear/FreeRegs.p_hi","RegAlloc/Linear/FreeRegs.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Linear/StackMap.hi","RegAlloc/Linear/StackMap.p_hi","RegAlloc/Linear/StackMap.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Linear/Base.hi","RegAlloc/Linear/Base.p_hi","RegAlloc/Linear/Base.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Linear/X86/FreeRegs.hi","RegAlloc/Linear/X86/FreeRegs.p_hi","RegAlloc/Linear/X86/FreeRegs.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Linear/PPC/FreeRegs.hi","RegAlloc/Linear/PPC/FreeRegs.p_hi","RegAlloc/Linear/PPC/FreeRegs.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["RegAlloc/Linear/SPARC/FreeRegs.hi","RegAlloc/Linear/SPARC/FreeRegs.p_hi","RegAlloc/Linear/SPARC/FreeRegs.dyn_hi"] (ignoring) ghc-7.6.3: cannot find any of ["libHSghc-7.6.3.a","libHSghc-7.6.3.p_a","libHSghc-7.6.3-ghc7.8.0.20140331.so","libHSghc-7.6.3-ghc7.8.0.20140331.dylib","HSghc-7.6.3-ghc7.8.0.20140331.dll"] on library path (ignoring) Writing new package config file... done. CROSS_COMPILE="" "inplace/bin/ghc-cabal" configure --with-ghc="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" --with-ghc-pkg="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" --flags=stage1 --package-db=/home/cjwatson/ghc-7.6.3/libraries/bootstrapping.conf --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --constraint "Cabal == 1.16.0" --constraint "hpc == 0.6.0.0" --constraint "binary == 0.5.1.1" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.9.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" -- stage1 ghc Configuring ghc-bin-7.6.3... Warning: 'data-dir: ..' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. CROSS_COMPILE="" "inplace/bin/ghc-cabal" configure --with-ghc="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" --with-ghc-pkg="/home/cjwatson/ghc-aarch64/inplace/bin/ghc-pkg" --package-db=/home/cjwatson/ghc-7.6.3/libraries/bootstrapping.conf --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --constraint "Cabal == 1.16.0" --constraint "hpc == 0.6.0.0" --constraint "binary == 0.5.1.1" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.9.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" -- dist utils/hsc2hs Configuring hsc2hs-0.67... Creating includes/ghcautoconf.h... Done. "rm" -f includes/ghcplatform.h Creating includes/ghcplatform.h... Done. "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -M -dep-makefile utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix "" -include-pkg-deps -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc utils/hsc2hs/./Main.hs utils/hsc2hs/./HSCParser.hs utils/hsc2hs/./DirectCodegen.hs utils/hsc2hs/./CrossCodegen.hs utils/hsc2hs/./UtilsCodegen.hs utils/hsc2hs/./Common.hs utils/hsc2hs/./C.hs utils/hsc2hs/./Flags.hs echo "utils/hsc2hs_dist_depfile_haskell_EXISTS = YES" >> utils/hsc2hs/dist/build/.depend.haskell.tmp for dir in utils/hsc2hs/dist/build/./; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' utils/hsc2hs/dist/build/.depend.haskell.tmp > utils/hsc2hs/dist/build/.depend.haskell "rm" -f utils/hsc2hs/dist/build/.depend.c_asm.tmp echo "utils/hsc2hs_dist_depfile_c_asm_EXISTS = YES" >> utils/hsc2hs/dist/build/.depend.c_asm.tmp mv utils/hsc2hs/dist/build/.depend.c_asm.tmp utils/hsc2hs/dist/build/.depend.c_asm "inplace/bin/mkdirhier" utils/genprimopcode/dist/build//. "rm" -f utils/genprimopcode/dist/build/.depend.haskell.tmp "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -M -dep-makefile utils/genprimopcode/dist/build/.depend.haskell.tmp -dep-suffix "" -include-pkg-deps -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen -package array -no-user-package-db -rtsopts -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build -hisuf hi -osuf o -hcsuf hc utils/genprimopcode/./Lexer.hs utils/genprimopcode/./Main.hs utils/genprimopcode/./ParserM.hs utils/genprimopcode/./Parser.hs utils/genprimopcode/./Syntax.hs echo "utils/genprimopcode_dist_depfile_haskell_EXISTS = YES" >> utils/genprimopcode/dist/build/.depend.haskell.tmp for dir in utils/genprimopcode/dist/build/./; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' utils/genprimopcode/dist/build/.depend.haskell.tmp > utils/genprimopcode/dist/build/.depend.haskell "rm" -f utils/genprimopcode/dist/build/.depend.c_asm.tmp echo "utils/genprimopcode_dist_depfile_c_asm_EXISTS = YES" >> utils/genprimopcode/dist/build/.depend.c_asm.tmp mv utils/genprimopcode/dist/build/.depend.c_asm.tmp utils/genprimopcode/dist/build/.depend.c_asm ===--- building phase 1 /usr/bin/make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds utils/unlit/ghc.mk:18: utils/unlit/dist/build/.depend.c_asm: No such file or directory utils/hp2ps/ghc.mk:24: utils/hp2ps/dist/build/.depend.c_asm: No such file or directory includes/ghc.mk:146: includes/dist-derivedconstants/build/.depend.c_asm: No such file or directory includes/ghc.mk:184: includes/dist-ghcconstants/build/.depend.c_asm: No such file or directory utils/genapply/ghc.mk:26: utils/genapply/dist/build/.depend.haskell: No such file or directory utils/genapply/ghc.mk:26: utils/genapply/dist/build/.depend.c_asm: No such file or directory libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No such file or directory libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.c_asm: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist-boot/build/.depend-v.haskell: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist-boot/build/.depend-v.c_asm: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist-boot/build/.depend-v.haskell: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist-boot/build/.depend-v.c_asm: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist-boot/build/.depend-v.haskell: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist-boot/build/.depend-v.c_asm: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/build/.depend-v.haskell: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/build/.depend-v.c_asm: No such file or directory compiler/ghc.mk:450: compiler/stage1/build/.depend-v.haskell: No such file or directory compiler/ghc.mk:450: compiler/stage1/build/.depend-v.c_asm: No such file or directory ghc/ghc.mk:106: ghc/stage1/build/.depend.haskell: No such file or directory ghc/ghc.mk:106: ghc/stage1/build/.depend.c_asm: No such file or directory "rm" -f ghc/stage1/build/.depend.c_asm.tmp echo "ghc_stage1_depfile_c_asm_EXISTS = YES" >> ghc/stage1/build/.depend.c_asm.tmp mv ghc/stage1/build/.depend.c_asm.tmp ghc/stage1/build/.depend.c_asm "rm" -f compiler/stage1/ghc_boot_platform.h Creating compiler/stage1/ghc_boot_platform.h... Done. "rm" -f ghc/stage1/build/.depend.haskell.tmp "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -M -dep-makefile ghc/stage1/build/.depend.haskell.tmp -dep-suffix "" -include-pkg-deps -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -ighc/. -ighc/stage1/build -ighc/stage1/build/autogen -Ighc/stage1/build -Ighc/stage1/build/autogen -optP-include -optPghc/stage1/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package ghc-7.8.0.20140331 -package process-1.2.0.0 -package unix-2.7.0.0 -Wall -XHaskell98 -XNondecreasingIndentation -XCPP -XPatternGuards -no-user-package-db -rtsopts -odir ghc/stage1/build -hidir ghc/stage1/build -stubdir ghc/stage1/build -hisuf hi -osuf o -hcsuf hc ghc/./Main.hs echo "ghc_stage1_depfile_haskell_EXISTS = YES" >> ghc/stage1/build/.depend.haskell.tmp for dir in ghc/stage1/build/./; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' ghc/stage1/build/.depend.haskell.tmp > ghc/stage1/build/.depend.haskell "rm" -f compiler/stage1/build/.depend-v.c_asm.tmp /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -fno-stack-protector -Icompiler/stage1 -Icompiler/. -Icompiler/parser -Icompiler/utils -isystem'/home/cjwatson/ghc-aarch64/libraries/process/include' -isystem'/home/cjwatson/ghc-aarch64/libraries/old-time/include' -isystem'/home/cjwatson/ghc-aarch64/libraries/directory/include' -isystem'/home/cjwatson/ghc-aarch64/libraries/unix/include' -isystem'/home/cjwatson/ghc-aarch64/libraries/bytestring/include' -isystem'/home/cjwatson/ghc-aarch64/libraries/time/include' -isystem'/home/cjwatson/ghc-aarch64/libraries/containers/include' -isystem'/home/cjwatson/ghc-aarch64/libraries/base/include' -isystem'/home/cjwatson/ghc-aarch64/rts/dist/build' -isystem'/home/cjwatson/ghc-aarch64/includes' -isystem'/home/cjwatson/ghc-aarch64/includes/dist-derivedconstants/header' -MM compiler/utils/md5.c -MF compiler/stage1/build/.depend-v.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|compiler/utils/|" -e "1s|compiler/|compiler/stage1/build/|" -e "1s|stage1/build/stage1/build|stage1/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" compiler/stage1/build/.depend-v.c_asm.bit >> compiler/stage1/build/.depend-v.c_asm.tmp && true "rm" -f compiler/stage1/build/.depend-v.c_asm.bit echo "compiler_stage1_depfile_c_asm_EXISTS = YES" >> compiler/stage1/build/.depend-v.c_asm.tmp mv compiler/stage1/build/.depend-v.c_asm.tmp compiler/stage1/build/.depend-v.c_asm "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/hsc2hs/./HSCParser.hs -o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/HSCParser.hs:24:10: Warning: `Parser' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. utils/hsc2hs/HSCParser.hs:36:10: Warning: `Parser' is an instance of MonadPlus but not Alternative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/hsc2hs/./Flags.hs -o utils/hsc2hs/dist/build/Flags.o "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/hsc2hs/./Common.hs -o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/Common.hs:11:1: Warning: Module `System.Cmd' is deprecated: Use "System.Process" instead "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/hsc2hs/./C.hs -o utils/hsc2hs/dist/build/C.o "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/hsc2hs/./UtilsCodegen.hs -o utils/hsc2hs/dist/build/UtilsCodegen.o "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/hsc2hs/./DirectCodegen.hs -o utils/hsc2hs/dist/build/DirectCodegen.o "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/hsc2hs/./CrossCodegen.hs -o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/CrossCodegen.hs:46:10: Warning: `TestMonad' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/hsc2hs/dist/build/autogen/Paths_hsc2hs.hs -o utils/hsc2hs/dist/build/Paths_hsc2hs.o "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/hsc2hs/./Main.hs -o utils/hsc2hs/dist/build/Main.o "inplace/bin/mkdirhier" utils/hsc2hs/dist/build/tmp//. "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -o utils/hsc2hs/dist/build/tmp/hsc2hs -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/Paths_hsc2hs.o "cp" -p utils/hsc2hs/dist/build/tmp/hsc2hs inplace/lib/hsc2hs "cp" utils/hsc2hs/template-hsc.h inplace/lib/template-hsc.h "rm" -f inplace/bin/hsc2hs echo '#!/bin/sh' >> inplace/bin/hsc2hs echo 'executablename="/home/cjwatson/ghc-7.6.3/inplace/lib/hsc2hs"' >> inplace/bin/hsc2hs echo 'datadir="/home/cjwatson/ghc-7.6.3/inplace/lib"' >> inplace/bin/hsc2hs echo 'bindir="/home/cjwatson/ghc-7.6.3/inplace/bin"' >> inplace/bin/hsc2hs echo 'topdir="/home/cjwatson/ghc-7.6.3/inplace/lib"' >> inplace/bin/hsc2hs echo 'pgmgcc="/usr/bin/gcc"' >> inplace/bin/hsc2hs echo 'HSC2HS_EXTRA="--cflag=-fno-stack-protector --lflag=-Wl,--hash-size=31 --lflag=-Wl,--reduce-memory-overheads -I/home/cjwatson/ghc-7.6.3/includes"' >> "inplace/bin/hsc2hs" cat utils/hsc2hs/hsc2hs.wrapper >> inplace/bin/hsc2hs chmod +x inplace/bin/hsc2hs "inplace/bin/hsc2hs" --cc=/usr/bin/gcc --ld=/usr/bin/gcc --cross-safe --cflag=-fno-stack-protector --cflag=-D__GLASGOW_HASKELL__=708 --cflag=-Darm64_HOST_ARCH=1 --cflag=-Dlinux_HOST_OS=1 '--cflag=-fno-stack-protector' '--cflag=-Icompiler/stage1' '--cflag=-Icompiler/.' '--cflag=-Icompiler/parser' '--cflag=-Icompiler/utils' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/process/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/old-time/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/directory/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/unix/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/bytestring/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/time/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/containers/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/base/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/rts/dist/build' '--cflag=-isystem/home/cjwatson/ghc-aarch64/includes' '--cflag=-isystem/home/cjwatson/ghc-aarch64/includes/dist-derivedconstants/header' '--lflag=-Wl,--hash-size=31' '--lflag=-Wl,--reduce-memory-overheads' '--lflag=-L/home/cjwatson/ghc-7.6.3/libraries/hpc/dist-boot/build' '--lflag=-L/home/cjwatson/ghc-7.6.3/libraries/hoopl/dist-boot/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/bin-package-db/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/binary/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/Cabal/Cabal/dist-install/build' '--lflag=-L/home/cjwatson/ghc-7.6.3/libraries/Cabal/Cabal/dist-boot/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/process/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/pretty/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/old-time/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/directory/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/unix/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/bytestring/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/time/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/old-locale/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/filepath/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/containers/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/deepseq/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/array/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/base/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/integer-simple/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/ghc-prim/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/rts/dist/build' '--lflag=-lrt' '--lflag=-lutil' '--lflag=-ldl' '--lflag=-lpthread' '--lflag=-lm' '--lflag=-lrt' '--lflag=-ldl' --cflag=-Icompiler/stage1/build/autogen --cflag=-include --cflag=compiler/stage1/build/autogen/cabal_macros.h compiler/utils/Fingerprint.hsc -o compiler/stage1/build/Fingerprint.hs "inplace/bin/mkdirhier" includes/dist-ghcconstants/build//. "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-DNOSMP -optc-DGEN_HASKELL -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -i -iincludes/. -iincludes/dist-ghcconstants/build -iincludes/dist-ghcconstants/build/autogen -Iincludes/dist-ghcconstants/build -Iincludes/dist-ghcconstants/build/autogen -no-user-package-db -rtsopts -c includes/mkDerivedConstants.c -o includes/dist-ghcconstants/build/mkDerivedConstants.o "inplace/bin/mkdirhier" includes/dist-ghcconstants/build/tmp//. "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -o includes/dist-ghcconstants/build/tmp/mkGHCConstants -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -i -iincludes/. -iincludes/dist-ghcconstants/build -iincludes/dist-ghcconstants/build/autogen -Iincludes/dist-ghcconstants/build -Iincludes/dist-ghcconstants/build/autogen -no-user-package-db -rtsopts -odir includes/dist-ghcconstants/build -hidir includes/dist-ghcconstants/build -stubdir includes/dist-ghcconstants/build -hisuf hi -osuf o -hcsuf hc -no-auto-link-packages -no-hs-main includes/dist-ghcconstants/build/mkDerivedConstants.o Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. "cp" -p includes/dist-ghcconstants/build/tmp/mkGHCConstants inplace/bin/mkGHCConstants "inplace/bin/mkdirhier" includes/dist-ghcconstants/header//. ./inplace/bin/mkGHCConstants >includes/dist-ghcconstants/header/GHCConstants.h "inplace/bin/mkdirhier" includes/dist-derivedconstants/build//. "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-DNOSMP -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -i -iincludes/. -iincludes/dist-derivedconstants/build -iincludes/dist-derivedconstants/build/autogen -Iincludes/dist-derivedconstants/build -Iincludes/dist-derivedconstants/build/autogen -no-user-package-db -rtsopts -c includes/mkDerivedConstants.c -o includes/dist-derivedconstants/build/mkDerivedConstants.o "inplace/bin/mkdirhier" includes/dist-derivedconstants/build/tmp//. "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -o includes/dist-derivedconstants/build/tmp/mkDerivedConstants -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -i -iincludes/. -iincludes/dist-derivedconstants/build -iincludes/dist-derivedconstants/build/autogen -Iincludes/dist-derivedconstants/build -Iincludes/dist-derivedconstants/build/autogen -no-user-package-db -rtsopts -odir includes/dist-derivedconstants/build -hidir includes/dist-derivedconstants/build -stubdir includes/dist-derivedconstants/build -hisuf hi -osuf o -hcsuf hc -no-auto-link-packages -no-hs-main includes/dist-derivedconstants/build/mkDerivedConstants.o Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. "cp" -p includes/dist-derivedconstants/build/tmp/mkDerivedConstants inplace/bin/mkDerivedConstants "inplace/bin/mkdirhier" includes/dist-derivedconstants/header//. ./inplace/bin/mkDerivedConstants >includes/dist-derivedconstants/header/DerivedConstants.h /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -undef -traditional -P -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -x c compiler/prelude/primops.txt.pp | grep -v '^#pragma GCC' > compiler/prelude/primops.txt "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen -package array -no-user-package-db -rtsopts -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/genprimopcode/./ParserM.hs -o utils/genprimopcode/dist/build/ParserM.o utils/genprimopcode/ParserM.hs:26:10: Warning: `ParserM' is an instance of Monad but not Applicative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen -package array -no-user-package-db -rtsopts -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/genprimopcode/./Lexer.hs -o utils/genprimopcode/dist/build/Lexer.o "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen -package array -no-user-package-db -rtsopts -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/genprimopcode/./Syntax.hs -o utils/genprimopcode/dist/build/Syntax.o "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen -package array -no-user-package-db -rtsopts -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/genprimopcode/./Parser.hs -o utils/genprimopcode/dist/build/Parser.o "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen -package array -no-user-package-db -rtsopts -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build -hisuf hi -osuf o -hcsuf hc -c utils/genprimopcode/./Main.hs -o utils/genprimopcode/dist/build/Main.o "inplace/bin/mkdirhier" utils/genprimopcode/dist/build/tmp//. "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -o utils/genprimopcode/dist/build/tmp/genprimopcode -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen -package array -no-user-package-db -rtsopts -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build -hisuf hi -osuf o -hcsuf hc utils/genprimopcode/dist/build/Lexer.o utils/genprimopcode/dist/build/Main.o utils/genprimopcode/dist/build/ParserM.o utils/genprimopcode/dist/build/Parser.o utils/genprimopcode/dist/build/Syntax.o "cp" -p utils/genprimopcode/dist/build/tmp/genprimopcode inplace/bin/genprimopcode "inplace/bin/genprimopcode" --data-decl < compiler/prelude/primops.txt > compiler/primop-data-decl.hs-incl "inplace/bin/genprimopcode" --primop-tag < compiler/prelude/primops.txt > compiler/primop-tag.hs-incl "inplace/bin/genprimopcode" --primop-list < compiler/prelude/primops.txt > compiler/primop-list.hs-incl "inplace/bin/genprimopcode" --has-side-effects < compiler/prelude/primops.txt > compiler/primop-has-side-effects.hs-incl "inplace/bin/genprimopcode" --out-of-line < compiler/prelude/primops.txt > compiler/primop-out-of-line.hs-incl "inplace/bin/genprimopcode" --commutable < compiler/prelude/primops.txt > compiler/primop-commutable.hs-incl "inplace/bin/genprimopcode" --code-size < compiler/prelude/primops.txt > compiler/primop-code-size.hs-incl "inplace/bin/genprimopcode" --can-fail < compiler/prelude/primops.txt > compiler/primop-can-fail.hs-incl "inplace/bin/genprimopcode" --strictness < compiler/prelude/primops.txt > compiler/primop-strictness.hs-incl "inplace/bin/genprimopcode" --primop-primop-info < compiler/prelude/primops.txt > compiler/primop-primop-info.hs-incl "rm" -f compiler/stage1/build/.depend-v.haskell.tmp "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -M -dep-makefile compiler/stage1/build/.depend-v.haskell.tmp -dep-suffix "" -include-pkg-deps -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -package-name ghc-7.6.3 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.16.0 -package array-0.5.0.0 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package hoopl-3.9.0.0 -package hpc-0.6.0.0 -package process-1.2.0.0 -package time-1.4.2 -package unix-2.7.0.0 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XHaskell98 -XNondecreasingIndentation -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -DNO_REGS -DSTAGE=1 -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc compiler/basicTypes/Avail.hs compiler/basicTypes/BasicTypes.lhs compiler/basicTypes/DataCon.lhs compiler/basicTypes/Demand.lhs compiler/utils/Exception.hs compiler/main/GhcMonad.hs compiler/basicTypes/Id.lhs compiler/basicTypes/IdInfo.lhs compiler/basicTypes/Literal.lhs compiler/llvmGen/Llvm.hs compiler/llvmGen/Llvm/AbsSyn.hs compiler/llvmGen/Llvm/PpLlvm.hs compiler/llvmGen/Llvm/Types.hs compiler/llvmGen/LlvmCodeGen.hs compiler/llvmGen/LlvmCodeGen/Base.hs compiler/llvmGen/LlvmCodeGen/CodeGen.hs compiler/llvmGen/LlvmCodeGen/Data.hs compiler/llvmGen/LlvmCodeGen/Ppr.hs compiler/llvmGen/LlvmCodeGen/Regs.hs compiler/llvmGen/LlvmMangler.hs compiler/basicTypes/MkId.lhs compiler/basicTypes/Module.lhs compiler/basicTypes/Name.lhs compiler/basicTypes/NameEnv.lhs compiler/basicTypes/NameSet.lhs compiler/basicTypes/OccName.lhs compiler/basicTypes/RdrName.lhs compiler/basicTypes/SrcLoc.lhs compiler/basicTypes/UniqSupply.lhs compiler/basicTypes/Unique.lhs compiler/basicTypes/Var.lhs compiler/basicTypes/VarEnv.lhs compiler/basicTypes/VarSet.lhs compiler/cmm/BlockId.hs compiler/cmm/CLabel.hs compiler/cmm/Cmm.hs compiler/cmm/CmmBuildInfoTables.hs compiler/cmm/CmmPipeline.hs compiler/cmm/CmmCallConv.hs compiler/cmm/CmmCommonBlockElim.hs compiler/cmm/CmmContFlowOpt.hs compiler/cmm/CmmCvt.hs compiler/cmm/CmmExpr.hs compiler/cmm/CmmInfo.hs compiler/cmm/CmmLex.hs compiler/cmm/CmmLint.hs compiler/cmm/CmmLive.hs compiler/cmm/CmmMachOp.hs compiler/cmm/CmmNode.hs compiler/cmm/CmmOpt.hs compiler/cmm/CmmParse.hs compiler/cmm/CmmProcPoint.hs compiler/cmm/CmmRewriteAssignments.hs compiler/cmm/CmmSink.hs compiler/cmm/CmmType.hs compiler/cmm/CmmUtils.hs compiler/cmm/CmmLayoutStack.hs compiler/cmm/MkGraph.hs compiler/cmm/OldCmm.hs compiler/cmm/OldCmmLint.hs compiler/cmm/OldCmmUtils.hs compiler/cmm/OldPprCmm.hs compiler/nativeGen/PprBase.hs compiler/cmm/PprC.hs compiler/cmm/PprCmm.hs compiler/cmm/PprCmmDecl.hs compiler/cmm/PprCmmExpr.hs compiler/cmm/Bitmap.hs compiler/codeGen/CgBindery.lhs compiler/codeGen/CgCallConv.hs compiler/codeGen/CgCase.lhs compiler/codeGen/CgClosure.lhs compiler/codeGen/CgCon.lhs compiler/codeGen/CgExpr.lhs compiler/codeGen/CgExtCode.hs compiler/codeGen/CgForeignCall.hs compiler/codeGen/CgHeapery.lhs compiler/codeGen/CgHpc.hs compiler/codeGen/CgInfoTbls.hs compiler/codeGen/CgLetNoEscape.lhs compiler/codeGen/CgMonad.lhs compiler/codeGen/CgParallel.hs compiler/codeGen/CgPrimOp.hs compiler/codeGen/CgProf.hs compiler/codeGen/CgStackery.lhs compiler/codeGen/CgTailCall.lhs compiler/codeGen/CgTicky.hs compiler/codeGen/CgUtils.hs compiler/codeGen/StgCmm.hs compiler/codeGen/StgCmmBind.hs compiler/codeGen/StgCmmClosure.hs compiler/codeGen/StgCmmCon.hs compiler/codeGen/StgCmmEnv.hs compiler/codeGen/StgCmmExpr.hs compiler/codeGen/StgCmmForeign.hs compiler/codeGen/StgCmmGran.hs compiler/codeGen/StgCmmHeap.hs compiler/codeGen/StgCmmHpc.hs compiler/codeGen/StgCmmLayout.hs compiler/codeGen/StgCmmMonad.hs compiler/codeGen/StgCmmPrim.hs compiler/codeGen/StgCmmProf.hs compiler/codeGen/StgCmmTicky.hs compiler/codeGen/StgCmmUtils.hs compiler/codeGen/ClosureInfo.lhs compiler/codeGen/CodeGen.lhs compiler/cmm/SMRep.lhs compiler/coreSyn/CoreArity.lhs compiler/coreSyn/CoreFVs.lhs compiler/coreSyn/CoreLint.lhs compiler/coreSyn/CorePrep.lhs compiler/coreSyn/CoreSubst.lhs compiler/coreSyn/CoreSyn.lhs compiler/coreSyn/TrieMap.lhs compiler/coreSyn/CoreTidy.lhs compiler/coreSyn/CoreUnfold.lhs compiler/coreSyn/CoreUtils.lhs compiler/coreSyn/ExternalCore.lhs compiler/coreSyn/MkCore.lhs compiler/coreSyn/MkExternalCore.lhs compiler/coreSyn/PprCore.lhs compiler/coreSyn/PprExternalCore.lhs compiler/deSugar/Check.lhs compiler/deSugar/Coverage.lhs compiler/deSugar/Desugar.lhs compiler/deSugar/DsArrows.lhs compiler/deSugar/DsBinds.lhs compiler/deSugar/DsCCall.lhs compiler/deSugar/DsExpr.lhs compiler/deSugar/DsForeign.lhs compiler/deSugar/DsGRHSs.lhs compiler/deSugar/DsListComp.lhs compiler/deSugar/DsMonad.lhs compiler/deSugar/DsUtils.lhs compiler/deSugar/Match.lhs compiler/deSugar/MatchCon.lhs compiler/deSugar/MatchLit.lhs compiler/hsSyn/HsBinds.lhs compiler/hsSyn/HsDecls.lhs compiler/hsSyn/HsDoc.hs compiler/hsSyn/HsExpr.lhs compiler/hsSyn/HsImpExp.lhs compiler/hsSyn/HsLit.lhs compiler/hsSyn/HsPat.lhs compiler/hsSyn/HsSyn.lhs compiler/hsSyn/HsTypes.lhs compiler/hsSyn/HsUtils.lhs compiler/iface/BinIface.hs compiler/iface/BuildTyCl.lhs compiler/iface/IfaceEnv.lhs compiler/iface/IfaceSyn.lhs compiler/iface/IfaceType.lhs compiler/iface/LoadIface.lhs compiler/iface/MkIface.lhs compiler/iface/TcIface.lhs compiler/iface/FlagChecker.hs compiler/main/Annotations.hs compiler/main/BreakArray.hs compiler/main/CmdLineParser.hs compiler/main/CodeOutput.lhs compiler/stage1/build/Config.hs compiler/main/Constants.lhs compiler/main/DriverMkDepend.hs compiler/main/DriverPhases.hs compiler/main/DriverPipeline.hs compiler/main/DynFlags.hs compiler/main/ErrUtils.lhs compiler/main/Finder.lhs compiler/main/GHC.hs compiler/main/GhcMake.hs compiler/main/GhcPlugins.hs compiler/main/DynamicLoading.hs compiler/main/HeaderInfo.hs compiler/main/HscMain.hs compiler/main/HscStats.hs compiler/main/HscTypes.lhs compiler/main/InteractiveEval.hs compiler/main/PackageConfig.hs compiler/main/Packages.lhs compiler/main/PprTyThing.hs compiler/main/StaticFlags.hs compiler/main/StaticFlagParser.hs compiler/main/SysTools.lhs compiler/main/TidyPgm.lhs compiler/parser/Ctype.lhs compiler/parser/HaddockUtils.hs compiler/parser/LexCore.hs compiler/parser/Lexer.hs compiler/types/OptCoercion.lhs compiler/parser/Parser.hs compiler/parser/ParserCore.hs compiler/parser/ParserCoreUtils.hs compiler/parser/RdrHsSyn.lhs compiler/prelude/ForeignCall.lhs compiler/prelude/PrelInfo.lhs compiler/prelude/PrelNames.lhs compiler/prelude/PrelRules.lhs compiler/prelude/PrimOp.lhs compiler/prelude/TysPrim.lhs compiler/prelude/TysWiredIn.lhs compiler/profiling/CostCentre.lhs compiler/profiling/ProfInit.hs compiler/profiling/SCCfinal.lhs compiler/rename/RnBinds.lhs compiler/rename/RnEnv.lhs compiler/rename/RnExpr.lhs compiler/rename/RnHsDoc.hs compiler/rename/RnNames.lhs compiler/rename/RnPat.lhs compiler/rename/RnSource.lhs compiler/rename/RnTypes.lhs compiler/simplCore/CoreMonad.lhs compiler/simplCore/CSE.lhs compiler/simplCore/FloatIn.lhs compiler/simplCore/FloatOut.lhs compiler/simplCore/LiberateCase.lhs compiler/simplCore/OccurAnal.lhs compiler/simplCore/SAT.lhs compiler/simplCore/SetLevels.lhs compiler/simplCore/SimplCore.lhs compiler/simplCore/SimplEnv.lhs compiler/simplCore/SimplMonad.lhs compiler/simplCore/SimplUtils.lhs compiler/simplCore/Simplify.lhs compiler/simplStg/SRT.lhs compiler/simplStg/SimplStg.lhs compiler/simplStg/StgStats.lhs compiler/simplStg/UnariseStg.lhs compiler/specialise/Rules.lhs compiler/specialise/SpecConstr.lhs compiler/specialise/Specialise.lhs compiler/stgSyn/CoreToStg.lhs compiler/stgSyn/StgLint.lhs compiler/stgSyn/StgSyn.lhs compiler/stranal/DmdAnal.lhs compiler/stranal/WorkWrap.lhs compiler/stranal/WwLib.lhs compiler/typecheck/FamInst.lhs compiler/typecheck/Inst.lhs compiler/typecheck/TcAnnotations.lhs compiler/typecheck/TcArrows.lhs compiler/typecheck/TcBinds.lhs compiler/typecheck/TcClassDcl.lhs compiler/typecheck/TcDefaults.lhs compiler/typecheck/TcDeriv.lhs compiler/typecheck/TcEnv.lhs compiler/typecheck/TcExpr.lhs compiler/typecheck/TcForeign.lhs compiler/typecheck/TcGenDeriv.lhs compiler/typecheck/TcGenGenerics.lhs compiler/typecheck/TcHsSyn.lhs compiler/typecheck/TcHsType.lhs compiler/typecheck/TcInstDcls.lhs compiler/typecheck/TcMType.lhs compiler/typecheck/TcMatches.lhs compiler/typecheck/TcPat.lhs compiler/typecheck/TcRnDriver.lhs compiler/typecheck/TcRnMonad.lhs compiler/typecheck/TcRnTypes.lhs compiler/typecheck/TcRules.lhs compiler/typecheck/TcSimplify.lhs compiler/typecheck/TcErrors.lhs compiler/typecheck/TcTyClsDecls.lhs compiler/typecheck/TcTyDecls.lhs compiler/typecheck/TcType.lhs compiler/typecheck/TcEvidence.lhs compiler/typecheck/TcUnify.lhs compiler/typecheck/TcInteract.lhs compiler/typecheck/TcCanonical.lhs compiler/typecheck/TcSMonad.lhs compiler/types/Class.lhs compiler/types/Coercion.lhs compiler/types/FamInstEnv.lhs compiler/types/FunDeps.lhs compiler/types/InstEnv.lhs compiler/types/TyCon.lhs compiler/types/Kind.lhs compiler/types/Type.lhs compiler/types/TypeRep.lhs compiler/types/Unify.lhs compiler/utils/Bag.lhs compiler/utils/Binary.hs compiler/utils/BufWrite.hs compiler/utils/Digraph.lhs compiler/utils/Encoding.hs compiler/utils/FastBool.lhs compiler/utils/FastFunctions.lhs compiler/utils/FastMutInt.lhs compiler/utils/FastString.lhs compiler/utils/FastTypes.lhs compiler/stage1/build/Fingerprint.hs compiler/utils/FiniteMap.lhs compiler/utils/GraphBase.hs compiler/utils/GraphColor.hs compiler/utils/GraphOps.hs compiler/utils/GraphPpr.hs compiler/utils/IOEnv.hs compiler/utils/ListSetOps.lhs compiler/utils/Maybes.lhs compiler/utils/MonadUtils.hs compiler/utils/OrdList.lhs compiler/utils/Outputable.lhs compiler/utils/Pair.lhs compiler/utils/Panic.lhs compiler/utils/Pretty.lhs compiler/utils/Serialized.hs compiler/utils/State.hs compiler/utils/Stream.hs compiler/utils/StringBuffer.lhs compiler/utils/UniqFM.lhs compiler/utils/UniqSet.lhs compiler/utils/Util.lhs compiler/vectorise/Vectorise/Builtins/Base.hs compiler/vectorise/Vectorise/Builtins/Initialise.hs compiler/vectorise/Vectorise/Builtins.hs compiler/vectorise/Vectorise/Monad/Base.hs compiler/vectorise/Vectorise/Monad/Naming.hs compiler/vectorise/Vectorise/Monad/Local.hs compiler/vectorise/Vectorise/Monad/Global.hs compiler/vectorise/Vectorise/Monad/InstEnv.hs compiler/vectorise/Vectorise/Monad.hs compiler/vectorise/Vectorise/Utils/Base.hs compiler/vectorise/Vectorise/Utils/Closure.hs compiler/vectorise/Vectorise/Utils/Hoisting.hs compiler/vectorise/Vectorise/Utils/PADict.hs compiler/vectorise/Vectorise/Utils/Poly.hs compiler/vectorise/Vectorise/Utils.hs compiler/vectorise/Vectorise/Generic/Description.hs compiler/vectorise/Vectorise/Generic/PAMethods.hs compiler/vectorise/Vectorise/Generic/PADict.hs compiler/vectorise/Vectorise/Generic/PData.hs compiler/vectorise/Vectorise/Type/Env.hs compiler/vectorise/Vectorise/Type/Type.hs compiler/vectorise/Vectorise/Type/TyConDecl.hs compiler/vectorise/Vectorise/Type/Classify.hs compiler/vectorise/Vectorise/Convert.hs compiler/vectorise/Vectorise/Vect.hs compiler/vectorise/Vectorise/Var.hs compiler/vectorise/Vectorise/Env.hs compiler/vectorise/Vectorise/Exp.hs compiler/vectorise/Vectorise.hs compiler/cmm/Hoopl/Dataflow.hs compiler/cmm/Hoopl.hs compiler/nativeGen/AsmCodeGen.lhs compiler/nativeGen/TargetReg.hs compiler/nativeGen/NCGMonad.hs compiler/nativeGen/Instruction.hs compiler/nativeGen/Size.hs compiler/nativeGen/Reg.hs compiler/nativeGen/RegClass.hs compiler/nativeGen/PIC.hs compiler/utils/Platform.hs compiler/nativeGen/CPrim.hs compiler/nativeGen/X86/Regs.hs compiler/nativeGen/X86/RegInfo.hs compiler/nativeGen/X86/Instr.hs compiler/nativeGen/X86/Cond.hs compiler/nativeGen/X86/Ppr.hs compiler/nativeGen/X86/CodeGen.hs compiler/nativeGen/PPC/Regs.hs compiler/nativeGen/PPC/RegInfo.hs compiler/nativeGen/PPC/Instr.hs compiler/nativeGen/PPC/Cond.hs compiler/nativeGen/PPC/Ppr.hs compiler/nativeGen/PPC/CodeGen.hs compiler/nativeGen/SPARC/Base.hs compiler/nativeGen/SPARC/Regs.hs compiler/nativeGen/SPARC/RegPlate.hs compiler/nativeGen/SPARC/Imm.hs compiler/nativeGen/SPARC/AddrMode.hs compiler/nativeGen/SPARC/Cond.hs compiler/nativeGen/SPARC/Instr.hs compiler/nativeGen/SPARC/Stack.hs compiler/nativeGen/SPARC/ShortcutJump.hs compiler/nativeGen/SPARC/Ppr.hs compiler/nativeGen/SPARC/CodeGen.hs compiler/nativeGen/SPARC/CodeGen/Amode.hs compiler/nativeGen/SPARC/CodeGen/Base.hs compiler/nativeGen/SPARC/CodeGen/CondCode.hs compiler/nativeGen/SPARC/CodeGen/Gen32.hs compiler/nativeGen/SPARC/CodeGen/Gen64.hs compiler/nativeGen/SPARC/CodeGen/Sanity.hs compiler/nativeGen/SPARC/CodeGen/Expand.hs compiler/nativeGen/RegAlloc/Liveness.hs compiler/nativeGen/RegAlloc/Graph/Main.hs compiler/nativeGen/RegAlloc/Graph/Stats.hs compiler/nativeGen/RegAlloc/Graph/ArchBase.hs compiler/nativeGen/RegAlloc/Graph/ArchX86.hs compiler/nativeGen/RegAlloc/Graph/Coalesce.hs compiler/nativeGen/RegAlloc/Graph/Spill.hs compiler/nativeGen/RegAlloc/Graph/SpillClean.hs compiler/nativeGen/RegAlloc/Graph/SpillCost.hs compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs compiler/nativeGen/RegAlloc/Linear/Main.hs compiler/nativeGen/RegAlloc/Linear/JoinToTargets.hs compiler/nativeGen/RegAlloc/Linear/State.hs compiler/nativeGen/RegAlloc/Linear/Stats.hs compiler/nativeGen/RegAlloc/Linear/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/StackMap.hs compiler/nativeGen/RegAlloc/Linear/Base.hs compiler/nativeGen/RegAlloc/Linear/X86/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/PPC/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/SPARC/FreeRegs.hs echo "compiler_stage1_depfile_haskell_EXISTS = YES" >> compiler/stage1/build/.depend-v.haskell.tmp for dir in compiler/stage1/build/./ compiler/stage1/build/Hoopl/ compiler/stage1/build/Llvm/ compiler/stage1/build/LlvmCodeGen/ compiler/stage1/build/PPC/ compiler/stage1/build/RegAlloc/ compiler/stage1/build/RegAlloc/Graph/ compiler/stage1/build/RegAlloc/Linear/ compiler/stage1/build/RegAlloc/Linear/PPC/ compiler/stage1/build/RegAlloc/Linear/SPARC/ compiler/stage1/build/RegAlloc/Linear/X86/ compiler/stage1/build/SPARC/ compiler/stage1/build/SPARC/CodeGen/ compiler/stage1/build/Vectorise/ compiler/stage1/build/Vectorise/Builtins/ compiler/stage1/build/Vectorise/Generic/ compiler/stage1/build/Vectorise/Monad/ compiler/stage1/build/Vectorise/Type/ compiler/stage1/build/Vectorise/Utils/ compiler/stage1/build/X86/; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' compiler/stage1/build/.depend-v.haskell.tmp > compiler/stage1/build/.depend-v.haskell "rm" -f libraries/hoopl/dist-boot/build/.depend-v.c_asm.tmp echo "libraries/hoopl_dist-boot_depfile_c_asm_EXISTS = YES" >> libraries/hoopl/dist-boot/build/.depend-v.c_asm.tmp mv libraries/hoopl/dist-boot/build/.depend-v.c_asm.tmp libraries/hoopl/dist-boot/build/.depend-v.c_asm "rm" -f libraries/hoopl/dist-boot/build/.depend-v.haskell.tmp "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -M -dep-makefile libraries/hoopl/dist-boot/build/.depend-v.haskell.tmp -dep-suffix "" -include-pkg-deps -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -package-name hoopl-3.9.0.0 -hide-all-packages -i -ilibraries/hoopl/src -ilibraries/hoopl/dist-boot/build -ilibraries/hoopl/dist-boot/build/autogen -Ilibraries/hoopl/dist-boot/build -Ilibraries/hoopl/dist-boot/build/autogen -Ilibraries/hoopl/. -optP-include -optPlibraries/hoopl/dist-boot/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.5.1 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -no-user-package-db -rtsopts -odir libraries/hoopl/dist-boot/build -hidir libraries/hoopl/dist-boot/build -stubdir libraries/hoopl/dist-boot/build -hisuf hi -osuf o -hcsuf hc libraries/hoopl/src/Compiler/Hoopl.hs libraries/hoopl/src/Compiler/Hoopl/Internals.hs libraries/hoopl/src/Compiler/Hoopl/Wrappers.hs libraries/hoopl/src/Compiler/Hoopl/Passes/Dominator.hs libraries/hoopl/src/Compiler/Hoopl/Passes/DList.hs libraries/hoopl/src/Compiler/Hoopl/Checkpoint.hs libraries/hoopl/src/Compiler/Hoopl/Collections.hs libraries/hoopl/src/Compiler/Hoopl/Combinators.hs libraries/hoopl/src/Compiler/Hoopl/Dataflow.hs libraries/hoopl/src/Compiler/Hoopl/Debug.hs libraries/hoopl/src/Compiler/Hoopl/Block.hs libraries/hoopl/src/Compiler/Hoopl/Graph.hs libraries/hoopl/src/Compiler/Hoopl/Label.hs libraries/hoopl/src/Compiler/Hoopl/MkGraph.hs libraries/hoopl/src/Compiler/Hoopl/Fuel.hs libraries/hoopl/src/Compiler/Hoopl/Pointed.hs libraries/hoopl/src/Compiler/Hoopl/Shape.hs libraries/hoopl/src/Compiler/Hoopl/Show.hs libraries/hoopl/src/Compiler/Hoopl/Unique.hs libraries/hoopl/src/Compiler/Hoopl/XUtil.hs echo "libraries/hoopl_dist-boot_depfile_haskell_EXISTS = YES" >> libraries/hoopl/dist-boot/build/.depend-v.haskell.tmp for dir in libraries/hoopl/dist-boot/build/Compiler/ libraries/hoopl/dist-boot/build/Compiler/Hoopl/ libraries/hoopl/dist-boot/build/Compiler/Hoopl/Passes/; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' libraries/hoopl/dist-boot/build/.depend-v.haskell.tmp > libraries/hoopl/dist-boot/build/.depend-v.haskell "rm" -f libraries/bin-package-db/dist-boot/build/.depend-v.c_asm.tmp echo "libraries/bin-package-db_dist-boot_depfile_c_asm_EXISTS = YES" >> libraries/bin-package-db/dist-boot/build/.depend-v.c_asm.tmp mv libraries/bin-package-db/dist-boot/build/.depend-v.c_asm.tmp libraries/bin-package-db/dist-boot/build/.depend-v.c_asm "rm" -f libraries/bin-package-db/dist-boot/build/.depend-v.haskell.tmp "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -M -dep-makefile libraries/bin-package-db/dist-boot/build/.depend-v.haskell.tmp -dep-suffix "" -include-pkg-deps -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -package-name bin-package-db-0.0.0.0 -hide-all-packages -i -ilibraries/bin-package-db/. -ilibraries/bin-package-db/dist-boot/build -ilibraries/bin-package-db/dist-boot/build/autogen -Ilibraries/bin-package-db/dist-boot/build -Ilibraries/bin-package-db/dist-boot/build/autogen -Ilibraries/bin-package-db/. -optP-include -optPlibraries/bin-package-db/dist-boot/build/autogen/cabal_macros.h -package Cabal-1.16.0 -package base-4.7.0.0 -package binary-0.5.1.1 -XHaskell98 -XCPP -no-user-package-db -rtsopts -odir libraries/bin-package-db/dist-boot/build -hidir libraries/bin-package-db/dist-boot/build -stubdir libraries/bin-package-db/dist-boot/build -hisuf hi -osuf o -hcsuf hc libraries/bin-package-db/./Distribution/InstalledPackageInfo/Binary.hs echo "libraries/bin-package-db_dist-boot_depfile_haskell_EXISTS = YES" >> libraries/bin-package-db/dist-boot/build/.depend-v.haskell.tmp for dir in libraries/bin-package-db/dist-boot/build/Distribution/InstalledPackageInfo/; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' libraries/bin-package-db/dist-boot/build/.depend-v.haskell.tmp > libraries/bin-package-db/dist-boot/build/.depend-v.haskell "rm" -f libraries/binary/dist-boot/build/.depend-v.c_asm.tmp echo "libraries/binary_dist-boot_depfile_c_asm_EXISTS = YES" >> libraries/binary/dist-boot/build/.depend-v.c_asm.tmp mv libraries/binary/dist-boot/build/.depend-v.c_asm.tmp libraries/binary/dist-boot/build/.depend-v.c_asm "rm" -f libraries/binary/dist-boot/build/.depend-v.haskell.tmp "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -M -dep-makefile libraries/binary/dist-boot/build/.depend-v.haskell.tmp -dep-suffix "" -include-pkg-deps -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -package-name binary-0.5.1.1 -hide-all-packages -i -ilibraries/binary/src -ilibraries/binary/dist-boot/build -ilibraries/binary/dist-boot/build/autogen -Ilibraries/binary/dist-boot/build -Ilibraries/binary/dist-boot/build/autogen -Ilibraries/binary/. -optP-DAPPLICATIVE_IN_BASE -optP-include -optPlibraries/binary/dist-boot/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -O2 -Wall -fliberate-case-threshold=1000 -XHaskell98 -XCPP -XFlexibleContexts -no-user-package-db -rtsopts -odir libraries/binary/dist-boot/build -hidir libraries/binary/dist-boot/build -stubdir libraries/binary/dist-boot/build -hisuf hi -osuf o -hcsuf hc libraries/binary/src/Data/Binary.hs libraries/binary/src/Data/Binary/Put.hs libraries/binary/src/Data/Binary/Get.hs libraries/binary/src/Data/Binary/Builder.hs libraries/binary/src/Data/Binary/Builder/Internal.hs libraries/binary/src/Data/Binary/Builder/Base.hs echo "libraries/binary_dist-boot_depfile_haskell_EXISTS = YES" >> libraries/binary/dist-boot/build/.depend-v.haskell.tmp for dir in libraries/binary/dist-boot/build/Data/ libraries/binary/dist-boot/build/Data/Binary/ libraries/binary/dist-boot/build/Data/Binary/Builder/; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' libraries/binary/dist-boot/build/.depend-v.haskell.tmp > libraries/binary/dist-boot/build/.depend-v.haskell "rm" -f libraries/Cabal/Cabal/dist-boot/build/.depend-v.c_asm.tmp echo "libraries/Cabal/Cabal_dist-boot_depfile_c_asm_EXISTS = YES" >> libraries/Cabal/Cabal/dist-boot/build/.depend-v.c_asm.tmp mv libraries/Cabal/Cabal/dist-boot/build/.depend-v.c_asm.tmp libraries/Cabal/Cabal/dist-boot/build/.depend-v.c_asm "rm" -f libraries/Cabal/Cabal/dist-boot/build/.depend-v.haskell.tmp "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -M -dep-makefile libraries/Cabal/Cabal/dist-boot/build/.depend-v.haskell.tmp -dep-suffix "" -include-pkg-deps -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -package-name Cabal-1.16.0 -hide-all-packages -i -ilibraries/Cabal/Cabal/. -ilibraries/Cabal/Cabal/dist-boot/build -ilibraries/Cabal/Cabal/dist-boot/build/autogen -Ilibraries/Cabal/Cabal/dist-boot/build -Ilibraries/Cabal/Cabal/dist-boot/build/autogen -Ilibraries/Cabal/Cabal/. -optP-include -optPlibraries/Cabal/Cabal/dist-boot/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package old-time-1.1.0.2 -package pretty-1.1.1.1 -package process-1.2.0.0 -package unix-2.7.0.0 -fwarn-tabs -Wall -fno-ignore-asserts -XHaskell98 -XCPP -no-user-package-db -rtsopts -odir libraries/Cabal/Cabal/dist-boot/build -hidir libraries/Cabal/Cabal/dist-boot/build -stubdir libraries/Cabal/Cabal/dist-boot/build -hisuf hi -osuf o -hcsuf hc libraries/Cabal/Cabal/./Distribution/Compiler.hs libraries/Cabal/Cabal/./Distribution/InstalledPackageInfo.hs libraries/Cabal/Cabal/./Distribution/License.hs libraries/Cabal/Cabal/./Distribution/Make.hs libraries/Cabal/Cabal/./Distribution/ModuleName.hs libraries/Cabal/Cabal/./Distribution/Package.hs libraries/Cabal/Cabal/./Distribution/PackageDescription.hs libraries/Cabal/Cabal/./Distribution/PackageDescription/Configuration.hs libraries/Cabal/Cabal/./Distribution/PackageDescription/Parse.hs libraries/Cabal/Cabal/./Distribution/PackageDescription/Check.hs libraries/Cabal/Cabal/./Distribution/PackageDescription/PrettyPrint.hs libraries/Cabal/Cabal/./Distribution/ParseUtils.hs libraries/Cabal/Cabal/./Distribution/ReadE.hs libraries/Cabal/Cabal/./Distribution/Simple.hs libraries/Cabal/Cabal/./Distribution/Simple/Build.hs libraries/Cabal/Cabal/./Distribution/Simple/Build/Macros.hs libraries/Cabal/Cabal/./Distribution/Simple/Build/PathsModule.hs libraries/Cabal/Cabal/./Distribution/Simple/BuildPaths.hs libraries/Cabal/Cabal/./Distribution/Simple/Bench.hs libraries/Cabal/Cabal/./Distribution/Simple/Command.hs libraries/Cabal/Cabal/./Distribution/Simple/Compiler.hs libraries/Cabal/Cabal/./Distribution/Simple/Configure.hs libraries/Cabal/Cabal/./Distribution/Simple/GHC.hs libraries/Cabal/Cabal/./Distribution/Simple/LHC.hs libraries/Cabal/Cabal/./Distribution/Simple/Haddock.hs libraries/Cabal/Cabal/./Distribution/Simple/Hpc.hs libraries/Cabal/Cabal/./Distribution/Simple/Hugs.hs libraries/Cabal/Cabal/./Distribution/Simple/Install.hs libraries/Cabal/Cabal/./Distribution/Simple/InstallDirs.hs libraries/Cabal/Cabal/./Distribution/Simple/JHC.hs libraries/Cabal/Cabal/./Distribution/Simple/LocalBuildInfo.hs libraries/Cabal/Cabal/./Distribution/Simple/NHC.hs libraries/Cabal/Cabal/./Distribution/Simple/PackageIndex.hs libraries/Cabal/Cabal/./Distribution/Simple/PreProcess.hs libraries/Cabal/Cabal/./Distribution/Simple/PreProcess/Unlit.hs libraries/Cabal/Cabal/./Distribution/Simple/Program.hs libraries/Cabal/Cabal/./Distribution/Simple/Program/Ar.hs libraries/Cabal/Cabal/./Distribution/Simple/Program/Builtin.hs libraries/Cabal/Cabal/./Distribution/Simple/Program/Db.hs libraries/Cabal/Cabal/./Distribution/Simple/Program/GHC.hs libraries/Cabal/Cabal/./Distribution/Simple/Program/HcPkg.hs libraries/Cabal/Cabal/./Distribution/Simple/Program/Hpc.hs libraries/Cabal/Cabal/./Distribution/Simple/Program/Ld.hs libraries/Cabal/Cabal/./Distribution/Simple/Program/Run.hs libraries/Cabal/Cabal/./Distribution/Simple/Program/Script.hs libraries/Cabal/Cabal/./Distribution/Simple/Program/Types.hs libraries/Cabal/Cabal/./Distribution/Simple/Register.hs libraries/Cabal/Cabal/./Distribution/Simple/Setup.hs libraries/Cabal/Cabal/./Distribution/Simple/SrcDist.hs libraries/Cabal/Cabal/./Distribution/Simple/Test.hs libraries/Cabal/Cabal/./Distribution/Simple/UHC.hs libraries/Cabal/Cabal/./Distribution/Simple/UserHooks.hs libraries/Cabal/Cabal/./Distribution/Simple/Utils.hs libraries/Cabal/Cabal/./Distribution/System.hs libraries/Cabal/Cabal/./Distribution/TestSuite.hs libraries/Cabal/Cabal/./Distribution/Text.hs libraries/Cabal/Cabal/./Distribution/Verbosity.hs libraries/Cabal/Cabal/./Distribution/Version.hs libraries/Cabal/Cabal/./Distribution/Compat/ReadP.hs libraries/Cabal/Cabal/./Language/Haskell/Extension.hs libraries/Cabal/Cabal/./Distribution/GetOpt.hs libraries/Cabal/Cabal/./Distribution/Compat/Exception.hs libraries/Cabal/Cabal/./Distribution/Compat/CopyFile.hs libraries/Cabal/Cabal/./Distribution/Compat/TempFile.hs libraries/Cabal/Cabal/./Distribution/Simple/GHC/IPI641.hs libraries/Cabal/Cabal/./Distribution/Simple/GHC/IPI642.hs libraries/Cabal/Cabal/dist-boot/build/autogen/Paths_Cabal.hs echo "libraries/Cabal/Cabal_dist-boot_depfile_haskell_EXISTS = YES" >> libraries/Cabal/Cabal/dist-boot/build/.depend-v.haskell.tmp for dir in libraries/Cabal/Cabal/dist-boot/build/./ libraries/Cabal/Cabal/dist-boot/build/Distribution/ libraries/Cabal/Cabal/dist-boot/build/Distribution/Compat/ libraries/Cabal/Cabal/dist-boot/build/Distribution/PackageDescription/ libraries/Cabal/Cabal/dist-boot/build/Distribution/Simple/ libraries/Cabal/Cabal/dist-boot/build/Distribution/Simple/Build/ libraries/Cabal/Cabal/dist-boot/build/Distribution/Simple/GHC/ libraries/Cabal/Cabal/dist-boot/build/Distribution/Simple/PreProcess/ libraries/Cabal/Cabal/dist-boot/build/Distribution/Simple/Program/ libraries/Cabal/Cabal/dist-boot/build/Language/Haskell/; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' libraries/Cabal/Cabal/dist-boot/build/.depend-v.haskell.tmp > libraries/Cabal/Cabal/dist-boot/build/.depend-v.haskell "rm" -f libraries/hpc/dist-boot/build/.depend-v.c_asm.tmp echo "libraries/hpc_dist-boot_depfile_c_asm_EXISTS = YES" >> libraries/hpc/dist-boot/build/.depend-v.c_asm.tmp mv libraries/hpc/dist-boot/build/.depend-v.c_asm.tmp libraries/hpc/dist-boot/build/.depend-v.c_asm "inplace/bin/mkdirhier" libraries/hpc/dist-boot/build/Trace/Hpc//. "inplace/bin/hsc2hs" --cc=/usr/bin/gcc --ld=/usr/bin/gcc --cross-safe --cflag=-fno-stack-protector --cflag=-D__GLASGOW_HASKELL__=708 --cflag=-Darm64_HOST_ARCH=1 --cflag=-Dlinux_HOST_OS=1 '--cflag=-fno-stack-protector' '--cflag=-Ilibraries/hpc/.' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/directory/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/unix/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/time/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/containers/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/bytestring/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/libraries/base/include' '--cflag=-isystem/home/cjwatson/ghc-aarch64/rts/dist/build' '--cflag=-isystem/home/cjwatson/ghc-aarch64/includes' '--cflag=-isystem/home/cjwatson/ghc-aarch64/includes/dist-derivedconstants/header' '--lflag=-Wl,--hash-size=31' '--lflag=-Wl,--reduce-memory-overheads' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/directory/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/unix/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/time/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/old-locale/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/filepath/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/containers/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/bytestring/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/deepseq/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/array/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/base/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/integer-simple/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/libraries/ghc-prim/dist-install/build' '--lflag=-L/home/cjwatson/ghc-aarch64/rts/dist/build' '--lflag=-lrt' '--lflag=-lutil' '--lflag=-ldl' '--lflag=-lpthread' '--lflag=-lm' '--lflag=-lrt' '--lflag=-ldl' --cflag=-Ilibraries/hpc/dist-boot/build/autogen --cflag=-include --cflag=libraries/hpc/dist-boot/build/autogen/cabal_macros.h libraries/hpc/./Trace/Hpc/Reflect.hsc -o libraries/hpc/dist-boot/build/Trace/Hpc/Reflect.hs "rm" -f libraries/hpc/dist-boot/build/.depend-v.haskell.tmp "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -M -dep-makefile libraries/hpc/dist-boot/build/.depend-v.haskell.tmp -dep-suffix "" -include-pkg-deps -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -package-name hpc-0.6.0.0 -hide-all-packages -i -ilibraries/hpc/. -ilibraries/hpc/dist-boot/build -ilibraries/hpc/dist-boot/build/autogen -Ilibraries/hpc/dist-boot/build -Ilibraries/hpc/dist-boot/build/autogen -Ilibraries/hpc/. -optP-include -optPlibraries/hpc/dist-boot/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.5.1 -package directory-1.2.0.2 -package time-1.4.2 -Wall -XHaskell98 -XCPP -no-user-package-db -rtsopts -odir libraries/hpc/dist-boot/build -hidir libraries/hpc/dist-boot/build -stubdir libraries/hpc/dist-boot/build -hisuf hi -osuf o -hcsuf hc libraries/hpc/./Trace/Hpc/Util.hs libraries/hpc/./Trace/Hpc/Mix.hs libraries/hpc/./Trace/Hpc/Tix.hs libraries/hpc/dist-boot/build/Trace/Hpc/Reflect.hs echo "libraries/hpc_dist-boot_depfile_haskell_EXISTS = YES" >> libraries/hpc/dist-boot/build/.depend-v.haskell.tmp for dir in libraries/hpc/dist-boot/build/Trace/Hpc/; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' libraries/hpc/dist-boot/build/.depend-v.haskell.tmp > libraries/hpc/dist-boot/build/.depend-v.haskell "inplace/bin/mkdirhier" utils/genapply/dist/build//. "rm" -f utils/genapply/dist/build/.depend.c_asm.tmp echo "utils/genapply_dist_depfile_c_asm_EXISTS = YES" >> utils/genapply/dist/build/.depend.c_asm.tmp mv utils/genapply/dist/build/.depend.c_asm.tmp utils/genapply/dist/build/.depend.c_asm "rm" -f utils/genapply/dist/build/.depend.haskell.tmp "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -M -dep-makefile utils/genapply/dist/build/.depend.haskell.tmp -dep-suffix "" -include-pkg-deps -H32m -O -lffi -optl-pthread -package pretty -DNO_REGS -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir utils/genapply/dist/build -hisuf hi -osuf o -hcsuf hc utils/genapply/./GenApply.hs echo "utils/genapply_dist_depfile_haskell_EXISTS = YES" >> utils/genapply/dist/build/.depend.haskell.tmp for dir in utils/genapply/dist/build/./; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' utils/genapply/dist/build/.depend.haskell.tmp > utils/genapply/dist/build/.depend.haskell "rm" -f includes/dist-ghcconstants/build/.depend.c_asm.tmp /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -DNOSMP -DGEN_HASKELL -MM includes/mkDerivedConstants.c -MF includes/dist-ghcconstants/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|includes/|" -e "1s|includes/|includes/dist-ghcconstants/build/|" -e "1s|dist-ghcconstants/build/dist-ghcconstants/build|dist-ghcconstants/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" includes/dist-ghcconstants/build/.depend.c_asm.bit >> includes/dist-ghcconstants/build/.depend.c_asm.tmp && true "rm" -f includes/dist-ghcconstants/build/.depend.c_asm.bit echo "includes_dist-ghcconstants_depfile_c_asm_EXISTS = YES" >> includes/dist-ghcconstants/build/.depend.c_asm.tmp mv includes/dist-ghcconstants/build/.depend.c_asm.tmp includes/dist-ghcconstants/build/.depend.c_asm "rm" -f includes/dist-derivedconstants/build/.depend.c_asm.tmp /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -DNOSMP -MM includes/mkDerivedConstants.c -MF includes/dist-derivedconstants/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|includes/|" -e "1s|includes/|includes/dist-derivedconstants/build/|" -e "1s|dist-derivedconstants/build/dist-derivedconstants/build|dist-derivedconstants/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" includes/dist-derivedconstants/build/.depend.c_asm.bit >> includes/dist-derivedconstants/build/.depend.c_asm.tmp && true "rm" -f includes/dist-derivedconstants/build/.depend.c_asm.bit echo "includes_dist-derivedconstants_depfile_c_asm_EXISTS = YES" >> includes/dist-derivedconstants/build/.depend.c_asm.tmp mv includes/dist-derivedconstants/build/.depend.c_asm.tmp includes/dist-derivedconstants/build/.depend.c_asm "inplace/bin/mkdirhier" utils/hp2ps/dist/build//. "rm" -f utils/hp2ps/dist/build/.depend.c_asm.tmp /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/AreaBelow.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/Curves.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/Error.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/Main.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/Reorder.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/TopTwenty.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/AuxFile.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/Deviation.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/HpFile.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/Marks.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/Scale.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/TraceElement.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/Axes.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/Dimensions.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/Key.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/PsFile.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/Shade.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -MM utils/hp2ps/Utilities.c -MF utils/hp2ps/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/hp2ps/|" -e "1s|utils/hp2ps/|utils/hp2ps/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/hp2ps/dist/build/.depend.c_asm.bit >> utils/hp2ps/dist/build/.depend.c_asm.tmp && true "rm" -f utils/hp2ps/dist/build/.depend.c_asm.bit echo "utils/hp2ps_dist_depfile_c_asm_EXISTS = YES" >> utils/hp2ps/dist/build/.depend.c_asm.tmp mv utils/hp2ps/dist/build/.depend.c_asm.tmp utils/hp2ps/dist/build/.depend.c_asm "inplace/bin/mkdirhier" utils/unlit/dist/build//. "rm" -f utils/unlit/dist/build/.depend.c_asm.tmp /usr/bin/gcc -E -D_FORTIFY_SOURCE=2 -fno-stack-protector -MM utils/unlit/unlit.c -MF utils/unlit/dist/build/.depend.c_asm.bit sed -e 's|\\|/|g' -e 's| /$| \\|' -e "1s|\.o|\.o|" -e "1s|^|utils/unlit/|" -e "1s|utils/unlit/|utils/unlit/dist/build/|" -e "1s|dist/build/dist/build|dist/build|g" -e "s|/home/cjwatson/ghc-7.6.3/||g" utils/unlit/dist/build/.depend.c_asm.bit >> utils/unlit/dist/build/.depend.c_asm.tmp && true "rm" -f utils/unlit/dist/build/.depend.c_asm.bit echo "utils/unlit_dist_depfile_c_asm_EXISTS = YES" >> utils/unlit/dist/build/.depend.c_asm.tmp mv utils/unlit/dist/build/.depend.c_asm.tmp utils/unlit/dist/build/.depend.c_asm "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -ighc/. -ighc/stage1/build -ighc/stage1/build/autogen -Ighc/stage1/build -Ighc/stage1/build/autogen -optP-include -optPghc/stage1/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package ghc-7.8.0.20140331 -package process-1.2.0.0 -package unix-2.7.0.0 -Wall -XHaskell98 -XNondecreasingIndentation -XCPP -XPatternGuards -no-user-package-db -rtsopts -odir ghc/stage1/build -hidir ghc/stage1/build -stubdir ghc/stage1/build -hisuf hi -osuf o -hcsuf hc -c ghc/./Main.hs -o ghc/stage1/build/Main.o Failed to load interface for `Distribution.InstalledPackageInfo.Binary' There are files missing in the `bin-package-db-0.0.0.0' package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[2]: *** [ghc/stage1/build/Main.o] Error 1 make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/cjwatson/ghc-7.6.3' make: *** [build-stamp] Error 2 ]0;(t-cjwatson)cjwatson at am1: ~/ghc-7.6.3(t-cjwatson)cjwatson at am1:~/ghc-7.6.3$ exit Script done on Fri May 8 16:37:33 2150 From haskell at nand.wakku.to Thu Apr 3 00:40:30 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Thu, 3 Apr 2014 02:40:30 +0200 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> <20140402070830.GA3380@weber> <20140402223236.GA30194@nanodesu.talocan.mine.nu> Message-ID: <20140403024030.GA31361@nanodesu.talocan.mine.nu> On Wed, 2 Apr 2014 14:25:55 -0700, John Lato wrote: > On Apr 2, 2014 4:32 PM, "Niklas Haas" wrote: > > > > On Wed, 2 Apr 2014 09:51:46 -0400, Edward Kmett wrote: > > > We're not storing the instance as a slot in the constructor, so this > isn't. > > > > > > data Foo a where > > > Foo :: Seq a => Int -> a -> Foo a > > > > > > or equivalently > > > > > > data Foo a = Seq a => Foo !Int !a > > > > Why not? Say we define Seq to something like > > > > > type family Seq (a :: *) :: Constraint where > > > Seq (a -> b) = 1 ~ 0 > > > Seq t = () > > > > What would be the drawback in this scenario? > > I think that would be acceptable if we posit the existence of a valid Seq a > dictionary. I think that would be possible for all builtin types and > anything defined via data. But what about e.g. > > newtype F = F (forall x. Show x => x-> String) Oh, fair point; this particular F apparently doesn't break it but if you remove the Show x constraint, it does. Actually, is that a bug in GHC? > ? newtype F = F (forall x. Show x => x -> String) > ? F undefined `seq` () > () > ? undefined `seq` () > *** Exception: Prelude.undefined I'm not sure how to interpret this output. From dan.doel at gmail.com Thu Apr 3 01:18:04 2014 From: dan.doel at gmail.com (Dan Doel) Date: Wed, 2 Apr 2014 21:18:04 -0400 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: <20140403024030.GA31361@nanodesu.talocan.mine.nu> References: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> <20140402070830.GA3380@weber> <20140402223236.GA30194@nanodesu.talocan.mine.nu> <20140403024030.GA31361@nanodesu.talocan.mine.nu> Message-ID: On Wed, Apr 2, 2014 at 8:40 PM, Niklas Haas wrote: > Oh, fair point; this particular F apparently doesn't break it but if you > remove the Show x constraint, it does. > > Actually, is that a bug in GHC? > > > ? newtype F = F (forall x. Show x => x -> String) > > ? F undefined `seq` () > > () > > ? undefined `seq` () > > *** Exception: Prelude.undefined > > I'm not sure how to interpret this output. > This is pretty weird, but here's what I think is going on: F requires an argument of type forall x. Show x => x -> String. This requires abstracting over a dictionary for Show x. So at the core level, this gets expanded to something like: \showd -> undefined which is non-bottom. Even if you annotate undefined with the above type, You'll probably end up with: (\showd -> undefined) defaultd `seq` () after GHC reinstantiates the polymorphic type and then defaults, which will be undefined. So you can only observe this by wrapping the polymorphic expression in a newtype, to keep it abstracted. I don't know that this qualifies as a bug, but it's definitely pretty subtle behavior. -- Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.doel at gmail.com Thu Apr 3 01:40:30 2014 From: dan.doel at gmail.com (Dan Doel) Date: Wed, 2 Apr 2014 21:40:30 -0400 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> <20140402070830.GA3380@weber> <20140402223236.GA30194@nanodesu.talocan.mine.nu> <20140403024030.GA31361@nanodesu.talocan.mine.nu> Message-ID: Also, with -XImpredicativeTypes: > (seq :: (forall x. Show x => x) -> b -> b) undefined () () On Wed, Apr 2, 2014 at 9:18 PM, Dan Doel wrote: > On Wed, Apr 2, 2014 at 8:40 PM, Niklas Haas wrote: > >> Oh, fair point; this particular F apparently doesn't break it but if you >> remove the Show x constraint, it does. >> >> Actually, is that a bug in GHC? >> >> > ? newtype F = F (forall x. Show x => x -> String) >> > ? F undefined `seq` () >> > () >> > ? undefined `seq` () >> > *** Exception: Prelude.undefined >> >> I'm not sure how to interpret this output. >> > > This is pretty weird, but here's what I think is going on: > > F requires an argument of type forall x. Show x => x -> String. This > requires abstracting over a dictionary for Show x. So at the core level, > this gets expanded to something like: > > \showd -> undefined > > which is non-bottom. > > Even if you annotate undefined with the above type, You'll probably end up > with: > > (\showd -> undefined) defaultd `seq` () > > after GHC reinstantiates the polymorphic type and then defaults, which > will be undefined. So you can only observe this by wrapping the polymorphic > expression in a newtype, to keep it abstracted. > > I don't know that this qualifies as a bug, but it's definitely pretty > subtle behavior. > > -- Dan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dstcruz at gmail.com Thu Apr 3 04:28:37 2014 From: dstcruz at gmail.com (Daniel Santa Cruz) Date: Thu, 3 Apr 2014 00:28:37 -0400 Subject: [Haskell-cafe] Haskell Weekly News: Issue 289 Message-ID: Welcome to issue 289 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from March 1 to 31, 2014 So... where have I been? My wife and I recently welcomed into the world our new baby, and as some of you have already experienced, I was doing good getting *some* sleep at night. Life has slowly started to get back to a more predictable rhythm, and I am sure glad to be back doing this. For a while there I thought that any project of mine before bambina was going to have to be put into permament hold, but things are getting very manageble now. Sorry for the abscense! I was somewhat pleased to see that some in -cafe wondered if this was coming back... this one is for you! Some have mentioned that they wish to see more of the "reviews" that HWN used to have of blog entries, and/or email chains in the different mailing lists. I understand that dessire. I'm probably going to need some extra hands to write those, if there are to be back. Maybe we can start with something "lighter", a la tl;dr. I'm stil trying to work out how we'd do that exacly. I'll keep you all posted. Anyway, enough rambling. Quotes of the Week * acowley: I will push machines-concurrent to hackage one fine day edwardk: not concurrent-machines ? acowley: Man, I walked right into that bike shed * malc: I have a coworker who constantly reads haskell stuff at work, nudged him towards the lens talk, that should push him towards actually doing work at work. * Fuuzetsu: I know someone who pulls in Lens just for & and ?? * Eduard_Munteanu: Don't put your money in monads, you can never get it back. :P Top Reddit Stories * Haskell for all: Introductions to advanced Haskell topics Domain: haskellforall.com, Score: 121, Comments: 23 On Reddit: [1] http://goo.gl/M6ZL9f Original: [2] http://goo.gl/YEKyCc * GHC 7.8.1 RC2 released Domain: well-typed.com, Score: 99, Comments: 36 On Reddit: [3] http://goo.gl/jxlLQl Original: [4] http://goo.gl/05xnqX * Book review: Parallel and Concurrent Programming in Haskell Domain: serpentine.com, Score: 87, Comments: 17 On Reddit: [5] http://goo.gl/BfWSWC Original: [6] http://goo.gl/nDe2UG * The Haskell Cast #6 - Gabriel Gonzalez and Michael Snoyman on Pipes and Conduit Domain: haskellcast.com, Score: 83, Comments: 13 On Reddit: [7] http://goo.gl/PwL2aV Original: [8] http://goo.gl/hwemr6 * Performance in Haskell from a noob's perspective Domain: self.haskell, Score: 74, Comments: 111 On Reddit: [9] http://goo.gl/IuT0uJ Original: [10] http://goo.gl/IuT0uJ * New Haddock -- a visual guide to changes Domain: fuuzetsu.co.uk, Score: 72, Comments: 13 On Reddit: [11] http://goo.gl/KWJSEh Original: [12] http://goo.gl/IXzESN * Full-time position available: computer scientist to create data types for scientific computing, in Haskell. Location: anywhere (telecommute). Domain: self.haskell, Score: 67, Comments: 17 On Reddit: [13] http://goo.gl/Z8y9py Original: [14] http://goo.gl/Z8y9py * Haskell Type Classes Cheatsheet Domain: fundeps.com, Score: 62, Comments: 21 On Reddit: [15] http://goo.gl/oAWk4C Original: [16] http://goo.gl/SqHbro * Malicious link in haskell.org docs for 6 years, 6 months, 6 days Domain: self.haskell, Score: 61, Comments: 6 On Reddit: [17] http://goo.gl/V5y3hk Original: [18] http://goo.gl/V5y3hk * What's your "killer app" for your scientific/statistical programming environment? Domain: self.haskell, Score: 57, Comments: 92 On Reddit: [19] http://goo.gl/jfbwdj Original: [20] http://goo.gl/jfbwdj * Find out the type of an expression/function with typed holes Domain: ro-che.info, Score: 56, Comments: 5 On Reddit: [21] http://goo.gl/hcjX1v Original: [22] http://goo.gl/TWLT5R * Elm 0.12 - making interactive UI elements easy and pure Domain: elm-lang.org, Score: 56, Comments: 5 On Reddit: [23] http://goo.gl/SRoog7 Original: [24] http://goo.gl/7FoFAz * QuickCheck 2.7 released Domain: hackage.haskell.org, Score: 55, Comments: 7 On Reddit: [25] http://goo.gl/RN66bR Original: [26] http://goo.gl/3S38Uz Top StackOverflow Questions * Why is Haskell unable to read "7e7" but able to read "7a7"? votes: 42, answers: 3 Read on SO: [27] http://goo.gl/ZI8qm8 * Strange GHCi lazy evaluation votes: 17, answers: 1 Read on SO: [28] http://goo.gl/aoHvVp * Fast, branchless unsigned int absolute difference votes: 16, answers: 3 Read on SO: [29] http://goo.gl/TT3Oxi * How can I write human-language units as postfixes in Haskell, like `3 seconds`? votes: 15, answers: 2 Read on SO: [30] http://goo.gl/6MJk5C * Running Haskell on Xeon-Phi votes: 14, answers: 1 Read on SO: [31] http://goo.gl/QEIayp Until next time, [32]+Daniel Santa Cruz References 1. http://www.haskellforall.com/2014/03/introductions-to-advanced-haskell-topics.html 2. http://www.reddit.com/r/haskell/comments/21bcb5/haskell_for_all_introductions_to_advanced_haskell/ 3. http://www.well-typed.com/blog/87 4. http://www.reddit.com/r/haskell/comments/1zgaln/ghc_781_rc2_released/ 5. http://www.serpentine.com/blog/2014/03/18/book-review-parallel-and-concurrent-programming-in-haskell/ 6. http://www.reddit.com/r/haskell/comments/20sdt4/book_review_parallel_and_concurrent_programming/ 7. http://www.haskellcast.com/episode/006-gabriel-gonzalez-and-michael-snoyman-on-pipes-and-conduit 8. http://www.reddit.com/r/haskell/comments/1zfo9g/the_haskell_cast_6_gabriel_gonzalez_and_michael/ 9. http://www.reddit.com/r/haskell/comments/21g6uo/performance_in_haskell_from_a_noobs_perspective/ 10. http://www.reddit.com/r/haskell/comments/21g6uo/performance_in_haskell_from_a_noobs_perspective/ 11. http://fuuzetsu.co.uk/blog/posts/2014-03-24-New-Haddock-released%21-A-visual-guide-to-changes.html 12. http://www.reddit.com/r/haskell/comments/218rov/new_haddock_a_visual_guide_to_changes/ 13. http://www.reddit.com/r/haskell/comments/202pvl/fulltime_position_available_computer_scientist_to/ 14. http://www.reddit.com/r/haskell/comments/202pvl/fulltime_position_available_computer_scientist_to/ 15. http://fundeps.com/posts/cheatsheets/2014-03-04-cheat-sheets/ 16. http://www.reddit.com/r/haskell/comments/1zn3h9/haskell_type_classes_cheatsheet/ 17. http://www.reddit.com/r/haskell/comments/21959m/malicious_link_in_haskellorg_docs_for_6_years_6/ 18. http://www.reddit.com/r/haskell/comments/21959m/malicious_link_in_haskellorg_docs_for_6_years_6/ 19. http://www.reddit.com/r/haskell/comments/1zowv1/whats_your_killer_app_for_your/ 20. http://www.reddit.com/r/haskell/comments/1zowv1/whats_your_killer_app_for_your/ 21. http://ro-che.info/articles/2014-03-13-type-of-local-function.html 22. http://www.reddit.com/r/haskell/comments/20bixd/find_out_the_type_of_an_expressionfunction_with/ 23. http://elm-lang.org/blog/announce/0.12.elm 24. http://www.reddit.com/r/haskell/comments/218isr/elm_012_making_interactive_ui_elements_easy_and/ 25. http://hackage.haskell.org/package/QuickCheck-2.7.1/changelog 26. http://www.reddit.com/r/haskell/comments/213da9/quickcheck_27_released/ 27. http://stackoverflow.com/questions/22689122/why-is-haskell-unable-to-read-7e7-but-able-to-read-7a7 28. http://stackoverflow.com/questions/22491700/strange-ghci-lazy-evaluation 29. http://stackoverflow.com/questions/22445019/fast-branchless-unsigned-int-absolute-difference 30. http://stackoverflow.com/questions/22109333/how-can-i-write-human-language-units-as-postfixes-in-haskell-like-3-seconds 31. http://stackoverflow.com/questions/22253311/running-haskell-on-xeon-phi 32. https://plus.google.com/105107667630152149014/about -------------- next part -------------- An HTML attachment was scrubbed... URL: From vigalchin at gmail.com Thu Apr 3 06:57:44 2014 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Thu, 3 Apr 2014 01:57:44 -0500 Subject: [Haskell-cafe] I guess this is "Play it again Sam"?? If so, sorry ... Message-ID: http://www.infoq.com/presentations/haskell-newsroom-nyt -------------- next part -------------- An HTML attachment was scrubbed... URL: From evohunz at gmail.com Thu Apr 3 11:22:33 2014 From: evohunz at gmail.com (Thiago Negri) Date: Thu, 3 Apr 2014 08:22:33 -0300 Subject: [Haskell-cafe] [Haskell] Haskell Weekly News: Issue 289 In-Reply-To: References: Message-ID: Congratulations on your baby! :-) 2014-04-03 1:28 GMT-03:00 Daniel Santa Cruz : > Welcome to issue 289 of the HWN, an issue covering crowd-sourced bits > of information about Haskell from around the web. This issue covers > from March 1 to 31, 2014 > > So... where have I been? > > My wife and I recently welcomed into the world our new baby, and as > some of you have already experienced, I was doing good getting *some* > sleep at night. Life has slowly started to get back to a more > predictable rhythm, and I am sure glad to be back doing this. For a > while there I thought that any project of mine before bambina was going > to have to be put into permament hold, but things are getting very > manageble now. > > Sorry for the abscense! I was somewhat pleased to see that some in > -cafe wondered if this was coming back... this one is for you! > > Some have mentioned that they wish to see more of the "reviews" that > HWN used to have of blog entries, and/or email chains in the different > mailing lists. I understand that dessire. I'm probably going to need > some extra hands to write those, if there are to be back. Maybe we can > start with something "lighter", a la tl;dr. I'm stil trying to work out > how we'd do that exacly. I'll keep you all posted. > > Anyway, enough rambling. > > Quotes of the Week > > * acowley: I will push machines-concurrent to hackage one fine day > edwardk: not concurrent-machines ? > acowley: Man, I walked right into that bike shed > > * malc: I have a coworker who constantly reads haskell stuff at work, > nudged him towards the lens talk, that should push him towards > actually doing work at work. > > * Fuuzetsu: I know someone who pulls in Lens just for & and ?? > > * Eduard_Munteanu: Don't put your money in monads, you can never get > it back. :P > > Top Reddit Stories > > * Haskell for all: Introductions to advanced Haskell topics > Domain: haskellforall.com, Score: 121, Comments: 23 > On Reddit: [1] http://goo.gl/M6ZL9f > Original: [2] http://goo.gl/YEKyCc > > * GHC 7.8.1 RC2 released > Domain: well-typed.com, Score: 99, Comments: 36 > On Reddit: [3] http://goo.gl/jxlLQl > Original: [4] http://goo.gl/05xnqX > > * Book review: Parallel and Concurrent Programming in Haskell > Domain: serpentine.com, Score: 87, Comments: 17 > On Reddit: [5] http://goo.gl/BfWSWC > Original: [6] http://goo.gl/nDe2UG > > * The Haskell Cast #6 - Gabriel Gonzalez and Michael Snoyman on Pipes > and Conduit > Domain: haskellcast.com, Score: 83, Comments: 13 > On Reddit: [7] http://goo.gl/PwL2aV > Original: [8] http://goo.gl/hwemr6 > > * Performance in Haskell from a noob's perspective > Domain: self.haskell, Score: 74, Comments: 111 > On Reddit: [9] http://goo.gl/IuT0uJ > Original: [10] http://goo.gl/IuT0uJ > > * New Haddock ? a visual guide to changes > Domain: fuuzetsu.co.uk, Score: 72, Comments: 13 > On Reddit: [11] http://goo.gl/KWJSEh > Original: [12] http://goo.gl/IXzESN > > * Full-time position available: computer scientist to create data types > for scientific computing, in Haskell. Location: anywhere (telecommute). > Domain: self.haskell, Score: 67, Comments: 17 > On Reddit: [13] http://goo.gl/Z8y9py > Original: [14] http://goo.gl/Z8y9py > > * Haskell Type Classes Cheatsheet > Domain: fundeps.com, Score: 62, Comments: 21 > On Reddit: [15] http://goo.gl/oAWk4C > Original: [16] http://goo.gl/SqHbro > > * Malicious link in haskell.org docs for 6 years, 6 months, 6 days > Domain: self.haskell, Score: 61, Comments: 6 > On Reddit: [17] http://goo.gl/V5y3hk > Original: [18] http://goo.gl/V5y3hk > > * What's your "killer app" for your scientific/statistical programming > environment? > Domain: self.haskell, Score: 57, Comments: 92 > On Reddit: [19] http://goo.gl/jfbwdj > Original: [20] http://goo.gl/jfbwdj > > * Find out the type of an expression/function with typed holes > Domain: ro-che.info, Score: 56, Comments: 5 > On Reddit: [21] http://goo.gl/hcjX1v > Original: [22] http://goo.gl/TWLT5R > > * Elm 0.12 - making interactive UI elements easy and pure > Domain: elm-lang.org, Score: 56, Comments: 5 > On Reddit: [23] http://goo.gl/SRoog7 > Original: [24] http://goo.gl/7FoFAz > > * QuickCheck 2.7 released > Domain: hackage.haskell.org, Score: 55, Comments: 7 > On Reddit: [25] http://goo.gl/RN66bR > Original: [26] http://goo.gl/3S38Uz > > Top StackOverflow Questions > > * Why is Haskell unable to read ?7e7? but able to read ?7a7?? > votes: 42, answers: 3 > Read on SO: [27] http://goo.gl/ZI8qm8 > > * Strange GHCi lazy evaluation > votes: 17, answers: 1 > Read on SO: [28] http://goo.gl/aoHvVp > > * Fast, branchless unsigned int absolute difference > votes: 16, answers: 3 > Read on SO: [29] http://goo.gl/TT3Oxi > > * How can I write human-language units as postfixes in Haskell, like `3 > seconds`? > votes: 15, answers: 2 > Read on SO: [30] http://goo.gl/6MJk5C > > * Running Haskell on Xeon-Phi > votes: 14, answers: 1 > Read on SO: [31] http://goo.gl/QEIayp > > Until next time, > [32]+Daniel Santa Cruz > > References > > 1. > http://www.haskellforall.com/2014/03/introductions-to-advanced-haskell-topics.html > 2. > http://www.reddit.com/r/haskell/comments/21bcb5/haskell_for_all_introductions_to_advanced_haskell/ > 3. http://www.well-typed.com/blog/87 > 4. > http://www.reddit.com/r/haskell/comments/1zgaln/ghc_781_rc2_released/ > 5. > http://www.serpentine.com/blog/2014/03/18/book-review-parallel-and-concurrent-programming-in-haskell/ > 6. > http://www.reddit.com/r/haskell/comments/20sdt4/book_review_parallel_and_concurrent_programming/ > 7. > http://www.haskellcast.com/episode/006-gabriel-gonzalez-and-michael-snoyman-on-pipes-and-conduit > 8. > http://www.reddit.com/r/haskell/comments/1zfo9g/the_haskell_cast_6_gabriel_gonzalez_and_michael/ > 9. > http://www.reddit.com/r/haskell/comments/21g6uo/performance_in_haskell_from_a_noobs_perspective/ > 10. > http://www.reddit.com/r/haskell/comments/21g6uo/performance_in_haskell_from_a_noobs_perspective/ > 11. > http://fuuzetsu.co.uk/blog/posts/2014-03-24-New-Haddock-released%21-A-visual-guide-to-changes.html > 12. > http://www.reddit.com/r/haskell/comments/218rov/new_haddock_a_visual_guide_to_changes/ > 13. > http://www.reddit.com/r/haskell/comments/202pvl/fulltime_position_available_computer_scientist_to/ > 14. > http://www.reddit.com/r/haskell/comments/202pvl/fulltime_position_available_computer_scientist_to/ > 15. http://fundeps.com/posts/cheatsheets/2014-03-04-cheat-sheets/ > 16. > http://www.reddit.com/r/haskell/comments/1zn3h9/haskell_type_classes_cheatsheet/ > 17. > http://www.reddit.com/r/haskell/comments/21959m/malicious_link_in_haskellorg_docs_for_6_years_6/ > 18. > http://www.reddit.com/r/haskell/comments/21959m/malicious_link_in_haskellorg_docs_for_6_years_6/ > 19. > http://www.reddit.com/r/haskell/comments/1zowv1/whats_your_killer_app_for_your/ > 20. > http://www.reddit.com/r/haskell/comments/1zowv1/whats_your_killer_app_for_your/ > 21. http://ro-che.info/articles/2014-03-13-type-of-local-function.html > 22. > http://www.reddit.com/r/haskell/comments/20bixd/find_out_the_type_of_an_expressionfunction_with/ > 23. http://elm-lang.org/blog/announce/0.12.elm > 24. > http://www.reddit.com/r/haskell/comments/218isr/elm_012_making_interactive_ui_elements_easy_and/ > 25. http://hackage.haskell.org/package/QuickCheck-2.7.1/changelog > 26. > http://www.reddit.com/r/haskell/comments/213da9/quickcheck_27_released/ > 27. > http://stackoverflow.com/questions/22689122/why-is-haskell-unable-to-read-7e7-but-able-to-read-7a7 > 28. > http://stackoverflow.com/questions/22491700/strange-ghci-lazy-evaluation > 29. > http://stackoverflow.com/questions/22445019/fast-branchless-unsigned-int-absolute-difference > 30. > http://stackoverflow.com/questions/22109333/how-can-i-write-human-language-units-as-postfixes-in-haskell-like-3-seconds > 31. > http://stackoverflow.com/questions/22253311/running-haskell-on-xeon-phi > 32. https://plus.google.com/105107667630152149014/about > > > _______________________________________________ > Haskell mailing list > Haskell at haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erochest at gmail.com Thu Apr 3 12:03:57 2014 From: erochest at gmail.com (Eric Rochester) Date: Thu, 3 Apr 2014 08:03:57 -0400 Subject: [Haskell-cafe] Haskell Weekly News: Issue 289 In-Reply-To: References: Message-ID: Congratulations! Welcome to issue 289 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from March 1 to 31, 2014 So... where have I been? My wife and I recently welcomed into the world our new baby, and as some of you have already experienced, I was doing good getting *some* sleep at night. Life has slowly started to get back to a more predictable rhythm, and I am sure glad to be back doing this. For a while there I thought that any project of mine before bambina was going to have to be put into permament hold, but things are getting very manageble now. Sorry for the abscense! I was somewhat pleased to see that some in -cafe wondered if this was coming back... this one is for you! Some have mentioned that they wish to see more of the "reviews" that HWN used to have of blog entries, and/or email chains in the different mailing lists. I understand that dessire. I'm probably going to need some extra hands to write those, if there are to be back. Maybe we can start with something "lighter", a la tl;dr. I'm stil trying to work out how we'd do that exacly. I'll keep you all posted. Anyway, enough rambling. Quotes of the Week * acowley: I will push machines-concurrent to hackage one fine day edwardk: not concurrent-machines ? acowley: Man, I walked right into that bike shed * malc: I have a coworker who constantly reads haskell stuff at work, nudged him towards the lens talk, that should push him towards actually doing work at work. * Fuuzetsu: I know someone who pulls in Lens just for & and ?? * Eduard_Munteanu: Don't put your money in monads, you can never get it back. :P Top Reddit Stories * Haskell for all: Introductions to advanced Haskell topics Domain: haskellforall.com, Score: 121, Comments: 23 On Reddit: [1] http://goo.gl/M6ZL9f Original: [2] http://goo.gl/YEKyCc * GHC 7.8.1 RC2 released Domain: well-typed.com, Score: 99, Comments: 36 On Reddit: [3] http://goo.gl/jxlLQl Original: [4] http://goo.gl/05xnqX * Book review: Parallel and Concurrent Programming in Haskell Domain: serpentine.com, Score: 87, Comments: 17 On Reddit: [5] http://goo.gl/BfWSWC Original: [6] http://goo.gl/nDe2UG * The Haskell Cast #6 - Gabriel Gonzalez and Michael Snoyman on Pipes and Conduit Domain: haskellcast.com, Score: 83, Comments: 13 On Reddit: [7] http://goo.gl/PwL2aV Original: [8] http://goo.gl/hwemr6 * Performance in Haskell from a noob's perspective Domain: self.haskell, Score: 74, Comments: 111 On Reddit: [9] http://goo.gl/IuT0uJ Original: [10] http://goo.gl/IuT0uJ * New Haddock -- a visual guide to changes Domain: fuuzetsu.co.uk, Score: 72, Comments: 13 On Reddit: [11] http://goo.gl/KWJSEh Original: [12] http://goo.gl/IXzESN * Full-time position available: computer scientist to create data types for scientific computing, in Haskell. Location: anywhere (telecommute). Domain: self.haskell, Score: 67, Comments: 17 On Reddit: [13] http://goo.gl/Z8y9py Original: [14] http://goo.gl/Z8y9py * Haskell Type Classes Cheatsheet Domain: fundeps.com, Score: 62, Comments: 21 On Reddit: [15] http://goo.gl/oAWk4C Original: [16] http://goo.gl/SqHbro * Malicious link in haskell.org docs for 6 years, 6 months, 6 days Domain: self.haskell, Score: 61, Comments: 6 On Reddit: [17] http://goo.gl/V5y3hk Original: [18] http://goo.gl/V5y3hk * What's your "killer app" for your scientific/statistical programming environment? Domain: self.haskell, Score: 57, Comments: 92 On Reddit: [19] http://goo.gl/jfbwdj Original: [20] http://goo.gl/jfbwdj * Find out the type of an expression/function with typed holes Domain: ro-che.info, Score: 56, Comments: 5 On Reddit: [21] http://goo.gl/hcjX1v Original: [22] http://goo.gl/TWLT5R * Elm 0.12 - making interactive UI elements easy and pure Domain: elm-lang.org, Score: 56, Comments: 5 On Reddit: [23] http://goo.gl/SRoog7 Original: [24] http://goo.gl/7FoFAz * QuickCheck 2.7 released Domain: hackage.haskell.org, Score: 55, Comments: 7 On Reddit: [25] http://goo.gl/RN66bR Original: [26] http://goo.gl/3S38Uz Top StackOverflow Questions * Why is Haskell unable to read "7e7" but able to read "7a7"? votes: 42, answers: 3 Read on SO: [27] http://goo.gl/ZI8qm8 * Strange GHCi lazy evaluation votes: 17, answers: 1 Read on SO: [28] http://goo.gl/aoHvVp * Fast, branchless unsigned int absolute difference votes: 16, answers: 3 Read on SO: [29] http://goo.gl/TT3Oxi * How can I write human-language units as postfixes in Haskell, like `3 seconds`? votes: 15, answers: 2 Read on SO: [30] http://goo.gl/6MJk5C * Running Haskell on Xeon-Phi votes: 14, answers: 1 Read on SO: [31] http://goo.gl/QEIayp Until next time, [32]+Daniel Santa Cruz References 1. http://www.haskellforall.com/2014/03/introductions-to-advanced-haskell-topics.html 2. http://www.reddit.com/r/haskell/comments/21bcb5/haskell_for_all_introductions_to_advanced_haskell/ 3. http://www.well-typed.com/blog/87 4. http://www.reddit.com/r/haskell/comments/1zgaln/ghc_781_rc2_released/ 5. http://www.serpentine.com/blog/2014/03/18/book-review-parallel-and-concurrent-programming-in-haskell/ 6. http://www.reddit.com/r/haskell/comments/20sdt4/book_review_parallel_and_concurrent_programming/ 7. http://www.haskellcast.com/episode/006-gabriel-gonzalez-and-michael-snoyman-on-pipes-and-conduit 8. http://www.reddit.com/r/haskell/comments/1zfo9g/the_haskell_cast_6_gabriel_gonzalez_and_michael/ 9. http://www.reddit.com/r/haskell/comments/21g6uo/performance_in_haskell_from_a_noobs_perspective/ 10. http://www.reddit.com/r/haskell/comments/21g6uo/performance_in_haskell_from_a_noobs_perspective/ 11. http://fuuzetsu.co.uk/blog/posts/2014-03-24-New-Haddock-released%21-A-visual-guide-to-changes.html 12. http://www.reddit.com/r/haskell/comments/218rov/new_haddock_a_visual_guide_to_changes/ 13. http://www.reddit.com/r/haskell/comments/202pvl/fulltime_position_available_computer_scientist_to/ 14. http://www.reddit.com/r/haskell/comments/202pvl/fulltime_position_available_computer_scientist_to/ 15. http://fundeps.com/posts/cheatsheets/2014-03-04-cheat-sheets/ 16. http://www.reddit.com/r/haskell/comments/1zn3h9/haskell_type_classes_cheatsheet/ 17. http://www.reddit.com/r/haskell/comments/21959m/malicious_link_in_haskellorg_docs_for_6_years_6/ 18. http://www.reddit.com/r/haskell/comments/21959m/malicious_link_in_haskellorg_docs_for_6_years_6/ 19. http://www.reddit.com/r/haskell/comments/1zowv1/whats_your_killer_app_for_your/ 20. http://www.reddit.com/r/haskell/comments/1zowv1/whats_your_killer_app_for_your/ 21. http://ro-che.info/articles/2014-03-13-type-of-local-function.html 22. http://www.reddit.com/r/haskell/comments/20bixd/find_out_the_type_of_an_expressionfunction_with/ 23. http://elm-lang.org/blog/announce/0.12.elm 24. http://www.reddit.com/r/haskell/comments/218isr/elm_012_making_interactive_ui_elements_easy_and/ 25. http://hackage.haskell.org/package/QuickCheck-2.7.1/changelog 26. http://www.reddit.com/r/haskell/comments/213da9/quickcheck_27_released/ 27. http://stackoverflow.com/questions/22689122/why-is-haskell-unable-to-read-7e7-but-able-to-read-7a7 28. http://stackoverflow.com/questions/22491700/strange-ghci-lazy-evaluation 29. http://stackoverflow.com/questions/22445019/fast-branchless-unsigned-int-absolute-difference 30. http://stackoverflow.com/questions/22109333/how-can-i-write-human-language-units-as-postfixes-in-haskell-like-3-seconds 31. http://stackoverflow.com/questions/22253311/running-haskell-on-xeon-phi 32. https://plus.google.com/105107667630152149014/about _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.oqube at gmail.com Thu Apr 3 13:26:48 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Thu, 3 Apr 2014 15:26:48 +0200 Subject: [Haskell-cafe] Haskell + emacs + Ghc-mod 4.0.1 Message-ID: Hello, I upgrade my emacs configuration with latest ghc-mod and all of sudden nothing works (again). When I try to load a .hs file from a project I got the first line highlighted with the error "cannot satisfy -package spec" and I cannot got type, info or doc from that file. Also I do not have anymore syntax errors highlighting I used to see. Any help greatly appreciated. I would also appreciate any pointer explaining how to setup and maintain a proper Haskell dev environment. Haskell is not the language I use at day work but I have been using it for years and every so often my emacs configuration is broken and I have a hard time getting it back to sane state. Thanks in advance Arnaud Here is my emacs configuration: ;; haskell coding (require 'haskell-mode) (require 'haskell-cabal) (autoload 'ghc-init "ghc" nil t) (add-hook 'haskell-mode-hook (lambda () (ghc-init))) (eval-after-load "haskell-mode" '(progn (define-key haskell-mode-map (kbd "C-,") 'haskell-move-nested-left) (define-key haskell-mode-map (kbd "C-.") 'haskell-move-nested-right) (define-key haskell-mode-map (kbd "C-c v c") 'haskell-cabal-visit-file) (define-key haskell-mode-map (kbd "C-c C-c") 'haskell-compile) (define-key haskell-mode-map (kbd "C-x C-d") nil) (setq haskell-font-lock-symbols t))) (add-hook 'haskell-mode-hook 'turn-on-haskell-decl-scan) (add-hook 'haskell-mode-hook 'turn-on-haskell-indentation) (eval-after-load "which-func" '(add-to-list 'which-func-modes 'haskell-mode)) (eval-after-load "haskell-cabal" '(define-key haskell-cabal-mode-map (kbd "C-c C-c") 'haskell-compile)) Here is the output of ls -l ~/Library/Haskell/bin: lrwxr-xr-x 1 arnaud staff 45 Dec 27 22:36 HsColour -> ../ghc-7.6.3/lib/hscolour-1.20.3/bin/HsColour lrwxr-xr-x 1 arnaud staff 50 Dec 31 07:11 aeson-pretty -> ../ghc-7.6.3/lib/aeson-pretty-0.7/bin/aeson-pretty lrwxr-xr-x 1 arnaud staff 52 Dec 31 07:11 biblio2yaml -> ../ghc-7.6.3/lib/pandoc-citeproc-0.2/bin/biblio2yaml lrwxr-xr-x 1 arnaud staff 49 Jan 10 16:25 cabal -> ../ghc-7.6.3/lib/cabal-install-1.18.0.2/bin/cabal lrwxr-xr-x 1 arnaud staff 46 Jan 15 13:51 cabal-dev -> ../ghc-7.6.3/lib/cabal-dev-0.9.2/bin/cabal-dev lrwxr-xr-x 1 arnaud staff 39 Dec 27 22:36 cpphs -> ../ghc-7.6.3/lib/cpphs-1.17.1/bin/cpphs lrwxr-xr-x 1 arnaud staff 43 Dec 28 14:17 doctest -> ../ghc-7.6.3/lib/doctest-0.9.10/bin/doctest lrwxr-xr-x 1 arnaud staff 55 Jan 15 13:51 fake-ghc-cabal-dev -> ../ghc-7.6.3/lib/cabal-dev-0.9.2/bin/fake-ghc-cabal-dev lrwxr-xr-x 1 arnaud staff 62 Jan 26 11:15 ghc-events -> ../../../projects/data-scientist/.cabal-sandbox/bin/ghc-events lrwxr-xr-x 1 arnaud staff 42 Apr 3 15:04 ghc-mod -> ../ghc-7.6.3/lib/ghc-mod-4.0.1/bin/ghc-mod lrwxr-xr-x 1 arnaud staff 43 Apr 3 13:35 ghc-modi -> ../ghc-7.6.3/lib/ghc-mod-4.0.1/bin/ghc-modi lrwxr-xr-x 1 arnaud staff 55 Jan 15 13:51 ghc-pkg-6_8-compat -> ../ghc-7.6.3/lib/cabal-dev-0.9.2/bin/ghc-pkg-6_8-compat lrwxr-xr-x 1 arnaud staff 47 Dec 31 07:11 hakyll-init -> ../ghc-7.6.3/lib/hakyll-4.4.2.0/bin/hakyll-init lrwxr-xr-x 1 arnaud staff 45 Mar 31 13:57 hasktags -> ../ghc-7.6.3/lib/hasktags-0.68.7/bin/hasktags lrwxr-xr-x 1 arnaud staff 36 Mar 17 06:09 hell -> ../ghc-7.6.3/lib/hell-0.0.1/bin/hell lrwxr-xr-x 1 arnaud staff 39 Dec 27 22:36 hlint -> ../ghc-7.6.3/lib/hlint-1.8.55/bin/hlint lrwxr-xr-x 1 arnaud staff 47 Apr 3 15:07 hspec-discover -> ../ghc-7.6.3/lib/hspec-1.9.1/bin/hspec-discover lrwxr-xr-x 1 arnaud staff 58 Dec 31 07:11 make-pandoc-man-pages -> ../ghc-7.6.3/lib/pandoc-1.12.2.1/bin/make-pandoc-man-pages lrwxr-xr-x 1 arnaud staff 62 Jan 15 04:25 operational-TicTacToe -> ../ghc-7.6.3/lib/operational-0.2.2.1/bin/operational-TicTacToe lrwxr-xr-x 1 arnaud staff 43 Jan 15 05:14 pandoc -> ../ghc-7.6.3/lib/pandoc-1.12.2.1/bin/pandoc lrwxr-xr-x 1 arnaud staff 56 Dec 31 07:11 pandoc-citeproc -> ../ghc-7.6.3/lib/pandoc-citeproc-0.2/bin/pandoc-citeproc lrwxr-xr-x 1 arnaud staff 44 Dec 27 19:34 pdf2line -> ../ghc-7.6.3/lib/pdf2line-0.0.1/bin/pdf2line lrwxr-xr-x 1 arnaud staff 43 Dec 27 19:34 pdfdump -> ../ghc-7.6.3/lib/pdf2line-0.0.1/bin/pdfdump lrwxr-xr-x 1 arnaud staff 42 Jan 15 05:26 word2vec -> ../ghc-7.6.3/lib/word2vec-0.1/bin/word2vec lrwxr-xr-x 1 arnaud staff 43 Dec 31 07:11 yaml2json -> ../ghc-7.6.3/lib/yaml-0.8.5.2/bin/yaml2json lrwxr-xr-x 1 arnaud staff 34 Mar 13 08:58 yate -> ../ghc-7.6.3/lib/yate-0.1/bin/yate -- Arnaud Bailly FoldLabs Associate: http://foldlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 3 16:21:38 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 3 Apr 2014 16:21:38 +0000 Subject: [Haskell-cafe] Inline makes program slow? In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF0E2D54@DB3PRD3001MB020.064d.mgd.msft.net> Dominick's program is very delicate: fibonacci :: (Integral a) => [a] fibonacci = 0 : 1 : zipWith (+) fibonacci (tail fibonacci) Remember, the "(Integral a) =>" thing is very like "Integral a ->"; it's an extra value argument. Would you expect this program to be fast? foo :: Int -> [Int] foo n = 0 : 1 : zipWith (+) (foo n) (tail (foo n)) Perhaps, but it depends on common sub-expression analysis which is on with -O. Anyway it is not related to INLINE or eta-expansion/contraction. Simon | -----Original Message----- | From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf | Of Dominick Samperi | Sent: 30 March 2014 17:58 | To: wren romano | Cc: haskell | Subject: Re: [Haskell-cafe] Inline makes program slow? | | Compiler optimization levels are also important. The attached program | compiles and runs ok using: | | ghc -O fibmustopt.hs | ./fibmustopt | | But if the '-O' option is omitted all of the available memory is used | and it fails. | | | On Sun, Mar 30, 2014 at 2:56 AM, wren romano | wrote: | > On Fri, Mar 28, 2014 at 9:43 PM, Kai Zhang wrote: | >> Without inline (remove the inline pragma), "slow" would be much | >> faster. I suspect this is because ghc can build a "persistent | >> structure" for the partial applied function. After inline, each call | >> of "g" will try to build a new vector. How can I tell ghc not to | >> inline some specific functions? Or are there other ways to resolve | this issue? | > | > For what it's worth, I don't think this is an inlining issue, per se; | > rather, it's an issue with the fact that eta-conversion does not | > preserve performance characteristics. That is, when we inline h and | > perform as much beta-reduction as we can, we're left with the lambda | > expression: | > | > \i -> (V.fromList $ sort str) V.! i | > | > Which is not necessarily the same thing, performance-wise, as: | > | > ((V.fromList $ sort str) V.!) | > | > The problem is that, implicitly, the whole body of the lambda | > abstraction (might) depend on the value of i and therefore cannot be | > performed until we know what i is. If we wanted to make it explicit | > that sorting the string is independent of the value of i, we could | > write: | > | > let s = V.fromList $ sort str in \i -> s V.! i | > | > By using let-binding to lift most of the computation out of the body | > of the lambda abstraction, we ensure that the sorting will only be | > done once, rather than (possibly) being done every time this function | > is called. | > | > The reason I say "might" and "possibly" is because, in theory, the | > compiler could choose to perform this transformation for you. And | > sometimes it does (as apparently it does in your fast code). The | > problem is that, in practice, performing this transformation | > everywhere can slow things down horribly by taking too much memory | > because you're trying to hold onto too many things. Thus, the | compiler | > must rely on heuristics to decide when it should float computations | > out from under lambdas and when it shouldn't. | > | > -- | > Live well, | > ~wren | > _______________________________________________ | > Haskell-Cafe mailing list | > Haskell-Cafe at haskell.org | > http://www.haskell.org/mailman/listinfo/haskell-cafe From ducis_cn at 126.com Thu Apr 3 16:34:58 2014 From: ducis_cn at 126.com (ducis) Date: Fri, 4 Apr 2014 00:34:58 +0800 (CST) Subject: [Haskell-cafe] What should I use if I want both deriving SQL 'create table' from haskell types automatically and relational queries ? In-Reply-To: References: Message-ID: <5e44183b.168d8.145287180ff.Coremail.ducis_cn@126.com> Persistent and acid-state are both 'No SQL' ? I guess there is only groundhog? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Thu Apr 3 16:48:42 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 3 Apr 2014 17:48:42 +0100 Subject: [Haskell-cafe] Inline makes program slow? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0E2D54@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0E2D54@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <20140403164842.GH9603@weber> On Thu, Apr 03, 2014 at 04:21:38PM +0000, Simon Peyton Jones wrote: > Dominick's program is very delicate: > > fibonacci :: (Integral a) => [a] > fibonacci = 0 : 1 : zipWith (+) fibonacci (tail fibonacci) > > Remember, the "(Integral a) =>" thing is very like "Integral a ->"; it's > an extra value argument. Would you expect this program to be fast? > > foo :: Int -> [Int] > foo n = 0 : 1 : zipWith (+) (foo n) (tail (foo n)) Indeed. The curious may be interested to know you can fix this by hand by sharing a monomorphic bind fibonacci = let f = fibonacci in 0 : 1 : zipWith (+) f (tail f) unless the dreaded monomorphism restriction is off, in which case you have to find some other way of making 'f' monomorphic, for example with ScopedTypeVariables: fibonacci = let f = fibonacci :: [a] in 0 : 1 : zipWith (+) f (tail f) (I guess examples like this are exactly the reason the monomorphism restriction exists). Tom From michael at snoyman.com Thu Apr 3 17:02:48 2014 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 3 Apr 2014 20:02:48 +0300 Subject: [Haskell-cafe] What should I use if I want both deriving SQL 'create table' from haskell types automatically and relational queries ? In-Reply-To: <5e44183b.168d8.145287180ff.Coremail.ducis_cn@126.com> References: <5e44183b.168d8.145287180ff.Coremail.ducis_cn@126.com> Message-ID: While Persistent supports some NoSQL databases, it definitely works with SQL databases. And with esqueleto[1] you can even write type-safe SQL queries in Haskell. [1] http://hackage.haskell.org/package/esqueleto On Thu, Apr 3, 2014 at 7:34 PM, ducis wrote: > Persistent and acid-state are both 'No SQL' ? I guess there is only > groundhog? > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Thu Apr 3 21:30:24 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 04 Apr 2014 06:30:24 +0900 (JST) Subject: [Haskell-cafe] Haskell + emacs + Ghc-mod 4.0.1 In-Reply-To: References: Message-ID: <20140404.063024.573783403235305621.kazu@iij.ad.jp> > I upgrade my emacs configuration with latest ghc-mod and all of sudden > nothing works (again). > When I try to load a .hs file from a project I got the first line > highlighted with the error "cannot satisfy -package spec" and I cannot got > type, info or doc from that file. Also I do not have anymore syntax errors > highlighting I used to see. As this message suggests, you need to install spec for testing. % cabal install spec # I don't know what the spec package is. A typo for hspec? This is because ghc-mod obtains dependency for executables, libraries *and* testing. In general, % cabal install --only-dependencies would help you. --Kazu From chris at chrisdornan.com Fri Apr 4 06:21:19 2014 From: chris at chrisdornan.com (Chris Dornan) Date: Fri, 04 Apr 2014 07:21:19 +0100 Subject: [Haskell-cafe] Fun and Profit with Stongly-Typed Data Schemas Message-ID: Folks, I will be giving a talk in London on Wednesday evening at Skills Matter on _api-tools_, a cool new Haskell package Iris Connect have been developing with Well Typed to help us with the new web platform. See the Skills Matter web site for details: https://skillsmatter.com/meetups/6201-fun-and-profit-with-stongly-typed-data -schemas? Cheers, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanielsen at gmail.com Fri Apr 4 09:30:36 2014 From: tanielsen at gmail.com (Tom Nielsen) Date: Fri, 4 Apr 2014 10:30:36 +0100 Subject: [Haskell-cafe] What should I use if I want both deriving SQL 'create table' from haskell types automatically and relational queries ? In-Reply-To: <5e44183b.168d8.145287180ff.Coremail.ducis_cn@126.com> References: <5e44183b.168d8.145287180ff.Coremail.ducis_cn@126.com> Message-ID: Persistent works with PostgreSQL, SQLite and some other SQL databases. On Thu, Apr 3, 2014 at 5:34 PM, ducis wrote: > Persistent and acid-state are both 'No SQL' ? I guess there is only > groundhog? > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eijiro.sumii at gmail.com Fri Apr 4 14:27:18 2014 From: eijiro.sumii at gmail.com (Eijiro Sumii) Date: Fri, 4 Apr 2014 23:27:18 +0900 Subject: [Haskell-cafe] FLOPS 2014 call for participation (June 4-6, Kanazawa, Japan; early registration deadline on May 13) Message-ID: Dear colleagues, The registration for FLOPS 2014 (Twelfth International Symposium on Functional and Logic Programming, June 4-6, Kanazawa, Japan) is now open: http://www.jaist.ac.jp/flops2014/registration.html - Early registration deadline on May 13, 2014 - Program http://www.jaist.ac.jp/flops2014/program.html with invited talks by Ranjit Jhala, Shin-ya Katsumata, and Gabriele Keller - Sponsored by JSSST SIGPPL; in cooperation with ACM SIGPLAN, AAFS, and ALP - Proceedings to be published as LNCS 8475 - Hyakuman-goku Matsuri Festival http://www.kanazawa-tourism.com/eng/event/event2.php on the day after the symposium (June 7); accommodation can be extended on request basis via the registration site (use the comments field) - See http://www.jaist.ac.jp/flops2014/ for more information Thank you! FLOPS 2014 Program Co-Chairs Michael Codish and Eijiro Sumii From rrnewton at gmail.com Fri Apr 4 15:25:26 2014 From: rrnewton at gmail.com (Ryan Newton) Date: Fri, 4 Apr 2014 11:25:26 -0400 Subject: [Haskell-cafe] 2nd CFP: FHPC'14 - Functional and High-Performance Computing - due May 15 Message-ID: There a couple small bugs in the previous CFP. (Dates were right, but day of the week was wrong -- the due date is a Thursday.) Please see the corrected version below. ===================================================================== CALL FOR PAPERS FHPC 2014 The 2nd ACM SIGPLAN Workshop on Functional High-Performance Computing Gothenburg, Sweden September 4, 2014 https://sites.google.com/site/fhpcworkshops/ Co-located with the International Conference on Functional Programming (ICFP 2014) Submission Deadline: Thursday, 15 May, 2014 (anywhere on earth) ===================================================================== The FHPC workshop aims at bringing together researchers exploring uses of functional (or more generally, declarative or high-level) programming technology in application domains where high performance is essential. The aim of the meeting is to enable sharing of results, experiences, and novel ideas about how high-level, declarative specifications of computationally challenging problems can serve as maintainable and portable code that approaches (or even exceeds) the performance of machine-oriented imperative implementations. All aspects of performance critical programming and parallel programming are in-scope for the workshop, irrespective of hardware target. This includes both traditional large-scale scientific computing (HPC), as well as work targeting single node systems with SMPs, GPUs, FPGAs, or embedded processors. It is becoming apparent that radically new and well founded methodologies for programming such systems are required to address their inherent complexity and to reconcile execution performance with programming productivity. Every year, the FHPC workshop has an application area as a theme. Papers touching on this topic are especially encouraged, though all in-scope papers are welcomed. For FHPC 2014, the theme is "Heterogeneous computing". In the systems and parallelism communities, there has been a lot of work on programming systems with CPUs and GPUs (or other mixed parallel architectures), but in the programming languages community this idea has not received as much attention. At their best, high-level languages can have the degrees of flexibility necessary to abstract over platform differences. Proceedings: ============ Accepted papers will be published by the ACM and will appear in the ACM Digital Library. * Submissions due: Thursday, 15 May, 2014 (anywhere on earth) * Author notification: Sunday, 15 June, 2014 * Final copy due: Sunday, 22 June, 2014 Submitted papers must be in portable document format (PDF), formatted according to the ACM SIGPLAN style guidelines (2 column, 9pt format). See http://www.sigplan.org/authorInformation.htm for more information and style files. Typical papers are expected to be 8 pages (but up to four additional pages are permitted). Contributions to FHPC 2014 should be submitted via Easychair, at the following URL: * https://www.easychair.org/conferences/?conf=fhpc14 The submission site is now open. The FHPC workshops adhere to the ACM SIGPLAN policies regarding programme committee contributions and republication. Any paper submitted must adhere to ACM SIGPLAN's republication policy. PC member submissions are welcome, but will be reviewed to a higher standard. http://www.sigplan.org/Resources/Policies/Review http://www.sigplan.org/Resources/Policies/Republication Travel Support: =============== Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC programme, see its web page (http://www.sigplan.org/PAC.htm). Programme Committee: ==================== Mary Sheeran (co-chair), Chalmers University of Technology, SE Ryan Newton (co-chair), Indiana University, USA Lennart Augustsson, Standard Chartered Bank, UK Jost Berthold, University of Copenhagen, Denmark Guy Blelloch, Carnegie Mellon University, USA Marius Eriksen, Twitter, USA Clemens Grelck, University of Amsterdam, Netherlands Vinod Grover, Nvidia, USA Kevin Hammond, University of St. Andrews, UK Ben Lippmeier, University of New South Wales, Australia Liu (Paul) Hai, Intel, USA Rita Loogen, University of Marburg, Germany Greg Michaelson, Heriot-Watt University, UK Marc Pouzet, ENS Paris, France John Reppy, Univesity of Chicago, USA Tiark Rompf, Oracle Labs and EPFL, Switzerland Satnam Singh, Google, USA Dimitrios Vytiniotis, Microsoft Research, UK General Chairs: ==================== Jost Berthold University of Copenhagen -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjwatson at ubuntu.com Fri Apr 4 16:33:04 2014 From: cjwatson at ubuntu.com (Colin Watson) Date: Fri, 4 Apr 2014 17:33:04 +0100 Subject: [Haskell-cafe] Building GHC 7.6 with 7.8 In-Reply-To: <20140402194146.GS6397@riva.ucam.org> References: <20140402194146.GS6397@riva.ucam.org> Message-ID: <20140404163304.GA25956@riva.ucam.org> On Wed, Apr 02, 2014 at 08:41:46PM +0100, Colin Watson wrote: > "/home/cjwatson/ghc-aarch64/inplace/bin/ghc-stage2" -H32m -O -lffi -optl-pthread -package-db libraries/bootstrapping.conf -hide-all-packages -i -ighc/. -ighc/stage1/build -ighc/stage1/build/autogen -Ighc/stage1/build -Ighc/stage1/build/autogen -optP-include -optPghc/stage1/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package ghc-7.8.0.20140331 -package process-1.2.0.0 -package unix-2.7.0.0 -Wall -XHaskell98 -XNondecreasingIndentation -XCPP -XPatternGuards -no-user-package-db -rtsopts -odir ghc/stage1/build -hidir ghc/stage1/build -stubdir ghc/stage1/build -hisuf hi -osuf o -hcsuf hc -c ghc/./Main.hs -o ghc/stage1/build/Main.o > Failed to load interface for `Distribution.InstalledPackageInfo.Binary' > There are files missing in the `bin-package-db-0.0.0.0' package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. Never mind - I got past this. The key was realising that this should be building against the just-built compiler/ tree, and hence "-package ghc-7.8.0.20140331" needs to be "-package ghc-7.6.3" instead. I fixed up a few too-new dependencies like this and things are working much better now. -- Colin Watson [cjwatson at ubuntu.com] From rvollmert-lists at gmx.net Fri Apr 4 17:02:55 2014 From: rvollmert-lists at gmx.net (Robert Vollmert) Date: Fri, 4 Apr 2014 19:02:55 +0200 Subject: [Haskell-cafe] design problem, "varying intermediate types" In-Reply-To: References: Message-ID: <3F68EC40-77E9-4EF3-9232-1D21346BEA08@gmx.net> On Mar 15, 2014, at 0:36 , Robert Vollmert wrote: > My problem is how I should deal with these intermediate types that vary based on the input. My current approach below has parsing and printing functions, and then one big function that strings the matching parsers and printers together. Just wanted to report that I?ve solved this well enough for now. The basic approach looks like: type Parsers a b = ? type Printers a b = ? type Handler c = forall a b. Parsers a b -> Printers a b -> c compose :: Tag -> Handler c -> c compose Tag1 h = h parsers1 printers1 compose Tag2 h = h parsers2 printers2 ? (where type parameters a b differ for the different tags) Then I can define different handlers for different ways of stringing together parsers and printers. I?d still love to know if this is the ?right? way to do this? Or if what I?m doing has a name? Cheers Rob From alex.solla at gmail.com Fri Apr 4 17:42:51 2014 From: alex.solla at gmail.com (Alexander Solla) Date: Fri, 4 Apr 2014 10:42:51 -0700 Subject: [Haskell-cafe] design problem, "varying intermediate types" In-Reply-To: <3F68EC40-77E9-4EF3-9232-1D21346BEA08@gmx.net> References: <3F68EC40-77E9-4EF3-9232-1D21346BEA08@gmx.net> Message-ID: On Fri, Apr 4, 2014 at 10:02 AM, Robert Vollmert wrote: > > On Mar 15, 2014, at 0:36 , Robert Vollmert > wrote: > > My problem is how I should deal with these intermediate types that vary > based on the input. My current approach below has parsing and printing > functions, and then one big function that strings the matching parsers and > printers together. > > Just wanted to report that I've solved this well enough for now. The basic > approach looks like: > > type Parsers a b = ... > type Printers a b = ... > > type Handler c = forall a b. Parsers a b -> Printers a b -> c > > compose :: Tag -> Handler c -> c > compose Tag1 h = h parsers1 printers1 > compose Tag2 h = h parsers2 printers2 > ... > > (where type parameters a b differ for the different tags) > > Then I can define different handlers for different ways of stringing > together parsers and printers. > > I'd still love to know if this is the "right" way to do this... Or if what > I'm doing has a name? > > Cheers > Rob It seems to me that you might benefit from a "compiler" approach. In such a design, you parse the input text, turn it into an abstract syntax tree, and then interpret the tree (typically in terms of some monad, but not necessarily). The "intermediate" data type is definitely tricky to get down. If you are having trouble expressing it in a way that fits your other design constraints, you might want to look into stuff like "data types a la carte" or the "syntactic" package. But really, standard Haskell data types are pretty good at this kind of thing. You shouldn't need data types a la carte unless you're trying to make a "pluggable" F-algebra. (That is, a data type that you can "extend" by importing a library) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvollmert-lists at gmx.net Fri Apr 4 20:49:24 2014 From: rvollmert-lists at gmx.net (Robert Vollmert) Date: Fri, 4 Apr 2014 22:49:24 +0200 Subject: [Haskell-cafe] design problem, "varying intermediate types" In-Reply-To: References: <3F68EC40-77E9-4EF3-9232-1D21346BEA08@gmx.net> Message-ID: <867AC095-CC6A-4CA1-BCA3-C9BD9B72E477@gmx.net> On Apr 4, 2014, at 19:42 , Alexander Solla wrote: > It seems to me that you might benefit from a "compiler" approach. In such a design, you parse the input text, turn it into an abstract syntax tree, and then interpret the tree (typically in terms of some monad, but not necessarily). Thanks, the program does seem obviously compiler-like now that it?s been suggested! This will at least help thinking about it. > The "intermediate" data type is definitely tricky to get down. If you are having trouble expressing it in a way that fits your other design constraints, you might want to look into stuff like "data types a la carte" or the "syntactic" package. But really, standard Haskell data types are pretty good at this kind of thing. > > You shouldn't need data types a la carte unless you're trying to make a "pluggable" F-algebra. (That is, a data type that you can "extend" by importing a library) Fun, I never had a reason to look at the data types a la carte and friends before. Though I?m not sure to what extent these approaches are a good fit given that my input doesn?t have any recursive structure? I do sort of want to keep the intermediate type ?open?, though that may well be a mistake? I?ll keep thinking about it, thanks for the input! Cheers Rob From miroslav.karpis at gmail.com Fri Apr 4 22:17:04 2014 From: miroslav.karpis at gmail.com (Miro Karpis) Date: Sat, 5 Apr 2014 00:17:04 +0200 Subject: [Haskell-cafe] scotty + aeson + ffi: optimising performance Message-ID: Hi, I have a C++ program that is doing some IO with one shared library (dll). I made a Haskell program that uses ffi for communicating with external dll. With scotty and aeson I made a web-service that communicates with the dll via REST-API (json). I was expecting that the performance would be a bit slower than the c++ internal dll calls, but I'm getting approx 3x slower performance in my haskell program. I tried to profile it but so far I can see that the bottleneck is Aeson (please correct me if I'm wrong). Is there a way how to optimise it? The data I'm sending via JSON are very small, so that can not be the problem. I have compiled the program with: ghc -O2 --make Service.hs -o eDS_FM -prof -auto-all -L. -lextlib Cheers, Miro profile: Fri Apr 04 23:57 2014 Time and Allocation Profiling Report (Final) eDS_FM.exe +RTS -p -RTS total time = 0.81 secs (810 ticks @ 1000 us, 1 processor) total alloc = 638,446,652 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc MAIN MAIN 65.3 63.1 go/Number Data.Aeson.Encode 22.5 26.2 array_ Data.Aeson.Parser.Internal 7.0 6.6 tableArrayInDataToJSON.json FM.Json 1.5 0.9 go/Array Data.Aeson.Encode 1.4 1.1 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 172 0 65.3 63.1 100.0 100.0 unstream/resize Data.Text.Fusion 419 7 0.0 0.0 0.0 0.0 main.arrayDouble Main 415 2158 0.0 0.2 0.0 0.2 main.retCodeInt Main 414 2158 0.0 0.0 0.0 0.0 main.dataOut Main 413 2158 0.0 0.0 0.0 0.0 getarray.paramLength FM.ModelIO 408 2158 0.0 0.0 0.0 0.0 getarray FM.ModelIO 407 2158 0.1 0.7 0.1 0.7 getarray.rowsReturnedInt FM.ModelIO 412 2158 0.0 0.0 0.0 0.0 getarray.arrayPtr FM.ModelIO 411 2158 0.0 0.0 0.0 0.0 main.resultInt Main 396 1 0.0 0.0 0.0 0.0 main.resultInt Main 395 1 0.0 0.0 0.0 0.0 setmodulestring FM.ModelIO 391 1 0.0 0.0 0.0 0.0 setmodulestring.setVarInArray FM.ModelIO 394 1 0.0 0.0 0.0 0.0 setmodulestring.cValueLength FM.ModelIO 393 1 0.0 0.0 0.0 0.0 setmodulestring.cParamLength FM.ModelIO 392 1 0.0 0.0 0.0 0.0 main.queryString Main 385 1 0.0 0.0 0.0 0.0 stringDataToJSON FM.Json 386 1 0.0 0.0 0.0 0.0 stringDataToJSON.json FM.Json 388 1 0.0 0.0 0.0 0.0 object_ Data.Aeson.Parser.Internal 389 0 0.0 0.0 0.0 0.0 jstring_ Data.Aeson.Parser.Internal 390 4 0.0 0.0 0.0 0.0 stringDataToJSON.retValue FM.Json 387 1 0.0 0.0 0.0 0.0 main.resultInt Main 382 290 0.0 0.0 0.0 0.0 go/Object Data.Aeson.Encode 379 2553 0.0 0.1 24.1 27.5 go/Array Data.Aeson.Encode 416 2158 1.2 0.8 21.7 26.2 go/Number Data.Aeson.Encode 418 63801 20.5 25.4 20.5 25.4 go/Number Data.Aeson.Encode 383 2656 0.1 0.1 0.1 0.1 string Data.Aeson.Encode 380 4814 0.1 0.1 2.2 1.1 go/Number Data.Aeson.Encode 384 0 1.9 0.8 2.0 1.0 go/Array Data.Aeson.Encode 417 0 0.1 0.2 0.1 0.2 break Data.Aeson.Encode 381 4814 0.1 0.0 0.1 0.0 setmoduletable FM.ModelIO 372 290 0.2 0.0 0.4 0.1 setmoduletable.cRows FM.ModelIO 376 290 0.0 0.0 0.0 0.0 setmoduletable.cColumns FM.ModelIO 375 290 0.0 0.0 0.0 0.0 setmoduletable.cParamLength FM.ModelIO 374 290 0.1 0.0 0.1 0.0 setmoduletable.cTable FM.ModelIO 373 290 0.0 0.0 0.0 0.0 main.queryString Main 363 290 0.0 0.0 9.6 7.7 tableArrayInDataToJSON FM.Json 364 290 0.0 0.0 9.6 7.7 tableArrayInDataToJSON.json FM.Json 366 290 1.5 0.9 9.6 7.7 object_ Data.Aeson.Parser.Internal 368 0 0.1 0.0 8.1 6.8 jstring_ Data.Aeson.Parser.Internal 369 1450 1.0 0.2 8.0 6.8 array_ Data.Aeson.Parser.Internal 371 0 7.0 6.6 7.0 6.6 tableArrayInDataToJSON.retValue FM.Json 365 290 0.0 0.0 0.0 0.0 main Main 345 0 0.2 0.7 0.2 0.7 run FM.ModelIO 398 0 0.0 0.0 0.0 0.0 run.result FM.ModelIO 405 103 0.0 0.0 0.0 0.0 run.timeTotal FM.ModelIO 404 103 0.0 0.0 0.0 0.0 run.retData FM.ModelIO 403 103 0.0 0.0 0.0 0.0 CAF GHC.Integer.Logarithms.Internals 343 0 0.0 0.0 0.0 0.0 CAF GHC.Float.ConversionUtils 340 0 0.0 0.0 0.0 0.0 CAF GHC.IO.Encoding.CodePage 327 0 0.0 0.0 0.0 0.0 CAF GHC.Conc.Windows 317 0 0.0 0.0 0.0 0.0 CAF GHC.TopHandler 315 0 0.0 0.0 0.0 0.0 CAF GHC.Float 312 0 0.0 0.0 0.0 0.0 CAF Data.Fixed 301 0 0.0 0.0 0.0 0.0 CAF GHC.IO.Handle.FD 299 0 0.0 0.0 0.0 0.0 CAF GHC.IO.Encoding 295 0 0.0 0.0 0.0 0.0 CAF GHC.IO.Exception 294 0 0.1 0.0 0.1 0.0 CAF Data.Text.Lazy.Builder.Int.Digits 282 0 0.0 0.0 0.0 0.0 CAF Data.Text.Lazy.Builder.Int 281 0 0.0 0.0 0.0 0.0 CAF Data.Text.Array 275 0 0.0 0.0 0.0 0.0 CAF Data.Text.Internal 274 0 0.0 0.0 0.0 0.0 CAF System.Locale 269 0 0.0 0.0 0.0 0.0 CAF Data.Scientific 268 0 0.0 0.0 0.0 0.0 CAF Data.Time.LocalTime.TimeOfDay 265 0 0.0 0.0 0.0 0.0 CAF Data.Time.Clock.POSIX 263 0 0.0 0.0 0.0 0.0 CAF Data.Aeson.Parser.Internal 256 0 0.0 0.0 0.0 0.0 array_ Data.Aeson.Parser.Internal 370 1 0.0 0.0 0.0 0.0 object_ Data.Aeson.Parser.Internal 367 1 0.0 0.0 0.0 0.0 CAF Blaze.ByteString.Builder.HTTP 249 0 0.0 0.0 0.0 0.0 CAF Network.HTTP.Types.Header 227 0 0.0 0.0 0.0 0.0 CAF Network.HTTP.Types.URI 226 0 0.0 0.0 0.0 0.0 CAF Network.HTTP.Types.Status 225 0 0.0 0.0 0.0 0.0 CAF Network.HTTP.Types.Method 224 0 0.0 0.0 0.0 0.0 CAF Network.Socket 220 0 0.0 0.0 0.0 0.0 CAF Network.Wai.Parse 211 0 0.0 0.0 0.0 0.0 CAF Network.Wai.Handler.Warp.RequestHeader 203 0 0.0 0.0 0.0 0.0 CAF Network.Wai.Handler.Warp.ResponseHeader 202 0 0.0 0.0 0.0 0.0 CAF Network.Wai.Handler.Warp.Date 199 0 0.0 0.0 0.0 0.0 CAF Network.Wai.Handler.Warp.Request 197 0 0.0 0.0 0.0 0.0 CAF Network.Wai.Handler.Warp.Response 196 0 0.0 0.0 0.0 0.0 CAF Network.Wai.Handler.Warp.Recv 194 0 0.0 0.0 0.0 0.0 CAF Network.Wai.Handler.Warp.Header 193 0 0.0 0.0 0.0 0.0 CAF Network.Wai.Handler.Warp.Types 191 0 0.0 0.0 0.0 0.0 CAF Network.Wai.Handler.Warp.Settings 189 0 0.0 0.0 0.0 0.0 CAF Web.Scotty.Trans 187 0 0.0 0.0 0.0 0.0 CAF Web.Scotty.Route 186 0 0.0 0.0 0.0 0.0 CAF Web.Scotty.Types 185 0 0.0 0.0 0.0 0.0 unstreamChunks/inner Data.Text.Lazy.Fusion 349 0 0.0 0.0 0.0 0.0 unstreamChunks/outer Data.Text.Lazy.Fusion 350 1 0.0 0.0 0.0 0.0 CAF Web.Scotty.Action 184 0 0.0 0.0 0.0 0.0 unstreamChunks/outer Data.Text.Lazy.Fusion 353 4 0.0 0.0 0.0 0.0 unstreamChunks/inner Data.Text.Lazy.Fusion 354 28 0.0 0.0 0.0 0.0 unstreamChunks/resize Data.Text.Lazy.Fusion 355 5 0.0 0.0 0.0 0.0 CAF Main 182 0 0.0 0.0 0.0 0.0 unstreamChunks/outer Data.Text.Lazy.Fusion 406 1 0.0 0.0 0.0 0.0 main.resultInt Main 360 1 0.0 0.0 0.0 0.0 main Main 344 1 0.0 0.0 0.0 0.0 go/Object Data.Aeson.Encode 357 1 0.0 0.0 0.0 0.0 go/Number Data.Aeson.Encode 361 1 0.0 0.0 0.0 0.0 string Data.Aeson.Encode 358 1 0.0 0.0 0.0 0.0 go/Number Data.Aeson.Encode 362 0 0.0 0.0 0.0 0.0 break Data.Aeson.Encode 359 1 0.0 0.0 0.0 0.0 unstreamChunks/outer Data.Text.Lazy.Fusion 346 10 0.0 0.0 0.0 0.0 unstreamChunks/inner Data.Text.Lazy.Fusion 347 104 0.0 0.0 0.0 0.0 unstreamChunks/resize Data.Text.Lazy.Fusion 348 20 0.0 0.0 0.0 0.0 CAF FM.Json 180 0 0.1 0.0 0.1 0.0 unstream/resize Data.Text.Fusion 356 14 0.0 0.0 0.0 0.0 CAF FM.ModelIO 179 0 0.0 0.0 0.0 0.0 getarray FM.ModelIO 409 0 0.0 0.0 0.0 0.0 getarray.rows FM.ModelIO 410 1 0.0 0.0 0.0 0.0 run.timeTot FM.ModelIO 399 1 0.0 0.0 0.0 0.0 run FM.ModelIO 397 1 0.0 0.0 0.0 0.0 run.runType FM.ModelIO 402 1 0.0 0.0 0.0 0.0 run.timeNow FM.ModelIO 401 1 0.0 0.0 0.0 0.0 run.timeTot FM.ModelIO 400 0 0.0 0.0 0.0 0.0 setmoduletable FM.ModelIO 377 0 0.0 0.0 0.0 0.0 setmoduletable.firstTimeStepAfterRestart FM.ModelIO 378 1 0.0 0.0 0.0 0.0 initfm FM.ModelIO 351 1 0.0 0.0 0.0 0.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.c.strahan at gmail.com Fri Apr 4 22:51:00 2014 From: charles.c.strahan at gmail.com (Charles Strahan) Date: Fri, 4 Apr 2014 18:51:00 -0400 Subject: [Haskell-cafe] Happybara Message-ID: Hey all, I've started a clone of the popular Ruby project "Capybara". Of course, it being written in Haskell, I just had to name it Happybara. It's in the early stages, but I think it's quickly coming together. Here's the mission plan: - Custom build hook to compile capybara-webkit's webkit_server (DONE) - High level interface to webkit_server (DONE) - Design Driver type-class, along with monadic DSL class - Queries/actions built atop the underlying Driver/DSL - Write instances/wrappers for hs-webdriver and others If you're interested, check out development here: https://github.com/cstrahan/happybara Oh, and a personal plug: who's hiring? :) -Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.dubuisson at gmail.com Fri Apr 4 23:54:07 2014 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Fri, 4 Apr 2014 16:54:07 -0700 Subject: [Haskell-cafe] Happybara In-Reply-To: References: Message-ID: For other ML readers who, like me, have never heard of from : "Capybara helps you test web applications by simulating how a real user would interact with your app." https://github.com/jnicklas/capybara On Fri, Apr 4, 2014 at 3:51 PM, Charles Strahan wrote: > Hey all, > > I've started a clone of the popular Ruby project "Capybara". Of course, it > being written in Haskell, I just had to name it Happybara. > > It's in the early stages, but I think it's quickly coming together. Here's > the mission plan: > > - Custom build hook to compile capybara-webkit's webkit_server (DONE) > - High level interface to webkit_server (DONE) > - Design Driver type-class, along with monadic DSL class > - Queries/actions built atop the underlying Driver/DSL > - Write instances/wrappers for hs-webdriver and others > > If you're interested, check out development here: > https://github.com/cstrahan/happybara > > > Oh, and a personal plug: who's hiring? :) > > -Charles > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From anacrolix at gmail.com Sat Apr 5 06:32:38 2014 From: anacrolix at gmail.com (Matt Joiner) Date: Sat, 5 Apr 2014 17:32:38 +1100 Subject: [Haskell-cafe] Ported a Python script for use with Go to Haskell Message-ID: It's been 3 years since my last attempt to use Haskell. I've ported a script from Python, I wonder if anyone might point out areas that I'm not doing things idiomatically for Haskell? I'm hoping to start using Haskell more in place of Go and Python. The Haskell script: http://pastebin.com/SxH3PXgG The original Python script if you're curious: http://pastebin.com/bqUVxB5d -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.oqube at gmail.com Sat Apr 5 06:32:37 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Sat, 5 Apr 2014 08:32:37 +0200 Subject: [Haskell-cafe] Haskell + emacs + Ghc-mod 4.0.1 In-Reply-To: <20140404.063024.573783403235305621.kazu@iij.ad.jp> References: <20140404.063024.573783403235305621.kazu@iij.ad.jp> Message-ID: <1AE112E3-EE4B-4FD2-9AC1-11F4C032C2CF@gmail.com> Thanks for your answer. hspec is installed actually: $ cabal install --only-dependencies Resolving dependencies... All the requested packages are already installed: Use --reinstall if you want to reinstall anyway. And yes, ?spec? is a typo, the error message appears as a tooltip in emacs so I cannot copy/paste it as text. I still do have the error however?. On 03 Apr 2014, at 23:30, Kazu Yamamoto (????) wrote: >> I upgrade my emacs configuration with latest ghc-mod and all of sudden >> nothing works (again). >> When I try to load a .hs file from a project I got the first line >> highlighted with the error "cannot satisfy -package spec" and I cannot got >> type, info or doc from that file. Also I do not have anymore syntax errors >> highlighting I used to see. > > As this message suggests, you need to install spec for testing. > > % cabal install spec > > # I don't know what the spec package is. A typo for hspec? > > This is because ghc-mod obtains dependency for executables, libraries > *and* testing. > > In general, > % cabal install --only-dependencies > would help you. > > --Kazu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From arnaud.oqube at gmail.com Sat Apr 5 07:03:41 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Sat, 5 Apr 2014 09:03:41 +0200 Subject: [Haskell-cafe] Haskell + emacs + Ghc-mod 4.0.1 In-Reply-To: <20140404.063024.573783403235305621.kazu@iij.ad.jp> References: <20140404.063024.573783403235305621.kazu@iij.ad.jp> Message-ID: OK, I forgot the ?enable-tests flag to cabal install? However, there seems to be some strange interactions I do not understand fully with the test section of cabal. Here is the cabal file: name: Thermometre version: 0.1.0.0 synopsis: synopsis -- description: license: PublicDomain license-file: LICENSE author: Black -- maintainer: -- copyright: -- category: build-type: Simple cabal-version: >= 1.8 library hs-source-dirs: src exposed-modules: Thermometre build-depends: base == 4.* test-suite spec type: exitcode-stdio-1.0 ghc-options: -Wall -Werror hs-source-dirs: test main-is: Spec.hs build-depends: base == 4.* , Thermometre , hspec >= 1.3 When I remove the test-suite section and open src/Thermometre.hs I got errors highlighting which is fine. C-c C-t does not give me types however ('Cannot guess type? message). When I leave the test-suite section then opening Thermometre.hs gives me a package error: ?cannot satisfy -package Thermometre? as there is a dependency from the tests to the main library. How can I solve that? Thanks Arnaud On 03 Apr 2014, at 23:30, Kazu Yamamoto (????) wrote: >> I upgrade my emacs configuration with latest ghc-mod and all of sudden >> nothing works (again). >> When I try to load a .hs file from a project I got the first line >> highlighted with the error "cannot satisfy -package spec" and I cannot got >> type, info or doc from that file. Also I do not have anymore syntax errors >> highlighting I used to see. > > As this message suggests, you need to install spec for testing. > > % cabal install spec > > # I don't know what the spec package is. A typo for hspec? > > This is because ghc-mod obtains dependency for executables, libraries > *and* testing. > > In general, > % cabal install --only-dependencies > would help you. > > --Kazu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ducis_cn at 126.com Sat Apr 5 07:39:45 2014 From: ducis_cn at 126.com (ducis) Date: Sat, 5 Apr 2014 15:39:45 +0800 (CST) Subject: [Haskell-cafe] What's the status of regular patterns? In-Reply-To: References: Message-ID: <28c9ac51.2777.14530d43668.Coremail.ducis_cn@126.com> The package description of haskell-src-exts says "Apart from these standard extensions, it also handles regular patterns as per the HaRP extension as well as HSX-style embedded XML syntax." So is this HaRP extension still alive in any way? The harp package seems to have nothing to do with syntax and long-abandoned. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvollmert-lists at gmx.net Sat Apr 5 10:21:14 2014 From: rvollmert-lists at gmx.net (Robert Vollmert) Date: Sat, 5 Apr 2014 12:21:14 +0200 Subject: [Haskell-cafe] Ported a Python script for use with Go to Haskell In-Reply-To: References: Message-ID: <5D6EA525-63B5-46A4-8869-2CE73BA593A0@gmx.net> On Apr 5, 2014, at 8:32 , Matt Joiner wrote: > It's been 3 years since my last attempt to use Haskell. I've ported a script from Python, I wonder if anyone might point out areas that I'm not doing things idiomatically for Haskell? I'm hoping to start using Haskell more in place of Go and Python. Hardly an expert here, but a couple of remarks: - try using ?span? (Prelude) for splitting the argument list - clobbering the environment by prepending to an association list makes me wonder if that?s really what happens when the variable is already defined - 'fmap rstrip (readProcess ?)? or ?rstrip <$> readProcess ?? instead of ?readProcess ? >>= return . rstrip? It does look like Haskell to my eyes. Cheers Rob From anacrolix at gmail.com Sat Apr 5 11:23:09 2014 From: anacrolix at gmail.com (Matt Joiner) Date: Sat, 5 Apr 2014 22:23:09 +1100 Subject: [Haskell-cafe] Ported a Python script for use with Go to Haskell In-Reply-To: <5D6EA525-63B5-46A4-8869-2CE73BA593A0@gmx.net> References: <5D6EA525-63B5-46A4-8869-2CE73BA593A0@gmx.net> Message-ID: Thanks very much. I'll look into fmap and <$>. On 05/04/2014 9:21 pm, "Robert Vollmert" wrote: > > On Apr 5, 2014, at 8:32 , Matt Joiner wrote: > > It's been 3 years since my last attempt to use Haskell. I've ported a > script from Python, I wonder if anyone might point out areas that I'm not > doing things idiomatically for Haskell? I'm hoping to start using Haskell > more in place of Go and Python. > > Hardly an expert here, but a couple of remarks: > > - try using ?span? (Prelude) for splitting the argument list > - clobbering the environment by prepending to an association list makes me > wonder if that?s really what happens when the variable is already defined > - 'fmap rstrip (readProcess ?)? or ?rstrip <$> readProcess ?? instead of > ?readProcess ? >>= return . rstrip? > > It does look like Haskell to my eyes. > > Cheers > Rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Sat Apr 5 11:33:51 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Sat, 5 Apr 2014 18:33:51 +0700 Subject: [Haskell-cafe] Ported a Python script for use with Go to Haskell In-Reply-To: <5D6EA525-63B5-46A4-8869-2CE73BA593A0@gmx.net> References: <5D6EA525-63B5-46A4-8869-2CE73BA593A0@gmx.net> Message-ID: On Sat, Apr 5, 2014 at 5:21 PM, Robert Vollmert wrote: > - clobbering the environment by prepending to an association list makes me > wonder if that's really what happens when the variable is already defined Yes, that does raise flags. The haskell here: installEnv <- getEnvironment >>= return . (:) ("GOBIN", gOBIN) which I'd probably write as installEnv <- (("GOBIN", gOBIN) :) <$> getEnvironment doesn't match the python here: GOBIN = tempfile.gettempdir() os.environ['GOBIN'] = GOBIN in the sense that the case for a predefined GOBIN in the environment will lead to different results. At least I'll be surprised if otherwise. To Matt: have you tested your haskell version? You might want to take a look at System.Posix.Env.putenv. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnw at fpcomplete.com Sat Apr 5 13:01:40 2014 From: johnw at fpcomplete.com (John Wiegley) Date: Sat, 05 Apr 2014 09:01:40 -0400 Subject: [Haskell-cafe] scotty + aeson + ffi: optimising performance In-Reply-To: (Miro Karpis's message of "Sat, 5 Apr 2014 00:17:04 +0200") References: Message-ID: >>>>> Miro Karpis writes: > I tried to profile it but so far I can see that the bottleneck is Aeson > (please correct me if I'm wrong). Is there a way how to optimise it? The > data I'm sending via JSON are very small, so that can not be the problem. Can you share any of your code with us? John From miroslav.karpis at gmail.com Sat Apr 5 13:31:38 2014 From: miroslav.karpis at gmail.com (Miro Karpis) Date: Sat, 5 Apr 2014 15:31:38 +0200 Subject: [Haskell-cafe] scotty + aeson + ffi: optimising performance In-Reply-To: References: Message-ID: sure, sorry should have done at the first place. Basically I have several similar calls like one below. This one should be the heaviest one. --scotty: post "/setmoduletable" $ do b <- body let queryString = tableArrayInDataToJSON b case queryString of Nothing -> text $ "error parsing json! " Just (ArrayDataIn tablename columnsCnt rowsCnt values) -> do result <- liftIO $ FM.setmoduletable tablename columnsCnt rowsCnt values let resultInt = fromIntegral $ result::Int json $ ReturnIntData resultInt --json conversions tableArrayInDataToJSON :: L.ByteString -> Maybe ArrayDataIn tableArrayInDataToJSON rawJson = retValue where json = decode rawJson :: Maybe ArrayDataIn retValue = case json of Nothing -> Nothing Just a -> Just a data ArrayDataIn = ArrayDataIn{ tablename :: !String ,columnscount :: Int ,rowscount :: Int ,values :: [Double] }deriving (Show,Generic) instance FromJSON ArrayDataIn instance ToJSON ArrayDataIn --ffi foreign import stdcall safe "setmoduletable" c_setmoduletable :: CString -> CInt -> Ptr CDouble -> CInt -> CInt -> CInt -> IO CInt setmoduletable :: String -> Int -> Int -> [Double] -> IO CInt setmoduletable param columns rows array = do let cParamLength = fromIntegral $ length param ::CInt cColumns = fromIntegral $ columns ::CInt cRows = fromIntegral $ rows ::CInt cTable = [realToFrac x ::CDouble | x <- array] firstTimeStepAfterRestart = 0::CInt cParam <- newCString param cTablePtr <- newArray cTable result <- c_setmoduletable cParam cParamLength cTablePtr cColumns cRows firstTimeStepAfterRestart free cTablePtr free cParam return result On Sat, Apr 5, 2014 at 3:01 PM, John Wiegley wrote: > >>>>> Miro Karpis writes: > > > I tried to profile it but so far I can see that the bottleneck is Aeson > > (please correct me if I'm wrong). Is there a way how to optimise it? The > > data I'm sending via JSON are very small, so that can not be the problem. > > Can you share any of your code with us? > > John > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mihai.maruseac at gmail.com Sat Apr 5 14:28:08 2014 From: mihai.maruseac at gmail.com (Mihai Maruseac) Date: Sat, 5 Apr 2014 10:28:08 -0400 Subject: [Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, May 2014 edition Message-ID: Dear all, I would like to collect contributions for the 24th edition of the ================================================================ Haskell Communities & Activities Report http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report Submission deadline: 1 May 2014 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format) ================================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough --- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell me, so that I can contact the project leaders and ask them to submit an entry. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the previous edition --- you will find interesting projects described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Mihai Maruseac and Alejandro Serrano Mena (current co-editors) FAQ: Q: What format should I write in? A: The required format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/05-2013/template.tex There is also a LaTeX style file at http://haskell.org/communities/05-2013/hcar.sty that you can use to preview your entry. If you do not know LaTeX, then use plain text. If you modify an old entry that you have written for an earlier edition of the report, you should already have received your old entry as a template (provided I have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Q: Can I include Haskell code? A: Yes. Please use lhs2tex syntax (http://people.cs.uu.nl/andres/lhs2tex/). The report is compiled in mode polycode.fmt. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg format, then. Q: Should I send files in .zip archives or similar? A: No, plain file attachements are the way. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or "historic" overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also ask the editor. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell the editor that there are no changes. The old entry will typically be reused in this case, but it might be dropped if it is older than a year, to give more room and more attention to projects that change a lot. Do not resend complete entries if you have not changed them. Q: Will I get confirmation if I send an entry? How do I know whether my email has even reached the editor, and not ended up in a spam folder? A: Prior to publication of the final report, the editor will send a draft to all contributors, for possible corrections. So if you do not hear from the editor within two weeks after the deadline, it is safer to send another mail and check whether your first one was received. -- Mihai Maruseac (MM) "If you don't know, the thing to do is not to get scared, but to learn." -- Atlas Shrugged. From andrew.gibiansky at gmail.com Sat Apr 5 15:48:33 2014 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Sat, 5 Apr 2014 08:48:33 -0700 Subject: [Haskell-cafe] Ported a Python script for use with Go to Haskell In-Reply-To: References: <5D6EA525-63B5-46A4-8869-2CE73BA593A0@gmx.net> Message-ID: The script itself looks pretty good to me, but you might want to take a look at Shelly [0] for Haskell scripting in the future. It's a really nice library / DSL for "bash"-like scripting directly in Haskell. If you try out Shelly, I suggest trying it with ClassyPrelude and -XOverloadedStrings, which makes dealing with all the Text and FilePath types bearable. (Heh, though it's annoying, having FilePath as a separate type once prevented me from writing code that deleted my home directory upon being run... fun story.) [0] https://hackage.haskell.org/package/shelly On Sat, Apr 5, 2014 at 4:33 AM, Kim-Ee Yeoh wrote: > > On Sat, Apr 5, 2014 at 5:21 PM, Robert Vollmert wrote: > >> - clobbering the environment by prepending to an association list makes >> me wonder if that's really what happens when the variable is already defined > > > Yes, that does raise flags. > > The haskell here: > > installEnv <- getEnvironment >>= return . (:) ("GOBIN", gOBIN) > > which I'd probably write as > > installEnv <- (("GOBIN", gOBIN) :) <$> getEnvironment > > doesn't match the python here: > > GOBIN = tempfile.gettempdir() > os.environ['GOBIN'] = GOBIN > > in the sense that the case for a predefined GOBIN in the environment will > lead to different results. At least I'll be surprised if otherwise. > > To Matt: have you tested your haskell version? You might want to take a > look at System.Posix.Env.putenv. > > -- Kim-Ee > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anacrolix at gmail.com Sat Apr 5 16:17:52 2014 From: anacrolix at gmail.com (Matt Joiner) Date: Sun, 6 Apr 2014 02:17:52 +1000 Subject: [Haskell-cafe] Ported a Python script for use with Go to Haskell In-Reply-To: References: <5D6EA525-63B5-46A4-8869-2CE73BA593A0@gmx.net> Message-ID: I considered the same thing with an existing GOBIN env var. I did actually test it and found it worked as expected. Items earlier in the list seem to have higher priority. I prefer not to use setenv, because I want to exec into the binary later without GOBIN clobbered, which means keeping the current environment pristine. Good point about it not matching the Python version, but then a few other things don't either now. :) Here's the latest version: http://pastebin.com/EejABjpR Something I can't get my head around: On line 50-52, I have a function that returns the result of getting the current directory (curDir) joined with the package path (maybeToList package). Is there someway to get the current directory without having to store the action the way that I am doing? <$> would work if the current directory was the last argument to the joinPath, but here it's the first. Thanks so much for your help. On Sun, Apr 6, 2014 at 2:48 AM, Andrew Gibiansky wrote: > The script itself looks pretty good to me, but you might want to take a > look at Shelly [0] for > Haskell scripting in the future. It's a really nice library / DSL for > "bash"-like scripting directly in Haskell. If you try out Shelly, I suggest > trying it with ClassyPrelude and -XOverloadedStrings, which makes dealing > with all the Text and FilePath types bearable. (Heh, though it's annoying, > having FilePath as a separate type once prevented me from writing code that > deleted my home directory upon being run... fun story.) > > [0] https://hackage.haskell.org/package/shelly > > > On Sat, Apr 5, 2014 at 4:33 AM, Kim-Ee Yeoh wrote: > >> >> On Sat, Apr 5, 2014 at 5:21 PM, Robert Vollmert wrote: >> >>> - clobbering the environment by prepending to an association list makes >>> me wonder if that?s really what happens when the variable is already defined >> >> >> Yes, that does raise flags. >> >> The haskell here: >> >> installEnv <- getEnvironment >>= return . (:) ("GOBIN", gOBIN) >> >> which I'd probably write as >> >> installEnv <- (("GOBIN", gOBIN) :) <$> getEnvironment >> >> doesn't match the python here: >> >> GOBIN = tempfile.gettempdir() >> os.environ['GOBIN'] = GOBIN >> >> in the sense that the case for a predefined GOBIN in the environment will >> lead to different results. At least I'll be surprised if otherwise. >> >> To Matt: have you tested your haskell version? You might want to take a >> look at System.Posix.Env.putenv. >> >> -- Kim-Ee >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Sat Apr 5 16:36:40 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Sat, 5 Apr 2014 23:36:40 +0700 Subject: [Haskell-cafe] Ported a Python script for use with Go to Haskell In-Reply-To: References: <5D6EA525-63B5-46A4-8869-2CE73BA593A0@gmx.net> Message-ID: On Sat, Apr 5, 2014 at 11:17 PM, Matt Joiner wrote: > I considered the same thing with an existing GOBIN env var. I did actually > test it and found it worked as expected. Omg, color me surprised! > Items earlier in the list seem to have higher priority. I'd drill deeper into this to find out why if I had the time, but in any case, are you sure you want to rely on such brittle, undocumented behavior? Goerzen's MissingH has an addToAL that's perfect for the job: origEnv <- getEnvironment let clobberedEnv = addToAL origEnv "GOBIN" dest I prefer not to use setenv, because I want to exec into the binary later > without GOBIN clobbered, which means keeping the current environment > pristine. Good point about it not matching the Python version, but then a > few other things don't either now. :) Fair enough. :) -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Sat Apr 5 19:34:35 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Sat, 5 Apr 2014 21:34:35 +0200 Subject: [Haskell-cafe] vim-hsimport: only consider modules of direct dependencies Message-ID: <20140405193435.GA27823@machine> Hi all, vim-hsimport[1] is a vim plugin that is able to automatically extend the import list of a haskell source file for the symbol under the cursor. It uses hdevtools[2] for finding the symbol in the modules of the installed packages and hsimport[3] for extending the import list. Until now vim-hsimport did consider all packages a project depends on, even if the package was only an indirect dependecy, not listed in the 'build-depends' field. So e.g. if a project directly and indirectly depends on the packages: base, containers, bytestring, binary, text and vector, and the modules for symbol 'foldl' have been requested, then the list of found modules might have been: Data.IntMap Data.IntMap.Lazy Data.IntMap.Strict Data.IntSet Data.Map Data.Map.Lazy Data.Map.Strict Data.Set Data.ByteString Data.ByteString.Char8 Data.ByteString.Lazy Data.ByteString.Lazy.Char8 Codec.Binary.UTF8.Generic Data.String.UTF8 Data.ByteString.UTF8 Data.ByteString.Lazy.UTF8 Data.Text Data.Text.Internal.Fusion.Common Data.Text.Lazy GHC.List Data.Foldable Data.List Prelude Data.Vector.Fusion.Stream.Monadic Data.Vector.Fusion.Stream Data.Vector.Generic Data.Vector.Primitive Data.Vector.Storable Data.Vector.Unboxed Data.Vector But if the project depends directly only on the packages: base and text, then only these modules are really relevant: Data.Text Data.Text.Internal.Fusion.Common Data.Text.Lazy GHC.List Data.Foldable Data.List Prelude This can be now achieved by using cabal-cargs[4] (>= 0.4) for the configuration of hdevtools. Please read the README[5] for detailed instructions. (One might argue, that even the modules Data.Text.Internal.Fusion.Common, GHC.List and Prelude might be left out, but that's another issue.) You might be also interested in a new feature of the 0.3 versions of hsimport and vim-hsimport. Before that version types have been always imported like: import SomeModule (Type) Now there's the option to choose between importing only the type or also importing all constructors/functions of the type: import SomeModule (Type(..)) If you're using hdevtools with the vim plugin syntastic[6] and have projects containing multiple sections (library/executable/testsuite ...) and each section has a separate 'hs-source-dirs', then you might get a more robust hdevtools behaviour by using this little change[7]. Happy Haskell hacking! :) Greetings, Daniel [1] https://github.com/dan-t/vim-hsimport [2] https://github.com/bitc/hdevtools [3] https://github.com/dan-t/hsimport [4] https://github.com/dan-t/cabal-cargs [5] https://github.com/dan-t/vim-hsimport/blob/master/README.md [6] https://github.com/scrooloose/syntastic [7] https://github.com/dan-t/syntastic/commit/7bd9b98342c93b7c7b06ddea19949233190106ce From anacrolix at gmail.com Sun Apr 6 06:31:25 2014 From: anacrolix at gmail.com (Matt Joiner) Date: Sun, 6 Apr 2014 16:31:25 +1000 Subject: [Haskell-cafe] Can I write this function without doing the action on a different line? Message-ID: 1. packageBase <- do 2. curDir <- getCurrentDirectory 3. return . last . splitDirectories . normalise . joinPath $ curDir:maybeToList package -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at karlv.net Sun Apr 6 07:15:05 2014 From: karl at karlv.net (Karl Voelker) Date: Sun, 06 Apr 2014 00:15:05 -0700 Subject: [Haskell-cafe] Can I write this function without doing the action on a different line? In-Reply-To: References: Message-ID: <1396768505.3793.103240905.1D9BD1F4@webmail.messagingengine.com> On Sat, Apr 5, 2014, at 11:31 PM, Matt Joiner wrote: 1. packageBase <- do 2. curDir <- getCurrentDirectory 3. return . last . splitDirectories . normalise . joinPath $ curDir:ma ybeToList package Sure. The most obvious transformation to me would have these three steps: 1. The right argument of (:) isn't coming from a monadic action, so you can extract it as a section and move it to your big long chain of compositions: return . last . splitDirectories . normalise . joinPath . (: maybeToList package) $ curDir 2. Get rid of the binding of curDir: getCurrentDirectory >>= return . last . splitDirectories . normalise . joinPath . (: maybeToList package) 3. Notice that the right argument of (>>=) really isn't using your monad, so you could use fmap or (<$>) (assuming this is a well-behaved monad which also has a Functor instance): last . splitDirectories . normalise . joinPath . (: maybeToList package) <$> getCurrentDirectory Fair warning: I'm tired and not type-checking this. But it looks right to me. -Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Sun Apr 6 16:00:21 2014 From: trebla at vex.net (Albert Y. C. Lai) Date: Sun, 06 Apr 2014 12:00:21 -0400 Subject: [Haskell-cafe] GHC and platform versions In-Reply-To: <20140330165354.55d3aaef.itz@buug.org> References: <20140330165354.55d3aaef.itz@buug.org> Message-ID: <53417A15.4000606@vex.net> On 14-03-30 07:53 PM, Ian Zimmerman wrote: > On the Haskell Platform webpage, it tells me what GHC version I need > for the latest/current version of the platform. Also, there are links > to downloads for prior versions of the platform. But, how can I find > out what GHC version I need for one of those older platform versions? > That information doesn't seem to be on the page, and I see no README or > similar file in the platform source tarball itself. My http://www.vex.net/~trebla/haskell/haskell-platform.xhtml records the historical mapping. From nick.rudnick at gmail.com Sun Apr 6 18:22:44 2014 From: nick.rudnick at gmail.com (Nick Rudnick) Date: Sun, 6 Apr 2014 20:22:44 +0200 Subject: [Haskell-cafe] c2hs: E.g. #include OK in *.cpp's, but not in *.h's Message-ID: Dear all, maybe this is a piece of c2hs behaviour I missed to understand, but it appears happening with C++ style includes deep in the header call hierarchy ? in case of a such backend C++ library, if one wishes to refer to by *.h's in c2hs (e.g. for access to types of it), one might have a problem. - 8< cSample.h --------------------------------------------- #include ///////// here, with c2hs, leading to build abort #ifdef __cplusplus extern "C" { #endif void sampleFunction(); #ifdef __cplusplus } #endif - 8< cSample.cpp --------------------------------------------- #include "cSample.h" #include ///////// here no problem void sampleFunction(){ std::cout << "OK" << std::endl; } - 8< ---------------------------------------------------------------- While 'old school' FFI (foreign import ccall) handles this effortlessly, c2hs uses to abort with an exception like C/cSample.h:3:20: fatal error: iostream: No such file or directory compilation terminated. I see that hsqml gets around this, but apparently by tweaking Setup.hs in a way not quite trivial ? would this be necessary in any case, or are there simpler alternatives? Please excuse if I oversaw something, but I am afraid I didn't see this interesting issue covered elsewhere. Thank you a lot in advance & cheers, Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Mon Apr 7 03:41:30 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 07 Apr 2014 04:41:30 +0100 Subject: [Haskell-cafe] ANN: Simon Marlow & Edward Kmett @ ZuriHac 2014 In-Reply-To: References: Message-ID: <53421E6A.8090806@fuuzetsu.co.uk> On 14/02/14 15:52, Bas van Dijk wrote: > Dear Haskellers and ZuriHac 2014 attendees, > > On this lovely day (pun intended), I'm excited to announce that Simon > Marlow and Edward Kmett will be giving talks at ZuriHac 2014. > > When: Friday 6 June 2014 - Sunday 8 June 2014 > Where: Erudify offices, Zurich, Switzerland > > ZuriHac is an international Haskell hackathon: a grassroots, > collaborative coding festival with a simple focus, to build and > improve Haskell libraries, tools, and infrastructure. > > This is a great opportunity to meet your fellow Haskellers in real > life, find new contributors for your project, improve existing > libraries and tools, or even start new ones! > > 30 people already signed up for ZuriHac 2014 but there's still room > for more. If you wish to attend, please register by filling in this > form: > > http://bit.ly/ZuriHac2014 > > Full details can be found on the wiki page: > > http://www.haskell.org/haskellwiki/ZuriHac2014 > > We look forward to seeing you there! > > -- The organisers of ZuriHac 2014 > > ZuriHac 2014 is sponsored by Erudify & Google > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Hi again, Is there a deadline by when we have to confirm our attendance? I might be able to make it but I won't know until much closer to the date, no sooner than May at least. Thanks -- Mateusz K. From sean at functionaljobs.com Mon Apr 7 06:00:06 2014 From: sean at functionaljobs.com (Functional Jobs) Date: Mon, 7 Apr 2014 02:00:06 -0400 Subject: [Haskell-cafe] New Functional Programming Job Opportunities Message-ID: <53423eed8da5f@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Server Game Developer at Quark Games http://functionaljobs.com/jobs/8701-server-game-developer-at-quark-games Infrastructure Engineer at Zeta Project Germany GmbH http://functionaljobs.com/jobs/8699-infrastructure-engineer-at-zeta-project-germany-gmbh Cheers, Sean Murphy FunctionalJobs.com From oleg at okmij.org Mon Apr 7 06:07:03 2014 From: oleg at okmij.org (oleg at okmij.org) Date: 7 Apr 2014 06:07:03 -0000 Subject: [Haskell-cafe] Second CFP: Higher-order, Typed, Inferred, Strict: ML Family Workshop Message-ID: <20140407060703.60603.qmail@www1.g3.pair.com> Higher-order, Typed, Inferred, Strict: ACM SIGPLAN ML Family Workshop Thursday September 4, 2014, Gothenburg, Sweden (immediately following ICFP and preceding OCaml Users and Developers Workshop) Call For Papers http://okmij.org/ftp/ML/ML14.html News: Post-proceedings will be published in EPTCS ML is a very large family of programming languages that includes Standard ML, OCaml, F#, SML#, Manticore, MetaOCaml, JoCaml, Alice ML, Dependent ML, Flow Caml, and many others. All ML languages, beside the great deal of syntax, share several fundamental traits. They are all higher-order, strict, mostly pure, and typed, with algebraic and other data types. Their type systems inherit from Hindley-Milner. The development of these languages has inspired a significant amount of computer science research and influenced a number of programming languages, including Haskell, Scala and Clojure, as well as Rust, ATS and many others. ML workshops have been held in affiliation with ICFP continuously since 2005. This workshop specifically aims to recognize the entire extended ML family and to provide the forum to present and discuss common issues, both practical (compilation techniques, implementations of concurrency and parallelism, programming for the Web) and theoretical (fancy types, module systems, metaprogramming). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Scala, Rust, Nemerle, ATS, etc.), to exchange experience of further developing ML ideas. The ML family workshop will be held in close coordination with the OCaml Users and Developers Workshop. Format Since 2010, the ML workshop has adopted an informal model. Presentations are selected from submitted abstracts. There are no published proceedings, so any contributions may be submitted for publication elsewhere. We hope that this format encourages the presentation of exciting (if unpolished) research and deliver a lively workshop atmosphere. Each presentation should take 20-25 minutes, except demos, which should take 10-15 minutes. The exact time will be decided based on the number of accepted submissions. The presentations will likely be recorded. Post-conference proceedings The post-proceedings of selected papers from the ML Family and the OCaml Users and Developers workshops will be published in the Electronic Proceedings in Theoretical Computer Science (EPTCS). The Program Committee shall invite interested authors of selected presentations to expand their abstract for inclusion in the proceedings. The submissions are to be reviewed according to the EPTCS standards. Coordination with the OCaml Users and Developers Workshop The OCaml workshop is seen as more practical and is dedicated in significant part to the OCaml community building and the evolution of the OCaml system. In contrast, the ML family workshop is not focused on any language in particular, is more research oriented, and deals with general issues of the ML-style programming and type systems. Yet there is an overlap, which we are keen to explore in various ways. The authors who feel their submission fits both workshops are encouraged to mention it at submission time or contact the Program Chairs. Scope We acknowledge the whole breadth of the ML family and aim to include languages that are closely related (although not by blood), such as Rust, ATS, Scala, Typed Clojure. Those languages have implemented and investigated run-time and type system choices that may be worth considering for OCaml, F# and other ML languages. We also hope that the exposure to the state of the art ML might favorably influence those related languages. Specifically, we seek research presentations on topics including but not limited to * Design: concurrency, distribution and mobility, programming for the web and embedded systems, handling semi-structured data, facilitating interactive programming, higher forms of polymorphism, generic programming, objects * Implementation: compilation techniques, interpreters, type checkers, partial evaluators, runtime systems, garbage collectors, etc. * Type systems: fancy types, inference, effects, overloading, modules, contracts, specifications and assertions, dynamic typing, error reporting, etc. * Applications: case studies, experience reports, pearls, etc. * Environments: libraries, tools, editors, debuggers, cross-language interoperability, functional data structures, etc. * Education: ML and ML-like languages in college or high-school, in general or computer science curriculum. Four kinds of submissions will be accepted: Informed Positions, Research Presentations, Experience Reports and Demos. * Informed Positions: A justified argument for or against a language feature. The argument must be substantiated, either theoretically (e.g., by a demonstration of (un)soundness, an inference algorithm, a complexity analysis), empirically or by a substantial experience. Personal experience is accepted as justification so long as it is extensive and illustrated with concrete examples. * Research Presentations: Research presentations should describe new ideas, experimental results, or significant advances in ML-related projects. We especially encourage presentations that describe work in progress, that outline a future research agenda, or that encourage lively discussion. These presentations should be structured in a way which can be, at least in part, of interest to (advanced) users. * Experience Reports: Users are invited to submit Experience Reports about their use of ML and related languages. These presentations do not need to contain original research but they should tell an interesting story to researchers or other advanced users, such as an innovative or unexpected use of advanced features or a description of the challenges they are facing or attempting to solve. * Demos: Live demonstrations or short tutorials should show new developments, interesting prototypes, or work in progress, in the form of tools, libraries, or applications built on or related to ML. (You will need to provide all the hardware and software required for your demo; the workshop organizers are only able to provide a projector.) Important dates Monday May 19 (any time zone): Abstract submission Monday June 30: Author notification Thursday September 4, 2014: ML Family Workshop Submission Submissions should be at most two pages, in PDF format, and printable on US Letter or A4 sized paper. A submission should have a synopsis (2-3 lines) and a body between 1 and 2 pages, in one- or two-column layout. The synopsis should be suitable for inclusion in the workshop program. Submissions must be uploaded to the workshop submission website before the submission deadline (Monday May 19, 2014). For any question concerning the scope of the workshop or the submission process, please contact the program chair. Program Committee Kenichi Asai Ochanomizu University, Japan Matthew Fluet Rochester Institute of Technology, USA Jacques Garrigue Nagoya University, Japan Dave Herman Mozilla, USA Stefan Holdermans Vector Fabrics, Netherlands Oleg Kiselyov (Chair) Monterey, CA, USA Keiko Nakata Tallinn University of Technology, Estonia Didier Remy INRIA Paris-Rocquencourt, France Zhong Shao Yale University, USA Hongwei Xi Boston University, USA From csaba.hruska at gmail.com Mon Apr 7 08:55:55 2014 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Mon, 7 Apr 2014 10:55:55 +0200 Subject: [Haskell-cafe] ANN: Budapest Hackathon 2014 Message-ID: Dear Haskellers, We're organizing the first ever Haskell Hackathon in Budapest, Hungary. When: Saturday 31 May 2014 - Sunday 1 June 2014 This will be a great opportunity to meet up with fellow Haskellers, and show off your cool hobby projects in one of the most vibrant cities in Europe. There's also room for working on existing tools, for example you can team up with Luite Stegeman at the event to hack on GHC-JS. Details about the when, where and how: http://www.haskell.org/haskellwiki/BudapestHackathon2014 See you all there! -------------- next part -------------- An HTML attachment was scrubbed... URL: From khushil.dep at gmail.com Mon Apr 7 09:40:50 2014 From: khushil.dep at gmail.com (Khushil Dep (Sphonic)) Date: Mon, 7 Apr 2014 10:40:50 +0100 Subject: [Haskell-cafe] Functional Software Engineering Posts Message-ID: <2B8CA4F2-4192-4EC7-96E2-C3E0F72FD14B@sphonic.com> Symphonic Solutions Ltd (www.sphonic.com) is a disruptive technology company that leverages functional paradigms to enable engineered innovation. In real terms, we build high performance, low latency platforms that integrate to a plethora of third party API?s and apply intelligent manipulation and analysis to the data via a DSL. We help turn ?Big Data? into ?Useful Information?. We also don?t use Hadoop - which is nice. We?re looking for software engineers who understand the functional domain extremely well. Ideally you will be a polyglot software engineer with skills and at least twelve months (commercial) experience in Scala (with with Akka) || Clojure || Haskell || NodeJS. We run all of these in production so it?s important you understand the difference between experimentation and production quality code. You should also be able to at least read one of either Python, Bash or C. We don?t allow Ruby anywhere on our platform so you should be comfortable about that. We?re looking for people who want to live the functional dream, not people who think it?s a ?nice to have? on their C.V please. You should understand the sympathetic orchestration of human, software, operating system and hardware. You should also be able to translate complex functional requirements into simple, well composed programs which work in concert to produce the desired result. Experience in working within a micro-services architecture will be looked on very favourably. We are flexible on working locations, including home working, with a London office based near Edgware Road station. During the early phases of engineering design some time in the office will be a necessity however and you should be comfortable about that. You should be able to work independently and within a wider team as well as manage your time such that your responsibilities in each sprint are delivered to a high quality and in a timely manner. You?ll be expected and empowered to make software design choices specific to your responsibilities in concert with the platform engineering team. You should be happy to work within an agile project management framework which supports Kanban. You should be familiar with working with JIRA, Confluence and Git. You will be expected to produce documentation around your sprint responsibilities which deliver a high level of knowledge retention and transfer. Your programs will be run on SmartOS platforms and so you should be able to build technology agnostic programs. In simple terms you should be happy not to rely on any operating system specific functionality in order to write your programs. You will be trained in technologies such as DTrace to better aid your diagnostic efforts. You will be provided with local build environments based off Vagrant which you should be happy to manage yourself though training and support from engineering will be available at all times. If this interests you, in the first instance, please answer the following questions : Question 1 Explain the relationship between the human and the machine. Describe the relationship in as much detail as you feel comfortable with. Question 2 Explain tail recursion to a 5 year old. Question 3 Explain how you would manage state in a functional manner to a 5 year old. We expect that you have public GitHub/Bitbucket repo?s sharing your work and/or research with functional languages and programs so please also send your GitHub/Bitbucket handle with your answers.Please send your answers and whatever you have of a C.V. to jobs at sphonic.com. --- Khushil Dep Head Of Engineering Symphonic Solutions Ltd khushildep at sphonic.com 07799908654 07415372737 From ian at skybluetrades.net Mon Apr 7 12:04:42 2014 From: ian at skybluetrades.net (Ian Ross) Date: Mon, 7 Apr 2014 14:04:42 +0200 Subject: [Haskell-cafe] c2hs: E.g. #include OK in *.cpp's, but not in *.h's In-Reply-To: References: Message-ID: Hi Nick, As far as I can tell from a quick look at hsqml, the stuff in Setup.hs isn't related to C2HS. What's more relevant is that hsqml defines a C library wrapper around the C++ library it uses -- C2HS is only used on that C wrapper, not on the C++ library itself. In general, C2HS doesn't support C++ at all, because it needs to be able to parse the header files that it includes and we use the C parser from the languagge-c package to do that. Any C++ constructs will just cause breakage. And your "old school" FFI definition doesn't look in any header files, which is why it has no trouble. Basically, if you want to do something like what hsqml does, just take a look in the cbits directory there, in particular at hsqml.h which is the header that defines the C wrapper around the C++ library. This hsqml.h header is the one that's included in the C2HS files. If you want to wrap a C++ library directly, C2HS probably isn't the tool for the job. I know there was some work during the last GSOC on a C++ FFI wrapper, but I don't know if anything concrete came of it. Cheers, Ian. On 6 April 2014 20:22, Nick Rudnick wrote: > Dear all, > > maybe this is a piece of c2hs behaviour I missed to understand, but it > appears happening with C++ style includes deep in the header call hierarchy > - in case of a such backend C++ library, if one wishes to refer to by *.h's > in c2hs (e.g. for access to types of it), one might have a problem. > > - 8< cSample.h --------------------------------------------- > #include ///////// here, with c2hs, leading to build abort > #ifdef __cplusplus > extern "C" { > #endif > void sampleFunction(); > #ifdef __cplusplus > } > #endif > - 8< cSample.cpp --------------------------------------------- > #include "cSample.h" > #include ///////// here no problem > > void sampleFunction(){ > std::cout << "OK" << std::endl; > } > - 8< ---------------------------------------------------------------- > > While 'old school' FFI (foreign import ccall) handles this effortlessly, > c2hs uses to abort with an exception like > C/cSample.h:3:20: fatal error: iostream: No such file or directory > compilation terminated. > > I see that hsqml gets around this, but apparently by tweaking Setup.hs in > a way not quite trivial - would this be necessary in any case, or are there > simpler alternatives? > > Please excuse if I oversaw something, but I am afraid I didn't see this > interesting issue covered elsewhere. > > Thank you a lot in advance & cheers, Nick > > > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Ian Ross Tel: +43(0)6804451378 ian at skybluetrades.net www.skybluetrades.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ifigueroap at gmail.com Mon Apr 7 12:57:29 2014 From: ifigueroap at gmail.com (Ismael Figueroa) Date: Mon, 7 Apr 2014 14:57:29 +0200 Subject: [Haskell-cafe] Domain Events in haskell In-Reply-To: <1396004383.91685.YahooMailNeo@web171906.mail.ir2.yahoo.com> References: <1396004383.91685.YahooMailNeo@web171906.mail.ir2.yahoo.com> Message-ID: Hi Rouan, I recently developed the effective-aspects package [1], which is a library for monadic pointcut/advice aspect-oriented programming (AOP) in Haskell. Essentially we keep track of the aspects (handlers if you think in terms of event-based programming) in a pure state monad. My problem is that the publish method returns IO (), which means that > events can only be > published from the IO monad, but I would like events to be 'publish-able' > from pure code. In the library, you must define a monad with the AOT transformer on top, say type M = AOT IO type M' = AOT (StateT String (ErrorT String Identity)) ... Our model is not tied to the IO monad (rather to an 'AOMonad' class that provides weaving); hence it does supports pure events (join points in AOP terminology). A pseudo-code example is: -- foo has type A -> m B for some types A, B and monad m -- adv has type Advice (A -> m B); which is a type synonym for (A -> m B) -> A -> m B do (deploy (aspect (pcCall foo) adv)) foo # arg here the # is the 'open application' operator, which triggers the weaving process that eventually executes the advice. The main publication of this work can be found here: http://hal.archives-ouvertes.fr/docs/00/87/27/82/PDF/TAOSD-EffectiveAspects.pdf I think your particular use case is not described in your email, but if you want to expose some content other than the application's arguments it will need some small work on my part (and a new version of the library). I will be pleased to help you if you are interested in using the library, and if you can wait a little--- I'm really time-constrained this month :) Bests, [1] http://hackage.haskell.org/package/effective-aspects 2014-03-28 11:59 GMT+01:00 Rouan van Dalen : > Hi Cafe, > > I am trying to write a very simple implementation of an event publisher > pattern but I am stuck and do > not know how to do this in Haskell. > > I have the following code: > > ======================== > > > {-# LANGUAGE RankNTypes, NamedFieldPuns #-} > > module Domain.DomainEventPublisher where > > import Control.Monad (forM_) > > import HsFu.Data.DateTime > import Domain.Client > > > data DomainEvent = ClientChangeAgeDomainEvent > > > data DomainEventContext = > DomainEventContext { domainEventContext_event :: DomainEvent > , domainEventContext_occurredOn :: DateTime > } deriving (Show) > > > data DomainEventPublisher = DomainEventPublisher { > domainEventPublisher_subscribers :: [DomainEventContext -> IO ()] } > > > mkEventPublisher :: DomainEventPublisher > mkEventPublisher = DomainEventPublisher [] > > > subscribe :: DomainEventPublisher -> (DomainEventContext -> IO ()) -> > DomainEventPublisher > subscribe publisher eventHandler = > DomainEventPublisher { domainEventPublisher_subscribers = > eventHandler : (domainEventPublisher_subscribers publisher) } > > > publish :: DomainEventPublisher -> DomainEventContext -> IO () > publish DomainEventPublisher{ domainEventPublisher_subscribers } event = > forM_ domainEventPublisher_subscribers ($ event) > > ======================== > > > My problem is that the publish method returns IO (), which means that > events can only be > published from the IO monad, but I would like events to be 'publish-able' > from pure code. > > I can live with event handlers (passed into the subscribe function) being > in the IO monad. > > Is there a better way to implement this pattern in Haskell? > > I have been racking my brain on this for a while now and cannot seem to > come up with a > good implementation. > > Regards > --Rouan. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Ismael -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.rudnick at gmail.com Mon Apr 7 13:33:52 2014 From: nick.rudnick at gmail.com (Nick Rudnick) Date: Mon, 7 Apr 2014 15:33:52 +0200 Subject: [Haskell-cafe] Fwd: c2hs: E.g. #include OK in *.cpp's, but not in *.h's In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Nick Rudnick Date: 2014-04-07 15:28 GMT+02:00 Subject: Re: [Haskell-cafe] c2hs: E.g. #include OK in *.cpp's, but not in *.h's To: Ian Ross Hi Ian, thanks for clearing up :-) So you mean the trick of hsqml primarily is (A) dummy typedefs to char, e.g.: typedef char HsQMLStringHandle; (B) 'extern' sigantures, e.g.: extern void hsqml_init_string(HsQMLStringHandle*); THIS WORKS... Occasionally, one might use two headers, e.g. a *.hpp as actual C++ header neither listed in the *.cabal nor the *.chs, where instead it would be represented by a *.h, as described above. No more...?? Thanks and cheers, Nick 2014-04-07 14:04 GMT+02:00 Ian Ross : Hi Nick, > > As far as I can tell from a quick look at hsqml, the stuff in Setup.hs > isn't related to C2HS. What's more relevant is that hsqml defines a C > library wrapper around the C++ library it uses -- C2HS is only used on that > C wrapper, not on the C++ library itself. In general, C2HS doesn't support > C++ at all, because it needs to be able to parse the header files that it > includes and we use the C parser from the languagge-c package to do that. > Any C++ constructs will just cause breakage. And your "old school" FFI > definition doesn't look in any header files, which is why it has no trouble. > > Basically, if you want to do something like what hsqml does, just take a > look in the cbits directory there, in particular at hsqml.h which is the > header that defines the C wrapper around the C++ library. This hsqml.h > header is the one that's included in the C2HS files. If you want to wrap a > C++ library directly, C2HS probably isn't the tool for the job. I know > there was some work during the last GSOC on a C++ FFI wrapper, but I don't > know if anything concrete came of it. > > Cheers, > > Ian. > > > > On 6 April 2014 20:22, Nick Rudnick wrote: > >> Dear all, >> >> maybe this is a piece of c2hs behaviour I missed to understand, but it >> appears happening with C++ style includes deep in the header call hierarchy >> ? in case of a such backend C++ library, if one wishes to refer to by *.h's >> in c2hs (e.g. for access to types of it), one might have a problem. >> >> - 8< cSample.h --------------------------------------------- >> #include ///////// here, with c2hs, leading to build abort >> #ifdef __cplusplus >> extern "C" { >> #endif >> void sampleFunction(); >> #ifdef __cplusplus >> } >> #endif >> - 8< cSample.cpp --------------------------------------------- >> #include "cSample.h" >> #include ///////// here no problem >> >> void sampleFunction(){ >> std::cout << "OK" << std::endl; >> } >> - 8< ---------------------------------------------------------------- >> >> While 'old school' FFI (foreign import ccall) handles this effortlessly, >> c2hs uses to abort with an exception like >> C/cSample.h:3:20: fatal error: iostream: No such file or directory >> compilation terminated. >> >> I see that hsqml gets around this, but apparently by tweaking Setup.hs in >> a way not quite trivial ? would this be necessary in any case, or are there >> simpler alternatives? >> >> Please excuse if I oversaw something, but I am afraid I didn't see this >> interesting issue covered elsewhere. >> >> Thank you a lot in advance & cheers, Nick >> >> >> >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > -- > Ian Ross Tel: +43(0)6804451378 ian at skybluetrades.net > www.skybluetrades.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at skybluetrades.net Mon Apr 7 13:43:16 2014 From: ian at skybluetrades.net (Ian Ross) Date: Mon, 7 Apr 2014 15:43:16 +0200 Subject: [Haskell-cafe] Fwd: c2hs: E.g. #include OK in *.cpp's, but not in *.h's In-Reply-To: References: Message-ID: More or less. Basically, C2HS is *C* FFI tool only. If you get into a situation where C2HS can see C++ header files, it's not going to work. How you get around that is up to you. If your C++ library isn't too complicated, a C wrapper as used in hsqml seems like a good choice, or you can write the Haskell FFI import declarations yourself. If your C++ library is complicated and you really want to get at all of its public interface, you could try using a real C++ FFI tool (the only one I've really heard anything about is fficxx: http://ianwookim.org/fficxx/). On 7 April 2014 15:33, Nick Rudnick wrote: > > > ---------- Forwarded message ---------- > From: Nick Rudnick > Date: 2014-04-07 15:28 GMT+02:00 > Subject: Re: [Haskell-cafe] c2hs: E.g. #include OK in *.cpp's, > but not in *.h's > To: Ian Ross > > > Hi Ian, > > thanks for clearing up :-) > > So you mean the trick of hsqml primarily is > > (A) dummy typedefs to char, e.g.: > > typedef char HsQMLStringHandle; > > (B) 'extern' sigantures, e.g.: > extern void hsqml_init_string(HsQMLStringHandle*); > > THIS WORKS... > > Occasionally, one might use two headers, e.g. a *.hpp as actual C++ header > neither listed in the *.cabal nor the *.chs, where instead it would be > represented by a *.h, as described above. > > No more...?? > > Thanks and cheers, Nick > > > > > > > > 2014-04-07 14:04 GMT+02:00 Ian Ross : > > Hi Nick, >> >> As far as I can tell from a quick look at hsqml, the stuff in Setup.hs >> isn't related to C2HS. What's more relevant is that hsqml defines a C >> library wrapper around the C++ library it uses -- C2HS is only used on that >> C wrapper, not on the C++ library itself. In general, C2HS doesn't support >> C++ at all, because it needs to be able to parse the header files that it >> includes and we use the C parser from the languagge-c package to do that. >> Any C++ constructs will just cause breakage. And your "old school" FFI >> definition doesn't look in any header files, which is why it has no trouble. >> >> Basically, if you want to do something like what hsqml does, just take a >> look in the cbits directory there, in particular at hsqml.h which is the >> header that defines the C wrapper around the C++ library. This hsqml.h >> header is the one that's included in the C2HS files. If you want to wrap a >> C++ library directly, C2HS probably isn't the tool for the job. I know >> there was some work during the last GSOC on a C++ FFI wrapper, but I don't >> know if anything concrete came of it. >> >> Cheers, >> >> Ian. >> >> >> >> On 6 April 2014 20:22, Nick Rudnick wrote: >> >>> Dear all, >>> >>> maybe this is a piece of c2hs behaviour I missed to understand, but it >>> appears happening with C++ style includes deep in the header call hierarchy >>> - in case of a such backend C++ library, if one wishes to refer to by *.h's >>> in c2hs (e.g. for access to types of it), one might have a problem. >>> >>> - 8< cSample.h --------------------------------------------- >>> #include ///////// here, with c2hs, leading to build abort >>> #ifdef __cplusplus >>> extern "C" { >>> #endif >>> void sampleFunction(); >>> #ifdef __cplusplus >>> } >>> #endif >>> - 8< cSample.cpp --------------------------------------------- >>> #include "cSample.h" >>> #include ///////// here no problem >>> >>> void sampleFunction(){ >>> std::cout << "OK" << std::endl; >>> } >>> - 8< ---------------------------------------------------------------- >>> >>> While 'old school' FFI (foreign import ccall) handles this effortlessly, >>> c2hs uses to abort with an exception like >>> C/cSample.h:3:20: fatal error: iostream: No such file or directory >>> compilation terminated. >>> >>> I see that hsqml gets around this, but apparently by tweaking Setup.hs >>> in a way not quite trivial - would this be necessary in any case, or are >>> there simpler alternatives? >>> >>> Please excuse if I oversaw something, but I am afraid I didn't see this >>> interesting issue covered elsewhere. >>> >>> Thank you a lot in advance & cheers, Nick >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >> >> -- >> Ian Ross Tel: +43(0)6804451378 ian at skybluetrades.net >> www.skybluetrades.net >> > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Ian Ross Tel: +43(0)6804451378 ian at skybluetrades.net www.skybluetrades.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.rudnick at gmail.com Mon Apr 7 14:03:24 2014 From: nick.rudnick at gmail.com (Nick Rudnick) Date: Mon, 7 Apr 2014 16:03:24 +0200 Subject: [Haskell-cafe] Fwd: c2hs: E.g. #include OK in *.cpp's, but not in *.h's In-Reply-To: References: Message-ID: Ian, thanks a lot :-) In fact I have a quite elaborate C++ backend to deal with ? so your recommendation of fficxx is highly welcome... :-) :-) :-) Cheers, Nick BTW: For everybody trying out the way described before, please enclose declarations by #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } #endif in the *.hpp, too, to prevent an error. 2014-04-07 15:43 GMT+02:00 Ian Ross : > More or less. Basically, C2HS is *C* FFI tool only. If you get into a > situation where C2HS can see C++ header files, it's not going to work. How > you get around that is up to you. If your C++ library isn't too > complicated, a C wrapper as used in hsqml seems like a good choice, or you > can write the Haskell FFI import declarations yourself. If your C++ > library is complicated and you really want to get at all of its public > interface, you could try using a real C++ FFI tool (the only one I've > really heard anything about is fficxx: http://ianwookim.org/fficxx/). > > > On 7 April 2014 15:33, Nick Rudnick wrote: > >> >> >> ---------- Forwarded message ---------- >> From: Nick Rudnick >> Date: 2014-04-07 15:28 GMT+02:00 >> Subject: Re: [Haskell-cafe] c2hs: E.g. #include OK in *.cpp's, >> but not in *.h's >> To: Ian Ross >> >> >> Hi Ian, >> >> thanks for clearing up :-) >> >> So you mean the trick of hsqml primarily is >> >> (A) dummy typedefs to char, e.g.: >> >> typedef char HsQMLStringHandle; >> >> (B) 'extern' sigantures, e.g.: >> extern void hsqml_init_string(HsQMLStringHandle*); >> >> THIS WORKS... >> >> Occasionally, one might use two headers, e.g. a *.hpp as actual C++ >> header neither listed in the *.cabal nor the *.chs, where instead it would >> be represented by a *.h, as described above. >> >> No more...?? >> >> Thanks and cheers, Nick >> >> >> >> >> >> >> >> 2014-04-07 14:04 GMT+02:00 Ian Ross : >> >> Hi Nick, >>> >>> As far as I can tell from a quick look at hsqml, the stuff in Setup.hs >>> isn't related to C2HS. What's more relevant is that hsqml defines a C >>> library wrapper around the C++ library it uses -- C2HS is only used on that >>> C wrapper, not on the C++ library itself. In general, C2HS doesn't support >>> C++ at all, because it needs to be able to parse the header files that it >>> includes and we use the C parser from the languagge-c package to do that. >>> Any C++ constructs will just cause breakage. And your "old school" FFI >>> definition doesn't look in any header files, which is why it has no trouble. >>> >>> Basically, if you want to do something like what hsqml does, just take a >>> look in the cbits directory there, in particular at hsqml.h which is the >>> header that defines the C wrapper around the C++ library. This hsqml.h >>> header is the one that's included in the C2HS files. If you want to wrap a >>> C++ library directly, C2HS probably isn't the tool for the job. I know >>> there was some work during the last GSOC on a C++ FFI wrapper, but I don't >>> know if anything concrete came of it. >>> >>> Cheers, >>> >>> Ian. >>> >>> >>> >>> On 6 April 2014 20:22, Nick Rudnick wrote: >>> >>>> Dear all, >>>> >>>> maybe this is a piece of c2hs behaviour I missed to understand, but it >>>> appears happening with C++ style includes deep in the header call hierarchy >>>> ? in case of a such backend C++ library, if one wishes to refer to by *.h's >>>> in c2hs (e.g. for access to types of it), one might have a problem. >>>> >>>> - 8< cSample.h --------------------------------------------- >>>> #include ///////// here, with c2hs, leading to build abort >>>> #ifdef __cplusplus >>>> extern "C" { >>>> #endif >>>> void sampleFunction(); >>>> #ifdef __cplusplus >>>> } >>>> #endif >>>> - 8< cSample.cpp --------------------------------------------- >>>> #include "cSample.h" >>>> #include ///////// here no problem >>>> >>>> void sampleFunction(){ >>>> std::cout << "OK" << std::endl; >>>> } >>>> - 8< ---------------------------------------------------------------- >>>> >>>> While 'old school' FFI (foreign import ccall) handles this >>>> effortlessly, c2hs uses to abort with an exception like >>>> C/cSample.h:3:20: fatal error: iostream: No such file or directory >>>> compilation terminated. >>>> >>>> I see that hsqml gets around this, but apparently by tweaking Setup.hs >>>> in a way not quite trivial ? would this be necessary in any case, or are >>>> there simpler alternatives? >>>> >>>> Please excuse if I oversaw something, but I am afraid I didn't see this >>>> interesting issue covered elsewhere. >>>> >>>> Thank you a lot in advance & cheers, Nick >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> >>> -- >>> Ian Ross Tel: +43(0)6804451378 ian at skybluetrades.net >>> www.skybluetrades.net >>> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > -- > Ian Ross Tel: +43(0)6804451378 ian at skybluetrades.net > www.skybluetrades.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at with-h.at Mon Apr 7 14:12:31 2014 From: haskell at with-h.at (Dominik Peteler) Date: Mon, 7 Apr 2014 16:12:31 +0200 Subject: [Haskell-cafe] Directed rounding in haskell ? Message-ID: <20140407141231.GA3594@fuckup> Hello list, I'm going to implement an interval arithmetic library (following the IEEE P1788) in Haskell and for that I need support for directed rounding to the nearest floating point number. I had a quick look at the Decimal package which comes with the `roundTo` function for rounding to a specified number of decimal places but it doesn't provide directed rounding. Is there way to get directed rounding to to the nearest float (maybe even with machine floats) ? I'm also aware of the AERN-* packages but they seem to be unmaintained. At least there is no version which builds with the current GHC. Does anybody know something about that ? Regards dominik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From klao at nilcons.com Mon Apr 7 15:49:50 2014 From: klao at nilcons.com (Mihaly Barasz) Date: Mon, 7 Apr 2014 17:49:50 +0200 Subject: [Haskell-cafe] Towards a better time library (announcing tz) In-Reply-To: References: <20140331181543.GA20036@cs.elte.hu> Message-ID: Hello Renzo and list, Since my last email I have implemented the two things that I mentioned: * a Template Haskell function with which you can include a few needed `TZ`s in your binary at compile time * a module which contains all of the time zones shipped in a pure way. So, if you use this module, all of the zone files will be compiled into your binary, so you can use them completely independently from the platform/machine you are running on. (This is appropriate for a webapp for example, where you need to display times to many users in many different time zones.) Renzo, please take a look at the Data.Time.Zones.All module (http://hackage.haskell.org/package/tz-0.0.0.3/docs/Data-Time-Zones-All.html). I tried to implement it with your comments in mind. If you think that this is something like what you need, something like what you were thinking about, I can release it as a separate package with your versioning scheme. Mihaly On Tue, Apr 1, 2014 at 11:55 AM, Mihaly Barasz wrote: > On Tue, Apr 1, 2014 at 3:21 AM, Renzo Carbonara wrote: >> I'm currently a user of the `timezone-olson` and `timezone-series` >> libraries, so I can understand the requirement for better time zone >> representations than the one offered by `time`. I think it would be >> best for the community if your work and the one in `timezone-olson` >> and `timezone-series` could be integrated somehow, as there doesn't >> seem to be a need to have two different implementations for parsing >> the Olson file format. As far as I know, Yitzchak is willing to >> improve his libraries, I CC him here. > > It seems that we have quite different views on things. :) But of > course, I agree that one good solution is much better than two > half-baked ones, I'm just not exactly sure how to proceed. I think, > it's best if we give it some time and slowly figure out a way to > compromise and cooperate. > >> Given that you are shipping a timezone database with your package, as >> a user I'd really prefer `loadTZFromDB` to be `String -> Maybe TZ` >> instead of `String -> IO TZ` so that it can be used in pure code. >> You'd probably need to hardcode the contents of the `*.zone` files you >> are including within a Haskell module, but that could be done >> automatically using some script. > > This is in the working, I just didn't get to it yet. > One problem with this is that once you use the module providing this > pure interface, _all_ of the time zone definitions will be compiled > into your binary, increasing its size substantially (few hundred > kilobytes). It's not a problem for many uses, but this is why I don't > want it as the only mechanism. > >> Moreover, an idea I've been toying with is writing a program that >> parses the tzdata information files and generates a type-safe pure API >> for interacting with the tz data in memory. For example, given the >> tzdata information files you would generate types, values and pure >> functions such as the following: >> >> data TimeZone >> = Europe__Paris >> | America__Buenos_Aires >> | ... >> >> timeZoneName :: TimeZone -> Text >> timeZoneName Europe__Paris = "Europe/Paris" >> timeZoneName America__Buenos_Aires = "America/Buenos_Aires" >> timeZoneName ... = ... >> >> timeZoneFromName :: Text -> Maybe TimeZone >> timeZoneFromName "Europe/Paris" = Just Europe__Paris >> timeZoneFromName "America/Buenos_Aires" = Just America__Buenos_Aires >> timeZoneFromName ... = ... >> timeZoneFromName _ = Nothing >> >> timeZoneInfo :: TimeZone -> TZ >> timeZoneInfo Europe_Paris = ... some hardcoded value (the `TZ` in >> your library) ... >> timeZoneInfo ... = ... > > Interesting idea, I have to think about it a bit more, but right now I > don't see why not. > >> As a minor tidbit: If one is going to do this, I think a good idea is >> to devise a package versioning system that's somewhat follows the tz >> database versions. This is what I had in mind for the `tzdata` package >> I was planning to create (unless someone else does it first): >> >> The version number of the package is always @YYYYMMDD.B.C@, where >> @YYYYMMDD@ are the year (@YYYY@), the month (@MM@) and the day (@DD@) >> of the @tzdata@ release this particular version was designed for. For >> example, @tzdata 2013i@ was officially released on @2013-12-17@, so a >> version of this package that was designed for @tzdata 2013i@ will >> carry the version number @20131217.B.C at . However, that doesn't mean >> that this library won't work with versions of the @tzdata@ library >> different than @2013i@, it's just that support for new or old data >> (say, the name of a new time zone that was introduced) can be missing. >> The @B@ and @C@ values in the version number of this library as >> treated as the /major/ and /minor/ versions respectively, as suggested >> in the /Haskell Package Version Policy/ page: >> http://www.haskell.org/haskellwiki/Package_versioning_policy > > Hmm, I see the reasoning behind this, but I think it would be annoying > for most of the users. Or not? > If we separate only the data in a separate package (on which `tz` > depends), then very few people would want to explicitly specify its > version... Yeah, this might work. :) > > Mihaly > >> >> Maybe the `timezone-olson`, `timezone-series`, this `tzdata` idea and >> `tz` could all live together; with `tz` depending on the others? Just >> a thought :) >> >> >> Regards, >> >> Renzo Carbonara. >> >> >> On Mon, Mar 31, 2014 at 3:15 PM, Mihaly Barasz wrote: >>> >>> I would like to propose reforming the 'time' [1] library. >>> >>> >>> Initially, I was just planning to announce my new 'tz' [2] library, but >>> realized that I have a more important agenda. Namely: Haskell needs a >>> better time library! >>> >>> Let me summarize what are - in my view - the biggest deficiencies of >>> 'time': >>> >>> 1. Inefficient data structures and implementations. >>> >>> 2. Ad-hoc API which is hard to remember and frustrating to work with. >>> >>> 3. Conceptually wrong representations and/or missing concepts. >>> >>> The wonderful thyme [3] package (by Liyang HU) improves a lot on #1 by >>> choosing better data structures and careful implementations and on #2 >>> by lensifying the API. >>> >>> But, it was the #3 that caused me the most frustration lately; most >>> importantly the time zone handling. >>> >>> There is a TimeZone data type in 'time', but it is a misnomer, it >>> basically represents a fixed time difference (with a label and a DST >>> flag). 'time' basically adapts the broken approach from libc: you can >>> work with one time zone at a time, which is defined globally for your >>> program (via the TZ environment variable). So, the transformation >>> between UTCTime and LocalTime which should have been a pure >>> function can only be done in IO now. Like this: >>> >>> do tz <- getTimeZone ut >>> return $ utcToLocalTime tz ut >>> >>> >>> Oh, and just to hammer down on the point #1 from the list above. This >>> code runs in about 6100 ns on my machine. The drop-in replacement from >>> tz: utcToLocalTimeTZ [4] (which is actually pure) runs in 2300 ns. >>> While this is a significant improvement, it's easy to miss the point >>> where the bulk of the inefficiency comes from the data structures. In >>> my main project we represent times as Int64 (raw nanoseconds since >>> UNIX epoch; and similar representation for zoned times). And to >>> convert those to and from different time zones we need 40 ns. That's >>> right, a 150 _times_ improvement! (There are many other interesting >>> benchmark results that I could mention. An exciting bottom line: we >>> can actually beat the libc in many use-cases!) >>> >>> The 'tz' package is still very much in flux. I will try to solidify >>> the API soon, but until then it should be considered more of a proof >>> of concept. There is some missing functionality, for example. On the >>> other hand, there are the 'timezone-series' [5] and 'timezone-olson' >>> [6] packages that together provide about the same functionality as >>> 'tz' (minus the efficiency), and I'd like to explore if we could >>> remove some of the overlap. But, all kind of suggestions and requests >>> are welcome! >>> >>> More importantly, I'd like to hear the opinions of the community about >>> the general issue of a better time library! Do we need one? How >>> should we proceed about it? I think, Haskell could potentially have >>> one of the best time libraries, but the current de-facto standard is >>> mediocre at best. Unfortunately, designing a good time library is very >>> far from trivial, as many existing examples demonstrate. And I >>> definitely don't know enough for it. (I understand time zone info >>> files, now that I wrote tz, but that's just a tiny fraction of what's >>> needed.) So, if you think you can contribute to the design (have >>> important use-cases in mind, know good examples of API, have some >>> experience working with dates and time, etc. etc.) - speak up! >>> >>> >>> Mihaly >>> >>> >>> Footnotes: >>> >>> [1] http://hackage.haskell.org/package/time >>> [2] http://hackage.haskell.org/package/tz >>> [3] http://hackage.haskell.org/package/thyme >>> [4] http://hackage.haskell.org/package/tz-0.0.0.1/docs/Data-Time-Zones.html#v:utcToLocalTimeTZ >>> [5] http://hackage.haskell.org/package/timezone-series >>> [6] http://hackage.haskell.org/package/timezone-olson >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.6 (GNU/Linux) >>> >>> iQEVAwUBUzmwz/i5FOsZqz9DAQJGcAgAhPF4JLWnL4ApJ2qxqAwHqXcIPqRpVb5A >>> TH2LERH2A/6b3xXCRYsPgyD43j2CzqZGffRvINSw9fGoJYWuRmis5dCf9hwPiKtg >>> hK1wUCz9AsKlKBZztR9eLxROqM/xXMH4HaFydr/YOVffDVY6fUIK9fPbRFJBVCBq >>> UwtoemQSVLUIIRxZyg5pdL+dxadnttm7bGC+UuQJHtSSBRweEh3unr8dcNm4idC3 >>> nxWOMclbo2hyMdwzDo1bqugugq2xCGPiGrL550aF1lCGD2pf2vQO1feW/5XyMaCR >>> Oj6gI+eHo8SuhUx30Dokv1kx8Ssay0aVmmASCJKnR8Bwv1J9AKWo3A== >>> =Bp64 >>> -----END PGP SIGNATURE----- >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> From ducis_cn at 126.com Mon Apr 7 16:02:08 2014 From: ducis_cn at 126.com (ducis) Date: Tue, 8 Apr 2014 00:02:08 +0800 (CST) Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: References: Message-ID: http://hackage.haskell.org/package/slot-lambda It lets your write lambdas with 'slots' without inventing names for the parameters. [s| ? + ? |] = \x y -> x+y The unicode character ?(305) representing a 'slot' can be input in vim with the digraph 'i.' . Use _? to refer to the immediate left ?, and _0, _1, _2, ... to refer to the 1st, 2nd, 3rd, ... arguments respectively. e.g. [s| ? : ? : _? : ? : _? : _? : _0 : [] |] 'a' 'b' 'c' = (\x y z -> x:y:y:z:z:z:x:[]) 'a' 'b' 'c' = "abbccca" I originally intended using '_' to represent the 'slots' but that doesn't parse as legal haskell. Actually I wonder how to achieve that without rolling my own haskell parser or forking haskell-src-exts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Apr 7 16:08:14 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 7 Apr 2014 12:08:14 -0400 Subject: [Haskell-cafe] Towards a better time library (announcing tz) In-Reply-To: References: <20140331181543.GA20036@cs.elte.hu> Message-ID: On Mon, Apr 7, 2014 at 11:49 AM, Mihaly Barasz wrote: > * a module which contains all of the time zones shipped in a pure way. > I have to admit that I strongly dislike this idea. What happens when someone changes timezone rules? (Which happens quite often, actually.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From klao at nilcons.com Mon Apr 7 16:20:19 2014 From: klao at nilcons.com (Mihaly Barasz) Date: Mon, 7 Apr 2014 18:20:19 +0200 Subject: [Haskell-cafe] Towards a better time library (announcing tz) In-Reply-To: References: <20140331181543.GA20036@cs.elte.hu> Message-ID: On Mon, Apr 7, 2014 at 6:08 PM, Brandon Allbery wrote: > On Mon, Apr 7, 2014 at 11:49 AM, Mihaly Barasz wrote: >> >> * a module which contains all of the time zones shipped in a pure way. > > > I have to admit that I strongly dislike this idea. What happens when someone > changes timezone rules? (Which happens quite often, actually.) I intend to maintain this library, so the latest version always have up-to-date zone information. Also, see Renzo's proposal to have this in a separate package with a versioning scheme that closely reflects the version of the tz data shipped. (I think it's a sensible idea and I will do this when/if what I have actually satisfies his needs). And also, you don't _have to_ use this. `tz` also has a `loadSystemTZ` function, which will read the appropriate file from /usr/share/zoneinfo (or whereever the TZDIR envvar points to), and then you can use the result in the (pure) utcToLocalTimeTZ and localTimeToUTCTZ conversion functions. This would be exactly like what happens in a C program if you run it with TZ envvar set to that location. Mihaly > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From gnuk0001 at gmail.com Mon Apr 7 16:20:40 2014 From: gnuk0001 at gmail.com (Renzo Carbonara) Date: Mon, 7 Apr 2014 13:20:40 -0300 Subject: [Haskell-cafe] Towards a better time library (announcing tz) In-Reply-To: References: <20140331181543.GA20036@cs.elte.hu> Message-ID: On Mon, Apr 7, 2014 at 12:49 PM, Mihaly Barasz wrote: > Hello Renzo and list, > > Since my last email I have implemented the two things that I mentioned: > * a Template Haskell function with which you can include a few needed > `TZ`s in your binary at compile time > * a module which contains all of the time zones shipped in a pure way. > So, if you use this module, all of the zone files will be compiled > into your binary, so you can use them completely independently from > the platform/machine you are running on. (This is appropriate for a > webapp for example, where you need to display times to many users in > many different time zones.) > > Renzo, please take a look at the Data.Time.Zones.All module > (http://hackage.haskell.org/package/tz-0.0.0.3/docs/Data-Time-Zones-All.html). > I tried to implement it with your comments in mind. Yes! This is precisely what I had in mind, thanks so much for working on this. Tools like these will allow us at work to deal with timezones in a type-safe manner, purely within a closed world (the tz database being used), avoiding any IO interactions, which is quite welcome when building a piece of software that needs to deal with timezones constantly like a web application attending users from different time zones, just like you said. This same approach of including a full tz database for internal use is done by other programs that need to operate with timezones quite frequently; PostgreSQL comes to mind. I particularly like that you are removing timezone names that are links from the `TZLabel` constructors, yet allowing the link names to be looked up when using `tzByName` (that is, both `"America/Buenos_Aires"` and `"America/Argentina/Buenos_Aires"` point to the canonical `America__Argentina__Buenos_Aires`). I have two recommendations, both related to performance: First, I'd prefer if instead of using `String` you used `ByteString` or `Text`. `String` seems like an unnecessary cost to pay, even more so when one of the purposes of this module is to avoid expensive lookups (in our particular use case at work, we already have stored strings such as `Europe/Rome` in the database, so reading them as `Text` or `ByteString` will be cheaper than reading them as `String`). And the second one, is that you could probably benefit from making `tzDescriptions` be a `Data.Map.Map` from the time zone name to the (either a `Text` or a `ByteString`) to the rest of the `TZDescription` information. That'll certainly speed up the lookups by name (though by looking at the definition of `tzByName`, maybe there are some memoization tricks into play already which I can't immediately recognize). > If you think that > this is something like what you need, something like what you were > thinking about, I can release it as a separate package with your > versioning scheme. I don't think you really need to do this, it was just a minor suggestion I made. As long as it's mentioned in the package and module documentation what tz database version is being used, it should be fine. Regards, Renzo Carbonara. From johan.tibell at gmail.com Mon Apr 7 16:30:11 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 7 Apr 2014 18:30:11 +0200 Subject: [Haskell-cafe] Towards a better time library (announcing tz) In-Reply-To: References: <20140331181543.GA20036@cs.elte.hu> Message-ID: On Mon, Apr 7, 2014 at 6:08 PM, Brandon Allbery wrote: > On Mon, Apr 7, 2014 at 11:49 AM, Mihaly Barasz wrote: > >> * a module which contains all of the time zones shipped in a pure way. >> > > I have to admit that I strongly dislike this idea. What happens when > someone changes timezone rules? (Which happens quite often, actually.) > This is quite common practice for those of us who push executables to servers. We need to push an updated library/binary. -------------- next part -------------- An HTML attachment was scrubbed... URL: From klao at nilcons.com Mon Apr 7 17:45:12 2014 From: klao at nilcons.com (Mihaly Barasz) Date: Mon, 7 Apr 2014 19:45:12 +0200 Subject: [Haskell-cafe] Towards a better time library (announcing tz) In-Reply-To: References: <20140331181543.GA20036@cs.elte.hu> Message-ID: On Mon, Apr 7, 2014 at 6:20 PM, Renzo Carbonara wrote: > On Mon, Apr 7, 2014 at 12:49 PM, Mihaly Barasz wrote: >> Hello Renzo and list, >> >> Since my last email I have implemented the two things that I mentioned: >> * a Template Haskell function with which you can include a few needed >> `TZ`s in your binary at compile time >> * a module which contains all of the time zones shipped in a pure way. >> So, if you use this module, all of the zone files will be compiled >> into your binary, so you can use them completely independently from >> the platform/machine you are running on. (This is appropriate for a >> webapp for example, where you need to display times to many users in >> many different time zones.) >> >> Renzo, please take a look at the Data.Time.Zones.All module >> (http://hackage.haskell.org/package/tz-0.0.0.3/docs/Data-Time-Zones-All.html). >> I tried to implement it with your comments in mind. > > Yes! This is precisely what I had in mind, thanks so much for working > on this. Tools like these will allow us at work to deal with timezones > in a type-safe manner, purely within a closed world (the tz database > being used), avoiding any IO interactions, which is quite welcome when > building a piece of software that needs to deal with timezones > constantly like a web application attending users from different time > zones, just like you said. This same approach of including a full tz > database for internal use is done by other programs that need to > operate with timezones quite frequently; PostgreSQL comes to mind. > > I particularly like that you are removing timezone names that are > links from the `TZLabel` constructors, yet allowing the link names to > be looked up when using `tzByName` (that is, both > `"America/Buenos_Aires"` and `"America/Argentina/Buenos_Aires"` point > to the canonical `America__Argentina__Buenos_Aires`). You are giving me too much credit! This is not how it was implemented, but you are right, this makes much more sense! I rewrote it to be like that. > I have two recommendations, both related to performance: First, I'd > prefer if instead of using `String` you used `ByteString` or `Text`. > `String` seems like an unnecessary cost to pay, even more so when one > of the purposes of this module is to avoid expensive lookups (in our > particular use case at work, we already have stored strings such as > `Europe/Rome` in the database, so reading them as `Text` or > `ByteString` will be cheaper than reading them as `String`). And the > second one, is that you could probably benefit from making > `tzDescriptions` be a `Data.Map.Map` from the time zone name to the > (either a `Text` or a `ByteString`) to the rest of the `TZDescription` > information. That'll certainly speed up the lookups by name (though by > looking at the definition of `tzByName`, maybe there are some > memoization tricks into play already which I can't immediately > recognize). I changed the names to be (strict) ByteStrings. Maybe I'll add some convenience functions to also work with Strings and Text. (Or maybe not, because there are also the lazy versions of ByteString and Text and I don't want to add functions for all of them.) For the second part: all of the lookups are done either from Data.Map or from Data.Vector. I only export the `tzDescriptions` list because maybe someone is interested, I never do lookups in it. (All three lookup functions have a constant vector or map produced from `tzDescriptions` and do lookups in those.) > >> If you think that >> this is something like what you need, something like what you were >> thinking about, I can release it as a separate package with your >> versioning scheme. > > I don't think you really need to do this, it was just a minor > suggestion I made. As long as it's mentioned in the package and module > documentation what tz database version is being used, it should be > fine. I might do it anyway. It's a nice separation, and also others who don't want to use `TZ` (like `timezone-olson`) might benefit from it too. > > Regards, > > Renzo Carbonara. From vogt.adam at gmail.com Mon Apr 7 20:28:40 2014 From: vogt.adam at gmail.com (adam vogt) Date: Mon, 7 Apr 2014 16:28:40 -0400 Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: References: Message-ID: Hi Ducis, Maybe haskell-src-exts will follow ghc-7.8 and accept _ in expressions as ghc-7.8 does (http://www.haskell.org/haskellwiki/GHC/TypedHoles). Ideally there could be something like camlp4 for haskell, but as far as I know there isn't such a thing. Regards, Adam On Mon, Apr 7, 2014 at 12:02 PM, ducis wrote: > http://hackage.haskell.org/package/slot-lambda > > It lets your write lambdas with 'slots' without inventing names for the > parameters. > > [s| ? + ? |] = \x y -> x+y > > The unicode character ?(305) representing a 'slot' can be input in vim with > the digraph 'i.' . > Use _? to refer to the immediate left ?, and _0, _1, _2, ... to refer to the > 1st, 2nd, 3rd, ... arguments respectively. > e.g. > [s| ? : ? : _? : ? : _? : _? : _0 : [] |] 'a' 'b' 'c' > = (\x y z -> x:y:y:z:z:z:x:[]) 'a' 'b' 'c' > = "abbccca" > I originally intended using '_' to represent the 'slots' but that doesn't > parse as legal haskell. > Actually I wonder how to achieve that without rolling my own haskell parser > or forking haskell-src-exts. > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From rendel at informatik.uni-marburg.de Mon Apr 7 20:53:06 2014 From: rendel at informatik.uni-marburg.de (Tillmann Rendel) Date: Mon, 07 Apr 2014 22:53:06 +0200 Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: References: Message-ID: <53431032.1020105@informatik.uni-marburg.de> Hi, Ducis wrote: > Actually I wonder how to achieve that without rolling my own haskell parser or forking haskell-src-exts. Adam vogt wrote: > Ideally there could be something like camlp4 for haskell, but as far > as I know there isn't such a thing. We built SugarHaskell to explore that design space. See our paper at the Haskell Symposium 2012: http://sugarj.org/sugarhaskell.pdf While there is not much going on about SugarHaskell specifically, the underlying language-independent framework is still actively developed, in the https://github.com/sugar-lang organization. The eclipse plugin for SugarHaskell from http://update.sugarj.org/ should work. I don't know what the status of the command-line version is, though. Even if you don't want to use all of SugarHaskell, the underlying easily extensible grammar might still be a good starting point. It uses declarative layout constraints to specify Haskell's layout in a modular way. See our paper at the conference on software language engineering 2012: http://sugarj.org/layout-parsing.pdf Tillmann From ky3 at atamo.com Mon Apr 7 20:58:30 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 8 Apr 2014 03:58:30 +0700 Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: References: Message-ID: On Mon, Apr 7, 2014 at 11:02 PM, ducis wrote: > It lets your write lambdas with 'slots' without inventing names for the > parameters. > > [s| ? + ? |] = \x y -> x+y > > I have no background in this 'slot lambda' and a search reveals this package as the only hit. Which may explain why I find the example given confusing. Why would [s| 1+1 |] not be equivalent to \x->x+x ? -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Mon Apr 7 21:01:02 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Mon, 7 Apr 2014 22:01:02 +0100 Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: References: Message-ID: I just want to add that I find the syntax extremely confusing and counter intuitive. I thought it was just me, or that I was missed something. But it looks like I'm not the only one. On 7 April 2014 21:58, Kim-Ee Yeoh wrote: > > On Mon, Apr 7, 2014 at 11:02 PM, ducis wrote: > >> It lets your write lambdas with 'slots' without inventing names for the >> parameters. >> >> [s| ? + ? |] = \x y -> x+y >> >> > I have no background in this 'slot lambda' and a search reveals this > package as the only hit. > > Which may explain why I find the example given confusing. Why would [s| > 1+1 |] not be equivalent to \x->x+x ? > > > > -- Kim-Ee > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- *Alois Cochard* http://aloiscochard.blogspot.com http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Mon Apr 7 21:12:26 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Mon, 7 Apr 2014 22:12:26 +0100 Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: References: Message-ID: In order to give a more constructive feedback, why not simply indexing arguments by position and use the `_N` syntax? The second example would be: _0 : _1 : _1 : _2 : _2 : _2 : _0 : [] One could just use `_` if there is only one arg: _ + _ (which mean what Kim thought it would mean) and use: _0 + _1 (for the case you wanted to support) Cheers On 7 April 2014 22:01, Alois Cochard wrote: > I just want to add that I find the syntax extremely confusing and counter > intuitive. > > I thought it was just me, or that I was missed something. But it looks > like I'm not the only one. > > > On 7 April 2014 21:58, Kim-Ee Yeoh wrote: > >> >> On Mon, Apr 7, 2014 at 11:02 PM, ducis wrote: >> >>> It lets your write lambdas with 'slots' without inventing names for the >>> parameters. >>> >>> [s| ? + ? |] = \x y -> x+y >>> >>> >> I have no background in this 'slot lambda' and a search reveals this >> package as the only hit. >> >> Which may explain why I find the example given confusing. Why would [s| >> 1+1 |] not be equivalent to \x->x+x ? >> >> >> >> -- Kim-Ee >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > -- > *Alois Cochard* > http://aloiscochard.blogspot.com > http://twitter.com/aloiscochard > http://github.com/aloiscochard > -- *Alois Cochard* http://aloiscochard.blogspot.com http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Mon Apr 7 21:16:18 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 7 Apr 2014 22:16:18 +0100 Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: References: Message-ID: <20140407211618.GZ13760@weber> On Tue, Apr 08, 2014 at 03:58:30AM +0700, Kim-Ee Yeoh wrote: > On Mon, Apr 7, 2014 at 11:02 PM, ducis wrote: > > > It lets your write lambdas with 'slots' without inventing names for the > > parameters. > > > > [s| ? + ? |] = \x y -> x+y > > > > > I have no background in this 'slot lambda' and a search reveals this > package as the only hit. > > Which may explain why I find the example given confusing. Why would [s| 1+1 > |] not be equivalent to \x->x+x ? Because each slot stands for a new variable. From alois.cochard at gmail.com Mon Apr 7 21:14:30 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Mon, 7 Apr 2014 22:14:30 +0100 Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: <20140407211618.GZ13760@weber> References: <20140407211618.GZ13760@weber> Message-ID: Understood and actually I forgot you can not use "_", so why not a symbol which don't look like a number? On 7 April 2014 22:16, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Tue, Apr 08, 2014 at 03:58:30AM +0700, Kim-Ee Yeoh wrote: > > On Mon, Apr 7, 2014 at 11:02 PM, ducis wrote: > > > > > It lets your write lambdas with 'slots' without inventing names for the > > > parameters. > > > > > > [s| ? + ? |] = \x y -> x+y > > > > > > > > I have no background in this 'slot lambda' and a search reveals this > > package as the only hit. > > > > Which may explain why I find the example given confusing. Why would [s| > 1+1 > > |] not be equivalent to \x->x+x ? > > Because each slot stands for a new variable. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- *Alois Cochard* http://aloiscochard.blogspot.com http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Apr 7 21:26:50 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 7 Apr 2014 17:26:50 -0400 Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: References: <20140407211618.GZ13760@weber> Message-ID: On Mon, Apr 7, 2014 at 5:14 PM, Alois Cochard wrote: > Understood and actually I forgot you can not use "_", so why not a symbol > which don't look like a number? > I was also wondering how Turkish speakers/writers would react to that notation.... -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.solla at gmail.com Mon Apr 7 21:57:23 2014 From: alex.solla at gmail.com (Alexander Solla) Date: Mon, 7 Apr 2014 14:57:23 -0700 Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: References: <20140407211618.GZ13760@weber> Message-ID: On Mon, Apr 7, 2014 at 2:26 PM, Brandon Allbery wrote: > On Mon, Apr 7, 2014 at 5:14 PM, Alois Cochard wrote: > >> Understood and actually I forgot you can not use "_", so why not a symbol >> which don't look like a number? >> > > I was also wondering how Turkish speakers/writers would react to that > notation.... > Native English speaker here. My first thought was, "Oh, a iota. And he's using it as a definite descriptor/anonymous variable. Nice." But then again, I took too many classes on Frege and Russell. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Mon Apr 7 22:03:23 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 8 Apr 2014 05:03:23 +0700 Subject: [Haskell-cafe] Can I write this function without doing the action on a different line? In-Reply-To: <1396768505.3793.103240905.1D9BD1F4@webmail.messagingengine.com> References: <1396768505.3793.103240905.1D9BD1F4@webmail.messagingengine.com> Message-ID: On Sun, Apr 6, 2014 at 2:15 PM, Karl Voelker wrote: > last . splitDirectories . normalise . joinPath . (: maybeToList package) > <$> getCurrentDirectory The thing to notice is that we really want to write getCurrentDirectory : maybeToList package but the effect-typing won't let us. This kludge: let x = flip (<$>) in getCurrentDirectory `x` (: maybeToList package) restores the smile in our haskell, where 'x' can be as imperceptibly unicoded as desired. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.oqube at gmail.com Mon Apr 7 23:04:35 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Tue, 8 Apr 2014 01:04:35 +0200 Subject: [Haskell-cafe] Haskell + emacs + Ghc-mod 4.0.1 In-Reply-To: References: <20140404.063024.573783403235305621.kazu@iij.ad.jp> Message-ID: OK, so now opening each file in emacs works correctly but when I try to load the test file in haskell repl, it fails complaining it cannot find the local package. Here is my cabal file: Name: tdd-qc Version: 1.0 Build-type: Simple Synopsis: This is a sample project License: BSD3 License-file: LICENSE Author: Arnaud Bailly Build-Depends: base Cabal-version: >= 1.8 Executable tdd-qc build-depends: base hs-source-dirs: src main-is: tdd-qc.hs ghc-options: -Wall Test-Suite tdd-qc-test type: exitcode-stdio-1.0 hs-source-dirs: test main-is: tdd-qc-test.hs build-depends: base, QuickCheck >= 2.6, tdd-qc And here is my emacs settings: ;; haskell coding (require 'auto-complete) (require 'haskell-mode) (require 'haskell-cabal) (autoload 'ghc-init "ghc" nil t) (add-hook 'haskell-mode-hook (lambda () (ghc-init))) (eval-after-load "haskell-mode" '(progn (setq haskell-stylish-on-save t) (setq haskell-process-args-cabal-repl '("--ghc-option=-ferror-spans" "--with-ghc=ghci-ng")) (define-key haskell-mode-map (kbd "C-,") 'haskell-move-nested-left) (define-key haskell-mode-map (kbd "C-.") 'haskell-move-nested-right) (define-key haskell-mode-map (kbd "C-c v c") 'haskell-cabal-visit-file) (define-key haskell-mode-map (kbd "C-c C-c") 'haskell-compile) (define-key haskell-mode-map (kbd "C-x C-d") nil) (setq haskell-font-lock-symbols t) ;; Do this to get a variable in scope (auto-complete-mode) ;; from http://pastebin.com/tJyyEBAS (ac-define-source ghc-mod '((depends ghc) (candidates . (ghc-select-completion-symbol)) (symbol . "s") (cache))) (defun my-ac-haskell-mode () (setq ac-sources '(ac-source-words-in-same-mode-buffers ac-source-dictionary ac-source-ghc-mod))) (add-hook 'haskell-mode-hook 'my-ac-haskell-mode) (defun my-haskell-ac-init () (when (member (file-name-extension buffer-file-name) '("hs" "lhs")) (auto-complete-mode t) (setq ac-sources '(ac-source-words-in-same-mode-buffers ac-source-dictionary ac-source-ghc-mod)))) (add-hook 'find-file-hook 'my-haskell-ac-init))) (add-hook 'haskell-mode-hook 'turn-on-haskell-decl-scan) (add-hook 'haskell-mode-hook 'turn-on-haskell-indentation) (eval-after-load "which-func" '(add-to-list 'which-func-modes 'haskell-mode)) (eval-after-load "haskell-cabal" '(define-key haskell-cabal-mode-map (kbd "C-c C-c") 'haskell-compile)) Thanks in advance for any advice.... -- Arnaud Bailly FoldLabs Associate: http://foldlabs.com On Sat, Apr 5, 2014 at 9:03 AM, Arnaud Bailly wrote: > OK, I forgot the ?enable-tests flag to cabal install? > > However, there seems to be some strange interactions I do not understand > fully with the test section of cabal. > Here is the cabal file: > > name: Thermometre > version: 0.1.0.0 > synopsis: synopsis > -- description: > license: PublicDomain > license-file: LICENSE > author: Black > -- maintainer: > -- copyright: > -- category: > build-type: Simple > cabal-version: >= 1.8 > > library > hs-source-dirs: > src > exposed-modules: > Thermometre > build-depends: > base == 4.* > > test-suite spec > type: > exitcode-stdio-1.0 > ghc-options: > -Wall -Werror > hs-source-dirs: > test > main-is: > Spec.hs > build-depends: > base == 4.* > , Thermometre > , hspec >= 1.3 > > When I remove the test-suite section and open src/Thermometre.hs I got > errors highlighting which is fine. C-c C-t does not give me types however > ('Cannot guess type? message). > > When I leave the test-suite section then opening Thermometre.hs gives me a > package error: ?cannot satisfy -package Thermometre? as there is a > dependency from the tests to the main library. > > How can I solve that? > > Thanks > Arnaud > > On 03 Apr 2014, at 23:30, Kazu Yamamoto (????) wrote: > > >> I upgrade my emacs configuration with latest ghc-mod and all of sudden > >> nothing works (again). > >> When I try to load a .hs file from a project I got the first line > >> highlighted with the error "cannot satisfy -package spec" and I cannot > got > >> type, info or doc from that file. Also I do not have anymore syntax > errors > >> highlighting I used to see. > > > > As this message suggests, you need to install spec for testing. > > > > % cabal install spec > > > > # I don't know what the spec package is. A typo for hspec? > > > > This is because ghc-mod obtains dependency for executables, libraries > > *and* testing. > > > > In general, > > % cabal install --only-dependencies > > would help you. > > > > --Kazu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Mon Apr 7 23:12:12 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Tue, 8 Apr 2014 00:12:12 +0100 Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: References: <20140407211618.GZ13760@weber> Message-ID: :-) Ok, nevermind. That's just me which is has no understanding of the context then, like Kim. I'm booking some classes with Frege and Russell, looks like they are pretty busy atm. On 7 April 2014 22:57, Alexander Solla wrote: > > On Mon, Apr 7, 2014 at 2:26 PM, Brandon Allbery wrote: > >> On Mon, Apr 7, 2014 at 5:14 PM, Alois Cochard wrote: >> >>> Understood and actually I forgot you can not use "_", so why not a >>> symbol which don't look like a number? >>> >> >> I was also wondering how Turkish speakers/writers would react to that >> notation.... >> > > Native English speaker here. My first thought was, "Oh, a iota. And he's > using it as a definite descriptor/anonymous variable. Nice." > > But then again, I took too many classes on Frege and Russell. > -- *Alois Cochard* http://aloiscochard.blogspot.com http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai at kzhang.org Mon Apr 7 23:44:16 2014 From: kai at kzhang.org (Kai Zhang) Date: Mon, 7 Apr 2014 16:44:16 -0700 Subject: [Haskell-cafe] Library for creating interactive diagrams? Message-ID: Hi cafe, Is there any active project about creating interactive diagrams, like D3js http://d3js.org/ ? The Diagrams library has already done a good job of making static images. Would it be possible to extend this library to support declaring interactive diagrams and then use JS and HTML as backend to draw them? Example: circle 1 $ with & hover .~ (change style) PS: I don't want a D3js binding. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.gibiansky at gmail.com Mon Apr 7 23:56:31 2014 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Mon, 7 Apr 2014 16:56:31 -0700 Subject: [Haskell-cafe] Library for creating interactive diagrams? In-Reply-To: References: Message-ID: I am very interested in using this with IHaskell, but don't know of something that exists already. I am currently working on using IPython widgets with IHaskell in order to create a generic "event handling" framework for *any* sort of displays. Code might look like this (just some initial thoughts): -- Uses a StateT of some sort. Reruns things every time -- a dependent value changes, and shows the updated output. interactive $ do -- Display a slider. The value changes every time the slider moves. width <- slider # name "Picture Width" # range 0.1 5 -- Rerun this event every key press. It can modify the state. onEvent (keyPress 'c') $ do modifyState doSomething -- Make a diagram using the current state. Rerun every time a -- slider value changes or key press event happens. diagram <- makeDiagram -- Show the diagram. This is what will chance in the IHaskell display. display diagram I have Diagrams already working with IHaskell, and interactivity already working in another example (interactive parsers with Parsec, see error messages etc as you type), so all that remains is combining them. I'm hoping to get it working nicely sometime this summer when I have more time, but if you're interested in this approach, feel free to contact me. [0] IHaskell: https://github.com/gibiansky/IHaskell On Mon, Apr 7, 2014 at 4:44 PM, Kai Zhang wrote: > Hi cafe, > > Is there any active project about creating interactive diagrams, like D3js > http://d3js.org/ ? The Diagrams library has already done a good job of > making static images. Would it be possible to extend this library to > support declaring interactive diagrams and then use JS and HTML as backend > to draw them? > > Example: circle 1 $ with & hover .~ (change style) > > PS: I don't want a D3js binding. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai at kzhang.org Tue Apr 8 00:55:34 2014 From: kai at kzhang.org (Kai Zhang) Date: Mon, 7 Apr 2014 17:55:34 -0700 Subject: [Haskell-cafe] Library for creating interactive diagrams? In-Reply-To: References: Message-ID: Looks like you are going to add some "control bars" to diagrams. This is definitely a nice feature to have. But how would you be able to do something like changing the color of a circle when you place the mouse on it? I want control bars as well as some interactivity built directly into the SVG. On Mon, Apr 7, 2014 at 4:56 PM, Andrew Gibiansky wrote: > I am very interested in using this with IHaskell, but don't know of > something that exists already. I am currently working on using IPython > widgets with IHaskell in order to create a generic "event handling" > framework for *any* sort of displays. Code might look like this (just > some initial thoughts): > > -- Uses a StateT of some sort. Reruns things every time > -- a dependent value changes, and shows the updated output. > interactive $ do > -- Display a slider. The value changes every time the slider moves. > width <- slider # name "Picture Width" # range 0.1 5 > > -- Rerun this event every key press. It can modify the state. > onEvent (keyPress 'c') $ do > modifyState doSomething > > -- Make a diagram using the current state. Rerun every time a > -- slider value changes or key press event happens. > diagram <- makeDiagram > > -- Show the diagram. This is what will chance in the IHaskell display. > display diagram > > I have Diagrams already working with IHaskell, and interactivity already > working in another example (interactive parsers with Parsec, see error > messages etc as you type), so all that remains is combining them. I'm > hoping to get it working nicely sometime this summer when I have more time, > but if you're interested in this approach, feel free to contact me. > > [0] IHaskell: https://github.com/gibiansky/IHaskell > > > On Mon, Apr 7, 2014 at 4:44 PM, Kai Zhang wrote: > >> Hi cafe, >> >> Is there any active project about creating interactive diagrams, like >> D3js http://d3js.org/ ? The Diagrams library has already done a good job >> of making static images. Would it be possible to extend this library to >> support declaring interactive diagrams and then use JS and HTML as backend >> to draw them? >> >> Example: circle 1 $ with & hover .~ (change style) >> >> PS: I don't want a D3js binding. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.clover at gmail.com Tue Apr 8 01:07:58 2014 From: s.clover at gmail.com (Sterling Clover) Date: Mon, 07 Apr 2014 21:07:58 -0400 Subject: [Haskell-cafe] Directed rounding in haskell ? In-Reply-To: <20140407141231.GA3594@fuckup> References: <20140407141231.GA3594@fuckup> Message-ID: <53434BEE.4000407@gmail.com> You can set the rounding mode directly with ieee-utils. Apparently it doesn't compile anymore, so someone has uploaded a temporary replacement: http://hackage.haskell.org/package/ieee-utils-tempfix-0.4.0.1 The primary maintainer of the original package left the haskell community some time ago. (I contributed some additional code many years ago). Michal Konecny -- would you be interested in taking over maintainership? -s On 4/7/14, 10:12 AM, Dominik Peteler wrote: > Hello list, > > I'm going to implement an interval arithmetic library (following the IEEE P1788) in Haskell and for > that I need support for directed rounding to the nearest floating point > number. I had a quick look at the Decimal package which comes with the > `roundTo` function for rounding to a specified number of decimal places > but it doesn't provide directed rounding. > Is there way to get directed rounding to to the nearest float (maybe > even with machine floats) ? > > I'm also aware of the AERN-* packages but they seem to be unmaintained. At > least there is no version which builds with the current GHC. Does > anybody know something about that ? > > Regards > > dominik > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.gibiansky at gmail.com Tue Apr 8 01:18:32 2014 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Mon, 7 Apr 2014 18:18:32 -0700 Subject: [Haskell-cafe] Library for creating interactive diagrams? In-Reply-To: References: Message-ID: All of this would rely on the IHaskell interface, and would not work with any other interface or work with raw SVG/HTML/JS/etc. I'd love to have a different approach though, in case anyone knows of one :) On Mon, Apr 7, 2014 at 5:55 PM, Kai Zhang wrote: > Looks like you are going to add some "control bars" to diagrams. This is > definitely a nice feature to have. But how would you be able to do > something like changing the color of a circle when you place the mouse on > it? I want control bars as well as some interactivity built directly into > the SVG. > > > On Mon, Apr 7, 2014 at 4:56 PM, Andrew Gibiansky < > andrew.gibiansky at gmail.com> wrote: > >> I am very interested in using this with IHaskell, but don't know of >> something that exists already. I am currently working on using IPython >> widgets with IHaskell in order to create a generic "event handling" >> framework for *any* sort of displays. Code might look like this (just >> some initial thoughts): >> >> -- Uses a StateT of some sort. Reruns things every time >> -- a dependent value changes, and shows the updated output. >> interactive $ do >> -- Display a slider. The value changes every time the slider moves. >> width <- slider # name "Picture Width" # range 0.1 5 >> >> -- Rerun this event every key press. It can modify the state. >> onEvent (keyPress 'c') $ do >> modifyState doSomething >> >> -- Make a diagram using the current state. Rerun every time a >> -- slider value changes or key press event happens. >> diagram <- makeDiagram >> >> -- Show the diagram. This is what will chance in the IHaskell display. >> display diagram >> >> I have Diagrams already working with IHaskell, and interactivity already >> working in another example (interactive parsers with Parsec, see error >> messages etc as you type), so all that remains is combining them. I'm >> hoping to get it working nicely sometime this summer when I have more time, >> but if you're interested in this approach, feel free to contact me. >> >> [0] IHaskell: https://github.com/gibiansky/IHaskell >> >> >> On Mon, Apr 7, 2014 at 4:44 PM, Kai Zhang wrote: >> >>> Hi cafe, >>> >>> Is there any active project about creating interactive diagrams, like >>> D3js http://d3js.org/ ? The Diagrams library has already done a good >>> job of making static images. Would it be possible to extend this library to >>> support declaring interactive diagrams and then use JS and HTML as backend >>> to draw them? >>> >>> Example: circle 1 $ with & hover .~ (change style) >>> >>> PS: I don't want a D3js binding. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ducis_cn at 126.com Tue Apr 8 01:21:53 2014 From: ducis_cn at 126.com (ducis) Date: Tue, 8 Apr 2014 09:21:53 +0800 (CST) Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: References: Message-ID: <4e2389c8.9600.1453eed592e.Coremail.ducis_cn@126.com> No, there is no theory behind it. I personally feel it convenient. ? 2014-04-08 04:58:30?"Kim-Ee Yeoh" ??? On Mon, Apr 7, 2014 at 11:02 PM, ducis wrote: It lets your write lambdas with 'slots' without inventing names for the parameters. [s| ? + ? |] = \x y -> x+y I have no background in this 'slot lambda' and a search reveals this package as the only hit. Which may explain why I find the example given confusing. Why would [s| 1+1 |] not be equivalent to \x->x+x ? -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From achudnov at gmail.com Tue Apr 8 01:30:16 2014 From: achudnov at gmail.com (Andrey Chudnov) Date: Mon, 07 Apr 2014 21:30:16 -0400 Subject: [Haskell-cafe] Library for creating interactive diagrams? In-Reply-To: References: Message-ID: <53435128.1020102@gmail.com> Have you looked at interactive-diagrams [1]? [1] https://github.com/co-dan/interactive-diagrams On 04/07/2014 07:44 PM, Kai Zhang wrote: > Hi cafe, > > Is there any active project about creating interactive diagrams, like > D3js http://d3js.org/ ? The Diagrams library has already done a good > job of making static images. Would it be possible to extend this > library to support declaring interactive diagrams and then use JS and > HTML as backend to draw them? > > Example: circle 1 $ with & hover .~ (change style) > > PS: I don't want a D3js binding. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ducis_cn at 126.com Tue Apr 8 01:34:48 2014 From: ducis_cn at 126.com (ducis) Date: Tue, 8 Apr 2014 09:34:48 +0800 (CST) Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: References: Message-ID: <7a6b5a81.9c91.1453ef92b1b.Coremail.ducis_cn@126.com> Thanks. [s|_0 + _1|] = \x y->x+y is supported. I simply like [s|_+_|] better personally. And [s|_+_?|] is for \x->x+x. I have to admit that '?' character is not very recognizable though. Any suggestions of another 'Letter, Lowercase' unicode character that no one would use as a variable name and can be easily input in vim are welcome. At 2014-04-08 05:12:26,"Alois Cochard" wrote: In order to give a more constructive feedback, why not simply indexing arguments by position and use the `_N` syntax? The second example would be: _0 : _1 : _1 : _2 : _2 : _2 : _0 : [] One could just use `_` if there is only one arg: _ + _ (which mean what Kim thought it would mean) and use: _0 + _1 (for the case you wanted to support) Cheers On 7 April 2014 22:01, Alois Cochard wrote: I just want to add that I find the syntax extremely confusing and counter intuitive. I thought it was just me, or that I was missed something. But it looks like I'm not the only one. On 7 April 2014 21:58, Kim-Ee Yeoh wrote: On Mon, Apr 7, 2014 at 11:02 PM, ducis wrote: It lets your write lambdas with 'slots' without inventing names for the parameters. [s| ? + ? |] = \x y -> x+y I have no background in this 'slot lambda' and a search reveals this package as the only hit. Which may explain why I find the example given confusing. Why would [s| 1+1 |] not be equivalent to \x->x+x ? -- Kim-Ee _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alois Cochard http://aloiscochard.blogspot.com http://twitter.com/aloiscochard http://github.com/aloiscochard -- Alois Cochard http://aloiscochard.blogspot.com http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai at kzhang.org Tue Apr 8 01:46:06 2014 From: kai at kzhang.org (Kai Zhang) Date: Mon, 7 Apr 2014 18:46:06 -0700 Subject: [Haskell-cafe] Library for creating interactive diagrams? In-Reply-To: <53435128.1020102@gmail.com> References: <53435128.1020102@gmail.com> Message-ID: Pretty nice. I'll definite take a look into it. But currently the documentation is poor. Thanks! On Mon, Apr 7, 2014 at 6:30 PM, Andrey Chudnov wrote: > Have you looked at interactive-diagrams [1]? > > [1] https://github.com/co-dan/interactive-diagrams > > > On 04/07/2014 07:44 PM, Kai Zhang wrote: > > Hi cafe, > > Is there any active project about creating interactive diagrams, like > D3js http://d3js.org/ ? The Diagrams library has already done a good job > of making static images. Would it be possible to extend this library to > support declaring interactive diagrams and then use JS and HTML as backend > to draw them? > > Example: circle 1 $ with & hover .~ (change style) > > PS: I don't want a D3js binding. > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ducis_cn at 126.com Tue Apr 8 02:06:10 2014 From: ducis_cn at 126.com (ducis) Date: Tue, 8 Apr 2014 10:06:10 +0800 (CST) Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: <53431032.1020105@informatik.uni-marburg.de> References: <53431032.1020105@informatik.uni-marburg.de> Message-ID: <424e574.ac29.1453f15e412.Coremail.ducis_cn@126.com> Does it depend on Stratego/XT? As far as I know I have to live in the Eclipse environment to use anything depending on Stratego/XT. At 2014-04-08 04:53:06,"Tillmann Rendel" wrote: >Hi, > >Ducis wrote: >> Actually I wonder how to achieve that without rolling my own haskell parser or forking haskell-src-exts. > >Adam vogt wrote: >> Ideally there could be something like camlp4 for haskell, but as far >> as I know there isn't such a thing. > >We built SugarHaskell to explore that design space. See our paper at the >Haskell Symposium 2012: > > http://sugarj.org/sugarhaskell.pdf > >While there is not much going on about SugarHaskell specifically, the >underlying language-independent framework is still actively developed, >in the https://github.com/sugar-lang organization. The eclipse plugin >for SugarHaskell from http://update.sugarj.org/ should work. I don't >know what the status of the command-line version is, though. > >Even if you don't want to use all of SugarHaskell, the underlying easily >extensible grammar might still be a good starting point. It uses >declarative layout constraints to specify Haskell's layout in a modular >way. See our paper at the conference on software language engineering 2012: > > http://sugarj.org/layout-parsing.pdf > >Tillmann From carter.schonwald at gmail.com Tue Apr 8 02:38:41 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 7 Apr 2014 22:38:41 -0400 Subject: [Haskell-cafe] Directed rounding in haskell ? In-Reply-To: <53434BEE.4000407@gmail.com> References: <20140407141231.GA3594@fuckup> <53434BEE.4000407@gmail.com> Message-ID: if you ask for taking over maintainership on the libraries list, I can give you uploader acls On Mon, Apr 7, 2014 at 9:07 PM, Sterling Clover wrote: > You can set the rounding mode directly with ieee-utils. > > Apparently it doesn't compile anymore, so someone has uploaded a temporary > replacement: http://hackage.haskell.org/package/ieee-utils-tempfix-0.4.0.1 > > The primary maintainer of the original package left the haskell community > some time ago. (I contributed some additional code many years ago). Michal > Konecny -- would you be interested in taking over maintainership? > > -s > > On 4/7/14, 10:12 AM, Dominik Peteler wrote: > > Hello list, > > I'm going to implement an interval arithmetic library (following the IEEE P1788) in Haskell and for > that I need support for directed rounding to the nearest floating point > number. I had a quick look at the Decimal package which comes with the > `roundTo` function for rounding to a specified number of decimal places > but it doesn't provide directed rounding. > Is there way to get directed rounding to to the nearest float (maybe > even with machine floats) ? > > I'm also aware of the AERN-* packages but they seem to be unmaintained. At > least there is no version which builds with the current GHC. Does > anybody know something about that ? > > Regards > > dominik > > > > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.solla at gmail.com Tue Apr 8 02:43:02 2014 From: alex.solla at gmail.com (Alexander Solla) Date: Mon, 7 Apr 2014 19:43:02 -0700 Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: References: <20140407211618.GZ13760@weber> Message-ID: On Mon, Apr 7, 2014 at 4:12 PM, Alois Cochard wrote: > :-) > > Ok, nevermind. That's just me which is has no understanding of the context > then, like Kim. > I wouldn't go that far. It's just that when you spend hundreds of hours naming "all of the possible kinds of things" in a formal language, notation kind of becomes transparent. And ducis says it's just a coincidence. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maydwell at gmail.com Tue Apr 8 05:34:49 2014 From: maydwell at gmail.com (Lyndon Maydwell) Date: Tue, 8 Apr 2014 15:34:49 +1000 Subject: [Haskell-cafe] ANN: Melbourne Haskell Users Group Message-ID: Hi Haskellers, A few people have been meeting up in the Melbourne CBD to talk about Haskell for the past couple of months. This month I've asked Bernie Pope (who organised the Melbourne Functional Programming Union) to give a talk about two libraries he has written in Haskell that compile Python code to Haskell, and Python Byte-Code. I thought I'd take the opportunity to announce the this meetup and the group in general to the wider Haskell community in case there is anyone in Melbourne who would be interested in coming along. The talk will be on Thursday, April 24. Details can be found at: http://www.meetup.com/Melbourne-Haskell-Users-Group/events/174401572/ Hope to see you there! - Lyndon From jeanchristophe.mincke at gmail.com Tue Apr 8 07:25:17 2014 From: jeanchristophe.mincke at gmail.com (jean-christophe mincke) Date: Tue, 8 Apr 2014 09:25:17 +0200 Subject: [Haskell-cafe] Question about typeclass & constraints Message-ID: Hello Consider the following data, class and instance: class PP m where create :: a -> m a data A a = A a instance PP A where create a = A a And then: class CB a where fb :: a -> Int data B m a = B (m a) If I try to define an instance of PP for B with the following implementation: instance (PP m) => PP (B m) where create a = let _ = fb a in B (create a) GHC issues the (expected) error: Could not deduce (CB a) arising from a use of 'fb' from the context (PP m). So the workaround I am using is to define a new class PP' where the type a is made more explicit. That allows the constraint (CB a) to be stated in an instance declaration. class PP' m a where create' :: a -> m a instance (PP m) => PP' m a where create' = create instance (PP m, CB a) => PP' (B m) a where create' a = let _ = fb a in B (create a) So, my question is: is there a way to achieve the same results without having to create the new class PP'? Thank you for your help J-C -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Tue Apr 8 07:42:06 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 8 Apr 2014 08:42:06 +0100 Subject: [Haskell-cafe] Question about typeclass & constraints In-Reply-To: References: Message-ID: <20140408074206.GA18048@weber> On Tue, Apr 08, 2014 at 09:25:17AM +0200, jean-christophe mincke wrote: > instance (PP m) => PP (B m) where > create a = let _ = fb a > in B (create a) Your use of 'fb' here is baffling. Am I right in thinking you have tried to simplify your problem for clarity? If so I think you have simplified too far! Could you give an example where the use of 'fb' actually matters? Tom From jeanchristophe.mincke at gmail.com Tue Apr 8 08:17:50 2014 From: jeanchristophe.mincke at gmail.com (jean-christophe mincke) Date: Tue, 8 Apr 2014 10:17:50 +0200 Subject: [Haskell-cafe] Question about typeclass & constraints In-Reply-To: <20140408074206.GA18048@weber> References: <20140408074206.GA18048@weber> Message-ID: Tom, Yes of course it is simplified for clarity. Here is a modified version where fb does something (a bit more usefull) class PP m where create :: a -> m a data A a = A a instance PP A where create a = A a class CB a where fb :: a -> a data B m a = B (m a) instance (PP m) => PP (B m) where create a = let a' = fb a in B (create a') class PP' m a where create' :: a -> m a instance (PP m) => PP' m a where create' = create instance (PP m, CB a) => PP' (B m) a where create' a = let a' = fb a in B (create a') Actually I ran into that problem when trying to add a kind of rule engine layer above the Persistent typeclass. Given the complexity of these typeclass, I think it is more practical to reason about a simpler form of the same problem. Thanks J-C On Tue, Apr 8, 2014 at 9:42 AM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Tue, Apr 08, 2014 at 09:25:17AM +0200, jean-christophe mincke wrote: > > instance (PP m) => PP (B m) where > > create a = let _ = fb a > > in B (create a) > > Your use of 'fb' here is baffling. Am I right in thinking you have tried > to > simplify your problem for clarity? If so I think you have simplified too > far! > > Could you give an example where the use of 'fb' actually matters? > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Tue Apr 8 08:41:09 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 8 Apr 2014 09:41:09 +0100 Subject: [Haskell-cafe] Question about typeclass & constraints In-Reply-To: References: <20140408074206.GA18048@weber> Message-ID: <20140408084109.GB18048@weber> On Tue, Apr 08, 2014 at 10:17:50AM +0200, jean-christophe mincke wrote: > class PP m where > create :: a -> m a > > data A a = A a > instance PP A where > create a = A a > > class CB a where > fb :: a -> a > > data B m a = B (m a) > instance (PP m) => PP (B m) where > create a = let a' = fb a > in B (create a') Thanks for the clarified example. The failure here is not a technicality. There's a very good reason it can't work this way: 'create' is required to be parametrically polymorphic in 'a' but 'fb' is specialised to the *particular* 'a' in the typeclass constraint. Thus you can't use 'fb' to implement 'create'! > class PP' m a where > create' :: a -> m a > > instance (PP m) => PP' m a where > create' = create > > instance (PP m, CB a) => PP' (B m) a where > create' a = let a' = fb a > in B (create a') create' is not required to be parametric, hence you can use 'fb' in its implementation. Without knowing more about your specific use case it's hard to know what to suggest. Personally speaking though, I am not a fan of complicated typeclass algebra, and prefer to create and pass dictionaries explicitly for all but the most trivial cases. Tom From hesselink at gmail.com Tue Apr 8 08:53:01 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Tue, 8 Apr 2014 10:53:01 +0200 Subject: [Haskell-cafe] Question about typeclass & constraints In-Reply-To: References: <20140408074206.GA18048@weber> Message-ID: I've run into problems like this as well. Often you can redesign a bit to fix things, although it depends on the application how to do that. Two other technical options in addition to your PP': You can add a constraint to the 'create' function. It depends on the actual semantics if this makes sense, I guess: class PP2 m where create :: CB a => a -> m a You can use ConstraintKinds [1] to add a constraint to create depending on the type 'm': type family C m a :: Constraint class PP3 m where create :: C m a => a -> m a This way you can choose if you want to add a constraint and which one, depending on the 'm'. If you can solve it without any of these things, I'd probably prefer that personally, though. As Tom also said, complicated type class constructions often make your program more difficult to understand and maintain. Erik [1] http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/constraint-kind.html On Tue, Apr 8, 2014 at 10:17 AM, jean-christophe mincke wrote: > Tom, > > Yes of course it is simplified for clarity. > > Here is a modified version where fb does something (a bit more usefull) > > > class PP m where > create :: a -> m a > > data A a = A a > instance PP A where > create a = A a > > class CB a where > fb :: a -> a > > data B m a = B (m a) > instance (PP m) => PP (B m) where > create a = let a' = fb a > in B (create a') > > class PP' m a where > create' :: a -> m a > > instance (PP m) => PP' m a where > create' = create > > instance (PP m, CB a) => PP' (B m) a where > create' a = let a' = fb a > in B (create a') > > Actually I ran into that problem when trying to add a kind of rule engine > layer above the Persistent typeclass. Given the complexity of these > typeclass, I think it is more practical to reason about a simpler form of > the same problem. > > Thanks > > J-C > > On Tue, Apr 8, 2014 at 9:42 AM, Tom Ellis > wrote: >> >> On Tue, Apr 08, 2014 at 09:25:17AM +0200, jean-christophe mincke wrote: >> > instance (PP m) => PP (B m) where >> > create a = let _ = fb a >> > in B (create a) >> >> Your use of 'fb' here is baffling. Am I right in thinking you have tried >> to >> simplify your problem for clarity? If so I think you have simplified too >> far! >> >> Could you give an example where the use of 'fb' actually matters? >> >> Tom >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From mail at joachim-breitner.de Tue Apr 8 09:20:38 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 08 Apr 2014 11:20:38 +0200 Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: <7a6b5a81.9c91.1453ef92b1b.Coremail.ducis_cn@126.com> References: <7a6b5a81.9c91.1453ef92b1b.Coremail.ducis_cn@126.com> Message-ID: <1396948838.2514.26.camel@kirk> Hi, Am Dienstag, den 08.04.2014, 09:34 +0800 schrieb ducis: > Thanks. [s|_0 + _1|] = \x y->x+y is supported. I simply like [s|_+_|] > better personally. And [s|_+_?|] is for \x->x+x. I have to admit that > '?' character is not very recognizable though. Any suggestions of > another 'Letter, Lowercase' unicode character that no one would use as > a variable name and can be easily input in vim are welcome. not sure about vim-inputability, but from http://www.fileformat.info/info/unicode/category/Ll/list.htm these look like slots to me: ? ? ? (But seriously, _ is nicer.) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jeanchristophe.mincke at gmail.com Tue Apr 8 09:25:36 2014 From: jeanchristophe.mincke at gmail.com (jean-christophe mincke) Date: Tue, 8 Apr 2014 11:25:36 +0200 Subject: [Haskell-cafe] Question about typeclass & constraints In-Reply-To: References: <20140408074206.GA18048@weber> Message-ID: Thank you The problem here is that I cannot modify the original PP class (In fact it, in the real life, it is PersistStore). So I guess I am left with PP' solution. Regards J-C On Tue, Apr 8, 2014 at 10:53 AM, Erik Hesselink wrote: > I've run into problems like this as well. Often you can redesign a bit > to fix things, although it depends on the application how to do that. > Two other technical options in addition to your PP': > > You can add a constraint to the 'create' function. It depends on the > actual semantics if this makes sense, I guess: > > class PP2 m where > create :: CB a => a -> m a > > You can use ConstraintKinds [1] to add a constraint to create > depending on the type 'm': > > type family C m a :: Constraint > > class PP3 m where > create :: C m a => a -> m a > > This way you can choose if you want to add a constraint and which one, > depending on the 'm'. > > If you can solve it without any of these things, I'd probably prefer > that personally, though. As Tom also said, complicated type class > constructions often make your program more difficult to understand and > maintain. > > Erik > > [1] > http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/constraint-kind.html > > On Tue, Apr 8, 2014 at 10:17 AM, jean-christophe mincke > wrote: > > Tom, > > > > Yes of course it is simplified for clarity. > > > > Here is a modified version where fb does something (a bit more usefull) > > > > > > class PP m where > > create :: a -> m a > > > > data A a = A a > > instance PP A where > > create a = A a > > > > class CB a where > > fb :: a -> a > > > > data B m a = B (m a) > > instance (PP m) => PP (B m) where > > create a = let a' = fb a > > in B (create a') > > > > class PP' m a where > > create' :: a -> m a > > > > instance (PP m) => PP' m a where > > create' = create > > > > instance (PP m, CB a) => PP' (B m) a where > > create' a = let a' = fb a > > in B (create a') > > > > Actually I ran into that problem when trying to add a kind of rule engine > > layer above the Persistent typeclass. Given the complexity of these > > typeclass, I think it is more practical to reason about a simpler form of > > the same problem. > > > > Thanks > > > > J-C > > > > On Tue, Apr 8, 2014 at 9:42 AM, Tom Ellis > > wrote: > >> > >> On Tue, Apr 08, 2014 at 09:25:17AM +0200, jean-christophe mincke wrote: > >> > instance (PP m) => PP (B m) where > >> > create a = let _ = fb a > >> > in B (create a) > >> > >> Your use of 'fb' here is baffling. Am I right in thinking you have > tried > >> to > >> simplify your problem for clarity? If so I think you have simplified > too > >> far! > >> > >> Could you give an example where the use of 'fb' actually matters? > >> > >> Tom > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Tue Apr 8 10:40:00 2014 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Tue, 8 Apr 2014 12:40:00 +0200 Subject: [Haskell-cafe] Haskell + emacs + Ghc-mod 4.0.1 In-Reply-To: <1AE112E3-EE4B-4FD2-9AC1-11F4C032C2CF@gmail.com> References: <20140404.063024.573783403235305621.kazu@iij.ad.jp> <1AE112E3-EE4B-4FD2-9AC1-11F4C032C2CF@gmail.com> Message-ID: > And yes, 'spec' is a typo, the error message appears as a tooltip in emacs > so I cannot copy/paste it as text. > Pressing "M-?" should help seeing full message, if I understood the problem correctly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rendel at informatik.uni-marburg.de Tue Apr 8 12:37:04 2014 From: rendel at informatik.uni-marburg.de (Tillmann Rendel) Date: Tue, 08 Apr 2014 14:37:04 +0200 Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: <424e574.ac29.1453f15e412.Coremail.ducis_cn@126.com> References: <53431032.1020105@informatik.uni-marburg.de> <424e574.ac29.1453f15e412.Coremail.ducis_cn@126.com> Message-ID: <5343ED70.4000104@informatik.uni-marburg.de> Hi, Ducis asked about SugarHaskell: > Does it depend on Stratego/XT? SugarHaskell uses Stratego and SDF, but all necessary tools are bundled, so you only need a Java virtual machine (and maybe a Java compiler, not sure). Most of the tools are bundled as Java class files. Two tools (sdf2table and implodePT) are bundled as a statically linked executable for common platforms. On a non-common platform, you would have to compile these from their C sources. There is a release of SugarHaskell on hackage: http://hackage.haskell.org/package/sugarhaskell The tarball consists mostly of *.jar files and native executables. Looking at the timestamp, this is obviously outdated, but it should work and give you a first impression. I'm sure an updated release on Hackage could be provided. (Eclipse is the main platform for SugarHaskell and the other Sugar languages, because we want to provide extensible syntax highlighting and other editor features. The process for making the Hackage release was to write a simple driver for the command-line interface that essentially calls java with the right parameters, and figure out which *.jar files from an Eclipse installation we need to bundle to make it work. The latter was done manually, and could be done manually again for a more recent SugarHaskell-in-Eclipse installation). Tillmann From klao at nilcons.com Tue Apr 8 14:23:18 2014 From: klao at nilcons.com (Mihaly Barasz) Date: Tue, 8 Apr 2014 16:23:18 +0200 Subject: [Haskell-cafe] Towards a better time library (announcing tz) In-Reply-To: References: <20140331181543.GA20036@cs.elte.hu> Message-ID: >> I don't think you really need to do this, it was just a minor >> suggestion I made. As long as it's mentioned in the package and module >> documentation what tz database version is being used, it should be >> fine. > > I might do it anyway. It's a nice separation, and also others who > don't want to use `TZ` (like `timezone-olson`) might benefit from it > too. I have separated the "data" part into a separate `tzdata` package: http://hackage.haskell.org/package/tzdata It should be completely `tz` agnostic and suitable for use with `timezone-{olson,series}` packages too. I have adopted Renzo's updated versioning suggestion: `A.B.YYYYMMDD.C`, where `A.B` describes the Haskell API as usual, and YYYYMMDD the official release date of time zone database contained. This way you normally specify only a `>= A.B` dependency and get the latest data released with the API you can handle. But you _can_ also specify that you need "fresh" time zone data if you _want_ to. Also, some numbers (which I only sent to Renzo by mistake): If you depend on Data.Time.Zones.All, you binary size increases by about 2M. (Of course, if you don't import it just use the rest of the package, you don't pay anything.) I don't know why is it so much, the data itself is less than 450k. I will look into it later. The memory usage increases by about 900k if you use _all_ of the time zones. But, because they are all parsed lazily, you only pay for what you use. If you don't touch any of the TZs, you don't pay anything in memory. (And this 900k is probably fair: the in-memory representation of `TZ` is not that compact. But, I have a few ideas how to improve on that.) Mihaly From ducis_cn at 126.com Tue Apr 8 15:47:26 2014 From: ducis_cn at 126.com (ducis) Date: Tue, 8 Apr 2014 23:47:26 +0800 (CST) Subject: [Haskell-cafe] ANNOUNCE slot-lambda In-Reply-To: <5343ED70.4000104@informatik.uni-marburg.de> References: <53431032.1020105@informatik.uni-marburg.de> <424e574.ac29.1453f15e412.Coremail.ducis_cn@126.com> <5343ED70.4000104@informatik.uni-marburg.de> Message-ID: <6bae166f.21258.1454205c961.Coremail.ducis_cn@126.com> So, it means that using Stratego outside of Eclipse is not that hard? Cool. I've heard of Stratego before. It's time to try again. Thanks for the information. At 2014-04-08 20:37:04,"Tillmann Rendel" wrote: >Hi, > >Ducis asked about SugarHaskell: >> Does it depend on Stratego/XT? > >SugarHaskell uses Stratego and SDF, but all necessary tools are bundled, >so you only need a Java virtual machine (and maybe a Java compiler, not >sure). Most of the tools are bundled as Java class files. Two tools >(sdf2table and implodePT) are bundled as a statically linked executable >for common platforms. On a non-common platform, you would have to >compile these from their C sources. > >There is a release of SugarHaskell on hackage: > > http://hackage.haskell.org/package/sugarhaskell > >The tarball consists mostly of *.jar files and native executables. >Looking at the timestamp, this is obviously outdated, but it should work >and give you a first impression. I'm sure an updated release on Hackage >could be provided. > >(Eclipse is the main platform for SugarHaskell and the other Sugar >languages, because we want to provide extensible syntax highlighting and >other editor features. The process for making the Hackage release was to >write a simple driver for the command-line interface that essentially >calls java with the right parameters, and figure out which *.jar files >from an Eclipse installation we need to bundle to make it work. The >latter was done manually, and could be done manually again for a more >recent SugarHaskell-in-Eclipse installation). > > Tillmann From KAction at gnu.org Tue Apr 8 17:05:33 2014 From: KAction at gnu.org (Dmitry Bogatov) Date: Tue, 8 Apr 2014 21:05:33 +0400 Subject: [Haskell-cafe] Automatically infer Newtype instance Message-ID: <20140408170533.GA2043@localhost.kaction.name> Hello! I think, that Newtype instances are transitive, and there is only one sane definiton is (pack . pack). But in example below I have to use UndecidableInstances and they seems to loop somewhere (Context reduction stack overflow; size = 132). To my understanding, Ghc tries to prove, that exists only one type b, and somewhy fail at it(It is unclear, why), but is it any way to say to it that I take responsibility, that ANY b would be nice? I know about TH, but interested in more elegant solution. {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} import Control.Newtype newtype A1 = A1 Int deriving (Eq, Show) newtype A2 = A2 A1 deriving (Eq, Show) instance Newtype A1 Int where pack = A1 unpack (A1 a) = a instance Newtype A2 A1 where pack = A2 unpack (A2 a) = a -- Here comes UndecidableInstances instance (Newtype a b, Newtype b c) => Newtype a c where pack = pack . pack unpack = unpack . unpack main = let foo :: A2 foo = pack "46" in print foo -- Best regards, Dmitry Bogatov , Free Software supporter, esperantisto and netiquette guardian. git://kaction.name/rc-files.git GPG: 54B7F00D From carter.schonwald at gmail.com Tue Apr 8 21:39:30 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 8 Apr 2014 17:39:30 -0400 Subject: [Haskell-cafe] Automatically infer Newtype instance In-Reply-To: <20140408170533.GA2043@localhost.kaction.name> References: <20140408170533.GA2043@localhost.kaction.name> Message-ID: you should checkout genealizednewtype deriving :) https://ghc.haskell.org/trac/haskell-prime/wiki/NewtypeDeriving GHC has had it for quite some time also the Coerce Machinery in 7.8 GHC provides a stronger version of your NewType style class On Tue, Apr 8, 2014 at 1:05 PM, Dmitry Bogatov wrote: > Hello! > I think, that Newtype instances are transitive, and there is only one > sane definiton is (pack . pack). But in example below I have to use > UndecidableInstances and they seems to loop somewhere > (Context reduction stack overflow; size = 132). > > To my understanding, Ghc tries to prove, that exists only one type b, > and somewhy fail at it(It is unclear, why), but is it any way to say to > it that I take responsibility, that ANY b would be nice? > > I know about TH, but interested in more elegant solution. > > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE FunctionalDependencies #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE UndecidableInstances #-} > > import Control.Newtype > > newtype A1 = A1 Int deriving (Eq, Show) > newtype A2 = A2 A1 deriving (Eq, Show) > > instance Newtype A1 Int where > pack = A1 > unpack (A1 a) = a > > instance Newtype A2 A1 where > pack = A2 > unpack (A2 a) = a > > -- Here comes UndecidableInstances > instance (Newtype a b, Newtype b c) => Newtype a c where > pack = pack . pack > unpack = unpack . unpack > > main = let foo :: A2 > foo = pack "46" in > print foo > > > -- > Best regards, Dmitry Bogatov , > Free Software supporter, esperantisto and netiquette guardian. > git://kaction.name/rc-files.git > GPG: 54B7F00D > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkarcher at mkarcher.dialup.fu-berlin.de Tue Apr 8 05:55:38 2014 From: mkarcher at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Tue, 8 Apr 2014 05:55:38 +0000 (UTC) Subject: [Haskell-cafe] GHC Optimization seriously hurting performance by unsharing. Message-ID: Hello Haskell folks, Can you give me a hint whether the GHC optimizer behaviour demonstrated below should be considered a bug? If it is no bug, what should I keep in mind to make sure not to hit that trap again? This posting is (obviously) formatted as literal Haskell file, so feel free to try. This is a case where -O2 completely kills performance, because it unshares an object that should be shared. I stumbled across this behaviour of GHC 7.6.3 when trying to solve RMQ from hackerrank. Lets start with a typical header, the reason for the IORef module is discussed later. > module Main where > import Data.Set (member, fromAscList) > import Control.Monad (replicateM_) > import Data.IORef Now lets get to the code. > main = do The original problem statement requested to read a set of numbers from the standard input. To have this testcase self-contained, we use a "virtual file" instead, which is an (IORef String). The key point is that we need to get the string with the space-sperated test element from an IO operation, whereas it does not matter whether it is "getLine" or "readIORef" > ior <- newIORef $ unwords $ map show $ [1..20000] Now read the space-separated test input from an IO action. > testdata <- fmap (map read.words) $ readIORef ior and build a set from the number array we obtained to speed up membership queries. You don't want to search 20.000 numbers on each iteration. > let bigset = fromAscList testdata finally query the membership of the number 5 several times. This happens to be reasonably fast if compiled without optimization, but goes down to dog slow if compiled with optimization, as the set building process is hoisted into the loop and thus performed 10 times. > replicateM_ 10 . print . member 5 $ bigset this is the solution (or the workaround) to the problem. If you use this line, things get fast, because the loop gets created after evaluting the set to WHNF, thus forcing sharing replicateM_ 10 . print . member 5 $! bigset Enabling both of the replicateM_ lines also speeds up the first one, as the use of bigset in both lines prevents hoisting set construction into the first loop. Regards, Michael Karcher From alex.solla at gmail.com Wed Apr 9 03:11:35 2014 From: alex.solla at gmail.com (Alexander Solla) Date: Tue, 8 Apr 2014 20:11:35 -0700 Subject: [Haskell-cafe] Confused about type seen in the wild Message-ID: I'm using the yesod-markdown package as a "template" for making my own yesod-mathjax package. I'm pretty much done, and it does compile now, but I'm just really confused by a type that looks like bad syntax. In fact, I ended up trying to "fix" it, which lead to errors: mathJaxField :: Monad m => RenderMessage (HandlerSite m) FormMessage => Field m MathJax Notice that there are two type arrows (=>). Interestingly, mathJaxField :: ( Monad m , RenderMessage (HandlerSite m) FormMessage ) => Field m MathJax compiles too. So it looks like currying/uncurrying, at the type level. But when did this start? I'm using GHC 7.6.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Wed Apr 9 05:11:41 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 9 Apr 2014 12:11:41 +0700 Subject: [Haskell-cafe] GHC Optimization seriously hurting performance by unsharing. In-Reply-To: References: Message-ID: On Tue, Apr 8, 2014 at 12:55 PM, Michael Karcher < mkarcher at mkarcher.dialup.fu-berlin.de> wrote: > > > let bigset = fromAscList testdata > > finally query the membership of the number 5 several times. This happens > to be reasonably fast if compiled without optimization, but goes down to > dog slow if compiled with optimization, as the set building process is > hoisted into the loop and thus performed 10 times. > > > replicateM_ 10 . print . member 5 $ bigset > Isn't this 'hoisting into the loop' a case of over-aggressive inlining, a known pitfall of -O2 ? What happens with plain -O, which is the recommended general-purpose setting? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Apr 9 05:12:11 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 9 Apr 2014 08:12:11 +0300 Subject: [Haskell-cafe] Stackage with GHC 7.8: build results Message-ID: I'm happy to report that after about six months, enough upper bounds have been corrected on Hackage that a Stackage build with GHC 7.8 can now proceed. I've run a build with 7.8.0rc2, and have uploaded the build.log[1] and the complete cabal output for each package[2]. The good news is that most packages are building correctly, though there is still at least one package deep in the dependency tree which does not build (pcre-light). Here's a list of packages which failed to build, ignoring those which couldn't be built due to broken dependencies: * fpco-api (yes, I'm working on it) * gitlib * groundhog * monad-peel * parsestar * pcre-light * recursion-schemes * statistics * syb-extras * thyme * uniqueid [1] http://download.fpcomplete.com/ghc-7.8-builds/2014-04-09/build.log [2] http://download.fpcomplete.com/ghc-7.8-builds/2014-04-09/logs.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnw at newartisans.com Wed Apr 9 06:15:38 2014 From: johnw at newartisans.com (John Wiegley) Date: Wed, 09 Apr 2014 01:15:38 -0500 Subject: [Haskell-cafe] Stackage with GHC 7.8: build results In-Reply-To: (Michael Snoyman's message of "Wed, 9 Apr 2014 08:12:11 +0300") References: Message-ID: >>>>> Michael Snoyman writes: > * fpco-api (yes, I'm working on it) > * gitlib > * groundhog > * monad-peel > * parsestar > * pcre-light > * recursion-schemes > * statistics > * syb-extras > * thyme > * uniqueid My own private bootstrapping (unrelated to stackage) has also revealed these broken packages: pcre-light categories thyme recursion-schemes yesod-persistent John From michael at snoyman.com Wed Apr 9 07:16:17 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 9 Apr 2014 10:16:17 +0300 Subject: [Haskell-cafe] Stackage with GHC 7.8: build results In-Reply-To: References: Message-ID: On Wed, Apr 9, 2014 at 9:15 AM, John Wiegley wrote: > >>>>> Michael Snoyman writes: > > > * fpco-api (yes, I'm working on it) > > * gitlib > > * groundhog > > * monad-peel > > * parsestar > > * pcre-light > > * recursion-schemes > > * statistics > > * syb-extras > > * thyme > > * uniqueid > > My own private bootstrapping (unrelated to stackage) has also revealed > these > broken packages: > > pcre-light > categories > thyme > recursion-schemes > yesod-persistent > > What build failure are you getting with yesod-persistent? It builds correctly for me. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From vigalchin at gmail.com Wed Apr 9 08:15:47 2014 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Wed, 9 Apr 2014 03:15:47 -0500 Subject: [Haskell-cafe] Heart Bleed bug in OpenSSL Message-ID: http://heartbleed.com/ Ok .. I just scanned this .. but is this problem a "logic" bug in the OpenSSL C/C++ code or is a type correctness issue? Thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: From noonslists at gmail.com Wed Apr 9 08:36:07 2014 From: noonslists at gmail.com (Noon Silk) Date: Wed, 9 Apr 2014 18:36:07 +1000 Subject: [Haskell-cafe] Heart Bleed bug in OpenSSL In-Reply-To: References: Message-ID: it's a "why is anyone still using c!" issue. http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3 On Wed, Apr 9, 2014 at 6:15 PM, Vasili I. Galchin wrote: > http://heartbleed.com/ > > Ok .. I just scanned this .. but is this problem a "logic" bug in the > OpenSSL C/C++ code or is a type correctness issue? > > Thanks, > > Vasili > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Noon Silk -------------- next part -------------- An HTML attachment was scrubbed... URL: From 0slemi0 at gmail.com Wed Apr 9 08:38:12 2014 From: 0slemi0 at gmail.com (Andras Slemmer) Date: Wed, 9 Apr 2014 10:38:12 +0200 Subject: [Haskell-cafe] Heart Bleed bug in OpenSSL In-Reply-To: References: Message-ID: Heartbleed is caused by an unchecked memcpy. In particular the size of the memory chunk to be copied is retrieved from a client request and and is not checked On 9 April 2014 10:15, Vasili I. Galchin wrote: > http://heartbleed.com/ > > Ok .. I just scanned this .. but is this problem a "logic" bug in the > OpenSSL C/C++ code or is a type correctness issue? > > Thanks, > > Vasili > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew.Butterfield at scss.tcd.ie Wed Apr 9 08:56:16 2014 From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield) Date: Wed, 9 Apr 2014 09:56:16 +0100 Subject: [Haskell-cafe] Heart Bleed bug in OpenSSL In-Reply-To: References: Message-ID: No, it's a "why does anyone use open-source software for critical applications" issue. The safety critical industries use C and Ada by and large, but restrict the language to safe subsets, - in particular operations like memcpy, or dynamic memory allocation are ruled out (google MISRA-C or SParkAda). 'though I'm sure the nice folks at Galois might have some interesting insights here? Andrew Butterfield PS - interestinglly, the first down-to-code formal verification of a O/S kernel (google seL4) used Haskell as a prototype language and then derived a formal Isabelle/HOL specification from that - the code verified was hand-written in C ( a safe subset ). Andras Slemmer wrote: > Heartbleed is caused by an unchecked memcpy. In particular the size of the memory chunk to be copied is retrieved from a client request and and is not checked > after Noon Silk wrote: > it's a "why is anyone still using c!" issue. > > http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3 > > -------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero at TCD, Head of Foundations & Methods Research Group Director of Teaching and Learning - Undergraduate, School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From chriswarbo at googlemail.com Wed Apr 9 09:29:50 2014 From: chriswarbo at googlemail.com (Chris Warburton) Date: Wed, 09 Apr 2014 10:29:50 +0100 Subject: [Haskell-cafe] Heart Bleed bug in OpenSSL In-Reply-To: (Andrew Butterfield's message of "Wed, 9 Apr 2014 09:56:16 +0100") References: Message-ID: <861tx6am0h.fsf@gmail.com> Andrew Butterfield writes: > No, > it's a "why does anyone use open-source software for critical applications" issue. > > The safety critical industries use C and Ada by and large, but restrict the language to safe subsets, > - in particular operations like memcpy, or dynamic memory allocation are ruled out > (google MISRA-C or SParkAda). > > 'though I'm sure the nice folks at Galois might have some interesting insights here? > > Andrew Butterfield > > PS - interestinglly, the first down-to-code formal verification of a O/S kernel (google seL4) > used Haskell as a prototype language and then derived a formal Isabelle/HOL specification > from that - the code verified was hand-written in C ( a safe subset ). I don't see what any of those points have to do with open-source software. Does the proprietary nature of MISRA-C and seL4 somehow make them better at their job, or is it (as I suspect) irrelevant to their job? Likewise (implementations of) SPARK ADA, Haskell and Isabelle are open source; does this make them untrustworthy? Regards, Chris From ky3 at atamo.com Wed Apr 9 09:57:41 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 9 Apr 2014 16:57:41 +0700 Subject: [Haskell-cafe] Heart Bleed bug in OpenSSL In-Reply-To: <861tx6am0h.fsf@gmail.com> References: <861tx6am0h.fsf@gmail.com> Message-ID: On Wed, Apr 9, 2014 at 4:29 PM, Chris Warburton wrote: > Likewise (implementations of) SPARK ADA, Haskell and Isabelle are > open source; does this make them untrustworthy? > By open source, I think Andrew meant something like general-purpose or garden-variety or riff-raff or some such, as opposed to something exclusively the province of specialists. I may be mistaken, however. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From difrumin at gmail.com Wed Apr 9 10:26:10 2014 From: difrumin at gmail.com (Daniil Frumin) Date: Wed, 9 Apr 2014 14:26:10 +0400 Subject: [Haskell-cafe] Library for creating interactive diagrams? In-Reply-To: References: <53435128.1020102@gmail.com> Message-ID: Hi! interactive-diagrams developer here The documentation is indeed lacking, but the "interactive" part is located in the display-src library. The interactivity is achieved by compiling Diagrams code to Javascript via GHCJS (see eval-api library). Right now it is not possible to write something like the color-changing circle in your example, but you can have something like this: http://paste.hskll.org/get/1385 Cheers - Dan On Tue, Apr 8, 2014 at 5:46 AM, Kai Zhang wrote: > Pretty nice. I'll definite take a look into it. But currently the > documentation is poor. Thanks! > > > On Mon, Apr 7, 2014 at 6:30 PM, Andrey Chudnov wrote: >> >> Have you looked at interactive-diagrams [1]? >> >> [1] https://github.com/co-dan/interactive-diagrams >> >> >> On 04/07/2014 07:44 PM, Kai Zhang wrote: >> >> Hi cafe, >> >> Is there any active project about creating interactive diagrams, like D3js >> http://d3js.org/ ? The Diagrams library has already done a good job of >> making static images. Would it be possible to extend this library to support >> declaring interactive diagrams and then use JS and HTML as backend to draw >> them? >> >> Example: circle 1 $ with & hover .~ (change style) >> >> PS: I don't want a D3js binding. >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Sincerely yours, -- Daniil From KAction at gnu.org Wed Apr 9 17:20:07 2014 From: KAction at gnu.org (Dmitry Bogatov) Date: Wed, 9 Apr 2014 21:20:07 +0400 Subject: [Haskell-cafe] Automatically infer Newtype instance In-Reply-To: References: <20140408170533.GA2043@localhost.kaction.name> Message-ID: <20140409172007.GA2158@localhost.kaction.name> > > I think, that Newtype instances are transitive, and there is only one > > sane definiton is (pack . pack). But in example below I have to use > > UndecidableInstances and they seems to loop somewhere > > (Context reduction stack overflow; size = 132). > > > > To my understanding, Ghc tries to prove, that exists only one type b, > > and somewhy fail at it(It is unclear, why), but is it any way to say to > > it that I take responsibility, that ANY b would be nice? > you should checkout genealizednewtype deriving :) > https://ghc.haskell.org/trac/haskell-prime/wiki/NewtypeDeriving > > GHC has had it for quite some time > > also the Coerce Machinery in 7.8 GHC provides a stronger version of your > NewType style class No, it is not what I want. With it I would have to enumerate every type down. so for A_n newtype A0 = A0 Int ... newtype A_n = A_n A_{n-1} I would need list all n instances. In more general say, I want following: class Foo a b where foo :: a -> b --- Yes, UndecidableInstances. Yes, ambitious types. --- Take any b, yes unsafe, trust me, it will be okay. instance (Foo a b, Foo b c) => Foo a c where foo = foo . foo -- Best regards, Dmitry Bogatov , Free Software supporter, esperantisto and netiquette guardian. git://kaction.name/rc-files.git GPG: 54B7F00D From felipe.lessa at gmail.com Wed Apr 9 17:24:28 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Wed, 09 Apr 2014 14:24:28 -0300 Subject: [Haskell-cafe] ANNOUNCE: GHC version 7.8.1 In-Reply-To: References: Message-ID: <5345824C.2050203@gmail.com> Em 09-04-2014 11:23, Austin Seipp escreveu: > An updated SHA256SUMS.sig is attached. Thanks for Edsko de Vries for > pointing it out! If anybody is, like myself, trying to find a link for the SHA256SUMS file on the download page, here it is: https://www.haskell.org/ghc/dist/7.8.1/SHA256SUMS For some reason it seems that it's not linked anywhere on that page. Cheers, and thanks for the release! =) -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From michael at snoyman.com Wed Apr 9 17:28:00 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 9 Apr 2014 20:28:00 +0300 Subject: [Haskell-cafe] Looking for maintainer of pwstore-fast Message-ID: I just tried emailing Peter Scott, the maintainer of pwstore-fast[1], but the listed email address is no longer working. He also hasn't been responding to Github pings. Does anyone know how to get in touch with him? [1] http://hackage.haskell.org/package/pwstore-fast -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.lessa at gmail.com Wed Apr 9 17:32:20 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Wed, 09 Apr 2014 14:32:20 -0300 Subject: [Haskell-cafe] Looking for maintainer of pwstore-fast In-Reply-To: References: Message-ID: <53458424.2050500@gmail.com> Em 09-04-2014 14:28, Michael Snoyman escreveu: > I just tried emailing Peter Scott, the maintainer of pwstore-fast[1], > but the listed email address is no longer working. He also hasn't been > responding to Github pings. Does anyone know how to get in touch with him? He seems to be semi-active since there are public commits from last week: https://github.com/Cue/scales/commits?author=PeterScott Did you try the e-mail listed on his GitHub profile page [1], which is different from the one on Hackage? [1] peter at greplin.com -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From jays at panix.com Wed Apr 9 17:32:25 2014 From: jays at panix.com (Jay Sulzberger) Date: Wed, 9 Apr 2014 13:32:25 -0400 (EDT) Subject: [Haskell-cafe] Heart Bleed bug in OpenSSL In-Reply-To: References: Message-ID: On Wed, 9 Apr 2014, Vasili I. Galchin wrote: > http://heartbleed.com/ > > Ok .. I just scanned this .. but is this problem a "logic" bug in the > OpenSSL C/C++ code or is a type correctness issue? > > Thanks, > > Vasili It is a type error. Information sent in blocks over the Net should contain a sub-block containing the total length and also some internal checksum, which may or may not need to be cryptographically defended. The length sub-block likely would require some further information too. The famous Bitcoin malleability difficulty is an example of a block of information failing to have enough length fields/checksums. Like most, perhaps all, errors in type design, it is a logic bug at the design level, which might give a logic bug at the code level. oo--JS. From michael at snoyman.com Wed Apr 9 17:34:04 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 9 Apr 2014 20:34:04 +0300 Subject: [Haskell-cafe] Looking for maintainer of pwstore-fast In-Reply-To: <53458424.2050500@gmail.com> References: <53458424.2050500@gmail.com> Message-ID: On Wed, Apr 9, 2014 at 8:32 PM, Felipe Lessa wrote: > Em 09-04-2014 14:28, Michael Snoyman escreveu: > > I just tried emailing Peter Scott, the maintainer of pwstore-fast[1], > > but the listed email address is no longer working. He also hasn't been > > responding to Github pings. Does anyone know how to get in touch with > him? > > He seems to be semi-active since there are public commits from last week: > > https://github.com/Cue/scales/commits?author=PeterScott > > Did you try the e-mail listed on his GitHub profile page [1], which is > different from the one on Hackage? > > [1] peter at greplin.com > > I'll try that email, thanks. I should have thought of checking there first... Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.solla at gmail.com Wed Apr 9 18:05:10 2014 From: alex.solla at gmail.com (Alexander Solla) Date: Wed, 9 Apr 2014 11:05:10 -0700 Subject: [Haskell-cafe] Automatically infer Newtype instance In-Reply-To: <20140408170533.GA2043@localhost.kaction.name> References: <20140408170533.GA2043@localhost.kaction.name> Message-ID: Try using scoped type variables, and explicitly declare the types for pack and unpack at the call site: instance (Newtype a b, Newtype b c) => Newtype a c where pack = (pack :: b -> c) . (pack :: a -> b) Did I get those types right? They look free to me. On Tue, Apr 8, 2014 at 10:05 AM, Dmitry Bogatov wrote: > Hello! > I think, that Newtype instances are transitive, and there is only one > sane definiton is (pack . pack). But in example below I have to use > UndecidableInstances and they seems to loop somewhere > (Context reduction stack overflow; size = 132). > > To my understanding, Ghc tries to prove, that exists only one type b, > and somewhy fail at it(It is unclear, why), but is it any way to say to > it that I take responsibility, that ANY b would be nice? > > I know about TH, but interested in more elegant solution. > > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE FunctionalDependencies #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE UndecidableInstances #-} > > import Control.Newtype > > newtype A1 = A1 Int deriving (Eq, Show) > newtype A2 = A2 A1 deriving (Eq, Show) > > instance Newtype A1 Int where > pack = A1 > unpack (A1 a) = a > > instance Newtype A2 A1 where > pack = A2 > unpack (A2 a) = a > > -- Here comes UndecidableInstances > instance (Newtype a b, Newtype b c) => Newtype a c where > pack = pack . pack > unpack = unpack . unpack > > main = let foo :: A2 > foo = pack "46" in > print foo > > > -- > Best regards, Dmitry Bogatov , > Free Software supporter, esperantisto and netiquette guardian. > git://kaction.name/rc-files.git > GPG: 54B7F00D > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.solla at gmail.com Wed Apr 9 18:06:55 2014 From: alex.solla at gmail.com (Alexander Solla) Date: Wed, 9 Apr 2014 11:06:55 -0700 Subject: [Haskell-cafe] Automatically infer Newtype instance In-Reply-To: References: <20140408170533.GA2043@localhost.kaction.name> Message-ID: On Wed, Apr 9, 2014 at 11:05 AM, Alexander Solla wrote: > Try using scoped type variables, and explicitly declare the types for pack > and unpack at the call site: > > instance (Newtype a b, Newtype b c) => Newtype a c where > pack = (pack :: b -> c) > . (pack :: a -> b) > > Did I get those types right? They look free to me. > Actually, I'm not sure if that will work. How will GHC know which b to choose for the pair a and c, unless there are functional dependencies on a and c? -------------- next part -------------- An HTML attachment was scrubbed... URL: From KAction at gnu.org Wed Apr 9 19:21:42 2014 From: KAction at gnu.org (Dmitry Bogatov) Date: Wed, 9 Apr 2014 23:21:42 +0400 Subject: [Haskell-cafe] Automatically infer Newtype instance In-Reply-To: References: <20140408170533.GA2043@localhost.kaction.name> Message-ID: <20140409192142.GA11121@localhost.kaction.name> * Alexander Solla [2014-04-09 11:06:55-0700] > On Wed, Apr 9, 2014 at 11:05 AM, Alexander Solla wrote: > > > Try using scoped type variables, and explicitly declare the types for pack > > and unpack at the call site: > > > > instance (Newtype a b, Newtype b c) => Newtype a c where > > pack = (pack :: b -> c) > > . (pack :: a -> b) > > > > Did I get those types right? They look free to me. > > > > Actually, I'm not sure if that will work. How will GHC know which b to > choose for the pair a and c, unless there are functional dependencies on a > and c? In fact, in case of Newtype there is fundep: class Newtype n o | n -> o where ... so I should have c -> a. Unfortunatelly, somewhy it do not work. But also I am interested in even more unsafe case, when there is no fundep. -- Best regards, Dmitry Bogatov , Free Software supporter, esperantisto and netiquette guardian. git://kaction.name/rc-files.git GPG: 54B7F00D From vogt.adam at gmail.com Wed Apr 9 19:24:58 2014 From: vogt.adam at gmail.com (adam vogt) Date: Wed, 9 Apr 2014 15:24:58 -0400 Subject: [Haskell-cafe] Automatically infer Newtype instance In-Reply-To: References: <20140408170533.GA2043@localhost.kaction.name> Message-ID: On Wed, Apr 9, 2014 at 2:06 PM, Alexander Solla wrote: >> instance (Newtype a b, Newtype b c) => Newtype a c where >> pack = (pack :: b -> c) >> . (pack :: a -> b) >> >> Did I get those types right? They look free to me. > > > Actually, I'm not sure if that will work. How will GHC know which b to > choose for the pair a and c, unless there are functional dependencies on a > and c? Hi Alex, If there was no fundep on Newtype, that 'b' could also be inferred when the 'a' is actually Int, and we have an instance: instance (b ~ Key) => Newtype Int b You tend to need many type annotations when you have types that look like they are ambiguous but turn out to be unambiguous because of your particular instances: https://ghc.haskell.org/trac/ghc/ticket/8477 Regards, Adam From vigalchin at gmail.com Thu Apr 10 02:18:35 2014 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Wed, 9 Apr 2014 21:18:35 -0500 Subject: [Haskell-cafe] www.galois.com' response to Heartbleed .... . Message-ID: http://corp.galois.com/blog/2014/4/9/heartbleed-a-great-time-to-think-about-incident-response.html BTW I am always very careful when I use memcpy .. .hate that function ... read "buffer overrun" big time ..... -------------- next part -------------- An HTML attachment was scrubbed... URL: From vigalchin at gmail.com Thu Apr 10 02:20:01 2014 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Wed, 9 Apr 2014 21:20:01 -0500 Subject: [Haskell-cafe] www.galois.com' response to Heartbleed .... . In-Reply-To: References: Message-ID: BTW ... .I was quoting on the memcpy issue: Andras Slemmer wrote: > Heartbleed is caused by an unchecked memcpy. In particular the size of the memory chunk to be copied is retrieved from a client request and and is not checked > IMO the computer is backward .. On Wed, Apr 9, 2014 at 9:18 PM, Vasili I. Galchin wrote: > > http://corp.galois.com/blog/2014/4/9/heartbleed-a-great-time-to-think-about-incident-response.html > > BTW I am always very careful when I use memcpy .. .hate that function ... > read "buffer overrun" big time ..... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dstcruz at gmail.com Thu Apr 10 04:46:24 2014 From: dstcruz at gmail.com (Daniel Santa Cruz) Date: Thu, 10 Apr 2014 00:46:24 -0400 Subject: [Haskell-cafe] Haskell Weekly News: Issue 290 Message-ID: Welcome to issue 289 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from April 1 to 5, 2014 Quotes of the Week * edwardk: Zombies are expensive. Top Reddit Stories * foldl is broken! Domain: well-typed.com, Score: 148, Comments: 63 On Reddit: [1] http://goo.gl/LXmJTV Original: [2] http://goo.gl/viOG5O * A small Haskell extension Domain: augustss.blogspot.nl, Score: 76, Comments: 23 On Reddit: [3] http://goo.gl/buI46t Original: [4] http://goo.gl/LnAV9y * New GHC Features for 7.10.1 and Beyond Domain: haskell.org, Score: 74, Comments: 26 On Reddit: [5] http://goo.gl/DdXTfO Original: [6] http://goo.gl/g0FPBS * Libc considered harmful Domain: sylvain-henry.info, Score: 58, Comments: 28 On Reddit: [7] http://goo.gl/aq39Mf Original: [8] http://goo.gl/qdQDXm * Category Theory by Tom LaGatta Domain: youtube.com, Score: 58, Comments: 53 On Reddit: [9] http://goo.gl/oIzG1e Original: [10] http://goo.gl/DeLu5G * Idris 0.9.12 released with major laziness, codata, and documentation updates plus metavars in types Domain: idris-lang.org, Score: 55, Comments: 25 On Reddit: [11] http://goo.gl/4MtXJS Original: [12] http://goo.gl/3tXbqC * A cool paper I found on "Functional Programming and 3D Games". It discusses everything from collision detection to physics and texturing. [PDF] Domain: cse.unsw.edu.au, Score: 52, Comments: 3 On Reddit: [13] http://goo.gl/6PYB2e Original: [14] http://goo.gl/Tf6fa2 * Error reporting with locations Domain: augustss.blogspot.fr, Score: 47, Comments: 28 On Reddit: [15] http://goo.gl/ikaENm Original: [16] http://goo.gl/hntlJT * [ANN] Haste now has a website and a mailing list Domain: haste-lang.org, Score: 42, Comments: 7 On Reddit: [17] http://goo.gl/Ife2FA Original: [18] http://goo.gl/lRWmhv * Haskell in the Newsroom Domain: infoq.com, Score: 41, Comments: 5 On Reddit: [19] http://goo.gl/M4tehD Original: [20] http://goo.gl/bpvgLA * Haskell application architecture best practices Domain: self.haskell, Score: 32, Comments: 23 On Reddit: [21] http://goo.gl/XjHfNJ Original: [22] http://goo.gl/XjHfNJ Top StackOverflow Questions * Haskell - Is it possible to make pointfree functions more readable using different combinators than (.)? votes: 11, answers: 1 Read on SO: [23] http://goo.gl/5b036l * How to detect if a program has been compiled using -threaded? votes: 10, answers: 2 Read on SO: [24] http://goo.gl/Cr7pMA * What does the star mean in this haskell code? votes: 9, answers: 2 Read on SO: [25] http://goo.gl/qnolS7 * What about arrows? votes: 9, answers: 2 Read on SO: [26] http://goo.gl/b1wwp4 * Triggering a documentation update for a Hackage package votes: 8, answers: 1 Read on SO: [27] http://goo.gl/ErTVzf * Combining Data.Dynamic and type classes votes: 7, answers: 0 Read on SO: [28] http://goo.gl/n8qMo9 * Systematically applying a function to all fields of a haskell record votes: 6, answers: 3 Read on SO: [29] http://goo.gl/tNkLGu * Transforming a List of 2-Tuples in Haskell votes: 6, answers: 3 Read on SO: [30] http://goo.gl/dDe8QP * Error in ghci which I cannot reproduce in written haskell file votes: 6, answers: 1 Read on SO: [31] http://goo.gl/bg8DCw * Why can I call a monadic function without supplying a monad? votes: 6, answers: 1 Read on SO: [32] http://goo.gl/xZZ5iO * Deriving default instances using GHC.Generics votes: 6, answers: 1 Read on SO: [33] http://goo.gl/Autu6r Until next time, [34]+Daniel Santa Cruz References 1. http://www.well-typed.com/blog/90/ 2. http://www.reddit.com/r/haskell/comments/21wvk7/foldl_is_broken/ 3. http://augustss.blogspot.nl/2014/04/a-small-haskell-extension.html 4. http://www.reddit.com/r/haskell/comments/2239wh/a_small_haskell_extension/ 5. http://www.haskell.org/pipermail/haskell-cafe/2014-April/113373.html 6. http://www.reddit.com/r/haskell/comments/21wbme/new_ghc_features_for_7101_and_beyond/ 7. http://sylvain-henry.info/blog/posts/2014-04-01-libc-considered-harmful.html 8. http://www.reddit.com/r/haskell/comments/220ae4/libc_considered_harmful/ 9. https://www.youtube.com/watch?v=o6L6XeNdd_k 10. http://www.reddit.com/r/haskell/comments/229scs/category_theory_by_tom_lagatta/ 11. http://www.idris-lang.org/idris-0-9-12-released/ 12. http://www.reddit.com/r/haskell/comments/2284s5/idris_0912_released_with_major_laziness_codata/ 13. http://www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf 14. http://www.reddit.com/r/haskell/comments/21zush/a_cool_paper_i_found_on_functional_programming/ 15. http://augustss.blogspot.fr/2014/04/haskell-error-reporting-with-locations.html 16. http://www.reddit.com/r/haskell/comments/226otd/error_reporting_with_locations/ 17. http://haste-lang.org/ 18. http://www.reddit.com/r/haskell/comments/21x4wm/ann_haste_now_has_a_website_and_a_mailing_list/ 19. http://www.infoq.com/presentations/haskell-newsroom-nyt 20. http://www.reddit.com/r/haskell/comments/222i82/haskell_in_the_newsroom/ 21. http://www.reddit.com/r/haskell/comments/223i80/haskell_application_architecture_best_practices/ 22. http://www.reddit.com/r/haskell/comments/223i80/haskell_application_architecture_best_practices/ 23. http://stackoverflow.com/questions/22872098/haskell-is-it-possible-to-make-pointfree-functions-more-readable-using-differe 24. http://stackoverflow.com/questions/22839824/how-to-detect-if-a-program-has-been-compiled-using-threaded 25. http://stackoverflow.com/questions/22807728/what-does-the-star-mean-in-this-haskell-code 26. http://stackoverflow.com/questions/22871648/what-about-arrows 27. http://stackoverflow.com/questions/22783637/triggering-a-documentation-update-for-a-hackage-package 28. http://stackoverflow.com/questions/22876370/combining-data-dynamic-and-type-classes 29. http://stackoverflow.com/questions/22807619/systematically-applying-a-function-to-all-fields-of-a-haskell-record 30. http://stackoverflow.com/questions/22828259/transforming-a-list-of-2-tuples-in-haskell 31. http://stackoverflow.com/questions/22839784/error-in-ghci-which-i-cannot-reproduce-in-written-haskell-file 32. http://stackoverflow.com/questions/22841899/why-can-i-call-a-monadic-function-without-supplying-a-monad 33. http://stackoverflow.com/questions/22850983/deriving-default-instances-using-ghc-generics 34. https://plus.google.com/105107667630152149014/about -------------- next part -------------- An HTML attachment was scrubbed... URL: From ketil at malde.org Thu Apr 10 06:24:44 2014 From: ketil at malde.org (Ketil Malde) Date: Thu, 10 Apr 2014 08:24:44 +0200 Subject: [Haskell-cafe] [Haskell] ANNOUNCE: GHC version 7.8.1 In-Reply-To: References: Message-ID: <87d2gp4s7n.fsf@wespe.malde.org> Austin Seipp writes: > The (Interactive) Glasgow Haskell Compiler -- version 7.8.1 Congrats! > * Massive scalability improvements to the I/O manager Just a brief note from the front lines - I recompiled a heavily threaded program with (a recent pre-release) of 7.8.1 and got a 10% performance increase over 7.6.3. Nothing like free lunches - so thanks again for the great work! -k -- If I haven't seen further, it is by standing in the footprints of giants From kazu at iij.ad.jp Thu Apr 10 06:34:01 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 10 Apr 2014 15:34:01 +0900 (JST) Subject: [Haskell-cafe] [Haskell] ANNOUNCE: GHC version 7.8.1 In-Reply-To: <87d2gp4s7n.fsf@wespe.malde.org> References: <87d2gp4s7n.fsf@wespe.malde.org> Message-ID: <20140410.153401.127913868145496843.kazu@iij.ad.jp> >> * Massive scalability improvements to the I/O manager > > Just a brief note from the front lines - I recompiled a heavily threaded > program with (a recent pre-release) of 7.8.1 and got a 10% performance > increase over 7.6.3. Nothing like free lunches - so thanks again for > the great work! Did you run you program on a multicore system? If so, did you specify +RTS -N option? If your program uses MVar heavily, you need to re-design your program. For more information, please read: http://www.yesodweb.com/blog/2014/01/new-fast-logger --Kazu From alexander.vershilov at gmail.com Thu Apr 10 06:49:38 2014 From: alexander.vershilov at gmail.com (Alexander V Vershilov) Date: Thu, 10 Apr 2014 10:49:38 +0400 Subject: [Haskell-cafe] Stackage with GHC 7.8: build results In-Reply-To: References: Message-ID: Hi, In my testing container it's: Building yesod-persistent-1.2.2.2... Preprocessing library yesod-persistent-1.2.2.2... [1 of 2] Compiling Yesod.Persist.Core ( Yesod/Persist/Core.hs, dist/build/Yesod/Persist/Core.o ) Yesod/Persist/Core.hs:113:5: Could not deduce (Monad (YesodDB site)) arising from a use of `transPipe' from the context (YesodPersistRunner site) bound by the type signature for runDBSource :: YesodPersistRunner site => Source (YesodDB site) a -> Source (HandlerT site IO) a at Yesod/Persist/Core.hs:(108,16)-(110,42) In a stmt of a 'do' block: transPipe (runDBRunner dbrunner) src In the expression: do { (dbrunner, cleanup) <- lift getDBRunner; transPipe (runDBRunner dbrunner) src; lift cleanup } In an equation for `runDBSource': runDBSource src No uhc found ./setup build Building yesod-persistent-1.2.2.2... Preprocessing library yesod-persistent-1.2.2.2... [1 of 2] Compiling Yesod.Persist.Core ( Yesod/Persist/Core.hs, dist/build/Yesod/Persist/Core.o ) Yesod/Persist/Core.hs:113:5: Could not deduce (Monad (YesodDB site)) arising from a use of `transPipe' from the context (YesodPersistRunner site) bound by the type signature for runDBSource :: YesodPersistRunner site => Source (YesodDB site) a -> Source (HandlerT site IO) a at Yesod/Persist/Core.hs:(108,16)-(110,42) In a stmt of a 'do' block: transPipe (runDBRunner dbrunner) src In the expression: do { (dbrunner, cleanup) <- lift getDBRunner; transPipe (runDBRunner dbrunner) src; lift cleanup } In an equation for `runDBSource': runDBSource src = do { (dbrunner, cleanup) <- lift getDBRunner; transPipe (runDBRunner dbrunner) src; lift cleanup } -- Alexander Vershilov On 9 April 2014 11:16, Michael Snoyman wrote: > > > > On Wed, Apr 9, 2014 at 9:15 AM, John Wiegley wrote: >> >> >>>>> Michael Snoyman writes: >> >> > * fpco-api (yes, I'm working on it) >> > * gitlib >> > * groundhog >> > * monad-peel >> > * parsestar >> > * pcre-light >> > * recursion-schemes >> > * statistics >> > * syb-extras >> > * thyme >> > * uniqueid >> >> My own private bootstrapping (unrelated to stackage) has also revealed >> these >> broken packages: >> >> pcre-light >> categories >> thyme >> recursion-schemes >> yesod-persistent >> > > What build failure are you getting with yesod-persistent? It builds > correctly for me. > > Michael > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Alexander From michael at snoyman.com Thu Apr 10 06:51:48 2014 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 10 Apr 2014 09:51:48 +0300 Subject: [Haskell-cafe] Stackage with GHC 7.8: build results In-Reply-To: References: Message-ID: On Thu, Apr 10, 2014 at 9:49 AM, Alexander V Vershilov < alexander.vershilov at gmail.com> wrote: > Hi, > > In my testing container it's: > > Building yesod-persistent-1.2.2.2... > Preprocessing library yesod-persistent-1.2.2.2... > [1 of 2] Compiling Yesod.Persist.Core ( Yesod/Persist/Core.hs, > dist/build/Yesod/Persist/Core.o ) > > Yesod/Persist/Core.hs:113:5: > Could not deduce (Monad (YesodDB site)) > arising from a use of `transPipe' > from the context (YesodPersistRunner site) > bound by the type signature for > runDBSource :: YesodPersistRunner site => > Source (YesodDB site) a -> Source > (HandlerT site IO) a > at Yesod/Persist/Core.hs:(108,16)-(110,42) > In a stmt of a 'do' block: transPipe (runDBRunner dbrunner) src > In the expression: > do { (dbrunner, cleanup) <- lift getDBRunner; > transPipe (runDBRunner dbrunner) src; > lift cleanup } > In an equation for `runDBSource': > runDBSource src > No uhc found > ./setup build > Building yesod-persistent-1.2.2.2... > Preprocessing library yesod-persistent-1.2.2.2... > [1 of 2] Compiling Yesod.Persist.Core ( Yesod/Persist/Core.hs, > dist/build/Yesod/Persist/Core.o ) > > Yesod/Persist/Core.hs:113:5: > Could not deduce (Monad (YesodDB site)) > arising from a use of `transPipe' > from the context (YesodPersistRunner site) > bound by the type signature for > runDBSource :: YesodPersistRunner site => > Source (YesodDB site) a -> Source > (HandlerT site IO) a > at Yesod/Persist/Core.hs:(108,16)-(110,42) > In a stmt of a 'do' block: transPipe (runDBRunner dbrunner) src > In the expression: > do { (dbrunner, cleanup) <- lift getDBRunner; > transPipe (runDBRunner dbrunner) src; > lift cleanup } > In an equation for `runDBSource': > runDBSource src > = do { (dbrunner, cleanup) <- lift getDBRunner; > transPipe (runDBRunner dbrunner) src; > lift cleanup } > > -- > Alexander Vershilov > > On 9 April 2014 11:16, Michael Snoyman wrote: > > > > > > > > On Wed, Apr 9, 2014 at 9:15 AM, John Wiegley > wrote: > >> > >> >>>>> Michael Snoyman writes: > >> > >> > * fpco-api (yes, I'm working on it) > >> > * gitlib > >> > * groundhog > >> > * monad-peel > >> > * parsestar > >> > * pcre-light > >> > * recursion-schemes > >> > * statistics > >> > * syb-extras > >> > * thyme > >> > * uniqueid > >> > >> My own private bootstrapping (unrelated to stackage) has also revealed > >> these > >> broken packages: > >> > >> pcre-light > >> categories > >> thyme > >> recursion-schemes > >> yesod-persistent > >> > > > > What build failure are you getting with yesod-persistent? It builds > > correctly for me. > > > > Michael > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > -- > Alexander > The problem is a regression between GHC 7.8.0rc2 (what I was testing with) and 7.8.1, which had just been released. There's a GHC ticket open on the issue[1]. Michael [1] https://ghc.haskell.org/trac/ghc/ticket/8978 -------------- next part -------------- An HTML attachment was scrubbed... URL: From atze at uu.nl Thu Apr 10 09:14:13 2014 From: atze at uu.nl (Atze Dijkstra) Date: Thu, 10 Apr 2014 11:14:13 +0200 Subject: [Haskell-cafe] ANNOUNCE (2nd call): Applied Functional Programming (AFP) Summerschool 7-18 July 2014, Utrecht, Netherlands Message-ID: Dear all, we bring the following announcement to your attention a 2nd time as the registration deadline (may 5) approaches. thank you, regards, Atze Dijkstra =========== AFP Summerschool 2014 =========== Applied Functional Programming (AFP) Summerschool July 7-18, 2014 Utrecht University, Department of Information and Computing Sciences Utrecht, The Netherlands Summerschool & registration website: http://www.utrechtsummerschool.nl/courses/science/applied-functional-programming-in-haskell AFP website with edition 2013 info : http://www.cs.uu.nl/wiki/USCS contact : Uscs-afp at lists.science.uu.nl *** The 2014 edition of the Applied Functional Programming (AFP) Summerschool in Utrecht, Netherlands will be held from 7-18 July 2014. The summerschool teaches Haskell on both beginners and advanced levels via lectures and lab exercises. More info can be found via the references above, included here is an excerpt from the summerschool website: ``Typed functional programming in Haskell allows for the development of compact programs in minimal time and with maximal guarantees about robustness and correctness. The course introduces Haskell as well as its theoretical underpinnings such as typed lambda calculus, and Damas-Milner type inference. There is ample opportunity to put this all in practice during lab sessions. Typed functional programming languages allow for the development of robust, concise programs in a short amount of time. The key advantages are higher-order functions as an abstraction mechanism, and an advanced type system for safety and reusability. This course introduces Haskell, a state-of-the-art functional programming language, together with some of its theoretical background, such as typed lambda calculi, referential transparency, Damas-Milner type inference, type level programming, and functional design patterns. We will combine this with applications of functional programming, concentrating on topics such as language processing, building graphical user interfaces, networking, databases, and programming for the web. The goal of the course is not just to teach the programming language and underlying theory, but also to learn about the Haskell community and to get hands-on experience by doing lab exercises or a Haskell project of your own.'' *** regards, - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 .... | Email: atze at uu.nl ............... / |___\ From capn.freako at gmail.com Thu Apr 10 13:20:36 2014 From: capn.freako at gmail.com (David Banas) Date: Thu, 10 Apr 2014 06:20:36 -0700 Subject: [Haskell-cafe] ANN.: TreeViz v0.0.6 release. Message-ID: <89871B88-E266-4D0D-AD9A-B2938F094449@gmail.com> I?ve just posted version `v0.0.6? of the TreeViz package to both Hackage and GitHub. This release fixes the ?mixed decimation style failure? bug, in which a DIF stage followed by a DIT stage, followed by anything was giving incorrect numerical results for the FFT. Cheers, -db From alpmestan at gmail.com Thu Apr 10 14:15:51 2014 From: alpmestan at gmail.com (Alp Mestanogullari) Date: Thu, 10 Apr 2014 16:15:51 +0200 Subject: [Haskell-cafe] Directed rounding in haskell ? In-Reply-To: <20140407141231.GA3594@fuckup> References: <20140407141231.GA3594@fuckup> Message-ID: Maybe these packages could be relevant/useful: - https://github.com/ekmett/rounded - https://github.com/ekmett/intervals On Mon, Apr 7, 2014 at 4:12 PM, Dominik Peteler wrote: > Hello list, > > I'm going to implement an interval arithmetic library (following the IEEE > P1788) in Haskell and for > that I need support for directed rounding to the nearest floating point > number. I had a quick look at the Decimal package which comes with the > `roundTo` function for rounding to a specified number of decimal places > but it doesn't provide directed rounding. > Is there way to get directed rounding to to the nearest float (maybe > even with machine floats) ? > > I'm also aware of the AERN-* packages but they seem to be unmaintained. At > least there is no version which builds with the current GHC. Does > anybody know something about that ? > > Regards > > dominik > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Alp Mestanogullari -------------- next part -------------- An HTML attachment was scrubbed... URL: From capn.freako at gmail.com Thu Apr 10 14:21:00 2014 From: capn.freako at gmail.com (David Banas) Date: Thu, 10 Apr 2014 07:21:00 -0700 Subject: [Haskell-cafe] ANN.: TreeViz v0.0.6 release. Message-ID: <05DB00E4-A0AF-4338-A593-2DBC8117A7B4@gmail.com> I?ve just posted version `v0.0.6? of the TreeViz package to both Hackage and GitHub. This release fixes the ?mixed decimation style failure? bug, in which a DIF stage followed by a DIT stage, followed by anything was giving incorrect numerical results for the FFT. Cheers, -db From christiaan.baaij at gmail.com Thu Apr 10 16:22:02 2014 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Thu, 10 Apr 2014 18:22:02 +0200 Subject: [Haskell-cafe] Haddock markup questions Message-ID: Hello list, I have two questions regarding proper markup for my haddock documentation. I'm using the latest released haddock, version 2.14.2. The first is about deprecation pragma's and operators usint '<' and '>' I have the following deprecation message: > {-# DEPRECATED Comp "Use 'Applicative' interface and ('<^>') instead" #-} Haddock however generates the following: http://christiaanb.github.io/clash-prelude/CLaSH-Prelude.html#t:Comp Where 'Applicative' gets a proper link to the applicative type class... but '<^>' is translated to a link to '^'... which is a page that doesn't exists. I can get haddock to not generate a link using: > > {-# DEPRECATED Comp "Use 'Applicative' interface and ('\\<^\\>') instead" #-} But that's unwanted, as those backslashes show up in GHC(i) messages. So: how do I get haddock to not parse my '<^>' operator as a link/URL? My second question is again about getting links to operators in general. If you take a look at, e.g., http://hackage.haskell.org/package/base-4.7.0.0/docs/Control-Applicative.html You can see that proper documentation links are generated to the '<*>' and such operators. However, if you take a look at the documention I tried to generate for my library: http://christiaanb.github.io/clash-prelude/CLaSH-Signal-Implicit.html#v:-60--94- You can see that the referenced '^>' operator does not get a proper link. So my question: how do I get haddock to create proper links for my referenced operators. I should note that I create haddock docs using 'cabal haddock' instead of calling haddock directly. Best regards, Christiaan -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Thu Apr 10 16:27:39 2014 From: trebla at vex.net (Albert Y. C. Lai) Date: Thu, 10 Apr 2014 12:27:39 -0400 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: Message-ID: <5346C67B.7050007@vex.net> On 14-04-08 11:11 PM, Alexander Solla wrote: > mathJaxField :: Monad m > > => RenderMessage (HandlerSite m) FormMessage > > => Field m MathJax > > > Notice that there are two type arrows (=>). Interestingly, > > > mathJaxField :: (Monad m > > > , RenderMessage (HandlerSite m) FormMessage > > > ) => Field m MathJax > > > > compiles too. So it looks like currying/uncurrying, at the type level. But when did this start? I'm using GHC 7.6.3 Yes, GHC accepts "X => Y => Z" and makes it "(X, Y) => Z". In fact, go wilder: whee :: Show a => Eq a => a => Bool whee x = x == x && null (show x) It is valid and it means (Show a, Eq a) => a -> Bool. Try it! My understanding is that when the type checker has to support all those generalizations like ConstraintKind, DataKinds, etc etc, it becomes so general that some traditional distinctions vanish. From fuuzetsu at fuuzetsu.co.uk Thu Apr 10 16:40:18 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Thu, 10 Apr 2014 17:40:18 +0100 Subject: [Haskell-cafe] Haddock markup questions In-Reply-To: References: Message-ID: <5346C972.2000806@fuuzetsu.co.uk> On 10/04/14 17:22, Christiaan Baaij wrote: > Hello list, > > I have two questions regarding proper markup for my haddock documentation. > I'm using the latest released haddock, version 2.14.2. > > The first is about deprecation pragma's and operators usint '<' and '>' > I have the following deprecation message: > >> {-# DEPRECATED Comp "Use 'Applicative' interface and ('<^>') instead" #-} > > Haddock however generates the following: > http://christiaanb.github.io/clash-prelude/CLaSH-Prelude.html#t:Comp > > Where 'Applicative' gets a proper link to the applicative type class... but > '<^>' is translated to a link to '^'... which is a page that doesn't exists. > > I can get haddock to not generate a link using: > >>> {-# DEPRECATED Comp "Use 'Applicative' interface and ('\\<^\\>') > instead" #-} > > But that's unwanted, as those backslashes show up in GHC(i) messages. > So: how do I get haddock to not parse my '<^>' operator as a link/URL? Hm, strange, technically we parse identifiers first and links second so this should work without a problem unless Haddock doesn't recognise it as an identifier. I actually now notice in the parser that we don't consider ^ to be a valid symbol so that's probably the culprit! Good catch, if that's actually the case here then you can expect it to be fixed in the next release, perhaps with 7.8.3 or something. Unfortunately the way we do identifier parsing now is that we slurp everything that looks like a valid identifier and afterwards we ask GHC to actually tell us if it's it's something we know about. It seems like a bug caused by me not being careful when reading the relevant part of the report, deepest apologies! I do wish we had a better way of parsing these identifiers but I can't think of one. > > My second question is again about getting links to operators in general. > If you take a look at, e.g., > http://hackage.haskell.org/package/base-4.7.0.0/docs/Control-Applicative.html > You can see that proper documentation links are generated to the '<*>' and > such operators. > However, if you take a look at the documention I tried to generate for my > library: > http://christiaanb.github.io/clash-prelude/CLaSH-Signal-Implicit.html#v:-60--94- > You can see that the referenced '^>' operator does not get a proper link. > So my question: how do I get haddock to create proper links for my > referenced operators. Sounds like it's the same issue. > I should note that I create haddock docs using 'cabal haddock' instead of > calling haddock directly. > > Best regards, > > Christiaan > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Mateusz K. From christiaan.baaij at gmail.com Thu Apr 10 16:52:08 2014 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Thu, 10 Apr 2014 18:52:08 +0200 Subject: [Haskell-cafe] Haddock markup questions In-Reply-To: <5346C972.2000806@fuuzetsu.co.uk> References: <5346C972.2000806@fuuzetsu.co.uk> Message-ID: > > > > But that's unwanted, as those backslashes show up in GHC(i) messages. > > So: how do I get haddock to not parse my '<^>' operator as a link/URL? > > Hm, strange, technically we parse identifiers first and links second so > this should work without a problem unless Haddock doesn't recognise it > as an identifier. > > I actually now notice in the parser that we don't consider ^ to be a > valid symbol so that's probably the culprit! Good catch, if that's > actually the case here then you can expect it to be fixed in the next > release, perhaps with 7.8.3 or something. Unfortunately the way we do > identifier parsing now is that we slurp everything that looks like a > valid identifier and afterwards we ask GHC to actually tell us if it's > it's something we know about. It seems like a bug caused by me not being > careful when reading the relevant part of the report, deepest apologies! > I do wish we had a better way of parsing these identifiers but I can't > think of one. > It never came to mind that '^' was the actual culprit :-) Now that I know that it's a (potential) bug, I'll just keep my eye on ghc-commit and wait for the bugfix. I'm used to running ghc-HEAD anyway. Also, is it not possible to update my haddock seperate from GHC? -- Christiaan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dagitj at gmail.com Thu Apr 10 17:12:14 2014 From: dagitj at gmail.com (Jason Dagit) Date: Thu, 10 Apr 2014 10:12:14 -0700 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: <5346C67B.7050007@vex.net> References: <5346C67B.7050007@vex.net> Message-ID: On Thu, Apr 10, 2014 at 9:27 AM, Albert Y. C. Lai wrote: > > Yes, GHC accepts "X => Y => Z" and makes it "(X, Y) => Z". In fact, go > wilder: > > whee :: Show a => Eq a => a => Bool > whee x = x == x && null (show x) > > It is valid and it means (Show a, Eq a) => a -> Bool. Try it! > What extensions do you have turned on? I'm trying this is ghci (7.6.3) and I can't get it to work even with DataKinds and ConstraintKinds. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Thu Apr 10 17:21:36 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Fri, 11 Apr 2014 00:21:36 +0700 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: <5346C67B.7050007@vex.net> Message-ID: No problems here: # ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> let whee :: Show a => Eq a => a => Bool; whee x = x == x && null (show x) Prelude> :t whee whee :: (Eq a, Show a) => a -> Bool -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From dagitj at gmail.com Thu Apr 10 17:28:21 2014 From: dagitj at gmail.com (Jason Dagit) Date: Thu, 10 Apr 2014 10:28:21 -0700 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: <5346C67B.7050007@vex.net> Message-ID: On Thu, Apr 10, 2014 at 10:21 AM, Kim-Ee Yeoh wrote: > No problems here: > > # ghci > GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> let whee :: Show a => Eq a => a => Bool; whee x = x == x && null > (show x) > Prelude> :t whee > whee :: (Eq a, Show a) => a -> Bool > It seems to be an issue with giving everything on a single line: $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude ?> let whee x = x == x && null (show x) :: Show a => Eq a => a => Bool :2:14: Couldn't match expected type `a -> Bool' with actual type `Bool' In the expression: x == x && null (show x) :: Show a => Eq a => a => Bool In an equation for `whee': whee x = x == x && null (show x) :: Show a => Eq a => a => Bool I see now to make it work as a one liner I could do it this way: Prelude ?> :t (\x -> x == x && null (show x)) :: Show a => Eq a => a => Bool (\x -> x == x && null (show x)) :: Show a => Eq a => a => Bool :: (Eq a, Show a) => a -> Bool Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.lessa at gmail.com Thu Apr 10 17:43:00 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu, 10 Apr 2014 14:43:00 -0300 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: <5346C67B.7050007@vex.net> References: <5346C67B.7050007@vex.net> Message-ID: <5346D824.8070704@gmail.com> Em 10-04-2014 13:27, Albert Y. C. Lai escreveu: > Yes, GHC accepts "X => Y => Z" and makes it "(X, Y) => Z". In fact, go > wilder: > > whee :: Show a => Eq a => a => Bool > whee x = x == x && null (show x) > > It is valid and it means (Show a, Eq a) => a -> Bool. Try it! > > My understanding is that when the type checker has to support all those > generalizations like ConstraintKind, DataKinds, etc etc, it becomes so > general that some traditional distinctions vanish. What? Shouldn't that be a bug? $ ghci -XHaskell98 GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> let f :: a => a; f = id :2:15: Predicate `a' used as a type In the type signature for `f': f :: a => a Prelude> let f :: Eq a => a => a; f = id Not even with Haskell98 turned on! -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From allbery.b at gmail.com Thu Apr 10 17:45:32 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 10 Apr 2014 13:45:32 -0400 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: <5346D824.8070704@gmail.com> References: <5346C67B.7050007@vex.net> <5346D824.8070704@gmail.com> Message-ID: On Thu, Apr 10, 2014 at 1:43 PM, Felipe Lessa wrote: > Em 10-04-2014 13:27, Albert Y. C. Lai escreveu: > > My understanding is that when the type checker has to support all those > > generalizations like ConstraintKind, DataKinds, etc etc, it becomes so > > general that some traditional distinctions vanish. > > What? Shouldn't that be a bug? > It "should be" but I suspect actually treating it as one is rather difficult now that it's possible for `a` there to be a Constraint or etc., in which case it is on the correct side of the =>. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Thu Apr 10 17:45:48 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Fri, 11 Apr 2014 00:45:48 +0700 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: <5346C67B.7050007@vex.net> Message-ID: On Fri, Apr 11, 2014 at 12:28 AM, Jason Dagit wrote: > It seems to be an issue with giving everything on a single line: > > Prelude ?> let whee x = x == x && null (show x) :: Show a => Eq a => a => > Bool > > :2:14: > Couldn't match expected type `a -> Bool' with actual type `Bool' > In the expression: > x == x && null (show x) :: Show a => Eq a => a => Bool > In an equation for `whee': > whee x = x == x && null (show x) :: Show a => Eq a => a => Bool > As the error message indicates, the (:: type) is being applied to the open term: x == x && null (show x), and not to the function whee. To do this single-line def properly, I think you need -XScopedTypeVariables: let whee (x :: a) = x == x && null (show x) :: Show a => Eq a => Bool > I see now to make it work as a one liner I could do it this way: > Prelude ?> :t (\x -> x == x && null (show x)) :: Show a => Eq a => a => > Bool > (\x -> x == x && null (show x)) :: Show a => Eq a => a => Bool > :: (Eq a, Show a) => a -> Bool > And to recover the named binding: let whee = (\x -> x == x && null (show x)) :: Show a => Eq a => a => Bool -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.lessa at gmail.com Thu Apr 10 17:59:45 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu, 10 Apr 2014 14:59:45 -0300 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: <5346C67B.7050007@vex.net> <5346D824.8070704@gmail.com> Message-ID: <5346DC11.4080503@gmail.com> Em 10-04-2014 14:45, Brandon Allbery escreveu: > It "should be" but I suspect actually treating it as one is rather > difficult now that it's possible for `a` there to be a Constraint or > etc., in which case it is on the correct side of the =>. What you're saying is that it would be difficult to ban this on the parser level. However, somewhere inside GHC this `a` that was used as a constraint got promoted to being an argument. This is where it should have been stopped on its track. Or am I missing something? =) -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From allbery.b at gmail.com Thu Apr 10 18:03:58 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 10 Apr 2014 14:03:58 -0400 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: <5346DC11.4080503@gmail.com> References: <5346C67B.7050007@vex.net> <5346D824.8070704@gmail.com> <5346DC11.4080503@gmail.com> Message-ID: On Thu, Apr 10, 2014 at 1:59 PM, Felipe Lessa wrote: > Em 10-04-2014 14:45, Brandon Allbery escreveu: > > It "should be" but I suspect actually treating it as one is rather > > difficult now that it's possible for `a` there to be a Constraint or > > etc., in which case it is on the correct side of the =>. > > What you're saying is that it would be difficult to ban this on the > parser level. However, somewhere inside GHC this `a` that was used as a > constraint got promoted to being an argument. This is where it should > have been stopped on its track. > Actually, what I'm saying is that it might be difficult to reliably catch it at that point; consider that the parse leading to that interpretation may not exist within ghc at that point, only an AST that may have been rearranged by uses of ConstraintKinds so as to lose its direct relationship to the parse that initially led to it. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From dagitj at gmail.com Thu Apr 10 18:05:14 2014 From: dagitj at gmail.com (Jason Dagit) Date: Thu, 10 Apr 2014 11:05:14 -0700 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: <5346C67B.7050007@vex.net> Message-ID: On Thu, Apr 10, 2014 at 10:45 AM, Kim-Ee Yeoh wrote: > > And to recover the named binding: > > let whee = (\x -> x == x && null (show x)) :: Show a => Eq a => a => > Bool > Right, or even: Prelude ?> :t let whee x = x == x && null (show x) in whee :: Show a => Eq a => a => Bool let whee x = x == x && null (show x) in whee :: Show a => Eq a => a => Bool :: (Eq a, Show a) => a -> Bool Which is what I think I meant to type initially but then confused myself and also misread the type error :) Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Apr 10 18:07:42 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 10 Apr 2014 14:07:42 -0400 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: <5346C67B.7050007@vex.net> <5346D824.8070704@gmail.com> <5346DC11.4080503@gmail.com> Message-ID: On Thu, Apr 10, 2014 at 2:03 PM, Brandon Allbery wrote: > Actually, what I'm saying is that it might be difficult to reliably catch > it at that point; consider that the parse leading to that interpretation > may not exist within ghc at that point, only an AST that may have been > rearranged by uses of ConstraintKinds so as to lose its direct relationship > to the parse that initially led to it. > Or worse, this is happening inside the typechecker and the tree it's manipulating has *no* relationship to the original parse or its AST, such that it has no idea whether it was on the wrong side of an =>. Depends on the internal representations used by the typechecker, and most likely doing it right means carrying around a lot more information than it currently does. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Thu Apr 10 18:13:54 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Thu, 10 Apr 2014 19:13:54 +0100 Subject: [Haskell-cafe] Haddock markup questions In-Reply-To: References: <5346C972.2000806@fuuzetsu.co.uk> Message-ID: <5346DF62.4030605@fuuzetsu.co.uk> On 10/04/14 17:52, Christiaan Baaij wrote: >> >> >>> But that's unwanted, as those backslashes show up in GHC(i) messages. >>> So: how do I get haddock to not parse my '<^>' operator as a link/URL? >> >> Hm, strange, technically we parse identifiers first and links second so >> this should work without a problem unless Haddock doesn't recognise it >> as an identifier. >> >> I actually now notice in the parser that we don't consider ^ to be a >> valid symbol so that's probably the culprit! Good catch, if that's >> actually the case here then you can expect it to be fixed in the next >> release, perhaps with 7.8.3 or something. Unfortunately the way we do >> identifier parsing now is that we slurp everything that looks like a >> valid identifier and afterwards we ask GHC to actually tell us if it's >> it's something we know about. It seems like a bug caused by me not being >> careful when reading the relevant part of the report, deepest apologies! >> I do wish we had a better way of parsing these identifiers but I can't >> think of one. >> > > It never came to mind that '^' was the actual culprit :-) > Now that I know that it's a (potential) bug, I'll just keep my eye on > ghc-commit and wait for the bugfix. > I'm used to running ghc-HEAD anyway. Ah. I'll probably push out a fix tomorrow then and you can grab that. > Also, is it not possible to update my haddock seperate from GHC? You should be able to simply cabal install haddock as long as you are using the GHC version it expects. For Haddock HEAD (to-be 2.15.0), you need GHC 7.9: you can just go to utils/haddock in the GHC tree and run cabal install there (or clone outside of the tree or whatever). For the 2.14.x releases, we require 7.8.x. > -- Christiaan > -- Mateusz K. From andres at well-typed.com Thu Apr 10 18:35:46 2014 From: andres at well-typed.com (=?ISO-8859-1?Q?Andres_L=F6h?=) Date: Thu, 10 Apr 2014 20:35:46 +0200 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: <5346C67B.7050007@vex.net> <5346D824.8070704@gmail.com> <5346DC11.4080503@gmail.com> Message-ID: I also find this scary. Even this works: Prelude> let whee :: (Show a, Eq a, a) => Bool; whee x = x == x && null (show x) Prelude> :t whee whee :: (Eq a, Show a) => a -> Bool But: Prelude> let test :: (Eq a) => a => b => a; test = undefined :35:13: Illegal polymorphic or qualified type: (b) => a Perhaps you intended to use -XRankNTypes or -XRank2Types In the type signature for `test': test :: Eq a => a => b => a Prelude> :set -XRankNTypes Prelude> let test :: (Eq a) => a => b => a; test = undefined :8:13: Illegal constraint: b (Use -XConstraintKinds to permit this) In the type signature for `test': test :: Eq a => a => b => a So this is what I'd also expect for "a" to happen. I think this is a bug. Cheers, Andres -- Andres L?h, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England From andres at well-typed.com Thu Apr 10 18:37:49 2014 From: andres at well-typed.com (=?ISO-8859-1?Q?Andres_L=F6h?=) Date: Thu, 10 Apr 2014 20:37:49 +0200 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: <5346C67B.7050007@vex.net> <5346D824.8070704@gmail.com> <5346DC11.4080503@gmail.com> Message-ID: And even more: Prelude> let test :: (Eq a, a, Eq b, b) => a; test = const Prelude> :t test test :: (Eq a, Eq b) => a -> b -> a Prelude> let test :: (Eq a, Eq b, a, b) => a; test = const Prelude> :t test test :: (Eq a, Eq b) => a -> b -> a Prelude> let test :: (a, b, Eq a, Eq b) => a; test = const :19:35: Predicate `a' used as a type In the type signature for `test': test :: (a, b, Eq a, Eq b) => a Cheers, Andres -- Andres L?h, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England From andres at well-typed.com Thu Apr 10 18:40:03 2014 From: andres at well-typed.com (=?ISO-8859-1?Q?Andres_L=F6h?=) Date: Thu, 10 Apr 2014 20:40:03 +0200 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: <5346C67B.7050007@vex.net> <5346D824.8070704@gmail.com> <5346DC11.4080503@gmail.com> Message-ID: Sorry for continuing to reply to myself. But all this seems fixed in 7.8.1: Prelude> let whee :: (Show a, Eq a, a) => Bool; whee x = x == x && null (show x) :5:28: Expected a constraint, but 'a' has kind '*' In the type signature for 'whee': whee :: (Show a, Eq a, a) => Bool Prelude> let whee :: (Show a, Eq a) => a => Bool; whee x = x == x && null (show x) :6:31: Expected a constraint, but 'a' has kind '*' In the type signature for 'whee': whee :: (Show a, Eq a) => a => Bool Cheers, Andres On Thu, Apr 10, 2014 at 8:37 PM, Andres L?h wrote: > And even more: > > Prelude> let test :: (Eq a, a, Eq b, b) => a; test = const > Prelude> :t test > test :: (Eq a, Eq b) => a -> b -> a > Prelude> let test :: (Eq a, Eq b, a, b) => a; test = const > Prelude> :t test > test :: (Eq a, Eq b) => a -> b -> a > Prelude> let test :: (a, b, Eq a, Eq b) => a; test = const > > :19:35: > Predicate `a' used as a type > In the type signature for `test': test :: (a, b, Eq a, Eq b) => a > > Cheers, > Andres > > -- > Andres L?h, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com > > Registered in England & Wales, OC335890 > 250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England -- Andres L?h, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England From alex.solla at gmail.com Thu Apr 10 18:44:25 2014 From: alex.solla at gmail.com (Alexander Solla) Date: Thu, 10 Apr 2014 11:44:25 -0700 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: <5346C67B.7050007@vex.net> <5346D824.8070704@gmail.com> <5346DC11.4080503@gmail.com> Message-ID: On Thu, Apr 10, 2014 at 11:40 AM, Andres L?h wrote: > Sorry for continuing to reply to myself. But all this seems fixed in 7.8.1: > > Prelude> let whee :: (Show a, Eq a, a) => Bool; whee x = x == x && null > (show x) > > :5:28: > Expected a constraint, but 'a' has kind '*' > In the type signature for 'whee': whee :: (Show a, Eq a, a) => Bool > Prelude> let whee :: (Show a, Eq a) => a => Bool; whee x = x == x && > null (show x) > I don't have a GHC 7.8 handy. Can you check to see if: whee :: Show a => Eq a => (a -> Bool) works over there? -------------- next part -------------- An HTML attachment was scrubbed... URL: From andres at well-typed.com Thu Apr 10 18:51:26 2014 From: andres at well-typed.com (=?ISO-8859-1?Q?Andres_L=F6h?=) Date: Thu, 10 Apr 2014 20:51:26 +0200 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: <5346C67B.7050007@vex.net> <5346D824.8070704@gmail.com> <5346DC11.4080503@gmail.com> Message-ID: > I don't have a GHC 7.8 handy. Can you check to see if: > > whee :: Show a => Eq a => (a -> Bool) > > works over there? Yes, it does. I also see no problem with this one. Even this works (but funnily enough, it requires RankNTypes, even though it translates to the same type): let whee :: a -> Show a => Eq a => Bool; whee = undefined None of these are kind errors though. And while I don't know if it's clearly specified what exactly is possible, it makes sense to me to allow these. Cheers, Andres -- Andres L?h, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England From haskell at nand.wakku.to Thu Apr 10 18:51:36 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Thu, 10 Apr 2014 20:51:36 +0200 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: <5346C67B.7050007@vex.net> <5346D824.8070704@gmail.com> <5346DC11.4080503@gmail.com> Message-ID: <20140410205136.GA27062@nanodesu.talocan.mine.nu> On Thu, 10 Apr 2014 11:44:25 -0700, Alexander Solla wrote: > On Thu, Apr 10, 2014 at 11:40 AM, Andres L?h wrote: > I don't have a GHC 7.8 handy. Can you check to see if: > > whee :: Show a => Eq a => (a -> Bool) > > works over there? It does, see: > ? let whee :: Show a => Eq a => (a -> Bool); whee x = x == x && null > (show x) > ? :t whee > whee :: (Show a, Eq a) => a -> Bool From felipe.lessa at gmail.com Thu Apr 10 19:01:27 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu, 10 Apr 2014 16:01:27 -0300 Subject: [Haskell-cafe] Confused about type seen in the wild In-Reply-To: References: <5346C67B.7050007@vex.net> <5346D824.8070704@gmail.com> <5346DC11.4080503@gmail.com> Message-ID: <5346EA87.9030105@gmail.com> Em 10-04-2014 15:40, Andres L?h escreveu: > Sorry for continuing to reply to myself. But all this seems fixed in 7.8.1: Great, thanks! -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From jeremyrobturtle at gmail.com Fri Apr 11 05:19:27 2014 From: jeremyrobturtle at gmail.com (Yang Leo) Date: Fri, 11 Apr 2014 13:19:27 +0800 Subject: [Haskell-cafe] Seems a wrong implementation of Graham Scan in Haskell Wiki Message-ID: The implementation in the page: http://www.haskell.org/haskellwiki/Graham_Scan_Implementation seems to be wrong. Given a Point list as follows: pts5 = [Point (0,0), Point (0,4), Point (1,4), Point (2,3), Point (6,5), Point (6,0)] The gscan will output a wrong answer which included a inner point Point (1,4). That is because the implemented algorithm cannot handle the situation where multiple consecutive points need to be removed. Here is my implementation: ``` module GrahamScan where import Data.List (sortBy) import Data.Function (on) -- 9. define data `Direction` data Direction = GoLeft | GoRight | GoStraight deriving (Show, Eq) -- 10. determine direct change via point a->b->c -- -- define 2D point data Pt = Pt (Double, Double) deriving (Show, Eq, Ord) isTurned :: Pt -> Pt -> Pt -> Direction isTurned (Pt (ax, ay)) (Pt (bx, by)) (Pt (cx, cy)) = case sign of EQ -> GoStraight LT -> GoRight GT -> GoLeft where sign = compare ((bx - ax) * (cy - ay)) ((cx - ax) * (by - ay)) -- 12. implement Graham scan algorithm for convex -- -- Helper functions -- -- Find the most button left point buttonLeft :: [Pt] -> Pt buttonLeft [] = Pt (1/0, 1/0) buttonLeft [pt] = pt buttonLeft (pt:pts) = minY pt (buttonLeft pts) where minY (Pt (ax, ay)) (Pt (bx, by)) | ay > by = Pt (bx, by) | ay < by = Pt (ax, ay) | ax < bx = Pt (ax, ay) | otherwise = Pt (bx, by) -- -- Main convex :: [Pt] -> [Pt] convex [] = [] convex [pt] = [pt] convex [pt0, pt1] = [pt0, pt1] convex pts = scan [pt0] spts where -- Find the most buttonleft point pt0 pt0 = buttonLeft pts -- Sort other points `ptx` based on angle ptx> spts = tail (sortBy (compare `on` compkey pt0) pts) where compkey (Pt (ax, ay)) (Pt (bx, by)) = (atan2 (by - ay) (bx - ax), {-the secondary key make sure collinear points in order-} abs (bx - ax)) -- Scan the points to find out convex -- -- handle the case that all points are collinear scan [p0] (p1:ps) | isTurned pz p0 p1 == GoStraight = [pz, p0] where pz = last ps scan (x:xs) (y:z:rsts) = case isTurned x y z of GoRight -> scan xs (x:z:rsts) GoStraight -> scan (x:xs) (z:rsts) -- I choose to skip the collinear points GoLeft -> scan (y:x:xs) (z:rsts) scan xs [z] = z : xs ``` The source file is at https://github.com/robturtle/Haskell/blob/master/ch03/GrahamScan.hs Maybe not elegant for I just finished the first 3 chapters in Real World Haskell. However it at least correctly computes the example `pts5` -------------- next part -------------- An HTML attachment was scrubbed... URL: From han.joosten.han at gmail.com Fri Apr 11 05:37:22 2014 From: han.joosten.han at gmail.com (Han Joosten) Date: Fri, 11 Apr 2014 07:37:22 +0200 Subject: [Haskell-cafe] How to find consumer packages on Hackage? Message-ID: Hi, I wonder if there is a (simple?) way to find out which packages use some package foo? The reason I would like this is that I am interested in using configFile in a project, and I would like to look at some example usage of it. So in my case I am interested in knowing what packages use configFile. I presume there is a generic way to find out.... Cheers Han Joosten -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Fri Apr 11 05:40:14 2014 From: michael at snoyman.com (Michael Snoyman) Date: Fri, 11 Apr 2014 08:40:14 +0300 Subject: [Haskell-cafe] How to find consumer packages on Hackage? In-Reply-To: References: Message-ID: On Fri, Apr 11, 2014 at 8:37 AM, Han Joosten wrote: > > Hi, > > I wonder if there is a (simple?) way to find out which packages use some > package foo? > The reason I would like this is that I am interested in using configFile > in a project, and I would like to look at some example usage of it. So in > my case I am interested in knowing what packages use configFile. I presume > there is a generic way to find out.... > > > You can use the reverse packdeps[1] listing. [1] http://packdeps.haskellers.com/reverse -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Fri Apr 11 06:02:00 2014 From: michael at snoyman.com (Michael Snoyman) Date: Fri, 11 Apr 2014 09:02:00 +0300 Subject: [Haskell-cafe] Hackage upload log Message-ID: There used to be a log of Hackage uploads available at [1], but "it's just not here" anymore. Has that content moved to a different URL? Or is there some new way to get that information? I'd like to know the upload dates of every package. I could definitely screenscrape fro the date on the package listing pages, but I was hoping for something a bit more elegant. [1] http://hackage.haskell.org/packages/archive/log -------------- next part -------------- An HTML attachment was scrubbed... URL: From gale at sefer.org Fri Apr 11 06:20:47 2014 From: gale at sefer.org (Yitzchak Gale) Date: Fri, 11 Apr 2014 09:20:47 +0300 Subject: [Haskell-cafe] Directed rounding in haskell ? In-Reply-To: References: <20140407141231.GA3594@fuckup> Message-ID: It might also be worthwhile to have a look at some prior art: http://hackage.haskell.org/package/Ranged-sets On Thu, Apr 10, 2014 at 5:15 PM, Alp Mestanogullari wrote: > Maybe these packages could be relevant/useful: > - https://github.com/ekmett/rounded > - https://github.com/ekmett/intervals > > > On Mon, Apr 7, 2014 at 4:12 PM, Dominik Peteler wrote: >> >> Hello list, >> >> I'm going to implement an interval arithmetic library (following the IEEE >> P1788) in Haskell and for >> that I need support for directed rounding to the nearest floating point >> number. I had a quick look at the Decimal package which comes with the >> `roundTo` function for rounding to a specified number of decimal places >> but it doesn't provide directed rounding. >> Is there way to get directed rounding to to the nearest float (maybe >> even with machine floats) ? >> >> I'm also aware of the AERN-* packages but they seem to be unmaintained. At >> least there is no version which builds with the current GHC. Does >> anybody know something about that ? >> >> Regards >> >> dominik >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > Alp Mestanogullari > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From han.joosten.han at gmail.com Fri Apr 11 07:08:08 2014 From: han.joosten.han at gmail.com (Han Joosten) Date: Fri, 11 Apr 2014 09:08:08 +0200 Subject: [Haskell-cafe] How to find consumer packages on Hackage? In-Reply-To: References: Message-ID: Thanks! That is a great site! Didn't know it before, but very usefull! Met vriendelijke groet / kind regards, Han Joosten. 06-20532131 2014-04-11 7:40 GMT+02:00 Michael Snoyman : > > > On Fri, Apr 11, 2014 at 8:37 AM, Han Joosten wrote: > >> >> Hi, >> >> I wonder if there is a (simple?) way to find out which packages use some >> package foo? >> The reason I would like this is that I am interested in using configFile >> in a project, and I would like to look at some example usage of it. So in >> my case I am interested in knowing what packages use configFile. I presume >> there is a generic way to find out.... >> >> >> > You can use the reverse packdeps[1] listing. > > [1] http://packdeps.haskellers.com/reverse > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Fri Apr 11 07:24:28 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Fri, 11 Apr 2014 14:24:28 +0700 Subject: [Haskell-cafe] Seems a wrong implementation of Graham Scan in Haskell Wiki In-Reply-To: References: Message-ID: On Fri, Apr 11, 2014 at 12:19 PM, Yang Leo wrote: > The implementation in the page: > http://www.haskell.org/haskellwiki/Graham_Scan_Implementation > seems to be wrong. > Have you tried updating the haskellwiki so that your contribution is properly preserved? -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From sophie at traumapony.org Fri Apr 11 08:45:44 2014 From: sophie at traumapony.org (Sophie Taylor) Date: Fri, 11 Apr 2014 18:45:44 +1000 Subject: [Haskell-cafe] package 'permutation' no longer compiles and the maintainer is uncontactable Message-ID: Hi, The permutation package no longer compiles due to the change in comparison primops in 7.8.1. Unfortunately, the maintainer Patrick Perry no longer appears to be contactable (the email address bounces) and so cannot submit a patch. I have a patch I wish to upload and according to https://www.haskell.org/haskellwiki/Taking_over_a_package I have to state my intention to take over the maintainence of the package, so yeah, this is me doing that. Thanks, Sophie Taylor (spacekitteh) -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at with-h.at Fri Apr 11 11:16:29 2014 From: haskell at with-h.at (Dominik Peteler) Date: Fri, 11 Apr 2014 13:16:29 +0200 Subject: [Haskell-cafe] Directed rounding in haskell ? In-Reply-To: References: <20140407141231.GA3594@fuckup> Message-ID: <20140411111629.GA8187@fuckup> On Thu 2014-04-10 16:15, Alp Mestanogullari wrote: > Maybe these packages could be relevant/useful: > - https://github.com/ekmett/rounded Very interesting, thank you. How does it compare to hmpfr[1] ? Regards Dominik [1] http://hackage.haskell.org/package/hmpfr > - https://github.com/ekmett/intervals > > > On Mon, Apr 7, 2014 at 4:12 PM, Dominik Peteler wrote: > > > Hello list, > > > > I'm going to implement an interval arithmetic library (following the IEEE > > P1788) in Haskell and for > > that I need support for directed rounding to the nearest floating point > > number. I had a quick look at the Decimal package which comes with the > > `roundTo` function for rounding to a specified number of decimal places > > but it doesn't provide directed rounding. > > Is there way to get directed rounding to to the nearest float (maybe > > even with machine floats) ? > > > > I'm also aware of the AERN-* packages but they seem to be unmaintained. At > > least there is no version which builds with the current GHC. Does > > anybody know something about that ? > > > > Regards > > > > dominik > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > -- > Alp Mestanogullari -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From hreinhardt at gmail.com Fri Apr 11 11:18:55 2014 From: hreinhardt at gmail.com (Holger Reinhardt) Date: Fri, 11 Apr 2014 13:18:55 +0200 Subject: [Haskell-cafe] package 'permutation' no longer compiles and the maintainer is uncontactable In-Reply-To: References: Message-ID: His 'gsl-random' package, which was updated more recently, has a different email-address and a GitHub URL. Maybe you can contact him there. 2014-04-11 10:45 GMT+02:00 Sophie Taylor : > Hi, > > The permutation package no longer compiles due to the change in comparison > primops in 7.8.1. Unfortunately, the maintainer Patrick Perry no longer > appears to be contactable (the email address bounces) and so cannot submit > a patch. > > I have a patch I wish to upload and according to > https://www.haskell.org/haskellwiki/Taking_over_a_package > I have to state my intention to take over the maintainence of the > package, so yeah, this is me doing that. > > Thanks, > Sophie Taylor (spacekitteh) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Fri Apr 11 11:32:01 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 11 Apr 2014 12:32:01 +0100 Subject: [Haskell-cafe] [ANN] Yi 0.8 Message-ID: <5347D2B1.6050103@fuuzetsu.co.uk> We're pleased to announced Yi 0.8! While this isn't a huge release, there are some nice fixes and breaking changes compared to 0.7.0. Please note that 0.7.1 and 0.7.2 were just maintenance releases so these are lumped under this announcement. What I think is most notable is removal of Yi.Prelude, dropping GHC 7.4 support, making Yi work with GHC 7.8.1 (and soon 7.8.2 when that comes out sometime today), moving from data-accessor to lens and finally dropping the dead front-ends. Please visit us at https://github.com/yi-editor/yi Relevant part of the CHANGELOG: 0.8.0 ----- * This release works with GHC 7.8.1. * And doesn't work with GHC 7.4. * Lens is now used instead of data-accessor. Migration was mostly mechanical, patches for more idiomatic lens usage are welcome. * Yi.Prelude was getting complaints over the years so it's now gone. * Commandline flag for choosing config directory now works. * Vte and Cocoa (issue #481) frontends that were abandoned for years are removed. If you want to revive these or make new frontends (Qt, EFL, SDL, threepenny-gui, etc), patches are welcome! * Test files no longer make case sensitive filesystems mad (issue #458). * Yi no longer eats (20 x filesize) memory when opening a file. * Other bugfixes and usability tweaks here and there. Emacs-specific changes: * Dynamic reconfiguring yi with "M-x reload" now works (issue #515). * Cancel incremental search on cursor movement/return (issue #499). * Remove binding to cabal configure from emacs keymap (issue #522). * Bind M-{ and M-} to jump between paragraphs (issue #106). * Prompt the user for comment style when it's missing (issue #413). Vim2-specific changes: * C-n completion now uses words from all open buffer instead of just current one. * Introduced :buffer, :buffers and :bdelete commands and C-^ and C-6 normal mode bindings. * Meta modifier is now available for use in Vim2 bindings. * :s(ubstitute) now works with delimiters other than '/' (issue #461). * Introduced :cabal command. * More tests. 0.7.2 ----- * This is a maintenance release, upper bound set for QuickCheck. 0.7.1 ----- * This is a maintenance release, yi.cabal got cleaned up a little and dependencies got bumped, some problematic upper bounds were removed. Thanks! -- Mateusz K. From michael at snoyman.com Fri Apr 11 11:32:16 2014 From: michael at snoyman.com (Michael Snoyman) Date: Fri, 11 Apr 2014 14:32:16 +0300 Subject: [Haskell-cafe] Hackage upload log In-Reply-To: References: Message-ID: On Fri, Apr 11, 2014 at 9:02 AM, Michael Snoyman wrote: > There used to be a log of Hackage uploads available at [1], but "it's just > not here" anymore. Has that content moved to a different URL? Or is there > some new way to get that information? I'd like to know the upload dates of > every package. I could definitely screenscrape fro the date on the package > listing pages, but I was hoping for something a bit more elegant. > > [1] http://hackage.haskell.org/packages/archive/log > Just in case anyone else needs something like this, I ended up hacking together a quick screen scraper, though it would be nice if this was available via an API: {-# LANGUAGE OverloadedStrings #-} import Text.XML.Cursor import Text.HTML.DOM (sinkDoc) import Network.HTTP.Client.Conduit import Data.Conduit import Control.Monad.IO.Class import qualified Data.Text as T import Data.Time import System.Locale main = withManager $ do withResponse ("http://hackage.haskell.org/package/conduit-1.1.0") $ \res -> do doc <- responseBody res $$ sinkDoc let uploadDate = fromDocument doc $// element "th" >=> hasContent "Upload date" >=> followingSibling &/ content liftIO $ print (parseTime defaultTimeLocale "%c" $ T.unpack $ T.concat uploadDate :: Maybe UTCTime) hasContent t c = if T.concat (c $// content) == t then [c] else [] -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at with-h.at Fri Apr 11 11:37:51 2014 From: haskell at with-h.at (Dominik Peteler) Date: Fri, 11 Apr 2014 13:37:51 +0200 Subject: [Haskell-cafe] Directed rounding in haskell ? In-Reply-To: <53434BEE.4000407@gmail.com> References: <20140407141231.GA3594@fuckup> <53434BEE.4000407@gmail.com> Message-ID: <20140411113751.GB8187@fuckup> Thank you for your response. I had a quick look at it but I'll probably go with some MPFR binding first. Maybe I'll add support for it later. Regards Dominik On Mon 2014-04-07 21:07, Sterling Clover wrote: > You can set the rounding mode directly with ieee-utils. > > Apparently it doesn't compile anymore, so someone has uploaded a temporary > replacement: http://hackage.haskell.org/package/ieee-utils-tempfix-0.4.0.1 > > The primary maintainer of the original package left the haskell community > some time ago. (I contributed some additional code many years ago). Michal > Konecny -- would you be interested in taking over maintainership? > > -s > > On 4/7/14, 10:12 AM, Dominik Peteler wrote: > >Hello list, > > > >I'm going to implement an interval arithmetic library (following the IEEE P1788) in Haskell and for > >that I need support for directed rounding to the nearest floating point > >number. I had a quick look at the Decimal package which comes with the > >`roundTo` function for rounding to a specified number of decimal places > >but it doesn't provide directed rounding. > >Is there way to get directed rounding to to the nearest float (maybe > >even with machine floats) ? > > > >I'm also aware of the AERN-* packages but they seem to be unmaintained. At > >least there is no version which builds with the current GHC. Does > >anybody know something about that ? > > > >Regards > > > >dominik > > > > > >_______________________________________________ > >Haskell-Cafe mailing list > >Haskell-Cafe at haskell.org > >http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From claude at mathr.co.uk Fri Apr 11 12:03:45 2014 From: claude at mathr.co.uk (Claude Heiland-Allen) Date: Fri, 11 Apr 2014 13:03:45 +0100 Subject: [Haskell-cafe] Directed rounding in haskell ? In-Reply-To: <20140411111629.GA8187@fuckup> References: <20140407141231.GA3594@fuckup> <20140411111629.GA8187@fuckup> Message-ID: <5347DA21.1060801@mathr.co.uk> On 11/04/14 12:16, Dominik Peteler wrote: > On Thu 2014-04-10 16:15, Alp Mestanogullari wrote: >> Maybe these packages could be relevant/useful: >> - https://github.com/ekmett/rounded > > Very interesting, thank you. > How does it compare to hmpfr[1] ? > > [1] http://hackage.haskell.org/package/hmpfr 'hmpfr' doesn't work safely (random crashes occur) unless you re-compile a custom ghc without 'integer-gmp', and the alternative 'integer-simple' is very slow in comparison. 'rounded' works around the problem (GHC's GC moving GMP things behind MPFR's back) but requires a patched libmpfr (which it bundles), though it is still not quite ready for general use (a few remaining issues to resolve afaik). Claude -- http://mathr.co.uk From haskell at with-h.at Fri Apr 11 12:42:22 2014 From: haskell at with-h.at (Dominik Peteler) Date: Fri, 11 Apr 2014 14:42:22 +0200 Subject: [Haskell-cafe] Directed rounding in haskell ? In-Reply-To: <5347DA21.1060801@mathr.co.uk> References: <20140407141231.GA3594@fuckup> <20140411111629.GA8187@fuckup> <5347DA21.1060801@mathr.co.uk> Message-ID: <20140411124222.GC8187@fuckup> Thank you for the explanation. Apparently there is no package on hackage (yet). (At least the link on the github page is dead) When is it going to be released ? Regards Dominik On Fri 2014-04-11 13:03, Claude Heiland-Allen wrote: > On 11/04/14 12:16, Dominik Peteler wrote: > >On Thu 2014-04-10 16:15, Alp Mestanogullari wrote: > >>Maybe these packages could be relevant/useful: > >>- https://github.com/ekmett/rounded > > > >Very interesting, thank you. > >How does it compare to hmpfr[1] ? > > > >[1] http://hackage.haskell.org/package/hmpfr > > 'hmpfr' doesn't work safely (random crashes occur) unless you re-compile a > custom ghc without 'integer-gmp', and the alternative 'integer-simple' is > very slow in comparison. > > 'rounded' works around the problem (GHC's GC moving GMP things behind MPFR's > back) but requires a patched libmpfr (which it bundles), though it is still > not quite ready for general use (a few remaining issues to resolve afaik). > > > Claude > -- > http://mathr.co.uk > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From duncan.coutts at googlemail.com Fri Apr 11 13:01:46 2014 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Fri, 11 Apr 2014 14:01:46 +0100 Subject: [Haskell-cafe] Hackage upload log In-Reply-To: References: Message-ID: <1397221306.16598.6.camel@dunky.localdomain> On Fri, 2014-04-11 at 14:32 +0300, Michael Snoyman wrote: > On Fri, Apr 11, 2014 at 9:02 AM, Michael Snoyman wrote: > > > There used to be a log of Hackage uploads available at [1], but "it's just > > not here" anymore. Has that content moved to a different URL? Or is there > > some new way to get that information? I'd like to know the upload dates of > > every package. I could definitely screenscrape fro the date on the package > > listing pages, but I was hoping for something a bit more elegant. > > > > [1] http://hackage.haskell.org/packages/archive/log > > > > Just in case anyone else needs something like this, I ended up hacking > together a quick screen scraper, though it would be nice if this was > available via an API: > ... > withResponse ("http://hackage.haskell.org/package/conduit-1.1.0") $ > ... It is available directly at: http://hackage.haskell.org/package/conduit-1.1.0/upload-time and you may also be interested in http://hackage.haskell.org/package/conduit-1.1.0/uploader How would you know this exists? The whole API is automatically (if not brilliantly) documented: http://hackage.haskell.org/api (which itself is mentioned on the front page) The goal has always been that all the info be publicly available in human and machine readable formats (at least JSON). There are certainly things missing, but we'll accept patches that exposes more stuff. Duncan From michael at snoyman.com Fri Apr 11 13:59:19 2014 From: michael at snoyman.com (Michael Snoyman) Date: Fri, 11 Apr 2014 16:59:19 +0300 Subject: [Haskell-cafe] Hackage upload log In-Reply-To: <1397221306.16598.6.camel@dunky.localdomain> References: <1397221306.16598.6.camel@dunky.localdomain> Message-ID: On Fri, Apr 11, 2014 at 4:01 PM, Duncan Coutts wrote: > On Fri, 2014-04-11 at 14:32 +0300, Michael Snoyman wrote: > > On Fri, Apr 11, 2014 at 9:02 AM, Michael Snoyman >wrote: > > > > > There used to be a log of Hackage uploads available at [1], but "it's > just > > > not here" anymore. Has that content moved to a different URL? Or is > there > > > some new way to get that information? I'd like to know the upload > dates of > > > every package. I could definitely screenscrape fro the date on the > package > > > listing pages, but I was hoping for something a bit more elegant. > > > > > > [1] http://hackage.haskell.org/packages/archive/log > > > > > > > Just in case anyone else needs something like this, I ended up hacking > > together a quick screen scraper, though it would be nice if this was > > available via an API: > > > > ... > > withResponse ("http://hackage.haskell.org/package/conduit-1.1.0") $ > > ... > > It is available directly at: > > http://hackage.haskell.org/package/conduit-1.1.0/upload-time > and you may also be interested in > http://hackage.haskell.org/package/conduit-1.1.0/uploader > > > How would you know this exists? The whole API is automatically (if not > brilliantly) documented: > > http://hackage.haskell.org/api > (which itself is mentioned on the front page) > > The goal has always been that all the info be publicly available in > human and machine readable formats (at least JSON). There are certainly > things missing, but we'll accept patches that exposes more stuff. > > Duncan > > Thanks, I looked through that page, but somehow missed the upload-time call. It would still be convenient to have the entire upload history in a single page available, but this will provide what I need for now. Thank you! Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Apr 11 14:01:27 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 11 Apr 2014 10:01:27 -0400 Subject: [Haskell-cafe] package 'permutation' no longer compiles and the maintainer is uncontactable In-Reply-To: References: Message-ID: Ccing him now Get his ok and I'll give you uploaded acls On Friday, April 11, 2014, Sophie Taylor wrote: > Hi, > > The permutation package no longer compiles due to the change in comparison > primops in 7.8.1. Unfortunately, the maintainer Patrick Perry no longer > appears to be contactable (the email address bounces) and so cannot submit > a patch. > > I have a patch I wish to upload and according to > https://www.haskell.org/haskellwiki/Taking_over_a_package > I have to state my intention to take over the maintainence of the > package, so yeah, this is me doing that. > > Thanks, > Sophie Taylor (spacekitteh) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Apr 11 14:02:14 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 11 Apr 2014 10:02:14 -0400 Subject: [Haskell-cafe] Directed rounding in haskell ? In-Reply-To: <20140411124222.GC8187@fuckup> References: <20140407141231.GA3594@fuckup> <20140411111629.GA8187@fuckup> <5347DA21.1060801@mathr.co.uk> <20140411124222.GC8187@fuckup> Message-ID: When it's ready. On Friday, April 11, 2014, Dominik Peteler wrote: > Thank you for the explanation. > Apparently there is no package on hackage (yet). > (At least the link on the github page is dead) > When is it going to be released ? > > Regards > > Dominik > > > > On Fri 2014-04-11 13:03, Claude Heiland-Allen wrote: > > On 11/04/14 12:16, Dominik Peteler wrote: > > >On Thu 2014-04-10 16:15, Alp Mestanogullari wrote: > > >>Maybe these packages could be relevant/useful: > > >>- https://github.com/ekmett/rounded > > > > > >Very interesting, thank you. > > >How does it compare to hmpfr[1] ? > > > > > >[1] http://hackage.haskell.org/package/hmpfr > > > > 'hmpfr' doesn't work safely (random crashes occur) unless you re-compile > a > > custom ghc without 'integer-gmp', and the alternative 'integer-simple' is > > very slow in comparison. > > > > 'rounded' works around the problem (GHC's GC moving GMP things behind > MPFR's > > back) but requires a patched libmpfr (which it bundles), though it is > still > > not quite ready for general use (a few remaining issues to resolve > afaik). > > > > > > Claude > > -- > > http://mathr.co.uk > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Fri Apr 11 14:16:16 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Fri, 11 Apr 2014 21:16:16 +0700 Subject: [Haskell-cafe] Seems a wrong implementation of Graham Scan in Haskell Wiki In-Reply-To: References: Message-ID: On Fri, Apr 11, 2014 at 6:16 PM, Yang Leo wrote: > I don't have the account on Haskell wiki. How can I get an account on it > so I can contribute? Look here: http://www.haskell.org/haskellwiki/HaskellWiki:Contributing -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From patperry at gmail.com Fri Apr 11 15:05:16 2014 From: patperry at gmail.com (Patrick Perry) Date: Fri, 11 Apr 2014 11:05:16 -0400 Subject: [Haskell-cafe] package 'permutation' no longer compiles and the maintainer is uncontactable In-Reply-To: <0A2BCC6FA8724186BB9C89CCA31878DA@stern.nyu.edu> References: <0A2BCC6FA8724186BB9C89CCA31878DA@stern.nyu.edu> Message-ID: <90EFBC2CF3AC421C936ECB9ACDD64962@gmail.com> It's fine with me if Sophie takes over maintenance of the "permutation" package. On Friday, April 11, 2014 at 11:03 AM, Patrick Perry wrote: > Hi Sophie, > > It's fine with me if you take over maintenance of the package. > > > Patrick > > On Friday, April 11, 2014 at 10:01 AM, Carter Schonwald wrote: > > > Ccing him now > > Get his ok and I'll give you uploaded acls > > > > On Friday, April 11, 2014, Sophie Taylor wrote: > > > Hi, > > > > > > The permutation package no longer compiles due to the change in comparison primops in 7.8.1. Unfortunately, the maintainer Patrick Perry no longer appears to be contactable (the email address bounces) and so cannot submit a patch. > > > > > > I have a patch I wish to upload and according to https://www.haskell.org/haskellwiki/Taking_over_a_package > > > > > > I have to state my intention to take over the maintainence of the package, so yeah, this is me doing that. > > > > > > Thanks, > > > Sophie Taylor (spacekitteh) > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan.coutts at googlemail.com Fri Apr 11 15:19:09 2014 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Fri, 11 Apr 2014 16:19:09 +0100 Subject: [Haskell-cafe] Hackage upload log In-Reply-To: References: <1397221306.16598.6.camel@dunky.localdomain> Message-ID: <1397229549.17903.3.camel@dunky.localdomain> On Fri, 2014-04-11 at 16:59 +0300, Michael Snoyman wrote: > On Fri, Apr 11, 2014 at 4:01 PM, Duncan Coutts > wrote: > > It is available directly at: > > > > http://hackage.haskell.org/package/conduit-1.1.0/upload-time > > and you may also be interested in > > http://hackage.haskell.org/package/conduit-1.1.0/uploader > > > > > > How would you know this exists? The whole API is automatically (if not > > brilliantly) documented: > > > > http://hackage.haskell.org/api > > (which itself is mentioned on the front page) > > > > The goal has always been that all the info be publicly available in > > human and machine readable formats (at least JSON). There are certainly > > things missing, but we'll accept patches that exposes more stuff. > > > > Duncan > > > > > > Thanks, I looked through that page, but somehow missed the upload-time call. It's currently grouped by feature. I had intended to also have a merged view with the resources from all features which would be helpful at times like these. (Turned out to be slightly more tricky than I'd expected so I didn't implement it.) > It would still be convenient to have the entire upload history in a single > page available, but this will provide what I need for now. Thank you! Patches gratefully accepted! :-) Duncan From duncan.coutts at googlemail.com Fri Apr 11 15:19:38 2014 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Fri, 11 Apr 2014 16:19:38 +0100 Subject: [Haskell-cafe] Feedback/Ideas for a Master Thesis about creating a Querying Tool for Hackage In-Reply-To: References: Message-ID: <1397229578.17903.5.camel@dunky.localdomain> On Thu, 2014-03-27 at 18:51 +0100, Victor Nithander wrote: > Hi, > > My name is Victor Nithander and I am currently doing my Master Thesis at > the Computer Science and Engineering department at Chalmers in Gothenburg > and would like to ask you for some help. > > My Master Thesis is about creating a querying tool for Hackage written in > Haskell and I would like to know what kind of features you would like the > querying tool to have. My plan is to design and implement an embedded > language for queries to be expressed in and then implement a backend which > accordingly takes care of those queries. I then plan to packet the tool as > a package using Cabal and upload it to Hackage. Hi Victor, This sounds great. Some feedback: I can't quite tell from your description if you're planning to query just the package metadata (ie the info available in the hackage index) or also the content / source code of packages. Just using the metadata would be a lot easier! Something you may or may not wish to consider is full text search. I've actually been considering integrating full text search into the cabal-install client (based on the text search code that the hackage-server uses). I'm not quite sure if that'd fit nicely with the kind of structured querying that you've mentioned or not. Something to consider anyway. Making it into it's own package is certainly the right place to start. You may want to keep in mind however two contexts where one may ultimately wish to use the code: hackage-server and cabal-install. Assuming that you're only using the index metadata and not package contents then this could fit nicely with either of these tools. In hackage-server we'd be somewhat concerned about performance, but would be able to keep data structures in memory. In cabal-install we obviously cannot pre-compute an in-memory structure for multiple queries, but it would be possible to pre-compute some structure and keep it on disk, and load it into memory to do a single query (a bit like how hoogle works now). Duncan From jeremyrobturtle at gmail.com Fri Apr 11 17:14:39 2014 From: jeremyrobturtle at gmail.com (Yang Leo) Date: Sat, 12 Apr 2014 01:14:39 +0800 Subject: [Haskell-cafe] Seems a wrong implementation of Graham Scan in Haskell Wiki In-Reply-To: References: <67F350E1-29B7-4015-BD47-E3B8D85642E9@gmail.com> <0F49A8BB-866D-45AC-9095-003228DD3B4F@gmail.com> Message-ID: Ah so that?s how a mailing list works.. Sorry for my stupidness... On Apr 12, 2014, at 1:08 AM, Kim-Ee Yeoh wrote: > > On Sat, Apr 12, 2014 at 12:01 AM, Yang Leo wrote: > I?ve updated the Haskell wiki now. I haven?t learnt how to do unit tests in Haskell yet, > any tests on my implementations would be welcomed. > > wikipage: http://www.haskell.org/haskellwiki/Graham_Scan_Implementation > > Would you mind forwarding to the haskell-cafe mailing list as well? > > So that everyone else is kept updated? > > -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Fri Apr 11 18:02:39 2014 From: vogt.adam at gmail.com (adam vogt) Date: Fri, 11 Apr 2014 14:02:39 -0400 Subject: [Haskell-cafe] Seems a wrong implementation of Graham Scan in Haskell Wiki In-Reply-To: References: <67F350E1-29B7-4015-BD47-E3B8D85642E9@gmail.com> <0F49A8BB-866D-45AC-9095-003228DD3B4F@gmail.com> Message-ID: Hi Yang Leo, Did you consider leaving or adapting the quickcheck tests that were on that page previously? Quickcheck isn't a unit test, but it is similarly useful. Regards, Adam On Fri, Apr 11, 2014 at 1:14 PM, Yang Leo wrote: > Ah so that?s how a mailing list works.. Sorry for my stupidness... > > On Apr 12, 2014, at 1:08 AM, Kim-Ee Yeoh wrote: > > > On Sat, Apr 12, 2014 at 12:01 AM, Yang Leo > wrote: >> >> I?ve updated the Haskell wiki now. I haven?t learnt how to do unit tests >> in Haskell yet, >> any tests on my implementations would be welcomed. >> >> wikipage: http://www.haskell.org/haskellwiki/Graham_Scan_Implementation > > > Would you mind forwarding to the haskell-cafe mailing list as well? > > So that everyone else is kept updated? > > -- Kim-Ee > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From fuuzetsu at fuuzetsu.co.uk Fri Apr 11 18:10:10 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 11 Apr 2014 19:10:10 +0100 Subject: [Haskell-cafe] [ANN] Yi 0.8 In-Reply-To: <5347D2B1.6050103@fuuzetsu.co.uk> References: <5347D2B1.6050103@fuuzetsu.co.uk> Message-ID: <53483002.2050105@fuuzetsu.co.uk> On 11/04/14 12:32, Mateusz Kowalczyk wrote: > We're pleased to announced Yi 0.8! > > While this isn't a huge release, there are some nice fixes and breaking > changes compared to 0.7.0. Please note that 0.7.1 and 0.7.2 were just > maintenance releases so these are lumped under this announcement. > > What I think is most notable is removal of Yi.Prelude, dropping GHC 7.4 > support, making Yi work with GHC 7.8.1 (and soon 7.8.2 when that comes > out sometime today), moving from data-accessor to lens and finally > dropping the dead front-ends. > > Please visit us at https://github.com/yi-editor/yi > > [snip] We've been made aware that this release doesn't build for some people due to name clashes with lens: the name in question has been removed from lens but if your lens version is old enough then you'll have this problem. We have released 0.8.1 which fixes lens version bounds. Thanks and apologies for the noise. -- Mateusz K. From fuuzetsu at fuuzetsu.co.uk Fri Apr 11 18:23:20 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 11 Apr 2014 19:23:20 +0100 Subject: [Haskell-cafe] Haddock markup questions In-Reply-To: References: <5346C972.2000806@fuuzetsu.co.uk> Message-ID: <53483318.2030306@fuuzetsu.co.uk> On 10/04/14 17:52, Christiaan Baaij wrote: >> >> >>> But that's unwanted, as those backslashes show up in GHC(i) messages. >>> So: how do I get haddock to not parse my '<^>' operator as a link/URL? >> >> Hm, strange, technically we parse identifiers first and links second so >> this should work without a problem unless Haddock doesn't recognise it >> as an identifier. >> >> I actually now notice in the parser that we don't consider ^ to be a >> valid symbol so that's probably the culprit! Good catch, if that's >> actually the case here then you can expect it to be fixed in the next >> release, perhaps with 7.8.3 or something. Unfortunately the way we do >> identifier parsing now is that we slurp everything that looks like a >> valid identifier and afterwards we ask GHC to actually tell us if it's >> it's something we know about. It seems like a bug caused by me not being >> careful when reading the relevant part of the report, deepest apologies! >> I do wish we had a better way of parsing these identifiers but I can't >> think of one. >> > > It never came to mind that '^' was the actual culprit :-) > Now that I know that it's a (potential) bug, I'll just keep my eye on > ghc-commit and wait for the bugfix. > I'm used to running ghc-HEAD anyway. > > Also, is it not possible to update my haddock seperate from GHC? > > -- Christiaan > For those not idling #ghc or stumbling upon this in 7 years, I have fixed the problem and it should ship with 2.14.3 which should in turn ship with 7.8.3. -- Mateusz K. From jeremyrobturtle at gmail.com Sat Apr 12 00:39:22 2014 From: jeremyrobturtle at gmail.com (Yang Leo) Date: Sat, 12 Apr 2014 08:39:22 +0800 Subject: [Haskell-cafe] Seems a wrong implementation of Graham Scan in Haskell Wiki In-Reply-To: References: <67F350E1-29B7-4015-BD47-E3B8D85642E9@gmail.com> <0F49A8BB-866D-45AC-9095-003228DD3B4F@gmail.com> Message-ID: I?ve adapt the old quickcheck tests to mine code, and yes, the old mistake gone. On Apr 12, 2014, at 2:02 AM, adam vogt wrote: > Hi Yang Leo, > > Did you consider leaving or adapting the quickcheck tests that were on > that page previously? Quickcheck isn't a unit test, but it is > similarly useful. > > Regards, > Adam > > On Fri, Apr 11, 2014 at 1:14 PM, Yang Leo wrote: >> Ah so that?s how a mailing list works.. Sorry for my stupidness... >> >> On Apr 12, 2014, at 1:08 AM, Kim-Ee Yeoh wrote: >> >> >> On Sat, Apr 12, 2014 at 12:01 AM, Yang Leo >> wrote: >>> >>> I?ve updated the Haskell wiki now. I haven?t learnt how to do unit tests >>> in Haskell yet, >>> any tests on my implementations would be welcomed. >>> >>> wikipage: http://www.haskell.org/haskellwiki/Graham_Scan_Implementation >> >> >> Would you mind forwarding to the haskell-cafe mailing list as well? >> >> So that everyone else is kept updated? >> >> -- Kim-Ee >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> From miroslav.karpis at gmail.com Sat Apr 12 21:22:01 2014 From: miroslav.karpis at gmail.com (Miro Karpis) Date: Sat, 12 Apr 2014 23:22:01 +0200 Subject: [Haskell-cafe] warp vs scotty + some benchmark numbers Message-ID: Hi, I'm trying to make a small benchmarking for warp and scotty (later with json/no-json text performance test). My client is a Qt c++ application. I made a minimum code in both Haskell and C++. The problem is the numbers I'm getting. (Benchmark::pong-warp) - total requests: 10000 , send/received in msec: 3848 (Benchmark::pong-scotty) - total requests: 10000 , send/received in msec: 3814 Only sending 10k requests from my c++ client takes around 1 sec. What I don't understand is: a) how is it possible that scotty is so close to warp (in this run it even wins)? b) 10k requests I'm getting in approximately 4 seconds. Hereis one 2 years old benchmark with 80k/second. Why is there so big difference? I'm running on macbook-pro 16g, 2.3 GHz Scotty and warp is compiled with: -O2 -threaded --scotty import Web.Scotty import Data.Monoid (mconcat) main = scotty 3005 $ do get "/" $ do text "pong" --warp import Network.Wai(responseLBS, Application) import Network.HTTP.Types(status200) import Network.Wai.Handler.Warp (run) app :: Application app _ = return $ responseLBS status200 [("Content-Type", "text/plain")] "pong" main :: IO () main = do let port = 3000 putStrLn $ "Listening on port " ++ show port run port app --c++ client sample (Qt) simStart = QDateTime().currentMSecsSinceEpoch(); for(int i=0; iget(QNetworkRequest(url)); QEventLoop eventLoop; QObject::connect(manager, SIGNAL(finished(QNetworkReply *)), &eventLoop, SLOT(quit())); eventLoop.exec(); QObject::disconnect(manager, SIGNAL(finished(QNetworkReply *)), &eventLoop, SLOT(quit())); } qDebug() << "(Benchmark::pong) - total requests: " << requests << ", send in msec: " << (QDateTime().currentMSecsSinceEpoch()-simStart); cheers, miro -------------- next part -------------- An HTML attachment was scrubbed... URL: From amit at amitlevy.com Sat Apr 12 21:49:59 2014 From: amit at amitlevy.com (Amit Aryeh Levy) Date: Sat, 12 Apr 2014 14:49:59 -0700 Subject: [Haskell-cafe] warp vs scotty + some benchmark numbers In-Reply-To: References: Message-ID: <5349B507.7080303@amitlevy.com> Several things... 1. The difference here isn't very big, so it's likely that the ~30ms difference to complete 10k requests is just noise. Scotty's overhead should really be pretty small 2. With GHC <= 7.6, -threaded is actually going to hurt you on Warp benchmarks that don't do much computational work. 7.8's new IO manager seems like is a different story from my benchmarks, but -threaded is basically a loss if you're not going to be doing any actual parallelism (which if it's just a pong benchmark, isn't really) 3. It's almost certainly the case that the bottleneck is in your client code. It's not trivial to write benchmark code and a fair amount of effort has gone into building such tools (httperf and wrk seem to be the best right now). Are you using Keep-Alive to recycle connections? Are you using events/threads on the client? Is your client HTTP parsing code fast? Are you spending a lot of time copying buffers around? The trick is to keep the servers constantly busy, and if they are waiting on getting the next request from the server, that's not going to be the case. For comparison, just yesterday I happened to run such a benchmark on Warp and get ~70k req/sec with a load of 2-3 client threads. I've gotten higher before. This was on my laptop with similar specs - Arch Linux, 3.4Ghz Intel i7, 16GB, all over localhost. I'd recommend testing out the benchmark with `wrk` and/or `httperf` (wrk is just easier to get going, but I've gotten good results with both). Cheers! Amit On 04/12/2014 02:22 PM, Miro Karpis wrote: > Hi, > I'm trying to make a small benchmarking for warp and scotty (later > with json/no-json text performance test). My client is a Qt c++ > application. I made a minimum code in both Haskell and C++. The > problem is the numbers I'm getting. > > (Benchmark::pong-warp) - total requests: 10000 , send/received in > msec: 3848 > > (Benchmark::pong-scotty) - total requests: 10000 , send/received in > msec: 3814 > > > Only sending 10k requests from my c++ client takes around 1 sec. > > > What I don't understand is: > a) how is it possible that scotty is so close to warp (in this run it > even wins)? > b) 10k requests I'm getting in approximately 4 seconds. Here > > is one 2 years old benchmark with 80k/second. Why is there so big > difference? > > I'm running on macbook-pro 16g, 2.3 GHz > > > Scotty and warp is compiled with: -O2 -threaded > > > --scotty > import Web.Scotty > import Data.Monoid (mconcat) > > main = scotty 3005 $ do > > get "/" $ do > text "pong" > > --warp > import Network.Wai(responseLBS, Application) > import Network.HTTP.Types(status200) > import Network.Wai.Handler.Warp (run) > > app :: Application > app _ = return $ responseLBS > status200 > [("Content-Type", "text/plain")] > "pong" > > main :: IO () > main = do > let port = 3000 > putStrLn $ "Listening on port " ++ show port > run port app > > --c++ client sample (Qt) > simStart = QDateTime().currentMSecsSinceEpoch(); > > for(int i=0; i QNetworkReply *reply = manager->get(QNetworkRequest(url)); > QEventLoop eventLoop; > QObject::connect(manager, SIGNAL(finished(QNetworkReply *)), &eventLoop, SLOT(quit())); > eventLoop.exec(); > QObject::disconnect(manager, SIGNAL(finished(QNetworkReply *)), &eventLoop, SLOT(quit())); > } > > qDebug() << "(Benchmark::pong) - total requests: " << requests << ", send in msec: " << (QDateTime().currentMSecsSinceEpoch()-simStart); > cheers, > miro > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikoamia at gmail.com Sun Apr 13 01:09:47 2014 From: nikoamia at gmail.com (Nikolay Amiantov) Date: Sun, 13 Apr 2014 05:09:47 +0400 Subject: [Haskell-cafe] Patches for (abandoned?) pcre-light Message-ID: Hello, I've tried the new ghc-7.8.1 and have had an issue with building pcre-light as one of dependencies for my project. I've made a patch which fixes this, but I can't reach maintainer by e-mail -- what can I do in this situation? Also, the second (unrelated) question would be: how can I find a package which depends on it in my project? I have found no way to dump a dependency tree in cabal. Thanks in advance, Nikolay. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Apr 13 01:21:17 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 12 Apr 2014 21:21:17 -0400 Subject: [Haskell-cafe] Patches for (abandoned?) pcre-light In-Reply-To: References: Message-ID: please upgrace to 7.8.2 before trying to build anything, theres a *big* bug in 7.8.1 type checker On Sat, Apr 12, 2014 at 9:09 PM, Nikolay Amiantov wrote: > Hello, > I've tried the new ghc-7.8.1 and have had an issue with building > pcre-light as one of dependencies for my project. I've made a patch which > fixes this, but I can't reach maintainer by e-mail -- what can I do in this > situation? Also, the second (unrelated) question would be: how can I find a > package which depends on it in my project? I have found no way to dump a > dependency tree in cabal. > > Thanks in advance, > Nikolay. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dburke.gw at gmail.com Sun Apr 13 01:35:28 2014 From: dburke.gw at gmail.com (Doug Burke) Date: Sat, 12 Apr 2014 21:35:28 -0400 Subject: [Haskell-cafe] Dependencies (was Re: Patches for (abandoned?) pcre-light) Message-ID: On Apr 12, 2014 9:10 PM, "Nikolay Amiantov" wrote: > > Also, the second (unrelated) question would be: how can I find a package which depends on it in my project? I have found no way to dump a dependency tree in cabal. Is this the information that you want? http://packdeps.haskellers.com/ http://packdeps.haskellers.com/reverse Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From tab at snarc.org Sun Apr 13 04:28:43 2014 From: tab at snarc.org (Vincent Hanquez) Date: Sun, 13 Apr 2014 05:28:43 +0100 Subject: [Haskell-cafe] Feedback/Ideas for a Master Thesis about creating a Querying Tool for Hackage In-Reply-To: References: Message-ID: <534A127B.1000608@snarc.org> On 2014-03-27 17:51, Victor Nithander wrote: > > Hi, > > > My name is Victor Nithander and I am currently doing my Master Thesis > at the Computer Science and Engineering department at Chalmers in > Gothenburg and would like to ask you for some help. > > > My Master Thesis is about creating a querying tool for Hackage written > in Haskell and I would like to know what kind of features you would > like the querying tool to have. My plan is to design and implement an > embedded language for queries to be expressed in and then implement a > backend which accordingly takes care of those queries. I then plan to > packet the tool as a package using Cabal and upload it to Hackage. > > > Any feedback/ideas on features or other things about the tool would be > greatly appreciated as I want to make a tool which benefits the > community as much as possible. > > > Examples of queries I?m thinking of to implement is: > > > * > > Which language features (such as typeclass instances) does a > certain package use? > > * > > How many packages uses a certain language feature? > > * > > Which packages does a certain package depend on? > > * > > Which packages depends on a certain package? > > Hi Victor, cabal-db [1] already does some have basic cross packages functionalities. It would be nice a more powerful query language to go with it. [1] https://github.com/vincenthz/cabal-db -- Vincent From tab at snarc.org Sun Apr 13 04:32:15 2014 From: tab at snarc.org (Vincent Hanquez) Date: Sun, 13 Apr 2014 05:32:15 +0100 Subject: [Haskell-cafe] Dependencies (was Re: Patches for (abandoned?) pcre-light) In-Reply-To: References: Message-ID: <534A134F.6030402@snarc.org> On 2014-04-13 02:35, Doug Burke wrote: > > > On Apr 12, 2014 9:10 PM, "Nikolay Amiantov" > wrote: > > > > Also, the second (unrelated) question would be: how can I find a > package which depends on it in my project? I have found no way to dump > a dependency tree in cabal. > > Is this the information that you want? > > http://packdeps.haskellers.com/ > http://packdeps.haskellers.com/reverse > > Also complementing the website, there's a CLI client called cabal-db [1]. cabal-db revdeps [1] https://github.com/vincenthz/cabal-db -- Vincent From djsamperi at gmail.com Sun Apr 13 04:56:12 2014 From: djsamperi at gmail.com (Dominick Samperi) Date: Sun, 13 Apr 2014 00:56:12 -0400 Subject: [Haskell-cafe] Handling Windows file name conventions without unix (Posix) package? Message-ID: Hello, The unix package (System.Posix) is not supported under Windows and I wonder if there is an alternative solution that deals with the odd file naming convention under windows (backward vs unix forward slash), spaces in file names, etc. It looks like System.Environment is a good substitute for System.Posix.Env, but it is not clear how to deal with file naming conventions. Any pointers or tips would be much appreciated. Thanks, Dominick From djohnson.m at gmail.com Sun Apr 13 05:17:22 2014 From: djohnson.m at gmail.com (David Johnson) Date: Sun, 13 Apr 2014 00:17:22 -0500 Subject: [Haskell-cafe] Handling Windows file name conventions without unix (Posix) package? In-Reply-To: References: Message-ID: Dominick, I recommend looking at the unix-compat package when working on non-posix systems. http://hackage.haskell.org/package/unix-compat-0.4.1.1/docs/System-PosixCompat-Files.html As far as dealing with the different file conventions across OS's, I recommend looking at the filepath library. It has functions for dealing w/ filepaths agnostically. http://hackage.haskell.org/package/filepath-1.3.0.2/docs/System-FilePath-Windows.html On Sat, Apr 12, 2014 at 11:56 PM, Dominick Samperi wrote: > Hello, > > The unix package (System.Posix) is not supported under Windows and > I wonder if there is an alternative solution that deals with the odd file > naming convention under windows (backward vs unix forward slash), > spaces in file names, etc. > > It looks like System.Environment is a good substitute for System.Posix.Env, > but it is not clear how to deal with file naming conventions. > > Any pointers or tips would be much appreciated. > > Thanks, > Dominick > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Cell: 1.630.740.8204 -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Sun Apr 13 08:45:53 2014 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Sun, 13 Apr 2014 10:45:53 +0200 Subject: [Haskell-cafe] Simple OverloadedLists question Message-ID: Hi! I wanted to check out great new OverloadedLists [0] feature, but got an error as in [1]. What am I doing wrong? Thanks. [0]: https://www.haskell.org/ghc/docs/7.8.1/html/users_guide/type-class-extensions.html#overloaded-lists [1]: https://gist.github.com/k-bx/10574806 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lambda.fairy at gmail.com Sun Apr 13 08:55:45 2014 From: lambda.fairy at gmail.com (Chris Wong) Date: Sun, 13 Apr 2014 20:55:45 +1200 Subject: [Haskell-cafe] Simple OverloadedLists question In-Reply-To: References: Message-ID: On Sun, Apr 13, 2014 at 8:45 PM, Konstantine Rybnikov wrote: > Hi! > > I wanted to check out great new OverloadedLists [0] feature, but got an > error as in [1]. > > What am I doing wrong? > > Thanks. > > [0]: > https://www.haskell.org/ghc/docs/7.8.1/html/users_guide/type-class-extensions.html#overloaded-lists > [1]: https://gist.github.com/k-bx/10574806 Try upgrading to GHC 7.8.2 first. I heard it fixes a serious bug in the type checker, which may be behind your problem. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From k-bx at k-bx.com Sun Apr 13 09:02:28 2014 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Sun, 13 Apr 2014 11:02:28 +0200 Subject: [Haskell-cafe] Simple OverloadedLists question In-Reply-To: References: Message-ID: It's 7.8.2. On Sun, Apr 13, 2014 at 10:55 AM, Chris Wong wrote: > On Sun, Apr 13, 2014 at 8:45 PM, Konstantine Rybnikov > wrote: > > Hi! > > > > I wanted to check out great new OverloadedLists [0] feature, but got an > > error as in [1]. > > > > What am I doing wrong? > > > > Thanks. > > > > [0]: > > > https://www.haskell.org/ghc/docs/7.8.1/html/users_guide/type-class-extensions.html#overloaded-lists > > [1]: https://gist.github.com/k-bx/10574806 > > Try upgrading to GHC 7.8.2 first. I heard it fixes a serious bug in > the type checker, which may be behind your problem. > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Sun Apr 13 09:07:37 2014 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Sun, 13 Apr 2014 11:07:37 +0200 Subject: [Haskell-cafe] Simple OverloadedLists question In-Reply-To: References: Message-ID: On Sun, Apr 13, 2014 at 10:45 AM, Konstantine Rybnikov wrote: > Hi! > > I wanted to check out great new OverloadedLists [0] feature, but got an > error as in [1]. > > What am I doing wrong? > > Thanks. > > [0]: > https://www.haskell.org/ghc/docs/7.8.1/html/users_guide/type-class-extensions.html#overloaded-lists > [1]: https://gist.github.com/k-bx/10574806 > > Just FYI, IRC-user @Hermit fixed it by adding IsList instance to Map. https://gist.github.com/Arm/10575474 -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregorycollins.net Sun Apr 13 09:38:40 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Sun, 13 Apr 2014 11:38:40 +0200 Subject: [Haskell-cafe] warp vs scotty + some benchmark numbers In-Reply-To: References: Message-ID: On Sat, Apr 12, 2014 at 11:22 PM, Miro Karpis wrote: > Hi, > I'm trying to make a small benchmarking for warp and scotty (later with > json/no-json text performance test). My client is a Qt c++ application. I > made a minimum code in both Haskell and C++. The problem is the numbers I'm > getting. > If you're not running your Haskell program with "+RTS -A4M" (or for a newer chip even larger, the "4M" should correspond to the size of your L3 cache), please do so. The default of 512k is really too small for most processors in use and will force the runtime into garbage collection before the L3 cache is even consumed. In my benchmarks this flag alone can give you a remarkable improvement. Also, a more fundamental issue: those other tests you mentioned are measuring something different than you are. Those tests use a large number of simultaneous client connections to simulate a busy server, i.e. measuring throughput. Your test makes 10,000 connections serially: you're measuring the server's latency. G -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Sun Apr 13 09:44:49 2014 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Sun, 13 Apr 2014 11:44:49 +0200 Subject: [Haskell-cafe] Docker image for GHC 7.8.2 Message-ID: For people like me who would like to try out 7.8.2, but don't want to make new creative ways of making your system be able to handle multiple ghc/cabal/etc, I created a docker image. Source code, instructions how to build image yourself, or just pull/run it are here: https://bitbucket.org/k_bx/docker-ghc-7.8 Thanks. // I will make a github mirror once hg-git is fixed back by new dulwich lib release soon -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Sun Apr 13 09:57:29 2014 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Sun, 13 Apr 2014 11:57:29 +0200 Subject: [Haskell-cafe] OverloadedLists pattern-matching Message-ID: Continuing playing with OverloadedLists and GHC 7.8.2. For this code: ``` {-# LANGUAGE OverloadedLists #-} {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE TypeFamilies #-} import Data.Map import Data.Text import GHC.Exts instance (Ord k) => IsList (Map k v) where type Item (Map k v) = (k,v) fromList = Data.Map.fromList toList = Data.Map.toList main :: IO () main = do let m = [("foo", 1), ("bar", 2)] :: Map Text Int putStrLn "My map looks like this:" case m of [] -> putStrLn "impossible!" [x,_] -> putStrLn $ "ok, some random elem is: " ++ show x print m ``` I have this output from compiler: ``` root at b575c8a9c84b:~/overloaded_lists# cabal build --ghc-options="-fforce-recomp" Building overloaded-lists-0.1.0.0... Preprocessing executable 'overloaded-lists' for overloaded-lists-0.1.0.0... [1 of 1] Compiling Main ( src/Main.hs, dist/build/overloaded-lists/overloaded-lists-tmp/Main.o ) src/Main.hs:19:5: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: _ src/Main.hs:9:10: Warning: Orphan instance: instance Ord k => IsList (Map k v) [1 of 1] Compiling Main ( src/Main.hs, dist/build/overloaded-lists/overloaded-lists-tmp/Main.o ) src/Main.hs:19:5: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: _ src/Main.hs:9:10: Warning: Orphan instance: instance Ord k => IsList (Map k v) Linking dist/build/overloaded-lists/overloaded-lists ... ``` Couple things: 1. It shows same warnings two times. Is this a bug? 2. It doesn't seem to be that warning that pattern "_" wasn't matched should be there. Should I also create a bug report? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Sun Apr 13 10:01:19 2014 From: ollie at ocharles.org.uk (Oliver Charles) Date: Sun, 13 Apr 2014 11:01:19 +0100 Subject: [Haskell-cafe] OverloadedLists pattern-matching In-Reply-To: References: Message-ID: You have only pattern matched the empty list and a two element list. Perhaps you meant (x : _) to match at least one element? - ocharles On 13 Apr 2014 10:58, "Konstantine Rybnikov" wrote: > Continuing playing with OverloadedLists and GHC 7.8.2. For this code: > > ``` > {-# LANGUAGE OverloadedLists #-} > {-# LANGUAGE OverloadedStrings #-} > {-# LANGUAGE TypeFamilies #-} > > import Data.Map > import Data.Text > import GHC.Exts > > instance (Ord k) => IsList (Map k v) where > type Item (Map k v) = (k,v) > fromList = Data.Map.fromList > toList = Data.Map.toList > > main :: IO () > main = do > let m = [("foo", 1), ("bar", 2)] > :: Map Text Int > putStrLn "My map looks like this:" > case m of > [] -> putStrLn "impossible!" > [x,_] -> putStrLn $ "ok, some random elem is: " ++ show x > > print m > ``` > > I have this output from compiler: > > ``` > root at b575c8a9c84b:~/overloaded_lists# cabal build > --ghc-options="-fforce-recomp" > Building overloaded-lists-0.1.0.0... > Preprocessing executable 'overloaded-lists' for overloaded-lists-0.1.0.0... > [1 of 1] Compiling Main ( src/Main.hs, > dist/build/overloaded-lists/overloaded-lists-tmp/Main.o ) > > src/Main.hs:19:5: Warning: > Pattern match(es) are non-exhaustive > In a case alternative: Patterns not matched: _ > > src/Main.hs:9:10: Warning: > Orphan instance: instance Ord k => IsList (Map k v) > [1 of 1] Compiling Main ( src/Main.hs, > dist/build/overloaded-lists/overloaded-lists-tmp/Main.o ) > > src/Main.hs:19:5: Warning: > Pattern match(es) are non-exhaustive > In a case alternative: Patterns not matched: _ > > src/Main.hs:9:10: Warning: > Orphan instance: instance Ord k => IsList (Map k v) > Linking dist/build/overloaded-lists/overloaded-lists ... > ``` > > Couple things: > > 1. It shows same warnings two times. Is this a bug? > 2. It doesn't seem to be that warning that pattern "_" wasn't matched > should be there. Should I also create a bug report? > > Thank you! > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Sun Apr 13 10:05:23 2014 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Sun, 13 Apr 2014 12:05:23 +0200 Subject: [Haskell-cafe] OverloadedLists pattern-matching In-Reply-To: References: Message-ID: Oh! Right, sorry about that. On Sun, Apr 13, 2014 at 12:01 PM, Oliver Charles wrote: > You have only pattern matched the empty list and a two element list. > Perhaps you meant (x : _) to match at least one element? > > - ocharles > On 13 Apr 2014 10:58, "Konstantine Rybnikov" wrote: > >> Continuing playing with OverloadedLists and GHC 7.8.2. For this code: >> >> ``` >> {-# LANGUAGE OverloadedLists #-} >> {-# LANGUAGE OverloadedStrings #-} >> {-# LANGUAGE TypeFamilies #-} >> >> import Data.Map >> import Data.Text >> import GHC.Exts >> >> instance (Ord k) => IsList (Map k v) where >> type Item (Map k v) = (k,v) >> fromList = Data.Map.fromList >> toList = Data.Map.toList >> >> main :: IO () >> main = do >> let m = [("foo", 1), ("bar", 2)] >> :: Map Text Int >> putStrLn "My map looks like this:" >> case m of >> [] -> putStrLn "impossible!" >> [x,_] -> putStrLn $ "ok, some random elem is: " ++ show x >> >> print m >> ``` >> >> I have this output from compiler: >> >> ``` >> root at b575c8a9c84b:~/overloaded_lists# cabal build >> --ghc-options="-fforce-recomp" >> Building overloaded-lists-0.1.0.0... >> Preprocessing executable 'overloaded-lists' for >> overloaded-lists-0.1.0.0... >> [1 of 1] Compiling Main ( src/Main.hs, >> dist/build/overloaded-lists/overloaded-lists-tmp/Main.o ) >> >> src/Main.hs:19:5: Warning: >> Pattern match(es) are non-exhaustive >> In a case alternative: Patterns not matched: _ >> >> src/Main.hs:9:10: Warning: >> Orphan instance: instance Ord k => IsList (Map k v) >> [1 of 1] Compiling Main ( src/Main.hs, >> dist/build/overloaded-lists/overloaded-lists-tmp/Main.o ) >> >> src/Main.hs:19:5: Warning: >> Pattern match(es) are non-exhaustive >> In a case alternative: Patterns not matched: _ >> >> src/Main.hs:9:10: Warning: >> Orphan instance: instance Ord k => IsList (Map k v) >> Linking dist/build/overloaded-lists/overloaded-lists ... >> ``` >> >> Couple things: >> >> 1. It shows same warnings two times. Is this a bug? >> 2. It doesn't seem to be that warning that pattern "_" wasn't matched >> should be there. Should I also create a bug report? >> >> Thank you! >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Sun Apr 13 10:21:44 2014 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Sun, 13 Apr 2014 12:21:44 +0200 Subject: [Haskell-cafe] OverloadedLists pattern-matching In-Reply-To: References: Message-ID: Just FYI, this still gives a warning: ``` {-# LANGUAGE OverloadedLists #-} {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE ViewPatterns #-} import Data.Map (Map) import qualified Data.Map as M import Data.Text import GHC.Exts instance (Ord k) => IsList (Map k v) where type Item (Map k v) = (k,v) fromList = M.fromList toList = M.toList main :: IO () main = do let m = [("foo", 1), ("bar", 2)] :: Map Text Int putStrLn "My map looks like this:" print m case m of [] -> putStrLn "empty" (M.toList -> (x:_)) -> putStrLn $ "ok, some random elem is: " ++ show x ``` On Sun, Apr 13, 2014 at 12:05 PM, Konstantine Rybnikov wrote: > Oh! Right, sorry about that. > > > On Sun, Apr 13, 2014 at 12:01 PM, Oliver Charles wrote: > >> You have only pattern matched the empty list and a two element list. >> Perhaps you meant (x : _) to match at least one element? >> >> - ocharles >> On 13 Apr 2014 10:58, "Konstantine Rybnikov" wrote: >> >>> Continuing playing with OverloadedLists and GHC 7.8.2. For this code: >>> >>> ``` >>> {-# LANGUAGE OverloadedLists #-} >>> {-# LANGUAGE OverloadedStrings #-} >>> {-# LANGUAGE TypeFamilies #-} >>> >>> import Data.Map >>> import Data.Text >>> import GHC.Exts >>> >>> instance (Ord k) => IsList (Map k v) where >>> type Item (Map k v) = (k,v) >>> fromList = Data.Map.fromList >>> toList = Data.Map.toList >>> >>> main :: IO () >>> main = do >>> let m = [("foo", 1), ("bar", 2)] >>> :: Map Text Int >>> putStrLn "My map looks like this:" >>> case m of >>> [] -> putStrLn "impossible!" >>> [x,_] -> putStrLn $ "ok, some random elem is: " ++ show x >>> >>> print m >>> ``` >>> >>> I have this output from compiler: >>> >>> ``` >>> root at b575c8a9c84b:~/overloaded_lists# cabal build >>> --ghc-options="-fforce-recomp" >>> Building overloaded-lists-0.1.0.0... >>> Preprocessing executable 'overloaded-lists' for >>> overloaded-lists-0.1.0.0... >>> [1 of 1] Compiling Main ( src/Main.hs, >>> dist/build/overloaded-lists/overloaded-lists-tmp/Main.o ) >>> >>> src/Main.hs:19:5: Warning: >>> Pattern match(es) are non-exhaustive >>> In a case alternative: Patterns not matched: _ >>> >>> src/Main.hs:9:10: Warning: >>> Orphan instance: instance Ord k => IsList (Map k v) >>> [1 of 1] Compiling Main ( src/Main.hs, >>> dist/build/overloaded-lists/overloaded-lists-tmp/Main.o ) >>> >>> src/Main.hs:19:5: Warning: >>> Pattern match(es) are non-exhaustive >>> In a case alternative: Patterns not matched: _ >>> >>> src/Main.hs:9:10: Warning: >>> Orphan instance: instance Ord k => IsList (Map k v) >>> Linking dist/build/overloaded-lists/overloaded-lists ... >>> ``` >>> >>> Couple things: >>> >>> 1. It shows same warnings two times. Is this a bug? >>> 2. It doesn't seem to be that warning that pattern "_" wasn't matched >>> should be there. Should I also create a bug report? >>> >>> Thank you! >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at mansionfamily.plus.com Sun Apr 13 10:52:36 2014 From: james at mansionfamily.plus.com (james) Date: Sun, 13 Apr 2014 11:52:36 +0100 Subject: [Haskell-cafe] Handling Windows file name conventions without unix (Posix) package? In-Reply-To: References: Message-ID: <534A6C74.6090500@mansionfamily.plus.com> On 13/04/2014 05:56, Dominick Samperi wrote: > odd file > naming convention under windows (backward vs unix forward slash), > spaces in file names, etc Surely spaces and shell wildcard characters are valid in UNIX filenames too? From roma at ro-che.info Sun Apr 13 11:24:38 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 13 Apr 2014 14:24:38 +0300 Subject: [Haskell-cafe] OverloadedLists pattern-matching In-Reply-To: References: Message-ID: <20140413112438.GA19771@sniper> * Konstantine Rybnikov [2014-04-13 12:21:44+0200] > Just FYI, this still gives a warning: > ... > case m of > [] -> putStrLn "empty" > (M.toList -> (x:_)) -> putStrLn $ "ok, some random elem is: " ++ show x Does that surprise you? The compiler doesn't have any special knowledge about the M.toList function to infer that these two cases are exhaustive. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From dhelta.diaz at gmail.com Sun Apr 13 12:05:53 2014 From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=) Date: Sun, 13 Apr 2014 14:05:53 +0200 Subject: [Haskell-cafe] Patches for (abandoned?) pcre-light In-Reply-To: References: Message-ID: There is no problem with the version of GHC installed. Library pcre-light is importing unsafePerformIO from Foreign, module that doesn't export this function since version 4.7.0.0 of the base package. That causes the build to fail for users of base-4.7.0.0. Importing this function from System.IO.Unsafe solves the problem. I have written to the maintainer as well, but did not received any answer yet. Regards, Daniel D?az. On Sun, Apr 13, 2014 at 3:21 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > please upgrace to 7.8.2 before trying to build anything, theres a *big* > bug in 7.8.1 type checker > > > On Sat, Apr 12, 2014 at 9:09 PM, Nikolay Amiantov wrote: > >> Hello, >> I've tried the new ghc-7.8.1 and have had an issue with building >> pcre-light as one of dependencies for my project. I've made a patch which >> fixes this, but I can't reach maintainer by e-mail -- what can I do in this >> situation? Also, the second (unrelated) question would be: how can I find a >> package which depends on it in my project? I have found no way to dump a >> dependency tree in cabal. >> >> Thanks in advance, >> Nikolay. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dons00 at gmail.com Sun Apr 13 12:11:24 2014 From: dons00 at gmail.com (Don Stewart) Date: Sun, 13 Apr 2014 20:11:24 +0800 Subject: [Haskell-cafe] Patches for (abandoned?) pcre-light In-Reply-To: References: Message-ID: Please update as necessary. I am unable to maintain this package now. On Sunday, 13 April 2014, Daniel D?az Casanueva wrote: > There is no problem with the version of GHC installed. Library pcre-light > is importing unsafePerformIO from Foreign, module that doesn't export this > function since version 4.7.0.0 of the base package. That causes the build > to fail for users of base-4.7.0.0. Importing this function from > System.IO.Unsafe solves the problem. I have written to the maintainer as > well, but did not received any answer yet. > > Regards, > Daniel D?az. > > > On Sun, Apr 13, 2014 at 3:21 AM, Carter Schonwald < > carter.schonwald at gmail.com > > wrote: > >> please upgrace to 7.8.2 before trying to build anything, theres a *big* >> bug in 7.8.1 type checker >> >> >> On Sat, Apr 12, 2014 at 9:09 PM, Nikolay Amiantov >> > wrote: >> >>> Hello, >>> I've tried the new ghc-7.8.1 and have had an issue with building >>> pcre-light as one of dependencies for my project. I've made a patch which >>> fixes this, but I can't reach maintainer by e-mail -- what can I do in this >>> situation? Also, the second (unrelated) question would be: how can I find a >>> package which depends on it in my project? I have found no way to dump a >>> dependency tree in cabal. >>> >>> Thanks in advance, >>> Nikolay. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhelta.diaz at gmail.com Sun Apr 13 12:20:28 2014 From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=) Date: Sun, 13 Apr 2014 14:20:28 +0200 Subject: [Haskell-cafe] Patches for (abandoned?) pcre-light In-Reply-To: References: Message-ID: If given permission, I can submit a new version with the problem fixed. However, this does not mean I would like to become the maintainer. But, yeah, I would like to see a working version uploaded. On Sun, Apr 13, 2014 at 2:11 PM, Don Stewart wrote: > Please update as necessary. I am unable to maintain this package now. > > > On Sunday, 13 April 2014, Daniel D?az Casanueva > wrote: > >> There is no problem with the version of GHC installed. Library pcre-light >> is importing unsafePerformIO from Foreign, module that doesn't export this >> function since version 4.7.0.0 of the base package. That causes the build >> to fail for users of base-4.7.0.0. Importing this function from >> System.IO.Unsafe solves the problem. I have written to the maintainer as >> well, but did not received any answer yet. >> >> Regards, >> Daniel D?az. >> >> >> On Sun, Apr 13, 2014 at 3:21 AM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> please upgrace to 7.8.2 before trying to build anything, theres a *big* >>> bug in 7.8.1 type checker >>> >>> >>> On Sat, Apr 12, 2014 at 9:09 PM, Nikolay Amiantov wrote: >>> >>>> Hello, >>>> I've tried the new ghc-7.8.1 and have had an issue with building >>>> pcre-light as one of dependencies for my project. I've made a patch which >>>> fixes this, but I can't reach maintainer by e-mail -- what can I do in this >>>> situation? Also, the second (unrelated) question would be: how can I find a >>>> package which depends on it in my project? I have found no way to dump a >>>> dependency tree in cabal. >>>> >>>> Thanks in advance, >>>> Nikolay. >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Sun Apr 13 12:48:26 2014 From: ollie at ocharles.org.uk (Oliver Charles) Date: Sun, 13 Apr 2014 13:48:26 +0100 Subject: [Haskell-cafe] OverloadedLists pattern-matching In-Reply-To: <20140413112438.GA19771@sniper> References: <20140413112438.GA19771@sniper> Message-ID: On Sun, Apr 13, 2014 at 12:24 PM, Roman Cheplyaka wrote: > * Konstantine Rybnikov [2014-04-13 12:21:44+0200] >> Just FYI, this still gives a warning: >> ... >> case m of >> [] -> putStrLn "empty" >> (M.toList -> (x:_)) -> putStrLn $ "ok, some random elem is: " ++ show x > > Does that surprise you? The compiler doesn't have any special knowledge about > the M.toList function to infer that these two cases are exhaustive. Roman is right, and I think it's clearer if you consider this without view patterns: case m of [] -> ... m' -> case M.toList m' of (x : _) -> ... Looking at this, it's clear that the patterns are not exhaustive - you didn't match the scenario that M.toList m' produced an empty list. *You* know that M.toList (M.fromList []) == [], but GHC doesn't - and I think this is where the problem lies. With that information you might be able to have exhaustive pattern matches there. - ocharles -------------- next part -------------- An HTML attachment was scrubbed... URL: From dons00 at gmail.com Sun Apr 13 12:56:07 2014 From: dons00 at gmail.com (Don Stewart) Date: Sun, 13 Apr 2014 20:56:07 +0800 Subject: [Haskell-cafe] Patches for (abandoned?) pcre-light In-Reply-To: References: Message-ID: Please proceed. On Sun, Apr 13, 2014 at 8:20 PM, Daniel D?az Casanueva wrote: > If given permission, I can submit a new version with the problem fixed. > However, this does not mean I would like to become the maintainer. But, > yeah, I would like to see a working version uploaded. > > > On Sun, Apr 13, 2014 at 2:11 PM, Don Stewart wrote: >> >> Please update as necessary. I am unable to maintain this package now. >> >> >> On Sunday, 13 April 2014, Daniel D?az Casanueva >> wrote: >>> >>> There is no problem with the version of GHC installed. Library pcre-light >>> is importing unsafePerformIO from Foreign, module that doesn't export this >>> function since version 4.7.0.0 of the base package. That causes the build to >>> fail for users of base-4.7.0.0. Importing this function from >>> System.IO.Unsafe solves the problem. I have written to the maintainer as >>> well, but did not received any answer yet. >>> >>> Regards, >>> Daniel D?az. >>> >>> >>> On Sun, Apr 13, 2014 at 3:21 AM, Carter Schonwald >>> wrote: >>>> >>>> please upgrace to 7.8.2 before trying to build anything, theres a *big* >>>> bug in 7.8.1 type checker >>>> >>>> >>>> On Sat, Apr 12, 2014 at 9:09 PM, Nikolay Amiantov >>>> wrote: >>>>> >>>>> Hello, >>>>> I've tried the new ghc-7.8.1 and have had an issue with building >>>>> pcre-light as one of dependencies for my project. I've made a patch which >>>>> fixes this, but I can't reach maintainer by e-mail -- what can I do in this >>>>> situation? Also, the second (unrelated) question would be: how can I find a >>>>> package which depends on it in my project? I have found no way to dump a >>>>> dependency tree in cabal. >>>>> >>>>> Thanks in advance, >>>>> Nikolay. >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> > From dhelta.diaz at gmail.com Sun Apr 13 13:15:24 2014 From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=) Date: Sun, 13 Apr 2014 15:15:24 +0200 Subject: [Haskell-cafe] Patches for (abandoned?) pcre-light In-Reply-To: References: Message-ID: As soon as I am given upload privileges I will push the fixed version to Hackage. On Sun, Apr 13, 2014 at 2:56 PM, Don Stewart wrote: > Please proceed. > > On Sun, Apr 13, 2014 at 8:20 PM, Daniel D?az Casanueva > wrote: > > If given permission, I can submit a new version with the problem fixed. > > However, this does not mean I would like to become the maintainer. But, > > yeah, I would like to see a working version uploaded. > > > > > > On Sun, Apr 13, 2014 at 2:11 PM, Don Stewart wrote: > >> > >> Please update as necessary. I am unable to maintain this package now. > >> > >> > >> On Sunday, 13 April 2014, Daniel D?az Casanueva > >> wrote: > >>> > >>> There is no problem with the version of GHC installed. Library > pcre-light > >>> is importing unsafePerformIO from Foreign, module that doesn't export > this > >>> function since version 4.7.0.0 of the base package. That causes the > build to > >>> fail for users of base-4.7.0.0. Importing this function from > >>> System.IO.Unsafe solves the problem. I have written to the maintainer > as > >>> well, but did not received any answer yet. > >>> > >>> Regards, > >>> Daniel D?az. > >>> > >>> > >>> On Sun, Apr 13, 2014 at 3:21 AM, Carter Schonwald > >>> wrote: > >>>> > >>>> please upgrace to 7.8.2 before trying to build anything, theres a > *big* > >>>> bug in 7.8.1 type checker > >>>> > >>>> > >>>> On Sat, Apr 12, 2014 at 9:09 PM, Nikolay Amiantov > > >>>> wrote: > >>>>> > >>>>> Hello, > >>>>> I've tried the new ghc-7.8.1 and have had an issue with building > >>>>> pcre-light as one of dependencies for my project. I've made a patch > which > >>>>> fixes this, but I can't reach maintainer by e-mail -- what can I do > in this > >>>>> situation? Also, the second (unrelated) question would be: how can I > find a > >>>>> package which depends on it in my project? I have found no way to > dump a > >>>>> dependency tree in cabal. > >>>>> > >>>>> Thanks in advance, > >>>>> Nikolay. > >>>>> > >>>>> _______________________________________________ > >>>>> Haskell-Cafe mailing list > >>>>> Haskell-Cafe at haskell.org > >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Haskell-Cafe mailing list > >>>> Haskell-Cafe at haskell.org > >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>>> > >>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.stutterheim at me.com Sun Apr 13 13:22:39 2014 From: j.stutterheim at me.com (J. Stutterheim) Date: Sun, 13 Apr 2014 15:22:39 +0200 Subject: [Haskell-cafe] Using GHC.Generics to print data type structure Message-ID: Hi all, I'm trying to use GHC.Generics to print a data type's structure. I have a test type TestRecord: data TestRecord = TestRecord { trId :: Int , someStr :: String } deriving Generic And a PrintDT class: class PrintDT a where printDT :: a -> String default printDT :: (Generic a, GPrintDT (Rep a)) => a -> String printDT = gprintDT . from With a corresponding instance for TestRecord. The GPrintDT class and instances are defined as follows: class GPrintDT f where gprintDT :: f a -> String instance (GPrintDT a, GPrintDT b) => GPrintDT (a :*: b) where gprintDT (x :*: y) = " { " ++ gprintDT x ++ ", " ++ gprintDT y ++ " }" instance (Datatype d, GPrintDT f) => GPrintDT (D1 d f) where gprintDT d = "data " ++ datatypeName d ++ " = " ++ (gprintDT $ unM1 d) instance (Constructor c, GPrintDT f) => GPrintDT (C1 c f) where gprintDT con | conIsRecord con = conName con ++ (gprintDT $ unM1 con) | otherwise = "No record" instance (Selector s, GPrintDT a) => GPrintDT (S1 s a) where gprintDT m = selName m instance (PrintDT a) => GPrintDT (K1 i a) where gprintDT _ = "" instance PrintDT Int where printDT n = show n instance PrintDT String where printDT xs = xs In a first attempt, I apply printDT to a TestRecord value: test1 :: String test1 = printDT (TestRecord 1 "foo") This prints the expected result: "data TestRecord = TestRecord { trId, someStr }" Now ideally, I wouldn't have to specify some value of TestRecord to get this output, since so far, I'm only printing the structure of the TestRecord type, not the values. I would want the following to give me the same result string: test2 :: String test2 = printDT (undefined :: TestRecord) With the current implementation, test2 gives me the following output: "data TestRecord = TestRecord*** Exception: Prelude.undefined Is there a way to implement GPrintDT such that test2 gives me the same output as test1? Thanks! - Jurri?n From sjoerd at w3future.com Sun Apr 13 13:36:06 2014 From: sjoerd at w3future.com (Sjoerd Visscher) Date: Sun, 13 Apr 2014 15:36:06 +0200 Subject: [Haskell-cafe] Using GHC.Generics to print data type structure In-Reply-To: References: Message-ID: <78DCED7C-7DC7-483E-955B-E524322944E9@w3future.com> Make the match on (x :*: y) irrefutable: gprintDT ~(x :*: y) = ? Sjoerd On 13 Apr 2014, at 15:22, J. Stutterheim wrote: > Hi all, > > I'm trying to use GHC.Generics to print a data type's structure. I have a test type TestRecord: > > data TestRecord = TestRecord > { trId :: Int > , someStr :: String } > deriving Generic > > And a PrintDT class: > > class PrintDT a where > printDT :: a -> String > > default printDT :: (Generic a, GPrintDT (Rep a)) => a -> String > printDT = gprintDT . from > > With a corresponding instance for TestRecord. The GPrintDT class and instances are defined as follows: > > class GPrintDT f where > gprintDT :: f a -> String > > instance (GPrintDT a, GPrintDT b) => GPrintDT (a :*: b) where > gprintDT (x :*: y) = " { " ++ gprintDT x ++ ", " ++ gprintDT y ++ " }" > > instance (Datatype d, GPrintDT f) => GPrintDT (D1 d f) where > gprintDT d = "data " ++ datatypeName d ++ " = " ++ (gprintDT $ unM1 d) > > instance (Constructor c, GPrintDT f) => GPrintDT (C1 c f) where > gprintDT con > | conIsRecord con = conName con ++ (gprintDT $ unM1 con) > | otherwise = "No record" > > instance (Selector s, GPrintDT a) => GPrintDT (S1 s a) where > gprintDT m = selName m > > instance (PrintDT a) => GPrintDT (K1 i a) where > gprintDT _ = "" > > instance PrintDT Int where > printDT n = show n > > instance PrintDT String where > printDT xs = xs > > In a first attempt, I apply printDT to a TestRecord value: > > test1 :: String > test1 = printDT (TestRecord 1 "foo") > > This prints the expected result: > > "data TestRecord = TestRecord { trId, someStr }" > > Now ideally, I wouldn't have to specify some value of TestRecord to get this output, since so far, I'm only printing the structure of the TestRecord type, not the values. I would want the following to give me the same result string: > > test2 :: String > test2 = printDT (undefined :: TestRecord) > > With the current implementation, test2 gives me the following output: > > "data TestRecord = TestRecord*** Exception: Prelude.undefined > > Is there a way to implement GPrintDT such that test2 gives me the same output as test1? > > Thanks! > > - Jurri?n > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From capn.freako at gmail.com Sun Apr 13 13:42:32 2014 From: capn.freako at gmail.com (David Banas) Date: Sun, 13 Apr 2014 06:42:32 -0700 Subject: [Haskell-cafe] Trouble splitting up source into multiple files, when using data abstraction. Message-ID: <76F59D2C-BD3A-4240-A85B-7C582D1667D4@gmail.com> Hi all, I?ve defined a typeclass, LogTree, and would like to put each instance definition in its own source file, in order that LogTree.hs not grow to a ridiculous length. I?m attempting to use data abstraction, in order to future-proof the user interface to this class. So, for instance, I don?t make all of the data constructors defined in LogTree accessible, via the module export list, but rather force the user to use certain ?helper? functions, instead. However, the individual instance definitions do need access to these data constructors, but they?re in a different source file. Is this possible? That is, is it possible to provide different export lists to ?friendly? vs. ?unknown? client code? Thanks, -db -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltclifton at gmail.com Sun Apr 13 14:02:39 2014 From: ltclifton at gmail.com (Luke Clifton) Date: Sun, 13 Apr 2014 22:02:39 +0800 Subject: [Haskell-cafe] Trouble splitting up source into multiple files, when using data abstraction. In-Reply-To: <76F59D2C-BD3A-4240-A85B-7C582D1667D4@gmail.com> References: <76F59D2C-BD3A-4240-A85B-7C582D1667D4@gmail.com> Message-ID: Hi David, I think you can do something like providing a LogTree.Internal module which you use internally and which exports everything you need, and making your LogTree module which re-exports only the safe subset which "unknown" code would then import. I don't think there is a way of stopping anyone from importing your LogTree.Internal module though. On Sun, Apr 13, 2014 at 9:42 PM, David Banas wrote: > Hi all, > > I?ve defined a typeclass, *LogTree*, and would like to put each instance > definition in its own source file, in order that *LogTree.hs *not grow to > a ridiculous length. > I?m attempting to use data abstraction, in order to future-proof the user > interface to this class. > So, for instance, I don?t make all of the data constructors defined in > LogTree accessible, via the module export list, but rather force the user > to use certain ?helper? functions, instead. > However, the individual instance definitions *do* need access to these > data constructors, but they?re in a different source file. > > *Is this possible? That is, is it possible to provide different export > lists to ?friendly? vs. ?unknown? client code?* > > Thanks, > -db > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Apr 13 14:03:57 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 13 Apr 2014 10:03:57 -0400 Subject: [Haskell-cafe] Trouble splitting up source into multiple files, when using data abstraction. In-Reply-To: <76F59D2C-BD3A-4240-A85B-7C582D1667D4@gmail.com> References: <76F59D2C-BD3A-4240-A85B-7C582D1667D4@gmail.com> Message-ID: On Sun, Apr 13, 2014 at 9:42 AM, David Banas wrote: > *Is this possible? That is, is it possible to provide different export > lists to ?friendly? vs. ?unknown? client code?* > Not directly. The usual convention is you put all your definitions in a .Internal module which is understood to be intended only for restricted use, although there is currently no way to enforce this; the public module(s) then imports that and re-exports the public interface. It might be interesting to have some way to enforce this, possibly by a generalization of the Safe mechanism. It's not clear how well this can be enforced, in any case; if it's available across modules at all, there will be some way for "untrusted" code to get at it. I'm not sure anyone wants to pay the costs of complexity (in particular of cross-platform, which is already somewhat dicey at times) or limited flexibility to provide harder guarantees; in particular, there are times when you really do need access to another package's internals, with the result that some packages that used to hide their internals completely are now starting to export Internals modules. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Sun Apr 13 14:08:30 2014 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Sun, 13 Apr 2014 16:08:30 +0200 Subject: [Haskell-cafe] OverloadedLists pattern-matching In-Reply-To: References: <20140413112438.GA19771@sniper> Message-ID: Thanks, you and Roman are right. On Sun, Apr 13, 2014 at 2:48 PM, Oliver Charles wrote: > On Sun, Apr 13, 2014 at 12:24 PM, Roman Cheplyaka > wrote: > > * Konstantine Rybnikov [2014-04-13 12:21:44+0200] > >> Just FYI, this still gives a warning: > >> ... > >> case m of > >> [] -> putStrLn "empty" > >> (M.toList -> (x:_)) -> putStrLn $ "ok, some random elem is: " ++ > show x > > > > Does that surprise you? The compiler doesn't have any special knowledge > about > > the M.toList function to infer that these two cases are exhaustive. > > Roman is right, and I think it's clearer if you consider this without view > patterns: > > case m of > [] -> ... > m' -> case M.toList m' of > (x : _) -> ... > > Looking at this, it's clear that the patterns are not exhaustive - you > didn't match the scenario that M.toList m' produced an empty list. > > *You* know that M.toList (M.fromList []) == [], but GHC doesn't - and I > think this is where the problem lies. With that information you might be > able to have exhaustive pattern matches there. > > - ocharles > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.stutterheim at me.com Sun Apr 13 14:15:51 2014 From: j.stutterheim at me.com (J. Stutterheim) Date: Sun, 13 Apr 2014 16:15:51 +0200 Subject: [Haskell-cafe] Using GHC.Generics to print data type structure In-Reply-To: <78DCED7C-7DC7-483E-955B-E524322944E9@w3future.com> References: <78DCED7C-7DC7-483E-955B-E524322944E9@w3future.com> Message-ID: <72346090-0B2E-4B27-B008-6C584EB19EF0@me.com> Short, simple, thanks! Works like a charm. - Jurri?n On 13 Apr 2014, at 15:36, Sjoerd Visscher wrote: > Make the match on (x :*: y) irrefutable: > > gprintDT ~(x :*: y) = ? > > Sjoerd > > On 13 Apr 2014, at 15:22, J. Stutterheim wrote: > >> Hi all, >> >> I'm trying to use GHC.Generics to print a data type's structure. I have a test type TestRecord: >> >> data TestRecord = TestRecord >> { trId :: Int >> , someStr :: String } >> deriving Generic >> >> And a PrintDT class: >> >> class PrintDT a where >> printDT :: a -> String >> >> default printDT :: (Generic a, GPrintDT (Rep a)) => a -> String >> printDT = gprintDT . from >> >> With a corresponding instance for TestRecord. The GPrintDT class and instances are defined as follows: >> >> class GPrintDT f where >> gprintDT :: f a -> String >> >> instance (GPrintDT a, GPrintDT b) => GPrintDT (a :*: b) where >> gprintDT (x :*: y) = " { " ++ gprintDT x ++ ", " ++ gprintDT y ++ " }" >> >> instance (Datatype d, GPrintDT f) => GPrintDT (D1 d f) where >> gprintDT d = "data " ++ datatypeName d ++ " = " ++ (gprintDT $ unM1 d) >> >> instance (Constructor c, GPrintDT f) => GPrintDT (C1 c f) where >> gprintDT con >> | conIsRecord con = conName con ++ (gprintDT $ unM1 con) >> | otherwise = "No record" >> >> instance (Selector s, GPrintDT a) => GPrintDT (S1 s a) where >> gprintDT m = selName m >> >> instance (PrintDT a) => GPrintDT (K1 i a) where >> gprintDT _ = "" >> >> instance PrintDT Int where >> printDT n = show n >> >> instance PrintDT String where >> printDT xs = xs >> >> In a first attempt, I apply printDT to a TestRecord value: >> >> test1 :: String >> test1 = printDT (TestRecord 1 "foo") >> >> This prints the expected result: >> >> "data TestRecord = TestRecord { trId, someStr }" >> >> Now ideally, I wouldn't have to specify some value of TestRecord to get this output, since so far, I'm only printing the structure of the TestRecord type, not the values. I would want the following to give me the same result string: >> >> test2 :: String >> test2 = printDT (undefined :: TestRecord) >> >> With the current implementation, test2 gives me the following output: >> >> "data TestRecord = TestRecord*** Exception: Prelude.undefined >> >> Is there a way to implement GPrintDT such that test2 gives me the same output as test1? >> >> Thanks! >> >> - Jurri?n >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > From adam at bergmark.nl Sun Apr 13 16:38:05 2014 From: adam at bergmark.nl (Adam Bergmark) Date: Sun, 13 Apr 2014 18:38:05 +0200 Subject: [Haskell-cafe] Simple OverloadedLists question In-Reply-To: References: Message-ID: The containers package doesn't have these instances, you may want to open up an issue for it [1] - Adam [1] https://github.com/haskell/containers On Sun, Apr 13, 2014 at 11:07 AM, Konstantine Rybnikov wrote: > > On Sun, Apr 13, 2014 at 10:45 AM, Konstantine Rybnikov wrote: > >> Hi! >> >> I wanted to check out great new OverloadedLists [0] feature, but got an >> error as in [1]. >> >> What am I doing wrong? >> >> Thanks. >> >> [0]: >> https://www.haskell.org/ghc/docs/7.8.1/html/users_guide/type-class-extensions.html#overloaded-lists >> [1]: https://gist.github.com/k-bx/10574806 >> >> > Just FYI, IRC-user @Hermit fixed it by adding IsList instance to Map. > > https://gist.github.com/Arm/10575474 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucas.dicioccio at gmail.com Sun Apr 13 18:15:09 2014 From: lucas.dicioccio at gmail.com (lucas di cioccio) Date: Sun, 13 Apr 2014 20:15:09 +0200 Subject: [Haskell-cafe] warp vs scotty + some benchmark numbers In-Reply-To: References: Message-ID: Hi Miro, As Gregory pointed, you should use a web-benchmark tool rather than rolling your own (e.g., weighttp). If you intend to run benchmarks and play with many parameters, I'd recommend to use a framework to handle the experiments (I'm selling my magic potion here :P). I've wrapped the weighttp client to benchmark the mighty web servers in these Laborantin experiments: - https://github.com/lucasdicioccio/laborantin-bench-web >From the results I got on my server, mighty handles from ~8K req/s to ~50K req/s depending on the input parameters of the server and of the measuring client. I'm not bragging that my server is beefy, but I report these results to show that results vary a lot with the methodology. Hence, take care and explore many operating points =). Feel free to contribute a Scotty / Warp wrapper (or wait until I find time to make these myself). Gregory, thanks for the -A4M tip, I wasn't aware of it. I'll patch my experiments with an extra parameter too =). Best, --Lucas 2014-04-13 11:38 GMT+02:00 Gregory Collins : > On Sat, Apr 12, 2014 at 11:22 PM, Miro Karpis wrote: > >> Hi, >> I'm trying to make a small benchmarking for warp and scotty (later with >> json/no-json text performance test). My client is a Qt c++ application. I >> made a minimum code in both Haskell and C++. The problem is the numbers I'm >> getting. >> > > If you're not running your Haskell program with "+RTS -A4M" (or for a > newer chip even larger, the "4M" should correspond to the size of your L3 > cache), please do so. The default of 512k is really too small for most > processors in use and will force the runtime into garbage collection before > the L3 cache is even consumed. In my benchmarks this flag alone can give > you a remarkable improvement. > > Also, a more fundamental issue: those other tests you mentioned are > measuring something different than you are. Those tests use a large number > of simultaneous client connections to simulate a busy server, i.e. > measuring throughput. Your test makes 10,000 connections serially: you're > measuring the server's latency. > > G > -- > Gregory Collins > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From J.T.Jeuring at uu.nl Sun Apr 13 19:11:10 2014 From: J.T.Jeuring at uu.nl (Johan Jeuring) Date: Sun, 13 Apr 2014 21:11:10 +0200 Subject: [Haskell-cafe] Video chair at ICFP Message-ID: <9DD5E6B8-09E6-4E20-B3B6-665F1C09DEEC@uu.nl> Dear people, We are busy organising ICFP 2014, which will happen together with the Haskell Symposium and many other events in G?teborg in Sweden from August 31 until September 6 2014. I am looking for a Video chair to organise the recording of the events on video. Tasks - prepare the video recording of the events: equipment (camera's, software, microphones?), required post-processing, ... - instruct student-volunteers in assisting the recording process - oversee the post-processing of the recordings, and the uploads Budget - we have some budget available for buying or renting equipment for the video recordings, or we can pay you for you bringing your own equipment - we will defray your costs for travelling to G?teborg, staying in G?teborg, and attending ICFP 2014 and affiliated events Please contact me if you are interested in this position/task, With kind regards, Johan Jeuring General chair for ICFP 2014 From roma at ro-che.info Sun Apr 13 21:28:12 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 14 Apr 2014 00:28:12 +0300 Subject: [Haskell-cafe] Video chair at ICFP In-Reply-To: <9DD5E6B8-09E6-4E20-B3B6-665F1C09DEEC@uu.nl> References: <9DD5E6B8-09E6-4E20-B3B6-665F1C09DEEC@uu.nl> Message-ID: <20140413212812.GA18973@sniper> BTW, does anyone know who Video chair at ICFP'13 was, and whether/when the videos will be available? Roman From roma at ro-che.info Sun Apr 13 21:33:14 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 14 Apr 2014 00:33:14 +0300 Subject: [Haskell-cafe] ANN: haskell-src-exts-1.15.0 Message-ID: <20140413213314.GA19568@sniper> I'm pleased to announce the release of haskell-src-exts-1.15.0! Hackage: https://hackage.haskell.org/package/haskell-src-exts-1.15.0 GitHub: https://github.com/haskell-suite/haskell-src-exts Changes from the last 1.14.0.1 release: * Add support for extensions: - MultiWayIf - LambdaCase - DataKinds * Remove support for old (deprecated) Generics * Derive GHC's Generic instances for datatypes * Derive some missing Data and Typeable instances * Many bug fixes * Add missing Functor and Applicative instances for monads * Remove support for GHCs older than 7.4 This release is brought to you by: Adam Vogt Andr?s Sicard-Ram?rez Ben Gamari Daniel Oom Danylo Hlynskyi Michael Sloan Neil Mitchell Niklas Broberg Niklas Hamb?chen Philipp Schuster phischu Roman Cheplyaka Stefan Wehr Stijn van Drongelen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From trebla at vex.net Sun Apr 13 21:33:09 2014 From: trebla at vex.net (Albert Y. C. Lai) Date: Sun, 13 Apr 2014 17:33:09 -0400 Subject: [Haskell-cafe] Handling Windows file name conventions without unix (Posix) package? In-Reply-To: References: Message-ID: <534B0295.2010703@vex.net> On 14-04-13 12:56 AM, Dominick Samperi wrote: > The unix package (System.Posix) is not supported under Windows and > I wonder if there is an alternative solution that deals with the odd file > naming convention under windows (backward vs unix forward slash), > spaces in file names, etc. module System.FilePath is a common interface providing the right thing for the hosting OS. It comes with GHC. For example you can use the operator without worry. From jwlato at gmail.com Mon Apr 14 00:00:07 2014 From: jwlato at gmail.com (John Lato) Date: Sun, 13 Apr 2014 17:00:07 -0700 Subject: [Haskell-cafe] Trouble splitting up source into multiple files, when using data abstraction. In-Reply-To: References: <76F59D2C-BD3A-4240-A85B-7C582D1667D4@gmail.com> Message-ID: It's possible to restrict LogTree.Internal to be visible only within the package (see cabal's other-modules field), but please don't do so. You will inevitably fail at providing every necessary function or accommodating all reasonable uses of your library. Then some user will either write their own, use something else or, if you're lucky, fork your library and send you a merge request. It will happen (unless you have no other users). As a recent example, I was using a library that had an internal data structure, 'A' (completely unexposed) as part of an exposed data structure 'B'. Both had 'deriving Generic' clauses. However, the Generic instance of 'B' was mostly useless because if you wanted to use the Generic instance to declare e.g. 'instance Binary B', it's also necessary to create a Binary instance for 'A'. Which was impossible for users, because 'A' was completely unexposed. When I pointed this out, the library's author graciously accepted a patch to expose the type constructor 'A' (I'm not entirely happy with this solution either, but for now we can't think of anything better). You could take this as an implementation flaw of Generic as it's currently implemented (which it possibly is), however I would hope you also take it as a demonstration of how data abstraction can interact with many different language features in often-subtle ways. I think erring on the side of allowing users maximum freedom is the best choice for now (preferably stashed in modules/functions with names like 'internal' or 'unsafe'). John On Sun, Apr 13, 2014 at 7:02 AM, Luke Clifton wrote: > Hi David, > > I think you can do something like providing a LogTree.Internal module > which you use internally and which exports everything you need, and making > your LogTree module which re-exports only the safe subset which "unknown" > code would then import. I don't think there is a way of stopping anyone > from importing your LogTree.Internal module though. > > > > On Sun, Apr 13, 2014 at 9:42 PM, David Banas wrote: > >> Hi all, >> >> I've defined a typeclass, *LogTree*, and would like to put each instance >> definition in its own source file, in order that *LogTree.hs *not grow >> to a ridiculous length. >> I'm attempting to use data abstraction, in order to future-proof the user >> interface to this class. >> So, for instance, I don't make all of the data constructors defined in >> LogTree accessible, via the module export list, but rather force the user >> to use certain "helper" functions, instead. >> However, the individual instance definitions *do* need access to these >> data constructors, but they're in a different source file. >> >> *Is this possible? That is, is it possible to provide different export >> lists to "friendly" vs. "unknown" client code?* >> >> Thanks, >> -db >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidleothomas at gmail.com Mon Apr 14 00:22:23 2014 From: davidleothomas at gmail.com (David Thomas) Date: Sun, 13 Apr 2014 17:22:23 -0700 Subject: [Haskell-cafe] Trouble splitting up source into multiple files, when using data abstraction. In-Reply-To: References: <76F59D2C-BD3A-4240-A85B-7C582D1667D4@gmail.com> Message-ID: A concern, to be sure. On the flip side, it might be better to know what you are actually exposing (also meaning fewer things would constitute a breaking change). On Apr 13, 2014 5:00 PM, "John Lato" wrote: > It's possible to restrict LogTree.Internal to be visible only within the > package (see cabal's other-modules field), but please don't do so. You > will inevitably fail at providing every necessary function or accommodating > all reasonable uses of your library. Then some user will either write > their own, use something else or, if you're lucky, fork your library and > send you a merge request. It will happen (unless you have no other users). > > As a recent example, I was using a library that had an internal data > structure, 'A' (completely unexposed) as part of an exposed data structure > 'B'. Both had 'deriving Generic' clauses. However, the Generic instance > of 'B' was mostly useless because if you wanted to use the Generic instance > to declare e.g. 'instance Binary B', it's also necessary to create a Binary > instance for 'A'. Which was impossible for users, because 'A' was > completely unexposed. When I pointed this out, the library's author > graciously accepted a patch to expose the type constructor 'A' (I'm not > entirely happy with this solution either, but for now we can't think of > anything better). > > You could take this as an implementation flaw of Generic as it's currently > implemented (which it possibly is), however I would hope you also take it > as a demonstration of how data abstraction can interact with many different > language features in often-subtle ways. I think erring on the side of > allowing users maximum freedom is the best choice for now (preferably > stashed in modules/functions with names like 'internal' or 'unsafe'). > > John > > > On Sun, Apr 13, 2014 at 7:02 AM, Luke Clifton wrote: > >> Hi David, >> >> I think you can do something like providing a LogTree.Internal module >> which you use internally and which exports everything you need, and making >> your LogTree module which re-exports only the safe subset which "unknown" >> code would then import. I don't think there is a way of stopping anyone >> from importing your LogTree.Internal module though. >> >> >> >> On Sun, Apr 13, 2014 at 9:42 PM, David Banas wrote: >> >>> Hi all, >>> >>> I've defined a typeclass, *LogTree*, and would like to put each >>> instance definition in its own source file, in order that *LogTree.hs *not >>> grow to a ridiculous length. >>> I'm attempting to use data abstraction, in order to future-proof the >>> user interface to this class. >>> So, for instance, I don't make all of the data constructors defined in >>> LogTree accessible, via the module export list, but rather force the user >>> to use certain "helper" functions, instead. >>> However, the individual instance definitions *do* need access to these >>> data constructors, but they're in a different source file. >>> >>> *Is this possible? That is, is it possible to provide different export >>> lists to "friendly" vs. "unknown" client code?* >>> >>> Thanks, >>> -db >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Mon Apr 14 00:25:51 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 14 Apr 2014 10:25:51 +1000 Subject: [Haskell-cafe] Trouble splitting up source into multiple files, when using data abstraction. In-Reply-To: References: <76F59D2C-BD3A-4240-A85B-7C582D1667D4@gmail.com> Message-ID: On 14 April 2014 10:22, David Thomas wrote: > A concern, to be sure. On the flip side, it might be better to know what > you are actually exposing (also meaning fewer things would constitute a > breaking change). There is the convention that "if it's in a .Internal module, then you're on your own: this module doesn't contribute towards breaking changes in the API". > > On Apr 13, 2014 5:00 PM, "John Lato" wrote: >> >> It's possible to restrict LogTree.Internal to be visible only within the >> package (see cabal's other-modules field), but please don't do so. You will >> inevitably fail at providing every necessary function or accommodating all >> reasonable uses of your library. Then some user will either write their >> own, use something else or, if you're lucky, fork your library and send you >> a merge request. It will happen (unless you have no other users). >> >> As a recent example, I was using a library that had an internal data >> structure, 'A' (completely unexposed) as part of an exposed data structure >> 'B'. Both had 'deriving Generic' clauses. However, the Generic instance of >> 'B' was mostly useless because if you wanted to use the Generic instance to >> declare e.g. 'instance Binary B', it's also necessary to create a Binary >> instance for 'A'. Which was impossible for users, because 'A' was >> completely unexposed. When I pointed this out, the library's author >> graciously accepted a patch to expose the type constructor 'A' (I'm not >> entirely happy with this solution either, but for now we can't think of >> anything better). >> >> You could take this as an implementation flaw of Generic as it's currently >> implemented (which it possibly is), however I would hope you also take it as >> a demonstration of how data abstraction can interact with many different >> language features in often-subtle ways. I think erring on the side of >> allowing users maximum freedom is the best choice for now (preferably >> stashed in modules/functions with names like 'internal' or 'unsafe'). >> >> John >> >> >> On Sun, Apr 13, 2014 at 7:02 AM, Luke Clifton wrote: >>> >>> Hi David, >>> >>> I think you can do something like providing a LogTree.Internal module >>> which you use internally and which exports everything you need, and making >>> your LogTree module which re-exports only the safe subset which "unknown" >>> code would then import. I don't think there is a way of stopping anyone from >>> importing your LogTree.Internal module though. >>> >>> >>> >>> On Sun, Apr 13, 2014 at 9:42 PM, David Banas >>> wrote: >>>> >>>> Hi all, >>>> >>>> I?ve defined a typeclass, LogTree, and would like to put each instance >>>> definition in its own source file, in order that LogTree.hs not grow to a >>>> ridiculous length. >>>> I?m attempting to use data abstraction, in order to future-proof the >>>> user interface to this class. >>>> So, for instance, I don?t make all of the data constructors defined in >>>> LogTree accessible, via the module export list, but rather force the user to >>>> use certain ?helper? functions, instead. >>>> However, the individual instance definitions do need access to these >>>> data constructors, but they?re in a different source file. >>>> >>>> Is this possible? That is, is it possible to provide different export >>>> lists to ?friendly? vs. ?unknown? client code? >>>> >>>> Thanks, >>>> -db >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From carter.schonwald at gmail.com Mon Apr 14 00:27:51 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 13 Apr 2014 20:27:51 -0400 Subject: [Haskell-cafe] Trouble splitting up source into multiple files, when using data abstraction. In-Reply-To: References: <76F59D2C-BD3A-4240-A85B-7C582D1667D4@gmail.com> Message-ID: yup! its accepted convention by the community that *.Internal Modules are not subject to ANY API stability guarantees (kinda like the GHC apis :) ) On Sun, Apr 13, 2014 at 8:25 PM, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > On 14 April 2014 10:22, David Thomas wrote: > > A concern, to be sure. On the flip side, it might be better to know what > > you are actually exposing (also meaning fewer things would constitute a > > breaking change). > > There is the convention that "if it's in a .Internal module, then > you're on your own: this module doesn't contribute towards breaking > changes in the API". > > > > > On Apr 13, 2014 5:00 PM, "John Lato" wrote: > >> > >> It's possible to restrict LogTree.Internal to be visible only within the > >> package (see cabal's other-modules field), but please don't do so. You > will > >> inevitably fail at providing every necessary function or accommodating > all > >> reasonable uses of your library. Then some user will either write their > >> own, use something else or, if you're lucky, fork your library and send > you > >> a merge request. It will happen (unless you have no other users). > >> > >> As a recent example, I was using a library that had an internal data > >> structure, 'A' (completely unexposed) as part of an exposed data > structure > >> 'B'. Both had 'deriving Generic' clauses. However, the Generic > instance of > >> 'B' was mostly useless because if you wanted to use the Generic > instance to > >> declare e.g. 'instance Binary B', it's also necessary to create a Binary > >> instance for 'A'. Which was impossible for users, because 'A' was > >> completely unexposed. When I pointed this out, the library's author > >> graciously accepted a patch to expose the type constructor 'A' (I'm not > >> entirely happy with this solution either, but for now we can't think of > >> anything better). > >> > >> You could take this as an implementation flaw of Generic as it's > currently > >> implemented (which it possibly is), however I would hope you also take > it as > >> a demonstration of how data abstraction can interact with many different > >> language features in often-subtle ways. I think erring on the side of > >> allowing users maximum freedom is the best choice for now (preferably > >> stashed in modules/functions with names like 'internal' or 'unsafe'). > >> > >> John > >> > >> > >> On Sun, Apr 13, 2014 at 7:02 AM, Luke Clifton > wrote: > >>> > >>> Hi David, > >>> > >>> I think you can do something like providing a LogTree.Internal module > >>> which you use internally and which exports everything you need, and > making > >>> your LogTree module which re-exports only the safe subset which > "unknown" > >>> code would then import. I don't think there is a way of stopping > anyone from > >>> importing your LogTree.Internal module though. > >>> > >>> > >>> > >>> On Sun, Apr 13, 2014 at 9:42 PM, David Banas > >>> wrote: > >>>> > >>>> Hi all, > >>>> > >>>> I?ve defined a typeclass, LogTree, and would like to put each instance > >>>> definition in its own source file, in order that LogTree.hs not grow > to a > >>>> ridiculous length. > >>>> I?m attempting to use data abstraction, in order to future-proof the > >>>> user interface to this class. > >>>> So, for instance, I don?t make all of the data constructors defined in > >>>> LogTree accessible, via the module export list, but rather force the > user to > >>>> use certain ?helper? functions, instead. > >>>> However, the individual instance definitions do need access to these > >>>> data constructors, but they?re in a different source file. > >>>> > >>>> Is this possible? That is, is it possible to provide different export > >>>> lists to ?friendly? vs. ?unknown? client code? > >>>> > >>>> Thanks, > >>>> -db > >>>> > >>>> > >>>> _______________________________________________ > >>>> Haskell-Cafe mailing list > >>>> Haskell-Cafe at haskell.org > >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> Haskell-Cafe at haskell.org > >>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>> > >> > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidleothomas at gmail.com Mon Apr 14 00:30:10 2014 From: davidleothomas at gmail.com (David Thomas) Date: Sun, 13 Apr 2014 17:30:10 -0700 Subject: [Haskell-cafe] Trouble splitting up source into multiple files, when using data abstraction. In-Reply-To: References: <76F59D2C-BD3A-4240-A85B-7C582D1667D4@gmail.com> Message-ID: Fair enough! Seems still a good practice to get any functionality you're using into the stable API, but certainly being able to get things done in the meanwhile is not a bad thing. On Apr 13, 2014 5:28 PM, "Carter Schonwald" wrote: > yup! > > its accepted convention by the community that *.Internal Modules are not > subject to ANY API stability guarantees (kinda like the GHC apis :) ) > > > On Sun, Apr 13, 2014 at 8:25 PM, Ivan Lazar Miljenovic < > ivan.miljenovic at gmail.com> wrote: > >> On 14 April 2014 10:22, David Thomas wrote: >> > A concern, to be sure. On the flip side, it might be better to know >> what >> > you are actually exposing (also meaning fewer things would constitute a >> > breaking change). >> >> There is the convention that "if it's in a .Internal module, then >> you're on your own: this module doesn't contribute towards breaking >> changes in the API". >> >> > >> > On Apr 13, 2014 5:00 PM, "John Lato" wrote: >> >> >> >> It's possible to restrict LogTree.Internal to be visible only within >> the >> >> package (see cabal's other-modules field), but please don't do so. >> You will >> >> inevitably fail at providing every necessary function or accommodating >> all >> >> reasonable uses of your library. Then some user will either write >> their >> >> own, use something else or, if you're lucky, fork your library and >> send you >> >> a merge request. It will happen (unless you have no other users). >> >> >> >> As a recent example, I was using a library that had an internal data >> >> structure, 'A' (completely unexposed) as part of an exposed data >> structure >> >> 'B'. Both had 'deriving Generic' clauses. However, the Generic >> instance of >> >> 'B' was mostly useless because if you wanted to use the Generic >> instance to >> >> declare e.g. 'instance Binary B', it's also necessary to create a >> Binary >> >> instance for 'A'. Which was impossible for users, because 'A' was >> >> completely unexposed. When I pointed this out, the library's author >> >> graciously accepted a patch to expose the type constructor 'A' (I'm not >> >> entirely happy with this solution either, but for now we can't think of >> >> anything better). >> >> >> >> You could take this as an implementation flaw of Generic as it's >> currently >> >> implemented (which it possibly is), however I would hope you also take >> it as >> >> a demonstration of how data abstraction can interact with many >> different >> >> language features in often-subtle ways. I think erring on the side of >> >> allowing users maximum freedom is the best choice for now (preferably >> >> stashed in modules/functions with names like 'internal' or 'unsafe'). >> >> >> >> John >> >> >> >> >> >> On Sun, Apr 13, 2014 at 7:02 AM, Luke Clifton >> wrote: >> >>> >> >>> Hi David, >> >>> >> >>> I think you can do something like providing a LogTree.Internal module >> >>> which you use internally and which exports everything you need, and >> making >> >>> your LogTree module which re-exports only the safe subset which >> "unknown" >> >>> code would then import. I don't think there is a way of stopping >> anyone from >> >>> importing your LogTree.Internal module though. >> >>> >> >>> >> >>> >> >>> On Sun, Apr 13, 2014 at 9:42 PM, David Banas >> >>> wrote: >> >>>> >> >>>> Hi all, >> >>>> >> >>>> I've defined a typeclass, LogTree, and would like to put each >> instance >> >>>> definition in its own source file, in order that LogTree.hs not grow >> to a >> >>>> ridiculous length. >> >>>> I'm attempting to use data abstraction, in order to future-proof the >> >>>> user interface to this class. >> >>>> So, for instance, I don't make all of the data constructors defined >> in >> >>>> LogTree accessible, via the module export list, but rather force the >> user to >> >>>> use certain "helper" functions, instead. >> >>>> However, the individual instance definitions do need access to these >> >>>> data constructors, but they're in a different source file. >> >>>> >> >>>> Is this possible? That is, is it possible to provide different export >> >>>> lists to "friendly" vs. "unknown" client code? >> >>>> >> >>>> Thanks, >> >>>> -db >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Haskell-Cafe mailing list >> >>>> Haskell-Cafe at haskell.org >> >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >>>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Haskell-Cafe mailing list >> >>> Haskell-Cafe at haskell.org >> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >>> >> >> >> >> >> >> _______________________________________________ >> >> Haskell-Cafe mailing list >> >> Haskell-Cafe at haskell.org >> >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe at haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Mon Apr 14 09:00:40 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 14 Apr 2014 11:00:40 +0200 Subject: [Haskell-cafe] Using GHC.Generics to print data type structure In-Reply-To: <72346090-0B2E-4B27-B008-6C584EB19EF0@me.com> References: <78DCED7C-7DC7-483E-955B-E524322944E9@w3future.com> <72346090-0B2E-4B27-B008-6C584EB19EF0@me.com> Message-ID: Instead of passing 'undefined :: a', I think the current best practice is to pass 'Proxy :: Proxy a' (or in fact 'proxy a', i.e. be polymorphic in the proxy). This way you can never accidentally use the undefined value. Erik On Sun, Apr 13, 2014 at 4:15 PM, J. Stutterheim wrote: > Short, simple, thanks! Works like a charm. > > - Jurri?n > > On 13 Apr 2014, at 15:36, Sjoerd Visscher wrote: > >> Make the match on (x :*: y) irrefutable: >> >> gprintDT ~(x :*: y) = ... >> >> Sjoerd >> >> On 13 Apr 2014, at 15:22, J. Stutterheim wrote: >> >>> Hi all, >>> >>> I'm trying to use GHC.Generics to print a data type's structure. I have a test type TestRecord: >>> >>> data TestRecord = TestRecord >>> { trId :: Int >>> , someStr :: String } >>> deriving Generic >>> >>> And a PrintDT class: >>> >>> class PrintDT a where >>> printDT :: a -> String >>> >>> default printDT :: (Generic a, GPrintDT (Rep a)) => a -> String >>> printDT = gprintDT . from >>> >>> With a corresponding instance for TestRecord. The GPrintDT class and instances are defined as follows: >>> >>> class GPrintDT f where >>> gprintDT :: f a -> String >>> >>> instance (GPrintDT a, GPrintDT b) => GPrintDT (a :*: b) where >>> gprintDT (x :*: y) = " { " ++ gprintDT x ++ ", " ++ gprintDT y ++ " }" >>> >>> instance (Datatype d, GPrintDT f) => GPrintDT (D1 d f) where >>> gprintDT d = "data " ++ datatypeName d ++ " = " ++ (gprintDT $ unM1 d) >>> >>> instance (Constructor c, GPrintDT f) => GPrintDT (C1 c f) where >>> gprintDT con >>> | conIsRecord con = conName con ++ (gprintDT $ unM1 con) >>> | otherwise = "No record" >>> >>> instance (Selector s, GPrintDT a) => GPrintDT (S1 s a) where >>> gprintDT m = selName m >>> >>> instance (PrintDT a) => GPrintDT (K1 i a) where >>> gprintDT _ = "" >>> >>> instance PrintDT Int where >>> printDT n = show n >>> >>> instance PrintDT String where >>> printDT xs = xs >>> >>> In a first attempt, I apply printDT to a TestRecord value: >>> >>> test1 :: String >>> test1 = printDT (TestRecord 1 "foo") >>> >>> This prints the expected result: >>> >>> "data TestRecord = TestRecord { trId, someStr }" >>> >>> Now ideally, I wouldn't have to specify some value of TestRecord to get this output, since so far, I'm only printing the structure of the TestRecord type, not the values. I would want the following to give me the same result string: >>> >>> test2 :: String >>> test2 = printDT (undefined :: TestRecord) >>> >>> With the current implementation, test2 gives me the following output: >>> >>> "data TestRecord = TestRecord*** Exception: Prelude.undefined >>> >>> Is there a way to implement GPrintDT such that test2 gives me the same output as test1? >>> >>> Thanks! >>> >>> - Jurri?n >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From hesselink at gmail.com Mon Apr 14 09:48:53 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 14 Apr 2014 11:48:53 +0200 Subject: [Haskell-cafe] Patches for (abandoned?) pcre-light In-Reply-To: References: Message-ID: I've added you to the maintainers of pcre-light. Regards, Erik On Sun, Apr 13, 2014 at 3:15 PM, Daniel D?az Casanueva wrote: > As soon as I am given upload privileges I will push the fixed version to > Hackage. > > > On Sun, Apr 13, 2014 at 2:56 PM, Don Stewart wrote: >> >> Please proceed. >> >> On Sun, Apr 13, 2014 at 8:20 PM, Daniel D?az Casanueva >> wrote: >> > If given permission, I can submit a new version with the problem fixed. >> > However, this does not mean I would like to become the maintainer. But, >> > yeah, I would like to see a working version uploaded. >> > >> > >> > On Sun, Apr 13, 2014 at 2:11 PM, Don Stewart wrote: >> >> >> >> Please update as necessary. I am unable to maintain this package now. >> >> >> >> >> >> On Sunday, 13 April 2014, Daniel D?az Casanueva >> >> wrote: >> >>> >> >>> There is no problem with the version of GHC installed. Library >> >>> pcre-light >> >>> is importing unsafePerformIO from Foreign, module that doesn't export >> >>> this >> >>> function since version 4.7.0.0 of the base package. That causes the >> >>> build to >> >>> fail for users of base-4.7.0.0. Importing this function from >> >>> System.IO.Unsafe solves the problem. I have written to the maintainer >> >>> as >> >>> well, but did not received any answer yet. >> >>> >> >>> Regards, >> >>> Daniel D?az. >> >>> >> >>> >> >>> On Sun, Apr 13, 2014 at 3:21 AM, Carter Schonwald >> >>> wrote: >> >>>> >> >>>> please upgrace to 7.8.2 before trying to build anything, theres a >> >>>> *big* >> >>>> bug in 7.8.1 type checker >> >>>> >> >>>> >> >>>> On Sat, Apr 12, 2014 at 9:09 PM, Nikolay Amiantov >> >>>> >> >>>> wrote: >> >>>>> >> >>>>> Hello, >> >>>>> I've tried the new ghc-7.8.1 and have had an issue with building >> >>>>> pcre-light as one of dependencies for my project. I've made a patch >> >>>>> which >> >>>>> fixes this, but I can't reach maintainer by e-mail -- what can I do >> >>>>> in this >> >>>>> situation? Also, the second (unrelated) question would be: how can I >> >>>>> find a >> >>>>> package which depends on it in my project? I have found no way to >> >>>>> dump a >> >>>>> dependency tree in cabal. >> >>>>> >> >>>>> Thanks in advance, >> >>>>> Nikolay. >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Haskell-Cafe mailing list >> >>>>> Haskell-Cafe at haskell.org >> >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >>>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Haskell-Cafe mailing list >> >>>> Haskell-Cafe at haskell.org >> >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >>>> >> >>> >> > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dhelta.diaz at gmail.com Mon Apr 14 10:09:51 2014 From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=) Date: Mon, 14 Apr 2014 12:09:51 +0200 Subject: [Haskell-cafe] Patches for (abandoned?) pcre-light In-Reply-To: References: Message-ID: I have uploaded the new version [1], where I am listed as maintainer of the library. I will make sure the package keeps building over time. However, I don't think I am going to put much effort into adding new features or do any modifications to the API. I will probably keep it as it is, just making sure it builds with each new GHC release. If anybody is interested in working in this package further, feel free to fork the GitHub repository [2] where the current code is living and, if desired, ask me to become the new maintainer. Best regards, Daniel D?az. [1] - http://hackage.haskell.org/package/pcre-light-0.4.0.1 [2] - https://github.com/Daniel-Diaz/pcre-light On Mon, Apr 14, 2014 at 11:48 AM, Erik Hesselink wrote: > I've added you to the maintainers of pcre-light. > > Regards, > > Erik > > On Sun, Apr 13, 2014 at 3:15 PM, Daniel D?az Casanueva > wrote: > > As soon as I am given upload privileges I will push the fixed version to > > Hackage. > > > > > > On Sun, Apr 13, 2014 at 2:56 PM, Don Stewart wrote: > >> > >> Please proceed. > >> > >> On Sun, Apr 13, 2014 at 8:20 PM, Daniel D?az Casanueva > >> wrote: > >> > If given permission, I can submit a new version with the problem > fixed. > >> > However, this does not mean I would like to become the maintainer. > But, > >> > yeah, I would like to see a working version uploaded. > >> > > >> > > >> > On Sun, Apr 13, 2014 at 2:11 PM, Don Stewart > wrote: > >> >> > >> >> Please update as necessary. I am unable to maintain this package now. > >> >> > >> >> > >> >> On Sunday, 13 April 2014, Daniel D?az Casanueva < > dhelta.diaz at gmail.com> > >> >> wrote: > >> >>> > >> >>> There is no problem with the version of GHC installed. Library > >> >>> pcre-light > >> >>> is importing unsafePerformIO from Foreign, module that doesn't > export > >> >>> this > >> >>> function since version 4.7.0.0 of the base package. That causes the > >> >>> build to > >> >>> fail for users of base-4.7.0.0. Importing this function from > >> >>> System.IO.Unsafe solves the problem. I have written to the > maintainer > >> >>> as > >> >>> well, but did not received any answer yet. > >> >>> > >> >>> Regards, > >> >>> Daniel D?az. > >> >>> > >> >>> > >> >>> On Sun, Apr 13, 2014 at 3:21 AM, Carter Schonwald > >> >>> wrote: > >> >>>> > >> >>>> please upgrace to 7.8.2 before trying to build anything, theres a > >> >>>> *big* > >> >>>> bug in 7.8.1 type checker > >> >>>> > >> >>>> > >> >>>> On Sat, Apr 12, 2014 at 9:09 PM, Nikolay Amiantov > >> >>>> > >> >>>> wrote: > >> >>>>> > >> >>>>> Hello, > >> >>>>> I've tried the new ghc-7.8.1 and have had an issue with building > >> >>>>> pcre-light as one of dependencies for my project. I've made a > patch > >> >>>>> which > >> >>>>> fixes this, but I can't reach maintainer by e-mail -- what can I > do > >> >>>>> in this > >> >>>>> situation? Also, the second (unrelated) question would be: how > can I > >> >>>>> find a > >> >>>>> package which depends on it in my project? I have found no way to > >> >>>>> dump a > >> >>>>> dependency tree in cabal. > >> >>>>> > >> >>>>> Thanks in advance, > >> >>>>> Nikolay. > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> Haskell-Cafe mailing list > >> >>>>> Haskell-Cafe at haskell.org > >> >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> >>>>> > >> >>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> Haskell-Cafe mailing list > >> >>>> Haskell-Cafe at haskell.org > >> >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> >>>> > >> >>> > >> > > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ifigueroap at gmail.com Mon Apr 14 12:55:31 2014 From: ifigueroap at gmail.com (Ismael Figueroa) Date: Mon, 14 Apr 2014 14:55:31 +0200 Subject: [Haskell-cafe] Best practice to target different monad transformer libraries? Message-ID: I am developing the effective-aspects package, which currently depends on the mtl library. I want to develop a new version based on the "Monads, Zippers and Views" approach, developed by Schrijvers and Oliveira in ICFP'11. The question is: do I need to publish a new package, say, effective-aspects-mzv, which will be an almost duplicate of the original package? or is there another more elegant way to deal with this situations? Thanks -- Ismael -------------- next part -------------- An HTML attachment was scrubbed... URL: From lunaryorn at gmail.com Mon Apr 14 16:19:21 2014 From: lunaryorn at gmail.com (Sebastian Wiesner) Date: Mon, 14 Apr 2014 18:19:21 +0200 Subject: [Haskell-cafe] Cabal flag default based on external program Message-ID: Hello, I have a cabal package with some optional flags. The ?reasonable? default for these flags depends on the target system, specifically on the result of some external program. Is there a way to dynamically set the default value of a Cabal flag based on the result of an external program in my .cabal file? Greetings, Sebastian Wiesner From ok at cs.otago.ac.nz Mon Apr 14 22:05:21 2014 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue, 15 Apr 2014 10:05:21 +1200 Subject: [Haskell-cafe] Directed rounding in haskell ? In-Reply-To: References: <20140407141231.GA3594@fuckup> Message-ID: On 11/04/2014, at 2:15 AM, Alp Mestanogullari wrote: > Maybe these packages could be relevant/useful: > - https://github.com/ekmett/rounded > - https://github.com/ekmett/intervals The latter of these has a rich interface, but I a b + I a' b' = (a + a') ... (b + b') _ + _ = Empty (Numeric.Interval.Internal.hs) does not do the necessary directed rounding. The package looks like an excellent way to deal with intervals of exact numbers, but for floating point numbers it's not at all what one usually intends. From travis.cardwell at extellisys.com Tue Apr 15 01:35:20 2014 From: travis.cardwell at extellisys.com (Travis Cardwell) Date: Tue, 15 Apr 2014 10:35:20 +0900 Subject: [Haskell-cafe] Minimal Haskell Platform Message-ID: <534C8CD8.1060108@extellisys.com> Hello, I have been using Haskell Platform since it was introduced because I have always heard that it is the recommended way to use GHC. Indeed, Haskell Platform has made the installation of a Haskell environment quite straightforward. My current usage strategy is a common one: * Only install Haskell Platform in --global. * Avoid installing into ~/.cabal (when possible). * Develop exclusively in Cabal sandboxes. In a recent /r/haskell post [1], user mightybyte commented: > This. The Haskell Platform installs a bunch of packages for you in > --global. My experience is that this inevitably leads to problems if > you're doing significant Haskell development. The best thing to do is > to minimize the number of packages installed as --global. The way to do > that is to install GHC directly and avoid using the Haskell Platform or > Haskell distributions provided by your OS. Asking about it in #haskell, it seems that a number of developers recommend such a minimal installation, particularly for large projects. I am very interested in minimizing the number of packages in --global, and I would like to start testing my software against the current Haskell Platform *as well as* such a minimal installation. I my initial tests (Debian stable amd64; minimal virtual machine), I tried installing GHC 7.8.2 and cabal-install (using bootstrap.sh) only. Installation went fine, `cabal update` worked fine, and `cabal sandbox init` worked fine. I then tried `cabal install hlint` (within the sandbox), and it successfully compiles a number of packages before failing when trying to build haskell-src-exts, complaining that happy could not be found. Running `cabal install happy` failed with the "setup: The program happy is required but it could not be found" error. Building happy via the source Setup.lhs worked fine, and installing the binary into my installation bin directory results in an environment in which I am able to `cabal install hlint` (and `cabal install happy`) into a sandbox without issue. It is interesting that cabal does not (try to) install happy as a prerequisite for haskell-src-exts, which lists happy as a Build-Tools dependency [2]. It is also interesting that `cabal install happy` requires itself, despite indication in the documentation [3] that it is a valid way to install the package... Does this indicate that Cabal expects Haskell Platform? Should Cabal be changed to (support minimal installations and) manage Build-Tools dependencies? Would it be worthwhile to create a "Minimal Haskell Platform" to create a truly common platform that everybody would be happy using? Cheers, Travis [1] http://www.reddit.com/r/haskell/comments/22up8l/ghc_782_released/ [2] https://github.com/haskell-suite/haskell-src-exts/blob/9bc4daf3b51d006741c6b1fc7524e18591f01945/haskell-src-exts.cabal#L127 [3] http://www.haskell.org/happy/ From sol at typeful.net Tue Apr 15 05:02:38 2014 From: sol at typeful.net (Simon Hengel) Date: Tue, 15 Apr 2014 13:02:38 +0800 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: <534C8CD8.1060108@extellisys.com> References: <534C8CD8.1060108@extellisys.com> Message-ID: <20140415050238.GA16708@x200> > It is interesting that cabal does not (try to) install happy as a > prerequisite for haskell-src-exts, which lists happy as a > Build-Tools dependency [2]. It is also interesting that `cabal > install happy` requires itself, despite indication in the > documentation [3] that it is a valid way to install the package... > > Does this indicate that Cabal expects Haskell Platform? No, installing build tools is just a missing feature of `cabal-install` (AFAIK). > Should Cabal be changed to (support minimal installations and) > manage Build-Tools dependencies? Yes. > Would it be worthwhile to create a "Minimal Haskell Platform" to > create a truly common platform that everybody would be happy using? I think most Haskell developers use a reasonably recent version of GHC (that would currently still be 7.6.3 for me) and the latest version of cabal-install. Everything else can be installed with cabal-install. So yes, I think we should just have an easy way to get that minimal setup (+ most importantly don't recommend something to beginners that we don't use ourself). Where would something like the HP actually make sense? For stuff that has external dependencies that are not easily installable with cabal-install (like curses bindings, SSL support, etc.). We have none of this in the HP. So I think currently we just have additional costs, but no benefits (+ we harm innovation by arbitrarily "endorsing" random packages). Cheers, Simon From rendel at informatik.uni-marburg.de Tue Apr 15 07:09:59 2014 From: rendel at informatik.uni-marburg.de (Tillmann Rendel) Date: Tue, 15 Apr 2014 09:09:59 +0200 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: <20140415050238.GA16708@x200> References: <534C8CD8.1060108@extellisys.com> <20140415050238.GA16708@x200> Message-ID: <534CDB47.2030300@informatik.uni-marburg.de> Hi, Simon Hengel wrote: > Where would something like the HP actually make sense? In my experience, the Haskell Platform makes it significantly easier to use Haskell on Windows. On Windows and/or for the typical Haskellers on Windows, it is hard to build a package that depends on external C libraries or uses a configure script, however trivial. This is because on Windows, there is no way to manage installed C libraries without understanding C development. But most Windows users are not C programmers, and some Windows Haskellers even learn Haskell as their first programming language. In extreme cases, ghc and cabal are the first command-line tool they learn. So on Windows, before the Haskell Platform was introduced, `cabal install some-random-package` usually failed for some dependency that required a C library. With the Haskell Platform, `cabal install some-random-package` usually works. I guess there are two effects: 1. The Haskell platform seems to bundle some packages that require external C libraries or configure scripts. The network package comes to mind. 2. The existence of the Haskell platform encourages non-Windows developers to avoid dependencies that are not in the Haskell platform. Because of effect 1, this translates to non-Windows developers avoiding dependencies that are hard to install on Windows. So from the perspective of using Haskell on Windows, the Haskell Platform is very successful, and installing it is good advice. If anything, it should be bigger, not smaller. And it should focus on libraries with external dependencies. So could we make a Haskell-on-Windows-Platform and drop the Haskell Platform for the other platforms? This would give Haskellers on Windows the first effect, but it would disable the second effect. I'm not sure how much the first effect is worth without the second. Why should we care about Haskellers on Windows? I think there are some important classes of new Haskellers that are on Windows, at least initially, and if we want to convert them to long-time Haskellers, we need to support them in their context. For example, here are three reasons to start your Haskell experience on Windows: 1. You might be a student at a university where the lab computers run Windows. A minimal installation without excellent support for libraries would be fine for following a lecture on Haskell, but you will not take Haskell serious if it doesn't give you easy access to libraries. In fact, installing Haskell libraries can be very easy, but only if you get the external dependency issue out of the way. 2. You might be a not-yet-programmer who wants to use a embedded DSL for your domain, and you're on Windows "by default" or because of the tradition in your field. We like to claim that Haskell is good for embedded DSLs, so we should support this usage scenario. 3. You might be a not-yet-programmer who wants to use an external DSL for your domain, and you're on Windows as above, and you want to become a power-user of the DSL. So maybe you start reporting bugs and are asked to `cabal install` the development version to check fixes. Or maybe you want to copy-and-adapt a little Haskell program that uses a library interface to the DSL for scripting purposes. We see both of this happening for pandoc, for example. Also, Haskell is a high-level language, and it would be somewhat silly if Haskell programs would not be easily portable due to low-level issues. Tillmann From roma at ro-che.info Tue Apr 15 08:45:22 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 15 Apr 2014 11:45:22 +0300 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: <20140415050238.GA16708@x200> References: <534C8CD8.1060108@extellisys.com> <20140415050238.GA16708@x200> Message-ID: <20140415084522.GA10244@sniper> * Simon Hengel [2014-04-15 13:02:38+0800] > > Would it be worthwhile to create a "Minimal Haskell Platform" to > > create a truly common platform that everybody would be happy using? > > I think most Haskell developers use a reasonably recent version of GHC > (that would currently still be 7.6.3 for me) and the latest version of > cabal-install. Everything else can be installed with cabal-install. > > So yes, I think we should just have an easy way to get that minimal > setup (+ most importantly don't recommend something to beginners that we > don't use ourself). > > Where would something like the HP actually make sense? For stuff that > has external dependencies that are not easily installable with > cabal-install (like curses bindings, SSL support, etc.). We have none > of this in the HP. So I think currently we just have additional costs, > but no benefits (+ we harm innovation by arbitrarily "endorsing" random > packages). Agreed. As Tillmann notes, HP is indispensable on Windows, but that is a side effect. Indeed, HP as a simple way to conveniently install the bits that are otherwise hard to install makes perfect sense. However, nowadays most attention goes not to that, but to choosing ordinary cabal packages to be bundled with HP. I see little value in that. As a way to ensure the "installability" of packages, Stackage now does a far greater job than HP by: - having much wider selection of packages, and making it almost trivial to incorporate new ones; - constantly building packages and running tests; - notifying maintainers about broken packages and packages with restrictive upper bounds. In other words, it ensures that Stackage packages are installable at any time with cabal. (Well, strictly speaking, there may be a delay between when a problem is reported by Michael and when it's fixed by the maintainer.) Apart from that, HP "arbitrarily endorses" its packages and forces them into stability mode. Whether it is a good thing or not is another argument and depends on one's perspective. I know that some people find it important (and I'm well aware of their reasoning). Personally, with my hats of * an open source libraries developer/maintainer * a personal Haskell user * a commercial Haskell user on, I don't care about HP. The only time when I remember about it is when I tell novices how they can "install Haskell". But again, this has nothing to do with the bundled cabal packages, only with the way of installing ghc/cabal/etc. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From christiaan.baaij at gmail.com Tue Apr 15 08:47:13 2014 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Tue, 15 Apr 2014 10:47:13 +0200 Subject: [Haskell-cafe] ANN: clash - from haskell to hardware Message-ID: <99395235-7AF1-4D2D-A587-474492B9209A@gmail.com> I'm pleased to announced to first official release of the new C?aSH compiler! Website: http://christiaanb.github.io/clash2 Hackage: http://hackage.haskell.org/package/clash-ghc Github: https://github.com/christiaanb/clash2 From the website: C?aSH (pronounced ?clash?) is a functional hardware description language that borrows both its syntax and semantics from the functional programming language Haskell. The merits of using a functional language to describe hardware comes from the fact that combinational circuits can be directly modelled as mathematical functions and that functional languages lend themselves very well at describing and (de-)composing mathematical functions. The C?aSH compiler transforms these high-level descriptions to low-level synthesizable VHDL. There is a tutorial at: http://hackage.haskell.org/package/clash-prelude/docs/CLaSH-Tutorial.html Which also lists the (nearly-compulsory) comparison between C?aSH and Lava. -- Christiaan Baaij From sol at typeful.net Tue Apr 15 10:11:13 2014 From: sol at typeful.net (Simon Hengel) Date: Tue, 15 Apr 2014 18:11:13 +0800 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: <20140415084522.GA10244@sniper> References: <534C8CD8.1060108@extellisys.com> <20140415050238.GA16708@x200> <20140415084522.GA10244@sniper> Message-ID: <20140415101113.GA25661@x200> On Tue, Apr 15, 2014 at 11:45:22AM +0300, Roman Cheplyaka wrote: > * Simon Hengel [2014-04-15 13:02:38+0800] > > > Would it be worthwhile to create a "Minimal Haskell Platform" to > > > create a truly common platform that everybody would be happy using? > > > > I think most Haskell developers use a reasonably recent version of GHC > > (that would currently still be 7.6.3 for me) and the latest version of > > cabal-install. Everything else can be installed with cabal-install. > > > > So yes, I think we should just have an easy way to get that minimal > > setup (+ most importantly don't recommend something to beginners that we > > don't use ourself). > > > > Where would something like the HP actually make sense? For stuff that > > has external dependencies that are not easily installable with > > cabal-install (like curses bindings, SSL support, etc.). We have none > > of this in the HP. So I think currently we just have additional costs, > > but no benefits (+ we harm innovation by arbitrarily "endorsing" random > > packages). > > Agreed. > > As Tillmann notes, HP is indispensable on Windows, but that is a side effect. > Indeed, HP as a simple way to conveniently install the bits that are otherwise > hard to install makes perfect sense. When looking at `network` specifically, I think it does not even have external dependencies, it just needs a C compiler and GNU autotools. So if we care about Windows support, couldn't we just bundle MingGW with a minimalistic GHC + cabal-install distribution. That would not only solve the network case, but also work for other packages that include some C files in the cabal package or need autotools for whatever reason. Cheers, Simon From rendel at informatik.uni-marburg.de Tue Apr 15 10:19:32 2014 From: rendel at informatik.uni-marburg.de (Tillmann Rendel) Date: Tue, 15 Apr 2014 12:19:32 +0200 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: <20140415101113.GA25661@x200> References: <534C8CD8.1060108@extellisys.com> <20140415050238.GA16708@x200> <20140415084522.GA10244@sniper> <20140415101113.GA25661@x200> Message-ID: <534D07B4.3090706@informatik.uni-marburg.de> Hi, Simon Hengel wrote: > When looking at `network` specifically, I think it does not even have > external dependencies, it just needs a C compiler and GNU autotools. So > if we care about Windows support, couldn't we just bundle MingGW with a > minimalistic GHC + cabal-install distribution. Interesting. As far as I know, the ghc distribution for Windows already bundles some tools. So maybe network was a bad example? Or maybe it was hard to install even with the tools bundled. I don't remember, because for the last couple of years, I have been happily using the Haskell Platform, so I stopped trying to install network from source. Tillmann From johan.tibell at gmail.com Tue Apr 15 12:54:22 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 15 Apr 2014 14:54:22 +0200 Subject: [Haskell-cafe] Cabal/cabal-install 1.20 release candidates Message-ID: Hi all, I've prepared the Cabal/cabal-install 1.20 release candidates. I now need some help testing, especially on Windows as I don't have a Windows machine. There are over 300 commits since the last release and lots of interesting new features and changes. I will write them down when I make the actual release. To install the release candidates simply run: cabal install --constraint="HTTP >= 4000.2.5" http://johantibell.com/files/Cabal-1.20.0-rc.tar.gz http://johantibell.com/files/cabal-install-1.20.0-rc.tar.gz (The --constraint="HTTP >= 4000.2.5" flag is used to work around an issue I already found in the RC, it won't be needed for the real release.) Please report any issues on the bug tracker: https://github.com/haskell/cabal/issues If I haven't heard of anything release blocking bugs (or last minute important patches) in a couple of days, I will make these tarballs the official release. The commits used are tagged in the repo as Cabal-v1.20.0-rc and cabal-install-v1.20.0-rc. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dav.vire+haskell at gmail.com Tue Apr 15 13:05:29 2014 From: dav.vire+haskell at gmail.com (David Virebayre) Date: Tue, 15 Apr 2014 15:05:29 +0200 Subject: [Haskell-cafe] Error in the GHC documentation for the IsList class ? Message-ID: In section 7.6.5.1, the documentation describes the IsList class, then goes on writing about a FromList class ( "The FromList class and its methods are intended to be used in conjunction with the OverloadedLists extension.") Later it's written : It is perfectly fine to declare new instances of IsList, so that list notation becomes useful for completely new data types. Here are several example instances: ... instance FromList [a] where David. From mail at joachim-breitner.de Tue Apr 15 13:34:50 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 15 Apr 2014 15:34:50 +0200 Subject: [Haskell-cafe] Error in the GHC documentation for the IsList class ? In-Reply-To: References: Message-ID: <1397568890.2524.24.camel@kirk> HI, Am Dienstag, den 15.04.2014, 15:05 +0200 schrieb David Virebayre: > In section 7.6.5.1, the documentation describes the IsList class, then > goes on writing about a FromList class ( "The FromList class and its > methods are intended to be used in conjunction with the > OverloadedLists extension.") > > Later it's written : > > It is perfectly fine to declare new instances of IsList, so that list > notation becomes useful for completely new data types. Here are > several example instances: > ... > instance FromList [a] where clearly a mistake; fixed in http://git.haskell.org/ghc.git/commit/a107737f84f6738a9fa572ec9c5da49c9db8a8b5 Thanks for the report, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mwm at mired.org Tue Apr 15 16:31:49 2014 From: mwm at mired.org (Mike Meyer) Date: Tue, 15 Apr 2014 11:31:49 -0500 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: <20140415084522.GA10244@sniper> References: <534C8CD8.1060108@extellisys.com> <20140415050238.GA16708@x200> <20140415084522.GA10244@sniper> Message-ID: On Tue, Apr 15, 2014 at 3:45 AM, Roman Cheplyaka wrote: > on, I don't care about HP. The only time when I remember about it is when I tell novices how they can "install Haskell". But again, this has nothing to do with the bundled cabal packages, only with the way of installing ghc/cabal/etc. This points out at least one other benefit of HP: it provides a larger set of libraries for people learning Haskell to get started with before having to learn how to deal with cabal and the possibilities of cabal hell. It may be that this isn't real - that the recent and good or popular tutorials all work fine with just GHC, in which case ignore me. On the other hand, if they all deal with cabal at one point or another, possibly HP needs better curation: audit what's there to make sure it's the best choice, drop things that aren't useful, expand it to include critical libraries that are required by the tutorials, etc. From schlepptop at henning-thielemann.de Tue Apr 15 20:05:32 2014 From: schlepptop at henning-thielemann.de (Henning Thielemann) Date: Tue, 15 Apr 2014 22:05:32 +0200 Subject: [Haskell-cafe] quantities 0.3.0 In-Reply-To: References: Message-ID: <534D910C.2070809@henning-thielemann.de> Am 15.04.2014 21:29, schrieb John David Reaver: > Hello! I am happy to publicly announce the quantities package: > > Hackage: http://hackage.haskell.org/package/quantities > Github: https://github.com/jdreaver/quantities > > I feel this package is complete enough as of version > 0.3.0 (released today) to announce it to the public. I have programmed something similar years ago, first for Haskell 98 numeric classes and then for numeric-prelude. My implementation does not use an expression tree for the physical dimensions. Instead it uses a vector of base dimensions and constructs reasonable units only for string output. http://hackage.haskell.org/package/numeric-prelude-0.4.1/docs/Number-SI.html You can play around with it by unpacking the numeric-prelude package and run 'make ghci' thielema at sputnik:/tmp> cabal unpack numeric-prelude Unpacking to numeric-prelude-0.4.1/ thielema at sputnik:/tmp> cd numeric-prelude-0.4.1/ thielema at sputnik:/tmp/numeric-prelude-0.4.1> make ghci ... *Main> 25*meter/second :: SIDouble ... 25.0 m/s *Main> minute/second :: SIDouble 60.0 *Main> ampere*volt :: SIDouble 1.0 W There are many more libraries for handling of physical dimensions: http://www.haskell.org/haskellwiki/Physical_units You may add 'quantities' there. From auke at tulcod.com Tue Apr 15 20:13:31 2014 From: auke at tulcod.com (Auke Booij) Date: Tue, 15 Apr 2014 21:13:31 +0100 Subject: [Haskell-cafe] [Haskell] [ANN] quantities 0.3.0 In-Reply-To: References: Message-ID: On 15 April 2014 20:29, John David Reaver wrote: > Hello! I am happy to publicly announce the quantities package: I think haskell-cafe is more appropriate for these kinds of libraries. Anyway, welcome. > From the description on Hackage: > > A library for creating and manipulating physical quantities, > which are a numerical value associated with a unit of > measurement. Included is an expression parser and a huge list > of predefined quantities with which to parse strings into a > Quantity datatype. Once created, a quantity can be converted > to different units or queried for its dimensionality. A user > can also operate on quantities arithmetically, and doing so > uses automatic unit conversion and simplification. > not sure if "quantities" is an appropriate name for your package: an integer, a float, complex numbers - those are quantities. doesn't this package parse units? > Just to get a taste of how this package works, here are some > examples: why can i only "unsafely" create quantities using strings? what if i know upfront what kind of a unit i want to deal with? from the looks of it, this library is only good for dealing with human-readable input - surely that's not the only use case you had in mind? > >>> fromString "min => s" > Right 60.0 second can't we find some elegant way to express this in haskell, instead of having to invent a scripting language of sorts? On a similar note, your "magnitude :: Quantity -> Double" sounds a bit like unsafeCoerce: why would you want to forget that your quantity has a unit? >From your documentation: > >>> fromString "m => 3 ft" > Left (ScalingFactorError 3.0 foot) Why isn't the outcome of this 3.28084/3=1.09361 or something along those lines? (this is just a suggestion, I'm not saying this is a bad thing.) > >>> fromString "2 ft + 6 in => ft" > Right 2.5 foot Oh, so you are trying to support arbitrary arithmetical input! Then again, there is no way to add two "Quantity"s. I have the feeling the goal of your package is a bit unclear: do you want to implement a framework to type-safely compute with units? Or do you just want to write something that parses string input to typed data? In the former case, have you considered the discussion on the haskellwiki [1]? In the latter case, why don't you write it on top of an existing units package? Well, that was a big rant, I hope you can use some of it. Auke. [1]: http://www.haskell.org/haskellwiki/Physical_units From the.dead.shall.rise at gmail.com Tue Apr 15 20:21:17 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Tue, 15 Apr 2014 22:21:17 +0200 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: <20140415101113.GA25661@x200> References: <534C8CD8.1060108@extellisys.com> <20140415050238.GA16708@x200> <20140415084522.GA10244@sniper> <20140415101113.GA25661@x200> Message-ID: Hi, On 15 April 2014 12:11, Simon Hengel wrote: > When looking at `network` specifically, I think it does not even have > external dependencies, it just needs a C compiler and GNU autotools. So > if we care about Windows support, couldn't we just bundle MingGW with a > minimalistic GHC + cabal-install distribution. That would not only > solve the network case, but also work for other packages that include > some C files in the cabal package or need autotools for whatever reason. GHC on Windows already includes MinGW, but you also need MSYS for configure scripts. I do want to ship MSYS with the HP installer, but haven't got around to integrating it yet. From jdreaver at adlerhorst.com Tue Apr 15 20:30:38 2014 From: jdreaver at adlerhorst.com (John David Reaver) Date: Tue, 15 Apr 2014 13:30:38 -0700 Subject: [Haskell-cafe] [Haskell] [ANN] quantities 0.3.0 In-Reply-To: References: Message-ID: Thanks for the feedback! > not sure if "quantities" is an appropriate name for your > package: an integer, a float, complex numbers - those are > quantities. doesn't this package parse units? Wikipedia and this dictionary (http://dictionary.reference.com/browse/quantity) imply that quantities are associated with units of measurement. This package does indeed parse units. When a magnitude is associated with those units, you get a quantity. I think the name "quantities" is totally appropriate. > why can i only "unsafely" create quantities using strings? what > if i know upfront what kind of a unit i want to deal with? from > the looks of it, this library is only good for dealing with > human-readable input - surely that's not the only use case you > had in mind? > can't we find some elegant way to express this in haskell, > instead of having to invent a scripting language of sorts? Using the type system to handle units is incorporated into some other libraries. I couldn't find a library that parses units from strings, so I made one. I certainly plan to add this functionality in the future. > On a similar note, your "magnitude :: Quantity -> Double" > sounds a bit like unsafeCoerce: why would you want to forget > that your quantity has a unit? You don't "forget" it has units. Sometimes you just want to get the magnitude, like after you perform a conversion operation, for instance. > Oh, so you are trying to support arbitrary arithmetical input! > Then again, there is no way to add two "Quantity"s. There is indeed: http://hackage.haskell.org/package/quantities-0.3.0/docs/Data-Quantities.html#v:addQuants > I have the feeling the goal of your package is a bit unclear: > do you want to implement a framework to type-safely compute > with units? Or do you just want to write something that parses > string input to typed data? Currently, it parses string input. I am a contributor to a Python package called pint, which was a huge inspiration to this library. In my day job, I develop a commercial Python GUI application for petroleum engineering that needs to convert between many units. One feature of this application is a user can enter arbitrary units of their choice to for plots and data so they don't have to convert units by hand when using the application. I wanted to bring that functionality to Haskell. > Well, that was a big rant, I hope you can use some of it. I did, thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From auke at tulcod.com Tue Apr 15 20:54:09 2014 From: auke at tulcod.com (Auke Booij) Date: Tue, 15 Apr 2014 21:54:09 +0100 Subject: [Haskell-cafe] [Haskell] [ANN] quantities 0.3.0 In-Reply-To: References: Message-ID: On 15 April 2014 21:30, John David Reaver wrote: >> why can i only "unsafely" create quantities using strings? what >> if i know upfront what kind of a unit i want to deal with? from >> the looks of it, this library is only good for dealing with >> human-readable input - surely that's not the only use case you >> had in mind? > >> can't we find some elegant way to express this in haskell, >> instead of having to invent a scripting language of sorts? > > Using the type system to handle units is incorporated into some > other libraries. I couldn't find a library that parses units from > strings, so I made one. I certainly plan to add this > functionality in the future. so then why are you reinventing those units libraries? in other words, why did you write Quantity instead of reusing a similar data type from an existing library? >> On a similar note, your "magnitude :: Quantity -> Double" >> sounds a bit like unsafeCoerce: why would you want to forget >> that your quantity has a unit? > > You don't "forget" it has units. Sometimes you just want to get > the magnitude, like after you perform a conversion operation, for > instance. but you do forget it has units! it says it right there: magnitude takes a Quantity, and gives back only the Double it contains. I don't know what definition of "forget" you're working with... your magnitude function suggests that to do some complicated calculation on some Quantity inputs, you first "unpack" them to Doubles, do your calculations, and then repack them into Quantities. that means my calculations are not type-safe against mixing up units anymore: why would we even store the unit of some number in the first place, if we have to (temporarily) forget those units the moment we start doing any serious calculations? Mind you: it is not acceptable to have to rewrite all my existing calculations to use your functions. I wrote +, I meant +, so I should be able to use + --- not your addQuants or subtractQuants. Maybe making Quantity an instance of the right type classes solves this entire issue? >> Oh, so you are trying to support arbitrary arithmetical input! >> Then again, there is no way to add two "Quantity"s. > > There is indeed: > http://hackage.haskell.org/package/quantities-0.3.0/docs/Data-Quantities.html#v:addQuants apologies, hadn't seen it. However, that leaves me with the impression that there are two ways to add two quantities: "inside the string", such as with > >>> fromString "ft + 12in" or in haskell, using addQuants. Although it is of course perfectly allowed to implement the same functionality twice (yes, the same functionality: the essence is that you add two quantities. the fact that the exact input data is different doesn't bother me as a mathematician), this smells of bad library design. Not saying it is, just saying it leaves a bad taste: there is no clear reason why you need both. Again, what exactly is the purpose of your library? >> I have the feeling the goal of your package is a bit unclear: >> do you want to implement a framework to type-safely compute >> with units? Or do you just want to write something that parses >> string input to typed data? > > Currently, it parses string input. I am a contributor to a Python > package called pint, which was a huge inspiration to this library. my impression is that, in general, people try to stick with the unix mentality when it comes to designing the goals of a package: do one thing, and do it well. you are doing several things. From hsyl20 at gmail.com Tue Apr 15 22:02:40 2014 From: hsyl20 at gmail.com (Sylvain Henry) Date: Wed, 16 Apr 2014 00:02:40 +0200 Subject: [Haskell-cafe] [Haskell] [ANN] quantities 0.3.0 In-Reply-To: References: Message-ID: 2014-04-15 22:54 GMT+02:00 Auke Booij : > On 15 April 2014 21:30, John David Reaver wrote: > > > Using the type system to handle units is incorporated into some > > other libraries. I couldn't find a library that parses units from > > strings, so I made one. I certainly plan to add this > > functionality in the future. > > so then why are you reinventing those units libraries? in other words, > why did you write Quantity instead of reusing a similar data type from > an existing library? > Most libraries only support static checking of units (AFAIK). Supporting unit parsing from a string is great. When we will rewrite Google with Haskell, we will need it ;) (try to type "(1m + 1ft + 2 yards + 50in) * 5 / (8 km/h) in minutes" for instance). You cannot ask him why his library only supports string input, then ask him to provide an additional Haskell DSL that is not unsafe and finally reproach him for wanting to support both approaches. For his needs (at least in the Python GUI app he describes), he can either use an external DSL approach (parsing strings) or use an Haskell EDSL with System.Eval.Haskell (or an equivalent). The former may be preferred. -- Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdreaver at adlerhorst.com Tue Apr 15 22:25:19 2014 From: jdreaver at adlerhorst.com (John David Reaver) Date: Tue, 15 Apr 2014 15:25:19 -0700 Subject: [Haskell-cafe] [Haskell] [ANN] quantities 0.3.0 In-Reply-To: References: Message-ID: > Most libraries only support static checking of units (AFAIK). I found that to be the case. Indeed, if would be nice to integrate both approaches elegantly. I haven't figured out how yet. > (try to type "(1m + 1ft + 2 yards + 50in) * 5 / (8 km/h) in minutes" > for instance). I had to try it using quantities :) >>> fromString "(1m + 1ft + 2 yard + 50in) * 5 / (8 km/h) => minute" Right 0.16513500000000006 minute -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Tue Apr 15 22:38:07 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 15 Apr 2014 23:38:07 +0100 Subject: [Haskell-cafe] [Haskell] [ANN] quantities 0.3.0 In-Reply-To: References: Message-ID: <20140415223807.GE29519@weber> On Tue, Apr 15, 2014 at 03:25:19PM -0700, John David Reaver wrote: > > Most libraries only support static checking of units (AFAIK). > > I found that to be the case. Indeed, if would be nice to integrate > both approaches elegantly. I haven't figured out how yet. This seems to be a specific instance of the general problem of type checking code which is loaded at runtime. Tom From mantkiew at gsd.uwaterloo.ca Wed Apr 16 00:55:54 2014 From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz) Date: Tue, 15 Apr 2014 20:55:54 -0400 Subject: [Haskell-cafe] Cabal/cabal-install 1.20 release candidates In-Reply-To: References: Message-ID: Hi Johan, Just reporting that everything works for me on Windows 8 with HP 2013.2.0.0 and the included GHC 7.6.3. I was able to build and install our three projects and all their dependencies (incl. lens, gitit, MissingH, glpk-hs...) from scratch (I removed Roaming/cabal and Roaming/ghc). But it wasn't without problems. With HaXml package: the latest version (1.24.1) no longer compiles with GHC 7.6.3. So when the build failed, I manually cabal installed HaXml-1.24, which worked, and then I could finish the build of my projects. It would be good if cabal somehow took into account the lowerbound of the compiler version required for a package, so that HaXml-1.24.1, for example, could say it requires ghc >= 7.8.2 and cabal would pick HaXml-1.24 which works with 7.6.3 instead. Of course, what I have to do now is to specify the upperbound on HaXml... Also, sometimes I am getting messages similar to this (it was also hapenning with 1.18.*): $ cabal install pandoc-1.11.1 Resolving dependencies... Failed to install pandoc-1.11.1 Last 10 lines of the build log ( C:\Users\mantkiew\AppData\Roaming\cabal\logs\pandoc-1.11.1.log ): cabal.exe: C:\Users\mantkiew\AppData\Roaming\cabal\logs\pandoc-1.11.1.log: does not exist The file "pandoc-1.11.1.log" indeed does not exist. After I manually create an empty log file, I get this: $ cabal install pandoc-1.11.1 Resolving dependencies... Failed to install pandoc-1.11.1 Last 10 lines of the build log ( C:\Users\mantkiew\AppData\Roaming\cabal\logs\pandoc-1.11.1.log ): cabal.exe: Error: some packages failed to install: pandoc-1.11.1 failed while unpacking the package. The exception was: C:\Users\mantkiew\AppData\Local\Temp\pandoc-1.11.1-4732\pandoc-1.11.1\dist-tmp: MoveFileEx "C:\\Users\\mantkiew\\AppData\\Local\\Temp\\pandoc-1.11.1-4732\\pandoc-1.11.1\\dist-tmp" "C:\\Users\\mantkiew\\AppData\\Local\\Temp\\pandoc-1.11.1-4732\\pandoc-1.11.1\\dist": permission denied (Access is denied.) the "pandoc-1.11.1-4732" does not even exit. Of course, on subsequent attempts, the number is changing after package version. Nothing I tried worked. The only way out of this is to completely remove the Roaming/cabal and Roaming/ghc folders and begin from scratch. Then it worked. I wasn't able to reproduce this behavior -- it seems random. Why would cabal report access denied for non-existing files/folders? Finally,I love the speed (jobs: $ncpus) :-D Thanks! Michal On Tue, Apr 15, 2014 at 8:54 AM, Johan Tibell wrote: > Hi all, > > I've prepared the Cabal/cabal-install 1.20 release candidates. I now need > some help testing, especially on Windows as I don't have a Windows machine. > > There are over 300 commits since the last release and lots of interesting > new features and changes. I will write them down when I make the actual > release. > > To install the release candidates simply run: > > cabal install --constraint="HTTP >= 4000.2.5" > http://johantibell.com/files/Cabal-1.20.0-rc.tar.gz > http://johantibell.com/files/cabal-install-1.20.0-rc.tar.gz > > (The --constraint="HTTP >= 4000.2.5" flag is used to work around an issue > I already found in the RC, it won't be needed for the real release.) > > Please report any issues on the bug tracker: > https://github.com/haskell/cabal/issues > > If I haven't heard of anything release blocking bugs (or last minute > important patches) in a couple of days, I will make these tarballs the > official release. > > The commits used are tagged in the repo as Cabal-v1.20.0-rc and > cabal-install-v1.20.0-rc. > > -- Johan > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Wed Apr 16 00:56:33 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Wed, 16 Apr 2014 02:56:33 +0200 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: <534C8CD8.1060108@extellisys.com> References: <534C8CD8.1060108@extellisys.com> Message-ID: Hi, On 15 April 2014 03:35, Travis Cardwell wrote: > > In a recent /r/haskell post [1], user mightybyte commented: >> This. The Haskell Platform installs a bunch of packages for you in >> --global. My experience is that this inevitably leads to problems if >> you're doing significant Haskell development. The best thing to do is >> to minimize the number of packages installed as --global. The way to do >> that is to install GHC directly and avoid using the Haskell Platform or >> Haskell distributions provided by your OS. Having the foundational libraries like text in the global package DB is not such a bad idea because otherwise you end up reinstalling them into each new sandbox. The post you quote doesn't provide information about specific problems with this setup. I'd be interested to hear about them. From the.dead.shall.rise at gmail.com Wed Apr 16 01:02:12 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Wed, 16 Apr 2014 03:02:12 +0200 Subject: [Haskell-cafe] Cabal/cabal-install 1.20 release candidates In-Reply-To: References: Message-ID: Hi, On 16 April 2014 02:55, Michal Antkiewicz wrote: > > Also, sometimes I am getting messages similar to this (it was also hapenning > with 1.18.*): > > [...] Thanks for the bug report, I'll try to look into this when I get some free time. > Why would cabal report > access denied for non-existing files/folders? These are temporary folders that get deleted on process exit. From mantkiew at gsd.uwaterloo.ca Wed Apr 16 01:26:20 2014 From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz) Date: Tue, 15 Apr 2014 21:26:20 -0400 Subject: [Haskell-cafe] Cabal/cabal-install 1.20 release candidates In-Reply-To: References: Message-ID: Re: reproducing... When you loose internet connection during cabal run or you try to build without internet access you get this on Win 8 (for any package...) $ cabal install hoogle Resolving dependencies... Downloading hoogle-4.2.32... Failed to install hoogle-4.2.32 Last 10 lines of the build log ( C:\Users\mantkiew\AppData\Roaming\cabal\logs\hoogle-4.2.32.log ): cabal.exe: C:\Users\mantkiew\AppData\Roaming\cabal\logs\hoogle-4.2.32.log: does not exist But when the connection returns, I could successfully built it. Previously, however, that was not the case (with pandoc example). Hope that helps. Maybe this bug is related to loosing internet connection during cabal install run and having some leftovers which prevent it from restarting. Just speculating. Michal On Tue, Apr 15, 2014 at 9:02 PM, Mikhail Glushenkov < the.dead.shall.rise at gmail.com> wrote: > Hi, > > On 16 April 2014 02:55, Michal Antkiewicz > wrote: > > > > Also, sometimes I am getting messages similar to this (it was also > hapenning > > with 1.18.*): > > > > [...] > > Thanks for the bug report, I'll try to look into this when I get some free > time. > > > Why would cabal report > > access denied for non-existing files/folders? > > These are temporary folders that get deleted on process exit. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantkiew at gsd.uwaterloo.ca Wed Apr 16 01:35:21 2014 From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz) Date: Tue, 15 Apr 2014 21:35:21 -0400 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: References: <534C8CD8.1060108@extellisys.com> <20140415050238.GA16708@x200> <20140415084522.GA10244@sniper> <20140415101113.GA25661@x200> Message-ID: Re: MSYS. I always install MSYS after installing the platform on windows, so that would be extremely useful. However (I cannot recall the details atm) MSYS alone may still not be sufficient to build some packages. Michal On Tue, Apr 15, 2014 at 4:21 PM, Mikhail Glushenkov < the.dead.shall.rise at gmail.com> wrote: > Hi, > > On 15 April 2014 12:11, Simon Hengel wrote: > > When looking at `network` specifically, I think it does not even have > > external dependencies, it just needs a C compiler and GNU autotools. So > > if we care about Windows support, couldn't we just bundle MingGW with a > > minimalistic GHC + cabal-install distribution. That would not only > > solve the network case, but also work for other packages that include > > some C files in the cabal package or need autotools for whatever reason. > > GHC on Windows already includes MinGW, but you also need MSYS for > configure scripts. I do want to ship MSYS with the HP installer, but > haven't got around to integrating it yet. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis.cardwell at extellisys.com Wed Apr 16 02:00:31 2014 From: travis.cardwell at extellisys.com (Travis Cardwell) Date: Wed, 16 Apr 2014 11:00:31 +0900 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: <534DE3EF.3010904@extellisys.com> References: <534DE3EF.3010904@extellisys.com> Message-ID: <534DE43F.4090908@extellisys.com> On 2014?04?15? 14:02, Simon Hengel wrote: >> It is interesting that cabal does not (try to) install happy as a >> prerequisite for haskell-src-exts, which lists happy as a >> Build-Tools dependency [2]. It is also interesting that `cabal >> install happy` requires itself, despite indication in the >> documentation [3] that it is a valid way to install the package... >> >> Does this indicate that Cabal expects Haskell Platform? > > No, installing build tools is just a missing feature of `cabal-install` > (AFAIK). I chatted with Duncan Coutts in #haskell, and he confirmed that it is indeed just a missing feature. I found the issue here: https://github.com/haskell/cabal/issues/220 I was unable to find an issue regarding the `cabal install happy` failure, so I created one: https://github.com/haskell/cabal/issues/1777 >> Should Cabal be changed to (support minimal installations and) >> manage Build-Tools dependencies? > > Yes. In #haskell, Duncan Coutts said: > as for the global vs. minimal, yes I see it's an issue. One sometimes > wants to start a sandbox with a very minimal set. > > the issue with making a minimal sandbox is simply knowing which > packages should be in it, and we currently just base them all off of > the global one. > > but that's not the only solution, it'd also be possible to copy a > subset, if we know what subset to copy > > and I have a somewhat cunning plan along these lines (related to some > other ghc-pkg/cabal improvement work) which might make that rather > easier > > what I want is for ghc itself to come with multiple profiles, with one > being the minimum (base + rts + deps), and that could be used as a basis > for new envs With such a feature, it sounds like we can get the best of both worlds: * a feature-rich Haskell Platform to support beginners * minimal sandboxes for advanced users > I think most Haskell developers use a reasonably recent version of GHC > (that would currently still be 7.6.3 for me) and the latest version of > cabal-install. Everything else can be installed with cabal-install. In my experience, the alex and happy binaries must also be installed (for a number of packages to be installable via cabal-install). > Where would something like the HP actually make sense? For stuff that > has external dependencies that are not easily installable with > cabal-install (like curses bindings, SSL support, etc.). We have none > of this in the HP. So I think currently we just have additional costs, > but no benefits (+ we harm innovation by arbitrarily "endorsing" random > packages). I understand this point of view, but allow me to offer an opposing one. By putting packages with external dependencies into Haskell Platform, we often increase the dependencies of Haskell Platform itself. For example, Haskell Platform currently includes Graphics packages; installing Haskell Platform on a server entails installing a number of OpenGL libraries that are never used. Cheers, Travis From sol at typeful.net Wed Apr 16 02:28:58 2014 From: sol at typeful.net (Simon Hengel) Date: Wed, 16 Apr 2014 10:28:58 +0800 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: <534DE43F.4090908@extellisys.com> References: <534DE3EF.3010904@extellisys.com> <534DE43F.4090908@extellisys.com> Message-ID: <20140416022858.GA3051@x200> > >and I have a somewhat cunning plan along these lines (related to some > >other ghc-pkg/cabal improvement work) which might make that rather > >easier > > > >what I want is for ghc itself to come with multiple profiles, with one > >being the minimum (base + rts + deps), and that could be used as a basis > >for new envs > > With such a feature, it sounds like we can get the best of both worlds: > * a feature-rich Haskell Platform to support beginners > * minimal sandboxes for advanced users The issue with such integrated approaches that affect the whole toolchain (ghc, cabal, etc.) is that this can seriously harm innovation, at least if the net result is that it gets harder and harder to write alternative package managers, etc. TL;DR: If anything, we should make things *less integrated* (read more open and hackable). Let me try to make my point by looking at Haddock. Let's assume you are not happy with the current state of Haskell documentation tools. In such a situation it can makes perfect sense to give it a fresh start. But Haddock is so integrated with GHC, Hackage, Cabal,... that this is very hard to do. You can write an alternate documentation tool, but it may be hard for potential uses to experiment with it. Currently I think the only feasible way to get your changes in or experiment with new ideas is through the current maintainer, and if the current maintainer thinks your approach is a bad idea or just does not like you or does not have the time to look at your code you may be in a situation where it's hard to improve things. There is a lack of competition and I think it is not something absurd to assume that this lack of competition results in a lack of innovation. > >Where would something like the HP actually make sense? For stuff that > >has external dependencies that are not easily installable with > >cabal-install (like curses bindings, SSL support, etc.). We have none > >of this in the HP. So I think currently we just have additional costs, > >but no benefits (+ we harm innovation by arbitrarily "endorsing" random > >packages). > > I understand this point of view, but allow me to offer an opposing one. > By putting packages with external dependencies into Haskell Platform, we > often increase the dependencies of Haskell Platform itself. For example, > Haskell Platform currently includes Graphics packages; installing Haskell > Platform on a server entails installing a number of OpenGL libraries that > are never used. My point here was that (from my perspective) the cost/benefit ratio of bundling packages that are easily installable with cabal-install is negative. Cheers, Simon From djsamperi at gmail.com Wed Apr 16 03:42:43 2014 From: djsamperi at gmail.com (Dominick Samperi) Date: Tue, 15 Apr 2014 23:42:43 -0400 Subject: [Haskell-cafe] hsc2hs behaves differently under Windows? Message-ID: It seems that hsc2hs behaves differently under Windows (when compared with Linux), causing build problems. An example foo.hsc is attached, along with the foo.hs that is generated using hsc2hs under Windows. Note the expressions my_$s in the result. It appears that under Windows the %n$s POSIX printf notation is not recognized. The correctly generated file that is produced under Linux is also attached, in foo-linux.hs. Note that proper substitution happens here. Is there a work-around for this Windows issue? Thanks, Dominick -------------- next part -------------- A non-text attachment was scrubbed... Name: foo.hs Type: application/octet-stream Size: 295 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: foo.hsc Type: application/octet-stream Size: 215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: foo-linux.hs Type: application/octet-stream Size: 287 bytes Desc: not available URL: From holmisen at gmail.com Wed Apr 16 04:52:38 2014 From: holmisen at gmail.com (Johan Holmquist) Date: Wed, 16 Apr 2014 06:52:38 +0200 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: <20140416022858.GA3051@x200> References: <534DE3EF.3010904@extellisys.com> <534DE43F.4090908@extellisys.com> <20140416022858.GA3051@x200> Message-ID: I strongly believe we need the HP to be able to compete with Python etc with "batteries included". Having a set of blessed packages with stable APIs makes development easier, so the HP is a very important part of the Haskell eco system IMHO. Having graphics packages in the platform does make it a bit wierd to install on servers which are typically not equipped with OpenGL etc. Johan 2014-04-16 4:28 GMT+02:00 Simon Hengel : > > >and I have a somewhat cunning plan along these lines (related to some > > >other ghc-pkg/cabal improvement work) which might make that rather > > >easier > > > > > >what I want is for ghc itself to come with multiple profiles, with one > > >being the minimum (base + rts + deps), and that could be used as a basis > > >for new envs > > > > With such a feature, it sounds like we can get the best of both worlds: > > * a feature-rich Haskell Platform to support beginners > > * minimal sandboxes for advanced users > > The issue with such integrated approaches that affect the whole > toolchain (ghc, cabal, etc.) is that this can seriously harm innovation, > at least if the net result is that it gets harder and harder to write > alternative package managers, etc. > > TL;DR: If anything, we should make things *less integrated* (read more > open and hackable). > > Let me try to make my point by looking at Haddock. Let's assume you are > not happy with the current state of Haskell documentation tools. In > such a situation it can makes perfect sense to give it a fresh start. > But Haddock is so integrated with GHC, Hackage, Cabal,... that this is > very hard to do. You can write an alternate documentation tool, but it > may be hard for potential uses to experiment with it. Currently I think > the only feasible way to get your changes in or experiment with new > ideas is through the current maintainer, and if the current maintainer > thinks your approach is a bad idea or just does not like you or does not > have the time to look at your code you may be in a situation where it's > hard to improve things. There is a lack of competition and I think it > is not something absurd to assume that this lack of competition results > in a lack of innovation. > > > >Where would something like the HP actually make sense? For stuff that > > >has external dependencies that are not easily installable with > > >cabal-install (like curses bindings, SSL support, etc.). We have none > > >of this in the HP. So I think currently we just have additional costs, > > >but no benefits (+ we harm innovation by arbitrarily "endorsing" random > > >packages). > > > > I understand this point of view, but allow me to offer an opposing one. > > By putting packages with external dependencies into Haskell Platform, we > > often increase the dependencies of Haskell Platform itself. For example, > > Haskell Platform currently includes Graphics packages; installing Haskell > > Platform on a server entails installing a number of OpenGL libraries that > > are never used. > > My point here was that (from my perspective) the cost/benefit ratio of > bundling packages that are easily installable with cabal-install is > negative. > > Cheers, > Simon > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djsamperi at gmail.com Wed Apr 16 05:08:48 2014 From: djsamperi at gmail.com (Dominick Samperi) Date: Wed, 16 Apr 2014 01:08:48 -0400 Subject: [Haskell-cafe] hsc2hs behaves differently under Windows? In-Reply-To: References: Message-ID: To answer my own question, one work-around (not a convenient one) is to list parameters multiple times after the format string in such a way that the desired params appear in the right order. On Tue, Apr 15, 2014 at 11:42 PM, Dominick Samperi wrote: > It seems that hsc2hs behaves differently under Windows > (when compared with Linux), causing build problems. > > An example foo.hsc is attached, along with the foo.hs > that is generated using hsc2hs under Windows. > > Note the expressions my_$s in the result. It appears > that under Windows the %n$s POSIX printf notation > is not recognized. The correctly generated file that > is produced under Linux is also attached, in > foo-linux.hs. Note that proper substitution happens > here. > > Is there a work-around for this Windows issue? > > Thanks, > Dominick From travis.cardwell at extellisys.com Wed Apr 16 05:26:58 2014 From: travis.cardwell at extellisys.com (Travis Cardwell) Date: Wed, 16 Apr 2014 14:26:58 +0900 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: References: <534C8CD8.1060108@extellisys.com> Message-ID: <534E14A2.2080507@extellisys.com> On 2014?04?16? 09:56, Mikhail Glushenkov wrote: > On 15 April 2014 03:35, Travis Cardwell wrote: >> In a recent /r/haskell post [1], user mightybyte commented: >>> This. The Haskell Platform installs a bunch of packages for you in >>> --global. My experience is that this inevitably leads to problems if >>> you're doing significant Haskell development. The best thing to do is >>> to minimize the number of packages installed as --global. The way to do >>> that is to install GHC directly and avoid using the Haskell Platform or >>> Haskell distributions provided by your OS. > > The post you quote doesn't provide information about specific problems > with this setup. I'd be interested to hear about them. Personally, I have not run into problems either, as newer versions of packages can be installed into sandboxes. I BCCed the original commenter, to make sure that he is aware of this thread, and I put a request for specific examples of problems in the Reddit discussion: http://www.reddit.com/r/haskell/comments/23224w/minimal_haskell_platform/ I also asked in #haskell, but nobody who is currently online seems to have examples. Cheers, Travis From travis.cardwell at extellisys.com Wed Apr 16 05:58:23 2014 From: travis.cardwell at extellisys.com (Travis Cardwell) Date: Wed, 16 Apr 2014 14:58:23 +0900 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: References: <534C8CD8.1060108@extellisys.com> <20140415050238.GA16708@x200> <20140415084522.GA10244@sniper> Message-ID: <534E1BFF.1000008@extellisys.com> On 2014?04?16? 01:31, Mike Meyer wrote: > This points out at least one other benefit of HP: it provides a larger > set of libraries for people learning Haskell to get started with > before having to learn how to deal with cabal and the possibilities of > cabal hell. > > It may be that this isn't real - that the recent and good or popular > tutorials all work fine with just GHC, in which case ignore me. On > the other hand, if they all deal with cabal at one point or another, > possibly HP needs better curation: audit what's there to make sure > it's the best choice, drop things that aren't useful, expand it to include > critical libraries that are required by the tutorials, etc. There are indeed packages in Haskell Platform that are beneficial for beginners who may not want to have to deal with Cabal yet: HUnit and QuickCheck. By the way, I do not think that using Cabal is particularly troublesome these days, as long as sandboxes are used. Perhaps it becomes difficult to use on Windows, but blaming Cabal for that would be like blaming a flower for the poor smell of the manure in which it is planted... We try to engineer the smell of the flower to cover the smell of the manure, but the strong flower smell can be overwhelming in cleaner environments. ;) Cheers, Travis From michael at snoyman.com Wed Apr 16 06:05:05 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 16 Apr 2014 09:05:05 +0300 Subject: [Haskell-cafe] Current status of Mavericks CPP Message-ID: I still seem to be getting bug reports about the CPP implementation of Mavericks. Last I'd heard, it seemed that general consensus was that packages should *not* be patched to work around the different CPP implementation, and instead Mavericks users should be installing GCC's CPP. Is this accurate? And is there a wiki page somewhere describing the situation and how to work around it? I'd like to have some authoritative URL to point people to, especially given that I have no access to a Mac system and therefore can't test this myself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Wed Apr 16 06:15:11 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 16 Apr 2014 09:15:11 +0300 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: Message-ID: <20140416061511.GA21052@sniper> * Michael Snoyman [2014-04-16 09:05:05+0300] > I still seem to be getting bug reports about the CPP implementation of > Mavericks. Last I'd heard, it seemed that general consensus was that > packages should *not* be patched to work around the different CPP > implementation, and instead Mavericks users should be installing GCC's CPP. > > Is this accurate? And is there a wiki page somewhere describing the > situation and how to work around it? I'd like to have some authoritative > URL to point people to, especially given that I have no access to a Mac > system and therefore can't test this myself. FWIW, the /topic on #haskell says: XCode 5 issues? http://www.haskell.org/platform/mac.html I wonder whether the problem was addressed by GHC 7.8 in any way. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From allbery.b at gmail.com Wed Apr 16 06:16:41 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 16 Apr 2014 02:16:41 -0400 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: Message-ID: On Wed, Apr 16, 2014 at 2:05 AM, Michael Snoyman wrote: > I still seem to be getting bug reports about the CPP implementation of > Mavericks. Last I'd heard, it seemed that general consensus was that > packages should *not* be patched to work around the different CPP > implementation, and instead Mavericks users should be installing GCC's CPP. > > Is this accurate? And is there a wiki page somewhere describing the > situation and how to work around it? I'd like to have some authoritative > URL to point people to, especially given that I have no access to a Mac > system and therefore can't test this myself. > The correct answer is for ghc 7.8 to become established, because it removes the dependency on an external C preprocessor. Some of the reasons for this are: - with FreeBSD 10 having moved to clang on x86 / x86_64, it is clearly only a matter of time before this becomes more than just a "Mavericks" issue; - pretty much everyone *except* the Haskell community accepted that expecting cpp to handle anything other than C and derivatives was a mistake back when ANSI C came out; - even with a K&R-style cpp like gcc -traditional, there are Haskell constructs that can break it; consider that it must know how to parse strings (there are some subtle differences between Haskell and C string syntax) and char constants (did you know that C allows multi-character (char) constants? and pretty much always has?) in order to know when to expand macros. With an ANSI cpp like clang's, it must also know when to interpret # and ## as splices. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Apr 16 06:25:38 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 16 Apr 2014 02:25:38 -0400 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: Message-ID: Further more, once some patches I've cooked up land in 7.8.3, it will be possible to ship ghc with it's own cpp program (or use GCC or clang cpp) Austin's 7.8.2 mavericks build will correctly handle / cope with clangs cpp, but there's a clear concensus to evolve Haskell cpp tooling going forward to avoid these issues in the future For those on ghc 7.6 or earlier who can't upgrade to ghc 7.8, the work arounds listed on the platform site are the current options. On Wednesday, April 16, 2014, Brandon Allbery wrote: > On Wed, Apr 16, 2014 at 2:05 AM, Michael Snoyman > > wrote: > >> I still seem to be getting bug reports about the CPP implementation of >> Mavericks. Last I'd heard, it seemed that general consensus was that >> packages should *not* be patched to work around the different CPP >> implementation, and instead Mavericks users should be installing GCC's CPP. >> >> Is this accurate? And is there a wiki page somewhere describing the >> situation and how to work around it? I'd like to have some authoritative >> URL to point people to, especially given that I have no access to a Mac >> system and therefore can't test this myself. >> > > The correct answer is for ghc 7.8 to become established, because it > removes the dependency on an external C preprocessor. Some of the reasons > for this are: > > - with FreeBSD 10 having moved to clang on x86 / x86_64, it is clearly > only a matter of time before this becomes more than just a "Mavericks" > issue; > > - pretty much everyone *except* the Haskell community accepted that > expecting cpp to handle anything other than C and derivatives was a mistake > back when ANSI C came out; > > - even with a K&R-style cpp like gcc -traditional, there are Haskell > constructs that can break it; consider that it must know how to parse > strings (there are some subtle differences between Haskell and C string > syntax) and char constants (did you know that C allows multi-character > (char) constants? and pretty much always has?) in order to know when to > expand macros. With an ANSI cpp like clang's, it must also know when to > interpret # and ## as splices. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Wed Apr 16 06:28:38 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 16 Apr 2014 15:28:38 +0900 (JST) Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: Message-ID: <20140416.152838.99400325763693819.kazu@iij.ad.jp> Hi Michael, > I still seem to be getting bug reports about the CPP implementation of > Mavericks. Last I'd heard, it seemed that general consensus was that > packages should *not* be patched to work around the different CPP > implementation, and instead Mavericks users should be installing GCC's CPP. > > Is this accurate? And is there a wiki page somewhere describing the > situation and how to work around it? I'd like to have some authoritative > URL to point people to, especially given that I have no access to a Mac > system and therefore can't test this myself. Mavericks users *must* install ghc-clang-wrapper provided by HP: http://www.haskell.org/platform/mac.html This scripts passes "-E -undef -x assembler-with-cpp" to CPP (clang) which solves many problems of CPP. If ghc-clang-wrapper causes problems with your code, I'd suggest to fix your code. I'm not sure this actually happens. Also, Haskell users should install the latest happy and alex. For more information, please read: http://www.haskell.org/pipermail/ghc-devs/2013-November/003300.html --Kazu From allbery.b at gmail.com Wed Apr 16 06:30:01 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 16 Apr 2014 02:30:01 -0400 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: Message-ID: On Wed, Apr 16, 2014 at 2:16 AM, Brandon Allbery wrote: > - pretty much everyone *except* the Haskell community accepted that > expecting cpp to handle anything other than C and derivatives was a mistake > back when ANSI C came out; > Having managed to completely omit the point of this observation: the C / C++ / ObjC / etc. communities are under no obligation whatsoever to ensure that their tools do anything sensible with Haskell code. Indeed, strict ANSI compliance prohibits doing so because of lexical differences such as ' being allowed in identifiers and # in operators (or identifiers with -XMagicHash). -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Apr 16 06:31:56 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 16 Apr 2014 02:31:56 -0400 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: <20140416.152838.99400325763693819.kazu@iij.ad.jp> References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> Message-ID: On Wed, Apr 16, 2014 at 2:28 AM, Kazu Yamamoto wrote: > If ghc-clang-wrapper causes problems with your code, I'd suggest to > fix your code. I'm not sure this actually happens. > It does. See my previous messages. Haskell is not C, and some Haskell constructs simply will not work with a program that must lex (and, for ANSI, parse) C code. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Apr 16 06:33:46 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 16 Apr 2014 09:33:46 +0300 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: Message-ID: So if I'm reading this all correctly: 1. Package authors are *not* encouraged to change their code to try and work around this issue. 2. Medium/long term, this won't be a problem at all due to changes in GHC itself. 3. Short term, users need to follow the instructions at [1] if they're using GHC 7.6 (or earlier?). [1] http://www.haskell.org/platform/mac.html On Wed, Apr 16, 2014 at 9:25 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Further more, once some patches I've cooked up land in 7.8.3, it will be > possible to ship ghc with it's own cpp program (or use GCC or clang cpp) > > Austin's 7.8.2 mavericks build will correctly handle / cope with clangs > cpp, but there's a clear concensus to evolve Haskell cpp tooling going > forward to avoid these issues in the future > > For those on ghc 7.6 or earlier who can't upgrade to ghc 7.8, the work > arounds listed on the platform site are the current options. > > > > On Wednesday, April 16, 2014, Brandon Allbery wrote: > >> On Wed, Apr 16, 2014 at 2:05 AM, Michael Snoyman wrote: >> >>> I still seem to be getting bug reports about the CPP implementation of >>> Mavericks. Last I'd heard, it seemed that general consensus was that >>> packages should *not* be patched to work around the different CPP >>> implementation, and instead Mavericks users should be installing GCC's CPP. >>> >>> Is this accurate? And is there a wiki page somewhere describing the >>> situation and how to work around it? I'd like to have some authoritative >>> URL to point people to, especially given that I have no access to a Mac >>> system and therefore can't test this myself. >>> >> >> The correct answer is for ghc 7.8 to become established, because it >> removes the dependency on an external C preprocessor. Some of the reasons >> for this are: >> >> - with FreeBSD 10 having moved to clang on x86 / x86_64, it is clearly >> only a matter of time before this becomes more than just a "Mavericks" >> issue; >> >> - pretty much everyone *except* the Haskell community accepted that >> expecting cpp to handle anything other than C and derivatives was a mistake >> back when ANSI C came out; >> >> - even with a K&R-style cpp like gcc -traditional, there are Haskell >> constructs that can break it; consider that it must know how to parse >> strings (there are some subtle differences between Haskell and C string >> syntax) and char constants (did you know that C allows multi-character >> (char) constants? and pretty much always has?) in order to know when to >> expand macros. With an ANSI cpp like clang's, it must also know when to >> interpret # and ## as splices. >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allbery.b at gmail.com >> ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Apr 16 06:38:21 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 16 Apr 2014 02:38:21 -0400 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: Message-ID: On Wed, Apr 16, 2014 at 2:33 AM, Michael Snoyman wrote: > So if I'm reading this all correctly: > > 1. Package authors are *not* encouraged to change their code to try and > work around this issue. > 2. Medium/long term, this won't be a problem at all due to changes in GHC > itself. > 3. Short term, users need to follow the instructions at [1] if they're > using GHC 7.6 (or earlier?). > Pretty much, although practically I suspect some packages *will* be changed to be compliant with clang's cpp simply because the community may not be able or willing to wait until the dependency on a C-parsing tool is removed. And there are some programs on Hackage which are broken even with the clang wrapper script because there is no way to tell clang's cpp not to recognize ANSI C splices (gcc's -traditional disables them) or to accept ' as a possible identifier character (someone earlier today on #haskell pointed out that they need to make sure there's an even number of ' characters on each line when using -XCPP... which makes sense when cpp needs to parse (char) constants). -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Wed Apr 16 06:42:34 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 16 Apr 2014 15:42:34 +0900 (JST) Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> Message-ID: <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Hi Brandon, >> If ghc-clang-wrapper causes problems with your code, I'd suggest to >> fix your code. I'm not sure this actually happens. > > It does. See my previous messages. Haskell is not C, and some Haskell > constructs simply will not work with a program that must lex (and, for > ANSI, parse) C code. I agree that ghc-clang-wrapper can cause problems and GHC should provide its own CPP. But have you ever experienced such problems actually? I have been using Mavericks just after it was released, and using both GHC 7.6.3 and GHC 7.8 (head in the past) with ghc-clang-wrapper/new alex/new happy. I have not experienced such problems so far. --Kazu From allbery.b at gmail.com Wed Apr 16 06:49:00 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 16 Apr 2014 02:49:00 -0400 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: <20140416.154234.1688972811072995946.kazu@iij.ad.jp> References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: On Wed, Apr 16, 2014 at 2:42 AM, Kazu Yamamoto wrote: > >> If ghc-clang-wrapper causes problems with your code, I'd suggest to > >> fix your code. I'm not sure this actually happens. > > > > It does. See my previous messages. Haskell is not C, and some Haskell > > constructs simply will not work with a program that must lex (and, for > > ANSI, parse) C code. > > I agree that ghc-clang-wrapper can cause problems and GHC should > provide its own CPP. But have you ever experienced such problems > actually? > I personally have not, but that's largely because I haven't really ever needed to use -XCPP. I did earlier today talk with someone on IRC who was running into one lexical incompatibility (Haskell's allowing ' to be an identifier character), and have in the past helped diagnose issues with the clang wrapper not working with some programs on Hackage which are incompatible with ANSI C (that ' issue, plus the use of # and ##). And I consider it nonsensical that people who need to use -XCPP to deal with different library versions or language extensions are restricted to that subset of Haskell which is lexically compatible with C. The problem here is not those people's code; it is that we are relying on a tool which by its nature lexes C code, and using it on Haskell code. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tab at snarc.org Wed Apr 16 08:58:11 2014 From: tab at snarc.org (Vincent Hanquez) Date: Wed, 16 Apr 2014 09:58:11 +0100 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: <20140415084522.GA10244@sniper> References: <534C8CD8.1060108@extellisys.com> <20140415050238.GA16708@x200> <20140415084522.GA10244@sniper> Message-ID: <534E4623.1070809@snarc.org> On 2014-04-15 09:45, Roman Cheplyaka wrote: > * Simon Hengel [2014-04-15 13:02:38+0800] >>> Would it be worthwhile to create a "Minimal Haskell Platform" to >>> create a truly common platform that everybody would be happy using? >> I think most Haskell developers use a reasonably recent version of GHC >> (that would currently still be 7.6.3 for me) and the latest version of >> cabal-install. Everything else can be installed with cabal-install. >> >> So yes, I think we should just have an easy way to get that minimal >> setup (+ most importantly don't recommend something to beginners that we >> don't use ourself). >> >> Where would something like the HP actually make sense? For stuff that >> has external dependencies that are not easily installable with >> cabal-install (like curses bindings, SSL support, etc.). We have none >> of this in the HP. So I think currently we just have additional costs, >> but no benefits (+ we harm innovation by arbitrarily "endorsing" random >> packages). > Agreed. > > As Tillmann notes, HP is indispensable on Windows, but that is a side effect. > Indeed, HP as a simple way to conveniently install the bits that are otherwise > hard to install makes perfect sense. > > However, nowadays most attention goes not to that, but to choosing ordinary > cabal packages to be bundled with HP. I see little value in that. > > As a way to ensure the "installability" of packages, Stackage now does a far > greater job than HP by: > > - having much wider selection of packages, and making it almost trivial to > incorporate new ones; > - constantly building packages and running tests; > - notifying maintainers about broken packages and packages with restrictive > upper bounds. > > In other words, it ensures that Stackage packages are installable at any time > with cabal. (Well, strictly speaking, there may be a delay between when a > problem is reported by Michael and when it's fixed by the maintainer.) > > Apart from that, HP "arbitrarily endorses" its packages and forces them into > stability mode. Whether it is a good thing or not is another argument and > depends on one's perspective. I know that some people find it important (and > I'm well aware of their reasoning). > > Personally, with my hats of > > * an open source libraries developer/maintainer > * a personal Haskell user > * a commercial Haskell user > > on, I don't care about HP. The only time when I remember about it is when I > tell novices how they can "install Haskell". But again, this has nothing to do > with the bundled cabal packages, only with the way of installing ghc/cabal/etc. Agreed with Simon and Roman here, The initial goals of the HP were good, but I think a smaller minimal haskell HP/installer (really for windows) would make more sense now considering the situation. I think for something like the HP to be successful (according to its goals), you would need to have full time staff developing it together in one common place. So currently, it doesn't really provides batteries, but merely a base++ with an extra set of "random" packages (opengl, cgi, ..). And, at the same time, it doesn't provide that much more API stability either (across multiple versions of the HP). -- Vincent From ben.franksen at online.de Wed Apr 16 10:34:57 2014 From: ben.franksen at online.de (Ben Franksen) Date: Wed, 16 Apr 2014 12:34:57 +0200 Subject: [Haskell-cafe] Current status of Mavericks CPP References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: Brandon Allbery wrote: > On Wed, Apr 16, 2014 at 2:42 AM, Kazu Yamamoto wrote: >> >> If ghc-clang-wrapper causes problems with your code, I'd suggest to >> >> fix your code. I'm not sure this actually happens. >> > >> > It does. See my previous messages. Haskell is not C, and some Haskell >> > constructs simply will not work with a program that must lex (and, for >> > ANSI, parse) C code. >> >> I agree that ghc-clang-wrapper can cause problems and GHC should >> provide its own CPP. But have you ever experienced such problems >> actually? >> > > I personally have not, but that's largely because I haven't really ever > needed to use -XCPP. I did earlier today talk with someone on IRC who was > running into one lexical incompatibility (Haskell's allowing ' to be an > identifier character), and have in the past helped diagnose issues with > the clang wrapper not working with some programs on Hackage which are > incompatible with ANSI C (that ' issue, plus the use of # and ##). > > And I consider it nonsensical that people who need to use -XCPP to deal > with different library versions or language extensions are restricted to > that subset of Haskell which is lexically compatible with C. The problem > here is not those people's code; it is that we are relying on a tool which > by its nature lexes C code, and using it on Haskell code. I couldn't agree more. My experience in this area is very bad. I am maintaining a language that is very C-like (it has *almost* the same lexical syntax), and still I regularly encounter problems when CPP is used as a preprocessor for it, due to sudden changes that are made e.g. by the GNU folks that are compatible with C but not other languages. Furthermore, I strongly suggest that a suitable replacement for CPP should be designed in such a way that its specification can be added to a future Haskell language standard. This is the only way to ensure that implementations other than GHC can be brought along. Has nobody ever written a paper about how to extend Haskell with the few features we actually need from CPP? I think general macro replacement like CPP offers is not on the list, right? IIUC, CPP is used in Haskell libraries almost exclusively for conditional compilation. I think the syntax should be based on pragmas, like in {-# DEFINE WITH_FEATURE_X True #-} {-# IF WITH_FEATURE_X && GHC_VERSION >= 708 && GHC_VERSION < 712 #-} ... {-# ELSIF #-} ... {-# ENDIF #-} That's four new pragmas (IF, ELSIF, ENDIF, DEFINE). Expressions (in DEFINE, IF and ELSIF) must have type Bool (True, False) or Integer (decimal notation only), identifiers must be ASCII (letter, followed by any amount of '_' or letter or decimal). Writing an evaluator for such expressions is an exercise for beginners. There is no need for such a CPP-replacement to be able to parse (nor even lex) all of Haskell; it just needs to understand lexing of Haskell string literals (so a pramga inside a string literal gets ignored) and comments. (Hmm, what about TH splices?) Existing Haskell implementations like GHC are of course free to integrate the preprocessing stage with normal compilation, making implementation even simpler. It's all very simple and nicely integrated. It would even be possible to write a tool that automatically converts existing Haskell modules that now use CPP directives to the new style (assuming the above is really the subset of CPP features that is actually used in practice). Cheers Ben -- "Make it so they have to reboot after every typo." -- Scott Adams From svenpanne at gmail.com Wed Apr 16 11:24:37 2014 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 16 Apr 2014 13:24:37 +0200 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: 2014-04-16 12:34 GMT+02:00 Ben Franksen : > [...]Has nobody ever written a paper about how to extend Haskell with the few > features we actually need from CPP? I think general macro replacement like > CPP offers is not on the list, right? IIUC, CPP is used in Haskell libraries > almost exclusively for conditional compilation. [...] Nope: https://github.com/haskell-opengl/OpenGLRaw/blob/master/include/HsOpenGLRaw.h Perhaps some template Haskell magic might work nowadays, bug there was no TH at all when the bindings started, and I am not sure if I should tie this package to GHC. The real solution is generating the binding via the OpenGL XML spec, anyway, but I somehow have to do some real (non-Haskell) work for real money. ;-) My point is: Do we really know that conditional compilation is *the* use case? I remember that in ancient days macros were used to generate instances etc. Make things as simple as possible, but not simpler. From waldmann at imn.htwk-leipzig.de Wed Apr 16 11:25:02 2014 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Wed, 16 Apr 2014 11:25:02 +0000 (UTC) Subject: [Haskell-cafe] Cabal/cabal-install 1.20 release candidates References: Message-ID: I am curious about the method used by cabal-install to distribute the compilation on several jobs (cores). By looking at the OS process list, I often see that initally, and at several times later, all cores are busy, but then there are states where only one job is running. That's presumably because all future compilations depend on this single job. Does cabal's scheduler take into account anything else besides the actual depencency relation - e.g., something about expected duration of compilations? (And would it help?) Oh, and I find it slightly annoying that I cannot see (from stdout) what actually is going on. I understand it's a design problem, and the current solution (showing just package names, not module names, for parallel builds) may indeed be better than printing too much. From haskell at ibotty.net Wed Apr 16 11:29:23 2014 From: haskell at ibotty.net (Tobias Florek) Date: Wed, 16 Apr 2014 13:29:23 +0200 Subject: [Haskell-cafe] extension to filter with external program (was: Current status of Mavericks CPP) In-Reply-To: References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: <534E6993.6020500@ibotty.net> hi, i may certainly be missing something, as i only used cpp in haskell for conditional compilation. having said that: i'd like to have (instead of LANGUAGE CPP) the following extension. LANGUAGE FilterWithExternalProgram my_cpp that would make it possible to use a cpp implementation implemented separately from ghc and would leave it to the ecosystem to implement best practices (i.e. a haskell implementation of cpp or the proposed declarative extension). i _guess_ that should also make it easier to use compile-to-haskell programs like she. maybe a hypothetical template haskell alternative might also work with it. regards, tobias florek From roma at ro-che.info Wed Apr 16 11:37:16 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 16 Apr 2014 14:37:16 +0300 Subject: [Haskell-cafe] extension to filter with external program (was: Current status of Mavericks CPP) In-Reply-To: <534E6993.6020500@ibotty.net> References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> <534E6993.6020500@ibotty.net> Message-ID: <20140416113716.GA27222@sniper> It's already possible (although I can't tell the exact flag off the top of my head ? look at the GHC docs for details). * Tobias Florek [2014-04-16 13:29:23+0200] > hi, > > i may certainly be missing something, as i only used cpp in haskell for > conditional compilation. having said that: > > i'd like to have (instead of LANGUAGE CPP) the following extension. > > LANGUAGE FilterWithExternalProgram my_cpp > > that would make it possible to use a cpp implementation implemented > separately from ghc and would leave it to the ecosystem to implement best > practices (i.e. a haskell implementation of cpp or the proposed declarative > extension). > > i _guess_ that should also make it easier to use compile-to-haskell programs > like she. maybe a hypothetical template haskell alternative might also work > with it. > > regards, > tobias florek > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Apr 16 11:53:36 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 16 Apr 2014 12:53:36 +0100 Subject: [Haskell-cafe] extension to filter with external program (was: Current status of Mavericks CPP) In-Reply-To: <534E6993.6020500@ibotty.net> References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> <534E6993.6020500@ibotty.net> Message-ID: <20140416115336.GK29519@weber> On Wed, Apr 16, 2014 at 01:29:23PM +0200, Tobias Florek wrote: > i'd like to have (instead of LANGUAGE CPP) the following extension. > > LANGUAGE FilterWithExternalProgram my_cpp I really don't want LANGUAGE pragmas running arbitrary programs on my computer. Regrettably there are already ways to get GHC to do this, but the fewer the better, in my opinion. Tom From the.dead.shall.rise at gmail.com Wed Apr 16 12:08:12 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Wed, 16 Apr 2014 14:08:12 +0200 Subject: [Haskell-cafe] Cabal/cabal-install 1.20 release candidates In-Reply-To: References: Message-ID: Hi, On 16 April 2014 13:25, Johannes Waldmann wrote: > Does cabal's scheduler take into account anything else besides the actual > depencency relation - e.g., something about expected duration of > compilations? No, it doesn't. > Oh, and I find it slightly annoying that I cannot see (from stdout) what > actually is going on. I understand it's a design problem, and the current > solution (showing just package names, not module names, for parallel builds) > may indeed be better than printing too much. Yes, this is a known issue [1]. Unfortunately, no-one has gotten around to fixing it yet. [1] https://github.com/haskell/cabal/issues/975 From the.dead.shall.rise at gmail.com Wed Apr 16 12:11:54 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Wed, 16 Apr 2014 14:11:54 +0200 Subject: [Haskell-cafe] extension to filter with external program (was: Current status of Mavericks CPP) In-Reply-To: <534E6993.6020500@ibotty.net> References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> <534E6993.6020500@ibotty.net> Message-ID: Hi, On 16 April 2014 13:29, Tobias Florek wrote: > hi, > > i may certainly be missing something, as i only used cpp in haskell for > conditional compilation. having said that: > > i'd like to have (instead of LANGUAGE CPP) the following extension. > > LANGUAGE FilterWithExternalProgram my_cpp Use custom preprocessor support in Cabal or 'ghc -cpp -pgmP /path/to/custom_cpp' . From the.dead.shall.rise at gmail.com Wed Apr 16 12:18:01 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Wed, 16 Apr 2014 14:18:01 +0200 Subject: [Haskell-cafe] extension to filter with external program (was: Current status of Mavericks CPP) In-Reply-To: References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> <534E6993.6020500@ibotty.net> Message-ID: Hi, On 16 April 2014 14:11, Mikhail Glushenkov wrote: > > Use custom preprocessor support in Cabal or 'ghc -cpp -pgmP > /path/to/custom_cpp' . Correction: A better method is to use '-F -pgmF /path/to/custom_cpp' [1]. Together with the OPTIONS_GHC pragma this gives you exactly what you requested. [1] http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/options-phases.html#pre-processor From ben.franksen at online.de Wed Apr 16 12:48:55 2014 From: ben.franksen at online.de (Ben Franksen) Date: Wed, 16 Apr 2014 14:48:55 +0200 Subject: [Haskell-cafe] Replacing CPP [was: Current status of Mavericks CPP] References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: Sven Panne wrote: > 2014-04-16 12:34 GMT+02:00 Ben Franksen : >> [...]Has nobody ever written a paper about how to extend Haskell with the >> [few >> features we actually need from CPP? I think general macro replacement >> like CPP offers is not on the list, right? IIUC, CPP is used in Haskell >> libraries almost exclusively for conditional compilation. [...] > > Nope: > https://github.com/haskell-opengl/OpenGLRaw/blob/master/include/HsOpenGLRaw.h Yes, I expected there are libraries out there that use more of CPP's features, just not very many. And note, I'm not proposing to deprecate CPP any time soon, just to offer a sane(r) alternative ASAP. > Perhaps some template Haskell magic might work nowadays, bug there was > no TH at all when the bindings started, and I am not sure if I should > tie this package to GHC. Agreed, you should not have to. > The real solution is generating the binding > via the OpenGL XML spec, anyway, but I somehow have to do some real > (non-Haskell) work for real money. ;-) I can relate to that, believe me. In the meantime, CPP will stay around for some time, for special use cases like yours. Its use would just no longer be encouraged for cases where it is not needed. BTW, I do not think that mixing conditional compilation and general macro replacements in the same tool is particularly good design. That CPP is used for both is an unfortunate accident of history and we should not try to repeat that. > My point is: Do we really know that conditional compilation is *the* > use case? I remember that in ancient days macros were used to generate > instances etc. Make things as simple as possible, but not simpler. Well, what everybody said whenever the question came up in the last years was that this is the killer feature we absolutely can't live without. But you are right, we should find out! There are people on this list who grep the whole of hackage in a matter of minutes whenever someone (seriously) proposes some non-compatible change to see who many libraries would be affected. (Any volunteers?) My guess is that no more than a few hands full of the hackage packages use more than conditional compilation, but I may be completely wrong about that. Cheers Ben -- "Make it so they have to reboot after every typo." -- Scott Adams From hesselink at gmail.com Wed Apr 16 13:03:43 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Wed, 16 Apr 2014 15:03:43 +0200 Subject: [Haskell-cafe] Replacing CPP [was: Current status of Mavericks CPP] In-Reply-To: References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: On Wed, Apr 16, 2014 at 2:48 PM, Ben Franksen wrote: > There are people on this list who grep the whole of hackage in a matter of > minutes whenever someone (seriously) proposes some non-compatible change to > see who many libraries would be affected. (Any volunteers?) My guess is that > no more than a few hands full of the hackage packages use more than > conditional compilation, but I may be completely wrong about that. I think some core packages like base and (IIRC) containers use CPP to define instances and such. One conditional compilation feature that's used relatively often and not covered by your earlier proposal is bounds checks on libraries through cabal. It could be handled the same way as GHC versions, of course, but I think the triple of version numbers is a bit more 'correct' and flexible. Erik From ben.franksen at online.de Wed Apr 16 13:19:10 2014 From: ben.franksen at online.de (Ben Franksen) Date: Wed, 16 Apr 2014 15:19:10 +0200 Subject: [Haskell-cafe] Replacing CPP [was: Current status of Mavericks CPP] References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: Erik Hesselink wrote: > On Wed, Apr 16, 2014 at 2:48 PM, Ben Franksen > wrote: >> There are people on this list who grep the whole of hackage in a matter >> of minutes whenever someone (seriously) proposes some non-compatible >> change to see who many libraries would be affected. (Any volunteers?) My >> guess is that no more than a few hands full of the hackage packages use >> more than conditional compilation, but I may be completely wrong about >> that. > > I think some core packages like base and (IIRC) containers use CPP to > define instances and such. Ok, these would still have to use CPP, until we have something more suitable. > One conditional compilation feature that's used relatively often and > not covered by your earlier proposal is bounds checks on libraries > through cabal. It could be handled the same way as GHC versions, of > course, but I think the triple of version numbers is a bit more > 'correct' and flexible. Can you point me to an example or some documentation? I am not too familiar with advanced cabal usage... Cheers Ben -- "Make it so they have to reboot after every typo." -- Scott Adams From allbery.b at gmail.com Wed Apr 16 13:47:37 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 16 Apr 2014 09:47:37 -0400 Subject: [Haskell-cafe] Replacing CPP [was: Current status of Mavericks CPP] In-Reply-To: References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: On Wed, Apr 16, 2014 at 9:19 AM, Ben Franksen wrote: > Erik Hesselink wrote: > > One conditional compilation feature that's used relatively often and > > not covered by your earlier proposal is bounds checks on libraries > > through cabal. It could be handled the same way as GHC versions, of > > course, but I think the triple of version numbers is a bit more > > 'correct' and flexible. > > Can you point me to an example or some documentation? I am not too familiar > with advanced cabal usage... http://www.haskell.org/cabal/users-guide/developing-packages.html#conditional-compilation which is actually the most common use of -XCPP in my experience, so it really needs to be supported. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Apr 16 14:00:05 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 16 Apr 2014 10:00:05 -0400 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: On Wed, Apr 16, 2014 at 7:24 AM, Sven Panne wrote: > My point is: Do we really know that conditional compilation is *the* > use case? I remember that in ancient days macros were used to generate > instances etc. Make things as simple as possible, but not simpler. > It's the most common one but pretty sure it's not the only one --- and, supporting conditional compilation may involve only a tiny subset of cpp in the user's code, but a fair bit more in terms of what cabal-install has to generate for those triplet macros to exist for user code to use. There are ANSI features we don't need (assertions, token splicing) but everything else probably gets used one way or another. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Apr 16 14:02:47 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 16 Apr 2014 10:02:47 -0400 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: On Wed, Apr 16, 2014 at 10:00 AM, Brandon Allbery wrote: > are ANSI features we don't need (assertions, token splicing) but > everything else probably gets used one way or another. > And, come to think of it, I can't swear someone's debugging messages module doesn't use token splicing somehow to generate strings for Debug.Trace or error.... -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Wed Apr 16 14:04:39 2014 From: ben.franksen at online.de (Ben Franksen) Date: Wed, 16 Apr 2014 16:04:39 +0200 Subject: [Haskell-cafe] Replacing CPP [was: Current status of Mavericks CPP] References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: Brandon Allbery wrote: > On Wed, Apr 16, 2014 at 9:19 AM, Ben Franksen > wrote: > >> Erik Hesselink wrote: >> > One conditional compilation feature that's used relatively often and >> > not covered by your earlier proposal is bounds checks on libraries >> > through cabal. It could be handled the same way as GHC versions, of >> > course, but I think the triple of version numbers is a bit more >> > 'correct' and flexible. >> >> Can you point me to an example or some documentation? I am not too >> familiar with advanced cabal usage... > > > http://www.haskell.org/cabal/users-guide/developing-packages.html#conditional-compilation > > which is actually the most common use of -XCPP in my experience, so it > really needs to be supported. I see. Thanks. I'll have to think some more about how to support that w/o unduly complicating everything. Cheers Ben -- "Make it so they have to reboot after every typo." -- Scott Adams From mwm at mired.org Wed Apr 16 14:38:28 2014 From: mwm at mired.org (Mike Meyer) Date: Wed, 16 Apr 2014 09:38:28 -0500 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: On Apr 16, 2014 5:35 AM, "Ben Franksen" wrote: > Furthermore, I strongly suggest that a suitable replacement for CPP should > be designed in such a way that its specification can be added to a future > Haskell language standard. This is the only way to ensure that > implementations other than GHC can be brought along. Do we need a Haskell-specific language preprocessor, or just one that's designed to be a general purpose preprocessor instead of specific to some language that's not Haskell? For instance, m4 should be available on most Unix-like systems, and wouldn't have most of the problems I've seen mentioned here. Not allowing single quotes in its variable names would still happen, but those should be lexically distinct from Haskell variables. -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm.wallace at me.com Wed Apr 16 14:42:14 2014 From: malcolm.wallace at me.com (malcolm.wallace) Date: Wed, 16 Apr 2014 14:42:14 +0000 (GMT) Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: Message-ID: My experience with receiving bug reports for cpphs is certainly that Haskell people use every imaginable feature of cpp. ?Initially, cpphs supported only conditional compilation. ?But then some macros started to appear, so I made that a separate pass. ?And then the conditional compilation started to depend on the values of the macros, so I had to fold the passes together somehow. ?And so on. ?I can confirm that token splicing is definitely used by someone, because I received the feature request. Regards, Malcolm On 16 Apr, 2014,at 03:00 PM, Brandon Allbery wrote: On Wed, Apr 16, 2014 at 7:24 AM, Sven Panne wrote: My point is: Do we really know that conditional compilation is *the* use case? I remember that in ancient days macros were used to generate instances etc. Make things as simple as possible, but not simpler. It's the most common one but pretty sure it's not the only one --- and, supporting conditional compilation may involve only a tiny subset of cpp in the user's code, but a fair bit more in terms of what cabal-install has to generate for those triplet macros to exist for user code to use. There are ANSI features we don't need (assertions, token splicing) but everything else probably gets used one way or another. -- brandon s allbery kf8nh ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? sine nomine associates allbery.b at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad ? ? ? ?http://sinenomine.net _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Apr 16 14:42:23 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 16 Apr 2014 10:42:23 -0400 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: I'd like to point out that cpphs is a thing. And that the near term plans for ghc are likely to lean on cpphs. A huge constraint is that ghc and many other Haskell code bases use cpp, and unless we migrate everything any near term choice will essentially be a Haskell aware cpp. On Wednesday, April 16, 2014, Mike Meyer wrote: > On Apr 16, 2014 5:35 AM, "Ben Franksen" > > wrote: > > Furthermore, I strongly suggest that a suitable replacement for CPP > should > > be designed in such a way that its specification can be added to a future > > Haskell language standard. This is the only way to ensure that > > implementations other than GHC can be brought along. > > Do we need a Haskell-specific language preprocessor, or just one that's > designed to be a general purpose preprocessor instead of specific to some > language that's not Haskell? For instance, m4 should be available on most > Unix-like systems, and wouldn't have most of the problems I've seen > mentioned here. Not allowing single quotes in its variable names would > still happen, but those should be lexically distinct from Haskell variables. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tab at snarc.org Wed Apr 16 14:58:23 2014 From: tab at snarc.org (Vincent Hanquez) Date: Wed, 16 Apr 2014 15:58:23 +0100 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> Message-ID: <534E9A8F.7000201@snarc.org> On 2014-04-16 15:42, Carter Schonwald wrote: > I'd like to point out that cpphs is a thing. And that the near term > plans for ghc are likely to lean on cpphs. > > A huge constraint is that ghc and many other Haskell code bases use > cpp, and unless we migrate everything any near term choice will > essentially be a Haskell aware cpp. I don't think anyone want to remove cpp anyhow in a near term. I think this exercise is about offering another preprocessor that would be more suited to preprocess haskell (HPP). Once ghc (or some standard) add this {-# LANGUAGE HPP #-} feature, projects can start migrating to the saner solution in their own time. -- Vincent From jan.stolarek at p.lodz.pl Wed Apr 16 15:19:30 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 16 Apr 2014 17:19:30 +0200 Subject: [Haskell-cafe] Autocomplete command line options with GHC 7.8 Message-ID: <201404161719.30203.jan.stolarek@p.lodz.pl> Hi all, GHC 7.8 adds --show-options flag that prints all supported command line flags on standard output. This can be used to enable autocompletion of command line options for ghc in shells that support autocompletion. If you're using bash add this snippet to your ~/.bashrc file: <<<<<<<<<<<<< START # Autocomplete GHC commands _ghc() { local envs=`ghc --show-options` # get the word currently being completed local cur=${COMP_WORDS[$COMP_CWORD]} # the resulting completions should be put into this array COMPREPLY=( $( compgen -W "$envs" -- $cur ) ) } complete -F _ghc -o default ghc <<<<<<<<<<<< END Enjoy. Janek PS. I also added a wiki page: https://ghc.haskell.org/trac/ghc/wiki/AutocompleteGHCFlags Feel free to add instructions for other shells. From carter.schonwald at gmail.com Wed Apr 16 15:23:11 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 16 Apr 2014 11:23:11 -0400 Subject: [Haskell-cafe] Current status of Mavericks CPP In-Reply-To: <534E9A8F.7000201@snarc.org> References: <20140416.152838.99400325763693819.kazu@iij.ad.jp> <20140416.154234.1688972811072995946.kazu@iij.ad.jp> <534E9A8F.7000201@snarc.org> Message-ID: That experimentation will become much easier in 7.8.3 :-) Because some patches that decouple cpp from the c compiler should land On Wednesday, April 16, 2014, Vincent Hanquez wrote: > On 2014-04-16 15:42, Carter Schonwald wrote: > >> I'd like to point out that cpphs is a thing. And that the near term >> plans for ghc are likely to lean on cpphs. >> >> A huge constraint is that ghc and many other Haskell code bases use cpp, >> and unless we migrate everything any near term choice will essentially be a >> Haskell aware cpp. >> > > I don't think anyone want to remove cpp anyhow in a near term. > I think this exercise is about offering another preprocessor that would be > more suited to preprocess haskell (HPP). > > Once ghc (or some standard) add this {-# LANGUAGE HPP #-} feature, > projects can start migrating to the saner solution in their own time. > > -- > Vincent > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barak at cs.nuim.ie Wed Apr 16 15:24:27 2014 From: barak at cs.nuim.ie (Barak A. Pearlmutter) Date: Wed, 16 Apr 2014 16:24:27 +0100 Subject: [Haskell-cafe] Directed rounding in haskell ? Message-ID: <87mwflqous.fsf@cs.nuim.ie> One issue that arises with rounding modes in a pure lazy language like Haskell is that it's pretty hard to nail down the semantics. The "round towards negative infinity" mode is a dynamic hardware feature, available by setting a rounding mode flag in the FPU. If you execute some hunk of code with that flag having different values, you will in general get different results. So if you try to do this in Haskell, you have to decide how to expose it without violating purity. This would break things: roundWith :: RoundMode -> ( () -> a) -> a consider let x = 0.1 + 0.2 in roundWith NegInfty (\_ -> x) vs roundWith NegInfty (\_ -> 0.1 + 0.2) So you need to make different numeric types. This is what Ed Kmett's "rounding" cabal package does, albeit in a much more general way where the new floating types are parameterized by both rounding mode and precision. The bottom line is that IEEE Floating Point numbers are actually a monad. There is NaN, which makes them a Maybe, or given that there are many NaNs perhaps an Either. And there is the rounding mode, which is sort of a Reader. As an aside, changing the rounding mode flags can be surprisingly slow on modern CPUs. One trick for doing interval arithmetic efficiently is to set the flags once, say to TowardInf. Then x*y computes the product of x and y rounding towards positive infinity while -((-x)*y) computes the same product rounding towards negative infinity without fiddling with the rounding mode. So for adding intervals, instead of Interval x0 x1 + Interval y0 y1 = Interval (x0+y0) (x1+y1) Interval x0 x1 * Interval y0 y1 | x0 >= 0 && y0 >= 0 = Interval (x0*y0) (x1*y1) -- etc but with some added hair to fiddle with the rounding modes, one leaves the rounding mode fixed and writes Interval x0 x1 + Interval y0 y1 = Interval (-(-x0-y0)) (x1+y1) Interval x0 x1 * Interval y0 y1 | x0 >= 0 && y0 >= 0 = Interval (-((-x0)*y0)) (x1*y1) -- etc As a final throwaway, allowing (Interval x0 x1) where x0>x1, i.e., improper intervals, gives a very pleasant system with a surprisingly nice and rich semantics. For example, Interval 1 2 - Interval 2 1 = Interval 0 0 which makes for a group rather than just a semigroup. The system is known variously as modal intervals, Kaucher intervals, directed interval arithmetic, or generalized interval arithmetic, and can be used to automatically prove interesting arithmetic properties full of ?s and ?s. -- Barak A. Pearlmutter Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/ From philip.dexter at gmail.com Wed Apr 16 16:03:38 2014 From: philip.dexter at gmail.com (Philip Dexter) Date: Wed, 16 Apr 2014 12:03:38 -0400 (EDT) Subject: [Haskell-cafe] Autocomplete command line options with GHC 7.8 In-Reply-To: <201404161719.30203.jan.stolarek@p.lodz.pl> References: <201404161719.30203.jan.stolarek@p.lodz.pl> Message-ID: On Wed, 16 Apr 2014, Jan Stolarek wrote: > PS. I also added a wiki page: https://ghc.haskell.org/trac/ghc/wiki/AutocompleteGHCFlags > Feel free to add instructions for other shells. Zsh autocompletion resides on the haskell wiki [1]. There are also updated versions of both _cabal and _ghc (PR pending) at [2]. _ghc also includes completions for ghci and ghc-pkg. [1] http://www.haskell.org/haskellwiki/Zsh [2] https://github.com/zsh-users/zsh-completions ps - I tried to register on trac to add this info to your page but my registration was marked as spam (even after answering a math question) From jan.stolarek at p.lodz.pl Wed Apr 16 16:49:41 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 16 Apr 2014 18:49:41 +0200 Subject: [Haskell-cafe] Autocomplete command line options with GHC 7.8 In-Reply-To: References: <201404161719.30203.jan.stolarek@p.lodz.pl> Message-ID: <201404161849.41679.jan.stolarek@p.lodz.pl> Thanks Philip. > ps - I tried to register on trac to add this info to your page but my > registration was marked as spam (even after answering a math question) I believe you have to contact Herbert about that (CC'd). In the meantime I added this information to GHC wiki, although it would be nice to be able to use --show-options under zsh as well. From my understanding scripts that you linked to need to be manually updated, whereas --show-options displays all flags defined in the code of GHC. Janek From philip.dexter at gmail.com Wed Apr 16 16:54:48 2014 From: philip.dexter at gmail.com (Philip Dexter) Date: Wed, 16 Apr 2014 12:54:48 -0400 (EDT) Subject: [Haskell-cafe] Autocomplete command line options with GHC 7.8 In-Reply-To: <201404161849.41679.jan.stolarek@p.lodz.pl> References: <201404161719.30203.jan.stolarek@p.lodz.pl> <201404161849.41679.jan.stolarek@p.lodz.pl> Message-ID: On Wed, 16 Apr 2014, Jan Stolarek wrote: > In the meantime I added this information to GHC wiki, although it would be nice to be able to > use --show-options under zsh as well. From my understanding scripts that you linked to need to be > manually updated, whereas --show-options displays all flags defined in the code of GHC. Yes, that is true. There are tradeoffs. Zsh does provide a brief description of each auto-completed flag which you cannot achieve with --show-options. Perhaps it could be some sort of fallback where if an option and its description isn't provided, the plain result from --show-options could be used. Hmmm From alexey.muranov at gmail.com Wed Apr 16 22:25:00 2014 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Thu, 17 Apr 2014 00:25:00 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) Message-ID: Hello, i am completely new to Haskell, but i am somewhat fascinated by lambda-calculus and programming. For whatever it is worth, i would like to propose for discussion a syntax for "(flip ($))" operation in Haskell. I think that a good syntax would be "|^", for example: square x = x * x y = 3 |^ square -- y == 9 Explanation: * i would have suggested just ^, but it would conflict with number exponentiation, * it is rather common in mathematics to write function application in exponential notation: x ^ f instead of f(x), especially if f is an automorphism of some structure, * (flip ($)) is exactly the exponentiation of Church numerals, * in "The calculi of lambda-conversion", Alonzo Church uses the "shorthand" notation "[N^M]" for "(MN)", where M and N are lambda-terms. * I am probably not the only person missing the ability to apply functions from the right: http://stackoverflow.com/questions/1457140/haskell-composition-vs-fs-pipe-forward-operator Well, other notations i've thought of are "\^" and "~$". Alexey. From ok at cs.otago.ac.nz Wed Apr 16 23:38:48 2014 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 17 Apr 2014 11:38:48 +1200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: Message-ID: <4C1F44A0-E967-4324-B870-619D81A45BB7@cs.otago.ac.nz> On 17/04/2014, at 10:25 AM, Alexey Muranov wrote: > For whatever it is worth, i would like to propose for discussion a syntax for "(flip ($))" operation in Haskell. Oh, you mean like F#'s "|>" operator? > (|>);; val it : ('a -> ('a -> 'b) -> 'b) = > (<|);; val it : (('a -> 'b) -> 'a -> 'b) = > I think that a good syntax would be "|^", for example: If we were to copy an operator from F#, it would have been nice to copy the F# name for it. Sadly, Data.Sequence already uses |> . Hoogle doesn't find a (|^), so that might work. I will say, however, that whenever I've read chunks of F# with long chains of |> operators, I've wanted to rewrite them using point-free style. From t at tmh.cc Wed Apr 16 23:43:45 2014 From: t at tmh.cc (Taylor Hedberg) Date: Wed, 16 Apr 2014 16:43:45 -0700 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: Message-ID: lens defines & for this purpose (not that one would want to pull in the behemoth that is lens as a dependency just for that). On Wed, Apr 16, 2014 at 3:25 PM, Alexey Muranov wrote: > Hello, > > i am completely new to Haskell, but i am somewhat fascinated by > lambda-calculus and programming. > > For whatever it is worth, i would like to propose for discussion a syntax > for "(flip ($))" operation in Haskell. > > I think that a good syntax would be "|^", for example: > > square x = x * x > y = 3 |^ square -- y == 9 > > > Explanation: > > * i would have suggested just ^, but it would conflict with number > exponentiation, > > * it is rather common in mathematics to write function application in > exponential notation: x ^ f instead of f(x), especially if f is an > automorphism of some structure, > > * (flip ($)) is exactly the exponentiation of Church numerals, > > * in "The calculi of lambda-conversion", Alonzo Church uses the > "shorthand" notation "[N^M]" for "(MN)", where M and N are lambda-terms. > > * I am probably not the only person missing the ability to apply functions > from the right: > > http://stackoverflow.com/questions/1457140/haskell-composition-vs-fs-pipe-forward-operator > > Well, other notations i've thought of are "\^" and "~$". > > Alexey. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.muranov at gmail.com Wed Apr 16 23:49:16 2014 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Wed, 16 Apr 2014 16:49:16 -0700 (PDT) Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <4C1F44A0-E967-4324-B870-619D81A45BB7@cs.otago.ac.nz> References: <4C1F44A0-E967-4324-B870-619D81A45BB7@cs.otago.ac.nz> Message-ID: <8a6cb833-84bf-4409-ae81-2ca1c9da80db@googlegroups.com> On Thursday, April 17, 2014 1:38:48 AM UTC+2, Richard A. O'Keefe wrote: > > On 17/04/2014, at 10:25 AM, Alexey Muranov wrote: > > For whatever it is worth, i would like to propose for discussion a > syntax for "(flip ($))" operation in Haskell. > > Oh, you mean like F#'s "|>" operator? > > If we were to copy an operator from F#, it would have been > nice to copy the F# name for it. Sadly, Data.Sequence > already uses |> . Hoogle doesn't find a (|^), so that might > work. > No, in fact i wanted to copy it from the exponential notation for function application. In particular, it would need to be right-associative: y |^ x |^ f == y |^ (x |^ f) == f x y Maybe a left-associative version can be defined too, by something like this: x ^| g ^| f == (x ^| (g |^ f) = f (g x) -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Wed Apr 16 23:49:31 2014 From: danburton.email at gmail.com (Dan Burton) Date: Wed, 16 Apr 2014 16:49:31 -0700 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: Message-ID: In the "lens" package, this is (&) at infixl 1. In the "diagrams" package, this is (#) at infixl 8. You're certainly not the first to want this, but nobody can ever agree what it should be called or what fixity it should have. You can always just define it yourself. -- Dan Burton On Wed, Apr 16, 2014 at 3:25 PM, Alexey Muranov wrote: > Hello, > > i am completely new to Haskell, but i am somewhat fascinated by > lambda-calculus and programming. > > For whatever it is worth, i would like to propose for discussion a syntax > for "(flip ($))" operation in Haskell. > > I think that a good syntax would be "|^", for example: > > square x = x * x > y = 3 |^ square -- y == 9 > > > Explanation: > > * i would have suggested just ^, but it would conflict with number > exponentiation, > > * it is rather common in mathematics to write function application in > exponential notation: x ^ f instead of f(x), especially if f is an > automorphism of some structure, > > * (flip ($)) is exactly the exponentiation of Church numerals, > > * in "The calculi of lambda-conversion", Alonzo Church uses the > "shorthand" notation "[N^M]" for "(MN)", where M and N are lambda-terms. > > * I am probably not the only person missing the ability to apply functions > from the right: > > http://stackoverflow.com/questions/1457140/haskell-composition-vs-fs-pipe-forward-operator > > Well, other notations i've thought of are "\^" and "~$". > > Alexey. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.muranov at gmail.com Wed Apr 16 23:56:37 2014 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Wed, 16 Apr 2014 16:56:37 -0700 (PDT) Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: Message-ID: <0569e94e-44b8-44a0-abe3-4bd7d80b2ed4@googlegroups.com> On Thursday, April 17, 2014 1:49:31 AM UTC+2, Dan Burton wrote: > In the "lens" package, this is (&) at infixl 1. In the "diagrams" package, > this is (#) at infixl 8. You're certainly not the first to want this, but > nobody can ever agree what it should be called or what fixity it should > have. You can always just define it yourself. > (#) does not look too bad either. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Thu Apr 17 01:41:01 2014 From: danburton.email at gmail.com (Dan Burton) Date: Wed, 16 Apr 2014 18:41:01 -0700 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <8a6cb833-84bf-4409-ae81-2ca1c9da80db@googlegroups.com> References: <4C1F44A0-E967-4324-B870-619D81A45BB7@cs.otago.ac.nz> <8a6cb833-84bf-4409-ae81-2ca1c9da80db@googlegroups.com> Message-ID: Interesting. I've never seen it proposed as right-associative before. Just FYI, the implementation is as simple as this: infixr 1 |^ (|^) :: a -> (a -> b) -> b x |^ f = f x Then you can write: 3 |^ 2 |^ (^) -- produces 2^3 = 8 It seems very odd to me. I don't know why you'd want to apply the arguments backwards one by one. However, lens and diagrams both provide examples where you want to start with a value and apply functions "forwards" one by one, which is why their corresponding operators are left-associative. -- Dan Burton On Wed, Apr 16, 2014 at 4:49 PM, Alexey Muranov wrote: > On Thursday, April 17, 2014 1:38:48 AM UTC+2, Richard A. O'Keefe wrote: > >> >> On 17/04/2014, at 10:25 AM, Alexey Muranov wrote: >> > For whatever it is worth, i would like to propose for discussion a >> syntax for "(flip ($))" operation in Haskell. >> >> Oh, you mean like F#'s "|>" operator? >> > > >> If we were to copy an operator from F#, it would have been >> nice to copy the F# name for it. Sadly, Data.Sequence >> already uses |> . Hoogle doesn't find a (|^), so that might >> work. >> > > No, in fact i wanted to copy it from the exponential notation for function > application. In particular, it would need to be right-associative: > > y |^ x |^ f == y |^ (x |^ f) == f x y > > Maybe a left-associative version can be defined too, by something like > this: > > x ^| g ^| f == (x ^| (g |^ f) = f (g x) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dstcruz at gmail.com Thu Apr 17 03:08:01 2014 From: dstcruz at gmail.com (Daniel Santa Cruz) Date: Wed, 16 Apr 2014 23:08:01 -0400 Subject: [Haskell-cafe] Haskell Weekly News: Issue 291 Message-ID: Welcome to issue 291 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from April 6 to 12, 2014 Quotes of the Week * geekosaur: IO, IO, it's off to (>>=) I go * edwardk: waiting for sclv to start going around door to door passing out little copies of the homotopy type theory book, and asking people if they have yet had the geometric realization that the simplicial sets are homotopically equivalent to their Lord and Savior. * carter: i'll leave you in the gentle hands of the rest of the channel Top Reddit Stories * GHC 7.8.1 Released Domain: haskell.org, Score: 226, Comments: 106 On Reddit: [1] http://goo.gl/pz4nE Original: [2] http://goo.gl/SjQ3Qv * What To Expect When You're a Platform Library Maintainer Domain: permalink.gmane.org, Score: 56, Comments: 4 On Reddit: [3] http://goo.gl/bD6VVf Original: [4] http://goo.gl/WDvy53 * Why are we relying on numeric identifiers for dependencies when we have so much richer information available? Domain: self.haskell, Score: 44, Comments: 18 On Reddit: [5] http://goo.gl/Z3gBEq Original: [6] http://goo.gl/Z3gBEq * How To Read "Pearls of Functional Algorithm Design" Domain: atamo.com, Score: 41, Comments: 8 On Reddit: [7] http://goo.gl/j4mXVz Original: [8] http://goo.gl/q41KEF * BayHac '14 Sign-Up and List of Classes Domain: self.haskell, Score: 40, Comments: 11 On Reddit: [9] http://goo.gl/xterjO Original: [10] http://goo.gl/xterjO * Is GHC the defacto standard? Domain: self.haskell, Score: 40, Comments: 39 On Reddit: [11] http://goo.gl/eiVjGM Original: [12] http://goo.gl/eiVjGM * Battleships web game written in Haskell/Yesod Domain: www-pg.iai.uni-bonn.de, Score: 34, Comments: 15 On Reddit: [13] http://goo.gl/hl2NC2 Original: [14] http://goo.gl/Wt5jqi * Heartbleed aftermath: should Haskell web frameworks allow using a pure Haskell SSL library instead of OpenSSL? Domain: self.haskell, Score: 32, Comments: 54 On Reddit: [15] http://goo.gl/ycHKNZ Original: [16] http://goo.gl/ycHKNZ * BudHac 2014 Domain: haskell.org, Score: 28, Comments: 3 On Reddit: [17] http://goo.gl/iObjrD Original: [18] http://goo.gl/KRJL2x * Hacking Haskell in nightclubs - video feature on Algorave Domain: motherboard.vice.com, Score: 27, Comments: 2 On Reddit: [19] http://goo.gl/LLG6qR Original: [20] http://goo.gl/PlzTTa * A brief introduction to ConstraintKinds extension (Wolfgang Jeltsch) Domain: jeltsch.wordpress.com, Score: 27, Comments: 4 On Reddit: [21] http://goo.gl/RadGh7 Original: [22] http://goo.gl/CZIfU8 * Generating Mazes with Inductive Graphs Domain: jelv.is, Score: 26, Comments: 11 On Reddit: [23] http://goo.gl/fufmgp Original: [24] http://goo.gl/FxAeGV Top StackOverflow Questions * Why MonadPlus and not Monad + Monoid? votes: 18, answers: 2 Read on SO: [25] http://goo.gl/J02Msv * Can a pure function have free variables? votes: 11, answers: 3 Read on SO: [26] http://goo.gl/iyJsn9 * FRP - Event streams and Signals - what is lost in using just signals? votes: 10, answers: 4 Read on SO: [27] http://goo.gl/cXwKKf * Is there a way to make GHC provide the type class constraints of typed holes? votes: 9, answers: 0 Read on SO: [28] http://goo.gl/LYxEvm * Where are the magic rules for GHC assert? votes: 8, answers: 1 Read on SO: [29] http://goo.gl/JL8OLZ * Using Haskell ranges: Why would mapping a floating point function across a range cause it to return an extra element? votes: 7, answers: 1 Read on SO: [30] http://goo.gl/mtBCBa * Why Haskell's Data.List.deleteBy takes in input a comparison function (a -> a -> Bool) and a value instead of a predicate (a -> Bool)? votes: 6, answers: 1 Read on SO: [31] http://goo.gl/Wd9evy Until next time, [32]+Daniel Santa Cruz References 1. http://www.haskell.org/pipermail/haskell/2014-April/024137.html 2. http://www.reddit.com/r/haskell/comments/22lw1b/ghc_781_released/ 3. http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/21681 4. http://www.reddit.com/r/haskell/comments/22oott/what_to_expect_when_youre_a_platform_library/ 5. http://www.reddit.com/r/haskell/comments/22o4i1/why_are_we_relying_on_numeric_identifiers_for/ 6. http://www.reddit.com/r/haskell/comments/22o4i1/why_are_we_relying_on_numeric_identifiers_for/ 7. http://www.atamo.com/blog/how-to-read-pearls-by-richard-bird-1/ 8. http://www.reddit.com/r/haskell/comments/22kavg/how_to_read_pearls_of_functional_algorithm_design/ 9. http://www.reddit.com/r/haskell/comments/22d1wu/bayhac_14_signup_and_list_of_classes/ 10. http://www.reddit.com/r/haskell/comments/22d1wu/bayhac_14_signup_and_list_of_classes/ 11. http://www.reddit.com/r/haskell/comments/22r569/is_ghc_the_defacto_standard/ 12. http://www.reddit.com/r/haskell/comments/22r569/is_ghc_the_defacto_standard/ 13. http://www-pg.iai.uni-bonn.de/battleships 14. http://www.reddit.com/r/haskell/comments/22f683/battleships_web_game_written_in_haskellyesod/ 15. http://www.reddit.com/r/haskell/comments/22udou/heartbleed_aftermath_should_haskell_web/ 16. http://www.reddit.com/r/haskell/comments/22udou/heartbleed_aftermath_should_haskell_web/ 17. http://www.haskell.org/haskellwiki/BudapestHackathon2014 18. http://www.reddit.com/r/haskell/comments/22euqt/budhac_2014/ 19. http://motherboard.vice.com/nl/read/algorave-coden-in-de-club 20. http://www.reddit.com/r/haskell/comments/22ou9y/hacking_haskell_in_nightclubs_video_feature_on/ 21. http://jeltsch.wordpress.com/2013/02/14/the-constraint-kind/ 22. http://www.reddit.com/r/haskell/comments/22tfgl/a_brief_introduction_to_constraintkinds_extension/ 23. http://jelv.is/blog/Generating-Mazes-with-Inductive-Graphs 24. http://www.reddit.com/r/haskell/comments/22ngz0/generating_mazes_with_inductive_graphs/ 25. http://stackoverflow.com/questions/23023961/why-monadplus-and-not-monad-monoid 26. http://stackoverflow.com/questions/22914878/can-a-pure-function-have-free-variables 27. http://stackoverflow.com/questions/22989253/frp-event-streams-and-signals-what-is-lost-in-using-just-signals 28. http://stackoverflow.com/questions/23028124/is-there-a-way-to-make-ghc-provide-the-type-class-constraints-of-typed-holes 29. http://stackoverflow.com/questions/22996814/where-are-the-magic-rules-for-ghc-assert 30. http://stackoverflow.com/questions/22901633/using-haskell-ranges-why-would-mapping-a-floating-point-function-across-a-range 31. http://stackoverflow.com/questions/23000665/why-haskells-data-list-deleteby-takes-in-input-a-comparison-function-a-a 32. https://plus.google.com/105107667630152149014/about -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Apr 17 03:22:14 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 16 Apr 2014 23:22:14 -0400 Subject: [Haskell-cafe] Haskell Weekly News: Issue 291 In-Reply-To: References: Message-ID: On Wed, Apr 16, 2014 at 11:08 PM, Daniel Santa Cruz wrote: > * geekosaur: IO, IO, it's off to (>>=) I go I thought we'd deleted that one... I was quoting one from a year or so ago. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From loupgaroublond at gmail.com Thu Apr 17 06:58:50 2014 From: loupgaroublond at gmail.com (Yaakov M Nemoy) Date: Wed, 16 Apr 2014 23:58:50 -0700 Subject: [Haskell-cafe] Minimal Haskell Platform In-Reply-To: References: <534DE3EF.3010904@extellisys.com> <534DE43F.4090908@extellisys.com> <20140416022858.GA3051@x200> Message-ID: <7CD1F5CD-55AE-49DB-91D8-B0610B5D5E57@gmail.com> Speaking as an ops guy who does manage said servers, i can tell you that sandboxing apps to let them run their own dependencies is going to be the future for ops. That said, I see the value of ?batteries included? because it?s great for anyone teaching anyone else which happens a lot. Having a consistent set of dependencies is also great for the systems engineers. These guys might be looking at a program?s performance in depth, so a server that may not have OpenGL installed still has a huge benefit in using a particular version of a library. The systems engineers can learn just that version of the code, understand its performance well and then pass on the requirements to the ops guys to install just enough packages and libraries in the sandbox to make the application work. The ops guys are happy because they know how many servers to provision and how the application is expected to scale because the systems engineers know every line of code in action, not just the application. So, is there value in minimal installs to facilitate sandboxing? Yup Is there an equal value in standardizing developers around specific sets of library-versions? Yup Is the future going to be ops installing Haskell Platform into a sandbox? No idea, but that?ll depend on the advocacy of Haskell Platform as the way for developers to write software, among other things Kind regards, Yaakov M Nemoy On Apr 15, 2014, at 21.52, Johan Holmquist wrote: > I strongly believe we need the HP to be able to compete with Python etc with "batteries included". Having a set of blessed packages with stable APIs makes development easier, so the HP is a very important part of the Haskell eco system IMHO. > > Having graphics packages in the platform does make it a bit wierd to install on servers which are typically not equipped with OpenGL etc. > > Johan > > > 2014-04-16 4:28 GMT+02:00 Simon Hengel : > > >and I have a somewhat cunning plan along these lines (related to some > > >other ghc-pkg/cabal improvement work) which might make that rather > > >easier > > > > > >what I want is for ghc itself to come with multiple profiles, with one > > >being the minimum (base + rts + deps), and that could be used as a basis > > >for new envs > > > > With such a feature, it sounds like we can get the best of both worlds: > > * a feature-rich Haskell Platform to support beginners > > * minimal sandboxes for advanced users > > The issue with such integrated approaches that affect the whole > toolchain (ghc, cabal, etc.) is that this can seriously harm innovation, > at least if the net result is that it gets harder and harder to write > alternative package managers, etc. > > TL;DR: If anything, we should make things *less integrated* (read more > open and hackable). > > Let me try to make my point by looking at Haddock. Let's assume you are > not happy with the current state of Haskell documentation tools. In > such a situation it can makes perfect sense to give it a fresh start. > But Haddock is so integrated with GHC, Hackage, Cabal,... that this is > very hard to do. You can write an alternate documentation tool, but it > may be hard for potential uses to experiment with it. Currently I think > the only feasible way to get your changes in or experiment with new > ideas is through the current maintainer, and if the current maintainer > thinks your approach is a bad idea or just does not like you or does not > have the time to look at your code you may be in a situation where it's > hard to improve things. There is a lack of competition and I think it > is not something absurd to assume that this lack of competition results > in a lack of innovation. > > > >Where would something like the HP actually make sense? For stuff that > > >has external dependencies that are not easily installable with > > >cabal-install (like curses bindings, SSL support, etc.). We have none > > >of this in the HP. So I think currently we just have additional costs, > > >but no benefits (+ we harm innovation by arbitrarily "endorsing" random > > >packages). > > > > I understand this point of view, but allow me to offer an opposing one. > > By putting packages with external dependencies into Haskell Platform, we > > often increase the dependencies of Haskell Platform itself. For example, > > Haskell Platform currently includes Graphics packages; installing Haskell > > Platform on a server entails installing a number of OpenGL libraries that > > are never used. > > My point here was that (from my perspective) the cost/benefit ratio of > bundling packages that are easily installable with cabal-install is > negative. > > Cheers, > Simon > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Apr 17 07:06:46 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 17 Apr 2014 09:06:46 +0200 Subject: [Haskell-cafe] Please test: Cabal/cabal-install 1.20 RC2 Message-ID: Hi all, The second, and hopefully last, release candidate for Cabal and cabal-install 1.20 is ready. If no issues are discovered, I plan to release this on Sunday, April 20th. You can help test by installing the release candidate and use it for your day-to-day work: cabal install http://johantibell.com/files/Cabal-1.20.0.0-rc2.tar.gz http://johantibell.com/files/cabal-install-1.20.0.0-rc2.tar.gz Please report any issues at https://github.com/haskell/cabal/issues -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From apfelmus at quantentunnel.de Thu Apr 17 08:23:05 2014 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Thu, 17 Apr 2014 10:23:05 +0200 Subject: [Haskell-cafe] Haskell Weekly News: Issue 291 In-Reply-To: References: Message-ID: Brandon Allbery wrote: > On Wed, Apr 16, 2014 at 11:08 PM, Daniel Santa Cruz wrote: > >> * geekosaur: IO, IO, it's off to (>>=) I go > > > I thought we'd deleted that one... I was quoting one from a year or so ago. Anyone who interferes with my precious weekly quotes will be (>>=)'d. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From alexey.muranov at gmail.com Thu Apr 17 08:48:35 2014 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Thu, 17 Apr 2014 10:48:35 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <4C1F44A0-E967-4324-B870-619D81A45BB7@cs.otago.ac.nz> <8a6cb833-84bf-4409-ae81-2ca1c9da80db@googlegroups.com> Message-ID: On 17 avr. 2014, at 03:41, Dan Burton wrote: > Interesting. I've never seen it proposed as right-associative before. Yes, maybe it was a bad idea after all. I just thought that the caret/exponentiation symbol may fit well the semantics, but unfortunately with the right associativity it would not allow to get rid of parentheses in common use, and with left associatifity it would not look like exponentiation. Alexey. From v.dijk.bas at gmail.com Thu Apr 17 12:23:39 2014 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Thu, 17 Apr 2014 14:23:39 +0200 Subject: [Haskell-cafe] ZuriHac 2014 - Updates Message-ID: Dear (potential) ZuriHac 2014 attendees, I would like to make a few announcements regarding ZuriHac 2014, a Haskell hackathon taking place in Zurich from Friday 6 June 2014 to Sunday 8 June 2014. Besides hacking on Haskell projects with core members of the community you will hear talks by Simon Marlow and Edward Kmett. Note that this event is open to any experience level, from beginners to gurus. In fact, one of the goals is to bring beginners in contact with experts so that the former can get a quick start in the Haskell community and the latter more help with their projects. For more information see: http://www.haskell.org/haskellwiki/ZuriHac2014 Registration ------------ I'm happy and sad to inform you that we've almost reached capacity for ZuriHac 2014. Happy because it looks like this might be the biggest Haskell Hackathon ever. Sad because I soon have to start adding new registrations to a waiting list. So if you want to join us, and haven't registered already, then please do so soon at: http://bit.ly/ZuriHac2014. Also if you've already registered but know you won't be able to make it, please cancel by emailing me to make room for others. T-Shirt ------- Like last year, each attendee will get a free ZuriHac T-shirt. If you've already registered, please tell me which sizes and model you would like to have: Male: S, M, L, XL, XXL Female: S, M, L, XL, XXL Host ---- Erudify, the company which is hosting ZuriHac, recently changed its name to Better. Do note that we haven't changed location. See our new website on why we have rebranded: http://better.com/en/rebranding Regards, The ZuriHac 2014 organizers From alexander at plaimi.net Thu Apr 17 12:35:48 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 17 Apr 2014 14:35:48 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: Message-ID: <534FCAA4.5000804@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 In my opinion we should just have '|>' and '<|' from F#. They are much nicer, being mnemonics for direction. And '|>' is just orders of magnitude nicer than 'flip ($)'. But alas, I fear we are stuck with this wart. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNPyqQACgkQRtClrXBQc7XDHQEAp0SL5NZJMf3MEvLcst/dr+O2 nPasMEggHMaoF6BsEBIA/RWaPBf//EVXWKUR9qpsVDBbSAPZa5T7jcoXCIZ8Wf9I =qE8a -----END PGP SIGNATURE----- From alexey.muranov at gmail.com Thu Apr 17 12:58:20 2014 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Thu, 17 Apr 2014 14:58:20 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <534FCAA4.5000804@plaimi.net> References: <534FCAA4.5000804@plaimi.net> Message-ID: On 17 avr. 2014, at 14:35, Alexander Berntsen wrote: > In my opinion we should just have '|>' and '<|' from F#. They are much > nicer, being mnemonics for direction. And '|>' is just orders of > magnitude nicer than 'flip ($)'. But alas, I fear we are stuck with > this wart. Then i think symmetric aliases for '(.)' and 'flip (.)' would also be needed. Still this would not make the language completely symmetric because it is impossible: * 'f x' would still be 'f x', * a left-associative and a right-associative operator symbols cannot have the same precedence, so '|>' and '<|' would need to have different precedence. Maybe just some naming convention is needed for the names of the flips of commongly flipped operators? I am thinking about something silly like '~$', '~.', or '-$', '-.', or maybe some other unary operator symbol can be used sefely as a prefix here... Alexey. From alexander at plaimi.net Thu Apr 17 13:05:56 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 17 Apr 2014 15:05:56 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <534FCAA4.5000804@plaimi.net> Message-ID: <534FD1B4.6020701@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17/04/14 14:58, Alexey Muranov wrote: > Then i think symmetric aliases for '(.)' and 'flip (.)' would also > be needed. F# solved this elegantly with '>>' and '<<', but these are already used in Haskell. But I see these as separate issues, and I use 'flip ($)' a lot more often than 'flip (.)'. > * a left-associative and a right-associative operator symbols > cannot have the same precedence, so '|>' and '<|' would need to > have different precedence. Why? In the languages I have used '|>' and '<|', they have the same precedence. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNP0bQACgkQRtClrXBQc7XzEQD/XR5vIrDLR/zWeqKA68D8mbzM 6wgeGeFipqC7QSeWdiYBAJBhgVHqfo8JghewXweF5f93QnrcdLF/khIFuJGUA+Rq =JtCP -----END PGP SIGNATURE----- From hesselink at gmail.com Thu Apr 17 13:08:17 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 17 Apr 2014 15:08:17 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <534FD1B4.6020701@plaimi.net> References: <534FCAA4.5000804@plaimi.net> <534FD1B4.6020701@plaimi.net> Message-ID: On Thu, Apr 17, 2014 at 3:05 PM, Alexander Berntsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 17/04/14 14:58, Alexey Muranov wrote: >> Then i think symmetric aliases for '(.)' and 'flip (.)' would also >> be needed. > F# solved this elegantly with '>>' and '<<', but these are already > used in Haskell. But I see these as separate issues, and I use 'flip > ($)' a lot more often than 'flip (.)'. Haskell has (>>>) and (<<<) in Control.Arrow if you want symmetric operators for this. Erik From alexey.muranov at gmail.com Thu Apr 17 13:11:03 2014 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Thu, 17 Apr 2014 15:11:03 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <534FD1B4.6020701@plaimi.net> References: <534FCAA4.5000804@plaimi.net> <534FD1B4.6020701@plaimi.net> Message-ID: <98F736F7-9D3D-40C8-9C1C-C17B072EBE0D@gmail.com> On 17 avr. 2014, at 15:05, Alexander Berntsen wrote: >> * a left-associative and a right-associative operator symbols >> cannot have the same precedence, so '|>' and '<|' would need to >> have different precedence. > Why? In the languages I have used '|>' and '<|', they have the same > precedence. I do not know F#, and maybe i am missing something, but assuming that x |> f |> g == (x |> f) |> g and g <| f <| x == g <| (f <| x) what are x |> f <| y and g <| x |> f ? From alexander at plaimi.net Thu Apr 17 13:16:01 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 17 Apr 2014 15:16:01 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <98F736F7-9D3D-40C8-9C1C-C17B072EBE0D@gmail.com> References: <534FCAA4.5000804@plaimi.net> <534FD1B4.6020701@plaimi.net> <98F736F7-9D3D-40C8-9C1C-C17B072EBE0D@gmail.com> Message-ID: <534FD411.3080004@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17/04/14 15:11, Alexey Muranov wrote: > what are > > x |> f <| y > > and > > g <| x |> f "conflicting associativity" errors. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNP1BEACgkQRtClrXBQc7WKpgEAp7QSKyl7ZFkkAznJVZgRzH6y OSGskwCithbusAzW9ScBAIVmebyf0lk77Oy7GAG4cl7oc0NLRsj77cAjaUqBLPor =FCx0 -----END PGP SIGNATURE----- From alexander at plaimi.net Thu Apr 17 13:20:02 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 17 Apr 2014 15:20:02 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <534FCAA4.5000804@plaimi.net> <534FD1B4.6020701@plaimi.net> Message-ID: <534FD502.70801@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17/04/14 15:08, Erik Hesselink wrote: > Haskell has (>>>) and (<<<) in Control.Arrow if you want symmetric > operators for this. Forgot all about those. Shows how little I need the backward composition operator. Thanks for reminding me. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNP1QIACgkQRtClrXBQc7UGagD/eupkBoVgYhi0tXVzU+0sTJRJ kKzL2HjuzaVfnILtLoAA/3loykUQOqJZ+MAN+pKwn+X2NRBXjFs9mYbk3YbQ++Ny =ka4w -----END PGP SIGNATURE----- From tonymorris at gmail.com Thu Apr 17 13:28:15 2014 From: tonymorris at gmail.com (Tony Morris) Date: Thu, 17 Apr 2014 23:28:15 +1000 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <534FD502.70801@plaimi.net> References: <534FCAA4.5000804@plaimi.net> <534FD1B4.6020701@plaimi.net> <534FD502.70801@plaimi.net> Message-ID: <534FD6EF.2010502@gmail.com> http://hackage.haskell.org/package/lens-4.1.2/docs/Control-Lens-Lens.html#v:-38- On 17/04/14 23:20, Alexander Berntsen wrote: > On 17/04/14 15:08, Erik Hesselink wrote: > > Haskell has (>>>) and (<<<) in Control.Arrow if you want symmetric > > operators for this. > Forgot all about those. Shows how little I need the backward > composition operator. Thanks for reminding me. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Tony Morris http://tmorris.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Thu Apr 17 13:34:39 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 17 Apr 2014 15:34:39 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <534FD6EF.2010502@gmail.com> References: <534FCAA4.5000804@plaimi.net> <534FD1B4.6020701@plaimi.net> <534FD502.70801@plaimi.net> <534FD6EF.2010502@gmail.com> Message-ID: <534FD86F.5070604@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17/04/14 15:28, Tony Morris wrote: > http://hackage.haskell.org/package/lens-4.1.2/docs/Control-Lens-Lens.html#v:-38- I > know about this. It has already been mentioned by Taylor Hedberg. And as correctly observed by Taylor, one does not simply walk into Mord^W^W^Wpull in lens just to get a simple function that you can define yourself without much trouble. I assumed this thread was about how people felt about having a backward application operator in prelude. And I would like to repeat my argument that '<|' and '|>' are much nicer mnemonically than '$' and '&'. (Though Edward has made the case for '&' being read "and", I don't think that's very nice. He certainly can't make the opposite case for '$'.) - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNP2G8ACgkQRtClrXBQc7X0GwD/at62rzxwrjDR4Aa4hZgEfSza LExn7hhRoSWObmVBV8wA/iKa9y9tik8Bt9FPGnbgkwu3DBx1YBhtn/2WAeh7OFkZ =B6Ih -----END PGP SIGNATURE----- From bhurt at spnz.org Thu Apr 17 14:14:14 2014 From: bhurt at spnz.org (Brian Hurt) Date: Thu, 17 Apr 2014 10:14:14 -0400 Subject: [Haskell-cafe] Stupid newbie question of the day: why is newMVar in the IO monad? Message-ID: So, I've hit a problem, and I'm wondering why this is. I want to write a function which returns a global monotonically incrementing int. This *should* be easy- just put a MVar in a global name, then update it as necessary: globalCounter :: MVar Integer globalCounter = undefined genId :: IO Integer genId = modifyMVar (\i -> (i+1, i)) globalCounter The problem with this is defining globalCounter- and that is because newMVar returns IO (MVar a), and not just MVar a. Now, I can go: globalCounter = unsafePerformIO $ newMVar 0 but I hate using unsafePerformIO. And I don't want to pass around the reference itself- I need to be in the IO monad with a StateT transform on top for other reasons, I don't want to complicate things. And even if I were, I would just pass the counter around instead of the reference. But it just feels like Haskell is being gratuitously difficult here. It's not just the name, it's the fact that creating the MVar is *explicitly* modifying the state of the world, which implies there is something more going on here than just allocating some memory. As an example of what I mean, newSTRef returns ST s (STRef s a). This is explicitly saying that the created STRef is only visible in the given thread. This is necessary for the implementation of the STRef, which is a mutable variable with no transactional guarantees. If it were visible from another thread, then it could be accessed from the other thread, creating a potential race condition. That I understand. But that isn't the case here- MVar's are explicitly designed to be accessed from multiple threads. So then I thought that it was something specific with MVars- maybe they need to do an OS call to set them up or something. OK, so let's try some alternatives. Like STM. Nope. newTVar has return type STM (TVar a) and newTMVar returns STM (TMVar a). Throw these into atomically, and I'm right back to where I started. newIORef returns IO (IORef a). And that's just a pointer store (I thought). It's easier for me to believe that I'm missing something here, rather than that Haskell is just being gratuitously difficult. But I honestly don't see what it is I'm missing. Help? Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.muranov at gmail.com Thu Apr 17 14:23:22 2014 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Thu, 17 Apr 2014 16:23:22 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <534FD411.3080004@plaimi.net> References: <534FCAA4.5000804@plaimi.net> <534FD1B4.6020701@plaimi.net> <98F736F7-9D3D-40C8-9C1C-C17B072EBE0D@gmail.com> <534FD411.3080004@plaimi.net> Message-ID: On 17 avr. 2014, at 15:16, Alexander Berntsen wrote: > On 17/04/14 15:11, Alexey Muranov wrote: >> what are >> >> x |> f <| y >> >> and >> >> g <| x |> f > "conflicting associativity" errors. Right, in a similar situation GHCi says > Precedence parsing error > cannot mix `foo' [infixl 9] and `bar' [infixr 9] in the same infix expression From danny.gratzer at gmail.com Thu Apr 17 14:26:02 2014 From: danny.gratzer at gmail.com (Danny Gratzer) Date: Thu, 17 Apr 2014 09:26:02 -0500 Subject: [Haskell-cafe] Stupid newbie question of the day: why is newMVar in the IO monad? In-Reply-To: References: Message-ID: New `MVar` has to return a different memory location every time and this is noticeable, it's not referentially transparent. Consider what would happen if we made the transformation let a = newMVar 0 let b = newMVar 0 putMVar a 1 readMVar b to let a = newMVar 0 b = a ... If newMVar was referentially transparent, we can automatically share any of it's calls with same arguments since they're supposed to return the same thing everytime. Since it's not referentially transparent, back into the IO monad it goes. Also if you do that toplevel counter trick, you want NoInline otherwise GHC might just inline it at each occurrence and you'll end up with separate counters. Cheers, Danny Gratzer -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhurt at spnz.org Thu Apr 17 14:34:46 2014 From: bhurt at spnz.org (Brian Hurt) Date: Thu, 17 Apr 2014 10:34:46 -0400 Subject: [Haskell-cafe] Stupid newbie question of the day: why is newMVar in the IO monad? In-Reply-To: References: Message-ID: Thanks. This helps. I was right to mistrust the unsafePerformIO "solution". :-) What Haskell was telling me is that I need to think about the scope of the identifiers I'm allocating, and what guarantees I'm making. On Thu, Apr 17, 2014 at 10:26 AM, Danny Gratzer wrote: > New `MVar` has to return a different memory location every time and this > is noticeable, it's not referentially transparent. > > Consider what would happen if we made the transformation > > let a = newMVar 0 > let b = newMVar 0 > putMVar a 1 > readMVar b > > to > > let a = newMVar 0 > b = a > ... > > If newMVar was referentially transparent, we can automatically share any > of it's calls with same arguments since they're supposed to return the same > thing everytime. Since it's not referentially transparent, back into the IO > monad it goes. > > Also if you do that toplevel counter trick, you want NoInline otherwise > GHC might just inline it at each occurrence and you'll end up with separate > counters. > > Cheers, > Danny Gratzer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.foppa at gmail.com Thu Apr 17 14:38:56 2014 From: benjamin.foppa at gmail.com (Ben Foppa) Date: Thu, 17 Apr 2014 10:38:56 -0400 Subject: [Haskell-cafe] Stupid newbie question of the day: why is newMVar in the IO monad? In-Reply-To: References: Message-ID: In my (limited) experience, there are two main solutions to this kind of problem: - Dependency-injection, i.e. add the MVar as an explicit parameter to every function you use it in. This is ideal, but it's often a little cumbersome. - unsafePerformIO, i.e. just initialize it globally. I've never really had issues with this approach, if used sparingly and appropriately. This might also be relevant: http://www.haskell.org/haskellwiki/Global_variables Hope that helps! On Thu, Apr 17, 2014 at 10:34 AM, Brian Hurt wrote: > Thanks. This helps. I was right to mistrust the unsafePerformIO > "solution". :-) What Haskell was telling me is that I need to think about > the scope of the identifiers I'm allocating, and what guarantees I'm making. > > > > > > On Thu, Apr 17, 2014 at 10:26 AM, Danny Gratzer wrote: > >> New `MVar` has to return a different memory location every time and this >> is noticeable, it's not referentially transparent. >> >> Consider what would happen if we made the transformation >> >> let a = newMVar 0 >> let b = newMVar 0 >> putMVar a 1 >> readMVar b >> >> to >> >> let a = newMVar 0 >> b = a >> ... >> >> If newMVar was referentially transparent, we can automatically share any >> of it's calls with same arguments since they're supposed to return the same >> thing everytime. Since it's not referentially transparent, back into the IO >> monad it goes. >> >> Also if you do that toplevel counter trick, you want NoInline otherwise >> GHC might just inline it at each occurrence and you'll end up with separate >> counters. >> >> Cheers, >> Danny Gratzer >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fryguybob at gmail.com Thu Apr 17 14:44:44 2014 From: fryguybob at gmail.com (Ryan Yates) Date: Thu, 17 Apr 2014 10:44:44 -0400 Subject: [Haskell-cafe] Stupid newbie question of the day: why is newMVar in the IO monad? In-Reply-To: References: Message-ID: Also note linked from the global variables page on the wiki is: http://www.haskell.org/haskellwiki/Top_level_mutable_state Important for the `unsafePerformIO` option is the NOINLINE pragma to ensure that only one global variable exists. In the STM case it is also important to use `newTVarIO` rather then `unsafePerformIO $ atomically newTVar` which does not work. Ryan On Thu, Apr 17, 2014 at 10:38 AM, Ben Foppa wrote: > In my (limited) experience, there are two main solutions to this kind of > problem: > > - Dependency-injection, i.e. add the MVar as an explicit parameter to > every function you use it in. This is ideal, but it's often a little > cumbersome. > - unsafePerformIO, i.e. just initialize it globally. I've never really > had issues with this approach, if used sparingly and appropriately. > > This might also be relevant: > http://www.haskell.org/haskellwiki/Global_variables > > Hope that helps! > > > On Thu, Apr 17, 2014 at 10:34 AM, Brian Hurt wrote: > >> Thanks. This helps. I was right to mistrust the unsafePerformIO >> "solution". :-) What Haskell was telling me is that I need to think about >> the scope of the identifiers I'm allocating, and what guarantees I'm making. >> >> >> >> >> >> On Thu, Apr 17, 2014 at 10:26 AM, Danny Gratzer wrote: >> >>> New `MVar` has to return a different memory location every time and this >>> is noticeable, it's not referentially transparent. >>> >>> Consider what would happen if we made the transformation >>> >>> let a = newMVar 0 >>> let b = newMVar 0 >>> putMVar a 1 >>> readMVar b >>> >>> to >>> >>> let a = newMVar 0 >>> b = a >>> ... >>> >>> If newMVar was referentially transparent, we can automatically share any >>> of it's calls with same arguments since they're supposed to return the same >>> thing everytime. Since it's not referentially transparent, back into the IO >>> monad it goes. >>> >>> Also if you do that toplevel counter trick, you want NoInline otherwise >>> GHC might just inline it at each occurrence and you'll end up with separate >>> counters. >>> >>> Cheers, >>> Danny Gratzer >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Thu Apr 17 15:05:14 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 17 Apr 2014 17:05:14 +0200 Subject: [Haskell-cafe] Stupid newbie question of the day: why is newMVar in the IO monad? In-Reply-To: References: Message-ID: Also note that *if* you create top level mutable variables (which you shouldn't, generally), you should make sure they're monomorphic. Especially with newEmptyMVar it's very easy to create a polymorphic one, which is just 'unsafeCoerce' in disguise: import Control.Concurrent.MVar import System.IO.Unsafe global = unsafePerformIO newEmptyMVar main = do putMVar global 72 c <- takeMVar global putStrLn [c] On Thu, Apr 17, 2014 at 4:44 PM, Ryan Yates wrote: > Also note linked from the global variables page on the wiki is: > http://www.haskell.org/haskellwiki/Top_level_mutable_state > > Important for the `unsafePerformIO` option is the NOINLINE pragma to ensure > that only one global variable exists. In the STM case it is also important > to use `newTVarIO` rather then `unsafePerformIO $ atomically newTVar` which > does not work. > > Ryan > > > On Thu, Apr 17, 2014 at 10:38 AM, Ben Foppa > wrote: >> >> In my (limited) experience, there are two main solutions to this kind of >> problem: >> >> Dependency-injection, i.e. add the MVar as an explicit parameter to every >> function you use it in. This is ideal, but it's often a little cumbersome. >> unsafePerformIO, i.e. just initialize it globally. I've never really had >> issues with this approach, if used sparingly and appropriately. >> >> This might also be relevant: >> http://www.haskell.org/haskellwiki/Global_variables >> >> Hope that helps! >> >> >> On Thu, Apr 17, 2014 at 10:34 AM, Brian Hurt wrote: >>> >>> Thanks. This helps. I was right to mistrust the unsafePerformIO >>> "solution". :-) What Haskell was telling me is that I need to think about >>> the scope of the identifiers I'm allocating, and what guarantees I'm making. >>> >>> >>> >>> >>> >>> On Thu, Apr 17, 2014 at 10:26 AM, Danny Gratzer >>> wrote: >>>> >>>> New `MVar` has to return a different memory location every time and this >>>> is noticeable, it's not referentially transparent. >>>> >>>> Consider what would happen if we made the transformation >>>> >>>> let a = newMVar 0 >>>> let b = newMVar 0 >>>> putMVar a 1 >>>> readMVar b >>>> >>>> to >>>> >>>> let a = newMVar 0 >>>> b = a >>>> ... >>>> >>>> If newMVar was referentially transparent, we can automatically share any >>>> of it's calls with same arguments since they're supposed to return the same >>>> thing everytime. Since it's not referentially transparent, back into the IO >>>> monad it goes. >>>> >>>> Also if you do that toplevel counter trick, you want NoInline otherwise >>>> GHC might just inline it at each occurrence and you'll end up with separate >>>> counters. >>>> >>>> Cheers, >>>> Danny Gratzer >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From graham at 3tsoftwarelabs.com Thu Apr 17 16:03:39 2014 From: graham at 3tsoftwarelabs.com (Graham Thomson) Date: Thu, 17 Apr 2014 17:03:39 +0100 Subject: [Haskell-cafe] [ANN] 3T Software Labs MongoDB tools for Haskell programmers. Message-ID: Hello fair Haskell hackers! I?d like to announce the availability of 3T Software Labs MongoDB tools to the readers of this list. To forward-thinking Haskell adopters and MongoDB users alike, I?d like to extend a special 60-day trial of all the apps in our suite at http://3tsoftwarelabs.com/evaluation-edition using the code ?HSKL?. My apologies for the spam if you?re not a MongoDB user. If you are, I hope you enjoy our tools and find them useful. Like many of the pioneering Haskell projects described on this list, we?ve just started our adventure, and would love to hear any feedback you have. Thanks a lot, Graham 3T Software Labs -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at nand.wakku.to Thu Apr 17 16:06:40 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Thu, 17 Apr 2014 18:06:40 +0200 Subject: [Haskell-cafe] Stupid newbie question of the day: why is newMVar in the IO monad? In-Reply-To: References: Message-ID: <20140417180640.GA22584@nanodesu.talocan.mine.nu> On Thu, 17 Apr 2014 10:14:14 -0400, Brian Hurt wrote: > So, I've hit a problem, and I'm wondering why this is. I want to write a > function which returns a global monotonically incrementing int. This > *should* be easy- just put a MVar in a global name, then update it as > necessary: > > globalCounter :: MVar Integer > globalCounter = undefined > > genId :: IO Integer > genId = modifyMVar (\i -> (i+1, i)) globalCounter > > The problem with this is defining globalCounter- and that is because > newMVar returns IO (MVar a), and not just MVar a. Now, I can go: > > globalCounter = unsafePerformIO $ newMVar 0 > > but I hate using unsafePerformIO. And I don't want to pass around the > reference itself- I need to be in the IO monad with a StateT transform on > top for other reasons, I don't want to complicate things. And even if I > were, I would just pass the counter around instead of the reference. But > it just feels like Haskell is being gratuitously difficult here. > > It's not just the name, it's the fact that creating the MVar is > *explicitly* modifying the state of the world, which implies there is > something more going on here than just allocating some memory. As an > example of what I mean, newSTRef returns ST s (STRef s a). This is > explicitly saying that the created STRef is only visible in the given > thread. This is necessary for the implementation of the STRef, which is a > mutable variable with no transactional guarantees. If it were visible from > another thread, then it could be accessed from the other thread, creating a > potential race condition. That I understand. But that isn't the case > here- MVar's are explicitly designed to be accessed from multiple threads. > > So then I thought that it was something specific with MVars- maybe they > need to do an OS call to set them up or something. OK, so let's try some > alternatives. Like STM. > > Nope. newTVar has return type STM (TVar a) and newTMVar returns STM (TMVar > a). Throw these into atomically, and I'm right back to where I started. > newIORef returns IO (IORef a). And that's just a pointer store (I > thought). > > It's easier for me to believe that I'm missing something here, rather than > that Haskell is just being gratuitously difficult. But I honestly don't > see what it is I'm missing. Help? > > Brian You said you're already using a StateT for other reasons but there's no problem with nesting StateT, you just have to lift a bit. I would personally use that approach - define another monad transformer layer on top of your IO to handle around the int state-passing. Perhaps, if you desperately want to avoid using StateT Int, you could also use ReaderT (MVar a) to pass around the function automatically. Note: Going beyond the ReaderT approach, there are more approaches one could use, for example a (?var :: MVar Int) implicit parameter, or another constraint that is resolved at runtime like with edwardk's reflection library. And finally, unsafePerformIO on this is safe as long as it's monomorphic and you don't inline it, ie. globalCounter :: Mvar Integer globalCounter = unsafePerformIO $ newMVar 0 {-# NOINLINE globalCounter #-} From hans at hanshoglund.se Thu Apr 17 18:03:34 2014 From: hans at hanshoglund.se (=?iso-8859-1?Q?Hans_H=F6glund?=) Date: Thu, 17 Apr 2014 20:03:34 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: Message-ID: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> There is also is my humble attempt to standardize the (&) formulation: http://hackage.haskell.org/package/reverse-apply As you can see, these definitions now mirror those in 'lens' exactly. I see no reason why this definition should not move to base. IMHO, the Diagrams definition is a very specific one based on the needs of that EDSL, while the lens formulation is the expected one. Mvh, Hans On 17 apr 2014, at 14:00, haskell-cafe-request at haskell.org wrote: > Message: 1 > Date: Wed, 16 Apr 2014 16:49:31 -0700 > From: Dan Burton > To: Alexey Muranov > Cc: haskell-cafe > Subject: Re: [Haskell-cafe] Syntax proposal for "reverse > apply"/"pipeline apply" (flip ($)) > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > In the "lens" package, this is (&) at infixl 1. In the "diagrams" package, > this is (#) at infixl 8. You're certainly not the first to want this, but > nobody can ever agree what it should be called or what fixity it should > have. You can always just define it yourself. > > -- Dan Burton > > > On Wed, Apr 16, 2014 at 3:25 PM, Alexey Muranov wrote: > >> Hello, >> >> i am completely new to Haskell, but i am somewhat fascinated by >> lambda-calculus and programming. >> >> For whatever it is worth, i would like to propose for discussion a syntax >> for "(flip ($))" operation in Haskell. >> >> I think that a good syntax would be "|^", for example: >> >> square x = x * x >> y = 3 |^ square -- y == 9 >> >> >> Explanation: >> >> * i would have suggested just ^, but it would conflict with number >> exponentiation, >> >> * it is rather common in mathematics to write function application in >> exponential notation: x ^ f instead of f(x), especially if f is an >> automorphism of some structure, >> >> * (flip ($)) is exactly the exponentiation of Church numerals, >> >> * in "The calculi of lambda-conversion", Alonzo Church uses the >> "shorthand" notation "[N^M]" for "(MN)", where M and N are lambda-terms. >> >> * I am probably not the only person missing the ability to apply functions >> from the right: >> >> http://stackoverflow.com/questions/1457140/haskell-composition-vs-fs-pipe-forward-operator >> >> Well, other notations i've thought of are "\^" and "~$". >> >> Alexey. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Wed, 16 Apr 2014 16:56:37 -0700 (PDT) > From: Alexey Muranov > To: haskell-cafe at googlegroups.com > Cc: haskell-cafe > Subject: Re: [Haskell-cafe] Syntax proposal for "reverse > apply"/"pipeline apply" (flip ($)) > Message-ID: <0569e94e-44b8-44a0-abe3-4bd7d80b2ed4 at googlegroups.com> > Content-Type: text/plain; charset="utf-8" > > On Thursday, April 17, 2014 1:49:31 AM UTC+2, Dan Burton wrote: > >> In the "lens" package, this is (&) at infixl 1. In the "diagrams" package, >> this is (#) at infixl 8. You're certainly not the first to want this, but >> nobody can ever agree what it should be called or what fixity it should >> have. You can always just define it yourself. >> > > (#) does not look too bad either. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 3 > Date: Wed, 16 Apr 2014 18:41:01 -0700 > From: Dan Burton > To: Alexey Muranov > Cc: haskell-cafe , > haskell-cafe at googlegroups.com > Subject: Re: [Haskell-cafe] Syntax proposal for "reverse > apply"/"pipeline apply" (flip ($)) > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Interesting. I've never seen it proposed as right-associative before. Just > FYI, the implementation is as simple as this: > > infixr 1 |^ > (|^) :: a -> (a -> b) -> b > x |^ f = f x > > Then you can write: > > 3 |^ 2 |^ (^) -- produces 2^3 = 8 > > It seems very odd to me. I don't know why you'd want to apply the arguments > backwards one by one. However, lens and diagrams both provide examples > where you want to start with a value and apply functions "forwards" one by > one, which is why their corresponding operators are left-associative. > > -- Dan Burton -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgaebel at uwaterloo.ca Thu Apr 17 18:05:30 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Thu, 17 Apr 2014 14:05:30 -0400 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> Message-ID: Last I checked, (&) = flip ($) is both shorter to type, and more explicit than: import Control.Apply.Reverse - Clark On Thu, Apr 17, 2014 at 2:03 PM, Hans H?glund wrote: > > There is also is my humble attempt to standardize the (&) formulation: > > http://hackage.haskell.org/package/reverse-apply > > As you can see, these definitions now mirror those in 'lens' exactly. I > see no reason why this definition should not move to base. IMHO, the > Diagrams definition is a very specific one based on the needs of that EDSL, > while the lens formulation is the expected one. > > Mvh, > Hans > > > On 17 apr 2014, at 14:00, haskell-cafe-request at haskell.org wrote: > > Message: 1 > Date: Wed, 16 Apr 2014 16:49:31 -0700 > From: Dan Burton > To: Alexey Muranov > Cc: haskell-cafe > Subject: Re: [Haskell-cafe] Syntax proposal for "reverse > apply"/"pipeline apply" (flip ($)) > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > > In the "lens" package, this is (&) at infixl 1. In the "diagrams" package, > this is (#) at infixl 8. You're certainly not the first to want this, but > nobody can ever agree what it should be called or what fixity it should > have. You can always just define it yourself. > > -- Dan Burton > > > On Wed, Apr 16, 2014 at 3:25 PM, Alexey Muranov >wrote: > > Hello, > > > i am completely new to Haskell, but i am somewhat fascinated by > > lambda-calculus and programming. > > > For whatever it is worth, i would like to propose for discussion a syntax > > for "(flip ($))" operation in Haskell. > > > I think that a good syntax would be "|^", for example: > > > square x = x * x > > y = 3 |^ square -- y == 9 > > > > Explanation: > > > * i would have suggested just ^, but it would conflict with number > > exponentiation, > > > * it is rather common in mathematics to write function application in > > exponential notation: x ^ f instead of f(x), especially if f is an > > automorphism of some structure, > > > * (flip ($)) is exactly the exponentiation of Church numerals, > > > * in "The calculi of lambda-conversion", Alonzo Church uses the > > "shorthand" notation "[N^M]" for "(MN)", where M and N are lambda-terms. > > > * I am probably not the only person missing the ability to apply functions > > from the right: > > > > http://stackoverflow.com/questions/1457140/haskell-composition-vs-fs-pipe-forward-operator > > > Well, other notations i've thought of are "\^" and "~$". > > > Alexey. > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.haskell.org/pipermail/haskell-cafe/attachments/20140416/818eebe7/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Wed, 16 Apr 2014 16:56:37 -0700 (PDT) > From: Alexey Muranov > To: haskell-cafe at googlegroups.com > Cc: haskell-cafe > Subject: Re: [Haskell-cafe] Syntax proposal for "reverse > apply"/"pipeline apply" (flip ($)) > Message-ID: <0569e94e-44b8-44a0-abe3-4bd7d80b2ed4 at googlegroups.com> > Content-Type: text/plain; charset="utf-8" > > > On Thursday, April 17, 2014 1:49:31 AM UTC+2, Dan Burton wrote: > > In the "lens" package, this is (&) at infixl 1. In the "diagrams" package, > > > this is (#) at infixl 8. You're certainly not the first to want this, but > > nobody can ever agree what it should be called or what fixity it should > > have. You can always just define it yourself. > > > > (#) does not look too bad either. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.haskell.org/pipermail/haskell-cafe/attachments/20140416/ccada62f/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Wed, 16 Apr 2014 18:41:01 -0700 > From: Dan Burton > To: Alexey Muranov > Cc: haskell-cafe , > haskell-cafe at googlegroups.com > Subject: Re: [Haskell-cafe] Syntax proposal for "reverse > apply"/"pipeline apply" (flip ($)) > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > > Interesting. I've never seen it proposed as right-associative before. Just > FYI, the implementation is as simple as this: > > infixr 1 |^ > (|^) :: a -> (a -> b) -> b > x |^ f = f x > > Then you can write: > > 3 |^ 2 |^ (^) -- produces 2^3 = 8 > > It seems very odd to me. I don't know why you'd want to apply the arguments > backwards one by one. However, lens and diagrams both provide examples > where you want to start with a value and apply functions "forwards" one by > one, which is why their corresponding operators are left-associative. > > -- Dan Burton > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.foppa at gmail.com Thu Apr 17 18:38:22 2014 From: benjamin.foppa at gmail.com (Ben Foppa) Date: Thu, 17 Apr 2014 14:38:22 -0400 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> Message-ID: Can we argue about the fixity for (<&>)? I've always it as infixl 4, to mix it in with other applicative operators, e.g.: (:) <$> fx <*> fl becomes fx <&> (:) <*> fl On Thu, Apr 17, 2014 at 2:05 PM, Clark Gaebel wrote: > Last I checked, > > (&) = flip ($) > > is both shorter to type, and more explicit than: > > import Control.Apply.Reverse > > - Clark > > > On Thu, Apr 17, 2014 at 2:03 PM, Hans H?glund wrote: > >> >> There is also is my humble attempt to standardize the (&) formulation: >> >> http://hackage.haskell.org/package/reverse-apply >> >> As you can see, these definitions now mirror those in 'lens' exactly. I >> see no reason why this definition should not move to base. IMHO, the >> Diagrams definition is a very specific one based on the needs of that EDSL, >> while the lens formulation is the expected one. >> >> Mvh, >> Hans >> >> >> On 17 apr 2014, at 14:00, haskell-cafe-request at haskell.org wrote: >> >> Message: 1 >> Date: Wed, 16 Apr 2014 16:49:31 -0700 >> From: Dan Burton >> To: Alexey Muranov >> Cc: haskell-cafe >> Subject: Re: [Haskell-cafe] Syntax proposal for "reverse >> apply"/"pipeline apply" (flip ($)) >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> >> In the "lens" package, this is (&) at infixl 1. In the "diagrams" package, >> this is (#) at infixl 8. You're certainly not the first to want this, but >> nobody can ever agree what it should be called or what fixity it should >> have. You can always just define it yourself. >> >> -- Dan Burton >> >> >> On Wed, Apr 16, 2014 at 3:25 PM, Alexey Muranov > >wrote: >> >> Hello, >> >> >> i am completely new to Haskell, but i am somewhat fascinated by >> >> lambda-calculus and programming. >> >> >> For whatever it is worth, i would like to propose for discussion a syntax >> >> for "(flip ($))" operation in Haskell. >> >> >> I think that a good syntax would be "|^", for example: >> >> >> square x = x * x >> >> y = 3 |^ square -- y == 9 >> >> >> >> Explanation: >> >> >> * i would have suggested just ^, but it would conflict with number >> >> exponentiation, >> >> >> * it is rather common in mathematics to write function application in >> >> exponential notation: x ^ f instead of f(x), especially if f is an >> >> automorphism of some structure, >> >> >> * (flip ($)) is exactly the exponentiation of Church numerals, >> >> >> * in "The calculi of lambda-conversion", Alonzo Church uses the >> >> "shorthand" notation "[N^M]" for "(MN)", where M and N are lambda-terms. >> >> >> * I am probably not the only person missing the ability to apply functions >> >> from the right: >> >> >> >> http://stackoverflow.com/questions/1457140/haskell-composition-vs-fs-pipe-forward-operator >> >> >> Well, other notations i've thought of are "\^" and "~$". >> >> >> Alexey. >> >> _______________________________________________ >> >> Haskell-Cafe mailing list >> >> Haskell-Cafe at haskell.org >> >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://www.haskell.org/pipermail/haskell-cafe/attachments/20140416/818eebe7/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 16 Apr 2014 16:56:37 -0700 (PDT) >> From: Alexey Muranov >> To: haskell-cafe at googlegroups.com >> Cc: haskell-cafe >> Subject: Re: [Haskell-cafe] Syntax proposal for "reverse >> apply"/"pipeline apply" (flip ($)) >> Message-ID: <0569e94e-44b8-44a0-abe3-4bd7d80b2ed4 at googlegroups.com> >> Content-Type: text/plain; charset="utf-8" >> >> >> On Thursday, April 17, 2014 1:49:31 AM UTC+2, Dan Burton wrote: >> >> In the "lens" package, this is (&) at infixl 1. In the "diagrams" package, >> >> >> this is (#) at infixl 8. You're certainly not the first to want this, but >> >> >> nobody can ever agree what it should be called or what fixity it should >> >> have. You can always just define it yourself. >> >> >> >> (#) does not look too bad either. >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://www.haskell.org/pipermail/haskell-cafe/attachments/20140416/ccada62f/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 16 Apr 2014 18:41:01 -0700 >> From: Dan Burton >> To: Alexey Muranov >> Cc: haskell-cafe , >> haskell-cafe at googlegroups.com >> Subject: Re: [Haskell-cafe] Syntax proposal for "reverse >> apply"/"pipeline apply" (flip ($)) >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> >> Interesting. I've never seen it proposed as right-associative before. Just >> FYI, the implementation is as simple as this: >> >> infixr 1 |^ >> (|^) :: a -> (a -> b) -> b >> x |^ f = f x >> >> Then you can write: >> >> 3 |^ 2 |^ (^) -- produces 2^3 = 8 >> >> It seems very odd to me. I don't know why you'd want to apply the >> arguments >> backwards one by one. However, lens and diagrams both provide examples >> where you want to start with a value and apply functions "forwards" one by >> one, which is why their corresponding operators are left-associative. >> >> -- Dan Burton >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > -- > Clark. > > Key ID : 0x78099922 > Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Thu Apr 17 19:12:23 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 17 Apr 2014 21:12:23 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> Message-ID: <53502797.2030509@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 17/04/14 20:05, Clark Gaebel wrote: > Last I checked, > > (&) = flip ($) > > is both shorter to type, and more explicit than: > > import Control.Apply.Reverse There is no reason to use a library for making a reverse compose operator. The discussion should rather be whether this is worthwhile and interesting to add to prelude. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF0EAREIAAYFAlNQJ5cACgkQRtClrXBQc7Ut3AD+LUk9sfgw73IL7agSHOf4dstg uJlKi7yUHTiX8RrYbdIA9R6DFKXr8BITDUFIjM1Q4kBM1umQdlfsuKF4a01nIs0= =WNYj -----END PGP SIGNATURE----- From felipe.lessa at gmail.com Thu Apr 17 19:14:08 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu, 17 Apr 2014 16:14:08 -0300 Subject: [Haskell-cafe] Stupid newbie question of the day: why is newMVar in the IO monad? In-Reply-To: References: Message-ID: <53502800.9040202@gmail.com> There are at least two packages on Hackage that try to solve this problem once and for all: http://hackage.haskell.org/package/global-variables http://hackage.haskell.org/package/safe-globals Note that, for "global-variables", you may use an unexported newtype and an empty string if just using a global string smells bad for you. Cheers, -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From ekmett at gmail.com Thu Apr 17 19:20:54 2014 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 17 Apr 2014 15:20:54 -0400 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <53502797.2030509@plaimi.net> References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> Message-ID: After the last time this made the rounds, this went to the core libraries committee. Consensus was achieved to add it as an infixl 1 & operator to Data.Function, but not to Prelude,so we just need to put in the patch and you'll see it in GHC 7.10. Done. -Edward Kmett -Edward On Thu, Apr 17, 2014 at 3:12 PM, Alexander Berntsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 17/04/14 20:05, Clark Gaebel wrote: > > Last I checked, > > > > (&) = flip ($) > > > > is both shorter to type, and more explicit than: > > > > import Control.Apply.Reverse > There is no reason to use a library for making a reverse compose > operator. The discussion should rather be whether this is worthwhile > and interesting to add to prelude. > > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF0EAREIAAYFAlNQJ5cACgkQRtClrXBQc7Ut3AD+LUk9sfgw73IL7agSHOf4dstg > uJlKi7yUHTiX8RrYbdIA9R6DFKXr8BITDUFIjM1Q4kBM1umQdlfsuKF4a01nIs0= > =WNYj > -----END PGP SIGNATURE----- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at hanshoglund.se Thu Apr 17 19:32:28 2014 From: hans at hanshoglund.se (=?iso-8859-1?Q?Hans_H=F6glund?=) Date: Thu, 17 Apr 2014 21:32:28 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> Message-ID: > Can we argue about the fixity for (<&>)? I've always it as infixl 4, to mix it in with other applicative operators, e.g.: > > (:) <$> fx <*> fl > > becomes > > fx <&> (:) <*> fl I agree, this seems to be a mistake in lens. > Last I checked, > > (&) = flip ($) > > is both shorter to type, and more explicit than: > > import Control.Apply.Reverse > > - Clark > Well the purpose here is to propose a standard name and fixity, not to save keystrokes. When a lot of libraries start to define a (trivial) thing under different names, that to me is a good indication that it should be in the standard library. It is a matter of keeping the signal-to-noise ratio large, which greatly helps when reading unfamiliar code. Hans -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Apr 17 19:56:29 2014 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 17 Apr 2014 15:56:29 -0400 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> Message-ID: The choice of fixity came about because actually the most common thing replaced by (<&>) is actually (>>=), when the thing you are binding to no longer has an effect, not actually (<$>), despite what the name suggests. This made a non-trivial difference in the amount of parentheses in real code, and was a conscious decision, so reverting it is not something I would do lightly and breaks real code. Back during the discussion of whether we should adopt (&), (<&>) also came up, but with only one voice in favor, and nobody else really feeling passionately, and with various colors like this available for the bikeshed it was dropped. -Edward On Thu, Apr 17, 2014 at 3:32 PM, Hans H?glund wrote: > > Can we argue about the fixity for (<&>)? I've always it as infixl 4, to > mix it in with other applicative operators, e.g.: > > (:) <$> fx <*> fl > > becomes > > fx <&> (:) <*> fl > >> > I agree, this seems to be a mistake in lens. > > > Last I checked, >> >> (&) = flip ($) >> >> is both shorter to type, and more explicit than: >> >> import Control.Apply.Reverse >> >> - Clark >> >> > Well the purpose here is to propose a standard name and fixity, not to > save keystrokes. > > When a lot of libraries start to define a (trivial) thing under different > names, that to me is a good indication that it should be in the standard > library. It is a matter of keeping the signal-to-noise ratio large, which > greatly helps when reading unfamiliar code. > > Hans > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.muranov at gmail.com Thu Apr 17 20:02:10 2014 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Thu, 17 Apr 2014 22:02:10 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> Message-ID: On 17 avr. 2014, at 21:20, Edward Kmett wrote: > Consensus was achieved to add it as an infixl 1 & operator to Data.Function, but not to Prelude,so we just need to put in the patch and you'll see it in GHC 7.10. Why '&' and not '#', for example? I have an empression that '&' often comes in pair with '|' for Boolean operations. Alexey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Apr 17 20:24:10 2014 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 17 Apr 2014 16:24:10 -0400 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> Message-ID: * (|) is already stolen for syntax, so the pairing, while a powerful mnemonic, can't be used at all here. * (#) collides with the use of (#) in MagicHash, so you get uncomfortable cases where you need to throw in a space. * (&) can be read off as "and then". (#) has no such obvious reading and is just more line noise someone has to learn. On Thu, Apr 17, 2014 at 4:02 PM, Alexey Muranov wrote: > On 17 avr. 2014, at 21:20, Edward Kmett wrote: > > Consensus was achieved to add it as an infixl 1 & operator to > Data.Function, but not to Prelude,so we just need to put in the patch and > you'll see it in GHC 7.10. > > > Why '&' and not '#', for example? I have an empression that '&' often > comes in pair with '|' for Boolean operations. > > Alexey. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.karachalias at gmail.com Fri Apr 18 07:22:29 2014 From: george.karachalias at gmail.com (George Karachalias) Date: Fri, 18 Apr 2014 09:22:29 +0200 Subject: [Haskell-cafe] Hackage libraries that make use of GADTs Message-ID: Hello, Could you tell me some Hackage Libraries that make use (heavy or not) of GADTs? George -- things you own end up owning you -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.muranov at gmail.com Fri Apr 18 08:13:33 2014 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Fri, 18 Apr 2014 10:13:33 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> Message-ID: On 17 avr. 2014, at 22:24, Edward Kmett wrote: > * (|) is already stolen for syntax, so the pairing, while a powerful mnemonic, can't be used at all here. > > * (#) collides with the use of (#) in MagicHash, so you get uncomfortable cases where you need to throw in a space. > > * (&) can be read off as "and then". (#) has no such obvious reading and is just more line noise someone has to learn. > Thanks for the explanation. Maybe some Wiki page with a list of syntax and fixity proposals, explanations, comments, and votes could be made for this? One more idea: how about '>-' for 'flip ($)' and '-<' for '$', by analogy with '>>=' and '=<<'? y = 3 >- \x -> x * x -- y == 9 Alexey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at nand.wakku.to Fri Apr 18 08:26:45 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Fri, 18 Apr 2014 10:26:45 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> Message-ID: <20140418102645.GA24255@nanodesu.talocan.mine.nu> On Fri, 18 Apr 2014 10:13:33 +0200, Alexey Muranov wrote: > On 17 avr. 2014, at 22:24, Edward Kmett wrote: > Thanks for the explanation. Maybe some Wiki page with a list of syntax and fixity proposals, explanations, comments, and votes could be made for this? > > One more idea: how about '>-' for 'flip ($)' and '-<' for '$', by analogy with '>>=' and '=<<'? > > y = 3 >- \x -> x * x -- y == 9 Conflicts with ArrowSyntax From alexey.muranov at gmail.com Fri Apr 18 08:37:44 2014 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Fri, 18 Apr 2014 10:37:44 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <20140418102645.GA24255@nanodesu.talocan.mine.nu> References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> <20140418102645.GA24255@nanodesu.talocan.mine.nu> Message-ID: On 18 avr. 2014, at 10:26, Niklas Haas wrote: >> y = 3 >- \x -> x * x -- y == 9 > > Conflicts with ArrowSyntax Thanks. For '|>' and '<|' Hoogle finds something, but there are still some symetric options left: maybe '\-' and '-/'? From malcolm.wallace at me.com Fri Apr 18 10:09:20 2014 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Fri, 18 Apr 2014 11:09:20 +0100 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> Message-ID: On 17 Apr 2014, at 20:20, Edward Kmett wrote: > After the last time this made the rounds, this went to the core libraries committee. > > Consensus was achieved to add it as an infixl 1 & operator to Data.Function, but not to Prelude,so we just need to put in the patch and you'll see it in GHC 7.10. I would like to strongly oppose the theft of the (&) operator from general use. The proposal to put it in Data.Function, such that you need to know you are importing it, is OK, but it should never go into the Prelude. My general position is that there are very few single-character operator names left for ordinary programmers to use locally in their code. Given we now have more than twenty years usage of Haskell, I think it is pretty likely that people have made use of the flexibility to define their own operators for code that will never be widely shared. Taking away those operators from users, to become "standard", will only break old code. As a single datapoint, I grepped for uses of the & operator in our codebase at work, and found ~28,000 LoC where it is used. Regards, Malcolm From alexander at plaimi.net Fri Apr 18 10:21:49 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Fri, 18 Apr 2014 12:21:49 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> Message-ID: <5350FCBD.6060405@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 18/04/14 12:09, Malcolm Wallace wrote: > I would like to strongly oppose the theft of the (&) operator from > general use. The proposal to put it in Data.Function, such that > you need to know you are importing it, is OK, but it should never > go into the Prelude. It is unlikely to ever go into Prelude as '&'. The current patch only puts it in Data.Function. I still maintain that '|>' and '<|' are preferable, and could go in prelude regardless of Data.Sequence. '&' represents conjunction in my head, and furthermore it does not obviously relate to '$'. To remedy my concerns, I think David Menendez's suggested '$$' should be strongly considered. This also remedies your concern of occupying all the one-character namespace, which makes it a stronger candidate for prelude than '&'. And I do think that we should have a reverse application operator in Prelude. Sitting in Data.Function it is only barely more convenient than defining it yourself. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNQ/L0ACgkQRtClrXBQc7VeRAEAsM1m7l/HYd1huc1UaLf/6S/m 2Da8dzFysp6ruQV4aa4BAIyBb/Ekc3Ohn+OIZRdR+FCQ+PQeaR7X+r7SZfFsF58u =yApD -----END PGP SIGNATURE----- From johan.tibell at gmail.com Fri Apr 18 10:31:21 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 18 Apr 2014 12:31:21 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <5350FCBD.6060405@plaimi.net> References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> <5350FCBD.6060405@plaimi.net> Message-ID: Hi all, This proposal comes up every 6-12 months or so. So far our decision has been "no". I don't think we should change that decision unless the circumstances for that decision has changed (I don't think they have.) We use this "don't reopen issues unless circumstances have changed" policy for HP package proposals*. I think it's a good policy, as it saves valuable community energy to discuss new things. If things have truly changed, we can of course have the discussion again. * We took the policy from Python's PEP proposal policy. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Fri Apr 18 10:34:52 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Fri, 18 Apr 2014 12:34:52 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> <5350FCBD.6060405@plaimi.net> Message-ID: <5350FFCC.7080609@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 18/04/14 12:31, Johan Tibell wrote: > So far our decision has been "no". You are mistaken. Please see Edward's email. ?Consensus was achieved to add it as an infixl 1 & operator to Data.Function, but not to Prelude,so we just need to put in the patch and you'll see it in GHC 7.10.? A patch has been provided and a GHC ticket has been opened. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNQ/8wACgkQRtClrXBQc7WG3wD/c59Tg9D5ixxnqjMrwQTKdD/X ZZMp3/W9OxZtcoPhAUwA/j0o4i/fCqsgdGDrrijZNW1PlefmzacNddlYNcqGkDQL =NLHK -----END PGP SIGNATURE----- From johan.tibell at gmail.com Fri Apr 18 10:39:43 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 18 Apr 2014 12:39:43 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <5350FFCC.7080609@plaimi.net> References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> <5350FCBD.6060405@plaimi.net> <5350FFCC.7080609@plaimi.net> Message-ID: On Fri, Apr 18, 2014 at 12:34 PM, Alexander Berntsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 18/04/14 12:31, Johan Tibell wrote: > > So far our decision has been "no". > You are mistaken. Please see Edward's email. > > ?Consensus was achieved to add it as an infixl 1 & operator to > Data.Function, but not to Prelude,so we just need to put in the patch > and you'll see it in GHC 7.10.? > > A patch has been provided and a GHC ticket has been opened. My apologies. I must have glanced over the details since I've seen '&' and '|>' proposed before on this list. Please link to the consensus email in the GHC ticket (I saw one of them got closed because it didn't.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Apr 18 13:53:13 2014 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 18 Apr 2014 09:53:13 -0400 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> Message-ID: I agree. This is not going into Prelude. -Edward On Friday, April 18, 2014, Malcolm Wallace wrote: > > On 17 Apr 2014, at 20:20, Edward Kmett wrote: > > > After the last time this made the rounds, this went to the core > libraries committee. > > > > Consensus was achieved to add it as an infixl 1 & operator to > Data.Function, but not to Prelude,so we just need to put in the patch and > you'll see it in GHC 7.10. > > > I would like to strongly oppose the theft of the (&) operator from general > use. The proposal to put it in Data.Function, such that you need to know > you are importing it, is OK, but it should never go into the Prelude. > > My general position is that there are very few single-character operator > names left for ordinary programmers to use locally in their code. Given we > now have more than twenty years usage of Haskell, I think it is pretty > likely that people have made use of the flexibility to define their own > operators for code that will never be widely shared. Taking away those > operators from users, to become "standard", will only break old code. > > As a single datapoint, I grepped for uses of the & operator in our > codebase at work, and found ~28,000 LoC where it is used. > > Regards, > Malcolm > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From creswick at gmail.com Fri Apr 18 15:20:13 2014 From: creswick at gmail.com (Rogan Creswick) Date: Fri, 18 Apr 2014 08:20:13 -0700 Subject: [Haskell-cafe] Hackage libraries that make use of GADTs In-Reply-To: References: Message-ID: On Fri, Apr 18, 2014 at 12:22 AM, George Karachalias < george.karachalias at gmail.com> wrote: > Hello, > > Could you tell me some Hackage Libraries that make use (heavy or not) of > GADTs? > I used GADTs in the HaVSA library (https://github.com/creswick/HaVSA, and on hackage: https://hackage.haskell.org/package/HaVSA). Take a look at the VersionSpaces data type ( https://github.com/creswick/HaVSA/blob/master/src/AI/VersionSpaces.hs). This is a tree-style type that creates tuples (representing functions) -- the input and output types at each level of the tree can be different, but only the top-level types are relevant when using a VersionSpace. GADTs were recommended as a way to create a single tree type that could be type-correct but have heterogenous types. I doubt anyone is actually using HaVSA, though! It's one of the first haskell projects I worked on, and was an adaptation of a java library I created for an actual project. If anyone is interested in comparing the two implementations, here's the parallel java version: https://code.google.com/p/jversionspaces/ (But please note that this is a /horrible/ use case for Java; it would be much cleaner if Java had type aliasing.) --Rogan > George > > -- > things you own end up owning you > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Fri Apr 18 14:10:39 2014 From: mwm at mired.org (Mike Meyer) Date: Fri, 18 Apr 2014 09:10:39 -0500 Subject: [Haskell-cafe] Minimal Haskell Platform & Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) Message-ID: On Fri, Apr 18, 2014 at 5:31 AM, Johan Tibell wrote: > We use this "don't reopen issues unless circumstances have changed" policy > for HP package proposals*. I think it's a good policy, as it saves valuable > community energy to discuss new things. If things have truly changed, we > can of course have the discussion again. > Where can I find that information? I went looking through the HP pages on Haskell.org, and couldn't turn up anything on contributions, or suggestions, or similar things. I found one link to a github repository, but it didn't have a README :-(. > * We took the policy from Python's PEP proposal policy. > While I'm relatively new to the Haskell community, I've been part of the Python community since I had to explain to my clients what Python was. One of the things that's always impressed me about that community is it's devotion to maintaining the zen of the language. I've watched it grow the official (as in "import this") zen, and the PEP process, and watched various PEPS go through the process. I've even written a few myself, though I only submitted one, which was rejected. Watching the discussion of the syntax proposal reminds me of watching some of the discussions about Python language changes - though if we have a BDFL, I haven't heard of them. That's also how discussions about the Python standard library looked (they're part of the PEP process now). If we want the HP to be generally useful - not just something to make beginners lives easier or provide hard-to-use tools - it needs to be dealt with with equal care. I'd like to contribute to that process. So, questions that I couldn't find answers to: Is there a Haskell equivalent to a Python PEP? Should there be? Is there a place to discus HP issues, other than here? If I want to contribute to the development of the HP, where should I start? Thanks, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.oqube at gmail.com Fri Apr 18 14:20:07 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Fri, 18 Apr 2014 16:20:07 +0200 Subject: [Haskell-cafe] Correctly setting up emacs + ghc-mod Message-ID: Hello, I am struggling to get my emacs settings right for doing significant Haskell development, eg. something more involved than a bunch of source files in a single directory. The issue I am running in currently is that when trying to load files in the interpreter, most source paths are missing which means loading inevitably fails. This is especially annoying with tests: To get things working correctly I need to explicitly add in the console > :set -iwhere/my/src/are Is there any configuration I should be aware of in my cabal files or .emacs file that would correctly set the source roots? Am I missing something? Here is my .emacs configuration. Thanks for any help. ;; haskell coding (require 'auto-complete) (require 'haskell-mode) (require 'haskell-cabal) (autoload 'ghc-init "ghc" nil t) (add-hook 'haskell-mode-hook (lambda () (ghc-init))) (eval-after-load "haskell-mode" '(progn (setq haskell-stylish-on-save t) (setq haskell-process-args-cabal-repl '("--ghc-option=-ferror-spans" "--with-ghc=ghci-ng")) (define-key haskell-mode-map (kbd "C-,") 'haskell-move-nested-left) (define-key haskell-mode-map (kbd "C-.") 'haskell-move-nested-right) (define-key haskell-mode-map (kbd "C-c v c") 'haskell-cabal-visit-file) (define-key haskell-mode-map (kbd "C-c C-c") 'haskell-compile) (define-key haskell-mode-map (kbd "C-x C-d") nil) (setq haskell-font-lock-symbols t) ;; Do this to get a variable in scope (auto-complete-mode) ;; from http://pastebin.com/tJyyEBAS (ac-define-source ghc-mod '((depends ghc) (candidates . (ghc-select-completion-symbol)) (symbol . "s") (cache))) (defun my-ac-haskell-mode () (setq ac-sources '(ac-source-words-in-same-mode-buffers ac-source-dictionary ac-source-ghc-mod))) (add-hook 'haskell-mode-hook 'my-ac-haskell-mode) (defun my-haskell-ac-init () (when (member (file-name-extension buffer-file-name) '("hs" "lhs")) (auto-complete-mode t) (setq ac-sources '(ac-source-words-in-same-mode-buffers ac-source-dictionary ac-source-ghc-mod)))) (add-hook 'find-file-hook 'my-haskell-ac-init))) (add-hook 'haskell-mode-hook 'turn-on-haskell-decl-scan) (add-hook 'haskell-mode-hook 'turn-on-haskell-indentation) (eval-after-load "which-func" '(add-to-list 'which-func-modes 'haskell-mode)) (eval-after-load "haskell-cabal" '(define-key haskell-cabal-mode-map (kbd "C-c C-c") 'haskell-compile)) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From johan.tibell at gmail.com Fri Apr 18 14:48:55 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 18 Apr 2014 16:48:55 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> <5350FCBD.6060405@plaimi.net> <5350FFCC.7080609@plaimi.net> Message-ID: I didn't even notice that this discussion was on haskell-cafe. Ideally such discussions should be on libraries@, as people who only want to read about more important stuff can subscribe to only that list. On Fri, Apr 18, 2014 at 4:33 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > There's a concensus email? Im pretty sure most folks don't check cafe > threads for rfcs :-) > > > On Friday, April 18, 2014, Johan Tibell wrote: > >> On Fri, Apr 18, 2014 at 12:34 PM, Alexander Berntsen < >> alexander at plaimi.net> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> On 18/04/14 12:31, Johan Tibell wrote: >>> > So far our decision has been "no". >>> You are mistaken. Please see Edward's email. >>> >>> ?Consensus was achieved to add it as an infixl 1 & operator to >>> Data.Function, but not to Prelude,so we just need to put in the patch >>> and you'll see it in GHC 7.10.? >>> >>> A patch has been provided and a GHC ticket has been opened. >> >> >> My apologies. I must have glanced over the details since I've seen '&' >> and '|>' proposed before on this list. Please link to the consensus email >> in the GHC ticket (I saw one of them got closed because it didn't.) >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Apr 18 14:33:11 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 18 Apr 2014 10:33:11 -0400 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> <5350FCBD.6060405@plaimi.net> <5350FFCC.7080609@plaimi.net> Message-ID: There's a concensus email? Im pretty sure most folks don't check cafe threads for rfcs :-) On Friday, April 18, 2014, Johan Tibell wrote: > On Fri, Apr 18, 2014 at 12:34 PM, Alexander Berntsen > > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 18/04/14 12:31, Johan Tibell wrote: >> > So far our decision has been "no". >> You are mistaken. Please see Edward's email. >> >> ?Consensus was achieved to add it as an infixl 1 & operator to >> Data.Function, but not to Prelude,so we just need to put in the patch >> and you'll see it in GHC 7.10.? >> >> A patch has been provided and a GHC ticket has been opened. > > > My apologies. I must have glanced over the details since I've seen '&' and > '|>' proposed before on this list. Please link to the consensus email in > the GHC ticket (I saw one of them got closed because it didn't.) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dburke.gw at gmail.com Fri Apr 18 20:18:59 2014 From: dburke.gw at gmail.com (Doug Burke) Date: Fri, 18 Apr 2014 16:18:59 -0400 Subject: [Haskell-cafe] Minimal Haskell Platform & Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: Message-ID: On Fri, Apr 18, 2014 at 10:10 AM, Mike Meyer wrote: > > > Is there a place to discus HP issues, other than here? > > There's the haskell-platform mailing list [1] Doug [1] http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Apr 18 14:56:37 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 18 Apr 2014 10:56:37 -0400 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> <5350FCBD.6060405@plaimi.net> <5350FFCC.7080609@plaimi.net> Message-ID: Indeed! (And while it looks like a Alex and Edward voted, not sure who else did :-) ) On Friday, April 18, 2014, Johan Tibell wrote: > I didn't even notice that this discussion was on haskell-cafe. Ideally > such discussions should be on libraries@, as people who only want to read > about more important stuff can subscribe to only that list. > > > On Fri, Apr 18, 2014 at 4:33 PM, Carter Schonwald < > carter.schonwald at gmail.com > > wrote: > >> There's a concensus email? Im pretty sure most folks don't check cafe >> threads for rfcs :-) >> >> >> On Friday, April 18, 2014, Johan Tibell > >> wrote: >> >>> On Fri, Apr 18, 2014 at 12:34 PM, Alexander Berntsen < >>> alexander at plaimi.net> wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> On 18/04/14 12:31, Johan Tibell wrote: >>>> > So far our decision has been "no". >>>> You are mistaken. Please see Edward's email. >>>> >>>> ?Consensus was achieved to add it as an infixl 1 & operator to >>>> Data.Function, but not to Prelude,so we just need to put in the patch >>>> and you'll see it in GHC 7.10.? >>>> >>>> A patch has been provided and a GHC ticket has been opened. >>> >>> >>> My apologies. I must have glanced over the details since I've seen '&' >>> and '|>' proposed before on this list. Please link to the consensus email >>> in the GHC ticket (I saw one of them got closed because it didn't.) >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Apr 18 20:28:10 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 18 Apr 2014 22:28:10 +0200 Subject: [Haskell-cafe] arbtt 0.8 released Message-ID: <1397852890.2539.21.camel@kirk> Dear arbtt users, I just uploaded arbtt 0.8 to Hackage. See http://arbtt.nomeata.de/doc/users_guide/release-notes.html#release-notes-0.8 for a list of changes. This release is the result of slightly above 100 commits, closing 8 bugs and took a bit more than a year. I hope you like it! Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From benjamin.foppa at gmail.com Fri Apr 18 15:13:56 2014 From: benjamin.foppa at gmail.com (Ben Foppa) Date: Fri, 18 Apr 2014 11:13:56 -0400 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <5350FCBD.6060405@plaimi.net> References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> <5350FCBD.6060405@plaimi.net> Message-ID: ($$) conflicts with conduit :) On Fri, Apr 18, 2014 at 6:21 AM, Alexander Berntsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 18/04/14 12:09, Malcolm Wallace wrote: > > I would like to strongly oppose the theft of the (&) operator from > > general use. The proposal to put it in Data.Function, such that > > you need to know you are importing it, is OK, but it should never > > go into the Prelude. > It is unlikely to ever go into Prelude as '&'. The current patch only > puts it in Data.Function. > > I still maintain that '|>' and '<|' are preferable, and could go in > prelude regardless of Data.Sequence. > > '&' represents conjunction in my head, and furthermore it does not > obviously relate to '$'. To remedy my concerns, I think David > Menendez's suggested '$$' should be strongly considered. This also > remedies your concern of occupying all the one-character namespace, > which makes it a stronger candidate for prelude than '&'. > > And I do think that we should have a reverse application operator in > Prelude. Sitting in Data.Function it is only barely more convenient > than defining it yourself. > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlNQ/L0ACgkQRtClrXBQc7VeRAEAsM1m7l/HYd1huc1UaLf/6S/m > 2Da8dzFysp6ruQV4aa4BAIyBb/Ekc3Ohn+OIZRdR+FCQ+PQeaR7X+r7SZfFsF58u > =yApD > -----END PGP SIGNATURE----- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Apr 18 21:03:29 2014 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 18 Apr 2014 17:03:29 -0400 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <8C31CCAE-9848-4F35-8412-334409C818E0@hanshoglund.se> <53502797.2030509@plaimi.net> <5350FCBD.6060405@plaimi.net> <5350FFCC.7080609@plaimi.net> Message-ID: This was brought up again in one of these very long threads in the cafe that have happened 2-3 times now. Last time when this came up in October, I offered to submit it to the core libraries committee for review as the previous time it had come up it was fairly contentious, and I opted to abstain from expressing an opinion for or against due to my role in the previous proposal. I submitted it to core-libraries-committee at haskell.org. They reviewed it, and came down 4 in favor, 2 not commenting, after a bit of a bikeshedding discussion the existing name was picked, and the scope was declared limited to just putting it in Data.Function, and not including it in Prelude. We decided to wait until 7.10 to put it in since at the time 7.8 was happening "any day now". Now it has happened, so when the topic popped up again it was just a matter of implementing an existing resoution. I do, however, agree the discussion of submitting it should have happened on the libraries mailing list. -Edward Kmett -Edward On Fri, Apr 18, 2014 at 10:56 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Indeed! (And while it looks like a Alex and Edward voted, not sure who > else did :-) ) > > > On Friday, April 18, 2014, Johan Tibell wrote: > >> I didn't even notice that this discussion was on haskell-cafe. Ideally >> such discussions should be on libraries@, as people who only want to >> read about more important stuff can subscribe to only that list. >> >> >> On Fri, Apr 18, 2014 at 4:33 PM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> There's a concensus email? Im pretty sure most folks don't check cafe >>> threads for rfcs :-) >>> >>> >>> On Friday, April 18, 2014, Johan Tibell wrote: >>> >>>> On Fri, Apr 18, 2014 at 12:34 PM, Alexander Berntsen < >>>> alexander at plaimi.net> wrote: >>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA256 >>>>> >>>>> On 18/04/14 12:31, Johan Tibell wrote: >>>>> > So far our decision has been "no". >>>>> You are mistaken. Please see Edward's email. >>>>> >>>>> ?Consensus was achieved to add it as an infixl 1 & operator to >>>>> Data.Function, but not to Prelude,so we just need to put in the patch >>>>> and you'll see it in GHC 7.10.? >>>>> >>>>> A patch has been provided and a GHC ticket has been opened. >>>> >>>> >>>> My apologies. I must have glanced over the details since I've seen '&' >>>> and '|>' proposed before on this list. Please link to the consensus email >>>> in the GHC ticket (I saw one of them got closed because it didn't.) >>>> >>>> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chantepie at altern.org Fri Apr 18 21:18:01 2014 From: chantepie at altern.org (=?ISO-8859-1?Q?C=E9dric_Chantepie?=) Date: Fri, 18 Apr 2014 23:18:01 +0200 Subject: [Haskell-cafe] GHC-7.8.2 & Win Message-ID: <53519689.7050209@altern.org> Hi, Try to setup GHC 7.8.2 & cabal 1.8 on Windows (7/64bits), using binary distributions from haskell.org I get error when I try to install glib package using cabal : cabal: Missing dependency on a foreign library: * Missing (or bad) header file: primitive-memops.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. If the header file does exist, it may contain errors that are caught by the C compiler at the preprocessing stage. In this case you can re-run configure with the verbosity flag -v3 to see the error messages. Failed to install primitive-0.5.2.1 cabal: Error: some packages failed to install: Command cabal install primitive raise the same error. I have tried either within cygwin or from plain cmd. Thanks for any hint, best. From johan.tibell at gmail.com Sat Apr 19 07:30:57 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat, 19 Apr 2014 09:30:57 +0200 Subject: [Haskell-cafe] Minimal Haskell Platform & Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: Message-ID: On Fri, Apr 18, 2014 at 4:10 PM, Mike Meyer wrote: > On Fri, Apr 18, 2014 at 5:31 AM, Johan Tibell wrote: > >> We use this "don't reopen issues unless circumstances have changed" >> policy for HP package proposals*. I think it's a good policy, as it saves >> valuable community energy to discuss new things. If things have truly >> changed, we can of course have the discussion again. >> > > > Where can I find that information? I went looking through the HP pages on > Haskell.org, and couldn't turn up anything on contributions, or > suggestions, or similar things. I found one link to a github repository, > but it didn't have a README :-(. > I believe we mention it in http://trac.haskell.org/haskell-platform/wiki/AddingPackages -------------- next part -------------- An HTML attachment was scrubbed... URL: From 0slemi0 at gmail.com Sat Apr 19 11:05:42 2014 From: 0slemi0 at gmail.com (Andras Slemmer) Date: Sat, 19 Apr 2014 13:05:42 +0200 Subject: [Haskell-cafe] Correctly setting up emacs + ghc-mod In-Reply-To: References: Message-ID: If you're using several source directories then simply specify them in your .cabal with hs-source-dirs. So for example if you have a library in src/lib and a test-suite in src/test and your tests use your lib then you'd have something like this in your .cabal library exposed-modules: Lib hs-source-dirs: src/lib test-suite sometest type: exitcode-stdio-1.0 main-is: Test.hs hs-source-dirs: src/test src/lib On 18 April 2014 16:20, Arnaud Bailly wrote: > Hello, > > I am struggling to get my emacs settings right for doing significant > Haskell development, eg. something more involved than a bunch of source > files in a single directory. The issue I am running in currently is that > when trying to load files in the interpreter, most source paths are missing > which means loading inevitably fails. This is especially annoying with > tests: To get things working correctly I need to explicitly add in the > console > > > :set -iwhere/my/src/are > > Is there any configuration I should be aware of in my cabal files or > .emacs file that would correctly set the source roots? Am I missing > something? > > Here is my .emacs configuration. Thanks for any help. > > ;; haskell coding > > > (require 'auto-complete) > (require 'haskell-mode) > (require 'haskell-cabal) > > (autoload 'ghc-init "ghc" nil t) > > (add-hook 'haskell-mode-hook (lambda () (ghc-init))) > > (eval-after-load "haskell-mode" > '(progn > (setq haskell-stylish-on-save t) > (setq haskell-process-args-cabal-repl '("--ghc-option=-ferror-spans" > "--with-ghc=ghci-ng")) > > (define-key haskell-mode-map (kbd "C-,") 'haskell-move-nested-left) > (define-key haskell-mode-map (kbd "C-.") 'haskell-move-nested-right) > (define-key haskell-mode-map (kbd "C-c v c") > 'haskell-cabal-visit-file) > (define-key haskell-mode-map (kbd "C-c C-c") 'haskell-compile) > (define-key haskell-mode-map (kbd "C-x C-d") nil) > (setq haskell-font-lock-symbols t) > > ;; Do this to get a variable in scope > > > (auto-complete-mode) > > ;; from http://pastebin.com/tJyyEBAS > > > (ac-define-source ghc-mod > '((depends ghc) > (candidates . (ghc-select-completion-symbol)) > (symbol . "s") > (cache))) > > (defun my-ac-haskell-mode () > (setq ac-sources '(ac-source-words-in-same-mode-buffers > ac-source-dictionary > ac-source-ghc-mod))) > (add-hook 'haskell-mode-hook 'my-ac-haskell-mode) > > > (defun my-haskell-ac-init () > (when (member (file-name-extension buffer-file-name) '("hs" "lhs")) > (auto-complete-mode t) > (setq ac-sources '(ac-source-words-in-same-mode-buffers > ac-source-dictionary > ac-source-ghc-mod)))) > (add-hook 'find-file-hook 'my-haskell-ac-init))) > > (add-hook 'haskell-mode-hook 'turn-on-haskell-decl-scan) > (add-hook 'haskell-mode-hook 'turn-on-haskell-indentation) > > (eval-after-load "which-func" > '(add-to-list 'which-func-modes 'haskell-mode)) > > (eval-after-load "haskell-cabal" > '(define-key haskell-cabal-mode-map (kbd "C-c C-c") 'haskell-compile)) > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Sat Apr 19 23:48:25 2014 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 19 Apr 2014 19:48:25 -0400 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) Message-ID: <201404192348.s3JNmPeT013305@stowe.cs.dartmouth.edu> > '$$' should be strongly considered That breaks time-honored practice in hugs and ghci. Doug McIlroy From arnaud.oqube at gmail.com Sun Apr 20 08:20:56 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Sun, 20 Apr 2014 10:20:56 +0200 Subject: [Haskell-cafe] Correctly setting up emacs + ghc-mod In-Reply-To: References: Message-ID: <46ACA9D7-6F00-4753-8B61-C51A2E46A182@gmail.com> This is what I have in my cabal file: library hs-source-dirs: ., fay-shared exposed-modules: Application Foundation but I keep getting same error when loading a file that depends on the fay-shared directory (please not that command-line building with cabal runs fine so this is definitely an issue with my emacs settings). Here is the output I got in haskell interpreter when loading a file that depends on fay-shared/SharedTypes.hs: GHCi is ignoring: /home/vagrant/yesod-splittest/.ghci (run M-x haskell-process-unignore) The next big Haskell project is about to start! If I break, you can: 1. Restart: M-x haskell-process-restart 2. Configure logging: C-h v haskell-process-log (useful for debugging) 3. General config: M-x customize-mode 4. Hide these tips: C-h v haskell-process-show-debug-tips Changed directory: /home/vagrant/yesod-splittest/ Import.hs:18:18-28: Could not find module `SharedTypes' ? Use -v to see a list of the files searched for. Compilation failed. Import.hs:18:18-28: Could not find module `SharedTypes' ? Use -v to see a list of the files searched for. Compilation failed. ?> Thanks Arnaud On 19 Apr 2014, at 13:05, Andras Slemmer <0slemi0 at gmail.com> wrote: > If you're using several source directories then simply specify them in your .cabal with hs-source-dirs. So for example if you have a library in src/lib and a test-suite in src/test and your tests use your lib then you'd have something like this in your .cabal > > library > exposed-modules: Lib > hs-source-dirs: src/lib > > test-suite sometest > type: exitcode-stdio-1.0 > main-is: Test.hs > hs-source-dirs: src/test src/lib > > > > On 18 April 2014 16:20, Arnaud Bailly wrote: > Hello, > > I am struggling to get my emacs settings right for doing significant Haskell development, eg. something more involved than a bunch of source files in a single directory. The issue I am running in currently is that when trying to load files in the interpreter, most source paths are missing which means loading inevitably fails. This is especially annoying with tests: To get things working correctly I need to explicitly add in the console > > > :set -iwhere/my/src/are > > Is there any configuration I should be aware of in my cabal files or .emacs file that would correctly set the source roots? Am I missing something? > > Here is my .emacs configuration. Thanks for any help. > > ;; haskell coding > (require 'auto-complete) > (require 'haskell-mode) > (require 'haskell-cabal) > > (autoload 'ghc-init "ghc" nil t) > > (add-hook 'haskell-mode-hook (lambda () (ghc-init))) > > (eval-after-load "haskell-mode" > '(progn > (setq haskell-stylish-on-save t) > (setq haskell-process-args-cabal-repl '("--ghc-option=-ferror-spans" > "--with-ghc=ghci-ng")) > > (define-key haskell-mode-map (kbd "C-,") 'haskell-move-nested-left) > (define-key haskell-mode-map (kbd "C-.") 'haskell-move-nested-right) > (define-key haskell-mode-map (kbd "C-c v c") 'haskell-cabal-visit-file) > (define-key haskell-mode-map (kbd "C-c C-c") 'haskell-compile) > (define-key haskell-mode-map (kbd "C-x C-d") nil) > (setq haskell-font-lock-symbols t) > > ;; Do this to get a variable in scope > (auto-complete-mode) > > ;; from http://pastebin.com/tJyyEBAS > (ac-define-source ghc-mod > '((depends ghc) > (candidates . (ghc-select-completion-symbol)) > (symbol . "s") > (cache))) > > (defun my-ac-haskell-mode () > (setq ac-sources '(ac-source-words-in-same-mode-buffers > ac-source-dictionary > ac-source-ghc-mod))) > (add-hook 'haskell-mode-hook 'my-ac-haskell-mode) > > > (defun my-haskell-ac-init () > (when (member (file-name-extension buffer-file-name) '("hs" "lhs")) > (auto-complete-mode t) > (setq ac-sources '(ac-source-words-in-same-mode-buffers > ac-source-dictionary > ac-source-ghc-mod)))) > (add-hook 'find-file-hook 'my-haskell-ac-init))) > > (add-hook 'haskell-mode-hook 'turn-on-haskell-decl-scan) > (add-hook 'haskell-mode-hook 'turn-on-haskell-indentation) > > (eval-after-load "which-func" > '(add-to-list 'which-func-modes 'haskell-mode)) > > (eval-after-load "haskell-cabal" > '(define-key haskell-cabal-mode-map (kbd "C-c C-c") 'haskell-compile)) > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From johan.tibell at gmail.com Sun Apr 20 11:42:05 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun, 20 Apr 2014 13:42:05 +0200 Subject: [Haskell-cafe] Announcing cabal 1.20 Message-ID: Hi all, On behalf of all the cabal contributors, I'm proud to announce cabal 1.20. With 404 commits since the 1.18 release, this is a feature packed release. Here's a short summary of the perhaps most notable changes: * Dependency freezing * Parallel cabal build * Flag to temporary ignore upper bounds * Unnecessary re-linking avoidance * Streaming cabal test output * New cabal exec command * Haddock configuration options I did a longer write-up about the new features on my blog: http://blog.johantibell.com/2014/04/announcing-cabal-120.html ## Contributors Here are the contributors for this release, ordered by number of commits: * Mikhail Glushenkov * Johan Tibell * Duncan Coutts * Thomas Tuegel * Ian D. Bollinger * Ben Armston * Niklas Hamb?chen * Daniel Trstenjak * Tuncer Ayaz * Herbert Valerio Riedel * Tillmann Rendel * Liyang HU * Dominic Steinitz * Brent Yorgey * Ricky Elrod * Geoff Nixon * Florian Hartwig * Bob Ippolito * Bj?rn Peem?ller * Wojciech Danilo * Sergei Trofimovich * Ryan Trinkle * Ryan Newton * Roman Cheplyaka * Peter Selinger * Niklas Haas * Nikita Karetnikov * Nick Smallbone * Mike Craig * Markus Pfeiffer * Luke Iannini * Luite Stegeman * John Lato * Jens Petersen * Jason Dagit * Gabor Pali * Daniel Velkov * Ben Millwood Apologies if someone was left out. Once in a while we have to make commits on behalf of an author. Those authors are not captured above. Enjoy, Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.matthews7 at gmail.com Sun Apr 20 11:48:33 2014 From: tim.matthews7 at gmail.com (Tim Matthews) Date: Sun, 20 Apr 2014 23:48:33 +1200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <201404192348.s3JNmPeT013305@stowe.cs.dartmouth.edu> References: <201404192348.s3JNmPeT013305@stowe.cs.dartmouth.edu> Message-ID: I think Applicative's use of <*> and <**> means that reverse fmap, ie reverse <$> should be <$$> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.muranov at gmail.com Sun Apr 20 12:53:23 2014 From: alexey.muranov at gmail.com (Alexey Muranov) Date: Sun, 20 Apr 2014 14:53:23 +0200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: References: <201404192348.s3JNmPeT013305@stowe.cs.dartmouth.edu> Message-ID: <2D7AA4BC-961A-4609-9E4E-4EC00B1E3218@gmail.com> On 20 avr. 2014, at 13:48, Tim Matthews wrote: > I think Applicative's use of <*> and <**> means that reverse fmap, ie reverse <$> should be <$$> This looks consistent to me. Excuse me however for being a bit repetitive, i just want to state more clearly my previous argument in favour of summetric arrow-like notation for "apply" and "reverse apply." In Haskell wiki book, in the introduction to monads, it is written: let x = foo in bar corresponds to (\x -> bar) foo and x <- foo; bar corresponds to foo >>= (\x -> bar) IMO it would be nice to be able rewrite here: let x = foo in bar corresponds to foo \- (\x -> bar) or something like that. Alexey. From zsol.zsol at gmail.com Sun Apr 20 14:28:31 2014 From: zsol.zsol at gmail.com (Zsolt Dollenstein) Date: Sun, 20 Apr 2014 16:28:31 +0200 Subject: [Haskell-cafe] Correctly setting up emacs + ghc-mod In-Reply-To: <46ACA9D7-6F00-4753-8B61-C51A2E46A182@gmail.com> References: <46ACA9D7-6F00-4753-8B61-C51A2E46A182@gmail.com> Message-ID: Have you tried M-x haskell-process-unignore? On Sun, Apr 20, 2014 at 10:20 AM, Arnaud Bailly wrote: > This is what I have in my cabal file: > > *library* > *hs-source-dirs*: ., fay-shared > *exposed-modules*: Application > Foundation > > > but I keep getting same error when loading a file that depends on the > fay-shared directory (please not that command-line building with cabal runs > fine so this is definitely an issue with my emacs settings). > > Here is the output I got in haskell interpreter when loading a file that > depends on fay-shared/SharedTypes.hs: > > *GHCi is ignoring: /home/vagrant/yesod-splittest/.ghci (run M-x > haskell-process-unignore) > * > The next big Haskell project is about to start! > If I break, you can: > 1. Restart: M-x haskell-process-restart > 2. Configure logging: C-h v haskell-process-log (useful for debugging) > 3. General config: M-x customize-mode > 4. Hide these tips: C-h v haskell-process-show-debug-tips > Changed directory: /home/vagrant/yesod-splittest/ > *Import.hs:18:18-28: Could not find module `SharedTypes' ? > > * > * Use -v to see a list of the files searched for. > > * > *Compilation failed. > > * > *Import.hs:18:18-28: Could not find module `SharedTypes' ? > > * > * Use -v to see a list of the files searched for. > > * > *Compilation failed. > > * > *?> * > > Thanks > Arnaud > > > On 19 Apr 2014, at 13:05, Andras Slemmer <0slemi0 at gmail.com> wrote: > > If you're using several source directories then simply specify them in > your .cabal with hs-source-dirs. So for example if you have a library in > src/lib and a test-suite in src/test and your tests use your lib then you'd > have something like this in your .cabal > > library > exposed-modules: Lib > hs-source-dirs: src/lib > > test-suite sometest > type: exitcode-stdio-1.0 > main-is: Test.hs > hs-source-dirs: src/test src/lib > > > > On 18 April 2014 16:20, Arnaud Bailly wrote: > >> Hello, >> >> I am struggling to get my emacs settings right for doing significant >> Haskell development, eg. something more involved than a bunch of source >> files in a single directory. The issue I am running in currently is that >> when trying to load files in the interpreter, most source paths are missing >> which means loading inevitably fails. This is especially annoying with >> tests: To get things working correctly I need to explicitly add in the >> console >> >> > :set -iwhere/my/src/are >> >> Is there any configuration I should be aware of in my cabal files or >> .emacs file that would correctly set the source roots? Am I missing >> something? >> >> Here is my .emacs configuration. Thanks for any help. >> >> ;; haskell coding >> >> >> (require 'auto-complete) >> (require 'haskell-mode) >> (require 'haskell-cabal) >> >> (autoload 'ghc-init "ghc" nil t) >> >> (add-hook 'haskell-mode-hook (lambda () (ghc-init))) >> >> (eval-after-load "haskell-mode" >> '(progn >> (setq haskell-stylish-on-save t) >> (setq haskell-process-args-cabal-repl '("--ghc-option=-ferror-spans" >> "--with-ghc=ghci-ng")) >> >> (define-key haskell-mode-map (kbd "C-,") 'haskell-move-nested-left) >> (define-key haskell-mode-map (kbd "C-.") 'haskell-move-nested-right) >> (define-key haskell-mode-map (kbd "C-c v c") >> 'haskell-cabal-visit-file) >> (define-key haskell-mode-map (kbd "C-c C-c") 'haskell-compile) >> (define-key haskell-mode-map (kbd "C-x C-d") nil) >> (setq haskell-font-lock-symbols t) >> >> ;; Do this to get a variable in scope >> >> >> (auto-complete-mode) >> >> ;; from http://pastebin.com/tJyyEBAS >> >> >> (ac-define-source ghc-mod >> '((depends ghc) >> (candidates . (ghc-select-completion-symbol)) >> (symbol . "s") >> (cache))) >> >> (defun my-ac-haskell-mode () >> (setq ac-sources '(ac-source-words-in-same-mode-buffers >> ac-source-dictionary >> ac-source-ghc-mod))) >> (add-hook 'haskell-mode-hook 'my-ac-haskell-mode) >> >> >> (defun my-haskell-ac-init () >> (when (member (file-name-extension buffer-file-name) '("hs" "lhs" >> )) >> (auto-complete-mode t) >> (setq ac-sources '(ac-source-words-in-same-mode-buffers >> ac-source-dictionary >> ac-source-ghc-mod)))) >> (add-hook 'find-file-hook 'my-haskell-ac-init))) >> >> (add-hook 'haskell-mode-hook 'turn-on-haskell-decl-scan) >> (add-hook 'haskell-mode-hook 'turn-on-haskell-indentation) >> >> (eval-after-load "which-func" >> '(add-to-list 'which-func-modes 'haskell-mode)) >> >> (eval-after-load "haskell-cabal" >> '(define-key haskell-cabal-mode-map (kbd "C-c C-c") >> 'haskell-compile)) >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at therning.org Sun Apr 20 16:11:25 2014 From: magnus at therning.org (Magnus Therning) Date: Sun, 20 Apr 2014 18:11:25 +0200 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? Message-ID: <20140420161125.GA3937@tatooine> I'm working on the packaging of Ghc for Arch Linux and the packaging of Ghc 7.8 was in place about a week ago. It was delivered with `Cabal` 1.18, and already now there's a 1.20 available, which is required by the latest version of `cabal-install` :( Ghc 7.8 comes with quite a few other basic libraries. Are there any dependencies between these libraries besides the obvious one on `base`? In other words, can I update Cabal without running into the diamond-dependency problem? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From a.s.chapman.10 at aberdeen.ac.uk Sun Apr 20 21:12:29 2014 From: a.s.chapman.10 at aberdeen.ac.uk (Chapman, Anthony Sergio) Date: Sun, 20 Apr 2014 21:12:29 +0000 Subject: [Haskell-cafe] Problem with percentage function? In-Reply-To: <20140420161125.GA3937@tatooine> References: <20140420161125.GA3937@tatooine> Message-ID: <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> Good evening everyone. I've made a percentage function for my application (with help from the internet) which is as follows. -- Turns a number into a percentage toPerc :: Double -> Double toPerc x = 100*(myRound x 4) -- Rounds a number to s decimal points myRound n s = fromIntegral (round (n * factor)) / factor where factor = fromIntegral (10^s) I would it to round to 2 decimal places no matter what the size of the input is ei toPerc 0.22222222222222 --- = 22.22 toPerc 0.22342222222222 --- = 22.34 The problem is that what I actually get is 22.220000000000002 If anyone has any suggestions on how to solve this problem or know of a different/better way to convert to percentage please let me know. Thanks From a.s.chapman.10 at aberdeen.ac.uk Sun Apr 20 21:19:30 2014 From: a.s.chapman.10 at aberdeen.ac.uk (Chapman, Anthony Sergio) Date: Sun, 20 Apr 2014 21:19:30 +0000 Subject: [Haskell-cafe] Problem with percentage function? In-Reply-To: <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> References: <20140420161125.GA3937@tatooine>, <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> Message-ID: Forgot to mentions that it works fine with odds such a 0.333333333333 or 0.55555555555 but not for evens such as 0.444444 Thanks ________________________________________ From: Haskell-Cafe on behalf of Chapman, Anthony Sergio Sent: 20 April 2014 22:12 To: Haskell Cafe Subject: [Haskell-cafe] Problem with percentage function? Good evening everyone. I've made a percentage function for my application (with help from the internet) which is as follows. -- Turns a number into a percentage toPerc :: Double -> Double toPerc x = 100*(myRound x 4) -- Rounds a number to s decimal points myRound n s = fromIntegral (round (n * factor)) / factor where factor = fromIntegral (10^s) I would it to round to 2 decimal places no matter what the size of the input is ei toPerc 0.22222222222222 --- = 22.22 toPerc 0.22342222222222 --- = 22.34 The problem is that what I actually get is 22.220000000000002 If anyone has any suggestions on how to solve this problem or know of a different/better way to convert to percentage please let me know. Thanks _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe From bob at redivi.com Sun Apr 20 21:21:10 2014 From: bob at redivi.com (Bob Ippolito) Date: Sun, 20 Apr 2014 14:21:10 -0700 Subject: [Haskell-cafe] Problem with percentage function? In-Reply-To: <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> References: <20140420161125.GA3937@tatooine> <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> Message-ID: The problem is the type Double, which can not exactly represent numbers such as 0.1. You would have this same issue in any language where you're using binary floating point. How to work around this really depends on the use case. There are many approaches, such as using a type that can exactly represent all of the numbers in the domain you're working with, or just doing this sort of rounding on output. http://floating-point-gui.de/ On Sun, Apr 20, 2014 at 2:12 PM, Chapman, Anthony Sergio < a.s.chapman.10 at aberdeen.ac.uk> wrote: > Good evening everyone. > > I've made a percentage function for my application (with help from the > internet) which is as follows. > > -- Turns a number into a percentage > toPerc :: Double -> Double > toPerc x = 100*(myRound x 4) > -- Rounds a number to s decimal points > myRound n s = fromIntegral (round (n * factor)) / factor > where factor = fromIntegral (10^s) > > I would it to round to 2 decimal places no matter what the size of the > input is > > ei toPerc 0.22222222222222 --- = 22.22 > toPerc 0.22342222222222 --- = 22.34 > > The problem is that what I actually get is 22.220000000000002 > > If anyone has any suggestions on how to solve this problem or know of a > different/better way to convert to percentage please let me know. > > Thanks > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at karlv.net Sun Apr 20 21:21:45 2014 From: karl at karlv.net (Karl Voelker) Date: Sun, 20 Apr 2014 14:21:45 -0700 Subject: [Haskell-cafe] Problem with percentage function? In-Reply-To: <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> References: <20140420161125.GA3937@tatooine> <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> Message-ID: <1398028905.20906.108455165.0CE33227@webmail.messagingengine.com> On Sun, Apr 20, 2014, at 02:12 PM, Chapman, Anthony Sergio wrote: > I would it to round to 2 decimal places no matter what the size of the > input is > > The problem is that what I actually get is 22.220000000000002 > The Double type cannot represent all values exactly, which produces this behavior. [1] If you just want to round the number for display purposes, you should probably round it as part of the conversion to text. Otherwise, there are a lot of other numeric representations, but the right one would depend on your application. -Karl 1: http://en.wikipedia.org/wiki/Double_precision_floating-point_format From allbery.b at gmail.com Sun Apr 20 21:30:17 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 20 Apr 2014 17:30:17 -0400 Subject: [Haskell-cafe] Problem with percentage function? In-Reply-To: <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> References: <20140420161125.GA3937@tatooine> <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> Message-ID: On Sun, Apr 20, 2014 at 5:12 PM, Chapman, Anthony Sergio < a.s.chapman.10 at aberdeen.ac.uk> wrote: > I would it to round to 2 decimal places no matter what the size of the > input is > > ei toPerc 0.22222222222222 --- = 22.22 > toPerc 0.22342222222222 --- = 22.34 > > The problem is that what I actually get is 22.220000000000002 > Looks like typical floating point behavior to me. The last place can't be precisely controlled because you are printing in base 10 but the internal format (as defined by the CPU) is base 2 and very few base 10 decimals have exact base 2 representations. This is not a bug (unless you consider the existence of floating point to be a bug) and cannot be "fixed". -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Apr 20 21:45:29 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 20 Apr 2014 22:45:29 +0100 Subject: [Haskell-cafe] Problem with percentage function? In-Reply-To: <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> References: <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> Message-ID: <20140420214529.GB9884@weber> On Sun, Apr 20, 2014 at 09:12:29PM +0000, Chapman, Anthony Sergio wrote: > -- Turns a number into a percentage > toPerc :: Double -> Double > toPerc x = 100*(myRound x 4) > -- Rounds a number to s decimal points > myRound n s = fromIntegral (round (n * factor)) / factor > where factor = fromIntegral (10^s) > > I would it to round to 2 decimal places no matter what the size of the input is > > ei toPerc 0.22222222222222 --- = 22.22 > toPerc 0.22342222222222 --- = 22.34 > > The problem is that what I actually get is 22.220000000000002 The other replies, whilst correct, have been a bit oblique to your question. The upshot is you should do the rounding when displaying, not in the floating point value itself. import Text.Printf toPerc :: Double -> String toPerc = printf "%.2f" . (*100) *Main> toPerc 0.22222222222222 "22.22" *Main> toPerc 0.22342222222222 "22.34" Tom From a.s.chapman.10 at aberdeen.ac.uk Sun Apr 20 21:50:43 2014 From: a.s.chapman.10 at aberdeen.ac.uk (Chapman, Anthony Sergio) Date: Sun, 20 Apr 2014 21:50:43 +0000 Subject: [Haskell-cafe] Problem with percentage function? In-Reply-To: <20140420214529.GB9884@weber> References: <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com>, <20140420214529.GB9884@weber> Message-ID: <177f4a9a5c384343833629b05819e518@DBXPR01MB015.eurprd01.prod.exchangelabs.com> Thank you very much, that worked a charm. The numbers crunching was done way before the printing so that's all I needed. Now it seems a bit peculiar to me that in your functions, you didn't define the input ie toPerc = printf "%.2f" . (*100) instead of toPerc number = printf "%.2f" . (*100) Would you might pointing me in the right direction to understand why you didn't have to give it a variable input when defining the function? Thanks again. ________________________________________ From: Haskell-Cafe on behalf of Tom Ellis Sent: 20 April 2014 22:45 To: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Problem with percentage function? On Sun, Apr 20, 2014 at 09:12:29PM +0000, Chapman, Anthony Sergio wrote: > -- Turns a number into a percentage > toPerc :: Double -> Double > toPerc x = 100*(myRound x 4) > -- Rounds a number to s decimal points > myRound n s = fromIntegral (round (n * factor)) / factor > where factor = fromIntegral (10^s) > > I would it to round to 2 decimal places no matter what the size of the input is > > ei toPerc 0.22222222222222 --- = 22.22 > toPerc 0.22342222222222 --- = 22.34 > > The problem is that what I actually get is 22.220000000000002 The other replies, whilst correct, have been a bit oblique to your question. The upshot is you should do the rounding when displaying, not in the floating point value itself. import Text.Printf toPerc :: Double -> String toPerc = printf "%.2f" . (*100) *Main> toPerc 0.22222222222222 "22.22" *Main> toPerc 0.22342222222222 "22.34" Tom _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Apr 20 22:00:10 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 20 Apr 2014 23:00:10 +0100 Subject: [Haskell-cafe] Problem with percentage function? In-Reply-To: <177f4a9a5c384343833629b05819e518@DBXPR01MB015.eurprd01.prod.exchangelabs.com> References: <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> <20140420214529.GB9884@weber> <177f4a9a5c384343833629b05819e518@DBXPR01MB015.eurprd01.prod.exchangelabs.com> Message-ID: <20140420220010.GC9884@weber> On Sun, Apr 20, 2014 at 09:50:43PM +0000, Chapman, Anthony Sergio wrote: > Now it seems a bit peculiar to me that in your functions, you didn't > define the input ie toPerc = printf "%.2f" . (*100) instead of toPerc > number = printf "%.2f" . (*100) This expression uses the composition operator (.) rather than using function application directly. Note that for any functions 'f' and 'g', 'f . g' is defined to be the function '\x -> f (g x)'. Thus writing toPerc = printf "%.2f" . (*100) just means toPerc = \x -> printf "%.2f" ((*100) x) Desugaring the operator section gives toPerc = \x -> printf "%.2f" (x * 100) and moving the lambda to become an argument of 'toPerc' gives toPerc x = printf "%.2f" (x * 100) which is now in a form probably more familiar to you. Tom From carter.schonwald at gmail.com Sun Apr 20 22:01:33 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 20 Apr 2014 18:01:33 -0400 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: <20140420161125.GA3937@tatooine> References: <20140420161125.GA3937@tatooine> Message-ID: yup. go crazy :) On Sun, Apr 20, 2014 at 12:11 PM, Magnus Therning wrote: > I'm working on the packaging of Ghc for Arch Linux and the packaging > of Ghc 7.8 was in place about a week ago. It was delivered with > `Cabal` 1.18, and already now there's a 1.20 available, which is > required by the latest version of `cabal-install` :( > > Ghc 7.8 comes with quite a few other basic libraries. Are there any > dependencies between these libraries besides the obvious one on > `base`? > > In other words, can I update Cabal without running into the > diamond-dependency problem? > > /M > > -- > Magnus Therning OpenPGP: 0xAB4DFBA4 > email: magnus at therning.org jabber: magnus at therning.org > twitter: magthe http://therning.org/magnus > > Most software today is very much like an Egyptian pyramid with > millions of bricks piled on top of each other, with no structural > integrity, but just done by brute force and thousands of slaves. > -- Alan Kay > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Sun Apr 20 22:18:20 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 21 Apr 2014 08:18:20 +1000 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: <20140420161125.GA3937@tatooine> References: <20140420161125.GA3937@tatooine> Message-ID: On 21 April 2014 02:11, Magnus Therning wrote: > I'm working on the packaging of Ghc for Arch Linux and the packaging > of Ghc 7.8 was in place about a week ago. It was delivered with > `Cabal` 1.18, and already now there's a 1.20 available, which is > required by the latest version of `cabal-install` :( > > Ghc 7.8 comes with quite a few other basic libraries. Are there any > dependencies between these libraries besides the obvious one on > `base`? > > In other words, can I update Cabal without running into the > diamond-dependency problem? The only time I've had a problem with Exherbo packages is that some of them (e.g. haskell-docs) require using the version of Cabal shipped with GHC (I think it was to have consistency with the version of Cabal that Haddock was built with); as long as the Arch packages can specify "use GHC's Cabal" for the few cases which it's necessary then you shouldn't have a problem. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From flickyfrans at gmail.com Mon Apr 21 00:47:26 2014 From: flickyfrans at gmail.com (flicky frans) Date: Mon, 21 Apr 2014 04:47:26 +0400 Subject: [Haskell-cafe] A list library without fixpoints and recursive types. Message-ID: Hello. I read some Oleg Kiselyov's papers and tried to write more or less efficient list library with lists represented as their right fold, as mentioned here http://okmij.org/ftp/Haskell/zip-folds.lhs : It would be interesting to see, constructively, how to build the full-fledged (FR)-list library and avoid general recursion. Let the FR-list be the only driver of iterations. Here is the code: http://ideone.com/NKNeWy I don't post it to hackage, since I'm not sure, these lists are really efficient. There are two main ideas: 1) List is represented as an accumulating right fold, and an accumulator passes from left to right. 2) For efficiency purposes elements skipping is incorporated into the cons (($:) in the code) function. So there is only one isSkipped test (d == 0 in the code) for every element, no matter, how many times drop (or tail or dropWhile) was applied. So there are no redundant (<= 0) checks, as described in the zip-folds paper: The function sdrop shows the major deficiency: we're stuck with the (<=0) test for the rest of the stream. In this case, some delimited continuation operators like `control' can help, in limited circumstances. Here are the pluses: 1) No fixpoints and recursive types. 2) These lists are totally isomorphic to ordinary haskell's, even in a strict monad. 3) No redundant (<= 0) checks. There are some not very big problems with this encoding: 1) Code becomes more complicated than with the ordinary right fold. 2) In fscanl and fsndMapAccumL functions skipped elements are traversed twice, because you need to traverse an accumulator through skipped elements too. And the same holds for the fdropWhile function with additional skipping overhead. 3) Since an accumulator passes from left to right, it's not possible to efficiently fuse fscanr and fmapAccumR functions, so they are defined in the terms of ($:) and ffoldr. And one big problem: zipWith and all other functions, that require parallel lists processing, are quadratic. And the same holds for the ftails function and all other functions, that deconstruct a list by repeatedly applying (fhead . ftail) or collect lists, obtained by repeteadly applied ftail function. However I have never seen any other representation, expressible in pure System F with higher-rank types, which allows such deconstruction in a linear time. If someone knows, give me a link, please. Any suggestions are welcome. From benjamin.foppa at gmail.com Mon Apr 21 00:52:22 2014 From: benjamin.foppa at gmail.com (Ben Foppa) Date: Sun, 20 Apr 2014 20:52:22 -0400 Subject: [Haskell-cafe] conduit zips Message-ID: Since conduit-1.1.*, the package hasn't contained conduit zipping functions anymore. They don't appear to have been moved to conduit-extra, either. Did they get lost in the ether, or are they in a separate package? -------------- next part -------------- An HTML attachment was scrubbed... URL: From midfield at gmail.com Mon Apr 21 00:53:34 2014 From: midfield at gmail.com (Ben) Date: Sun, 20 Apr 2014 17:53:34 -0700 Subject: [Haskell-cafe] Problem with percentage function? In-Reply-To: <20140420220010.GC9884@weber> References: <9728527461944ca58f317a84e5b46b8e@DBXPR01MB015.eurprd01.prod.exchangelabs.com> <20140420214529.GB9884@weber> <177f4a9a5c384343833629b05819e518@DBXPR01MB015.eurprd01.prod.exchangelabs.com> <20140420220010.GC9884@weber> Message-ID: <99650116-7129-476E-A0EA-B548A1F76D2B@gmail.com> since this seems to come up with some regularity, i'm curious, does the haskell standard or ghc implement Florian Loitsch, "Printing Floating-Point Numbers Quickly and Accurately with Integers" for floating types? it seems like that would go a long way towards preventing this kind of confusion. i seem to recall brian o'sullivan using this algorithm for aeson or something. b On Apr 20, 2014, at 3:00 PM, Tom Ellis wrote: > On Sun, Apr 20, 2014 at 09:50:43PM +0000, Chapman, Anthony Sergio wrote: >> Now it seems a bit peculiar to me that in your functions, you didn't >> define the input ie toPerc = printf "%.2f" . (*100) instead of toPerc >> number = printf "%.2f" . (*100) > > This expression uses the composition operator (.) rather than using function > application directly. Note that for any functions 'f' and 'g', 'f . g' is > defined to be the function '\x -> f (g x)'. Thus writing > > toPerc = printf "%.2f" . (*100) > > just means > > toPerc = \x -> printf "%.2f" ((*100) x) > > Desugaring the operator section gives > > toPerc = \x -> printf "%.2f" (x * 100) > > and moving the lambda to become an argument of 'toPerc' gives > > toPerc x = printf "%.2f" (x * 100) > > which is now in a form probably more familiar to you. > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4885 bytes Desc: not available URL: From mantkiew at gsd.uwaterloo.ca Mon Apr 21 01:10:01 2014 From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz) Date: Sun, 20 Apr 2014 21:10:01 -0400 Subject: [Haskell-cafe] GHC-7.8.2 & Win In-Reply-To: <53519689.7050209@altern.org> References: <53519689.7050209@altern.org> Message-ID: Hi, you need to install these deps. manually. This might be of help: https://github.com/23Skidoo/haskell-platform-windows It's also good to use MinGW and MSYS. MinGW comes with the platform. MSYS currently doesn't but it should too. You can install them yourself, if you don't have the platform. Regarding third-party libraries, I only have experience with `glpk-hs` package which is a wrapper around the GLPK solver. It took me a lot of time to get this to work but in general, try to get a binary build for windows (for GLPK, there's a Winglpk on sourceforge) and then you use `--extra-include-dirs=` and `--extra-lib-dirs=` so specify the locations of the library files. In my case, I use a Makefile for this, which accepts a $(glpk) argument with the install location of Winglpk. ``` GPLK_LIBS_INCLUDES := --extra-include-dirs=$(glpk)/src --extra-include-dirs=$(glpk)/src/amd --extra-include-dirs=$(glpk)/src/colamd --extra-include-dirs=$(glpk)/src/minisat --extra-include-dirs=$(glpk)/src/zlib --extra-lib-dirs=$(glpk)/w32 ``` Then I call cabal like this `cabal install --only-dependencies $(GPLK_LIBS_INCLUDES)` Finally, (just in case...), with MSYS you give paths on windows like this, for example, `/c/lib/glpk-4.51`. Hope that helps, Michal On Fri, Apr 18, 2014 at 5:18 PM, C?dric Chantepie wrote: > Hi, > > Try to setup GHC 7.8.2 & cabal 1.8 on Windows (7/64bits), using binary > distributions from haskell.org I get error when I try to install glib > package using cabal : > > cabal: Missing dependency on a foreign library: > * Missing (or bad) header file: primitive-memops.h > This problem can usually be solved by installing the system package that > provides this library (you may need the "-dev" version). If the library is > already installed but in a non-standard location then you can use the flags > --extra-include-dirs= and --extra-lib-dirs= to specify where it is. > If the header file does exist, it may contain errors that are caught by > the C > compiler at the preprocessing stage. In this case you can re-run configure > with the verbosity flag -v3 to see the error messages. > Failed to install primitive-0.5.2.1 > cabal: Error: some packages failed to install: > > Command cabal install primitive raise the same error. > > I have tried either within cygwin or from plain cmd. > > Thanks for any hint, best. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Mon Apr 21 05:09:13 2014 From: spam at scientician.net (Bardur Arantsson) Date: Mon, 21 Apr 2014 07:09:13 +0200 Subject: [Haskell-cafe] Does this typeclass have a name? Message-ID: Hi all, I was wondering if anyone out there knows if this type class has a name? class Foo a e where foo :: e -> a -> a bar :: a (I also have a fundep a -> e, but that's not essential.) Essentially the usage is: You have a sequence of "events" e_i and a starting value "bar" and can use the "foo" function to apply all events to that starting value foo e_n $ foo e_{n-1} $ ... $ foo e_0 $ bar and thus get the final value of the a induced by the events e_i. (I've included the "bar" starting value in the type class, but I suppose it could be supplied by a Default instance.) Regards, From magnus at therning.org Mon Apr 21 05:35:32 2014 From: magnus at therning.org (Magnus Therning) Date: Mon, 21 Apr 2014 07:35:32 +0200 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: References: <20140420161125.GA3937@tatooine> Message-ID: <20140421053532.GA6082@tatooine> On Sun, Apr 20, 2014 at 06:01:33PM -0400, Carter Schonwald wrote: > yup. go crazy :) What other packages that are shipped with Ghc can I update without running into the diamond-dependency problem? Package | Safe to update ================================= Cabal | ? array | base | bin-package-db | binary | bytestring | containers | deepseq | directory | filepath | ghc-prim | haskell2010 | haskell98 | hoopl | hpc | integer-gmp | old-locale | old-time | pretty | process | rts | template-haskell | time | transformers | unix | /M > On Sun, Apr 20, 2014 at 12:11 PM, Magnus Therning wrote: > > > I'm working on the packaging of Ghc for Arch Linux and the packaging > > of Ghc 7.8 was in place about a week ago. It was delivered with > > `Cabal` 1.18, and already now there's a 1.20 available, which is > > required by the latest version of `cabal-install` :( > > > > Ghc 7.8 comes with quite a few other basic libraries. Are there any > > dependencies between these libraries besides the obvious one on > > `base`? > > > > In other words, can I update Cabal without running into the > > diamond-dependency problem? > > > > /M > > > > -- > > Magnus Therning OpenPGP: 0xAB4DFBA4 > > email: magnus at therning.org jabber: magnus at therning.org > > twitter: magthe http://therning.org/magnus > > > > Most software today is very much like an Egyptian pyramid with > > millions of bricks piled on top of each other, with no structural > > integrity, but just done by brute force and thousands of slaves. > > -- Alan Kay > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Code as if whoever maintains your program is a violent psychopath who knows where you live. -- Anonymous -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From magnus at therning.org Mon Apr 21 05:40:36 2014 From: magnus at therning.org (Magnus Therning) Date: Mon, 21 Apr 2014 07:40:36 +0200 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: References: <20140420161125.GA3937@tatooine> Message-ID: <20140421054036.GB6082@tatooine> On Mon, Apr 21, 2014 at 08:18:20AM +1000, Ivan Lazar Miljenovic wrote: > On 21 April 2014 02:11, Magnus Therning wrote: >> I'm working on the packaging of Ghc for Arch Linux and the >> packaging of Ghc 7.8 was in place about a week ago. It was >> delivered with `Cabal` 1.18, and already now there's a 1.20 >> available, which is required by the latest version of >> `cabal-install` :( >> >> Ghc 7.8 comes with quite a few other basic libraries. Are there >> any dependencies between these libraries besides the obvious one on >> `base`? >> >> In other words, can I update Cabal without running into the >> diamond-dependency problem? > > The only time I've had a problem with Exherbo packages is that some > of them (e.g. haskell-docs) require using the version of Cabal > shipped with GHC (I think it was to have consistency with the > version of Cabal that Haddock was built with); as long as the Arch > packages can specify "use GHC's Cabal" for the few cases which it's > necessary then you shouldn't have a problem. That is exactly the kind of situation I want to avoid :) I have no problem re-compiling everything that depends on Cabal, but I want that recompile to result in a situation where neither the user (nor me) need to ever ask "Which of the installed Cabal versions should I use to compile this program?". /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Code as if whoever maintains your program is a violent psychopath who knows where you live. -- Anonymous -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From ivan.miljenovic at gmail.com Mon Apr 21 07:04:21 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 21 Apr 2014 17:04:21 +1000 Subject: [Haskell-cafe] Does this typeclass have a name? In-Reply-To: References: Message-ID: On 21 April 2014 15:09, Bardur Arantsson wrote: > Hi all, > > I was wondering if anyone out there knows if this type class has a name? > > class Foo a e where > foo :: e -> a -> a > bar :: a > > (I also have a fundep a -> e, but that's not essential.) > > Essentially the usage is: > > You have a sequence of "events" e_i and a starting value > "bar" and can use the "foo" function to apply all events > to that starting value > > foo e_n $ foo e_{n-1} $ ... $ foo e_0 $ bar = foldr foo bar [e_n, e_{n-1} .. e_0] ? > > and thus get the final value of the a induced by the > events e_i. > > (I've included the "bar" starting value in the type class, but I suppose > it could be supplied by a Default instance.) > > Regards, > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From ivan.miljenovic at gmail.com Mon Apr 21 07:06:16 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 21 Apr 2014 17:06:16 +1000 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: <20140421054036.GB6082@tatooine> References: <20140420161125.GA3937@tatooine> <20140421054036.GB6082@tatooine> Message-ID: On 21 April 2014 15:40, Magnus Therning wrote: > On Mon, Apr 21, 2014 at 08:18:20AM +1000, Ivan Lazar Miljenovic wrote: >> On 21 April 2014 02:11, Magnus Therning wrote: >>> I'm working on the packaging of Ghc for Arch Linux and the >>> packaging of Ghc 7.8 was in place about a week ago. It was >>> delivered with `Cabal` 1.18, and already now there's a 1.20 >>> available, which is required by the latest version of >>> `cabal-install` :( >>> >>> Ghc 7.8 comes with quite a few other basic libraries. Are there >>> any dependencies between these libraries besides the obvious one on >>> `base`? >>> >>> In other words, can I update Cabal without running into the >>> diamond-dependency problem? >> >> The only time I've had a problem with Exherbo packages is that some >> of them (e.g. haskell-docs) require using the version of Cabal >> shipped with GHC (I think it was to have consistency with the >> version of Cabal that Haddock was built with); as long as the Arch >> packages can specify "use GHC's Cabal" for the few cases which it's >> necessary then you shouldn't have a problem. > > That is exactly the kind of situation I want to avoid :) > > I have no problem re-compiling everything that depends on Cabal, but I > want that recompile to result in a situation where neither the user > (nor me) need to ever ask "Which of the installed Cabal versions > should I use to compile this program?". I think cabal-install can get away with this because it ensures the same version of Cabal is used throughout, as the .cabal file for haskell-docs doesn't explicitly state that it requires the same version of Cabal as used by Haddock. So if Arch's dependency resolver is smart enough, this might work. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From arnaud.oqube at gmail.com Mon Apr 21 07:25:55 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Mon, 21 Apr 2014 09:25:55 +0200 Subject: [Haskell-cafe] Correctly setting up emacs + ghc-mod In-Reply-To: References: <46ACA9D7-6F00-4753-8B61-C51A2E46A182@gmail.com> Message-ID: <838B6D69-9E67-4A47-9341-10E69BE55D56@gmail.com> Yes, but only once on ?.? I suspect from your answer I should do it for all directories ? On 20 Apr 2014, at 16:28, Zsolt Dollenstein wrote: > Have you tried M-x haskell-process-unignore? > > > On Sun, Apr 20, 2014 at 10:20 AM, Arnaud Bailly wrote: > This is what I have in my cabal file: > > library > hs-source-dirs: ., fay-shared > exposed-modules: Application > Foundation > > but I keep getting same error when loading a file that depends on the fay-shared directory (please not that command-line building with cabal runs fine so this is definitely an issue with my emacs settings). > > Here is the output I got in haskell interpreter when loading a file that depends on fay-shared/SharedTypes.hs: > > GHCi is ignoring: /home/vagrant/yesod-splittest/.ghci (run M-x haskell-process-unignore) > The next big Haskell project is about to start! > If I break, you can: > 1. Restart: M-x haskell-process-restart > 2. Configure logging: C-h v haskell-process-log (useful for debugging) > 3. General config: M-x customize-mode > 4. Hide these tips: C-h v haskell-process-show-debug-tips > Changed directory: /home/vagrant/yesod-splittest/ > Import.hs:18:18-28: Could not find module `SharedTypes' ? > Use -v to see a list of the files searched for. > Compilation failed. > Import.hs:18:18-28: Could not find module `SharedTypes' ? > Use -v to see a list of the files searched for. > Compilation failed. > ?> > > Thanks > Arnaud > > > On 19 Apr 2014, at 13:05, Andras Slemmer <0slemi0 at gmail.com> wrote: > >> If you're using several source directories then simply specify them in your .cabal with hs-source-dirs. So for example if you have a library in src/lib and a test-suite in src/test and your tests use your lib then you'd have something like this in your .cabal >> >> library >> exposed-modules: Lib >> hs-source-dirs: src/lib >> >> test-suite sometest >> type: exitcode-stdio-1.0 >> main-is: Test.hs >> hs-source-dirs: src/test src/lib >> >> >> >> On 18 April 2014 16:20, Arnaud Bailly wrote: >> Hello, >> >> I am struggling to get my emacs settings right for doing significant Haskell development, eg. something more involved than a bunch of source files in a single directory. The issue I am running in currently is that when trying to load files in the interpreter, most source paths are missing which means loading inevitably fails. This is especially annoying with tests: To get things working correctly I need to explicitly add in the console >> >> > :set -iwhere/my/src/are >> >> Is there any configuration I should be aware of in my cabal files or .emacs file that would correctly set the source roots? Am I missing something? >> >> Here is my .emacs configuration. Thanks for any help. >> >> ;; haskell coding >> (require 'auto-complete) >> (require 'haskell-mode) >> (require 'haskell-cabal) >> >> (autoload 'ghc-init "ghc" nil t) >> >> (add-hook 'haskell-mode-hook (lambda () (ghc-init))) >> >> (eval-after-load "haskell-mode" >> '(progn >> (setq haskell-stylish-on-save t) >> (setq haskell-process-args-cabal-repl '("--ghc-option=-ferror-spans" >> "--with-ghc=ghci-ng")) >> >> (define-key haskell-mode-map (kbd "C-,") 'haskell-move-nested-left) >> (define-key haskell-mode-map (kbd "C-.") 'haskell-move-nested-right) >> (define-key haskell-mode-map (kbd "C-c v c") 'haskell-cabal-visit-file) >> (define-key haskell-mode-map (kbd "C-c C-c") 'haskell-compile) >> (define-key haskell-mode-map (kbd "C-x C-d") nil) >> (setq haskell-font-lock-symbols t) >> >> ;; Do this to get a variable in scope >> (auto-complete-mode) >> >> ;; from http://pastebin.com/tJyyEBAS >> (ac-define-source ghc-mod >> '((depends ghc) >> (candidates . (ghc-select-completion-symbol)) >> (symbol . "s") >> (cache))) >> >> (defun my-ac-haskell-mode () >> (setq ac-sources '(ac-source-words-in-same-mode-buffers >> ac-source-dictionary >> ac-source-ghc-mod))) >> (add-hook 'haskell-mode-hook 'my-ac-haskell-mode) >> >> >> (defun my-haskell-ac-init () >> (when (member (file-name-extension buffer-file-name) '("hs" "lhs")) >> (auto-complete-mode t) >> (setq ac-sources '(ac-source-words-in-same-mode-buffers >> ac-source-dictionary >> ac-source-ghc-mod)))) >> (add-hook 'find-file-hook 'my-haskell-ac-init))) >> >> (add-hook 'haskell-mode-hook 'turn-on-haskell-decl-scan) >> (add-hook 'haskell-mode-hook 'turn-on-haskell-indentation) >> >> (eval-after-load "which-func" >> '(add-to-list 'which-func-modes 'haskell-mode)) >> >> (eval-after-load "haskell-cabal" >> '(define-key haskell-cabal-mode-map (kbd "C-c C-c") 'haskell-compile)) >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From arnaud.oqube at gmail.com Mon Apr 21 07:30:06 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Mon, 21 Apr 2014 09:30:06 +0200 Subject: [Haskell-cafe] Correctly setting up emacs + ghc-mod In-Reply-To: References: <46ACA9D7-6F00-4753-8B61-C51A2E46A182@gmail.com> Message-ID: <368068B3-0656-400A-809D-93B51683683D@gmail.com> I tried it but to no avail. Still got the same error. I removed ghc-init from my config, just in case, and still have the problem Will post on haskell-mode ML? Arnaud On 20 Apr 2014, at 16:28, Zsolt Dollenstein wrote: > Have you tried M-x haskell-process-unignore? > > > On Sun, Apr 20, 2014 at 10:20 AM, Arnaud Bailly wrote: > This is what I have in my cabal file: > > library > hs-source-dirs: ., fay-shared > exposed-modules: Application > Foundation > > but I keep getting same error when loading a file that depends on the fay-shared directory (please not that command-line building with cabal runs fine so this is definitely an issue with my emacs settings). > > Here is the output I got in haskell interpreter when loading a file that depends on fay-shared/SharedTypes.hs: > > GHCi is ignoring: /home/vagrant/yesod-splittest/.ghci (run M-x haskell-process-unignore) > The next big Haskell project is about to start! > If I break, you can: > 1. Restart: M-x haskell-process-restart > 2. Configure logging: C-h v haskell-process-log (useful for debugging) > 3. General config: M-x customize-mode > 4. Hide these tips: C-h v haskell-process-show-debug-tips > Changed directory: /home/vagrant/yesod-splittest/ > Import.hs:18:18-28: Could not find module `SharedTypes' ? > Use -v to see a list of the files searched for. > Compilation failed. > Import.hs:18:18-28: Could not find module `SharedTypes' ? > Use -v to see a list of the files searched for. > Compilation failed. > ?> > > Thanks > Arnaud > > > On 19 Apr 2014, at 13:05, Andras Slemmer <0slemi0 at gmail.com> wrote: > >> If you're using several source directories then simply specify them in your .cabal with hs-source-dirs. So for example if you have a library in src/lib and a test-suite in src/test and your tests use your lib then you'd have something like this in your .cabal >> >> library >> exposed-modules: Lib >> hs-source-dirs: src/lib >> >> test-suite sometest >> type: exitcode-stdio-1.0 >> main-is: Test.hs >> hs-source-dirs: src/test src/lib >> >> >> >> On 18 April 2014 16:20, Arnaud Bailly wrote: >> Hello, >> >> I am struggling to get my emacs settings right for doing significant Haskell development, eg. something more involved than a bunch of source files in a single directory. The issue I am running in currently is that when trying to load files in the interpreter, most source paths are missing which means loading inevitably fails. This is especially annoying with tests: To get things working correctly I need to explicitly add in the console >> >> > :set -iwhere/my/src/are >> >> Is there any configuration I should be aware of in my cabal files or .emacs file that would correctly set the source roots? Am I missing something? >> >> Here is my .emacs configuration. Thanks for any help. >> >> ;; haskell coding >> (require 'auto-complete) >> (require 'haskell-mode) >> (require 'haskell-cabal) >> >> (autoload 'ghc-init "ghc" nil t) >> >> (add-hook 'haskell-mode-hook (lambda () (ghc-init))) >> >> (eval-after-load "haskell-mode" >> '(progn >> (setq haskell-stylish-on-save t) >> (setq haskell-process-args-cabal-repl '("--ghc-option=-ferror-spans" >> "--with-ghc=ghci-ng")) >> >> (define-key haskell-mode-map (kbd "C-,") 'haskell-move-nested-left) >> (define-key haskell-mode-map (kbd "C-.") 'haskell-move-nested-right) >> (define-key haskell-mode-map (kbd "C-c v c") 'haskell-cabal-visit-file) >> (define-key haskell-mode-map (kbd "C-c C-c") 'haskell-compile) >> (define-key haskell-mode-map (kbd "C-x C-d") nil) >> (setq haskell-font-lock-symbols t) >> >> ;; Do this to get a variable in scope >> (auto-complete-mode) >> >> ;; from http://pastebin.com/tJyyEBAS >> (ac-define-source ghc-mod >> '((depends ghc) >> (candidates . (ghc-select-completion-symbol)) >> (symbol . "s") >> (cache))) >> >> (defun my-ac-haskell-mode () >> (setq ac-sources '(ac-source-words-in-same-mode-buffers >> ac-source-dictionary >> ac-source-ghc-mod))) >> (add-hook 'haskell-mode-hook 'my-ac-haskell-mode) >> >> >> (defun my-haskell-ac-init () >> (when (member (file-name-extension buffer-file-name) '("hs" "lhs")) >> (auto-complete-mode t) >> (setq ac-sources '(ac-source-words-in-same-mode-buffers >> ac-source-dictionary >> ac-source-ghc-mod)))) >> (add-hook 'find-file-hook 'my-haskell-ac-init))) >> >> (add-hook 'haskell-mode-hook 'turn-on-haskell-decl-scan) >> (add-hook 'haskell-mode-hook 'turn-on-haskell-indentation) >> >> (eval-after-load "which-func" >> '(add-to-list 'which-func-modes 'haskell-mode)) >> >> (eval-after-load "haskell-cabal" >> '(define-key haskell-cabal-mode-map (kbd "C-c C-c") 'haskell-compile)) >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Mon Apr 21 08:00:20 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 21 Apr 2014 09:00:20 +0100 Subject: [Haskell-cafe] Does this typeclass have a name? In-Reply-To: References: Message-ID: <20140421080020.GG9884@weber> On Mon, Apr 21, 2014 at 07:09:13AM +0200, Bardur Arantsson wrote: > class Foo a e where > foo :: e -> a -> a > bar :: a [...] > You have a sequence of "events" e_i and a starting value > "bar" and can use the "foo" function to apply all events > to that starting value Do you *really* want a typeclass for this, rather than a value? Tom From spam at scientician.net Mon Apr 21 08:08:30 2014 From: spam at scientician.net (Bardur Arantsson) Date: Mon, 21 Apr 2014 10:08:30 +0200 Subject: [Haskell-cafe] Does this typeclass have a name? In-Reply-To: References: Message-ID: On 2014-04-21 09:04, Ivan Lazar Miljenovic wrote: > On 21 April 2014 15:09, Bardur Arantsson wrote: >> Hi all, >> >> I was wondering if anyone out there knows if this type class has a name? >> >> class Foo a e where >> foo :: e -> a -> a >> bar :: a >> >> (I also have a fundep a -> e, but that's not essential.) >> >> Essentially the usage is: >> >> You have a sequence of "events" e_i and a starting value >> "bar" and can use the "foo" function to apply all events >> to that starting value >> >> foo e_n $ foo e_{n-1} $ ... $ foo e_0 $ bar > > = foldr foo bar [e_n, e_{n-1} .. e_0] ? > Yes, indeed, but I want the type class to constrain things since there are other interacting constraints on the types "a" and "e" (plus there's the fundep that I mentioned). The "single instance" part of type classes is also very desirable. Regards, From nikoamia at gmail.com Mon Apr 21 08:25:32 2014 From: nikoamia at gmail.com (Nikolay Amiantov) Date: Mon, 21 Apr 2014 12:25:32 +0400 Subject: [Haskell-cafe] Building foreign shared libraries with Cabal Message-ID: Hello, I want to use cabal to build and install shared library, which will be called from C. I've already found necessary combination of flags and options to successfully build it, but now I have two main issues: 1) The library is installed into "bin". 2) The generated "stub" C headers are not installed at all. How can I resolve this? My current options is as follows: executable libtest.so hs-source-dirs: src main-is: Test.hs default-language: Haskell2010 default-extensions: ForeignFunctionInterface build-depends: base >= 4.7 c-sources: cbits/library_init.c ghc-options: -no-hs-main -shared -dynamic cc-options: -DMODULE=Test -fPIC Thanks for any help and have a nice day, Nikolay. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Mon Apr 21 08:38:51 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Mon, 21 Apr 2014 10:38:51 +0200 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: <20140421053532.GA6082@tatooine> (Magnus Therning's message of "Mon, 21 Apr 2014 07:35:32 +0200") References: <20140420161125.GA3937@tatooine> <20140421053532.GA6082@tatooine> Message-ID: <8738h7jcv8.fsf@gnu.org> On 2014-04-21 at 07:35:32 +0200, Magnus Therning wrote: > On Sun, Apr 20, 2014 at 06:01:33PM -0400, Carter Schonwald wrote: >> yup. go crazy :) > > What other packages that are shipped with Ghc can I update without > running into the diamond-dependency problem? > > Package | Safe to update > ================================= > Cabal | ? Problems can arise though, if you install packages which start linking against the newer Cabal package, and then you happen to need to link those together with the 'ghc' package (which currently depends on the Cabal lib bundled with the GHC distro), then you got yourself a diamond-dep problem nevertheless If that poses no problem to you, many of the packages listed below (except for the wired-in packages, namely: base, ghc-prim, integer-gmp, and template-haskell), could be regarded similarly "safe to update" (more so in a Cabal sandbox) just look at the output of ghc-pkg dot --global | dotty - and look out for those packages that are only depended upon directly by GHC (minus the aforementioned wired-in packages) > array | > base | > bin-package-db | > binary | > bytestring | > containers | > deepseq | > directory | > filepath | > ghc-prim | > haskell2010 | > haskell98 | > hoopl | > hpc | > integer-gmp | > old-locale | > old-time | > pretty | > process | > rts | > template-haskell | > time | > transformers | > unix | From ivan.miljenovic at gmail.com Mon Apr 21 09:25:41 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 21 Apr 2014 19:25:41 +1000 Subject: [Haskell-cafe] Does this typeclass have a name? In-Reply-To: References: Message-ID: On 21 April 2014 18:08, Bardur Arantsson wrote: > On 2014-04-21 09:04, Ivan Lazar Miljenovic wrote: >> On 21 April 2014 15:09, Bardur Arantsson wrote: >>> Hi all, >>> >>> I was wondering if anyone out there knows if this type class has a name? >>> >>> class Foo a e where >>> foo :: e -> a -> a >>> bar :: a >>> >>> (I also have a fundep a -> e, but that's not essential.) >>> >>> Essentially the usage is: >>> >>> You have a sequence of "events" e_i and a starting value >>> "bar" and can use the "foo" function to apply all events >>> to that starting value >>> >>> foo e_n $ foo e_{n-1} $ ... $ foo e_0 $ bar >> >> = foldr foo bar [e_n, e_{n-1} .. e_0] ? >> > > Yes, indeed, but I want the type class to constrain things since there > are other interacting constraints on the types "a" and "e" (plus there's > the fundep that I mentioned). The "single instance" part of type classes > is also very desirable. Typeclasses only really make sense if you're defining polymorphic functions that deal with a variety of these kinds of types. If that's the case, define your own typeclass (as it doesn't appear generic enough to be found in existing libraries) and define the instances you need. Otherwise, maybe just define an explicit dictionary record with values for every possible type pairing (and use an associated type instance if you want to explicitly state that there's a relation between a and e)? -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From spam at scientician.net Mon Apr 21 09:28:18 2014 From: spam at scientician.net (Bardur Arantsson) Date: Mon, 21 Apr 2014 11:28:18 +0200 Subject: [Haskell-cafe] Does this typeclass have a name? In-Reply-To: References: Message-ID: On 2014-04-21 11:25, Ivan Lazar Miljenovic wrote: > On 21 April 2014 18:08, Bardur Arantsson wrote: >> On 2014-04-21 09:04, Ivan Lazar Miljenovic wrote: >>> On 21 April 2014 15:09, Bardur Arantsson wrote: >>>> Hi all, >>>> >>>> I was wondering if anyone out there knows if this type class has a name? >>>> >>>> class Foo a e where >>>> foo :: e -> a -> a >>>> bar :: a >>>> >>>> (I also have a fundep a -> e, but that's not essential.) >>>> >>>> Essentially the usage is: >>>> >>>> You have a sequence of "events" e_i and a starting value >>>> "bar" and can use the "foo" function to apply all events >>>> to that starting value >>>> >>>> foo e_n $ foo e_{n-1} $ ... $ foo e_0 $ bar >>> >>> = foldr foo bar [e_n, e_{n-1} .. e_0] ? >>> >> >> Yes, indeed, but I want the type class to constrain things since there >> are other interacting constraints on the types "a" and "e" (plus there's >> the fundep that I mentioned). The "single instance" part of type classes >> is also very desirable. > > Typeclasses only really make sense if you're defining polymorphic > functions that deal with a variety of these kinds of types. > > If that's the case, define your own typeclass (as it doesn't appear > generic enough to be found in existing libraries) and define the > instances you need. > Of course, I'm already doing exactly that -- I really was just wondering if there might be a name for the type class :). Regards, From magnus at therning.org Mon Apr 21 09:38:13 2014 From: magnus at therning.org (Magnus Therning) Date: Mon, 21 Apr 2014 11:38:13 +0200 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: <8738h7jcv8.fsf@gnu.org> References: <20140420161125.GA3937@tatooine> <20140421053532.GA6082@tatooine> <8738h7jcv8.fsf@gnu.org> Message-ID: <20140421093813.GA1089@tatooine> On Mon, Apr 21, 2014 at 10:38:51AM +0200, Herbert Valerio Riedel wrote: > On 2014-04-21 at 07:35:32 +0200, Magnus Therning wrote: >> On Sun, Apr 20, 2014 at 06:01:33PM -0400, Carter Schonwald wrote: >>> yup. go crazy :) >> >> What other packages that are shipped with Ghc can I update without >> running into the diamond-dependency problem? >> >> Package | Safe to update >> ================================= >> Cabal | ? > > Problems can arise though, if you install packages which start > linking against the newer Cabal package, and then you happen to need > to link those together with the 'ghc' package (which currently > depends on the Cabal lib bundled with the GHC distro), then you got > yourself a diamond-dep problem nevertheless Yes, that would be exactly the kind of problem that prompted me to ask the question. So, in short, it is not safe to upgrade Cabal. Then I have to say it is rather irritating that there is no way for me to safely provide the latest version of cabal-install! > If that poses no problem to you, many of the packages listed below > (except for the wired-in packages, namely: base, ghc-prim, > integer-gmp, and template-haskell), could be regarded similarly > "safe to update" (more so in a Cabal sandbox) Unfortunately I'm not talking about a Cabal sandbox, but rather of packages in an Arch Linux repository. So the problems caused by my actions affect not only me but every user of the repository. Well, the dependency graph produced by `ghc-pkg dot --global` seems to indicate that upgrading a single one of the packages-that-comes-with-ghc is akin to wandering into a proper mine field. AFAIU I can't upgrade a single package that `ghc` depends on: "ghc-7.8.2" -> "Cabal-1.18.1.3" "ghc-7.8.2" -> "array-0.5.0.0" "ghc-7.8.2" -> "base-4.7.0.0" "ghc-7.8.2" -> "bin-package-db-0.0.0.0" "ghc-7.8.2" -> "bytestring-0.10.4.0" "ghc-7.8.2" -> "containers-0.5.5.1" "ghc-7.8.2" -> "directory-1.2.1.0" "ghc-7.8.2" -> "filepath-1.3.0.2" "ghc-7.8.2" -> "hoopl-3.10.0.1" "ghc-7.8.2" -> "hpc-0.6.0.1" "ghc-7.8.2" -> "process-1.2.0.0" "ghc-7.8.2" -> "template-haskell-2.9.0.0" "ghc-7.8.2" -> "time-1.4.2" "ghc-7.8.2" -> "transformers-0.3.0.0" "ghc-7.8.2" -> "unix-2.7.0.1" On top of that I'd have to re-compile all packages that depend on the package I do upgrade. But then all packages come together as dependencies of `base`, which is hard-wired which I suppose will make it problematic to even recompile the same version. In short that would mean that none of the packages bundled with Ghc are "safe to update". No? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus As long as there are ill-defined goals, bizarre bugs, and unrealistic schedules, there will be Real Programmers willing to jump in and Solve The Problem, saving the documentation for later. Long live Fortran! -- Ed Post -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From tob.brandt at googlemail.com Mon Apr 21 09:46:29 2014 From: tob.brandt at googlemail.com (Tobias Brandt) Date: Mon, 21 Apr 2014 11:46:29 +0200 Subject: [Haskell-cafe] Does this typeclass have a name? In-Reply-To: References: Message-ID: Your class looks like Unfoldable from Data.Collections. foo is insert and bar is empty. The other three methods can be defined in terms of insert and empty. On 21 April 2014 07:09, Bardur Arantsson wrote: > Hi all, > > I was wondering if anyone out there knows if this type class has a name? > > class Foo a e where > foo :: e -> a -> a > bar :: a > > (I also have a fundep a -> e, but that's not essential.) > > Essentially the usage is: > > You have a sequence of "events" e_i and a starting value > "bar" and can use the "foo" function to apply all events > to that starting value > > foo e_n $ foo e_{n-1} $ ... $ foo e_0 $ bar > > and thus get the final value of the a induced by the > events e_i. > > (I've included the "bar" starting value in the type class, but I suppose > it could be supplied by a Default instance.) > > Regards, > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at therning.org Mon Apr 21 09:55:24 2014 From: magnus at therning.org (Magnus Therning) Date: Mon, 21 Apr 2014 11:55:24 +0200 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: <20140421093813.GA1089@tatooine> References: <20140420161125.GA3937@tatooine> <20140421053532.GA6082@tatooine> <8738h7jcv8.fsf@gnu.org> <20140421093813.GA1089@tatooine> Message-ID: <20140421095524.GA2032@tatooine> Haha, oups. This is a rather confused answer. I think I started reading the depency arrows the wrong way about half way through writing it. Just disregard the whole thing. I'll attempt a better reply in a new email instead. /M On Mon, Apr 21, 2014 at 11:38:13AM +0200, Magnus Therning wrote: > On Mon, Apr 21, 2014 at 10:38:51AM +0200, Herbert Valerio Riedel wrote: > > On 2014-04-21 at 07:35:32 +0200, Magnus Therning wrote: > >> On Sun, Apr 20, 2014 at 06:01:33PM -0400, Carter Schonwald wrote: > >>> yup. go crazy :) > >> > >> What other packages that are shipped with Ghc can I update without > >> running into the diamond-dependency problem? > >> > >> Package | Safe to update > >> ================================= > >> Cabal | ? > > > > Problems can arise though, if you install packages which start > > linking against the newer Cabal package, and then you happen to need > > to link those together with the 'ghc' package (which currently > > depends on the Cabal lib bundled with the GHC distro), then you got > > yourself a diamond-dep problem nevertheless > > Yes, that would be exactly the kind of problem that prompted me to ask > the question. So, in short, it is not safe to upgrade Cabal. > > Then I have to say it is rather irritating that there is no way for me > to safely provide the latest version of cabal-install! > > > If that poses no problem to you, many of the packages listed below > > (except for the wired-in packages, namely: base, ghc-prim, > > integer-gmp, and template-haskell), could be regarded similarly > > "safe to update" (more so in a Cabal sandbox) > > Unfortunately I'm not talking about a Cabal sandbox, but rather of > packages in an Arch Linux repository. So the problems caused by my > actions affect not only me but every user of the repository. > > Well, the dependency graph produced by `ghc-pkg dot --global` seems to > indicate that upgrading a single one of the > packages-that-comes-with-ghc is akin to wandering into a proper mine > field. AFAIU I can't upgrade a single package that `ghc` depends on: > > "ghc-7.8.2" -> "Cabal-1.18.1.3" > "ghc-7.8.2" -> "array-0.5.0.0" > "ghc-7.8.2" -> "base-4.7.0.0" > "ghc-7.8.2" -> "bin-package-db-0.0.0.0" > "ghc-7.8.2" -> "bytestring-0.10.4.0" > "ghc-7.8.2" -> "containers-0.5.5.1" > "ghc-7.8.2" -> "directory-1.2.1.0" > "ghc-7.8.2" -> "filepath-1.3.0.2" > "ghc-7.8.2" -> "hoopl-3.10.0.1" > "ghc-7.8.2" -> "hpc-0.6.0.1" > "ghc-7.8.2" -> "process-1.2.0.0" > "ghc-7.8.2" -> "template-haskell-2.9.0.0" > "ghc-7.8.2" -> "time-1.4.2" > "ghc-7.8.2" -> "transformers-0.3.0.0" > "ghc-7.8.2" -> "unix-2.7.0.1" > > On top of that I'd have to re-compile all packages that depend on the > package I do upgrade. But then all packages come together as > dependencies of `base`, which is hard-wired which I suppose will make > it problematic to even recompile the same version. > > In short that would mean that none of the packages bundled with Ghc > are "safe to update". No? > > /M > > -- > Magnus Therning OpenPGP: 0xAB4DFBA4 > email: magnus at therning.org jabber: magnus at therning.org > twitter: magthe http://therning.org/magnus > > As long as there are ill-defined goals, bizarre bugs, and unrealistic > schedules, there will be Real Programmers willing to jump in and Solve The > Problem, saving the documentation for later. Long live Fortran! > -- Ed Post -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus What gets measured, gets done. -- Tom Peters -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From magnus at therning.org Mon Apr 21 10:18:34 2014 From: magnus at therning.org (Magnus Therning) Date: Mon, 21 Apr 2014 12:18:34 +0200 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: <8738h7jcv8.fsf@gnu.org> References: <20140420161125.GA3937@tatooine> <20140421053532.GA6082@tatooine> <8738h7jcv8.fsf@gnu.org> Message-ID: <20140421101834.GB2032@tatooine> On Mon, Apr 21, 2014 at 10:38:51AM +0200, Herbert Valerio Riedel wrote: > On 2014-04-21 at 07:35:32 +0200, Magnus Therning wrote: >> On Sun, Apr 20, 2014 at 06:01:33PM -0400, Carter Schonwald wrote: >>> yup. go crazy :) >> >> What other packages that are shipped with Ghc can I update without >> running into the diamond-dependency problem? >> >> Package | Safe to update >> ================================= >> Cabal | ? > > Problems can arise though, if you install packages which start > linking against the newer Cabal package, and then you happen to need > to link those together with the 'ghc' package (which currently > depends on the Cabal lib bundled with the GHC distro), then you got > yourself a diamond-dep problem nevertheless Yes, that would be the diamond-dependency problem, which I'm trying to avoid! > If that poses no problem to you, many of the packages listed below > (except for the wired-in packages, namely: base, ghc-prim, > integer-gmp, and template-haskell), could be regarded similarly > "safe to update" (more so in a Cabal sandbox) It does, since this isn't only my development environment but the development environment of everyone using the Arch Linux repository I upload packages to. > just look at the output of > > ghc-pkg dot --global | dotty - > > and look out for those packages that are only depended upon directly > by GHC (minus the aforementioned wired-in packages) Well, wouldn't I need to look at the transitive closure of `ghc` dependencies, since e.g. an upgrade of `array` would trigger a recompile of `Cabal` which is a dependency of `ghc` (a wired-in package)? If I'm reading that graph correctly only packages that have no incoming arrows and aren't wired-in are safe to upgrade. That means only `haskell98` and `haskell2010` would be safe to upgrade. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From ivan.miljenovic at gmail.com Mon Apr 21 10:30:26 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 21 Apr 2014 20:30:26 +1000 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: <20140421101834.GB2032@tatooine> References: <20140420161125.GA3937@tatooine> <20140421053532.GA6082@tatooine> <8738h7jcv8.fsf@gnu.org> <20140421101834.GB2032@tatooine> Message-ID: On 21 April 2014 20:18, Magnus Therning wrote: > On Mon, Apr 21, 2014 at 10:38:51AM +0200, Herbert Valerio Riedel wrote: >> On 2014-04-21 at 07:35:32 +0200, Magnus Therning wrote: >>> On Sun, Apr 20, 2014 at 06:01:33PM -0400, Carter Schonwald wrote: >>>> yup. go crazy :) >>> >>> What other packages that are shipped with Ghc can I update without >>> running into the diamond-dependency problem? >>> >>> Package | Safe to update >>> ================================= >>> Cabal | ? >> >> Problems can arise though, if you install packages which start >> linking against the newer Cabal package, and then you happen to need >> to link those together with the 'ghc' package (which currently >> depends on the Cabal lib bundled with the GHC distro), then you got >> yourself a diamond-dep problem nevertheless > > Yes, that would be the diamond-dependency problem, which I'm trying to > avoid! > >> If that poses no problem to you, many of the packages listed below >> (except for the wired-in packages, namely: base, ghc-prim, >> integer-gmp, and template-haskell), could be regarded similarly >> "safe to update" (more so in a Cabal sandbox) > > It does, since this isn't only my development environment but the > development environment of everyone using the Arch Linux repository I > upload packages to. > >> just look at the output of >> >> ghc-pkg dot --global | dotty - >> >> and look out for those packages that are only depended upon directly >> by GHC (minus the aforementioned wired-in packages) > > Well, wouldn't I need to look at the transitive closure of `ghc` > dependencies, since e.g. an upgrade of `array` would trigger a > recompile of `Cabal` which is a dependency of `ghc` (a wired-in > package)? > > If I'm reading that graph correctly only packages that have no > incoming arrows and aren't wired-in are safe to upgrade. That means > only `haskell98` and `haskell2010` would be safe to upgrade. What makes Cabal different is that most packages don't have an actually dependency on Cabal (in terms of their code); they just use Cabal to build themselves. > > /M > > -- > Magnus Therning OpenPGP: 0xAB4DFBA4 > email: magnus at therning.org jabber: magnus at therning.org > twitter: magthe http://therning.org/magnus > > Perl is another example of filling a tiny, short-term need, and then > being a real problem in the longer term. > -- Alan Kay > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From mail at joachim-breitner.de Mon Apr 21 12:10:42 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 21 Apr 2014 14:10:42 +0200 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: <20140421093813.GA1089@tatooine> References: <20140420161125.GA3937@tatooine> <20140421053532.GA6082@tatooine> <8738h7jcv8.fsf@gnu.org> <20140421093813.GA1089@tatooine> Message-ID: <1398082242.2438.24.camel@kirk> Hi, Am Montag, den 21.04.2014, 11:38 +0200 schrieb Magnus Therning: > Then I have to say it is rather irritating that there is no way for me > to safely provide the latest version of cabal-install! the same problem affects Debian, and I find it equally irritating. Not sure how Fedora handles this ? Jens, did you find a problem around this? One possibility would be to manually bundle the Cabal and cabal-install sources into one (dpkg supports source packages with multiple original tarballs), build the new Cabal just to be used to build cabal-install and link that statically (which is the default). This would provide an up-to-date cabal-install binary without having to ship a new Cabal version as a library. Or does cabal-install require the matching version of Cabal to be registered to work? Alternatively it might be possible to build ghc with a newer Cabal. Not sure what that might break. I believe there was talk to avoid having ghc depend on Cabal (it uses very little of it anyways), and indeed, there is https://ghc.haskell.org/trac/ghc/ticket/8244 but work got stalled 7 months ago. Fixing tht would solve the problems for us distributions ? maybe someone wants to pick up the work? Greetings, Joachim PS: https://ghc.haskell.org/trac/ghc/ticket/8947 is a related bug (though about ghc?s dependency on binary, not on Cabal). -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From 0slemi0 at gmail.com Mon Apr 21 13:46:34 2014 From: 0slemi0 at gmail.com (Andras Slemmer) Date: Mon, 21 Apr 2014 15:46:34 +0200 Subject: [Haskell-cafe] Does this typeclass have a name? In-Reply-To: References: Message-ID: I think what you're looking for are monoid actions: http://hackage.haskell.org/package/monoid-extras-0.2.2.0/docs/Data-Monoid-Action.html And the laws the typeclass should satisfy: foo bar = id foo f . foo g = foo (f `mappend` g) The identity law is optional, in whihc case your 'e' would be a semigroup without a default 'bar' On 21 April 2014 11:46, Tobias Brandt wrote: > Your class looks like Unfoldable from Data.Collections. > foo is insert and bar is empty. The other three methods can be defined in > terms of insert and empty. > > > On 21 April 2014 07:09, Bardur Arantsson wrote: > >> Hi all, >> >> I was wondering if anyone out there knows if this type class has a name? >> >> class Foo a e where >> foo :: e -> a -> a >> bar :: a >> >> (I also have a fundep a -> e, but that's not essential.) >> >> Essentially the usage is: >> >> You have a sequence of "events" e_i and a starting value >> "bar" and can use the "foo" function to apply all events >> to that starting value >> >> foo e_n $ foo e_{n-1} $ ... $ foo e_0 $ bar >> >> and thus get the final value of the a induced by the >> events e_i. >> >> (I've included the "bar" starting value in the type class, but I suppose >> it could be supplied by a Default instance.) >> >> Regards, >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 0slemi0 at gmail.com Mon Apr 21 13:49:13 2014 From: 0slemi0 at gmail.com (Andras Slemmer) Date: Mon, 21 Apr 2014 15:49:13 +0200 Subject: [Haskell-cafe] Does this typeclass have a name? In-Reply-To: References: Message-ID: Oh, and bar = mempty On 21 April 2014 15:46, Andras Slemmer <0slemi0 at gmail.com> wrote: > I think what you're looking for are monoid actions: > http://hackage.haskell.org/package/monoid-extras-0.2.2.0/docs/Data-Monoid-Action.html > And the laws the typeclass should satisfy: > foo bar = id > foo f . foo g = foo (f `mappend` g) > > The identity law is optional, in whihc case your 'e' would be a semigroup > without a default 'bar' > > > On 21 April 2014 11:46, Tobias Brandt wrote: > >> Your class looks like Unfoldable from Data.Collections. >> foo is insert and bar is empty. The other three methods can be defined in >> terms of insert and empty. >> >> >> On 21 April 2014 07:09, Bardur Arantsson wrote: >> >>> Hi all, >>> >>> I was wondering if anyone out there knows if this type class has a name? >>> >>> class Foo a e where >>> foo :: e -> a -> a >>> bar :: a >>> >>> (I also have a fundep a -> e, but that's not essential.) >>> >>> Essentially the usage is: >>> >>> You have a sequence of "events" e_i and a starting value >>> "bar" and can use the "foo" function to apply all events >>> to that starting value >>> >>> foo e_n $ foo e_{n-1} $ ... $ foo e_0 $ bar >>> >>> and thus get the final value of the a induced by the >>> events e_i. >>> >>> (I've included the "bar" starting value in the type class, but I suppose >>> it could be supplied by a Default instance.) >>> >>> Regards, >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From capn.freako at gmail.com Mon Apr 21 13:49:46 2014 From: capn.freako at gmail.com (David Banas) Date: Mon, 21 Apr 2014 06:49:46 -0700 Subject: [Haskell-cafe] ANN: v0.0.8 of treeviz package released. Message-ID: <7893B286-B88B-42DE-8BC7-BEE000A81C4E@gmail.com> - Split code into multiple files. - Completed Haddoc documentation. - Changed decimation style flag from Boolean to custom type, DecimationStyle, w/ constructors: DIT & DIF, as per Mark L.?s suggestion. - Introduced type alias: type Radix = Int, for readability. cabal install treeviz http://www.haskell.org/haskellwiki/Treeviz Cheers, -db From capn.freako at gmail.com Mon Apr 21 13:52:51 2014 From: capn.freako at gmail.com (David Banas) Date: Mon, 21 Apr 2014 06:52:51 -0700 Subject: [Haskell-cafe] How to get access to Haddock HTML for newly cabal installed package? Message-ID: <58AA9790-A188-40E4-A040-A7507D97C267@gmail.com> Does anyone know how I get the link to the Haddock generated HTML for a newly cabal installed package to show up in: file:///Users/dbanas/Library/Haskell/doc/index.html ? I?ve got documentation=True set, in ~/.cabal/config. Thanks, -db From fuuzetsu at fuuzetsu.co.uk Mon Apr 21 14:19:25 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 21 Apr 2014 16:19:25 +0200 Subject: [Haskell-cafe] How to get access to Haddock HTML for newly cabal installed package? In-Reply-To: <58AA9790-A188-40E4-A040-A7507D97C267@gmail.com> References: <58AA9790-A188-40E4-A040-A7507D97C267@gmail.com> Message-ID: <535528ED.8010508@fuuzetsu.co.uk> On 04/21/2014 03:52 PM, David Banas wrote: > Does anyone know how I get the link to the Haddock generated HTML for a newly cabal installed package to show up in: > > file:///Users/dbanas/Library/Haskell/doc/index.html > > ? > > I?ve got documentation=True set, in ~/.cabal/config. > > Thanks, > -db > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > I believe it should be automagical. Are you sure you are cabal install'ing to the user directory as opposed to something like a sandbox instead? Upon a second look, I don't know where you're getting that path from. My documentation seems to be listed under ~/.cabal/share/doc/index.html , perhaps that's what you want? -- Mateusz K. From 0slemi0 at gmail.com Mon Apr 21 14:35:49 2014 From: 0slemi0 at gmail.com (Andras Slemmer) Date: Mon, 21 Apr 2014 16:35:49 +0200 Subject: [Haskell-cafe] Correctly setting up emacs + ghc-mod In-Reply-To: <368068B3-0656-400A-809D-93B51683683D@gmail.com> References: <46ACA9D7-6F00-4753-8B61-C51A2E46A182@gmail.com> <368068B3-0656-400A-809D-93B51683683D@gmail.com> Message-ID: Are you trying to use inferior haskell mode? That operates separately from ghc-mod/cabal. In particular i think the setting you're looking for is the command to execute in the inferior process: M-x customize search for "Haskell Program Name" and change "ghci" to sth like "ghci -iwhere/my/src/are" On 21 April 2014 09:30, Arnaud Bailly wrote: > I tried it but to no avail. Still got the same error. I removed ghc-init > from my config, just in case, and still have the problem > > Will post on haskell-mode ML? > > Arnaud > On 20 Apr 2014, at 16:28, Zsolt Dollenstein wrote: > > Have you tried M-x haskell-process-unignore? > > > On Sun, Apr 20, 2014 at 10:20 AM, Arnaud Bailly wrote: > >> This is what I have in my cabal file: >> >> *library* >> *hs-source-dirs*: ., fay-shared >> *exposed-modules*: Application >> Foundation >> >> >> but I keep getting same error when loading a file that depends on the >> fay-shared directory (please not that command-line building with cabal runs >> fine so this is definitely an issue with my emacs settings). >> >> Here is the output I got in haskell interpreter when loading a file that >> depends on fay-shared/SharedTypes.hs: >> >> *GHCi is ignoring: /home/vagrant/yesod-splittest/.ghci (run M-x >> haskell-process-unignore) >> * >> The next big Haskell project is about to start! >> If I break, you can: >> 1. Restart: M-x haskell-process-restart >> 2. Configure logging: C-h v haskell-process-log (useful for debugging) >> 3. General config: M-x customize-mode >> 4. Hide these tips: C-h v haskell-process-show-debug-tips >> Changed directory: /home/vagrant/yesod-splittest/ >> *Import.hs:18:18-28: Could not find module `SharedTypes' ? >> >> * >> * Use -v to see a list of the files searched for. >> >> * >> *Compilation failed. >> >> * >> *Import.hs:18:18-28: Could not find module `SharedTypes' ? >> >> * >> * Use -v to see a list of the files searched for. >> >> * >> *Compilation failed. >> >> * >> *?> * >> >> Thanks >> Arnaud >> >> >> On 19 Apr 2014, at 13:05, Andras Slemmer <0slemi0 at gmail.com> wrote: >> >> If you're using several source directories then simply specify them in >> your .cabal with hs-source-dirs. So for example if you have a library in >> src/lib and a test-suite in src/test and your tests use your lib then you'd >> have something like this in your .cabal >> >> library >> exposed-modules: Lib >> hs-source-dirs: src/lib >> >> test-suite sometest >> type: exitcode-stdio-1.0 >> main-is: Test.hs >> hs-source-dirs: src/test src/lib >> >> >> >> On 18 April 2014 16:20, Arnaud Bailly wrote: >> >>> Hello, >>> >>> I am struggling to get my emacs settings right for doing significant >>> Haskell development, eg. something more involved than a bunch of source >>> files in a single directory. The issue I am running in currently is that >>> when trying to load files in the interpreter, most source paths are missing >>> which means loading inevitably fails. This is especially annoying with >>> tests: To get things working correctly I need to explicitly add in the >>> console >>> >>> > :set -iwhere/my/src/are >>> >>> Is there any configuration I should be aware of in my cabal files or >>> .emacs file that would correctly set the source roots? Am I missing >>> something? >>> >>> Here is my .emacs configuration. Thanks for any help. >>> >>> ;; haskell coding >>> >>> >>> (require 'auto-complete) >>> (require 'haskell-mode) >>> (require 'haskell-cabal) >>> >>> (autoload 'ghc-init "ghc" nil t) >>> >>> (add-hook 'haskell-mode-hook (lambda () (ghc-init))) >>> >>> (eval-after-load "haskell-mode" >>> '(progn >>> (setq haskell-stylish-on-save t) >>> (setq haskell-process-args-cabal-repl '( >>> "--ghc-option=-ferror-spans" >>> "--with-ghc=ghci-ng")) >>> >>> (define-key haskell-mode-map (kbd "C-,") 'haskell-move-nested-left) >>> (define-key haskell-mode-map (kbd "C-.") >>> 'haskell-move-nested-right) >>> (define-key haskell-mode-map (kbd "C-c v c") >>> 'haskell-cabal-visit-file) >>> (define-key haskell-mode-map (kbd "C-c C-c") 'haskell-compile) >>> (define-key haskell-mode-map (kbd "C-x C-d") nil) >>> (setq haskell-font-lock-symbols t) >>> >>> ;; Do this to get a variable in scope >>> >>> >>> (auto-complete-mode) >>> >>> ;; from http://pastebin.com/tJyyEBAS >>> >>> >>> (ac-define-source ghc-mod >>> '((depends ghc) >>> (candidates . (ghc-select-completion-symbol)) >>> (symbol . "s") >>> (cache))) >>> >>> (defun my-ac-haskell-mode () >>> (setq ac-sources '(ac-source-words-in-same-mode-buffers >>> ac-source-dictionary >>> ac-source-ghc-mod))) >>> (add-hook 'haskell-mode-hook 'my-ac-haskell-mode) >>> >>> >>> (defun my-haskell-ac-init () >>> (when (member (file-name-extension buffer-file-name) '("hs" "lhs" >>> )) >>> (auto-complete-mode t) >>> (setq ac-sources '(ac-source-words-in-same-mode-buffers >>> ac-source-dictionary >>> ac-source-ghc-mod)))) >>> (add-hook 'find-file-hook 'my-haskell-ac-init))) >>> >>> (add-hook 'haskell-mode-hook 'turn-on-haskell-decl-scan) >>> (add-hook 'haskell-mode-hook 'turn-on-haskell-indentation) >>> >>> (eval-after-load "which-func" >>> '(add-to-list 'which-func-modes 'haskell-mode)) >>> >>> (eval-after-load "haskell-cabal" >>> '(define-key haskell-cabal-mode-map (kbd "C-c C-c") >>> 'haskell-compile)) >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhelta.diaz at gmail.com Mon Apr 21 17:21:40 2014 From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=) Date: Mon, 21 Apr 2014 19:21:40 +0200 Subject: [Haskell-cafe] How to get access to Haddock HTML for newly cabal installed package? In-Reply-To: <535528ED.8010508@fuuzetsu.co.uk> References: <58AA9790-A188-40E4-A040-A7507D97C267@gmail.com> <535528ED.8010508@fuuzetsu.co.uk> Message-ID: It seems you are running on Windows. From that assumption, try looking in the following path: users/yourusername/AppData/Roaming/cabal/doc/index.html Good luck. On Mon, Apr 21, 2014 at 4:19 PM, Mateusz Kowalczyk wrote: > On 04/21/2014 03:52 PM, David Banas wrote: > > Does anyone know how I get the link to the Haddock generated HTML for a > newly cabal installed package to show up in: > > > > file:///Users/dbanas/Library/Haskell/doc/index.html > > > > ? > > > > I?ve got documentation=True set, in ~/.cabal/config. > > > > Thanks, > > -db > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > I believe it should be automagical. Are you sure you are cabal > install'ing to the user directory as opposed to something like a sandbox > instead? > > Upon a second look, I don't know where you're getting that path from. My > documentation seems to be listed under ~/.cabal/share/doc/index.html , > perhaps that's what you want? > > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Mon Apr 21 17:40:03 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 21 Apr 2014 19:40:03 +0200 Subject: [Haskell-cafe] How to get access to Haddock HTML for newly cabal installed package? In-Reply-To: References: <58AA9790-A188-40E4-A040-A7507D97C267@gmail.com> <535528ED.8010508@fuuzetsu.co.uk> Message-ID: <535557F3.2030909@fuuzetsu.co.uk> On 04/21/2014 07:21 PM, Daniel D?az Casanueva wrote: > It seems you are running on Windows. From that assumption, try looking in > the following path: users/yourusername/AppData/Roaming/cabal/doc/index.html > > Good luck. >From the use of ~ and Users, I think David is using OSX. PS: You gave me quite a good scare, it looks like you're replying to me and I'm certainly *not* using Windows. > > On Mon, Apr 21, 2014 at 4:19 PM, Mateusz Kowalczyk > wrote: > >> On 04/21/2014 03:52 PM, David Banas wrote: >>> Does anyone know how I get the link to the Haddock generated HTML for a >> newly cabal installed package to show up in: >>> >>> file:///Users/dbanas/Library/Haskell/doc/index.html >>> >>> ? >>> >>> I?ve got documentation=True set, in ~/.cabal/config. >>> >>> Thanks, >>> -db >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> I believe it should be automagical. Are you sure you are cabal >> install'ing to the user directory as opposed to something like a sandbox >> instead? >> >> Upon a second look, I don't know where you're getting that path from. My >> documentation seems to be listed under ~/.cabal/share/doc/index.html , >> perhaps that's what you want? >> >> -- >> Mateusz K. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > -- Mateusz K. From spam at scientician.net Mon Apr 21 18:23:24 2014 From: spam at scientician.net (Bardur Arantsson) Date: Mon, 21 Apr 2014 20:23:24 +0200 Subject: [Haskell-cafe] Does this typeclass have a name? In-Reply-To: References: Message-ID: On 2014-04-21 15:46, Andras Slemmer wrote: > I think what you're looking for are monoid actions: > http://hackage.haskell.org/package/monoid-extras-0.2.2.0/docs/Data-Monoid-Action.html > And the laws the typeclass should satisfy: > foo bar = id > foo f . foo g = foo (f `mappend` g) > > The identity law is optional, in whihc case your 'e' would be a semigroup > without a default 'bar' > > Ah, yes, thanks. That looks about right, but unfortunately I have even less structure in that I don't have a monoid -- I had previously looked at group actions, but those have various extra laws. Maybe I should just call it "Action", but avoid the monoid bits. Thanks all, From benjamin.foppa at gmail.com Mon Apr 21 19:07:07 2014 From: benjamin.foppa at gmail.com (Ben Foppa) Date: Mon, 21 Apr 2014 15:07:07 -0400 Subject: [Haskell-cafe] conduit zips In-Reply-To: References: Message-ID: Don't know how I missed those. Thanks! On Mon, Apr 21, 2014 at 3:04 PM, Michael Snoyman wrote: > Instead of functions, they're now newtype wrappers: ZipSource, ZipSink, > and ZipConduit (that last one never existed as a function). Some > information on each of these: > > * http://www.yesodweb.com/blog/2013/09/zipsinks-conduit-extra > * http://www.yesodweb.com/blog/2014/02/conduit-zip-source > * > http://stackoverflow.com/questions/21671688/single-stepping-a-conduit/21684239#21684239 > > > On Mon, Apr 21, 2014 at 3:52 AM, Ben Foppa wrote: > >> Since conduit-1.1.*, the package hasn't contained conduit zipping >> functions anymore. They don't appear to have been moved to conduit-extra, >> either. Did they get lost in the ether, or are they in a separate package? >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjoerd at w3future.com Mon Apr 21 22:09:23 2014 From: sjoerd at w3future.com (Sjoerd Visscher) Date: Tue, 22 Apr 2014 00:09:23 +0200 Subject: [Haskell-cafe] Does this typeclass have a name? In-Reply-To: References: Message-ID: <0C91A69B-1CDB-4CA9-A8EF-B660D675C6AE@w3future.com> Just for completeness another option: http://hackage.haskell.org/package/reducers-3.10.2/docs/Data-Semigroup-Reducer.html But this probably has the same problem, as it requires a Semigroup. Sjoerd On 21 Apr 2014, at 20:23, Bardur Arantsson wrote: > On 2014-04-21 15:46, Andras Slemmer wrote: >> I think what you're looking for are monoid actions: >> http://hackage.haskell.org/package/monoid-extras-0.2.2.0/docs/Data-Monoid-Action.html >> And the laws the typeclass should satisfy: >> foo bar = id >> foo f . foo g = foo (f `mappend` g) >> >> The identity law is optional, in whihc case your 'e' would be a semigroup >> without a default 'bar' >> >> > > Ah, yes, thanks. That looks about right, but unfortunately I have even > less structure in that I don't have a monoid -- I had previously looked > at group actions, but those have various extra laws. > > Maybe I should just call it "Action", but avoid the monoid bits. > > Thanks all, > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ydewit at gmail.com Mon Apr 21 22:39:30 2014 From: ydewit at gmail.com (Yuri de Wit) Date: Mon, 21 Apr 2014 23:39:30 +0100 Subject: [Haskell-cafe] "add ifM and whenM to Control.Monad" and other discussions like that Message-ID: I haven't been around for long in the Haskell community, but I have seen a few of these discussions taking long email rounds in different mailing lists. I don't have a strong opinion at this point to add my vote here or there one way or the other, and I do appreciate the effort made by everyone to find a sort of consensus, as hard as that can be sometimes. However, the question I keep asking myself is why can't the compiler disambiguate between two definitions with the same name based on the actual argument types? This would allow packages to choose their own names for functions without such global-naming discussions and without much pain when using them. e.g.: > import PackageA (when) > import PackageB (when) > when (Just True) doSomething versus: > when True 1 Is there a theoretical or practical issue that makes this an undesirable feature in Haskell? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.solla at gmail.com Tue Apr 22 00:22:28 2014 From: alex.solla at gmail.com (Alexander Solla) Date: Mon, 21 Apr 2014 17:22:28 -0700 Subject: [Haskell-cafe] "add ifM and whenM to Control.Monad" and other discussions like that In-Reply-To: References: Message-ID: On Mon, Apr 21, 2014 at 3:39 PM, Yuri de Wit wrote: > I haven't been around for long in the Haskell community, but I have seen a > few of these discussions taking long email rounds in different mailing > lists. > > I don't have a strong opinion at this point to add my vote here or there > one way or the other, and I do appreciate the effort made by everyone to > find a sort of consensus, as hard as that can be sometimes. > > However, the question I keep asking myself is why can't the compiler > disambiguate between two definitions with the same name based on the actual > argument types? > > This would allow packages to choose their own names for functions without > such global-naming discussions and without much pain when using them. > > e.g.: > > > import PackageA (when) > > import PackageB (when) > > > when (Just True) doSomething > > versus: > > > when True 1 > > Is there a theoretical or practical issue that makes this an undesirable > feature in Haskell? > It has been discussed. https://ghc.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61723 There is no clear consensus, but it is on the docket for consideration for a future version of the Haskell standard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhp at community.haskell.org Tue Apr 22 02:37:44 2014 From: juhp at community.haskell.org (Jens Petersen) Date: Tue, 22 Apr 2014 11:37:44 +0900 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: <1398082242.2438.24.camel@kirk> References: <20140420161125.GA3937@tatooine> <20140421053532.GA6082@tatooine> <8738h7jcv8.fsf@gnu.org> <20140421093813.GA1089@tatooine> <1398082242.2438.24.camel@kirk> Message-ID: On 21 April 2014 21:10, Joachim Breitner wrote: > Am Montag, den 21.04.2014, 11:38 +0200 schrieb Magnus Therning: > > Then I have to say it is rather irritating that there is no way for me > > to safely provide the latest version of cabal-install! > > the same problem affects Debian, and I find it equally irritating. Not > sure how Fedora handles this ? Jens, did you find a problem around this? > I haven't really. I think I will just ship cabal-install-1.18 in Fedora 21 with ghc-7.8. > One possibility would be to manually bundle the Cabal and cabal-install > sources into one (dpkg supports source packages with multiple original > tarballs), build the new Cabal just to be used to build cabal-install > and link that statically (which is the default). This would provide an > up-to-date cabal-install binary without having to ship a new Cabal > version as a library. Right, this is what I do in my Copr repo (Fedora equivalent of OBS/PPA). > Or does cabal-install require the matching version of Cabal to be registered to work? I don't think so, but I believe some of the latest functionality needs Cabal >= 1.18 to work. Alternatively it might be possible to build ghc with a newer Cabal. Not > sure what that might break. > Right that should work I guess. (Personally I still wish for bundling cabal-install with ghc though that doesn't help with this of course, except then you could replace with a newer cabal-install too.;) Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.oqube at gmail.com Tue Apr 22 09:10:53 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Tue, 22 Apr 2014 11:10:53 +0200 Subject: [Haskell-cafe] Correctly setting up emacs + ghc-mod In-Reply-To: References: <46ACA9D7-6F00-4753-8B61-C51A2E46A182@gmail.com> <368068B3-0656-400A-809D-93B51683683D@gmail.com> Message-ID: Yes, I am running haskell interpreter from inferior-haskell-mode. I though haskell mode had the logic to extract the source info from cabal file. On 21 Apr 2014, at 16:35, Andras Slemmer <0slemi0 at gmail.com> wrote: > Are you trying to use inferior haskell mode? That operates separately from ghc-mod/cabal. In particular i think the setting you're looking for is the command to execute in the inferior process: > M-x customize > search for "Haskell Program Name" and change "ghci" to sth like "ghci -iwhere/my/src/are" > > > On 21 April 2014 09:30, Arnaud Bailly wrote: > I tried it but to no avail. Still got the same error. I removed ghc-init from my config, just in case, and still have the problem > > Will post on haskell-mode ML? > > Arnaud > On 20 Apr 2014, at 16:28, Zsolt Dollenstein wrote: > >> Have you tried M-x haskell-process-unignore? >> >> >> On Sun, Apr 20, 2014 at 10:20 AM, Arnaud Bailly wrote: >> This is what I have in my cabal file: >> >> library >> hs-source-dirs: ., fay-shared >> exposed-modules: Application >> Foundation >> >> but I keep getting same error when loading a file that depends on the fay-shared directory (please not that command-line building with cabal runs fine so this is definitely an issue with my emacs settings). >> >> Here is the output I got in haskell interpreter when loading a file that depends on fay-shared/SharedTypes.hs: >> >> GHCi is ignoring: /home/vagrant/yesod-splittest/.ghci (run M-x haskell-process-unignore) >> The next big Haskell project is about to start! >> If I break, you can: >> 1. Restart: M-x haskell-process-restart >> 2. Configure logging: C-h v haskell-process-log (useful for debugging) >> 3. General config: M-x customize-mode >> 4. Hide these tips: C-h v haskell-process-show-debug-tips >> Changed directory: /home/vagrant/yesod-splittest/ >> Import.hs:18:18-28: Could not find module `SharedTypes' ? >> Use -v to see a list of the files searched for. >> Compilation failed. >> Import.hs:18:18-28: Could not find module `SharedTypes' ? >> Use -v to see a list of the files searched for. >> Compilation failed. >> ?> >> >> Thanks >> Arnaud >> >> >> On 19 Apr 2014, at 13:05, Andras Slemmer <0slemi0 at gmail.com> wrote: >> >>> If you're using several source directories then simply specify them in your .cabal with hs-source-dirs. So for example if you have a library in src/lib and a test-suite in src/test and your tests use your lib then you'd have something like this in your .cabal >>> >>> library >>> exposed-modules: Lib >>> hs-source-dirs: src/lib >>> >>> test-suite sometest >>> type: exitcode-stdio-1.0 >>> main-is: Test.hs >>> hs-source-dirs: src/test src/lib >>> >>> >>> >>> On 18 April 2014 16:20, Arnaud Bailly wrote: >>> Hello, >>> >>> I am struggling to get my emacs settings right for doing significant Haskell development, eg. something more involved than a bunch of source files in a single directory. The issue I am running in currently is that when trying to load files in the interpreter, most source paths are missing which means loading inevitably fails. This is especially annoying with tests: To get things working correctly I need to explicitly add in the console >>> >>> > :set -iwhere/my/src/are >>> >>> Is there any configuration I should be aware of in my cabal files or .emacs file that would correctly set the source roots? Am I missing something? >>> >>> Here is my .emacs configuration. Thanks for any help. >>> >>> ;; haskell coding >>> (require 'auto-complete) >>> (require 'haskell-mode) >>> (require 'haskell-cabal) >>> >>> (autoload 'ghc-init "ghc" nil t) >>> >>> (add-hook 'haskell-mode-hook (lambda () (ghc-init))) >>> >>> (eval-after-load "haskell-mode" >>> '(progn >>> (setq haskell-stylish-on-save t) >>> (setq haskell-process-args-cabal-repl '("--ghc-option=-ferror-spans" >>> "--with-ghc=ghci-ng")) >>> >>> (define-key haskell-mode-map (kbd "C-,") 'haskell-move-nested-left) >>> (define-key haskell-mode-map (kbd "C-.") 'haskell-move-nested-right) >>> (define-key haskell-mode-map (kbd "C-c v c") 'haskell-cabal-visit-file) >>> (define-key haskell-mode-map (kbd "C-c C-c") 'haskell-compile) >>> (define-key haskell-mode-map (kbd "C-x C-d") nil) >>> (setq haskell-font-lock-symbols t) >>> >>> ;; Do this to get a variable in scope >>> (auto-complete-mode) >>> >>> ;; from http://pastebin.com/tJyyEBAS >>> (ac-define-source ghc-mod >>> '((depends ghc) >>> (candidates . (ghc-select-completion-symbol)) >>> (symbol . "s") >>> (cache))) >>> >>> (defun my-ac-haskell-mode () >>> (setq ac-sources '(ac-source-words-in-same-mode-buffers >>> ac-source-dictionary >>> ac-source-ghc-mod))) >>> (add-hook 'haskell-mode-hook 'my-ac-haskell-mode) >>> >>> >>> (defun my-haskell-ac-init () >>> (when (member (file-name-extension buffer-file-name) '("hs" "lhs")) >>> (auto-complete-mode t) >>> (setq ac-sources '(ac-source-words-in-same-mode-buffers >>> ac-source-dictionary >>> ac-source-ghc-mod)))) >>> (add-hook 'find-file-hook 'my-haskell-ac-init))) >>> >>> (add-hook 'haskell-mode-hook 'turn-on-haskell-decl-scan) >>> (add-hook 'haskell-mode-hook 'turn-on-haskell-indentation) >>> >>> (eval-after-load "which-func" >>> '(add-to-list 'which-func-modes 'haskell-mode)) >>> >>> (eval-after-load "haskell-cabal" >>> '(define-key haskell-cabal-mode-map (kbd "C-c C-c") 'haskell-compile)) >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From corentin.dupont at gmail.com Tue Apr 22 09:24:26 2014 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Tue, 22 Apr 2014 11:24:26 +0200 Subject: [Haskell-cafe] Job offer at Create-Net, Italy Message-ID: Hi guys, I'm surprised I didn't got any reply from the community to this job offer, that I posted some time ago: http://www.create-net.org/work-with-us/postdoctoral-researcher-cloud-computing While it's not 100% guarantee to work in Haskell, the position is still very interesting with technologies such as Constraint Programming (I'm currently exploring SMT with the SBV library), Cloud computing and energy efficiency. Ciao, Corentin -------------- next part -------------- An HTML attachment was scrubbed... URL: From evohunz at gmail.com Tue Apr 22 17:59:44 2014 From: evohunz at gmail.com (Thiago Negri) Date: Tue, 22 Apr 2014 14:59:44 -0300 Subject: [Haskell-cafe] Imports at bottom, why not? Message-ID: When reading code, I find it quite distracting to have to get past the import list to reach the actual module code, as the import list can be (and often is) quite big. So, why not issue import statements at the bottom of a module file? Likewise, we can use "where" statements to define names used in a function after using them, so they don't distract the reader. I'm against imports at the middle of the file. But I guess being able to issue them at the end of the module could make sense if you want to get the reader straight to the code. A language pragma could be used to select between top imports or bottom imports (can't use both). What do you think? Example: """ {-# LANGUAGE LateImports #-} module Foo where bar :: String bar = "quux" baz :: Fiz baz = mkFiz import Fiz (Fiz, mkFiz) """ -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.foppa at gmail.com Tue Apr 22 18:04:56 2014 From: benjamin.foppa at gmail.com (Ben Foppa) Date: Tue, 22 Apr 2014 14:04:56 -0400 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: References: Message-ID: Why not have an editor that collapses them? On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri wrote: > When reading code, I find it quite distracting to have to get past the > import list to reach the actual module code, as the import list can be (and > often is) quite big. > > So, why not issue import statements at the bottom of a module file? > > Likewise, we can use "where" statements to define names used in a function > after using them, so they don't distract the reader. > > I'm against imports at the middle of the file. > But I guess being able to issue them at the end of the module could make > sense if you want to get the reader straight to the code. > > A language pragma could be used to select between top imports or bottom > imports (can't use both). > > What do you think? > > Example: > > """ > {-# LANGUAGE LateImports #-} > module Foo where > > bar :: String > bar = "quux" > > baz :: Fiz > baz = mkFiz > > import Fiz (Fiz, mkFiz) > """ > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evohunz at gmail.com Tue Apr 22 18:18:44 2014 From: evohunz at gmail.com (Thiago Negri) Date: Tue, 22 Apr 2014 15:18:44 -0300 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: References: Message-ID: The desired editor features are written in the haskell spec? I'm talking about the language in an editor/IDE agnostic way. If the IDE/editor is hiding it for you, it is because the language failed to be good enough to be "out of the way". So, I guess this is a +1. 2014-04-22 15:04 GMT-03:00 Ben Foppa : > Why not have an editor that collapses them? > > > On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri wrote: > >> When reading code, I find it quite distracting to have to get past the >> import list to reach the actual module code, as the import list can be (and >> often is) quite big. >> >> So, why not issue import statements at the bottom of a module file? >> >> Likewise, we can use "where" statements to define names used in a >> function after using them, so they don't distract the reader. >> >> I'm against imports at the middle of the file. >> But I guess being able to issue them at the end of the module could make >> sense if you want to get the reader straight to the code. >> >> A language pragma could be used to select between top imports or bottom >> imports (can't use both). >> >> What do you think? >> >> Example: >> >> """ >> {-# LANGUAGE LateImports #-} >> module Foo where >> >> bar :: String >> bar = "quux" >> >> baz :: Fiz >> baz = mkFiz >> >> import Fiz (Fiz, mkFiz) >> """ >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at nand.wakku.to Tue Apr 22 18:28:00 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Tue, 22 Apr 2014 20:28:00 +0200 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: References: Message-ID: <20140422202800.GA32556@nanodesu.talocan.mine.nu> On Tue, 22 Apr 2014 14:59:44 -0300, Thiago Negri wrote: > When reading code, I find it quite distracting to have to get past the > import list to reach the actual module code, as the import list can be (and > often is) quite big. > > So, why not issue import statements at the bottom of a module file? > > Likewise, we can use "where" statements to define names used in a function > after using them, so they don't distract the reader. > > I'm against imports at the middle of the file. > But I guess being able to issue them at the end of the module could make > sense if you want to get the reader straight to the code. > > A language pragma could be used to select between top imports or bottom > imports (can't use both). > > What do you think? > > Example: > > """ > {-# LANGUAGE LateImports #-} > module Foo where > > bar :: String > bar = "quux" > > baz :: Fiz > baz = mkFiz > > import Fiz (Fiz, mkFiz) > """ A practical reason is that this lets you process modules dependency graphs without ever analyzing the structure past the import list. From magnus at therning.org Tue Apr 22 18:31:22 2014 From: magnus at therning.org (Magnus Therning) Date: Tue, 22 Apr 2014 20:31:22 +0200 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: References: Message-ID: <20140422183122.GA3139@tatooine.lan> On Tue, Apr 22, 2014 at 03:18:44PM -0300, Thiago Negri wrote: > The desired editor features are written in the haskell spec? > I'm talking about the language in an editor/IDE agnostic way. > If the IDE/editor is hiding it for you, it is because the language failed > to be good enough to be "out of the way". > So, I guess this is a +1. Yay for top posting! Well, collapsing (or folding) is a language agnostic way of hiding away anything you like. Do consider that what you want to hide changes with the task at hand. /M > 2014-04-22 15:04 GMT-03:00 Ben Foppa : > > > Why not have an editor that collapses them? > > > > > > On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri wrote: > > > >> When reading code, I find it quite distracting to have to get past the > >> import list to reach the actual module code, as the import list can be (and > >> often is) quite big. > >> > >> So, why not issue import statements at the bottom of a module file? > >> > >> Likewise, we can use "where" statements to define names used in a > >> function after using them, so they don't distract the reader. > >> > >> I'm against imports at the middle of the file. > >> But I guess being able to issue them at the end of the module could make > >> sense if you want to get the reader straight to the code. > >> > >> A language pragma could be used to select between top imports or bottom > >> imports (can't use both). > >> > >> What do you think? > >> > >> Example: > >> > >> """ > >> {-# LANGUAGE LateImports #-} > >> module Foo where > >> > >> bar :: String > >> bar = "quux" > >> > >> baz :: Fiz > >> baz = mkFiz > >> > >> import Fiz (Fiz, mkFiz) > >> """ > >> > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus The results point out the fragility of programmer expertise: advanced programmers have strong expectations about what programs should look like, and when those expectations are violated--in seemingly innocuous ways--their performance drops drastically. -- Elliot Soloway and Kate Ehrlich -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dominique.devriese at cs.kuleuven.be Tue Apr 22 18:37:26 2014 From: dominique.devriese at cs.kuleuven.be (Dominique Devriese) Date: Tue, 22 Apr 2014 20:37:26 +0200 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: References: Message-ID: FWIW, a while ago I talked to one of the guys working on the official Eclipse Scala plugin. He said that Scala's policy of allowing imports pretty much everywhere made it quite hard to build an IDE that's responsive on large codebases. It's not quite the same, because Scala allows much more than just imports at the bottom, but still... Regards Dominique 2014-04-22 19:59 GMT+02:00 Thiago Negri : > When reading code, I find it quite distracting to have to get past the > import list to reach the actual module code, as the import list can be (and > often is) quite big. > > So, why not issue import statements at the bottom of a module file? > > Likewise, we can use "where" statements to define names used in a function > after using them, so they don't distract the reader. > > I'm against imports at the middle of the file. > But I guess being able to issue them at the end of the module could make > sense if you want to get the reader straight to the code. > > A language pragma could be used to select between top imports or bottom > imports (can't use both). > > What do you think? > > Example: > > """ > {-# LANGUAGE LateImports #-} > module Foo where > > bar :: String > bar = "quux" > > baz :: Fiz > baz = mkFiz > > import Fiz (Fiz, mkFiz) > """ > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From mwm at mired.org Tue Apr 22 18:48:58 2014 From: mwm at mired.org (Mike Meyer) Date: Tue, 22 Apr 2014 13:48:58 -0500 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: References: Message-ID: In that case, there is no language that is "good enough", because liking code folding is language agnostic. Personally, I like imports at the top, as they let me know what functions I can expect to find in the module. At least, if used properly. Which shows the real problem with this suggestion: some modules will have imports at the top and some at the bottom, so if you're looking at the middle of the module and want to check on them, you've got to guess where they are. Frankly, if the goal is to get them out of the way, I'd rather see "local imports" in a where or in clause, so you can add them to the expression that needs them. But that has little enough utility that I'd rather not do it, either. Hmm, maybe only in the "import Module (thing ...)" form? Nah. On Tue, Apr 22, 2014 at 1:18 PM, Thiago Negri wrote: > The desired editor features are written in the haskell spec? > I'm talking about the language in an editor/IDE agnostic way. > If the IDE/editor is hiding it for you, it is because the language failed > to be good enough to be "out of the way". > So, I guess this is a +1. > > > > > 2014-04-22 15:04 GMT-03:00 Ben Foppa : > >> Why not have an editor that collapses them? >> >> >> On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri wrote: >> >>> When reading code, I find it quite distracting to have to get past the >>> import list to reach the actual module code, as the import list can be (and >>> often is) quite big. >>> >>> So, why not issue import statements at the bottom of a module file? >>> >>> Likewise, we can use "where" statements to define names used in a >>> function after using them, so they don't distract the reader. >>> >>> I'm against imports at the middle of the file. >>> But I guess being able to issue them at the end of the module could make >>> sense if you want to get the reader straight to the code. >>> >>> A language pragma could be used to select between top imports or bottom >>> imports (can't use both). >>> >>> What do you think? >>> >>> Example: >>> >>> """ >>> {-# LANGUAGE LateImports #-} >>> module Foo where >>> >>> bar :: String >>> bar = "quux" >>> >>> baz :: Fiz >>> baz = mkFiz >>> >>> import Fiz (Fiz, mkFiz) >>> """ >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evohunz at gmail.com Tue Apr 22 19:07:24 2014 From: evohunz at gmail.com (Thiago Negri) Date: Tue, 22 Apr 2014 16:07:24 -0300 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: References: Message-ID: Just to get things clear... I'm not saying that folding is a bad thing. But it is not a valid reason to invalidate a "import at bottom" feature. It's like saying that if you shouldn't care if you have a broken leg, just grab a crutch and you are good to go: "don't bother going to a physiotherapist." The code analysis situations are valid reasons, but I still prefer the language to be easier to man than to machine. Adding them at the bottom would incur an absurd overhead? You don't need to scan the file looking for imports, you can scan bottom-up the same way you would scan top-down. Or would you need a "do-nothing-scan" to find the end of file? (Sorry, I lack knowledge in file system implementations.) I browse a lot of code on github, and I don't find a way to fold import statements on the website. 2014-04-22 15:48 GMT-03:00 Mike Meyer : > In that case, there is no language that is "good enough", because liking > code folding is language agnostic. > > Personally, I like imports at the top, as they let me know what functions > I can expect to find in the module. At least, if used properly. Which shows > the real problem with this suggestion: some modules will have imports at > the top and some at the bottom, so if you're looking at the middle of the > module and want to check on them, you've got to guess where they are. > > Frankly, if the goal is to get them out of the way, I'd rather see "local > imports" in a where or in clause, so you can add them to the expression > that needs them. But that has little enough utility that I'd rather not do > it, either. Hmm, maybe only in the "import Module (thing ...)" form? Nah. > > > On Tue, Apr 22, 2014 at 1:18 PM, Thiago Negri wrote: > >> The desired editor features are written in the haskell spec? >> I'm talking about the language in an editor/IDE agnostic way. >> If the IDE/editor is hiding it for you, it is because the language failed >> to be good enough to be "out of the way". >> So, I guess this is a +1. >> >> >> >> >> 2014-04-22 15:04 GMT-03:00 Ben Foppa : >> >>> Why not have an editor that collapses them? >>> >>> >>> On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri wrote: >>> >>>> When reading code, I find it quite distracting to have to get past the >>>> import list to reach the actual module code, as the import list can be (and >>>> often is) quite big. >>>> >>>> So, why not issue import statements at the bottom of a module file? >>>> >>>> Likewise, we can use "where" statements to define names used in a >>>> function after using them, so they don't distract the reader. >>>> >>>> I'm against imports at the middle of the file. >>>> But I guess being able to issue them at the end of the module could >>>> make sense if you want to get the reader straight to the code. >>>> >>>> A language pragma could be used to select between top imports or bottom >>>> imports (can't use both). >>>> >>>> What do you think? >>>> >>>> Example: >>>> >>>> """ >>>> {-# LANGUAGE LateImports #-} >>>> module Foo where >>>> >>>> bar :: String >>>> bar = "quux" >>>> >>>> baz :: Fiz >>>> baz = mkFiz >>>> >>>> import Fiz (Fiz, mkFiz) >>>> """ >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgaebel at uwaterloo.ca Tue Apr 22 19:12:49 2014 From: cgaebel at uwaterloo.ca (Clark Gaebel) Date: Tue, 22 Apr 2014 15:12:49 -0400 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: References: Message-ID: How did this work out in other languages which have imports at the bottom? - Clark On Tue, Apr 22, 2014 at 3:07 PM, Thiago Negri wrote: > Just to get things clear... > I'm not saying that folding is a bad thing. > But it is not a valid reason to invalidate a "import at bottom" feature. > > It's like saying that if you shouldn't care if you have a broken leg, just > grab a crutch and you are good to go: "don't bother going to a > physiotherapist." > > The code analysis situations are valid reasons, but I still prefer the > language to be easier to man than to machine. Adding them at the bottom > would incur an absurd overhead? You don't need to scan the file looking for > imports, you can scan bottom-up the same way you would scan top-down. Or > would you need a "do-nothing-scan" to find the end of file? (Sorry, I lack > knowledge in file system implementations.) > > I browse a lot of code on github, and I don't find a way to fold import > statements on the website. > > > > 2014-04-22 15:48 GMT-03:00 Mike Meyer : > > In that case, there is no language that is "good enough", because liking >> code folding is language agnostic. >> >> Personally, I like imports at the top, as they let me know what functions >> I can expect to find in the module. At least, if used properly. Which shows >> the real problem with this suggestion: some modules will have imports at >> the top and some at the bottom, so if you're looking at the middle of the >> module and want to check on them, you've got to guess where they are. >> >> Frankly, if the goal is to get them out of the way, I'd rather see "local >> imports" in a where or in clause, so you can add them to the expression >> that needs them. But that has little enough utility that I'd rather not do >> it, either. Hmm, maybe only in the "import Module (thing ...)" form? Nah. >> >> >> On Tue, Apr 22, 2014 at 1:18 PM, Thiago Negri wrote: >> >>> The desired editor features are written in the haskell spec? >>> I'm talking about the language in an editor/IDE agnostic way. >>> If the IDE/editor is hiding it for you, it is because the language >>> failed to be good enough to be "out of the way". >>> So, I guess this is a +1. >>> >>> >>> >>> >>> 2014-04-22 15:04 GMT-03:00 Ben Foppa : >>> >>>> Why not have an editor that collapses them? >>>> >>>> >>>> On Tue, Apr 22, 2014 at 1:59 PM, Thiago Negri wrote: >>>> >>>>> When reading code, I find it quite distracting to have to get past the >>>>> import list to reach the actual module code, as the import list can be (and >>>>> often is) quite big. >>>>> >>>>> So, why not issue import statements at the bottom of a module file? >>>>> >>>>> Likewise, we can use "where" statements to define names used in a >>>>> function after using them, so they don't distract the reader. >>>>> >>>>> I'm against imports at the middle of the file. >>>>> But I guess being able to issue them at the end of the module could >>>>> make sense if you want to get the reader straight to the code. >>>>> >>>>> A language pragma could be used to select between top imports or >>>>> bottom imports (can't use both). >>>>> >>>>> What do you think? >>>>> >>>>> Example: >>>>> >>>>> """ >>>>> {-# LANGUAGE LateImports #-} >>>>> module Foo where >>>>> >>>>> bar :: String >>>>> bar = "quux" >>>>> >>>>> baz :: Fiz >>>>> baz = mkFiz >>>>> >>>>> import Fiz (Fiz, mkFiz) >>>>> """ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at skybluetrades.net Tue Apr 22 21:26:45 2014 From: ian at skybluetrades.net (Ian Ross) Date: Tue, 22 Apr 2014 23:26:45 +0200 Subject: [Haskell-cafe] Contract opportunity Message-ID: Dear all, This is kind of weird, but it might be of interest to someone and I think it's within the remit of this list, so here goes. Sorry to everyone who's not interested! I'm looking for someone to take over a contract I've been working on -- I've been offered something better and I won't have the time to carry on with this thing. I can't say too much about the details, but it's mostly GIS and geoprocessing work for a smallish business consulting firm, probably expanding to some statistical modelling soon. I've been using PostGIS with postgresql-simple to do some quite complicated geoprocessing of OpenStreetMap data for them: much of the Haskell content is really only using Haskell as a fancy scripting language to run lots of SQL, but there are a couple of more interesting bits. Anyone who was going to take this over would need to be a reasonably proficient Haskeller, know SQL well (including having some idea about query optimisation), have some familiarity with GIS work (data formats, something like QGIS or ArcGIS, ideally PostGIS and/or spatial SQL) and be persistent enough to deal with the places where the OpenStreetMap data isn't all you might hope. The client has a large number of sites in different cities that they're interested in, which means that everything has to be automated as much as possible, and that often means iterating again and again to discover geometrical or metadata problems that you need to work around. It can be quite frustrating. What's there now is pretty solid, I think, but it's quite fragile to changes in the OSM data. The rate of pay is good, there's enough work to occupy someone full-time, and the client is OK. There are the usual on-again-off-again rushes associated with this sort of business consulting. The timescale for me moving on is quite short: 2-3 weeks. I'll be organising notes and things for any potential handover, and there's another Haskell person at the client, so you would have someone to talk things over with. If you're interested, either get in touch with me if you have questions, or directly with Chad Scherrer (the Haskeller at the client: cscherrer at melinae.com). Cheers, Ian. -- Ian Ross Tel: +43(0)6804451378 ian at skybluetrades.net www.skybluetrades.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Tue Apr 22 22:08:51 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Wed, 23 Apr 2014 08:08:51 +1000 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: <20140422202800.GA32556@nanodesu.talocan.mine.nu> References: <20140422202800.GA32556@nanodesu.talocan.mine.nu> Message-ID: On 23 April 2014 04:28, Niklas Haas wrote: > On Tue, 22 Apr 2014 14:59:44 -0300, Thiago Negri wrote: >> When reading code, I find it quite distracting to have to get past the >> import list to reach the actual module code, as the import list can be (and >> often is) quite big. >> >> So, why not issue import statements at the bottom of a module file? >> >> Likewise, we can use "where" statements to define names used in a function >> after using them, so they don't distract the reader. >> >> I'm against imports at the middle of the file. >> But I guess being able to issue them at the end of the module could make >> sense if you want to get the reader straight to the code. >> >> A language pragma could be used to select between top imports or bottom >> imports (can't use both). >> >> What do you think? >> >> Example: >> >> """ >> {-# LANGUAGE LateImports #-} >> module Foo where >> >> bar :: String >> bar = "quux" >> >> baz :: Fiz >> baz = mkFiz >> >> import Fiz (Fiz, mkFiz) >> """ > > A practical reason is that this lets you process modules dependency > graphs without ever analyzing the structure past the import list. Also so when you're reading the code you have an idea up-front of what kind of external modules it might be using; otherwise - especially if the names are generic (e.g. "Parser") or using some form of overloaded extension (e.g. OverloadedStrings) - you might not be able to tell as easily the behaviour of the code. After all, two different parser libraries might behave differently (how they deal with backtracking is usually a big difference), and if you see someone using OverloadedStrings with ByteStrings then you know to be more careful about the code if using characters not expressable in a single byte. Whilst I doubt this is a common use-case in practice, it's also possible someone might want to add some code to a file using a shell script: if the imports are at the top you can just append it; if the imports are at the bottom you have to be more careful. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From roma at ro-che.info Tue Apr 22 22:09:38 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 23 Apr 2014 01:09:38 +0300 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: References: <20140420161125.GA3937@tatooine> <20140421053532.GA6082@tatooine> <8738h7jcv8.fsf@gnu.org> <20140421093813.GA1089@tatooine> <1398082242.2438.24.camel@kirk> Message-ID: <20140422220938.GA30112@sniper> * Jens Petersen [2014-04-22 11:37:44+0900] > > Or does cabal-install require the matching version > > of Cabal to be registered to work? > > I don't think so, but I believe some of the latest functionality needs > Cabal >= 1.18 to work. Unfortunately, it does. The reason being that in some cases (custom build type; -j) a setup script is compiled (against Cabal). If Cabal and cabal-install are of different versions, you'll get inconsistent behavior depending on whether, say, you build in parallel. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From mail at joachim-breitner.de Tue Apr 22 22:12:25 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 23 Apr 2014 00:12:25 +0200 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: References: <20140420161125.GA3937@tatooine> <20140421053532.GA6082@tatooine> <8738h7jcv8.fsf@gnu.org> <20140421093813.GA1089@tatooine> <1398082242.2438.24.camel@kirk> Message-ID: <1398204745.2268.6.camel@kirk> Hi, Am Dienstag, den 22.04.2014, 11:37 +0900 schrieb Jens Petersen: > > Alternatively it might be possible to build ghc with a newer > Cabal. Not > sure what that might break. > > > Right that should work I guess. can anyone comment on the chances of this to work? It seems that this would be a good way to solve the problem for the distributions. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From evohunz at gmail.com Tue Apr 22 22:37:46 2014 From: evohunz at gmail.com (Thiago Negri) Date: Tue, 22 Apr 2014 19:37:46 -0300 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: References: <20140422202800.GA32556@nanodesu.talocan.mine.nu> Message-ID: Appending code to a module via script is a valid use case, but then you just use top imports. This doesn't make a point towards forbidding bottom imports. The point is: there are a number of reasons to do top imports and another number of reasons to do bottom imports. I think bottom imports could be very useful. Even literate Haskell could read better with bottom imports, in my opinion. Em 22/04/2014 19:09, "Ivan Lazar Miljenovic" escreveu: > On 23 April 2014 04:28, Niklas Haas wrote: > > On Tue, 22 Apr 2014 14:59:44 -0300, Thiago Negri > wrote: > >> When reading code, I find it quite distracting to have to get past the > >> import list to reach the actual module code, as the import list can be > (and > >> often is) quite big. > >> > >> So, why not issue import statements at the bottom of a module file? > >> > >> Likewise, we can use "where" statements to define names used in a > function > >> after using them, so they don't distract the reader. > >> > >> I'm against imports at the middle of the file. > >> But I guess being able to issue them at the end of the module could make > >> sense if you want to get the reader straight to the code. > >> > >> A language pragma could be used to select between top imports or bottom > >> imports (can't use both). > >> > >> What do you think? > >> > >> Example: > >> > >> """ > >> {-# LANGUAGE LateImports #-} > >> module Foo where > >> > >> bar :: String > >> bar = "quux" > >> > >> baz :: Fiz > >> baz = mkFiz > >> > >> import Fiz (Fiz, mkFiz) > >> """ > > > > A practical reason is that this lets you process modules dependency > > graphs without ever analyzing the structure past the import list. > > Also so when you're reading the code you have an idea up-front of what > kind of external modules it might be using; otherwise - especially if > the names are generic (e.g. "Parser") or using some form of overloaded > extension (e.g. OverloadedStrings) - you might not be able to tell as > easily the behaviour of the code. > > After all, two different parser libraries might behave differently > (how they deal with backtracking is usually a big difference), and if > you see someone using OverloadedStrings with ByteStrings then you know > to be more careful about the code if using characters not expressable > in a single byte. > > Whilst I doubt this is a common use-case in practice, it's also > possible someone might want to add some code to a file using a shell > script: if the imports are at the top you can just append it; if the > imports are at the bottom you have to be more careful. > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.kjeldaas at gmail.com Tue Apr 22 23:33:25 2014 From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas) Date: Wed, 23 Apr 2014 01:33:25 +0200 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: References: <20140422202800.GA32556@nanodesu.talocan.mine.nu> Message-ID: I think it's a great idea. Go for it. "Real" haskell, similar to "real" java and C++ contains a long list of imports, much longer than what you typically have in toy examples. This leads to IDEs needing to hide them, because when they start growing, they start being noisy. Regarding the informational value in imports, I've written elisp support for both java and haskell where the imports are "guessed" based on compiler feedback/errors. The result of this is that very simple heuristics (looking at other open buffers to see what they use for example) is able to guess the imports in 99% of the cases. This means that the imports have little informational value. If a simple program can write the missing code, it is unlikely that it contributes much to a reader's comprehension of the code. I think, based on the success my auto-imports helper has for my code that the information value is inversely proportional to the number of files a reader has seen in the project. Some imports correlate between projects and these mostly standardized imports have even less informational value. I think the more "industrial" the code is, the more moving parts it juggles, the more imports will be used and the more readability is gained by putting them at the bottom. Based on the redundancy in this information, maybe there are other ways to innovate around representing this information more succinct and useful across multiple files in projects. Alexander On Wed, Apr 23, 2014 at 12:37 AM, Thiago Negri wrote: > Appending code to a module via script is a valid use case, but then you > just use top imports. This doesn't make a point towards forbidding bottom > imports. > > The point is: there are a number of reasons to do top imports and another > number of reasons to do bottom imports. I think bottom imports could be > very useful. Even literate Haskell could read better with bottom imports, > in my opinion. > Em 22/04/2014 19:09, "Ivan Lazar Miljenovic" > escreveu: > > On 23 April 2014 04:28, Niklas Haas wrote: >> > On Tue, 22 Apr 2014 14:59:44 -0300, Thiago Negri >> wrote: >> >> When reading code, I find it quite distracting to have to get past the >> >> import list to reach the actual module code, as the import list can be >> (and >> >> often is) quite big. >> >> >> >> So, why not issue import statements at the bottom of a module file? >> >> >> >> Likewise, we can use "where" statements to define names used in a >> function >> >> after using them, so they don't distract the reader. >> >> >> >> I'm against imports at the middle of the file. >> >> But I guess being able to issue them at the end of the module could >> make >> >> sense if you want to get the reader straight to the code. >> >> >> >> A language pragma could be used to select between top imports or bottom >> >> imports (can't use both). >> >> >> >> What do you think? >> >> >> >> Example: >> >> >> >> """ >> >> {-# LANGUAGE LateImports #-} >> >> module Foo where >> >> >> >> bar :: String >> >> bar = "quux" >> >> >> >> baz :: Fiz >> >> baz = mkFiz >> >> >> >> import Fiz (Fiz, mkFiz) >> >> """ >> > >> > A practical reason is that this lets you process modules dependency >> > graphs without ever analyzing the structure past the import list. >> >> Also so when you're reading the code you have an idea up-front of what >> kind of external modules it might be using; otherwise - especially if >> the names are generic (e.g. "Parser") or using some form of overloaded >> extension (e.g. OverloadedStrings) - you might not be able to tell as >> easily the behaviour of the code. >> >> After all, two different parser libraries might behave differently >> (how they deal with backtracking is usually a big difference), and if >> you see someone using OverloadedStrings with ByteStrings then you know >> to be more careful about the code if using characters not expressable >> in a single byte. >> >> Whilst I doubt this is a common use-case in practice, it's also >> possible someone might want to add some code to a file using a shell >> script: if the imports are at the top you can just append it; if the >> imports are at the bottom you have to be more careful. >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.fleckenstein at gmail.com Wed Apr 23 00:40:50 2014 From: andrew.fleckenstein at gmail.com (Andrew Fleckenstein) Date: Tue, 22 Apr 2014 20:40:50 -0400 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: References: <20140422202800.GA32556@nanodesu.talocan.mine.nu> Message-ID: IMHO, when you are unfamiliar with the codebase (like me), it's nice to see the imports first to give yourself a bearing point. On Tue, Apr 22, 2014 at 7:33 PM, Alexander Kjeldaas < alexander.kjeldaas at gmail.com> wrote: > > I think it's a great idea. Go for it. > > "Real" haskell, similar to "real" java and C++ contains a long list of > imports, much longer than what you typically have in toy examples. This > leads to IDEs needing to hide them, because when they start growing, they > start being noisy. > > Regarding the informational value in imports, I've written elisp support > for both java and haskell where the imports are "guessed" based on compiler > feedback/errors. The result of this is that very simple heuristics > (looking at other open buffers to see what they use for example) is able to > guess the imports in 99% of the cases. > > This means that the imports have little informational value. If a simple > program can write the missing code, it is unlikely that it contributes much > to a reader's comprehension of the code. I think, based on the success my > auto-imports helper has for my code that the information value is inversely > proportional to the number of files a reader has seen in the project. Some > imports correlate between projects and these mostly standardized imports > have even less informational value. > > I think the more "industrial" the code is, the more moving parts it > juggles, the more imports will be used and the more readability is gained > by putting them at the bottom. > > Based on the redundancy in this information, maybe there are other ways to > innovate around representing this information more succinct and useful > across multiple files in projects. > > > Alexander > > > On Wed, Apr 23, 2014 at 12:37 AM, Thiago Negri wrote: > >> Appending code to a module via script is a valid use case, but then you >> just use top imports. This doesn't make a point towards forbidding bottom >> imports. >> >> The point is: there are a number of reasons to do top imports and another >> number of reasons to do bottom imports. I think bottom imports could be >> very useful. Even literate Haskell could read better with bottom imports, >> in my opinion. >> Em 22/04/2014 19:09, "Ivan Lazar Miljenovic" >> escreveu: >> >> On 23 April 2014 04:28, Niklas Haas wrote: >>> > On Tue, 22 Apr 2014 14:59:44 -0300, Thiago Negri >>> wrote: >>> >> When reading code, I find it quite distracting to have to get past the >>> >> import list to reach the actual module code, as the import list can >>> be (and >>> >> often is) quite big. >>> >> >>> >> So, why not issue import statements at the bottom of a module file? >>> >> >>> >> Likewise, we can use "where" statements to define names used in a >>> function >>> >> after using them, so they don't distract the reader. >>> >> >>> >> I'm against imports at the middle of the file. >>> >> But I guess being able to issue them at the end of the module could >>> make >>> >> sense if you want to get the reader straight to the code. >>> >> >>> >> A language pragma could be used to select between top imports or >>> bottom >>> >> imports (can't use both). >>> >> >>> >> What do you think? >>> >> >>> >> Example: >>> >> >>> >> """ >>> >> {-# LANGUAGE LateImports #-} >>> >> module Foo where >>> >> >>> >> bar :: String >>> >> bar = "quux" >>> >> >>> >> baz :: Fiz >>> >> baz = mkFiz >>> >> >>> >> import Fiz (Fiz, mkFiz) >>> >> """ >>> > >>> > A practical reason is that this lets you process modules dependency >>> > graphs without ever analyzing the structure past the import list. >>> >>> Also so when you're reading the code you have an idea up-front of what >>> kind of external modules it might be using; otherwise - especially if >>> the names are generic (e.g. "Parser") or using some form of overloaded >>> extension (e.g. OverloadedStrings) - you might not be able to tell as >>> easily the behaviour of the code. >>> >>> After all, two different parser libraries might behave differently >>> (how they deal with backtracking is usually a big difference), and if >>> you see someone using OverloadedStrings with ByteStrings then you know >>> to be more careful about the code if using characters not expressable >>> in a single byte. >>> >>> Whilst I doubt this is a common use-case in practice, it's also >>> possible someone might want to add some code to a file using a shell >>> script: if the imports are at the top you can just append it; if the >>> imports are at the bottom you have to be more careful. >>> >>> -- >>> Ivan Lazar Miljenovic >>> Ivan.Miljenovic at gmail.com >>> http://IvanMiljenovic.wordpress.com >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Wed Apr 23 01:05:56 2014 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 22 Apr 2014 21:05:56 -0400 Subject: [Haskell-cafe] imports at bottom Message-ID: <201404230105.s3N15uXP020798@stowe.cs.dartmouth.edu> > A language pragma could be used to select between top imports or bottom > imports (can't use both). > > What do you think? Warning. This one touches a personal hot button, mostly off topic. To my mind, language pragmas are blemishes. Reasonable, assuredly, to announce that code uses some nonstandard feature of a compiler, but generally unreasonable as an integral part of the language definition. As originally promulgated for ALGOL, pragmas had no effect on the meaning of a program or its conformance to the standard, though they could, for example, affect the efficiency of object code. Language pragmas stray far from this intent. As unstable features, often incompletely described (just what does FlexibleInstances permit, anyway?), language pragmas might well be banned from the Haskell Platform. Doug McIlroy From sol at typeful.net Wed Apr 23 01:17:24 2014 From: sol at typeful.net (Simon Hengel) Date: Wed, 23 Apr 2014 09:17:24 +0800 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: References: Message-ID: <20140423011724.GB3050@x200> > So, why not issue import statements at the bottom of a module file? Because then you have to deal with two ways of reading code (unless you only intend to read code that you have written your self). Cheers, Simon From hvr at gnu.org Wed Apr 23 17:55:12 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 23 Apr 2014 19:55:12 +0200 Subject: [Haskell-cafe] Info on dependencies among libs distributed with ghc? In-Reply-To: <1398204745.2268.6.camel@kirk> (Joachim Breitner's message of "Wed, 23 Apr 2014 00:12:25 +0200") References: <20140420161125.GA3937@tatooine> <20140421053532.GA6082@tatooine> <8738h7jcv8.fsf@gnu.org> <20140421093813.GA1089@tatooine> <1398082242.2438.24.camel@kirk> <1398204745.2268.6.camel@kirk> Message-ID: <874n1krkvz.fsf@gnu.org> On 2014-04-23 at 00:12:25 +0200, Joachim Breitner wrote: >>> Alternatively it might be possible to build ghc with a newer >>> Cabal. Not >>> sure what that might break. >> >> Right that should work I guess. > > can anyone comment on the chances of this to work? It seems that this > would be a good way to solve the problem for the distributions. you'd probably need to backport commits such as git.haskell.org/ghc.git/commitdiff/8992d5269804b727fb77249511e89df678526907 but other than that it would work From dhelta.diaz at gmail.com Wed Apr 23 22:19:45 2014 From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=) Date: Thu, 24 Apr 2014 00:19:45 +0200 Subject: [Haskell-cafe] How to get access to Haddock HTML for newly cabal installed package? In-Reply-To: <535557F3.2030909@fuuzetsu.co.uk> References: <58AA9790-A188-40E4-A040-A7507D97C267@gmail.com> <535528ED.8010508@fuuzetsu.co.uk> <535557F3.2030909@fuuzetsu.co.uk> Message-ID: I clicked "Reply All", hoping to reach the list, and I did. And yes, you are right about he's probably using OSX. However, I do not have access to any OSX to look for the right path. Did you solve the problem, David? Best regards, Daniel D?az. On Mon, Apr 21, 2014 at 7:40 PM, Mateusz Kowalczyk wrote: > On 04/21/2014 07:21 PM, Daniel D?az Casanueva wrote: > > It seems you are running on Windows. From that assumption, try looking in > > the following path: > users/yourusername/AppData/Roaming/cabal/doc/index.html > > > > Good luck. > > From the use of ~ and Users, I think David is using OSX. > > PS: You gave me quite a good scare, it looks like you're replying to me > and I'm certainly *not* using Windows. > > > > > On Mon, Apr 21, 2014 at 4:19 PM, Mateusz Kowalczyk > > wrote: > > > >> On 04/21/2014 03:52 PM, David Banas wrote: > >>> Does anyone know how I get the link to the Haddock generated HTML for a > >> newly cabal installed package to show up in: > >>> > >>> file:///Users/dbanas/Library/Haskell/doc/index.html > >>> > >>> ? > >>> > >>> I?ve got documentation=True set, in ~/.cabal/config. > >>> > >>> Thanks, > >>> -db > >>> > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> Haskell-Cafe at haskell.org > >>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>> > >> > >> I believe it should be automagical. Are you sure you are cabal > >> install'ing to the user directory as opposed to something like a sandbox > >> instead? > >> > >> Upon a second look, I don't know where you're getting that path from. My > >> documentation seems to be listed under ~/.cabal/share/doc/index.html , > >> perhaps that's what you want? > >> > >> -- > >> Mateusz K. > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > > > > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Thu Apr 24 00:29:16 2014 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 24 Apr 2014 12:29:16 +1200 Subject: [Haskell-cafe] Syntax proposal for "reverse apply"/"pipeline apply" (flip ($)) In-Reply-To: <98F736F7-9D3D-40C8-9C1C-C17B072EBE0D@gmail.com> References: <534FCAA4.5000804@plaimi.net> <534FD1B4.6020701@plaimi.net> <98F736F7-9D3D-40C8-9C1C-C17B072EBE0D@gmail.com> Message-ID: <356A5974-D0B2-4647-9087-3ADA86B85FA7@cs.otago.ac.nz> On 18/04/2014, at 1:11 AM, Alexey Muranov wrote: > I do not know F#, and maybe i am missing something, but assuming that > > x |> f |> g == (x |> f) |> g > > and > > g <| f <| x == g <| (f <| x) > > what are > > x |> f <| y > This is the same as (f x) y. Determined by experiment: let h x y = (x,y) ;; 1 |> h <| 2 ;; => val it : int * int = (1, 2) (f y) x would give the answer (2, 1). > > g <| x |> f This is f (g x). Determined by experiment: let f x = x * 2 ;; let g x = x + 1 ;; g <| 1 |> f ;; => val it : int = 4 g (f 1) would give the answer 3. From ok at cs.otago.ac.nz Thu Apr 24 00:51:57 2014 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 24 Apr 2014 12:51:57 +1200 Subject: [Haskell-cafe] Imports at bottom, why not? In-Reply-To: <20140423011724.GB3050@x200> References: <20140423011724.GB3050@x200> Message-ID: <51B31F96-5A54-42DB-8DB9-48A62DD514D7@cs.otago.ac.nz> Someone asked "what about other languages that use bottom imports?" It's actually a pretty rare language feature. Off-hand, I've used more languages where assignment is (or can be) written "expr -> var" than languages with bottom imports. If you don't want to be distracted by imports, you could use your favoured editor's chroma-coding features to colour them grey, so that your eye naturally skips to the rest of the code. One major problem is that as long as (a) you need to read other people's code as well as your own and (b) the language allows top imports, allowing bottom imports will FAIL TO SOLVE the problem it was invented for: you will *still* have to deal with top imports when reading other people's code. To be honest, folding the imports seems to me like the perfect solution: no language change (given that there _are_ other compilers than GHC, this seems like a Good Thing), a click away when you do want to see what's there but just one (-)imports line when you don't. I for one *prefer* seeing the imports at the top; I would find imports at the bottom very unpleasant to work with. Perhaps that's because I'm used to top imports everywhere else. From dstcruz at gmail.com Thu Apr 24 02:18:00 2014 From: dstcruz at gmail.com (Daniel Santa Cruz) Date: Wed, 23 Apr 2014 22:18:00 -0400 Subject: [Haskell-cafe] Haskell Weekly News: Issue 292 Message-ID: Welcome to issue 292 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from April 13 to 19, 2014 Edward Kemett wrote in to remind us of the Call For Proposals for CUFP 2014, which is going to be held in Gothenburg, Sweden between September 4-6. See more details here [1] http://goo.gl/X62cBO Quotes of the Week * pdxleif: see s.p. jones & h.p. lovecraft's paper on the subject: "generic programming with lenses, barbed wire, and the fibres of sanity" Top Reddit Stories * A time traveling debugger for Elm - pause, rewind, replay, and change history Domain: debug.elm-lang.org, Score: 87, Comments: 6 On Reddit: [2] http://goo.gl/GJahIU Original: [3] http://goo.gl/V2kcCP * OC: Haskell programming font with ligatures Domain: github.com, Score: 78, Comments: 59 On Reddit: [4] http://goo.gl/ZaFRJ4 Original: [5] http://goo.gl/m17EUj * Porting GHC: A Tale of Two Architectures Domain: chiark.greenend.org.uk, Score: 77, Comments: 12 On Reddit: [6] http://goo.gl/MJ196R Original: [7] http://goo.gl/PVVHZo * Try Idris Domain: tryidris.org, Score: 70, Comments: 22 On Reddit: [8] http://goo.gl/7hn84J Original: [9] http://goo.gl/6iPW8S * Why are examples completely absent from hackage? Am I missing something? Domain: self.haskell, Score: 67, Comments: 68 On Reddit: [10] http://goo.gl/QmZjZs Original: [11] http://goo.gl/QmZjZs * Implementing Python in Haskell - Melbourne Haskell Users Group, April 24 Domain: meetup.com, Score: 53, Comments: 6 On Reddit: [12] http://goo.gl/tYRtG9 Original: [13] http://goo.gl/oClHGb * Blog post - Haskell Gets Static Typing Right - Andres L?h Domain: skillsmatterblog.wordpress.com, Score: 51, Comments: 25 On Reddit: [14] http://goo.gl/5AQO4h Original: [15] http://goo.gl/WddMUA * Haskell for all: Scalable program architectures Domain: haskellforall.com, Score: 45, Comments: 19 On Reddit: [16] http://goo.gl/JDYSQl Original: [17] http://goo.gl/MUrRRg * GHC 7.8?s -staticlib flag makes compiling Mac libs easy Domain: maxs.io, Score: 42, Comments: 5 On Reddit: [18] http://goo.gl/SVICOm Original: [19] http://goo.gl/FwVdOv * Autocomplete command line options with GHC 7.8 Domain: self.haskell, Score: 39, Comments: 10 On Reddit: [20] http://goo.gl/bXNI20 Original: [21] http://goo.gl/bXNI20 * How to learn Haskell Domain: acm3.wustl.edu, Score: 39, Comments: 16 On Reddit: [22] http://goo.gl/oaQsAL Original: [23] http://goo.gl/TLbCEL * Calling Python from Haskell Domain: lunaryorn.com, Score: 36, Comments: 14 On Reddit: [24] http://goo.gl/9n8O4m Original: [25] http://goo.gl/j8YqgK * "latest API" link in Hackage Domain: self.haskell, Score: 30, Comments: 15 On Reddit: [26] http://goo.gl/RJnphF Original: [27] http://goo.gl/RJnphF * Functional Pearl: F for Functor Domain: cs.ox.ac.uk, Score: 27, Comments: 14 On Reddit: [28] http://goo.gl/i7TPuf Original: [29] http://goo.gl/7c33Xn Top StackOverflow Questions * Idris eager evaluation votes: 14, answers: 1 Read on SO: [30] http://goo.gl/LDpNtI * Why use such a peculiar function type in monads? votes: 11, answers: 4 Read on SO: [31] http://goo.gl/XX8KSX * How does mapA work with a Stream Function Arrow in Haskell? votes: 8, answers: 1 Read on SO: [32] http://goo.gl/vECKBa * Lenses and Monomorphism Restriction votes: 8, answers: 2 Read on SO: [33] http://goo.gl/hG44KA * Is this a GHC bug? votes: 7, answers: 1 Read on SO: [34] http://goo.gl/sqByI2 * Why do some of threepenny-gui FRP combinators operate on a MonadIO monad instead of being pure? votes: 6, answers: 2 Read on SO: [35] http://goo.gl/ySVqya * S combinator in Haskell votes: 6, answers: 2 Read on SO: [36] http://goo.gl/vnb64N * Graphing criterion benchmarks taking different orders of magnitude of time votes: 6, answers: 1 Read on SO: [37] http://goo.gl/J3jgWf * Fun with fixity votes: 6, answers: 1 Read on SO: [38] http://goo.gl/molyi9 Until next time, [39]+Daniel Santa Cruz References 1. http://cufp.org/2014cfp 2. http://debug.elm-lang.org/ 3. http://www.reddit.com/r/haskell/comments/233ff9/a_time_traveling_debugger_for_elm_pause_rewind/ 4. https://github.com/i-tu/source-code-pro-L/ 5. http://www.reddit.com/r/haskell/comments/23g9dv/oc_haskell_programming_font_with_ligatures/ 6. http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2014-04-15-porting-ghc-a-tale-of-two-architectures.html 7. http://www.reddit.com/r/haskell/comments/232erb/porting_ghc_a_tale_of_two_architectures/ 8. http://www.tryidris.org/console 9. http://www.reddit.com/r/haskell/comments/22yww7/try_idris/ 10. http://www.reddit.com/r/haskell/comments/23dxli/why_are_examples_completely_absent_from_hackage/ 11. http://www.reddit.com/r/haskell/comments/23dxli/why_are_examples_completely_absent_from_hackage/ 12. http://www.meetup.com/Melbourne-Haskell-Users-Group/events/174401572/ 13. http://www.reddit.com/r/haskell/comments/238akv/implementing_python_in_haskell_melbourne_haskell/ 14. http://skillsmatterblog.wordpress.com/2014/04/15/guest-post-haskell-gets-static-typing-right-andres-loh/ 15. http://www.reddit.com/r/haskell/comments/233njg/blog_post_haskell_gets_static_typing_right_andres/ 16. http://www.haskellforall.com/2014/04/scalable-program-architectures.html 17. http://www.reddit.com/r/haskell/comments/2300zb/haskell_for_all_scalable_program_architectures/ 18. http://maxs.io/ghc-78-static-lib-flag/ 19. http://www.reddit.com/r/haskell/comments/23fyok/ghc_78s_staticlib_flag_makes_compiling_mac_libs/ 20. http://www.reddit.com/r/haskell/comments/236qkb/autocomplete_command_line_options_with_ghc_78/ 21. http://www.reddit.com/r/haskell/comments/236qkb/autocomplete_command_line_options_with_ghc_78/ 22. http://acm3.wustl.edu/functional/haskell.php 23. http://www.reddit.com/r/haskell/comments/239f2m/how_to_learn_haskell/ 24. http://www.lunaryorn.com/2014/04/15/calling-python-from-haskell.html 25. http://www.reddit.com/r/haskell/comments/2330aj/calling_python_from_haskell/ 26. http://www.reddit.com/r/haskell/comments/22xz96/latest_api_link_in_hackage/ 27. http://www.reddit.com/r/haskell/comments/22xz96/latest_api_link_in_hackage/ 28. http://www.cs.ox.ac.uk/people/daniel.james/functor/functor.pdf 29. http://www.reddit.com/r/haskell/comments/2327e7/functional_pearl_f_for_functor/ 30. http://stackoverflow.com/questions/23149532/idris-eager-evaluation 31. http://stackoverflow.com/questions/23051800/why-use-such-a-peculiar-function-type-in-monads 32. http://stackoverflow.com/questions/23048100/how-does-mapa-work-with-a-stream-function-arrow-in-haskell 33. http://stackoverflow.com/questions/23066099/lenses-and-monomorphism-restriction 34. http://stackoverflow.com/questions/23091080/is-this-a-ghc-bug 35. http://stackoverflow.com/questions/23044464/why-do-some-of-threepenny-gui-frp-combinators-operate-on-a-monadio-monad-instead 36. http://stackoverflow.com/questions/23095224/s-combinator-in-haskell 37. http://stackoverflow.com/questions/23129649/graphing-criterion-benchmarks-taking-different-orders-of-magnitude-of-time 38. http://stackoverflow.com/questions/23142075/fun-with-fixity 39. https://plus.google.com/105107667630152149014/about -------------- next part -------------- An HTML attachment was scrubbed... URL: From walkiner at eecs.oregonstate.edu Thu Apr 24 13:19:49 2014 From: walkiner at eecs.oregonstate.edu (Eric Walkingshaw) Date: Thu, 24 Apr 2014 15:19:49 +0200 Subject: [Haskell-cafe] How to get access to Haddock HTML for newly cabal installed package? In-Reply-To: <58AA9790-A188-40E4-A040-A7507D97C267@gmail.com> References: <58AA9790-A188-40E4-A040-A7507D97C267@gmail.com> Message-ID: David Banas wrote: > Does anyone know how I get the link to the Haddock generated HTML for a newly cabal installed package to show up in: > > file:///Users/dbanas/Library/Haskell/doc/index.html > > I?ve got documentation=True set, in ~/.cabal/config. In ~/.cabal/config, try setting: doc-index-file: /Users/dbanas/Library/Haskell/doc/index.html I also use OS X and use this as my doc index, since that's where Haskell Platform puts it. -Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From garrett.mitchener at gmail.com Thu Apr 24 14:13:14 2014 From: garrett.mitchener at gmail.com (Garrett Mitchener) Date: Thu, 24 Apr 2014 07:13:14 -0700 (PDT) Subject: [Haskell-cafe] Haskell Programming Font with Ligatures In-Reply-To: <1025dd06-1b73-435c-902b-302a654fd1c0@googlegroups.com> References: <1025dd06-1b73-435c-902b-302a654fd1c0@googlegroups.com> Message-ID: <8c27a5dd-f8a1-44bd-8882-d3f3092fb7d9@googlegroups.com> I just tried this in gedit and it looks *really* nice! Thanks for putting this together. Doesn't work in emacs though :-( -------------- next part -------------- An HTML attachment was scrubbed... URL: From capn.freako at gmail.com Thu Apr 24 16:02:17 2014 From: capn.freako at gmail.com (David Banas) Date: Thu, 24 Apr 2014 09:02:17 -0700 Subject: [Haskell-cafe] How to get access to Haddock HTML for newly cabal installed package? In-Reply-To: References: Message-ID: <0903BC6B-52AD-4ACA-A88C-4A1506F5FB15@gmail.com> Nope. I?ve had some great suggestions, but am still struggling to figure this one out. And, yes, I?m running on a MacBook using OSX Mavericks. Thanks, -db > Date: Thu, 24 Apr 2014 00:19:45 +0200 > From: Daniel D?az Casanueva > To: Haskell-Cafe > Subject: Re: [Haskell-cafe] How to get access to Haddock HTML for > newly cabal installed package? > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > I clicked "Reply All", hoping to reach the list, and I did. And yes, you > are right about he's probably using OSX. However, I do not have access to > any OSX to look for the right path. Did you solve the problem, David? > > Best regards, > Daniel D?az. From rustompmody at gmail.com Thu Apr 24 17:15:49 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Thu, 24 Apr 2014 22:45:49 +0530 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! Message-ID: I'm mighty pleased to note that the following is valid Haskell code! Do others find this useful/appealing? Any possibilities on making the commented out parts work? [Pragmatics about typing this at the same speed and facility as we do with Ascii is a separate and (IMHO) solvable problem though its not the case at the moment] -------------------- import qualified Data.Set as Set -- Experimenting with Unicode in Haskell source -- Numbers x ? y = x /= y x ? y = x <= y x ? y = x >= y x ? y = divMod x y x ? y = x ^ y x ? y = x * y -- readability hmmm !!! ? = pi -- ? x = floor x -- ? x = ceiling x -- Lists xs ? ys = xs ++ ys -- Bools x ? y = x && y x ? y = y || y -- ?x = not x -- Sets x ? s = x `Set.member` s -- or keep ? for list elem? s ? t = s `Set.union` t s ? t = s `Set.intersection` t s ? t = s `Set.isSubsetOf` t s ? t = s `Set.isProperSubsetOf` t s ? t = not (s `Set.isSubsetOf` t) -- ? = Set.null -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Apr 24 17:21:27 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 24 Apr 2014 13:21:27 -0400 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: On Thu, Apr 24, 2014 at 1:15 PM, Rustom Mody wrote: > Any possibilities on making the commented out parts work? Unary operators are not really doable. Take a look at the ugliness around unary minus for why. (Note in particular how it breaks section syntax.) Nullary operators are even less doable; Set.null must be done with an identifier character, not a symbol character. (There are a number of such that would fit, since it is actually used in some languages.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguelimo38 at yandex.ru Thu Apr 24 17:22:10 2014 From: miguelimo38 at yandex.ru (MigMit) Date: Thu, 24 Apr 2014 21:22:10 +0400 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: <02C0B25D-C797-4874-938C-2A74131DB605@yandex.ru> It's disgusting. ?????????? ? iPhone > 24 ???. 2014 ?., ? 21:15, Rustom Mody ???????(?): > > I'm mighty pleased to note that the following is valid Haskell code! > > Do others find this useful/appealing? > Any possibilities on making the commented out parts work? > > [Pragmatics about typing this at the same speed and facility as we do with Ascii is a separate and (IMHO) solvable problem though its not the case at the moment] > > > -------------------- > import qualified Data.Set as Set > -- Experimenting with Unicode in Haskell source > > -- Numbers > x ? y = x /= y > x ? y = x <= y > x ? y = x >= y > x ? y = divMod x y > x ? y = x ^ y > > x ? y = x * y -- readability hmmm !!! > ? = pi > > -- ? x = floor x > -- ? x = ceiling x > > -- Lists > xs ? ys = xs ++ ys > > -- Bools > x ? y = x && y > x ? y = y || y > -- ?x = not x > > > -- Sets > > x ? s = x `Set.member` s -- or keep ? for list elem? > s ? t = s `Set.union` t > s ? t = s `Set.intersection` t > s ? t = s `Set.isSubsetOf` t > s ? t = s `Set.isProperSubsetOf` t > s ? t = not (s `Set.isSubsetOf` t) > -- ? = Set.null > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From orclev at gmail.com Thu Apr 24 17:27:51 2014 From: orclev at gmail.com (Kyle Murphy) Date: Thu, 24 Apr 2014 13:27:51 -0400 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: It's an interesting feature, and nice if you want that sort of thing, but not something I'd personally want to see as the default. Deviating from the standard ASCII set of characters is just too much of a hurdle to usability of the language. If you really like that sort of thing though you might want to look into APL which is either famous or infamous depending on your outlook for needing its own custom keyboard in order to write it. -R. Kyle Murphy -- Curiosity was framed, Ignorance killed the cat. On Thu, Apr 24, 2014 at 1:15 PM, Rustom Mody wrote: > I'm mighty pleased to note that the following is valid Haskell code! > > Do others find this useful/appealing? > Any possibilities on making the commented out parts work? > > [Pragmatics about typing this at the same speed and facility as we do with > Ascii is a separate and (IMHO) solvable problem though its not the case at > the moment] > > > -------------------- > import qualified Data.Set as Set > -- Experimenting with Unicode in Haskell source > > -- Numbers > x ? y = x /= y > x ? y = x <= y > x ? y = x >= y > x ? y = divMod x y > x ? y = x ^ y > > x ? y = x * y -- readability hmmm !!! > ? = pi > > -- ? x = floor x > -- ? x = ceiling x > > -- Lists > xs ? ys = xs ++ ys > > -- Bools > x ? y = x && y > x ? y = y || y > -- ?x = not x > > > -- Sets > > x ? s = x `Set.member` s -- or keep ? for list elem? > s ? t = s `Set.union` t > s ? t = s `Set.intersection` t > s ? t = s `Set.isSubsetOf` t > s ? t = s `Set.isProperSubsetOf` t > s ? t = not (s `Set.isSubsetOf` t) > -- ? = Set.null > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustompmody at gmail.com Thu Apr 24 17:36:20 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Thu, 24 Apr 2014 23:06:20 +0530 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: On Thu, Apr 24, 2014 at 10:57 PM, Kyle Murphy wrote: > It's an interesting feature, and nice if you want that sort of thing, but > not something I'd personally want to see as the default. Deviating from the > standard ASCII set of characters is just too much of a hurdle to usability > of the language. If you really like that sort of thing though you might > want to look into APL which is either famous or infamous depending on your > outlook for needing its own custom keyboard in order to write it. > > -R. Kyle Murphy > I dont think anyone can reasonably talk of making it a default! Just seeing how much and to where the envelope can be pushed. eg I would like to see \ spelled as ? As for APL, it failed for various reasons eg - mixing up assembly language (straight line code with gotos) with functional idioms - the character set was a major hurdle in the 60s. Thats not an issue today when most OSes/editors are unicode compliant -------------- next part -------------- An HTML attachment was scrubbed... URL: From hsyl20 at gmail.com Thu Apr 24 17:54:05 2014 From: hsyl20 at gmail.com (Sylvain Henry) Date: Thu, 24 Apr 2014 19:54:05 +0200 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: As a first step, it could be useful to provide this kind of syntax for haddock generated HTML sources (read-only). Fortress language provides something similar (see Section 2.3 in the spec [1]). -Sylvain [1] http://www.ccs.neu.edu/home/samth/fortress-spec.pdf 2014-04-24 19:36 GMT+02:00 Rustom Mody : > > > > On Thu, Apr 24, 2014 at 10:57 PM, Kyle Murphy wrote: > >> It's an interesting feature, and nice if you want that sort of thing, but >> not something I'd personally want to see as the default. Deviating from the >> standard ASCII set of characters is just too much of a hurdle to usability >> of the language. If you really like that sort of thing though you might >> want to look into APL which is either famous or infamous depending on your >> outlook for needing its own custom keyboard in order to write it. >> >> -R. Kyle Murphy >> > > I dont think anyone can reasonably talk of making it a default! > Just seeing how much and to where the envelope can be pushed. > > eg I would like to see \ spelled as ? > > As for APL, it failed for various reasons eg > - mixing up assembly language (straight line code with gotos) with > functional idioms > - the character set was a major hurdle in the 60s. Thats not an issue > today when most OSes/editors are unicode compliant > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nickolay.kudasov at gmail.com Thu Apr 24 18:40:02 2014 From: nickolay.kudasov at gmail.com (Nickolay Kudasov) Date: Thu, 24 Apr 2014 22:40:02 +0400 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: > > eg I would like to see \ spelled as ? ?I have symbol substitution enabled in Vim. E.g. when I write \ (and it is syntactically lambda) I get ?. The same way composition (.) is replaced with ?. The same trick can be enabled for other operators as well. So I have normal text and nice presentation in *my* text editor: it does not bother anyone but me. Nick 2014-04-24 21:36 GMT+04:00 Rustom Mody : > > > > On Thu, Apr 24, 2014 at 10:57 PM, Kyle Murphy wrote: > >> It's an interesting feature, and nice if you want that sort of thing, but >> not something I'd personally want to see as the default. Deviating from the >> standard ASCII set of characters is just too much of a hurdle to usability >> of the language. If you really like that sort of thing though you might >> want to look into APL which is either famous or infamous depending on your >> outlook for needing its own custom keyboard in order to write it. >> >> -R. Kyle Murphy >> > > I dont think anyone can reasonably talk of making it a default! > Just seeing how much and to where the envelope can be pushed. > > eg I would like to see \ spelled as ? > > As for APL, it failed for various reasons eg > - mixing up assembly language (straight line code with gotos) with > functional idioms > - the character set was a major hurdle in the 60s. Thats not an issue > today when most OSes/editors are unicode compliant > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vandijk.roel at gmail.com Thu Apr 24 19:51:07 2014 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Thu, 24 Apr 2014 21:51:07 +0200 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: I think it is a nice feature if used sparingly. Note that while Unicode symbols are a normal part of the Haskell language you can also turn on some Unicode syntax using the UnicodeSyntax [1] language extension. This means the following will be accepted by GHC: (?) ? ? ?. Eq ? ? ? ? [?] ? Bool (?) = elem You might want to take a look at some packages I created that define some Unicode symbols for common operators and values [2, 3, 4]. Opinions on whether this is a good idea vary. My anecdotal observation is that it seems to be used more by people who speak a native language that is already poorly served by ASCII. Perhaps because they are already used to not being able to simply type every character they need. 1 - http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#unicode-syntax 2 - http://www.haskell.org/haskellwiki/Unicode-symbols 3 - http://hackage.haskell.org/package/base-unicode-symbols 4 - http://hackage.haskell.org/package/containers-unicode-symbols -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Thu Apr 24 20:02:30 2014 From: tikhon at jelv.is (Tikhon Jelvis) Date: Thu, 24 Apr 2014 13:02:30 -0700 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: I'm actually a fan of using Unicode in my code. As people like to say, code is read more often than it's written, so I'm willing to make typing a bit harder in return for making the code prettier. Happily, typing Unicode characters is quite easy with a good editor (Emacs). I use the TeX input mode which just lets me use TeX names for symbols, but somebody has actually written a Haskell-specific mode which might be even better[1]. I might try it some day. One peculiar habit I have is using x? x? x? instead of x1, x2, x3 or x_1, x_2, x_3. I definitely find the Unicode version easier to read and work with, although it probably helps that Emacs highlights the number in a different color. Unfortunately, this is a minority opinion at the moment. Even in *this* day and age, people still find Unicode too difficult to type! For my internal code, this is not a problem, but it's kept me from putting any Unicode in public APIs. Shame. I also don't use UnicodeSyntax because Emacs can do most of the transformations transparently for me without changing the underlying file. You can turn this on by setting `haskell-font-lock-symbols' to t. I find it makes for much nicer code that's easier to read and, even more importantly, easier to skim. [1]: https://github.com/roelvandijk/emacs-haskell-unicode-input-method On Thu, Apr 24, 2014 at 12:51 PM, Roel van Dijk wrote: > I think it is a nice feature if used sparingly. > > Note that while Unicode symbols are a normal part of the Haskell language > you can also turn on some Unicode syntax using the UnicodeSyntax [1] > language extension. This means the following will be accepted by GHC: > > (?) ? ? ?. Eq ? ? ? ? [?] ? Bool > (?) = elem > > You might want to take a look at some packages I created that define some > Unicode symbols for common operators and values [2, 3, 4]. > > Opinions on whether this is a good idea vary. My anecdotal observation is > that it seems to be used more by people who speak a native language that is > already poorly served by ASCII. Perhaps because they are already used to > not being able to simply type every character they need. > > 1 - > http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#unicode-syntax > 2 - http://www.haskell.org/haskellwiki/Unicode-symbols > 3 - http://hackage.haskell.org/package/base-unicode-symbols > 4 - http://hackage.haskell.org/package/containers-unicode-symbols > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhrosa at gmail.com Thu Apr 24 08:43:48 2014 From: dhrosa at gmail.com (Diony Rosa) Date: Wed, 24 Apr 2014 09:43:48 +0100 Subject: [Haskell-cafe] Diony Rosa Message-ID: http://kagankoc.av.tr/wpjbk/fowmsjjzqavbptwpdmgezeghq.wiodhkueoruzhok -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Thu Apr 24 21:07:57 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Thu, 24 Apr 2014 22:07:57 +0100 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: <53597D2D.6060107@nh2.me> A smart, recently proposed alternative is using a font that does this automatically for you: https://github.com/i-tu/Hasklig In my opinion, this gives you all benefits of unicode syntax without imposing the drawbacks on others, and you don't even have to set up a custom input method to conveniently type them in. Quoting: Some Haskell programmers have resorted to unicode symbols in code as a solution (?, ? etc.). This opens a whole new can of worms. In addition to encoding/compatibility problems and all the reasons it never worked out for APL, these symbols are one-character-wide and therefore eye-strainingly small. Hasklig solves this problem the way typographers have always solved ill-fitting characters which co-occur often: ligatures. The underlying code stays the same ? only the representation changes. On Thu 24 Apr 2014 21:02:30 BST, Tikhon Jelvis wrote: > I'm actually a fan of using Unicode in my code. As people like to say, > code is read more often than it's written, so I'm willing to make > typing a bit harder in return for making the code prettier. > > Happily, typing Unicode characters is quite easy with a good editor > (Emacs). I use the TeX input mode which just lets me use TeX names for > symbols, but somebody has actually written a Haskell-specific mode > which might be even better[1]. I might try it some day. > > One peculiar habit I have is using x? x? x? instead of x1, x2, x3 or > x_1, x_2, x_3. I definitely find the Unicode version easier to read > and work with, although it probably helps that Emacs highlights the > number in a different color. > > Unfortunately, this is a minority opinion at the moment. Even in > *this* day and age, people still find Unicode too difficult to type! > > For my internal code, this is not a problem, but it's kept me from > putting any Unicode in public APIs. Shame. > > I also don't use UnicodeSyntax because Emacs can do most of the > transformations transparently for me without changing the underlying > file. You can turn this on by setting `haskell-font-lock-symbols' to > t. I find it makes for much nicer code that's easier to read and, even > more importantly, easier to skim. > > [1]: https://github.com/roelvandijk/emacs-haskell-unicode-input-method > > > On Thu, Apr 24, 2014 at 12:51 PM, Roel van Dijk > > wrote: > > I think it is a nice feature if used sparingly. > > Note that while Unicode symbols are a normal part of the Haskell > language you can also turn on some Unicode syntax using the > UnicodeSyntax [1] language extension. This means the following > will be accepted by GHC: > > (?) ? ? ?. Eq ? ? ? ? [?] ? Bool > (?) = elem > > You might want to take a look at some packages I created that > define some Unicode symbols for common operators and values [2, 3, 4]. > > Opinions on whether this is a good idea vary. My anecdotal > observation is that it seems to be used more by people who speak a > native language that is already poorly served by ASCII. Perhaps > because they are already used to not being able to simply type > every character they need. > > 1 > - http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#unicode-syntax > 2 - http://www.haskell.org/haskellwiki/Unicode-symbols > 3 - http://hackage.haskell.org/package/base-unicode-symbols > 4 - http://hackage.haskell.org/package/containers-unicode-symbols > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From alois.cochard at gmail.com Thu Apr 24 22:54:29 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Thu, 24 Apr 2014 23:54:29 +0100 Subject: [Haskell-cafe] [ANN] codex - generate tags file from dependencies Message-ID: Hi, Just to let you know that I released a tool which allow to generate a tags[1] file for a given cabal project using the sources of all the dependencies of that project. `cabal install codex` You can simply run `codex update` in one of your cabal project directory and you'll get a 'codex.tags' file to feed in your favorite text editors. It store the source code in the hackage local cache, and it store there as well the tags file per module (so the tool just aggregate per project). I hope it will be useful to other hackers, it's a joy for me in vim when using unknown libraries. Note: This tool actually use `ctags` but that could be easily made configurable if someone need it, integrating native haskell tagger is an option too. I personally like using ctags, it's very fast. *[1]Those tags file basically contain references to functions/types definition in source code and allow "jump to definition" like functionality in text editors.* source: http://github.com/aloiscochard/codex hackage: http://hackage.haskell.org/package/codex -- *Alois Cochard* http://twitter.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Thu Apr 24 06:35:58 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 23 Apr 2014 23:35:58 -0700 Subject: [Haskell-cafe] ANN: Monad.Reader Issue 23 Message-ID: <1398320767-sup-3466@sabre> I am pleased to announce that Issue 23 of the Monad Reader is now available. http://themonadreader.files.wordpress.com/2014/04/issue23.pdf http://themonadreader.wordpress.com/2014/04/23/issue-23/ Issue 23 consists of the following five articles: * FizzBuzz in Haskell by Embedding a Domain-Specific Language by Maciej P?rog http://themonadreader.files.wordpress.com/2014/04/fizzbuzz.pdf * Supercompilation: Ideas and Methods (+appendix) by Ilya Klyuchnikov and Dimitur Krustev http://themonadreader.files.wordpress.com/2014/04/super-final.pdf * A Haskell sound specification DSL: Ludic support and deep immersion in Nordic technology-supported LARP by Henrik B??rnhielm, Daniel Sundstr?m and Mikael Vejdemo-Johansson http://themonadreader.files.wordpress.com/2014/04/celestria_main.pdf * MFlow, a continuation-based web framework without continuations by Alberto Gomez Corona http://themonadreader.files.wordpress.com/2014/04/mflow.pdf * Practical Type System Benefits by Neil Brown http://themonadreader.files.wordpress.com/2014/04/nccb.pdf This time around, I have individual article files for each (and the supercompilation article has an extra appendix not included in the full issue PDF). Feel free to browse the source files. You can check out the entire repository using Git: git clone https://github.com/ezyang/tmr-issue23.git If you?d like to write something for Issue 24, please get in touch! Cheers, Edward From ezyang at mit.edu Thu Apr 24 20:09:25 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 24 Apr 2014 13:09:25 -0700 Subject: [Haskell-cafe] Monad.Reader #24 call for copy Message-ID: <1398369857-sup-413@sabre> Call for Copy: The Monad.Reader - Issue 24 -------------------------------------------- Whether you're an established academic or have only just started learning Haskell, if you have something to say, please consider writing an article for The Monad.Reader! The submission deadline for Issue 24 will be: **Saturday, July 5, 2014** The Monad.Reader ~~~~~~~~~~~~~~~~ The Monad.Reader is a electronic magazine about all things Haskell. It is less formal than journal, but somehow more enduring than a wiki- page. There have been a wide variety of articles: exciting code fragments, intriguing puzzles, book reviews, tutorials, and even half-baked research ideas. Submission Details ~~~~~~~~~~~~~~~~~~ NEW this issue: for my reviewing sanity, I am setting a soft page limit of fifteen pages. If you would like to write something longer, get in touch, but remember: brevity is the soul of wit. In any case, contact me if you intend to submit something -- the sooner you let me know what you're up to, the better. Please submit articles for the next issue to me by e-mail. Articles should be written according to the guidelines available from http://themonadreader.wordpress.com/contributing/ Please submit your article in PDF, together with any source files you used. The sources will be released together with the magazine under a BSD license. If you would like to submit an article, but have trouble with LaTeX please let me know and we'll work something out. From christian at ponies.io Fri Apr 25 01:37:16 2014 From: christian at ponies.io (Christian Marie) Date: Fri, 25 Apr 2014 11:37:16 +1000 Subject: [Haskell-cafe] [ANN] codex - generate tags file from dependencies In-Reply-To: References: Message-ID: <20140425013716.GA4454@cucumber.iiNet> On Thu, Apr 24, 2014 at 11:54:29PM +0100, Alois Cochard wrote: > Hi, > > Just to let you know that I released a tool which allow to generate a > tags[1] file for a given cabal project using the sources of all the > dependencies of that project. > > `cabal install codex` Slight issue with base 4.6 installed: $ cabal install --reinstall codex Resolving dependencies... cabal: Could not resolve dependencies: trying: codex-0.0.1.1 (user goal) next goal: base (dependency of codex-0.0.1.1) rejecting: base-4.6.0.1/... (conflict: codex => base>=4.7 && It does install fine with the .cabal patched to accept: base >=4.6 && <4.8 > You can simply run `codex update` in one of your cabal project directory > and you'll get a 'codex.tags' file to feed in your favorite text editors. > > It store the source code in the hackage local cache, and it store there as > well the tags file per module (so the tool just aggregate per project). > > I hope it will be useful to other hackers, it's a joy for me in vim when > using unknown libraries. > > Note: This tool actually use `ctags` but that could be easily made > configurable if someone need it, integrating native haskell tagger is an > option too. I personally like using ctags, it's very fast. After generating a tags file with 'codex update', I have a bunch of references to .c and .h files. I can't see ctags being particularly useful for cabal projects but perhaps I'm missing something? I would personally use your tool if it were to provide an aggregate of tag files generated by something like hothasktags. -- Christian Marie - Sparkly Code Princess -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From rustompmody at gmail.com Fri Apr 25 06:31:41 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Fri, 25 Apr 2014 12:01:41 +0530 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: <02C0B25D-C797-4874-938C-2A74131DB605@yandex.ru> References: <02C0B25D-C797-4874-938C-2A74131DB605@yandex.ru> Message-ID: Many and varied answers -- this is sure a vibrant place -- Thanks for all suggestions and pointers -- including negative -- I really wish to know the lay-of-the-land! It will sure take me a while to follow up check and get back -- hope thats ok :-) As of this point haskell seems to be ahead of the competition in embracing unicode. eg python moved to python 3 with a number of backward incompatible changes, the most notable of which is the moving to unicode as the default. However for unicode in python source it still seems people are finding it hard to accept. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmitdase at gmail.com Fri Apr 25 06:32:19 2014 From: jmitdase at gmail.com (Joey Eremondi) Date: Thu, 24 Apr 2014 23:32:19 -0700 (PDT) Subject: [Haskell-cafe] Thoughts on Hakyll vs. Octopress for an experienced Haskeller but HTML newbie Message-ID: <64c42830-5514-4a36-a63e-b4d172dc3416@googlegroups.com> Disclaimer: Cross-posted at http://www.reddit.com/r/haskell/comments/23xgzf/thoughts_on_hakyll_vs_octopress_for_an/ I'm starting a personal website/blog, just the typical thing you see a lot of programmers keeping. I'm looking at using Github Pages, but as I don't want to hand-code everything, I'll be using a static site generator. I'm choosing between Hakyll and Octopress, but I wanted to get some opinions before I put in the effort of learning and installing one. I'll start by saying that I'm comfortable with Monads, EDSLs, and Haskell in general. Conversely, I have next to no HTML/CSS skill. What I'm really wondering is, how much hand-HTML does Hakyll require you to do? In particular: 1. Does Hakyll have any support for visual "themes"? If not, are there libraries/examples of visual layouts I could choose from? 2. Does Hakyll integrate well with Github pages? 3. How hard is it to get things like a Facebook like button, twitter sidebar, comments, etc. working in Hakyll? Is there anything equivalent to Octopress's plugins ? 4. Octopress advertises itself as dealing well with code snippets. Does Hakyll deal well with code within pages? I realize that many of these things will not be built into Hakyll, so cases where it's not built in but there are lots of easy examples to take from are welcome. Reccomendations of one over the other are welcome, but I'm more looking for feedback and knowledge from people who have used Hakyll (and Octopress, though that's more tangential to this subreddit). Thanks! EDIT: Generalized to "comments" instead of just "disqus comments" -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at nand.wakku.to Fri Apr 25 06:34:58 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Fri, 25 Apr 2014 08:34:58 +0200 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: <02C0B25D-C797-4874-938C-2A74131DB605@yandex.ru> Message-ID: <20140425083458.GA9210@nanodesu.talocan.mine.nu> On Fri, 25 Apr 2014 12:01:41 +0530, Rustom Mody wrote: > As of this point haskell seems to be ahead of the competition in embracing > unicode. eg python moved to python 3 with a number of backward > incompatible changes, the most notable of which is the moving to unicode as > the default. However for unicode in python source it still seems people are > finding it hard to accept. FWIW, python's support for Unicode in its standard library is significantly better than Haskell's. Haskell fails on basic functions such as ?toUpper?, ?length? or ?==?. From hoerdegen at funktional.info Fri Apr 25 06:45:35 2014 From: hoerdegen at funktional.info (=?ISO-8859-15?Q?Heinrich_H=F6rdegen?=) Date: Fri, 25 Apr 2014 08:45:35 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting Message-ID: <535A048F.7020107@funktional.info> Dear all, next week, our monthly Munich Haskell Meeting is scheduled for the 29th of April, 19h30 Cafe Puck. If you plan to join, please go to http://www.haskell-munich.de/dates and hit the button. Everybody is welcome! Heinrich From travis.cardwell at extellisys.com Fri Apr 25 06:54:17 2014 From: travis.cardwell at extellisys.com (Travis Cardwell) Date: Fri, 25 Apr 2014 15:54:17 +0900 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: <20140425083458.GA9210@nanodesu.talocan.mine.nu> References: <02C0B25D-C797-4874-938C-2A74131DB605@yandex.ru> <20140425083458.GA9210@nanodesu.talocan.mine.nu> Message-ID: <535A0699.8030207@extellisys.com> On 2014?04?25? 15:34, Niklas Haas wrote: > FWIW, python's support for Unicode in its standard library is > significantly better than Haskell's. Haskell fails on basic functions > such as ?toUpper?, ?length? or ?==?. I have to humbly disagree. Python does indeed have great Unicode support, but using Unicode for everything is not efficient in cases where it is not needed. With Haskell, one can use bytestring [1] and text [2] as necessary to have more control over how content is processed. Both packages are in Haskell Platform, the equivalent of Python's standard library. Cheers, Travis ---- [1] http://hackage.haskell.org/package/bytestring [2] http://hackage.haskell.org/package/text From cma at bitemyapp.com Fri Apr 25 07:25:17 2014 From: cma at bitemyapp.com (Christopher Allen) Date: Fri, 25 Apr 2014 02:25:17 -0500 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: <535A0699.8030207@extellisys.com> References: <02C0B25D-C797-4874-938C-2A74131DB605@yandex.ru> <20140425083458.GA9210@nanodesu.talocan.mine.nu> <535A0699.8030207@extellisys.com> Message-ID: I'm going to disagree for a different reason. The transition to Python 3 improved unicode support in some respects, but utterly gutted the previously excellent codec support. Now you can't really handle arbitrary source/destination encodings of text without treating everything as if they were bytes. Really bad. On Fri, Apr 25, 2014 at 1:54 AM, Travis Cardwell < travis.cardwell at extellisys.com> wrote: > On 2014?04?25? 15:34, Niklas Haas wrote: > > FWIW, python's support for Unicode in its standard library is > > significantly better than Haskell's. Haskell fails on basic functions > > such as ?toUpper?, ?length? or ?==?. > > I have to humbly disagree. Python does indeed have great Unicode support, > but using Unicode for everything is not efficient in cases where it is not > needed. With Haskell, one can use bytestring [1] and text [2] as > necessary to have more control over how content is processed. Both > packages are in Haskell Platform, the equivalent of Python's standard > library. > > Cheers, > > Travis > > ---- > > [1] http://hackage.haskell.org/package/bytestring > [2] http://hackage.haskell.org/package/text > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis.cardwell at extellisys.com Fri Apr 25 08:24:02 2014 From: travis.cardwell at extellisys.com (Travis Cardwell) Date: Fri, 25 Apr 2014 17:24:02 +0900 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: <02C0B25D-C797-4874-938C-2A74131DB605@yandex.ru> <20140425083458.GA9210@nanodesu.talocan.mine.nu> <535A0699.8030207@extellisys.com> Message-ID: <535A1BA2.6000806@extellisys.com> On 2014?04?25? 16:25, Christopher Allen wrote: > I'm going to disagree for a different reason. The transition to Python 3 > improved unicode support in some respects, but utterly gutted the > previously excellent codec support. Now you can't really handle arbitrary > source/destination encodings of text without treating everything as if they > were bytes. Really bad. Perhaps I am misunderstanding, but, from my experience, Python 3 still has excellent codec support: https://docs.python.org/3.4/library/codecs.html When reading from a file, the source encoding can be passed to the `open` function so that it handles transcoding for you. When writing to a file, the destination encoding can similarly be specified to `open`. When dealing with other sources/destinations, data must be read/written as bytes, but content can be encoded/decoded as necessary using the functions in the codecs module. Haskell has excellent codec support thanks to ICU: http://hackage.haskell.org/package/text-icu The contents of the `Data.Text.ICU.Convert` module can be used to convert between codecs. For reference, here is a list of supported codecs: http://demo.icu-project.org/icu-bin/convexp Cheers, Travis From cma at bitemyapp.com Fri Apr 25 08:37:42 2014 From: cma at bitemyapp.com (Christopher Allen) Date: Fri, 25 Apr 2014 03:37:42 -0500 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: <535A1BA2.6000806@extellisys.com> References: <02C0B25D-C797-4874-938C-2A74131DB605@yandex.ru> <20140425083458.GA9210@nanodesu.talocan.mine.nu> <535A0699.8030207@extellisys.com> <535A1BA2.6000806@extellisys.com> Message-ID: http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ On Fri, Apr 25, 2014 at 3:24 AM, Travis Cardwell < travis.cardwell at extellisys.com> wrote: > On 2014?04?25? 16:25, Christopher Allen wrote: > > I'm going to disagree for a different reason. The transition to Python 3 > > improved unicode support in some respects, but utterly gutted the > > previously excellent codec support. Now you can't really handle arbitrary > > source/destination encodings of text without treating everything as if > they > > were bytes. Really bad. > > Perhaps I am misunderstanding, but, from my experience, Python 3 still has > excellent codec support: > > https://docs.python.org/3.4/library/codecs.html > > When reading from a file, the source encoding can be passed to the `open` > function so that it handles transcoding for you. When writing to a file, > the destination encoding can similarly be specified to `open`. When > dealing with other sources/destinations, data must be read/written as > bytes, but content can be encoded/decoded as necessary using the functions > in the codecs module. > > Haskell has excellent codec support thanks to ICU: > > http://hackage.haskell.org/package/text-icu > > The contents of the `Data.Text.ICU.Convert` module can be used to convert > between codecs. For reference, here is a list of supported codecs: > > http://demo.icu-project.org/icu-bin/convexp > > Cheers, > > Travis > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.rudnick at gmail.com Fri Apr 25 08:49:04 2014 From: nick.rudnick at gmail.com (Nick Rudnick) Date: Fri, 25 Apr 2014 10:49:04 +0200 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: Thanks for the hint =) I ever wondered about some special characters on the standard keyboard, ? -- i.e. [?][^] ? ? ? ? --e.g. [Alt Gr][R] ? -- e.g. [Alt Gr][,] ? -- e.g. [Alt Gr][,] ? -- e.g. [Alt Gr][-], though optically ambiguous with -, a candidate for *unary minus*, which I think ever has been considered to be realized a little unsatisfactorily ? e.g. [Alt Gr][6], also a great candidate for unary use now I see they are usable, too, which to me is great news. Since some time, I began using chars like ?, ?, ?, ?, ?, ?, ?, etc., which, easily accessible on a Linux keyboard, have more than cosmetic utility to me; with find / replace it prevents you from the usual trouble when working ? but that with the special chars above is a pleasing discovery. :-) I ever wondered for the reason that in Haskell function composition is not declared by (?) instead of (.), which (a) interferes with other uses of the period and (b) looks less similar to the actual symbol. It also reminds me of a very beautiful feature (Emacs) haskell-mode had some years ago; it was able to display special characters in wider characters (maybe using a special Emacs font??) ? does anybody know what I am speaking about, too? Unfortunately, this feature wasn't continued while frankly, "?" as in recent use to me slightly hurts the eye a little everywhere it's seen in code (sorry, "?"... ;-), while back then, in Emacs there where BEAUTIFUL arrows in double width and gorgeous lambdas. Cheers, Nick 2014-04-24 19:15 GMT+02:00 Rustom Mody : > I'm mighty pleased to note that the following is valid Haskell code! > > Do others find this useful/appealing? > Any possibilities on making the commented out parts work? > > [Pragmatics about typing this at the same speed and facility as we do with > Ascii is a separate and (IMHO) solvable problem though its not the case at > the moment] > > > -------------------- > import qualified Data.Set as Set > -- Experimenting with Unicode in Haskell source > > -- Numbers > x ? y = x /= y > x ? y = x <= y > x ? y = x >= y > x ? y = divMod x y > x ? y = x ^ y > > x ? y = x * y -- readability hmmm !!! > ? = pi > > -- ? x = floor x > -- ? x = ceiling x > > -- Lists > xs ? ys = xs ++ ys > > -- Bools > x ? y = x && y > x ? y = y || y > -- ?x = not x > > > -- Sets > > x ? s = x `Set.member` s -- or keep ? for list elem? > s ? t = s `Set.union` t > s ? t = s `Set.intersection` t > s ? t = s `Set.isSubsetOf` t > s ? t = s `Set.isProperSubsetOf` t > s ? t = not (s `Set.isSubsetOf` t) > -- ? = Set.null > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis.cardwell at extellisys.com Fri Apr 25 10:43:04 2014 From: travis.cardwell at extellisys.com (Travis Cardwell) Date: Fri, 25 Apr 2014 19:43:04 +0900 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: <02C0B25D-C797-4874-938C-2A74131DB605@yandex.ru> <20140425083458.GA9210@nanodesu.talocan.mine.nu> <535A0699.8030207@extellisys.com> <535A1BA2.6000806@extellisys.com> Message-ID: <535A3C38.5060107@extellisys.com> On 2014?04?25? 17:37, Christopher Allen wrote: > http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/ Much of this article relates to what I wrote in my first reply: On 2014?04?25? 15:54, Travis Cardwell wrote: > Python does indeed have great Unicode support, but using Unicode for > everything is not efficient in cases where it is not needed. Armin says that Python 3 is not appropriate for real-world applications due to this issue. He wants functionality in the standard library that processes bytes directly (as in Python 2). The problem is that processing bytes directly is not safe. The `urlparse` example is a good one: naively parsing URLs as bytes can lead to major security vulnerabilities. While Armin would not parse things naively, people with less experience with encodings are less likely to make mistakes in Python 3, at the expense of performance. I think that Haskell's support for byte-strings and Unicode strings (as well as many other encodings via ICU transcoding) is quite nice because it supports doing whatever needs to be done while giving the programmer the control necessary to implement real-world applications. Though one can still manage to shoot themselves in the foot, Haskell's types make the confusing subject of encoding more approachable and significantly reduces chance of error, IMHO. The article also talks about how Python's codec system is used for non-character encodings (such as zlib!) in addition to character encodings. I do not think that it is particularly good design. Attempts to clean up the design have resulted in compatibility issues with old code: type errors! As a Haskell programmer, I am clearly biased, but I think that the design of such modules could be significantly improved by using static types and type classes! ;) Cheers, Travis From chriswarbo at googlemail.com Fri Apr 25 13:02:38 2014 From: chriswarbo at googlemail.com (Chris Warburton) Date: Fri, 25 Apr 2014 14:02:38 +0100 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: (Rustom Mody's message of "Thu, 24 Apr 2014 23:06:20 +0530") References: Message-ID: <86wqedmuj5.fsf@gmail.com> Rustom Mody writes: > As for APL, it failed for various reasons eg > - mixing up assembly language (straight line code with gotos) with > functional idioms > - the character set was a major hurdle in the 60s. Thats not an issue today > when most OSes/editors are unicode compliant I know it's bikeshedding, but I think Agda and Idris are more relevant to Haskell than APL, since their semantics are closer (and they're both implemented in Haskell). Agda makes extensive (ab)use of Unicode identifiers, eg. https://github.com/agda/agda-stdlib/blob/master/src/Algebra.agda Idris specifically avoids Unicode identifiers, for reasons outlined at https://github.com/idris-lang/Idris-dev/wiki/Unofficial-FAQ Personally I prefer working in Idris to Agda, since the Unicode puts me off. I usually resort to copy/pasting symbols, which is tedious compared to typing names. Cheers, Chris From rustompmody at gmail.com Fri Apr 25 13:30:34 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Fri, 25 Apr 2014 19:00:34 +0530 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: <86wqedmuj5.fsf@gmail.com> References: <86wqedmuj5.fsf@gmail.com> Message-ID: On Fri, Apr 25, 2014 at 6:32 PM, Chris Warburton wrote: > Rustom Mody writes: > > > As for APL, it failed for various reasons eg > > - mixing up assembly language (straight line code with gotos) with > > functional idioms > > - the character set was a major hurdle in the 60s. Thats not an issue > today > > when most OSes/editors are unicode compliant > > I know it's bikeshedding, but I think Agda and Idris are more relevant > to Haskell than APL, since their semantics are closer (and they're both > implemented in Haskell). > > Agda makes extensive (ab)use of Unicode identifiers, > eg. https://github.com/agda/agda-stdlib/blob/master/src/Algebra.agda > > Idris specifically avoids Unicode identifiers, for reasons outlined at > https://github.com/idris-lang/Idris-dev/wiki/Unofficial-FAQ > > Personally I prefer working in Idris to Agda, since the Unicode puts me > off. I usually resort to copy/pasting symbols, which is tedious compared > to typing names. > > Cheers, > Chris > Thanks Chris for that evaluation. Not bike-shedding as far as I can see. Yes input-ing things by some GUI-picker or copy-pasting etc would quickly become a major pain. I believe that there are roughly these 5 levels to this with per-char cost decreasing and fixed cost increasing as we go down 1. GUI-picker (IBUS etc) copy-pasting from the web etc -- ok for arm-chair discussions; ridiculous for serious development 2. Editor based input methods eg tex input-method in emacs 3. Window-system (X/MS etc) input methods 4. OS-based input methods 5. Special purpose hardware-keyboards I believe 3 makes for a particularly good fixed/variable cost balance point eg in X-windows if you run this command $ setxkbmap -layout "us,gr" -option "grp:switch" then typing abcdefg with right-alt depressed, gives: ??????? For those who prefer a more moded approach (vi-users?) here is $ setxkbmap -option "grp:switch,grp:alt_shift_toggle,grp_led:scroll" -layout "us,gr" This makes the Shift-Alt chord switch in and out (ie toggle) greek keyboard with the scroll-lock light as indicator All this is clearly just an analogy; what we need is not a greek keyboard but a keyboard mapping analogous to gr(eek). Try s/gr/apl in the commands above for apl which, while distant from haskell gives a taste for what a *programmer* can use/make. regards Rusi -------------- next part -------------- An HTML attachment was scrubbed... URL: From hsyl20 at gmail.com Fri Apr 25 13:49:13 2014 From: hsyl20 at gmail.com (Sylvain Henry) Date: Fri, 25 Apr 2014 15:49:13 +0200 Subject: [Haskell-cafe] Haddock CSS Message-ID: Hi, I have quickly hacked a new CSS for haddock based on ocean.css (see attached file). It has a fixed maximal width and is a little bit lighter. To try it with cabal, use: > cabal haddock --css=ocean2.css [--hyperlink-source] Feel free to improve it, I am not that good at web design. -Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean2.css Type: text/css Size: 9120 bytes Desc: not available URL: From tekul.hs at gmail.com Fri Apr 25 13:55:04 2014 From: tekul.hs at gmail.com (Luke Taylor) Date: Fri, 25 Apr 2014 14:55:04 +0100 Subject: [Haskell-cafe] [ANN] codex - generate tags file from dependencies In-Reply-To: References: Message-ID: <535A6938.6000403@gmail.com> On 24/04/2014 23:54, Alois Cochard wrote: > Hi, > > Just to let you know that I released a tool which allow to generate a > tags[1] file for a given cabal project using the sources of all the > dependencies of that project. > Hi, It sounds kind of similar to "haskdogs" (https://github.com/ierton/haskdogs), which I use now. Is there something more sophisticated in there which would make it worth switching :) ? Luke. From mystic.satvik at gmail.com Fri Apr 25 14:54:43 2014 From: mystic.satvik at gmail.com (satvik chauhan) Date: Fri, 25 Apr 2014 20:24:43 +0530 Subject: [Haskell-cafe] Haddock CSS In-Reply-To: References: Message-ID: It would be better if you could put it on github. PS: "I am not that good at web design" <== being too humble here. It looks awesome :). On Fri, Apr 25, 2014 at 7:19 PM, Sylvain Henry wrote: > Hi, > > I have quickly hacked a new CSS for haddock based on ocean.css (see > attached file). > > It has a fixed maximal width and is a little bit lighter. To try it with > cabal, use: > > cabal haddock --css=ocean2.css [--hyperlink-source] > > Feel free to improve it, I am not that good at web design. > > -Sylvain > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hsyl20 at gmail.com Fri Apr 25 15:11:08 2014 From: hsyl20 at gmail.com (Sylvain Henry) Date: Fri, 25 Apr 2014 17:11:08 +0200 Subject: [Haskell-cafe] Haddock CSS In-Reply-To: References: Message-ID: Done: https://github.com/hsyl20/haddock-css Thank you :) -Sylvain 2014-04-25 16:54 GMT+02:00 satvik chauhan : > It would be better if you could put it on github. > > PS: "I am not that good at web design" <== being too humble here. It > looks awesome :). > > > On Fri, Apr 25, 2014 at 7:19 PM, Sylvain Henry wrote: > >> Hi, >> >> I have quickly hacked a new CSS for haddock based on ocean.css (see >> attached file). >> >> It has a fixed maximal width and is a little bit lighter. To try it with >> cabal, use: >> > cabal haddock --css=ocean2.css [--hyperlink-source] >> >> Feel free to improve it, I am not that good at web design. >> >> -Sylvain >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Fri Apr 25 20:58:14 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Fri, 25 Apr 2014 21:58:14 +0100 Subject: [Haskell-cafe] [ANN] codex - generate tags file from dependencies In-Reply-To: <20140425013716.GA4454@cucumber.iiNet> References: <20140425013716.GA4454@cucumber.iiNet> Message-ID: On 25 April 2014 02:37, Christian Marie wrote: > On Thu, Apr 24, 2014 at 11:54:29PM +0100, Alois Cochard wrote: > > Hi, > > > > Just to let you know that I released a tool which allow to generate a > > tags[1] file for a given cabal project using the sources of all the > > dependencies of that project. > > > > `cabal install codex` > > Slight issue with base 4.6 installed: > > $ cabal install --reinstall codex > Resolving dependencies... > cabal: Could not resolve dependencies: > trying: codex-0.0.1.1 (user goal) > next goal: base (dependency of codex-0.0.1.1) > rejecting: base-4.6.0.1/... (conflict: codex => base>=4.7 && > > It does install fine with the .cabal patched to accept: > > base >=4.6 && <4.8 > > Oh sorry for that! I just released a new version with a lower bound constrain at 4.6 > > You can simply run `codex update` in one of your cabal project directory > > and you'll get a 'codex.tags' file to feed in your favorite text editors. > > > > It store the source code in the hackage local cache, and it store there > as > > well the tags file per module (so the tool just aggregate per project). > > > > I hope it will be useful to other hackers, it's a joy for me in vim when > > using unknown libraries. > > > > Note: This tool actually use `ctags` but that could be easily made > > configurable if someone need it, integrating native haskell tagger is an > > option too. I personally like using ctags, it's very fast. > > After generating a tags file with 'codex update', I have a bunch of > references > to .c and .h files. I can't see ctags being particularly useful for cabal > projects but perhaps I'm missing something? > > I would personally use your tool if it were to provide an aggregate of tag > files generated by something like hothasktags. > > This is is because you have to configure your ctags to deal with haskell (and also ignore some stuff from cabal), I wanted to explain that part but I completely forgot... sorry. It's actually quite simple, I have just updated the README with an example ~/.ctags configuration: https://github.com/aloiscochard/codex Be sure to delete all "tags" file in your hackage (as they were generated with a miss-configured ctags) before re-running the tool, I'll add a command to do that directly from the tool, but for now you can just: "find ~/.cabal/packages/hackage.haskell.org -name "tags" -exec rm {} \;" About `hothasktags`, I'm not sure how fast it is and how big is the improvement in term of quality. Maybe you could share with us which differences you see? Honestly I don't care much about having to disambiguate manually (as i did that with other languages) and I don't think there is others difference vs using a haskell tagger, but I understand some might prefer a native tagger in which case it should be pretty trivial to plug hothasktags on any other tagger on it. Using a tool which work cross language is actually very powerful, for example I have a githook which tag the source of the project itself [1] ... it work for all my git based project, doesn't matter which language. I hope that help [1] https://github.com/aloiscochard/configurations/tree/master/.git_template/hooks > -- > Christian Marie - Sparkly Code Princess > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- *Alois Cochard* http://aloiscochard.blogspot.com http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Fri Apr 25 21:14:08 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Fri, 25 Apr 2014 22:14:08 +0100 Subject: [Haskell-cafe] [ANN] codex - generate tags file from dependencies In-Reply-To: <535A6938.6000403@gmail.com> References: <535A6938.6000403@gmail.com> Message-ID: On 25 April 2014 14:55, Luke Taylor wrote: > On 24/04/2014 23:54, Alois Cochard wrote: > >> Hi, >> >> Just to let you know that I released a tool which allow to generate a >> tags[1] file for a given cabal project using the sources of all the >> dependencies of that project. >> >> > Hi, > > It sounds kind of similar to "haskdogs" (https://github.com/ierton/ > haskdogs), which I use now. Is there something more sophisticated in > there which would make it worth switching :) ? > > Luke. > Hi Luke, I don't think there is much differences in term of functionality, but there is clearly lot of difference in term of design (which you might not care at all as everything work fine for you!). Basically haskdogs is a shell script ported to haskell, so it rely on command line tools. OTHO codex use Cabal as a library and and deal with hackage directly... the only external command it use is `ctags`. If I were to integrate hasktags, I would do it as a library which would make possible to remove completely the platform dependency (basically atm it's only linux/macos, but then it could work on windows). > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- *Alois Cochard* http://aloiscochard.blogspot.com http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Fri Apr 25 23:14:18 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 25 Apr 2014 16:14:18 -0700 Subject: [Haskell-cafe] ANN: Cryptol, a DSL for cryptography Message-ID: Hello, Galois is happy to announce the first open source release of Cryptol! Please visit Cryptol's website for documentation, source code, and information on how to contribute: http://www.cryptol.net/ Cryptol is a domain-specific language for specifying cryptographic algorithms. A Cryptol implementation of an algorithm resembles its mathematical specification more closely than an implementation in a general purpose language. Furthermore, Cryptol shares lots of similarities with Haskell so, hopefully, Haskell programmers should be able to start writing Cryptol programs fairly quickly. Last, but not least, we are always interested in contributors! So, if you think of a cool new feature, or discover an annoying bug, please don't be afraid to have a look at the source code. At present, we think that the easiest way to manage contributions is by using github's fork model, so just sand us a pull request. Also, if you have questions about the source code or the Cryptol language, please feel free to drop me an e-mail or a message on git-hub (I am user "yav"). Happy hacking, -Iavor and the Cryptol team -------------- next part -------------- An HTML attachment was scrubbed... URL: From ducis_cn at 126.com Sat Apr 26 13:56:05 2014 From: ducis_cn at 126.com (ducis) Date: Sat, 26 Apr 2014 21:56:05 +0800 (CST) Subject: [Haskell-cafe] How to extract current bindings from GHCi ? In-Reply-To: References: Message-ID: <2d39ae17.1c530.1459e524d9a.Coremail.ducis_cn@126.com> Currently I need to manually find the last binding of a value if I want to copy-paste it into an editor. With ':show bindings' I get the result of computation. Say, if I had input 'let a = 1' and 'let b = a+2' I would only get either 'b = _' or 'b = 3' with ':show bindings', while I actually need 'b = a+2'. Are there any externel tools that can help? At 2014-04-26 20:00:04,haskell-cafe-request at haskell.org wrote: >Send Haskell-Cafe mailing list submissions to > haskell-cafe at haskell.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/haskell-cafe >or, via email, send a message with subject or body 'help' to > haskell-cafe-request at haskell.org > >You can reach the person managing the list at > haskell-cafe-owner at haskell.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Haskell-Cafe digest..." > > >Today's Topics: > > 1. Re: Unicode Haskell source -- Yippie! (Chris Warburton) > 2. Re: Unicode Haskell source -- Yippie! (Rustom Mody) > 3. Haddock CSS (Sylvain Henry) > 4. Re: [ANN] codex - generate tags file from dependencies > (Luke Taylor) > 5. Re: Haddock CSS (satvik chauhan) > 6. Re: Haddock CSS (Sylvain Henry) > 7. Re: [ANN] codex - generate tags file from dependencies > (Alois Cochard) > 8. Re: [ANN] codex - generate tags file from dependencies > (Alois Cochard) > 9. ANN: Cryptol, a DSL for cryptography (Iavor Diatchki) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 25 Apr 2014 14:02:38 +0100 >From: Chris Warburton >To: Rustom Mody >Cc: Haskell Cafe >Subject: Re: [Haskell-cafe] Unicode Haskell source -- Yippie! >Message-ID: <86wqedmuj5.fsf at gmail.com> >Content-Type: text/plain > >Rustom Mody writes: > >> As for APL, it failed for various reasons eg >> - mixing up assembly language (straight line code with gotos) with >> functional idioms >> - the character set was a major hurdle in the 60s. Thats not an issue today >> when most OSes/editors are unicode compliant > >I know it's bikeshedding, but I think Agda and Idris are more relevant >to Haskell than APL, since their semantics are closer (and they're both >implemented in Haskell). > >Agda makes extensive (ab)use of Unicode identifiers, >eg. https://github.com/agda/agda-stdlib/blob/master/src/Algebra.agda > >Idris specifically avoids Unicode identifiers, for reasons outlined at >https://github.com/idris-lang/Idris-dev/wiki/Unofficial-FAQ > >Personally I prefer working in Idris to Agda, since the Unicode puts me >off. I usually resort to copy/pasting symbols, which is tedious compared >to typing names. > >Cheers, >Chris > > >------------------------------ > >Message: 2 >Date: Fri, 25 Apr 2014 19:00:34 +0530 >From: Rustom Mody >To: Chris Warburton >Cc: Haskell Cafe >Subject: Re: [Haskell-cafe] Unicode Haskell source -- Yippie! >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >On Fri, Apr 25, 2014 at 6:32 PM, Chris Warburton >wrote: > >> Rustom Mody writes: >> >> > As for APL, it failed for various reasons eg >> > - mixing up assembly language (straight line code with gotos) with >> > functional idioms >> > - the character set was a major hurdle in the 60s. Thats not an issue >> today >> > when most OSes/editors are unicode compliant >> >> I know it's bikeshedding, but I think Agda and Idris are more relevant >> to Haskell than APL, since their semantics are closer (and they're both >> implemented in Haskell). >> >> Agda makes extensive (ab)use of Unicode identifiers, >> eg. https://github.com/agda/agda-stdlib/blob/master/src/Algebra.agda >> >> Idris specifically avoids Unicode identifiers, for reasons outlined at >> https://github.com/idris-lang/Idris-dev/wiki/Unofficial-FAQ >> >> Personally I prefer working in Idris to Agda, since the Unicode puts me >> off. I usually resort to copy/pasting symbols, which is tedious compared >> to typing names. >> >> Cheers, >> Chris >> > >Thanks Chris for that evaluation. Not bike-shedding as far as I can see. > >Yes input-ing things by some GUI-picker or copy-pasting etc would quickly >become a major pain. >I believe that there are roughly these 5 levels to this with >per-char cost decreasing and fixed cost increasing as we go down > >1. GUI-picker (IBUS etc) copy-pasting from the web etc -- ok for arm-chair >discussions; ridiculous for serious development >2. Editor based input methods eg tex input-method in emacs >3. Window-system (X/MS etc) input methods >4. OS-based input methods >5. Special purpose hardware-keyboards > >I believe 3 makes for a particularly good fixed/variable cost balance point > >eg in X-windows if you run this command >$ setxkbmap -layout "us,gr" -option "grp:switch" >then typing >abcdefg >with right-alt depressed, gives: >??????? > >For those who prefer a more moded approach (vi-users?) here is >$ setxkbmap -option "grp:switch,grp:alt_shift_toggle,grp_led:scroll" >-layout "us,gr" > >This makes the Shift-Alt chord switch in and out (ie toggle) greek keyboard >with the scroll-lock light as indicator > >All this is clearly just an analogy; what we need is not a greek keyboard >but a keyboard mapping analogous to gr(eek). Try s/gr/apl in the commands >above for apl which, while distant from haskell gives a taste for what a >*programmer* can use/make. > >regards >Rusi >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: > >------------------------------ > >Message: 3 >Date: Fri, 25 Apr 2014 15:49:13 +0200 >From: Sylvain Henry >To: haskell-cafe at haskell.org >Subject: [Haskell-cafe] Haddock CSS >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >Hi, > >I have quickly hacked a new CSS for haddock based on ocean.css (see >attached file). > >It has a fixed maximal width and is a little bit lighter. To try it with >cabal, use: >> cabal haddock --css=ocean2.css [--hyperlink-source] > >Feel free to improve it, I am not that good at web design. > >-Sylvain >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: >-------------- next part -------------- >A non-text attachment was scrubbed... >Name: ocean2.css >Type: text/css >Size: 9120 bytes >Desc: not available >URL: > >------------------------------ > >Message: 4 >Date: Fri, 25 Apr 2014 14:55:04 +0100 >From: Luke Taylor >To: haskell-cafe at haskell.org >Subject: Re: [Haskell-cafe] [ANN] codex - generate tags file from > dependencies >Message-ID: <535A6938.6000403 at gmail.com> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >On 24/04/2014 23:54, Alois Cochard wrote: >> Hi, >> >> Just to let you know that I released a tool which allow to generate a >> tags[1] file for a given cabal project using the sources of all the >> dependencies of that project. >> > >Hi, > >It sounds kind of similar to "haskdogs" >(https://github.com/ierton/haskdogs), which I use now. Is there >something more sophisticated in there which would make it worth >switching :) ? > >Luke. > > > >------------------------------ > >Message: 5 >Date: Fri, 25 Apr 2014 20:24:43 +0530 >From: satvik chauhan >To: Sylvain Henry >Cc: haskell-cafe >Subject: Re: [Haskell-cafe] Haddock CSS >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >It would be better if you could put it on github. > >PS: "I am not that good at web design" <== being too humble here. It looks >awesome :). > > >On Fri, Apr 25, 2014 at 7:19 PM, Sylvain Henry wrote: > >> Hi, >> >> I have quickly hacked a new CSS for haddock based on ocean.css (see >> attached file). >> >> It has a fixed maximal width and is a little bit lighter. To try it with >> cabal, use: >> > cabal haddock --css=ocean2.css [--hyperlink-source] >> >> Feel free to improve it, I am not that good at web design. >> >> -Sylvain >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: > >------------------------------ > >Message: 6 >Date: Fri, 25 Apr 2014 17:11:08 +0200 >From: Sylvain Henry >To: satvik chauhan >Cc: haskell-cafe >Subject: Re: [Haskell-cafe] Haddock CSS >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >Done: https://github.com/hsyl20/haddock-css > >Thank you :) > >-Sylvain > > >2014-04-25 16:54 GMT+02:00 satvik chauhan : > >> It would be better if you could put it on github. >> >> PS: "I am not that good at web design" <== being too humble here. It >> looks awesome :). >> >> >> On Fri, Apr 25, 2014 at 7:19 PM, Sylvain Henry wrote: >> >>> Hi, >>> >>> I have quickly hacked a new CSS for haddock based on ocean.css (see >>> attached file). >>> >>> It has a fixed maximal width and is a little bit lighter. To try it with >>> cabal, use: >>> > cabal haddock --css=ocean2.css [--hyperlink-source] >>> >>> Feel free to improve it, I am not that good at web design. >>> >>> -Sylvain >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: > >------------------------------ > >Message: 7 >Date: Fri, 25 Apr 2014 21:58:14 +0100 >From: Alois Cochard >To: Christian Marie >Cc: Haskell Cafe >Subject: Re: [Haskell-cafe] [ANN] codex - generate tags file from > dependencies >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >On 25 April 2014 02:37, Christian Marie wrote: > >> On Thu, Apr 24, 2014 at 11:54:29PM +0100, Alois Cochard wrote: >> > Hi, >> > >> > Just to let you know that I released a tool which allow to generate a >> > tags[1] file for a given cabal project using the sources of all the >> > dependencies of that project. >> > >> > `cabal install codex` >> >> Slight issue with base 4.6 installed: >> >> $ cabal install --reinstall codex >> Resolving dependencies... >> cabal: Could not resolve dependencies: >> trying: codex-0.0.1.1 (user goal) >> next goal: base (dependency of codex-0.0.1.1) >> rejecting: base-4.6.0.1/... (conflict: codex => base>=4.7 && >> >> It does install fine with the .cabal patched to accept: >> >> base >=4.6 && <4.8 >> >> >Oh sorry for that! >I just released a new version with a lower bound constrain at 4.6 > > >> > You can simply run `codex update` in one of your cabal project directory >> > and you'll get a 'codex.tags' file to feed in your favorite text editors. >> > >> > It store the source code in the hackage local cache, and it store there >> as >> > well the tags file per module (so the tool just aggregate per project). >> > >> > I hope it will be useful to other hackers, it's a joy for me in vim when >> > using unknown libraries. >> > >> > Note: This tool actually use `ctags` but that could be easily made >> > configurable if someone need it, integrating native haskell tagger is an >> > option too. I personally like using ctags, it's very fast. >> >> After generating a tags file with 'codex update', I have a bunch of >> references >> to .c and .h files. I can't see ctags being particularly useful for cabal >> projects but perhaps I'm missing something? >> >> I would personally use your tool if it were to provide an aggregate of tag >> files generated by something like hothasktags. >> >> >This is is because you have to configure your ctags to deal with haskell >(and also ignore some stuff from cabal), I wanted to explain that part but >I completely forgot... sorry. > >It's actually quite simple, I have just updated the README with an example >~/.ctags configuration: >https://github.com/aloiscochard/codex > >Be sure to delete all "tags" file in your hackage (as they were generated >with a miss-configured ctags) before re-running the tool, I'll add a >command to do that directly from the tool, but for now you can just: >"find ~/.cabal/packages/hackage.haskell.org -name "tags" -exec rm {} \;" > >About `hothasktags`, I'm not sure how fast it is and how big is the >improvement in term of quality. Maybe you could share with us which >differences you see? > >Honestly I don't care much about having to disambiguate manually (as i did >that with other languages) and I don't think there is others difference vs >using a haskell tagger, but I understand some might prefer a native tagger >in which case it should be pretty trivial to plug hothasktags on any other >tagger on it. > >Using a tool which work cross language is actually very powerful, for >example I have a githook which tag the source of the project itself [1] ... >it work for all my git based project, doesn't matter which language. > >I hope that help > >[1] >https://github.com/aloiscochard/configurations/tree/master/.git_template/hooks > > >> -- >> Christian Marie - Sparkly Code Princess >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > >-- >*Alois Cochard* >http://aloiscochard.blogspot.com >http://twitter.com/aloiscochard >http://github.com/aloiscochard >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: > >------------------------------ > >Message: 8 >Date: Fri, 25 Apr 2014 22:14:08 +0100 >From: Alois Cochard >To: Luke Taylor >Cc: Haskell Cafe >Subject: Re: [Haskell-cafe] [ANN] codex - generate tags file from > dependencies >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >On 25 April 2014 14:55, Luke Taylor wrote: > >> On 24/04/2014 23:54, Alois Cochard wrote: >> >>> Hi, >>> >>> Just to let you know that I released a tool which allow to generate a >>> tags[1] file for a given cabal project using the sources of all the >>> dependencies of that project. >>> >>> >> Hi, >> >> It sounds kind of similar to "haskdogs" (https://github.com/ierton/ >> haskdogs), which I use now. Is there something more sophisticated in >> there which would make it worth switching :) ? >> >> Luke. >> > >Hi Luke, > >I don't think there is much differences in term of functionality, but there >is clearly lot of difference in term of design (which you might not care at >all as everything work fine for you!). >Basically haskdogs is a shell script ported to haskell, so it rely on >command line tools. OTHO codex use Cabal as a library and and deal with >hackage directly... the only external command it use is `ctags`. > >If I were to integrate hasktags, I would do it as a library which would >make possible to remove completely the platform dependency (basically atm >it's only linux/macos, but then it could work on windows). > > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > >-- >*Alois Cochard* >http://aloiscochard.blogspot.com >http://twitter.com/aloiscochard >http://github.com/aloiscochard >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: > >------------------------------ > >Message: 9 >Date: Fri, 25 Apr 2014 16:14:18 -0700 >From: Iavor Diatchki >To: Haskell Cafe >Subject: [Haskell-cafe] ANN: Cryptol, a DSL for cryptography >Message-ID: > >Content-Type: text/plain; charset="utf-8" > >Hello, > >Galois is happy to announce the first open source release of Cryptol! > Please visit Cryptol's website for documentation, source code, and >information on how to contribute: > >http://www.cryptol.net/ > >Cryptol is a domain-specific language for specifying cryptographic >algorithms. A Cryptol implementation of an algorithm resembles its >mathematical specification more closely than an implementation in a general >purpose language. Furthermore, Cryptol shares lots of similarities with >Haskell so, hopefully, Haskell programmers should be able to start writing >Cryptol programs fairly quickly. > >Last, but not least, we are always interested in contributors! So, if you >think of a cool new feature, or discover an annoying bug, please don't be >afraid to have a look at the source code. At present, we think that the >easiest way to manage contributions is by using github's fork model, so >just sand us a pull request. > >Also, if you have questions about the source code or the Cryptol language, >please feel free to drop me an e-mail or a message on git-hub (I am user >"yav"). > >Happy hacking, >-Iavor and the Cryptol team >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe at haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe > > >------------------------------ > >End of Haskell-Cafe Digest, Vol 128, Issue 46 >********************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsf at seereason.com Sat Apr 26 15:58:40 2014 From: dsf at seereason.com (David Fox) Date: Sat, 26 Apr 2014 08:58:40 -0700 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: On Thu, Apr 24, 2014 at 10:27 AM, Kyle Murphy wrote: > It's an interesting feature, and nice if you want that sort of thing, but > not something I'd personally want to see as the default. Deviating from the > standard ASCII set of characters is just too much of a hurdle to usability > of the language. > On the other hand, maybe if its good enough for the entire field of Mathematics since forever there might be some benefit in it for us. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Sat Apr 26 16:46:36 2014 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 26 Apr 2014 18:46:36 +0200 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: On 2014-04-26 17:58, David Fox wrote: > On Thu, Apr 24, 2014 at 10:27 AM, Kyle Murphy wrote: > >> It's an interesting feature, and nice if you want that sort of thing, but >> not something I'd personally want to see as the default. Deviating from the >> standard ASCII set of characters is just too much of a hurdle to usability >> of the language. >> > > On the other hand, maybe if its good enough for the entire field of > Mathematics since forever there might be some benefit in it for us. > Typing into a computer != Handwriting (in various significant ways). Most of mathematics notation predates computers/typewriters. Just compare writing a formula by hand and typing the same formula in (La)TeX. Regards, From dbrumley at forallsecure.com Sat Apr 26 17:01:42 2014 From: dbrumley at forallsecure.com (David Brumley) Date: Sat, 26 Apr 2014 13:01:42 -0400 Subject: [Haskell-cafe] Job: Automatic Exploit Generation developer Message-ID: Hi, ForAllSecure is a small startup bent on checking the world's software for exploitable bugs. We have two open positions, posted at http://jobs.forallsecure.com/ 1) Performing program analysis on binary (x86) code. Our current code base is in OCaml. The product automatically finds vulnerabilities, and generate exploits to prove which ones are exploitable. 2) Automatically harden binary (x86) code against vulnerabilities. As a side project, we've ran our tools on 33,000 Debian programs, and found about 11,000 new unique crashing bugs (150 give us a shell). Please consider applying if this sounds exciting. http://jobs.forallsecure.com/ Take care, -David PS. ForAllSecure is a Carnegie Mellon University spinoff. The job is in Pittsburgh, but we will also consider highly qualified remote candidates. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Apr 26 17:45:31 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 26 Apr 2014 13:45:31 -0400 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: the vast majority of math is written using latex, which while supporting unicode, is mostly ascii :) On Sat, Apr 26, 2014 at 11:58 AM, David Fox wrote: > On Thu, Apr 24, 2014 at 10:27 AM, Kyle Murphy wrote: > >> It's an interesting feature, and nice if you want that sort of thing, but >> not something I'd personally want to see as the default. Deviating from the >> standard ASCII set of characters is just too much of a hurdle to usability >> of the language. >> > > On the other hand, maybe if its good enough for the entire field of > Mathematics since forever there might be some benefit in it for us. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Sat Apr 26 18:00:04 2014 From: trebla at vex.net (Albert Y. C. Lai) Date: Sat, 26 Apr 2014 14:00:04 -0400 Subject: [Haskell-cafe] Building foreign shared libraries with Cabal In-Reply-To: References: Message-ID: <535BF424.5070507@vex.net> On 14-04-21 04:25 AM, Nikolay Amiantov wrote: > I want to use cabal to build and install shared library, which will be > called from C. I've already found necessary combination of flags and > options to successfully build it, but now I have two main issues: > > 1) The library is installed into "bin". > 2) The generated "stub" C headers are not installed at all. > > How can I resolve this? My current options is as follows: > > executable libtest.so [...] See my http://www.vex.net/~trebla/haskell/so.xhtml for how to use "library" instead. It has the advantage of needing no ghc-options or cc-options, and installing into "lib/xxx-1.0/ghc-n.n.n". It has the disadvantage of losing control over the filename---it must be "libHSxxx-1.0-ghcn.n.n.so". Combine "include-dirs" and "install-includes" for the C header. It will be installed into "lib/xxx-1.0/ghc-n.n.n/include". However, you have a dilemma: * If you use the generated file under dist/build, cabal warns you that dist/build is not to be relied upon, and it is right. Also, it depends too much on HsFFI.h. * If you hand-write the file yourself, you worry that it mismatches the Haskell export, and you are right. From michaeltbaker at gmail.com Sat Apr 26 18:24:00 2014 From: michaeltbaker at gmail.com (Michael Baker) Date: Sat, 26 Apr 2014 13:24:00 -0500 Subject: [Haskell-cafe] Packing Haskell values into a C array Message-ID: I'm working on a game in Haskell and I'm at a point where I have to do some optimization so I'm looking for advice or resources from people who may have already solved my problem. Specifically, I have a grid of 10,000 circles and I need to get them rendered. This involves translating the 10,000 circles into a single C array (of CFloats in my case) so that I can ship that array off to OpenGL for rendering. This is something I can't change, that's just the way OpenGL works. What I can change is the way I create and maintain the array. Currently I'm doing the most naive thing I can, which is to convert the list of circles into a list of floats, and then convert that list into a C array every frame. This is obviously very expensive. I've thought of several things to try including: * Only allocate an array when the number of circles changes. * Convert a circles into a C struct and "poke" them directly into an existing array instead of going through the intermediate form of a list. * Do some manual memory management and index each circle into a preallocated array, only updating the values of the array that correspond to circles which have changed. I'm wondering if there are already common solutions to this sort of problem (packing a lot of Haskell values that might change each frame into an array efficiently). Any resources that are tangential to this sort of thing would also be nice. For instance, how I can use the type system to ensure that the resulting array has the shape I want. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Sat Apr 26 19:21:28 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Sat, 26 Apr 2014 21:21:28 +0200 Subject: [Haskell-cafe] Packing Haskell values into a C array In-Reply-To: References: Message-ID: <20140426192128.GA14339@machine> Hi Michael, On Sat, Apr 26, 2014 at 01:24:00PM -0500, Michael Baker wrote: > Specifically, I have a grid of 10,000 circles and I need to get them rendered. > This involves translating the 10,000 circles into a single C array (of CFloats > in my case) so that I can ship that array ? ?off to OpenGL for rendering. This > is something I can't change, that's just the way OpenGL works. Perhaps you don't need to change the Haskell representation that much, but only memorize which cricles have change and only update these ones. I would use a VertexBuffer-Object on the OpenGL side and memorize on the Haskell side which circles have changed per frame. Then you could map the VertexBuffer-Object and only update the corresponding coordinates. It might make sense to use a Vector instead of a List, then you could just memorize the indices of the changed Vector entries and the update should be faster when indexing into a Vector instead of a List. Greetings, Daniel From mail at nh2.me Sat Apr 26 19:53:09 2014 From: mail at nh2.me (=?ISO-8859-1?Q?Niklas_Hamb=FCchen?=) Date: Sat, 26 Apr 2014 20:53:09 +0100 Subject: [Haskell-cafe] Packing Haskell values into a C array In-Reply-To: References: Message-ID: <535C0EA5.9040807@nh2.me> Using a Storable vector is what I mostly do. It goes nicely with rendering arrays of objects using OpenGL `BufferObject`s, using `fromVector` from http://hackage.haskell.org/package/GLUtil-0.6.4/docs/Graphics-GLUtil-BufferObjects.html#v:fromVector. On 26/04/14 19:24, Michael Baker wrote: > I've thought of several things to try including: > * Only allocate an array when the number of circles changes. > * Convert a circles into a C struct and "poke" them directly into an > existing array instead of going through the intermediate form of a list. > * Do some manual memory management and index each circle into a > preallocated array, only updating the values of the array that > correspond to circles which have changed. From acowley at seas.upenn.edu Sat Apr 26 20:13:54 2014 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Sat, 26 Apr 2014 16:13:54 -0400 Subject: [Haskell-cafe] Packing Haskell values into a C array In-Reply-To: <535C0EA5.9040807@nh2.me> References: <535C0EA5.9040807@nh2.me> Message-ID: > On Apr 26, 2014, at 3:53 PM, Niklas Hamb?chen wrote: > > Using a Storable vector is what I mostly do. > > It goes nicely with rendering arrays of objects using OpenGL > `BufferObject`s, using `fromVector` from > http://hackage.haskell.org/package/GLUtil-0.6.4/docs/Graphics-GLUtil-BufferObjects.html#v:fromVector. > I second this recommendation. If you are doing frequent updates on a small subset of these values, I have most of an interface for doing so, but I haven't bundled it into GLUtil yet, so let me know (better: open an issue on github) if the existing interface just doesn't work for you. Anthony >> On 26/04/14 19:24, Michael Baker wrote: >> I've thought of several things to try including: >> * Only allocate an array when the number of circles changes. >> * Convert a circles into a C struct and "poke" them directly into an >> existing array instead of going through the intermediate form of a list. >> * Do some manual memory management and index each circle into a >> preallocated array, only updating the values of the array that >> correspond to circles which have changed. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From mail at nh2.me Sat Apr 26 21:40:50 2014 From: mail at nh2.me (=?ISO-8859-1?Q?Niklas_Hamb=FCchen?=) Date: Sat, 26 Apr 2014 22:40:50 +0100 Subject: [Haskell-cafe] How to write fast for loops Message-ID: <535C27E2.6010808@nh2.me> As you probably now, `forM_ [1..n]` is incredibly slow in Haskell due to lack of list fusion [1]; a manually written loop is 10x faster. How do you people work around this? I keep defining myself something like loop :: (Monad m) => Int -> (Int -> m ()) -> m () loop bex f = go 0 where go !n | n == bex = return () | otherwise = f n >> go (n+1) Is there a function for this somewhere already? Or do you have another way to deal with this problem? Thanks! [1]: https://ghc.haskell.org/trac/ghc/ticket/8763 From jwlato at gmail.com Sun Apr 27 00:13:52 2014 From: jwlato at gmail.com (John Lato) Date: Sat, 26 Apr 2014 17:13:52 -0700 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <535C27E2.6010808@nh2.me> References: <535C27E2.6010808@nh2.me> Message-ID: I usually use a manually written loop, but you can use Data.Vector for this and it should fuse. John L. On Apr 26, 2014 2:41 PM, "Niklas Hamb?chen" wrote: > As you probably now, `forM_ [1..n]` is incredibly slow in Haskell due to > lack of list fusion [1]; a manually written loop is 10x faster. > > How do you people work around this? > > I keep defining myself something like > > loop :: (Monad m) => Int -> (Int -> m ()) -> m () > loop bex f = go 0 > where > go !n | n == bex = return () > | otherwise = f n >> go (n+1) > > Is there a function for this somewhere already? > Or do you have another way to deal with this problem? > > Thanks! > > > [1]: https://ghc.haskell.org/trac/ghc/ticket/8763 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Sun Apr 27 01:16:06 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Sun, 27 Apr 2014 02:16:06 +0100 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: References: <535C27E2.6010808@nh2.me> Message-ID: <535C5A56.7060704@nh2.me> Hey John, do you mean something along the lines of `V.forM_ (fromList [1..n])`? I guess GHC wouldn't mash away the list in this case and I'd have to use the new OverloadedLists with `V.forM_ [1..n]` (indeed that looks quite sweet). However, would that actually be fast? Judging from how list syntax is desugared, I guess that would use `V.enumFromTo` then, whose docs claim "WARNING: This operation can be very inefficient. If at all possible, use enumFromN instead". Does anybody know wonder if "vector literals" desugar enumFromN, or what "can be very inefficient" means? Niklas On Sun 27 Apr 2014 01:13:52 BST, John Lato wrote: > I usually use a manually written loop, but you can use Data.Vector for > this and it should fuse. From daniel.is.fischer at googlemail.com Sun Apr 27 01:32:12 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Sun, 27 Apr 2014 03:32:12 +0200 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <535C27E2.6010808@nh2.me> References: <535C27E2.6010808@nh2.me> Message-ID: <1415627.XeXDu9OFXS@linux-hpeb.site> On Saturday 26 April 2014, 22:40:50, Niklas Hamb?chen wrote: > As you probably now, `forM_ [1..n]` is incredibly slow in Haskell due to > lack of list fusion [1]; It's not the lack of list fusion per se. If you have a forM_ [a .. b] $ \n -> do stuff where the type is Int, GHC is perfectly capable of eliminating the list and rewriting it to a loop (usually on par with a hand-written loop, although the core you get from a hand-written loop often is smaller and nicer to look at). The problem is that you use the same list multiple times, and GHC thinks "hey, let me re-use that", so it gets floated to the top-level, and the inner "loop" really uses the list, which apart from the `case`s on the list forces it to use boxed 'Int's instead of Int#. Then the boxed Ints need to be unboxed to be used, oops. If you manage to conceal the fact that the lists are the same from GHC, it eliminates the lists and you get fast code also with forM_. In your matmult example, using forM_ [k-k .. _SIZE-1] $ \j -> do ... does the trick for GHC-7.0 to 7.8. That is of course a brittle workaround, future GHCs might rewrite the k-k to 0 and share the list again. > a manually written loop is 10x faster. > > How do you people work around this? Do the idiomatic thing and write a loop ;) > > [1]: https://ghc.haskell.org/trac/ghc/ticket/8763 Cheers, Daniel From mail at nh2.me Sun Apr 27 01:46:07 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Sun, 27 Apr 2014 02:46:07 +0100 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <1415627.XeXDu9OFXS@linux-hpeb.site> References: <535C27E2.6010808@nh2.me> <1415627.XeXDu9OFXS@linux-hpeb.site> Message-ID: <535C615F.8070405@nh2.me> Thanks for the insight! There's one thing I don't understand yet: On 27/04/14 02:32, Daniel Fischer wrote: > The problem is that you use the same list multiple times, and GHC thinks "hey, > let me re-use that", so it gets floated to the top-level, and the inner "loop" > really uses the list, which apart from the `case`s on the list forces it to > use boxed 'Int's instead of Int#. Then the boxed Ints need to be unboxed to be > used, oops. When you say that the problem is that I "use the same list multiple times", do you mean that I use the actual syntactic expression `[0.._SIZE-1]` multiple times on multiple lines, and suggest that this should not happen if I use it in only one place? If so, how far does that go, and would GHC even notice that it is the same as a potential `[0.._511]` I might write elsewhere? > Do the idiomatic thing and write a loop ;) Unfortunately, `forM_ [1..n]` is pretty much the most idiomatic and beautiful way I can come up with when ask for an iteration over 1 up to n! So this better be fixed :) From daniel.is.fischer at googlemail.com Sun Apr 27 02:12:55 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Sun, 27 Apr 2014 04:12:55 +0200 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <535C615F.8070405@nh2.me> References: <535C27E2.6010808@nh2.me> <1415627.XeXDu9OFXS@linux-hpeb.site> <535C615F.8070405@nh2.me> Message-ID: <1843154.k7RxbMFAYv@linux-hpeb.site> On Sunday 27 April 2014, 02:46:07, Niklas Hamb?chen wrote: > Thanks for the insight! There's one thing I don't understand yet: > > On 27/04/14 02:32, Daniel Fischer wrote: > > The problem is that you use the same list multiple times, and GHC thinks > > "hey, let me re-use that", so it gets floated to the top-level, and the > > inner "loop" really uses the list, which apart from the `case`s on the > > list forces it to use boxed 'Int's instead of Int#. Then the boxed Ints > > need to be unboxed to be used, oops. > > When you say that the problem is that I "use the same list multiple > times", do you mean that I use the actual syntactic expression > `[0.._SIZE-1]` multiple times on multiple lines, and suggest that this > should not happen if I use it in only one place? More or less. The `_SIZE - 1` is constant-folded to 511, so writing the list as [0 .. 511] would probably not prevent the sharing. And using the same list in a different function may or may not affect the produced code, I don't know GHC well enough to predict that. If you write it in a form that GHC doesn't recognise as the same value, GHC can and does optimise it as if the value were used only once. > > If so, how far does that go, and would GHC even notice that it is the > same as a potential `[0.._511]` I might write elsewhere? Depends on "elsewhere". I've seen GHC produce multiple top-level values for the very same thing used in different functions in the same module, so if "elsewhere" means a different function and inlining doesn't cause GHC to see the two at the same time, it will probably not notice. But ask somebody who knows how GHC works if you want to be sure. > > > Do the idiomatic thing and write a loop ;) > > Unfortunately, `forM_ [1..n]` is pretty much the most idiomatic and > beautiful way I can come up with when ask for an iteration over 1 up to > n! Well, my idiom is looping, because. > So this better be fixed :) Agreed. From michaeltbaker at gmail.com Sun Apr 27 02:28:22 2014 From: michaeltbaker at gmail.com (Michael Baker) Date: Sat, 26 Apr 2014 21:28:22 -0500 Subject: [Haskell-cafe] Packing Haskell values into a C array In-Reply-To: References: <535C0EA5.9040807@nh2.me> Message-ID: > On 26/04/14 19:24, Michael Baker wrote: > I've thought of several things to try including: > * Only allocate an array when the number of circles changes. > * Convert a circles into a C struct and "poke" them directly into an > existing array instead of going through the intermediate form of a list. > * Do some manual memory management and index each circle into a > preallocated array, only updating the values of the array that > correspond to circles which have changed. > On Apr 26, 2014, at 3:53 PM, Niklas Hamb?chen wrote: > > Using a Storable vector is what I mostly do. > > It goes nicely with rendering arrays of objects using OpenGL > `BufferObject`s, using `fromVector` from > http://hackage.haskell.org/package/GLUtil-0.6.4/docs/Graphics-GLUtil-BufferObjects.html#v:fromVector . > On Sat, Apr 26, 2014 at 3:13 PM, Anthony Cowley wrote: > I second this recommendation. If you are doing frequent updates on a small subset of these values, I have most of an interface for doing so, but I haven't bundled it into GLUtil yet, so let me know (better: open an issue on github) if the existing interface just doesn't work for you. So do you all just create a new vector every frame? Could you go into a little more detail? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Sun Apr 27 02:28:30 2014 From: jwlato at gmail.com (John Lato) Date: Sat, 26 Apr 2014 19:28:30 -0700 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <535C5A56.7060704@nh2.me> References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> Message-ID: Hi Niklas, No, I mean this: > V.forM_ (V.enumFromN 1 n) I agree it's less elegant. And like Daniel points out with lists, you definitely don't want the "enumFromN" to be shared. But one of the biggest warts of Haskell IMHO is that it's still very difficult to get really high-performance code without an intimate understanding of the optimizer. John L. On Sat, Apr 26, 2014 at 6:16 PM, Niklas Hamb?chen wrote: > Hey John, > > do you mean something along the lines of `V.forM_ (fromList [1..n])`? > I guess GHC wouldn't mash away the list in this case and I'd have to > use the new OverloadedLists with `V.forM_ [1..n]` (indeed that looks > quite sweet). > However, would that actually be fast? Judging from how list syntax is > desugared, I guess that would use `V.enumFromTo` then, whose docs claim > "WARNING: This operation can be very inefficient. If at all possible, > use enumFromN instead". > > Does anybody know wonder if "vector literals" desugar enumFromN, or > what "can be very inefficient" means? > > Niklas > > On Sun 27 Apr 2014 01:13:52 BST, John Lato wrote: > > I usually use a manually written loop, but you can use Data.Vector for > > this and it should fuse. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Apr 27 03:20:54 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 26 Apr 2014 23:20:54 -0400 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> Message-ID: John, can't a careful use of the identity monad or the like prevent that CSE? (i'm a bit fuzzy on that piece of ghc lore) On Sat, Apr 26, 2014 at 10:28 PM, John Lato wrote: > Hi Niklas, > > No, I mean this: > > > V.forM_ (V.enumFromN 1 n) > > I agree it's less elegant. And like Daniel points out with lists, you > definitely don't want the "enumFromN" to be shared. But one of the biggest > warts of Haskell IMHO is that it's still very difficult to get really > high-performance code without an intimate understanding of the optimizer. > > John L. > > On Sat, Apr 26, 2014 at 6:16 PM, Niklas Hamb?chen wrote: > >> Hey John, >> >> do you mean something along the lines of `V.forM_ (fromList [1..n])`? >> I guess GHC wouldn't mash away the list in this case and I'd have to >> use the new OverloadedLists with `V.forM_ [1..n]` (indeed that looks >> quite sweet). >> However, would that actually be fast? Judging from how list syntax is >> desugared, I guess that would use `V.enumFromTo` then, whose docs claim >> "WARNING: This operation can be very inefficient. If at all possible, >> use enumFromN instead". >> >> Does anybody know wonder if "vector literals" desugar enumFromN, or >> what "can be very inefficient" means? >> >> Niklas >> >> On Sun 27 Apr 2014 01:13:52 BST, John Lato wrote: >> > I usually use a manually written loop, but you can use Data.Vector for >> > this and it should fuse. >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From acowley at seas.upenn.edu Sun Apr 27 03:54:38 2014 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Sat, 26 Apr 2014 23:54:38 -0400 Subject: [Haskell-cafe] Packing Haskell values into a C array In-Reply-To: References: <535C0EA5.9040807@nh2.me> Message-ID: <19C335B2-619C-4EFE-9FA6-65CE6680ED01@seas.upenn.edu> > On Apr 26, 2014, at 10:28 PM, Michael Baker wrote: > > > On 26/04/14 19:24, Michael Baker wrote: > > I've thought of several things to try including: > > * Only allocate an array when the number of circles changes. > > * Convert a circles into a C struct and "poke" them directly into an > > existing array instead of going through the intermediate form of a list. > > * Do some manual memory management and index each circle into a > > preallocated array, only updating the values of the array that > > correspond to circles which have changed. > > > On Apr 26, 2014, at 3:53 PM, Niklas Hamb?chen wrote: > > > > Using a Storable vector is what I mostly do. > > > > It goes nicely with rendering arrays of objects using OpenGL > > `BufferObject`s, using `fromVector` from > > http://hackage.haskell.org/package/GLUtil-0.6.4/docs/Graphics-GLUtil-BufferObjects.html#v:fromVector. > > > On Sat, Apr 26, 2014 at 3:13 PM, Anthony Cowley wrote: > > I second this recommendation. If you are doing frequent updates on a small subset of these values, I have most of an interface for doing so, but I haven't bundled it into GLUtil yet, so let me know (better: open an issue on github) if the existing interface just doesn't work for you. > > So do you all just create a new vector every frame? Could you go into a little more detail? You can create a new vector every frame, or you can use a mutable vector that you freeze before passing to 'fromVector' or 'replaceVector'. You can also investigate using, say, 10 vectors of 1k elements each if your updates are spatially correlated somehow. I do the latter when I am generating new data over time, for example. The nice thing about using Vector is that you can use it like an array that you peek from and poke to, or you can take advantage of the fusion machinery to generate or update it on the Haskell side before shipping the underlying data off to OpenGL. The specifics of your update patterns will govern what is the best strategy. Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Apr 27 07:47:32 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 27 Apr 2014 08:47:32 +0100 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <1415627.XeXDu9OFXS@linux-hpeb.site> References: <535C27E2.6010808@nh2.me> <1415627.XeXDu9OFXS@linux-hpeb.site> Message-ID: <20140427074732.GF22120@weber> On Sun, Apr 27, 2014 at 03:32:12AM +0200, Daniel Fischer wrote: > On Saturday 26 April 2014, 22:40:50, Niklas Hamb?chen wrote: > > As you probably now, `forM_ [1..n]` is incredibly slow in Haskell due to > > lack of list fusion [1]; > > It's not the lack of list fusion per se. If you have a > > forM_ [a .. b] $ \n -> do stuff > > where the type is Int, GHC is perfectly capable of eliminating the list and > rewriting it to a loop (usually on par with a hand-written loop, although the > core you get from a hand-written loop often is smaller and nicer to look at). > > The problem is that you use the same list multiple times, and GHC thinks "hey, > let me re-use that", so it gets floated to the top-level If this is the case, does -fno-full-laziness help? From kai at kzhang.org Sun Apr 27 08:27:03 2014 From: kai at kzhang.org (Kai Zhang) Date: Sun, 27 Apr 2014 01:27:03 -0700 Subject: [Haskell-cafe] Why this doesn't work? Message-ID: Hi Cafe, I don't understand why this doesn't work: import qualified Data.Vector.Generic as G import Control.Monad.ST test :: G.Vector v a => v a -> v a test x = runST . (>>= G.freeze) . G.thaw $ x But if I replace "." with "$", it can compile. test x = runST $ (>>= G.freeze) . G.thaw $ x I originally though f $ g x can always be written as f . g $ x -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Sun Apr 27 09:30:47 2014 From: ben.franksen at online.de (Ben Franksen) Date: Sun, 27 Apr 2014 11:30:47 +0200 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! References: Message-ID: Nickolay Kudasov wrote: >> eg I would like to see \ spelled as ? > > ?I have symbol substitution enabled in Vim. E.g. when I write \ (and it is > syntactically lambda) I get ?. The same way composition (.) is replaced > with ?. The same trick can be enabled for other operators as well. So I > have normal text and nice presentation in *my* text editor: it does not > bother anyone but me. I think this is the right approach. See also https://github.com/i-tu/Hasklig/ The main problem with special Unicode characters, as I see it, is that it is no longer possible to distinguish characters unambiguously just by looking at them. Apart from questions of maintainability, this is also a potential security problem: it enables an attacker to slip in malicious code simply by importing a module whose name looks like a well known safe module. In a big and complex piece of software, such an attack might not be spotted for some time. Cheers Ben -- "Make it so they have to reboot after every typo." -- Scott Adams From miguelimo38 at yandex.ru Sun Apr 27 10:21:27 2014 From: miguelimo38 at yandex.ru (MigMit) Date: Sun, 27 Apr 2014 14:21:27 +0400 Subject: [Haskell-cafe] Why this doesn't work? In-Reply-To: References: Message-ID: <730B4134-B5B8-4157-8AA3-0C6CC0170694@yandex.ru> runST uses forall. It messes up type inference (and yes, type inference is at play even if top-level function has type signature). See, if you write "runST $ f x", then GHC deduces this: ($) :: (a -> b) -> a -> b runST :: (forall s. ST s z) -> z therefore (a -> b) ~ (forall s. ST s z) -> z therefore a ~ forall s. ST s z, b ~ z and also f x :: a therefore f x :: forall s. ST s z Then it goes on checking that f x :: forall s. ST s z actually makes sense, which it does by first stripping away forall and checking that f x :: ST s z is sound. If you write (runST . f) x, then what GHC sees is (.) :: (b -> c) -> (a -> b) -> (a -> c) runST :: (forall s. ST s z) -> z therefore b -> c ~ (forall s. ST s z) -> z therefore b ~ (forall s. ST s z), c ~ z and also f :: a -> b therefore f :: a -> forall s. ST s z Unfortunately, f is of type a -> ST s z, or, if you quantify explicitly, forall s. a -> ST s z. These two types don't match. If you write type arguments explicitly, like you'll do in Agda, you'd have (s :: Type) -> a -> ST s z vs a -> (s :: Type) -> ST s z So they are different. I don't think there is an easy way to fix that, apart from using "$". On 27 Apr 2014, at 12:27, Kai Zhang wrote: > Hi Cafe, > > I don't understand why this doesn't work: > > import qualified Data.Vector.Generic as G > import Control.Monad.ST > > test :: G.Vector v a => v a -> v a > test x = runST . (>>= G.freeze) . G.thaw $ x > > But if I replace "." with "$", it can compile. > > test x = runST $ (>>= G.freeze) . G.thaw $ x > > I originally though f $ g x can always be written as f . g $ x > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From roma at ro-che.info Sun Apr 27 11:03:12 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 27 Apr 2014 14:03:12 +0300 Subject: [Haskell-cafe] Why this doesn't work? In-Reply-To: <730B4134-B5B8-4157-8AA3-0C6CC0170694@yandex.ru> References: <730B4134-B5B8-4157-8AA3-0C6CC0170694@yandex.ru> Message-ID: <20140427110312.GA10493@sniper> GHC doesn't have a difficulty translating between a -> forall s. ST s z and forall s. a -> ST s z This is easy to verify: Prelude> :m +Control.Monad.ST Prelude Control.Monad.ST> :set -XRankNTypes Prelude Control.Monad.ST> let f :: forall a . a -> forall s. ST s a; f = undefined Prelude Control.Monad.ST> :t f f :: a -> ST s a (and vice versa) The real problem is that both examples of inference require impredicative instantiation: > therefore (a -> b) ~ (forall s. ST s z) -> z > therefore a ~ forall s. ST s z, b ~ z in the first case, and > therefore b -> c ~ (forall s. ST s z) -> z > therefore b ~ (forall s. ST s z), c ~ z in the second case. The difference between ($) and (.) is that there's a special case in GHC's type checker for ($) which enables impredicative instantiation, which was added exactly for the common use case of runST $ ... Such a rule wasn't added for (.), presumably because people write runST . f much less often, and there weren't as many complaints (perhaps any at all) about (.) not working with runST. Roman * MigMit [2014-04-27 14:21:27+0400] > runST uses forall. It messes up type inference (and yes, type inference is at play even if top-level function has type signature). > > See, if you write "runST $ f x", then GHC deduces this: > > ($) :: (a -> b) -> a -> b > runST :: (forall s. ST s z) -> z > therefore (a -> b) ~ (forall s. ST s z) -> z > therefore a ~ forall s. ST s z, b ~ z > and also f x :: a > therefore f x :: forall s. ST s z > > Then it goes on checking that f x :: forall s. ST s z actually makes sense, which it does by first stripping away forall and checking that f x :: ST s z is sound. > > If you write (runST . f) x, then what GHC sees is > > (.) :: (b -> c) -> (a -> b) -> (a -> c) > runST :: (forall s. ST s z) -> z > therefore b -> c ~ (forall s. ST s z) -> z > therefore b ~ (forall s. ST s z), c ~ z > and also f :: a -> b > therefore f :: a -> forall s. ST s z > > Unfortunately, f is of type a -> ST s z, or, if you quantify explicitly, forall s. a -> ST s z. These two types don't match. If you write type arguments explicitly, like you'll do in Agda, you'd have > > (s :: Type) -> a -> ST s z > > vs > > a -> (s :: Type) -> ST s z > > So they are different. > > I don't think there is an easy way to fix that, apart from using "$". > > On 27 Apr 2014, at 12:27, Kai Zhang wrote: > > > Hi Cafe, > > > > I don't understand why this doesn't work: > > > > import qualified Data.Vector.Generic as G > > import Control.Monad.ST > > > > test :: G.Vector v a => v a -> v a > > test x = runST . (>>= G.freeze) . G.thaw $ x > > > > But if I replace "." with "$", it can compile. > > > > test x = runST $ (>>= G.freeze) . G.thaw $ x > > > > I originally though f $ g x can always be written as f . g $ x > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From alois.cochard at gmail.com Sun Apr 27 11:15:48 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Sun, 27 Apr 2014 12:15:48 +0100 Subject: [Haskell-cafe] [ANN] codex - generate tags file from dependencies In-Reply-To: References: Message-ID: I have finally updated the tool to use `hasktags` by default as after more in depth testing I realize that the quality is much better in term of dealing with namespaces. In fact I made the tagger command fully configurable (with template for hasktags and ctags), the tool now store as well a 'hash' of the dependency graph in the tags file to avoid recomputing it when there is no need (that easy to integrate the tool as hook). More information in the README: https://github.com/aloiscochard/codex#usage Cheers On 24 April 2014 23:54, Alois Cochard wrote: > Hi, > > Just to let you know that I released a tool which allow to generate a > tags[1] file for a given cabal project using the sources of all the > dependencies of that project. > > `cabal install codex` > > You can simply run `codex update` in one of your cabal project directory > and you'll get a 'codex.tags' file to feed in your favorite text editors. > > It store the source code in the hackage local cache, and it store there as > well the tags file per module (so the tool just aggregate per project). > > I hope it will be useful to other hackers, it's a joy for me in vim when > using unknown libraries. > > Note: This tool actually use `ctags` but that could be easily made > configurable if someone need it, integrating native haskell tagger is an > option too. I personally like using ctags, it's very fast. > > *[1]Those tags file basically contain references to functions/types > definition in source code and allow "jump to definition" > like functionality in text editors.* > > source: http://github.com/aloiscochard/codex > hackage: http://hackage.haskell.org/package/codex > > -- > *Alois Cochard* > http://twitter.com/aloiscochard > -- *Alois Cochard* http://aloiscochard.blogspot.com http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustompmody at gmail.com Sun Apr 27 11:45:54 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Sun, 27 Apr 2014 17:15:54 +0530 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: On Sat, Apr 26, 2014 at 9:28 PM, David Fox wrote: > On Thu, Apr 24, 2014 at 10:27 AM, Kyle Murphy wrote: > >> It's an interesting feature, and nice if you want that sort of thing, but >> not something I'd personally want to see as the default. Deviating from the >> standard ASCII set of characters is just too much of a hurdle to usability >> of the language. >> > > On the other hand, maybe if its good enough for the entire field of > Mathematics since forever there might be some benefit in it for us. > Chris spoke of his choice of Idris over Agda related to not going overboard with unicode. The FAQ he linked to has this to say: | And I'm sure that in a few years time things will be different and software will | cope better and it will make sense to revisit this. For now, however, I would | prefer not to allow arbitrary unicode symbols in operators. 1. I'd like to underscore the 'arbitrary'. Why is ASCII any less arbitrary -- apart from an increasingly irrelevant historical accident -- than Arabic, Bengali, Cyrillic, Deseret? [Hint: Whats the A in ASCII?] By contrast math may at least have some pretensions to universality? 2. Maybe its a good time now to 'revisit'? Otherwise like klunky-qwerty, it may happen that when the technological justifications for an inefficient choice are long gone, social inertia will prevent any useful change. On Sun, Apr 27, 2014 at 3:00 PM, Ben Franksen wrote: > The main problem with special Unicode characters, as I see it, is that it > is > no longer possible to distinguish characters unambiguously just by looking > at them. Apart from questions of maintainability, this is also a potential > security problem: it enables an attacker to slip in malicious code simply > by > importing a module whose name looks like a well known safe module. In a big > and complex piece of software, such an attack might not be spotted for some > time. > Bang on! However the Pandora-box is already open and the creepy-crawlies are all over us. Witness: GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> let ? = 1 Prelude> a :11:1: Not in scope: `a' Prelude> In case you cant see it the two a's are different unicode characters: CYRILLIC SMALL LETTER A vs LATIN SMALL LETTER A Regards Rusi -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.is.fischer at googlemail.com Sun Apr 27 12:21:34 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Sun, 27 Apr 2014 14:21:34 +0200 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <20140427074732.GF22120@weber> References: <535C27E2.6010808@nh2.me> <1415627.XeXDu9OFXS@linux-hpeb.site> <20140427074732.GF22120@weber> Message-ID: <4280295.Ao0vlmXUNq@linux-hpeb.site> On Sunday 27 April 2014, 08:47:32, Tom Ellis wrote: > On Sun, Apr 27, 2014 at 03:32:12AM +0200, Daniel Fischer wrote: > > The problem is that you use the same list multiple times, and GHC thinks > > "hey, let me re-use that", so it gets floated to the top-level > > If this is the case, does -fno-full-laziness help? Yes and no. It prevents the list from being floated to the top-level, but the overall code you get is slower than with the shared list. So it works as far as preventing unwanted sharing is concerned, but it inhibits optimisations at other places. From spam at scientician.net Sun Apr 27 12:22:49 2014 From: spam at scientician.net (Bardur Arantsson) Date: Sun, 27 Apr 2014 14:22:49 +0200 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: On 2014-04-27 13:45, Rustom Mody wrote: > > 1. I'd like to underscore the 'arbitrary'. Why is ASCII any less arbitrary > -- apart from an increasingly irrelevant historical accident -- than > Arabic, Bengali, Cyrillic, Deseret? [Hint: Whats the A in ASCII?] By > contrast math may at least have some pretensions to universality? The symbols in math are also mostly arbitrary. In effect they should be considered as "parallel" to the Cyrillic, Latin or Greek alphabets. (Of course math borrows quite a few symbols from the latter, but I digress.) > > 2. Maybe its a good time now to 'revisit'? Otherwise like klunky-qwerty, > it may happen that when the technological justifications for an inefficient > choice are long gone, social inertia will prevent any useful change. > Billions of people have QWERTY keyboards. Unless you come up with something *radically* better then they're not going to change. Inertia has made anything but incremental change impossible. (I note that Microsoft actually managed to change the QWERTY keyboard incrementally a decade or two ago by adding the Windows and Context Menu keys. Of course that didn't removing/change any of the existing functionality of the basic QWERTY, so it was a relatively small change.) Using "macros" like "\" (for lambda) or "\sum_{i=0}^{n} i" and having the editor/IDE display that differently is at least semi-practical for typing stuff into your computer using QWERTY. Regards, From mail at nh2.me Sun Apr 27 13:15:34 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Sun, 27 Apr 2014 14:15:34 +0100 Subject: [Haskell-cafe] Packing Haskell values into a C array In-Reply-To: <19C335B2-619C-4EFE-9FA6-65CE6680ED01@seas.upenn.edu> References: <535C0EA5.9040807@nh2.me> <19C335B2-619C-4EFE-9FA6-65CE6680ED01@seas.upenn.edu> Message-ID: <535D02F6.9090801@nh2.me> Yes, what Anthony says. I create the BufferObject from the Vector when what I want to render changes (which happens less frequently than every frame), and each frame then renders from the BufferObject. If you want to change single elements, like he says, the mutable vector should make you happy. On 27/04/14 04:54, Anthony Cowley wrote: >> So do you all just create a new vector every frame? Could you go into >> a little more detail? > > You can create a new vector every frame, or you can use a mutable vector > that you freeze before passing to 'fromVector' or 'replaceVector'. You > can also investigate using, say, 10 vectors of 1k elements each if your > updates are spatially correlated somehow. I do the latter when I am > generating new data over time, for example. The nice thing about using > Vector is that you can use it like an array that you peek from and poke > to, or you can take advantage of the fusion machinery to generate or > update it on the Haskell side before shipping the underlying data off to > OpenGL. > > The specifics of your update patterns will govern what is the best strategy. > > Anthony From michaeltbaker at gmail.com Sun Apr 27 13:48:05 2014 From: michaeltbaker at gmail.com (Michael Baker) Date: Sun, 27 Apr 2014 08:48:05 -0500 Subject: [Haskell-cafe] Packing Haskell values into a C array In-Reply-To: <535D02F6.9090801@nh2.me> References: <535C0EA5.9040807@nh2.me> <19C335B2-619C-4EFE-9FA6-65CE6680ED01@seas.upenn.edu> <535D02F6.9090801@nh2.me> Message-ID: Thanks! On Sun, Apr 27, 2014 at 8:15 AM, Niklas Hamb?chen wrote: > Yes, what Anthony says. I create the BufferObject from the Vector when > what I want to render changes (which happens less frequently than every > frame), and each frame then renders from the BufferObject. > > If you want to change single elements, like he says, the mutable vector > should make you happy. > > On 27/04/14 04:54, Anthony Cowley wrote: > >> So do you all just create a new vector every frame? Could you go into > >> a little more detail? > > > > You can create a new vector every frame, or you can use a mutable vector > > that you freeze before passing to 'fromVector' or 'replaceVector'. You > > can also investigate using, say, 10 vectors of 1k elements each if your > > updates are spatially correlated somehow. I do the latter when I am > > generating new data over time, for example. The nice thing about using > > Vector is that you can use it like an array that you peek from and poke > > to, or you can take advantage of the fusion machinery to generate or > > update it on the Haskell side before shipping the underlying data off to > > OpenGL. > > > > The specifics of your update patterns will govern what is the best > strategy. > > > > Anthony > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Sun Apr 27 14:20:29 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 28 Apr 2014 00:20:29 +1000 Subject: [Haskell-cafe] ANNOUNCE: fgl-5.5.0.0 Message-ID: I'm pleased to announce a new version of the functional graph library: http://hackage.haskell.org/package/fgl-5.5.0.0 The main change in this version: proper Show, Read and Eq instances for both graph implementations. Previously, Data.Graph.Inductive.Tree had a pretty-printed Show output; now both it and PatriciaTree have Show and Read instances via the mkGraph function, and Eq via deriving (I'm not sure how well this will work because as I write this I realise it may not deal with multiple edges that well... I guess I'll be doing an updated version tomorrow after getting some sleep ;p). The previous Show behaviour of Tree is now available as a pretty-printing function for all DynGraph instances. The PatriciaTree implementation is now exported and used by default, because as far as I'm aware it will always perform better. Finally, the Data.Graph.Inductive.Graphviz module has been removed; if you want to visualise your fgl graph, please see my graphviz package on Hackage (cheap plug? moi?). -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From michael at orlitzky.com Sun Apr 27 14:31:28 2014 From: michael at orlitzky.com (Michael Orlitzky) Date: Sun, 27 Apr 2014 10:31:28 -0400 Subject: [Haskell-cafe] Baltimore Haskell Users Group Message-ID: <535D14C0.3000907@orlitzky.com> For those who don't reddit: http://www.reddit.com/r/haskell/comments/23zevt/baltimore_haskell_users_group/ https://groups.google.com/forum/#!forum/bmore-hug And if like me you have no idea how to Google Groups, just send an email to bmore-hug+subscribe at googlegroups.com to subscribe to the list. From miguelimo38 at yandex.ru Sun Apr 27 14:52:45 2014 From: miguelimo38 at yandex.ru (MigMit) Date: Sun, 27 Apr 2014 18:52:45 +0400 Subject: [Haskell-cafe] Why this doesn't work? In-Reply-To: <20140427110312.GA10493@sniper> References: <730B4134-B5B8-4157-8AA3-0C6CC0170694@yandex.ru> <20140427110312.GA10493@sniper> Message-ID: <4B45AAB2-6921-4762-A4B4-C202EF63415C@yandex.ru> Yeah, you're right. Thanks. On 27 Apr 2014, at 15:03, Roman Cheplyaka wrote: > GHC doesn't have a difficulty translating between > > a -> forall s. ST s z > > and > > forall s. a -> ST s z > > This is easy to verify: > > Prelude> :m +Control.Monad.ST > Prelude Control.Monad.ST> :set -XRankNTypes > Prelude Control.Monad.ST> let f :: forall a . a -> forall s. ST s a; f = undefined > Prelude Control.Monad.ST> :t f > f :: a -> ST s a > > (and vice versa) > > The real problem is that both examples of inference require impredicative > instantiation: > >> therefore (a -> b) ~ (forall s. ST s z) -> z >> therefore a ~ forall s. ST s z, b ~ z > > in the first case, and > >> therefore b -> c ~ (forall s. ST s z) -> z >> therefore b ~ (forall s. ST s z), c ~ z > > in the second case. The difference between ($) and (.) is that there's a special > case in GHC's type checker for ($) which enables impredicative instantiation, > which was added exactly for the common use case of > > runST $ ... > > Such a rule wasn't added for (.), presumably because people write runST . f much > less often, and there weren't as many complaints (perhaps any at all) about (.) > not working with runST. > > Roman > > > * MigMit [2014-04-27 14:21:27+0400] >> runST uses forall. It messes up type inference (and yes, type inference is at play even if top-level function has type signature). >> >> See, if you write "runST $ f x", then GHC deduces this: >> >> ($) :: (a -> b) -> a -> b >> runST :: (forall s. ST s z) -> z >> therefore (a -> b) ~ (forall s. ST s z) -> z >> therefore a ~ forall s. ST s z, b ~ z >> and also f x :: a >> therefore f x :: forall s. ST s z >> >> Then it goes on checking that f x :: forall s. ST s z actually makes sense, which it does by first stripping away forall and checking that f x :: ST s z is sound. >> >> If you write (runST . f) x, then what GHC sees is >> >> (.) :: (b -> c) -> (a -> b) -> (a -> c) >> runST :: (forall s. ST s z) -> z >> therefore b -> c ~ (forall s. ST s z) -> z >> therefore b ~ (forall s. ST s z), c ~ z >> and also f :: a -> b >> therefore f :: a -> forall s. ST s z >> >> Unfortunately, f is of type a -> ST s z, or, if you quantify explicitly, forall s. a -> ST s z. These two types don't match. If you write type arguments explicitly, like you'll do in Agda, you'd have >> >> (s :: Type) -> a -> ST s z >> >> vs >> >> a -> (s :: Type) -> ST s z >> >> So they are different. >> >> I don't think there is an easy way to fix that, apart from using "$". >> >> On 27 Apr 2014, at 12:27, Kai Zhang wrote: >> >>> Hi Cafe, >>> >>> I don't understand why this doesn't work: >>> >>> import qualified Data.Vector.Generic as G >>> import Control.Monad.ST >>> >>> test :: G.Vector v a => v a -> v a >>> test x = runST . (>>= G.freeze) . G.thaw $ x >>> >>> But if I replace "." with "$", it can compile. >>> >>> test x = runST $ (>>= G.freeze) . G.thaw $ x >>> >>> I originally though f $ g x can always be written as f . g $ x >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe From allbery.b at gmail.com Sun Apr 27 15:13:17 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 27 Apr 2014 11:13:17 -0400 Subject: [Haskell-cafe] Why this doesn't work? In-Reply-To: <20140427110312.GA10493@sniper> References: <730B4134-B5B8-4157-8AA3-0C6CC0170694@yandex.ru> <20140427110312.GA10493@sniper> Message-ID: On Sun, Apr 27, 2014 at 7:03 AM, Roman Cheplyaka wrote: > runST $ ... > > Such a rule wasn't added for (.), presumably because people write runST . > f much > less often, and there weren't as many complaints (perhaps any at all) > about (.) > not working with runST. > That, and because they kept trying to fix the real problem (and missing, a lot). A search of the archives will find various Simons grumping about getting it to work right. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Apr 27 15:32:49 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 27 Apr 2014 11:32:49 -0400 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: On Sun, Apr 27, 2014 at 7:45 AM, Rustom Mody wrote: > 1. I'd like to underscore the 'arbitrary'. Why is ASCII any less > arbitrary -- apart from an increasingly irrelevant historical accident -- > than Arabic, Bengali, Cyrillic, Deseret? [Hint: Whats the A in ASCII?] By > contrast math may at least have some pretensions to universality? Math notations are not as universal as many would like to think, sadly. And I am not sure the historical accident is really irrelevant; as the same "accident" was involved in most of the computer languages and protocols we use daily, I would not be at all surprised to find that there are subtle dependencies buried in the whole mess --- similar to how (most... sigh) humans pick up language and culture signals as children too young to apply any kind of critical analysis to it, and can have real problems trying to eradicate or modify them later. (Yes, languages can be fixed. But how many tools do you use when working with them? It's almost certainly more than the ones that immediately come to mind or are listed on e.g. Hackage. In particular, that ligature may be great in your editor and unfortunate when you pop a terminal and grep for it --- especially if you start extending this to other languages so you need a different set of ligatures [a different font!] for each language....) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustompmody at gmail.com Sun Apr 27 16:58:17 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Sun, 27 Apr 2014 22:28:17 +0530 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: On Sun, Apr 27, 2014 at 9:02 PM, Brandon Allbery wrote: > On Sun, Apr 27, 2014 at 7:45 AM, Rustom Mody wrote: > >> 1. I'd like to underscore the 'arbitrary'. Why is ASCII any less >> arbitrary -- apart from an increasingly irrelevant historical accident -- >> than Arabic, Bengali, Cyrillic, Deseret? [Hint: Whats the A in ASCII?] By >> contrast math may at least have some pretensions to universality? > > > Math notations are not as universal as many would like to think, sadly. > > And I am not sure the historical accident is really irrelevant; as the > same "accident" was involved in most of the computer languages and > protocols we use daily, I would not be at all surprised to find that there > are subtle dependencies buried in the whole mess --- similar to how > (most... sigh) humans pick up language and culture signals as children too > young to apply any kind of critical analysis to it, and can have real > problems trying to eradicate or modify them later. (Yes, languages can be > fixed. But how many tools do you use when working with them? It's almost > certainly more than the ones that immediately come to mind or are listed on > e.g. Hackage. In particular, that ligature may be great in your editor and > unfortunate when you pop a terminal and grep for it --- especially if you > start extending this to other languages so you need a different set of > ligatures [a different font!] for each language....) > > Nice point! And as I said above that Pandora's box is already wide open for current Haskell. [And python and probably most modern languages] Can we reverse it?? Witness: ---------------------- $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> let (fine,?ne) = (1,2) Prelude> (fine,?ne) (1,2) Prelude> --------------------- If you had the choice would you allow that f-i ligature to be thus confusable with the more normal fi? I probably wouldn't but nobody is asking us and the water that's flowed under the bridge cannot be 'flowed' backwards (to the best of my knowledge!) In case that seems far-fetched consider the scenario: 1. Somebody loads (maybe innocently) the code involving variables like 'fine' into a 'ligature-happy 'IDE/editor' 2. The editor quietly changes all the fine to ?ne. 3. Since all those variables are in local scope nothing untoward is noticed 4. Until someone loads it into an 'old-fashioned' editor... and then... Would you like to be on the receiving end on such 'fun'? IOW the choice "Ascii is the universal bedrock of computers -- best to stick with it" vs "Ascii is arbitrary and parochial and we SHOULD move on" is not a choice at all. We (ie OSes, editors, languages) have all already moved on. And moved on in a particularly ill-considered way. For example there used to be the minor nuisance that linux filesystems were typically case-sensitive, windows case-insensitive. Now with zillions of new confusables like the Latin vs Cyrillic ? vs a -- well we have quite a mess! Embracing math in a well-considered and systematic way does not increase the mess; it can even reduce it. My 2 (truly American) ? Rusi PS Someone spoke of APL and someone else said Agda/Idris may be more relevant. I wonder how many of the younger generation have heard of squiggol? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathangfischoff at gmail.com Sun Apr 27 19:47:05 2014 From: jonathangfischoff at gmail.com (Jonathan Fischoff) Date: Sun, 27 Apr 2014 12:47:05 -0700 Subject: [Haskell-cafe] BayHac 2014 (May 16-18) Reminder Message-ID: This is your three week reminder for the up coming Bay Area Haskell Hackathon, held Friday May 16 to Sunday May 18 at the Hacker Dojo in Mountain View CA. Here is the signup sheet: https://docs.google.com/forms/d/16QEHqAioGQeHHOlnMTEmjdgtO4YNN2_Qc-rbgLOFatU/viewform BayHac is time for Haskellers of all skill levels to collaborate on projects, disseminate knowledge and socialize. This year, we responded to requests to have more teaching, and there will be 15 classes in addition to experience reports, demos, and lightning talks. More information can be found on the wiki: http://www.haskell.org/haskellwiki/BayHac2014 Happy Hacking, Jonathan From mail at nh2.me Sun Apr 27 20:10:00 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Sun, 27 Apr 2014 21:10:00 +0100 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> Message-ID: <535D6418.5040304@nh2.me> On 27/04/14 03:28, John Lato wrote: > No, I mean this: > >> V.forM_ (V.enumFromN 1 n) Hey John, unfortunately that's not fast, and it eats all the RAMs. Here comes the sad comparison of looping in Haskell: - loop (maxBound :: Word32) 3 seconds, constant space - forM_ [0..maxBound :: Word32] 36 seconds, constant space - V.forM_ (V.enumFromTo 0 (maxBound :: Word32)) 37 seconds, constant space - V.forM_ (V.enumFromN 0 (fromIntegral (maxBound :: Word32))) linear space -> crashes All loops execute `return ()`. :( From ian.tuomi at aalto.fi Sun Apr 27 20:57:03 2014 From: ian.tuomi at aalto.fi (Ian Tuomi) Date: Sun, 27 Apr 2014 23:57:03 +0300 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: <376C1879-963D-455D-A78B-0FB0470FC3FB@aalto.fi> On 27 Apr 2014, at 19:58, Rustom Mody wrote: > If you had the choice would you allow that f-i ligature to be thus > confusable with the more normal fi? I probably wouldn't but nobody is > asking us and the water that's flowed under the bridge cannot be > 'flowed' > backwards (to the best of my knowledge!) > > In case that seems far-fetched consider the scenario: > 1. Somebody loads (maybe innocently) the code involving variables like > 'fine' > into a 'ligature-happy 'IDE/editor' > 2. The editor quietly changes all the fine to ?ne. > 3. Since all those variables are in local scope nothing untoward is > noticed > 4. Until someone loads it into an 'old-fashioned' editor... and > then... I develop Hasklig, and have enjoyed the discussion about the pros and cons of ligatures in coding fonts. However, I really must protest this line of reasoning since it is based on false premises. As an opentype feature, ligatures have nothing to do with the 'fi' and 'fl' unicode points, (which are legacy only, and heavily discouraged by the unicode consortium), or with unicode at all. The encoding of the file could be pure ASCII for all the ligatures care. The font used changes how the text looks, and nothing else. When speaking of special unicode symbols in code, I agree with most objections raised against them :) br, Ian P.S. Sorry for potential repost - I'm getting automatic rejects From jwlato at gmail.com Sun Apr 27 22:18:13 2014 From: jwlato at gmail.com (John Lato) Date: Sun, 27 Apr 2014 15:18:13 -0700 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <535D6418.5040304@nh2.me> References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> <535D6418.5040304@nh2.me> Message-ID: On Apr 27, 2014 1:10 PM, "Niklas Hamb?chen" wrote: > > On 27/04/14 03:28, John Lato wrote: > > No, I mean this: > > > >> V.forM_ (V.enumFromN 1 n) > > Hey John, > > unfortunately that's not fast, and it eats all the RAMs. > > Here comes the sad comparison of looping in Haskell: > > - loop (maxBound :: Word32) > 3 seconds, constant space > > - forM_ [0..maxBound :: Word32] > 36 seconds, constant space > > - V.forM_ (V.enumFromTo 0 (maxBound :: Word32)) > 37 seconds, constant space > > - V.forM_ (V.enumFromN 0 (fromIntegral (maxBound :: Word32))) > linear space -> crashes > > All loops execute `return ()`. Hmm. Are you using regular vectors or unboxed? Also what sort of crash? Is it a stack space overflow or are you on a 32-bit platform? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Sun Apr 27 22:37:20 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Sun, 27 Apr 2014 23:37:20 +0100 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> <535D6418.5040304@nh2.me> Message-ID: <535D86A0.3010200@nh2.me> On 27/04/14 23:18, John Lato wrote:> Hmm. Are you using regular vectors or unboxed? Also what sort of crash? > Is it a stack space overflow or are you on a 32-bit platform? I'm using regular Data.Vector as V. It's just eating my 8GB and then I kill it (or let my ulimit do it). It can't be the stack space since I'm on 7.6 where stack space is limited by default. It's on 64 bit Linux. From jwlato at gmail.com Sun Apr 27 23:22:26 2014 From: jwlato at gmail.com (John Lato) Date: Sun, 27 Apr 2014 16:22:26 -0700 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <535D86A0.3010200@nh2.me> References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> <535D6418.5040304@nh2.me> <535D86A0.3010200@nh2.me> Message-ID: On Sun, Apr 27, 2014 at 3:37 PM, Niklas Hamb?chen wrote: > On 27/04/14 23:18, John Lato wrote:> Hmm. Are you using regular vectors > or unboxed? Also what sort of crash? > > Is it a stack space overflow or are you on a 32-bit platform? > > I'm using regular Data.Vector as V. > Are unboxed vectors faster? My rule of thumb is to use them over Data.Vector whenever possible. > It's just eating my 8GB and then I kill it (or let my ulimit do it). It > can't be the stack space since I'm on 7.6 where stack space is limited > by default. > > It's on 64 bit Linux. > I would expect it's because you never force the argument. With `enumFromTo` the argument is forced because it needs to be checked for termination, but `enumFromN` is probably building up a big chain of thunks. I guess for this case `enumFromN` has no benefit over `enumFromTo` because the intention is to create a single loop instead of actually allocating the vector, so the warning in the documentation doesn't necessarily apply. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Sun Apr 27 23:49:05 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Mon, 28 Apr 2014 00:49:05 +0100 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> <535D6418.5040304@nh2.me> <535D86A0.3010200@nh2.me> Message-ID: <535D9771.4060201@nh2.me> On 28/04/14 00:22, John Lato wrote: > Are unboxed vectors faster? My rule of thumb is to use them over > Data.Vector whenever possible. I haven't checked yet, but should it matter? Because my goal is that the vector never be created *at all*, and boxed or not shouldn't make a difference on that! > I would expect it's because you never force the argument. With > `enumFromTo` the argument is forced because it needs to be checked for > termination, but `enumFromN` is probably building up a big chain of > thunks. I guess for this case `enumFromN` has no benefit over > `enumFromTo` because the intention is to create a single loop instead of > actually allocating the vector, so the warning in the documentation > doesn't necessarily apply. Also haven't checked that yet, but I suspect that instead of something thunk-related, the thing plainly allocates the vector. Just to clarify: `V.enumFromTo` works much better than `V.enumFromN` because in contrast to the latter it doesn't actually try to create the fully sized vector. From conrad at metadecks.org Mon Apr 28 00:00:00 2014 From: conrad at metadecks.org (Conrad Parker) Date: Mon, 28 Apr 2014 10:00:00 +1000 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <535D9771.4060201@nh2.me> References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> <535D6418.5040304@nh2.me> <535D86A0.3010200@nh2.me> <535D9771.4060201@nh2.me> Message-ID: Niklas, just for fun, and seeing as your goal is to make something that works elegeantly and efficiently with list syntax, how about making a new type that's an instance of OverloadedLists but never actually allocates anything, so you can basically desugar "X.forM_ [a..b]" to your loop function? Conrad. On 28 April 2014 09:49, Niklas Hamb?chen wrote: > On 28/04/14 00:22, John Lato wrote: > > Are unboxed vectors faster? My rule of thumb is to use them over > > Data.Vector whenever possible. > > I haven't checked yet, but should it matter? > Because my goal is that the vector never be created *at all*, and boxed > or not shouldn't make a difference on that! > > > I would expect it's because you never force the argument. With > > `enumFromTo` the argument is forced because it needs to be checked for > > termination, but `enumFromN` is probably building up a big chain of > > thunks. I guess for this case `enumFromN` has no benefit over > > `enumFromTo` because the intention is to create a single loop instead of > > actually allocating the vector, so the warning in the documentation > > doesn't necessarily apply. > > Also haven't checked that yet, but I suspect that instead of something > thunk-related, the thing plainly allocates the vector. > > Just to clarify: `V.enumFromTo` works much better than `V.enumFromN` > because in contrast to the latter it doesn't actually try to create the > fully sized vector. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Mon Apr 28 00:34:09 2014 From: jwlato at gmail.com (John Lato) Date: Sun, 27 Apr 2014 17:34:09 -0700 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <535D9771.4060201@nh2.me> References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> <535D6418.5040304@nh2.me> <535D86A0.3010200@nh2.me> <535D9771.4060201@nh2.me> Message-ID: On Sun, Apr 27, 2014 at 4:49 PM, Niklas Hamb?chen wrote: > On 28/04/14 00:22, John Lato wrote: > > Are unboxed vectors faster? My rule of thumb is to use them over > > Data.Vector whenever possible. > > I haven't checked yet, but should it matter? > Because my goal is that the vector never be created *at all*, and boxed > or not shouldn't make a difference on that! > It can make a difference in that, with unboxed vectors, the compiler can statically determine that it is able to use unboxed values, and therefore is more likely to do so. Having finally broken down and run some tests, I can report that on my system using V.enumFromTo with unboxed vectors results in the same performance as the hand-written loop. > > > I would expect it's because you never force the argument. With > > `enumFromTo` the argument is forced because it needs to be checked for > > termination, but `enumFromN` is probably building up a big chain of > > thunks. I guess for this case `enumFromN` has no benefit over > > `enumFromTo` because the intention is to create a single loop instead of > > actually allocating the vector, so the warning in the documentation > > doesn't necessarily apply. > > Also haven't checked that yet, but I suspect that instead of something > thunk-related, the thing plainly allocates the vector. > > Just to clarify: `V.enumFromTo` works much better than `V.enumFromN` > because in contrast to the latter it doesn't actually try to create the > fully sized vector. > I believe that if you check this with ghc-7.6.3 and -O2, you will discover that my analysis is correct :) However, I like Conrad's suggestion, looks like an interesting library. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Mon Apr 28 01:16:39 2014 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 28 Apr 2014 13:16:39 +1200 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: <5BDAE5D1-E900-4EC9-B13F-E6DDB2AD87C1@cs.otago.ac.nz> On 25/04/2014, at 5:15 AM, Rustom Mody wrote: > x ? y = divMod x y This one looks wrong to me. In common usage, ? indicates plain old division, e.g., 3?2 = 1?. See for example http://en.wikipedia.org/wiki/Table_of_mathematical_symbols One possibility would be > x ? y = x / y :: Rational From conrad at metadecks.org Mon Apr 28 01:31:24 2014 From: conrad at metadecks.org (Conrad Parker) Date: Mon, 28 Apr 2014 11:31:24 +1000 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: <376C1879-963D-455D-A78B-0FB0470FC3FB@aalto.fi> References: <376C1879-963D-455D-A78B-0FB0470FC3FB@aalto.fi> Message-ID: On 28 April 2014 06:57, Ian Tuomi wrote: > On 27 Apr 2014, at 19:58, Rustom Mody wrote: > >> If you had the choice would you allow that f-i ligature to be thus >> confusable with the more normal fi? I probably wouldn't but nobody is >> asking us and the water that's flowed under the bridge cannot be 'flowed' >> backwards (to the best of my knowledge!) >> >> In case that seems far-fetched consider the scenario: >> 1. Somebody loads (maybe innocently) the code involving variables like >> 'fine' >> into a 'ligature-happy 'IDE/editor' >> 2. The editor quietly changes all the fine to ?ne. >> 3. Since all those variables are in local scope nothing untoward is >> noticed >> 4. Until someone loads it into an 'old-fashioned' editor... and then... >> > > I develop Hasklig, and have enjoyed the discussion about the pros and cons > of ligatures in coding fonts. However, I really must protest this line of > reasoning since it is based on false premises. > > As an opentype feature, ligatures have nothing to do with the 'fi' and > 'fl' unicode points, (which are legacy only, and heavily discouraged by the > unicode consortium), or with unicode at all. The encoding of the file could > be pure ASCII for all the ligatures care. The font used changes how the > text looks, and nothing else. > > When speaking of special unicode symbols in code, I agree with most > objections raised against them :) > Ian, thanks for hasklig. My first thought when I saw it was that hopefully it would assuage the annoying promoters of unicode overreach. Conrad. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Mon Apr 28 02:05:40 2014 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 28 Apr 2014 14:05:40 +1200 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: <86wqedmuj5.fsf@gmail.com> Message-ID: <06608A6A-FDAF-4097-97E6-5DAB802D6146@cs.otago.ac.nz> On 26/04/2014, at 1:30 AM, Rustom Mody wrote: > On Fri, Apr 25, 2014 at 6:32 PM, Chris Warburton wrote: > Rustom Mody writes: > > > As for APL, it failed for various reasons eg > > - mixing up assembly language (straight line code with gotos) with > > functional idioms > > - the character set was a major hurdle in the 60s. Thats not an issue today > > when most OSes/editors are unicode compliant I strongly suspect that the failure of APL had very little to do with the character set. When APL was introduced, the character set was just a matter of dropping in a different golf-ball. Later, it was just bits on a screen. Heck in 1984 I was using C and LaTeX on an IBM mainframe where the terminals displayed curly braces as spaces, and oddly enough that didn't kill C... In any case, it was possible to enter any arbitrary APL text using straight ASCII, so that was no great problem. There were a number of much more serious issues with APL. (1) In "classic" APL everything is an n-dimensional array, either an array of characters or an array of (complex) numbers. An absolutely regular array. Want to process a collection of records where some of the fields are strings? No can do. Want to process a collection of strings of different length? No can do: you must use a 2-dimensional array, padding all the strings to the same length. Want type checking? Hysterical laughter. APL2 "fixed" this by introducing nested arrays. This is powerful, but occasionally clumsy. And it is positional, not named. You *can* represent trees, you can represent records with mixed fields, you can do all sorts of stuff. But it's positional, not named. (2) There aren't _that_ many APL symbols, and it didn't take too long to learn them, and once you did, they weren't that hard to remember. (Although the use of the horseshoe symbols in APL2 strikes me as *ab*use.) Problem is, a whole lot of other things were done with numbers. Here's the trig functions: 0 ? x sqrt(1-x**2) 1 ? x sin x ?1 ? x arcsin x 2 ? x cos x ?2 ? x arccos x 3 ? x tan x ?3 ? x arctan x 4 ? x sqrt(x**2+1) ?4 ? x sqrt(x**2-1) 5 ? x sinh x ?5 ? x arcsinh x 6 ? x cosh x ?6 ? x arccosh x 7 ? x tanh x ?7 ? x arctanh x Who thought _that_ was a good idea? Well, presumably it was the same person who introduced the "I-beam functions". A range of system functions (time of day, cpu time used, space available, ...) were distinguished by *numbers*. (3) Which brings me to the dialect problem. No two systems had the *same* set of I-beam functions. You couldn't even rely on two systems having the same *kind* of approach to files. There were several commercial APL systems, and they weren't priced for the hobbyist or student. From mail at nh2.me Mon Apr 28 02:23:54 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Mon, 28 Apr 2014 03:23:54 +0100 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> <535D6418.5040304@nh2.me> <535D86A0.3010200@nh2.me> <535D9771.4060201@nh2.me> Message-ID: <535DBBBA.7010703@nh2.me> I've just uploaded my benchmarks to https://github.com/nh2/loop. Please take a look. There are some interesting results. The first thing I don't understand at all is: http://htmlpreview.github.io/?https://github.com/nh2/loop/blob/master/results/bench.html See how w32/loop and w32/unsafeLoop are equally fast. Then look at http://htmlpreview.github.io/?https://github.com/nh2/loop/blob/master/results/bench-traverse-w32.html Here I run the same thing over the whole of Word32. See how `loop` is faster here than `unsafeLoop`? How does that make sense? Next thing: It seems that V.enumFromTo and V.fromList are actually the same: http://hackage.haskell.org/package/vector-0.10.9.1/docs/src/Data-Vector-Fusion-Stream-Monadic.html#enumFromTo However in my benchmark, at least for `Int`, the performance is different - am I overlooking something? On 28/04/14 01:34, John Lato wrote: > It can make a difference in that, with unboxed vectors, the compiler can > statically determine that it is able to use unboxed values, and > therefore is more likely to do so. Having finally broken down and run > some tests, I can report that on my system using V.enumFromTo with > unboxed vectors results in the same performance as the hand-written loop. I cannot see a difference between Vector.enumFromTo and Vector.Unboxed.enumFromTo in my benchmark. Vector.enumFromTo is as fast as the hand-written loop, but only for `Int`. For `Word32`, it is 5 times slower. Any idea why? > > I would expect it's because you never force the argument. With > > `enumFromTo` the argument is forced because it needs to be checked for > > termination, but `enumFromN` is probably building up a big chain of > > thunks. I guess for this case `enumFromN` has no benefit over > > `enumFromTo` because the intention is to create a single loop > instead of > > actually allocating the vector, so the warning in the documentation > > doesn't necessarily apply. > > Also haven't checked that yet, but I suspect that instead of something > thunk-related, the thing plainly allocates the vector. > > Just to clarify: `V.enumFromTo` works much better than `V.enumFromN` > because in contrast to the latter it doesn't actually try to create the > fully sized vector. > > > I believe that if you check this with ghc-7.6.3 and -O2, you will > discover that my analysis is correct :) Ok, I think I understand now what you mean. From mail at nh2.me Mon Apr 28 02:25:25 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Mon, 28 Apr 2014 03:25:25 +0100 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> <535D6418.5040304@nh2.me> <535D86A0.3010200@nh2.me> <535D9771.4060201@nh2.me> Message-ID: <535DBC15.8050507@nh2.me> Hey Conrad! That sounds like a nice idea. I might have a look at it after I have actually figured out what the fastest/best way is (see the benchmarks I just posted). Niklas On 28/04/14 01:00, Conrad Parker wrote: > Niklas, > > just for fun, and seeing as your goal is to make something that works > elegeantly and efficiently with list syntax, how about making a new type > that's an instance of OverloadedLists but never actually allocates > anything, so you can basically desugar "X.forM_ [a..b]" to your loop > function? > > Conrad. From ok at cs.otago.ac.nz Mon Apr 28 02:33:26 2014 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 28 Apr 2014 14:33:26 +1200 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: <40E6988C-56AB-4642-AA04-A73CEAC12F08@cs.otago.ac.nz> On 27/04/2014, at 9:30 PM, Ben Franksen wrote: > The main problem with special Unicode characters, as I see it, is that it is > no longer possible to distinguish characters unambiguously just by looking > at them. "No longer"? Hands up all the people old enough to have used "coding forms". Yes, children, there was a time when programmers wrote their programs on printed paper forms (sort of like A4 tipped sideways) so that the keypunch girls (not my sexism, historical accuracy) knew exactly which column each character went in. And at the top of each sheet was a row of boxes for you to show how you wrote 2 Z 7 1 I ! 0 O and the like. For that matter, I recall a PhD thesis from the 80s in which the author spent a page grumbling about the difficulty of telling commas and semicolons apart... > Apart from questions of maintainability, this is also a potential > security problem: it enables an attacker to slip in malicious code simply by > importing a module whose name looks like a well known safe module. In a big > and complex piece of software, such an attack might not be spotted for some > time. Again, considering the possibilities of "1" "i" "l", I don't think we actually have a new problem here. Presumably this can be addressed by tools: "here is are some modules, tell me what exactly they depend on" not entirely unlike ldd(1). Of course, the gotofail bug shows that it's not enough to _have_ tools like that, you have to use them and review the results periodically. From rustompmody at gmail.com Mon Apr 28 04:23:39 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Mon, 28 Apr 2014 09:53:39 +0530 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: <5BDAE5D1-E900-4EC9-B13F-E6DDB2AD87C1@cs.otago.ac.nz> References: <5BDAE5D1-E900-4EC9-B13F-E6DDB2AD87C1@cs.otago.ac.nz> Message-ID: On Mon, Apr 28, 2014 at 6:46 AM, Richard A. O'Keefe wrote: > > On 25/04/2014, at 5:15 AM, Rustom Mody wrote: > > x ? y = divMod x y > > This one looks wrong to me. > In common usage, ? indicates plain old division, > e.g., 3?2 = 1?. > See for example http://en.wikipedia.org/wiki/Table_of_mathematical_symbols > > One possibility would be > > > x ? y = x / y :: Rational > > > Thanks Richard for (as usual!) look at that list with a fine-toothed comb I started with writing a corresponding list for python: http://blog.languager.org/2014/04/unicoded-python.html As you will see I mention there that ? mapped to divMod is one but hardly the only possibility. That list is mostly about math, not imperative features and so carries over from python to haskell mostly unchanged. Please (if you have 5 minutes) glance at it and give me your comments. I may then finish a similar one for Haskell. Thanks Rusi -- http://www.the-magus.in http://blog.languager.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Mon Apr 28 04:24:38 2014 From: jwlato at gmail.com (John Lato) Date: Sun, 27 Apr 2014 21:24:38 -0700 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <535DBBBA.7010703@nh2.me> References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> <535D6418.5040304@nh2.me> <535D86A0.3010200@nh2.me> <535D9771.4060201@nh2.me> <535DBBBA.7010703@nh2.me> Message-ID: On Sun, Apr 27, 2014 at 7:23 PM, Niklas Hamb?chen wrote: > I've just uploaded my benchmarks to https://github.com/nh2/loop. > > Please take a look. There are some interesting results. > > > The first thing I don't understand at all is: > > > > http://htmlpreview.github.io/?https://github.com/nh2/loop/blob/master/results/bench.html > > See how w32/loop and w32/unsafeLoop are equally fast. Then look at > > > > http://htmlpreview.github.io/?https://github.com/nh2/loop/blob/master/results/bench-traverse-w32.html > > Here I run the same thing over the whole of Word32. > See how `loop` is faster here than `unsafeLoop`? How does that make sense? > Huh? In the comments you wrote: -- Note that some types (e.g. Word32) have bounds checks even for -- `toEnum`. Doesn't that explain it? For Int, toEnum/fromEnum is a noop, but on Word32 it's not. > Next thing: > > It seems that V.enumFromTo and V.fromList are actually the same: > > > > http://hackage.haskell.org/package/vector-0.10.9.1/docs/src/Data-Vector-Fusion-Stream-Monadic.html#enumFromTo > > However in my benchmark, at least for `Int`, the performance is > different - am I overlooking something? > Probably with V.fromList, the list gets floated out? Just guessing, check the core! > > > On 28/04/14 01:34, John Lato wrote: > > It can make a difference in that, with unboxed vectors, the compiler can > > statically determine that it is able to use unboxed values, and > > therefore is more likely to do so. Having finally broken down and run > > some tests, I can report that on my system using V.enumFromTo with > > unboxed vectors results in the same performance as the hand-written loop. > > I cannot see a difference between Vector.enumFromTo and > Vector.Unboxed.enumFromTo in my benchmark. > > Vector.enumFromTo is as fast as the hand-written loop, but only for > `Int`. For `Word32`, it is 5 times slower. Any idea why? > Ahh, you made me look at the core again. I think this is related to your observation about V.enumFromTo being the same as V.fromList. With Word32 the generated core shows that this goes via a list representation instead of a nice loop. Which makes me suspect there's some RULE that applies to Stream.enumFromTo that is firing in the first case but not the second. And if I build both versions with -ddump-rule-firings, indeed I see that the Int version has Rule fired: enumFromTo [Stream] With nothing comparable for the Word32 version. I'd imagine if you grep for that in the Vector sources, you'd find something interesting. The EnumFromN version does not seem to suffer from this (but again it's necessary to evaluate the argument). -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at functionaljobs.com Mon Apr 28 06:00:01 2014 From: sean at functionaljobs.com (Functional Jobs) Date: Mon, 28 Apr 2014 02:00:01 -0400 Subject: [Haskell-cafe] New Functional Programming Job Opportunities Message-ID: <535dee69e50a3@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: functional software developer at OpinionLab http://functionaljobs.com/jobs/8706-functional-software-developer-at-opinionlab Cheers, Sean Murphy FunctionalJobs.com From markjordanthom at gmail.com Mon Apr 28 17:06:01 2014 From: markjordanthom at gmail.com (Mark Thom) Date: Mon, 28 Apr 2014 11:06:01 -0600 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> <535D6418.5040304@nh2.me> <535D86A0.3010200@nh2.me> <535D9771.4060201@nh2.me> <535DBBBA.7010703@nh2.me> Message-ID: Has anyone written a blog post to the effect of "Haskell: The Slow Parts"? Or a heuristic for reliably identifying them, maybe? It sounds as though I could really benefit from it. I had no idea about forM. On Sun, Apr 27, 2014 at 10:24 PM, John Lato wrote: > On Sun, Apr 27, 2014 at 7:23 PM, Niklas Hamb?chen wrote: > >> I've just uploaded my benchmarks to https://github.com/nh2/loop. >> >> Please take a look. There are some interesting results. >> >> >> The first thing I don't understand at all is: >> >> >> >> http://htmlpreview.github.io/?https://github.com/nh2/loop/blob/master/results/bench.html >> >> See how w32/loop and w32/unsafeLoop are equally fast. Then look at >> >> >> >> http://htmlpreview.github.io/?https://github.com/nh2/loop/blob/master/results/bench-traverse-w32.html >> >> Here I run the same thing over the whole of Word32. >> See how `loop` is faster here than `unsafeLoop`? How does that make sense? >> > > Huh? In the comments you wrote: > > -- Note that some types (e.g. Word32) have bounds checks even for > -- `toEnum`. > > > Doesn't that explain it? For Int, toEnum/fromEnum is a noop, but on > Word32 it's not. > > >> Next thing: >> >> It seems that V.enumFromTo and V.fromList are actually the same: >> >> >> >> http://hackage.haskell.org/package/vector-0.10.9.1/docs/src/Data-Vector-Fusion-Stream-Monadic.html#enumFromTo >> >> However in my benchmark, at least for `Int`, the performance is >> different - am I overlooking something? >> > > Probably with V.fromList, the list gets floated out? Just guessing, check > the core! > >> >> >> On 28/04/14 01:34, John Lato wrote: >> > It can make a difference in that, with unboxed vectors, the compiler can >> > statically determine that it is able to use unboxed values, and >> > therefore is more likely to do so. Having finally broken down and run >> > some tests, I can report that on my system using V.enumFromTo with >> > unboxed vectors results in the same performance as the hand-written >> loop. >> >> I cannot see a difference between Vector.enumFromTo and >> Vector.Unboxed.enumFromTo in my benchmark. >> >> Vector.enumFromTo is as fast as the hand-written loop, but only for >> `Int`. For `Word32`, it is 5 times slower. Any idea why? >> > > Ahh, you made me look at the core again. I think this is related to your > observation about V.enumFromTo being the same as V.fromList. With Word32 > the generated core shows that this goes via a list representation instead > of a nice loop. Which makes me suspect there's some RULE that applies to > Stream.enumFromTo that is firing in the first case but not the second. And > if I build both versions with -ddump-rule-firings, indeed I see that the > Int version has > > Rule fired: enumFromTo [Stream] > > With nothing comparable for the Word32 version. I'd imagine if you grep > for that in the Vector sources, you'd find something interesting. > > The EnumFromN version does not seem to suffer from this (but again it's > necessary to evaluate the argument). > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dons00 at gmail.com Mon Apr 28 17:08:45 2014 From: dons00 at gmail.com (Don Stewart) Date: Mon, 28 Apr 2014 18:08:45 +0100 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> <535D6418.5040304@nh2.me> <535D86A0.3010200@nh2.me> <535D9771.4060201@nh2.me> <535DBBBA.7010703@nh2.me> Message-ID: http://book.realworldhaskell.org/read/profiling-and-optimization.html Would be a start On Monday, 28 April 2014, Mark Thom wrote: > Has anyone written a blog post to the effect of "Haskell: The Slow Parts"? > Or a heuristic for reliably identifying them, maybe? It sounds as though I > could really benefit from it. I had no idea about forM. > > > On Sun, Apr 27, 2014 at 10:24 PM, John Lato > > wrote: > >> On Sun, Apr 27, 2014 at 7:23 PM, Niklas Hamb?chen >> > wrote: >> >>> I've just uploaded my benchmarks to https://github.com/nh2/loop. >>> >>> Please take a look. There are some interesting results. >>> >>> >>> The first thing I don't understand at all is: >>> >>> >>> >>> http://htmlpreview.github.io/?https://github.com/nh2/loop/blob/master/results/bench.html >>> >>> See how w32/loop and w32/unsafeLoop are equally fast. Then look at >>> >>> >>> >>> http://htmlpreview.github.io/?https://github.com/nh2/loop/blob/master/results/bench-traverse-w32.html >>> >>> Here I run the same thing over the whole of Word32. >>> See how `loop` is faster here than `unsafeLoop`? How does that make >>> sense? >>> >> >> Huh? In the comments you wrote: >> >> -- Note that some types (e.g. Word32) have bounds checks even for >> >> -- `toEnum`. >> >> >> Doesn't that explain it? For Int, toEnum/fromEnum is a noop, but on >> Word32 it's not. >> >> >>> Next thing: >>> >>> It seems that V.enumFromTo and V.fromList are actually the same: >>> >>> >>> >>> http://hackage.haskell.org/package/vector-0.10.9.1/docs/src/Data-Vector-Fusion-Stream-Monadic.html#enumFromTo >>> >>> However in my benchmark, at least for `Int`, the performance is >>> different - am I overlooking something? >>> >> >> Probably with V.fromList, the list gets floated out? Just guessing, >> check the core! >> >>> >>> >>> On 28/04/14 01:34, John Lato wrote: >>> > It can make a difference in that, with unboxed vectors, the compiler >>> can >>> > statically determine that it is able to use unboxed values, and >>> > therefore is more likely to do so. Having finally broken down and run >>> > some tests, I can report that on my system using V.enumFromTo with >>> > unboxed vectors results in the same performance as the hand-written >>> loop. >>> >>> I cannot see a difference between Vector.enumFromTo and >>> Vector.Unboxed.enumFromTo in my benchmark. >>> >>> Vector.enumFromTo is as fast as the hand-written loop, but only for >>> `Int`. For `Word32`, it is 5 times slower. Any idea why? >>> >> >> Ahh, you made me look at the core again. I think this is related to your >> observation about V.enumFromTo being the same as V.fromList. With Word32 >> the generated core shows that this goes via a list representation instead >> of a nice loop. Which makes me suspect there's some RULE that applies to >> Stream.enumFromTo that is firing in the first case but not the second. And >> if I build both versions with -ddump-rule-firings, indeed I see that the >> Int version has >> >> Rule fired: enumFromTo [Stream] >> >> With nothing comparable for the Word32 version. I'd imagine if you grep >> for that in the Vector sources, you'd find something interesting. >> >> The EnumFromN version does not seem to suffer from this (but again it's >> necessary to evaluate the argument). >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai at kzhang.org Mon Apr 28 17:32:05 2014 From: kai at kzhang.org (Kai Zhang) Date: Mon, 28 Apr 2014 10:32:05 -0700 Subject: [Haskell-cafe] Why this doesn't work? In-Reply-To: References: <730B4134-B5B8-4157-8AA3-0C6CC0170694@yandex.ru> <20140427110312.GA10493@sniper> Message-ID: Thank you guys! These discussions were very helpful for me to figure out what is going on. On Sun, Apr 27, 2014 at 8:13 AM, Brandon Allbery wrote: > On Sun, Apr 27, 2014 at 7:03 AM, Roman Cheplyaka wrote: > >> runST $ ... >> >> Such a rule wasn't added for (.), presumably because people write runST . >> f much >> less often, and there weren't as many complaints (perhaps any at all) >> about (.) >> not working with runST. >> > > That, and because they kept trying to fix the real problem (and missing, a > lot). A search of the archives will find various Simons grumping about > getting it to work right. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From J.T.Jeuring at uu.nl Mon Apr 28 19:03:56 2014 From: J.T.Jeuring at uu.nl (Johan Jeuring) Date: Mon, 28 Apr 2014 21:03:56 +0200 Subject: [Haskell-cafe] FINAL CALL: Applied Functional Programming (AFP) Summerschool 7-18 July 2014, Utrecht, Netherlands In-Reply-To: References: Message-ID: One week to go until the registration deadline... -- Johan Jeuring > =========== AFP Summerschool 2014 =========== > > Applied Functional Programming (AFP) Summerschool > July 7-18, 2014 > Utrecht University, Department of Information and Computing Sciences > Utrecht, The Netherlands > > Summerschool & registration website: http://www.utrechtsummerschool.nl/courses/science/applied-functional-programming-in-haskell > AFP website with edition 2013 info : http://www.cs.uu.nl/wiki/USCS > contact : Uscs-afp at lists.science.uu.nl > > *** > > The 2014 edition of the Applied Functional Programming (AFP) > Summerschool in Utrecht, Netherlands will be held from 7-18 July 2014. > The summerschool teaches Haskell on both beginners and advanced levels > via lectures and lab exercises. More info can be found via the > references above, included here is an excerpt from the summerschool > website: > > ``Typed functional programming in Haskell allows for the development of > compact programs in minimal time and with maximal guarantees about > robustness and correctness. The course introduces Haskell as well as its > theoretical underpinnings such as typed lambda calculus, and > Damas-Milner type inference. There is ample opportunity to put this all > in practice during lab sessions. > > Typed functional programming languages allow for the development of > robust, concise programs in a short amount of time. The key advantages > are higher-order functions as an abstraction mechanism, and an advanced > type system for safety and reusability. This course introduces Haskell, > a state-of-the-art functional programming language, together with some > of its theoretical background, such as typed lambda calculi, referential > transparency, Damas-Milner type inference, type level programming, and > functional design patterns. > > We will combine this with applications of functional programming, > concentrating on topics such as language processing, building graphical > user interfaces, networking, databases, and programming for the web. The > goal of the course is not just to teach the programming language and > underlying theory, but also to learn about the Haskell community and to > get hands-on experience by doing lab exercises or a Haskell project of > your own.'' > > *** From robstewart57 at gmail.com Mon Apr 28 19:17:27 2014 From: robstewart57 at gmail.com (Rob Stewart) Date: Mon, 28 Apr 2014 20:17:27 +0100 Subject: [Haskell-cafe] Parse error when #ifdef pragma enabled Message-ID: Hi, I'm missing something obvious. I'd like to compile the following code. --8<---------------cut here---------------start------------->8--- {-# LANGUAGE CPP #-} module CPP where #ifdef CUDA import qualified Data.Array.Accelerate.CUDA as CUDA #endif f = "lolcats" --8<---------------cut here---------------end--------------->8--- Without the CUDA pragma, it's all good: $ ghc --make CPP.hs [1 of 1] Compiling CPP ( CPP.hs, CPP.o ) With the pragma thought, I get a compilation error: $ ghc --make CPP.hs -DCUDA [1 of 1] Compiling CPP ( CPP.hs, CPP.o ) CPP.hs:6:39: parse error on input `.' Where's my mistake? Thanks! -- Rob From hsyl20 at gmail.com Mon Apr 28 19:30:14 2014 From: hsyl20 at gmail.com (Sylvain Henry) Date: Mon, 28 Apr 2014 21:30:14 +0200 Subject: [Haskell-cafe] Parse error when #ifdef pragma enabled In-Reply-To: References: Message-ID: CUDA is substituted in > import qualified Data.Array.Acceletare.*CUDA* as *CUDA* with nothing. -Sylvain 2014-04-28 21:17 GMT+02:00 Rob Stewart : > Hi, > > I'm missing something obvious. I'd like to compile the following code. > > --8<---------------cut here---------------start------------->8--- > {-# LANGUAGE CPP #-} > > module CPP where > > #ifdef CUDA > import qualified Data.Array.Accelerate.CUDA as CUDA > #endif > > f = "lolcats" > --8<---------------cut here---------------end--------------->8--- > > Without the CUDA pragma, it's all good: > > $ ghc --make CPP.hs > [1 of 1] Compiling CPP ( CPP.hs, CPP.o ) > > With the pragma thought, I get a compilation error: > > $ ghc --make CPP.hs -DCUDA > [1 of 1] Compiling CPP ( CPP.hs, CPP.o ) > CPP.hs:6:39: parse error on input `.' > > Where's my mistake? > > Thanks! > > -- > Rob > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvollmert-lists at gmx.net Mon Apr 28 19:32:42 2014 From: rvollmert-lists at gmx.net (Robert Vollmert) Date: Mon, 28 Apr 2014 21:32:42 +0200 Subject: [Haskell-cafe] Parse error when #ifdef pragma enabled In-Reply-To: References: Message-ID: On Apr 28, 2014, at 21:17 , Rob Stewart wrote: > I'm missing something obvious. I'd like to compile the following code. > > --8<---------------cut here---------------start------------->8--- > {-# LANGUAGE CPP #-} > > module CPP where > > #ifdef CUDA > import qualified Data.Array.Accelerate.CUDA as CUDA > #endif > > f = "lolcats" > --8<---------------cut here---------------end--------------->8--- > > Without the CUDA pragma, it's all good: > > $ ghc --make CPP.hs > [1 of 1] Compiling CPP ( CPP.hs, CPP.o ) > > With the pragma thought, I get a compilation error: > > $ ghc --make CPP.hs -DCUDA > [1 of 1] Compiling CPP ( CPP.hs, CPP.o ) > CPP.hs:6:39: parse error on input `.' > > Where's my mistake? You?re defining ?CUDA? to be replaced by the empty string, so after running through CPP, you?ll have module CPP where import qualified Data.Array.Accelerate. as (Haven?t actually tested this, but it?s what cpp should do, and explains the error message nicely.) Try using ?-DWITHCUDA? or something similar? Cheers Rob From robstewart57 at gmail.com Mon Apr 28 20:35:54 2014 From: robstewart57 at gmail.com (Rob Stewart) Date: Mon, 28 Apr 2014 21:35:54 +0100 Subject: [Haskell-cafe] Parse error when #ifdef pragma enabled In-Reply-To: References: Message-ID: Hi Rob, On 28 April 2014 20:32, Robert Vollmert wrote: > You?re defining ?CUDA? to be replaced by the empty string, so after running through CPP, you?ll have > > module CPP where > import qualified Data.Array.Accelerate. as > > (Haven?t actually tested this, but it?s what cpp should do, and explains the error message nicely.) > > Try using ?-DWITHCUDA? or something similar? Works as you might expect, thanks! -- Rob From mail at nh2.me Tue Apr 29 00:35:29 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Tue, 29 Apr 2014 01:35:29 +0100 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> <535D6418.5040304@nh2.me> <535D86A0.3010200@nh2.me> <535D9771.4060201@nh2.me> <535DBBBA.7010703@nh2.me> Message-ID: <535EF3D1.7020103@nh2.me> On 28/04/14 05:24, John Lato wrote: > Doesn't that explain it? For Int, toEnum/fromEnum is a noop, but on > Word32 it's not. No, I'm not talking about the comparison between Word32 and Int: I'm looking at Word32 only, "w32/loop vs w32/unsafeLoop" in the one benchmark, and "loop vs unsafeLoop" in the other one. That's the same functions over the same data type, just that the second one iterates over more of that data type. > Ahh, you made me look at the core again. I think this is related to > your observation about V.enumFromTo being the same as V.fromList. With > Word32 the generated core shows that this goes via a list representation > instead of a nice loop. Which makes me suspect there's some RULE that > applies to Stream.enumFromTo that is firing in the first case but not > the second. And if I build both versions with -ddump-rule-firings, > indeed I see that the Int version has > > Rule fired: enumFromTo [Stream] > > With nothing comparable for the Word32 version. I'd imagine if you grep > for that in the Vector sources, you'd find something interesting. Nice observation. I filed this as https://github.com/haskell/vector/issues/21. Hopefully something comes out of it. From mail at nh2.me Tue Apr 29 03:39:35 2014 From: mail at nh2.me (=?ISO-8859-1?Q?Niklas_Hamb=FCchen?=) Date: Tue, 29 Apr 2014 04:39:35 +0100 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: References: <535C27E2.6010808@nh2.me> <535C5A56.7060704@nh2.me> <535D6418.5040304@nh2.me> <535D86A0.3010200@nh2.me> <535D9771.4060201@nh2.me> <535DBBBA.7010703@nh2.me> Message-ID: <535F1EF7.7040201@nh2.me> After some evaluation, here come some results of my benchmarks, and the final function I've packaged: * It is tricky to write an Enum-based general loop function that is fast for all data types. The way overflow checks are implemented in different types makes e.g. Int and Word32 behave differently; Word32 is slower. * [a..b] is nice and can be just as fast as a manual loop - if you are lucky. Unfortunately, if you don't want to rely on luck for your program's performance, you can't have your [a..b] (at the time being). * Vector's equivalent of [a..b] *might* not be as luck dependent, but suffers from a factor 5 penalty, which is hopefully a but (see John's post). Current most appealing solution for fast loops ---------------------------------------------- Unfortunately, this seems to be the most robustly fast (across all types I have tested it with) loop: forLoop :: (Monad m) => a -> (a -> Bool) -> (a -> a) -> (a -> m ()) -> m () forLoop start cond inc f = go start where go !x | cond x = f x >> go (inc x) | otherwise = return () And you can use it as forLoop 0 (< n) (+1) $ \i -> ... Now, you probably don't like this, and neither do I, but it really looks like this is what you should use if you want to write high performance code :/ What also works is a `numLoop :: (Num a, Eq a, Monad m) => a -> a -> (a -> m ()) -> m ()` with start and end value like [a..b], but the `forLoop` aboves gives more flexibility and you can use either (+1) or `succ` with it depending on whether you want performance or overflow-safety. Does it really matter? ---------------------- One might think that in many cases the loop incrementing performance doesn't matter too much, since the loop body should dominate the time spent. That is true, but it is easy to get into cases where it doesn't. Some examples: * You want to write a test to make sure that reinterpret-casting a Word32 to Float and back gives you the same Word32 [1]. Using `forLoop` can make the difference if you have to wait 40 seconds for your test to pass or 3 seconds. (This is how I got into this topic.) * You want to implement something that does trivial operations on unboxed vectors, say dot product or matrix multiplication. `forLoop` can make a 5x performance difference. Shouldn't I write something this trivial ad-hoc? ------------------------------------------------ I've packed `forLoop` into https://github.com/nh2/loop and uploaded it to Hackage (http://hackage.haskell.org/package/loop). * Maintaining the fastest way to loop in one place frees one from thinking about it, and I plan to keep this updated with the fastest implementation known (contributions welcome). * It gives us a place to discuss alternatives and collect benchmarks for high-performance looping. Let's hope it becomes useless soon! [1]: http://stackoverflow.com/a/7002812/263061 From ok at cs.otago.ac.nz Tue Apr 29 05:34:47 2014 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue, 29 Apr 2014 17:34:47 +1200 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: <5BDAE5D1-E900-4EC9-B13F-E6DDB2AD87C1@cs.otago.ac.nz> Message-ID: Before speaking of "Apl's mistakes", one should be clear about what exactly those mistakes *were*. I should point out that the symbols of APL, as such, were not a problem. But the *number* of such symbols was. In order to avoid questions about operator precedence, APL *hasn't* any. In the same way, Smalltalk has an extensible set of 'binary selectors'. If you see an expression like a ?> b ~@ c which operator dominates which? Smalltalk adopted the same solution as APL: no operator precedence. Before Pascal, there was something approaching a consensus in programming languages that ** tightest *,/,div,mod unary and binary +,- relational operators not and or In order to make life easier with user-defined operators, Algol 68 broke this by making unary operators (including not and others you haven't heard of like 'down' and 'upb') bind tightest. As it turned out, this make have made life easier for the compiler, but not for people. In order, allegedly, to make life easier for students, Pascal broke this by making 'or' and 'and' at the same level as '+' and '*'. To this day, many years after Pascal vanished (Think Pascal is dead, MrP is dead, MPW Pascal is dead, IBM mainframe Pascal died so long ago it doesn't smell any more, Sun Pascal is dead, ...) a couple of generations of programmers believe that you have to write (x > 0) && (x < n) in C, because of what their Pascal-trained predecessor taught them. If we turn to Unicode, how should we read a ? b ? c Maybe someone has a principled way to tell. I don't. And then we have to ask about a ?? b ?? c. This is NOT a new problem. Haskell already has way too many operators floating around for me to remember their relative precedence, and I have to follow a rule "when an expression contains two operators from different 'semantic fields', use parentheses." Don't ask me to explain that! Unicode does make the problem rather more pressing. Instead of agonising over the difference between < << <<< <<<< and the like, now we can agonise over the difference between a couple of dozen variously decorated and accompanied versions of the subset sign as single characters. Did you know that there is a single ? character? Distinct from ==? I firmly believe that *careful* introduction of mathematical symbols can be good, but that it needs rather more care for consistency and readabiity than Haskell operators have had so far. I think wide consideration is necessary lest we end up with things like x ? y where x and y are numbers not giving a number. > > I started with writing a corresponding list for python: > http://blog.languager.org/2014/04/unicoded-python.html The "Math Space Advantage" there can be summarised as: "if you use Unicode symbols for operators you can omit even more spaces than you already do, wow!" Never mind APL. What about SETL? For years I yearned to get my hands on SETL so that I could write (?x?s)(?y?s)f(x, y) The idea of using *different* symbols for testing and binding (2.2, "Dis") strikes me as "Dis" indeed. I want to use the same character in both places because they mean the same thing. It's the ? and ? that mean "bind". The name space burden reduction argument won't fly either. Go back and look at http://en.wikipedia.org/wiki/Table_of_mathematical_symbols ? less than or equal to in a partial order is a subgroup of can be reduced to ? multiplication Cartesian product cross product (as superscript) group of units In mathematics, the same meaning may be represented by several different symbols. And the same symbol may be used for several different meanings. (If Haskell allowed prefix and superscript operators, think of the fun we could have keeping track of * the Hodge dual *v and the ordinary dual: v .) Representing ? as ? seems like a clear win. But do we want to use c, e, G, ?, ? and other constants with familiar 1-character names by those characters? What if someone is writing Haskell in Greek? (Are you reading this, Kostis?) I STRONGLY disagree that x?y should violate the norms of school by returning something other than a number. When it comes to returning a quotient and remainder, Haskell has two ways to do this and Common Lisp has four. I don't know how many Python has, but in situation of such ambiguity, it would be disastrous NOT to use words to make it clear which is meant. I find the use of double up arrow for exponentiation odd. Back in the days of BASIC on a model 33 Teletype, one used the single up arrow for that purpose. As for floor and ceiling, it would be truer to mathematical notation to use ?x? for floor. (I note that in Arial Unicode as this appears on my screen these characters look horrible. They should have the same vertical extent as the square brackets they are derived from. Cambria Math and Lucida Sans are OK.) The claim that "dicts are more fundamental to programming than sets" appears to be falsified by SETL, in which dicts were just a special case of sets. (For that matter, so they were in Smalltalk-80.) For existing computational notations with rich sets of mathematical symbols look at Z and B. (B as in the B method, not as in the ancestor of C.) The claim that mathematical expressions cannot be written in Lisp or COBOL is clearly false. See Interlisp, which allowed infix operators. COBOL uses "-" for subtraction, it just needs spaces around it, which is a Good Thing. Using the centre dot as a word separator would have more merit if it weren't so useful as an operator. The reference to APL has switch the operands of take and drop. It should be number_to_keep ? vector number_to_lose ? vector > From daniel.trstenjak at gmail.com Tue Apr 29 07:36:00 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Tue, 29 Apr 2014 09:36:00 +0200 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <535F1EF7.7040201@nh2.me> References: <535D86A0.3010200@nh2.me> <535D9771.4060201@nh2.me> <535DBBBA.7010703@nh2.me> <535F1EF7.7040201@nh2.me> Message-ID: <20140429073600.GA2084@machine> On Tue, Apr 29, 2014 at 04:39:35AM +0100, Niklas Hamb?chen wrote: > Current most appealing solution for fast loops > ---------------------------------------------- > > Unfortunately, this seems to be the most robustly fast (across all types > I have tested it with) loop: > > forLoop :: (Monad m) => a -> (a -> Bool) -> (a -> a) -> (a -> m ()) -> m () > forLoop start cond inc f = go start > where > go !x | cond x = f x >> go (inc x) > | otherwise = return () Regarding the used stack space, wouldn't the following solution be even better? forLoop :: (Monad m) => a -> (a -> Bool) -> (a -> a) -> (a -> m ()) -> m () forLoop start cond inc f = go start (return ()) where go !x m | cond x = go (inc x, m >> f x) | otherwise = m Greetings, Daniel From daniel.trstenjak at gmail.com Tue Apr 29 08:01:41 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Tue, 29 Apr 2014 10:01:41 +0200 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <20140429073600.GA2084@machine> References: <535D86A0.3010200@nh2.me> <535D9771.4060201@nh2.me> <535DBBBA.7010703@nh2.me> <535F1EF7.7040201@nh2.me> <20140429073600.GA2084@machine> Message-ID: <20140429080141.GA4121@machine> On Tue, Apr 29, 2014 at 09:36:00AM +0200, Daniel Trstenjak wrote: > go !x m | cond x = go (inc x, m >> f x) Obviously I'm programming too much C, it should be: go !x m | cond x = go (inc x) (m >> f x) From bertram.felgenhauer at googlemail.com Tue Apr 29 13:03:54 2014 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Tue, 29 Apr 2014 15:03:54 +0200 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <20140429073600.GA2084@machine> References: <535D86A0.3010200@nh2.me> <535D9771.4060201@nh2.me> <535DBBBA.7010703@nh2.me> <535F1EF7.7040201@nh2.me> <20140429073600.GA2084@machine> Message-ID: <20140429130354.GA13759@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Daniel Trstenjak wrote: > Regarding the used stack space, wouldn't the following solution be even better? > > > forLoop :: (Monad m) => a -> (a -> Bool) -> (a -> a) -> (a -> m ()) -> m () > forLoop start cond inc f = go start (return ()) > where > go !x m | cond x = go (inc x, m >> f x) > | otherwise = m This version would build a thunk of shape (return () >> f x1 >> ... before any of the f xi calls get a chance to run; to make matters worse, evaluating that thunk *will* use the evaluation stack. The go !x | cond x = f x >> go (inc x) | otherwise = return () version is better. The guideline here is the strictness of (>>): in most monads, (>>) is strict in its first argument but lazy in its second one; furthermore, the second argument is used at most once in typical monad stacks. So the evaluation stack is not used up at all: Evaluating 'go x' will suspend the 'go (inc x)' call while 'f x' is being run; once 'f x' returns, the 'go (inc x)' is taken care of, which is now effectively a tail call. Laziness saves the day. Cheers, Bertram From dhelta.diaz at gmail.com Tue Apr 29 13:33:07 2014 From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=) Date: Tue, 29 Apr 2014 15:33:07 +0200 Subject: [Haskell-cafe] ANNOUNCE: haskintex-0.5.0.0. Evaluating Haskell inside LaTeX. Message-ID: Dear cafe readers. I have released today a new version (0.5.0.0) of the haskintex program, which is written in Haskell, for Haskell people, and by Daniel D?az (that's me!). Haskintex is a program that processes files which contains LaTeX and (maybe!) some Haskell expressions on it. Exactly as you are expecting, it will evaluate those expressions and replace them by their results. Neat, but there is more. If the Haskell expression is of type LaTeX (yes, there is a type for that, look in [1]), then it will be replaced by the LaTeX expression that value represents. This allows magic tricks like plotting a Haskell function in a LaTeX file in just a few seconds! (see [2]). So, what is new in this version? Haskintex can now memorize results of evaluations, to avoid repeating computations. The values are shared in different runs of the program, so you can save lot of time. This feature was proposed by a kind haskintex user in the #hatex IRC channel under the alias of colmcbeardman (I hope I have spelled it correctly). Find more about haskintex in: http://daniel-diaz.github.io/projects/haskintex Happy hacking, Daniel D?az. -- References [1] http://hackage.haskell.org/package/HaTeX-3.10.0.0/docs/Text-LaTeX-Base-Syntax.html#t:LaTeX [2] http://hackage.haskell.org/package/HaTeX-3.10.0.0/docs/Text-LaTeX-Packages-TikZ-Simple.html#v:pathImage -------------- next part -------------- An HTML attachment was scrubbed... URL: From temporalabstraction at gmail.com Tue Apr 29 14:55:00 2014 From: temporalabstraction at gmail.com (EatsKittens) Date: Tue, 29 Apr 2014 16:55:00 +0200 Subject: [Haskell-cafe] How to create a background program that monitors input (linux) Message-ID: Essentially, I want to create a program that is simply ran in the background, not in a terminal, that monitors keypresses and mouse presses and takes certain actions on specific keypresses. Where to start? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Tue Apr 29 15:13:16 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Tue, 29 Apr 2014 16:13:16 +0100 Subject: [Haskell-cafe] How to create a background program that monitors input (linux) In-Reply-To: References: Message-ID: <535FC18C.9060602@nh2.me> Do you wish to do that in an active Xorg GUI session? If yes, the X API (and corresponding Haskell packages) will allow you to do that; otherwise you usually have to read directly from the device files (e.g. /dev/input*) which usually requires root. On Tue 29 Apr 2014 15:55:00 BST, EatsKittens wrote: > Essentially, I want to create a program that is simply ran in the > background, not in a terminal, that monitors keypresses and mouse > presses and takes certain actions on specific keypresses. Where to start? From temporalabstraction at gmail.com Tue Apr 29 15:19:35 2014 From: temporalabstraction at gmail.com (EatsKittens) Date: Tue, 29 Apr 2014 17:19:35 +0200 Subject: [Haskell-cafe] How to create a background program that monitors input (linux) In-Reply-To: <535FC18C.9060602@nh2.me> References: <535FC18C.9060602@nh2.me> Message-ID: Yes, from within the X server. I've used Xlib in the past but this seemed mostly limited to window management and keypresses when a specific terminal in which a program is running has focus. I never came across a way to simply monitor arbitray keypresses from a background program and take action depending on them. For instance running a system command whenever ctrl+alt+r is pressed. On 29 April 2014 17:13, Niklas Hamb?chen wrote: > Do you wish to do that in an active Xorg GUI session? > > If yes, the X API (and corresponding Haskell packages) will allow you > to do that; otherwise you usually have to read directly from the device > files (e.g. /dev/input*) which usually requires root. > > On Tue 29 Apr 2014 15:55:00 BST, EatsKittens wrote: > > Essentially, I want to create a program that is simply ran in the > > background, not in a terminal, that monitors keypresses and mouse > > presses and takes certain actions on specific keypresses. Where to start? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Apr 29 15:25:22 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 29 Apr 2014 11:25:22 -0400 Subject: [Haskell-cafe] How to create a background program that monitors input (linux) In-Reply-To: References: <535FC18C.9060602@nh2.me> Message-ID: On Tue, Apr 29, 2014 at 11:19 AM, EatsKittens wrote: > Yes, from within the X server. I've used Xlib in the past but this seemed > mostly limited to window management and keypresses when a specific terminal > in which a program is running has focus. I never came across a way to > simply monitor arbitray keypresses from a background program and take > action depending on them. For instance running a system command whenever > ctrl+alt+r is pressed. > You're looking for passive key grabs, http://hackage.haskell.org/package/X11/docs/Graphics-X11-Xlib-Misc.html#v:grabKey(XGrabKey(3) for Xlib manpage). -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Tue Apr 29 15:29:26 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Tue, 29 Apr 2014 17:29:26 +0200 Subject: [Haskell-cafe] How to write fast for loops In-Reply-To: <20140429130354.GA13759@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> References: <535D9771.4060201@nh2.me> <535DBBBA.7010703@nh2.me> <535F1EF7.7040201@nh2.me> <20140429073600.GA2084@machine> <20140429130354.GA13759@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: <20140429152925.GA20137@machine> On Tue, Apr 29, 2014 at 03:03:54PM +0200, Bertram Felgenhauer wrote: > This version would build a thunk of shape (return () >> f x1 >> ... > before any of the f xi calls get a chance to run; to make matters > worse, evaluating that thunk *will* use the evaluation stack. Ok, I can see, that it has to build the whole thunk, because otherwise 'go' couldn't return anything. But why would the evaluation of the thunk use the stack? Why does the evaluation of '>>' in this case use the stack and in the other it doesn't? > The > > go !x | cond x = f x >> go (inc x) > | otherwise = return () > > version is better. The guideline here is the strictness of (>>): in most > monads, (>>) is strict in its first argument but lazy in its second one; > furthermore, the second argument is used at most once in typical monad > stacks. So the evaluation stack is not used up at all: Evaluating > 'go x' will suspend the 'go (inc x)' call while 'f x' is being run; > once 'f x' returns, the 'go (inc x)' is taken care of, which is now > effectively a tail call. Laziness saves the day. I think that I was mostly irritated by 'mapM', which uses the stack, but that's because of it's use of '>>=', and it's bound value has to be kept on the stack. Thanks! Greetings, Daniel From mail at nh2.me Tue Apr 29 16:31:51 2014 From: mail at nh2.me (=?ISO-8859-1?Q?Niklas_Hamb=FCchen?=) Date: Tue, 29 Apr 2014 17:31:51 +0100 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' Message-ID: <535FD3F7.2080402@nh2.me> This is just a short notice that using foldl' (+) 0 [0..100000::Int] is over 10 times slower than using flip execState 0 $ forLoop (0 :: Int) (< n) (+1) $ \i -> do x <- get put $! x + i with `loopFor` as on https://github.com/nh2/loop. Even using an IORef is twice as fast as the pure foldl' (but still 5 times slower than strict State). The benchmark is at http://htmlpreview.github.io/?https://github.com/nh2/loop/blob/master/results/bench-foldl-and-iorefs-are-slow.html. (All benchmarks are linked from https://github.com/nh2/loop.) You can see there that the problem is gone when using Vector.foldl', but only for Int - for Word32 it persists. It seems that manual looping is beneficial even when dealing with prime examples of pure code that GHC ought to optimize well. Niklas From mail at nh2.me Tue Apr 29 16:35:06 2014 From: mail at nh2.me (=?ISO-8859-1?Q?Niklas_Hamb=FCchen?=) Date: Tue, 29 Apr 2014 17:35:06 +0100 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: <535FD3F7.2080402@nh2.me> References: <535FD3F7.2080402@nh2.me> Message-ID: <535FD4BA.2010807@nh2.me> Interestingly, the discrimination against Word32 does not end here: When compiling with -fllvm (http://htmlpreview.github.io/?https://github.com/nh2/loop/blob/master/results/bench-foldl-and-iorefs-are-slow-llvm.html), we can see that the forLoop + strict State monad is completely compiled away to a no-op for Int, but not for Word32. From felipe.lessa at gmail.com Tue Apr 29 16:43:24 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Tue, 29 Apr 2014 13:43:24 -0300 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: <535FD4BA.2010807@nh2.me> References: <535FD3F7.2080402@nh2.me> <535FD4BA.2010807@nh2.me> Message-ID: <535FD6AC.6080504@gmail.com> Em 29-04-2014 13:35, Niklas Hamb?chen escreveu: > (http://htmlpreview.github.io/?https://github.com/nh2/loop/blob/master/results/bench-foldl-and-iorefs-are-slow-llvm.html), Is it just or is criterion broken in some way? It considers a 1140% effect on the mean "moderate", so I would guess that the number is being incorrectly printed. One of the tests even has a "severe" 7280% effect! Also, for "sum32/sumIntStrictState" is reports microseconds on the charts but seconds on the table. Cheers, =) -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From mail at nh2.me Tue Apr 29 16:53:13 2014 From: mail at nh2.me (=?ISO-8859-1?Q?Niklas_Hamb=FCchen?=) Date: Tue, 29 Apr 2014 17:53:13 +0100 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: <535FD6AC.6080504@gmail.com> References: <535FD3F7.2080402@nh2.me> <535FD4BA.2010807@nh2.me> <535FD6AC.6080504@gmail.com> Message-ID: <535FD8F9.6080702@nh2.me> On 29/04/14 17:43, Felipe Lessa wrote: > Also, for "sum32/sumIntStrictState" is reports microseconds on the > charts but seconds on the table. I have noticed these things before as well, but I don't know what causes them and it only seems to happen sometimes :/ I filed it as https://github.com/bos/criterion/issues/50 From jwlato at gmail.com Tue Apr 29 18:31:49 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 29 Apr 2014 11:31:49 -0700 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: <535FD8F9.6080702@nh2.me> References: <535FD3F7.2080402@nh2.me> <535FD4BA.2010807@nh2.me> <535FD6AC.6080504@gmail.com> <535FD8F9.6080702@nh2.me> Message-ID: Regardless, that report is garbage. It's not worth the paper it's printed on! Maybe re-run it and upload new results? On Tue, Apr 29, 2014 at 9:53 AM, Niklas Hamb?chen wrote: > On 29/04/14 17:43, Felipe Lessa wrote: > > Also, for "sum32/sumIntStrictState" is reports microseconds on the > > charts but seconds on the table. > > I have noticed these things before as well, but I don't know what causes > them and it only seems to happen sometimes :/ > > I filed it as https://github.com/bos/criterion/issues/50 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.lessa at gmail.com Tue Apr 29 18:34:27 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Tue, 29 Apr 2014 15:34:27 -0300 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: References: <535FD3F7.2080402@nh2.me> <535FD4BA.2010807@nh2.me> <535FD6AC.6080504@gmail.com> <535FD8F9.6080702@nh2.me> Message-ID: <535FF0B3.9060903@gmail.com> Em 29-04-2014 15:31, John Lato escreveu: > Regardless, that report is garbage. It's not worth the paper it's > printed on! Maybe re-run it and upload new results? That's very harsh, why is it garbage? Cheers, =) -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From carter.schonwald at gmail.com Tue Apr 29 18:55:54 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 29 Apr 2014 14:55:54 -0400 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: <535FF0B3.9060903@gmail.com> References: <535FD3F7.2080402@nh2.me> <535FD4BA.2010807@nh2.me> <535FD6AC.6080504@gmail.com> <535FD8F9.6080702@nh2.me> <535FF0B3.9060903@gmail.com> Message-ID: because the events are on millisecond and microsecond scales, yet the means are being reported on the order of seconds. This is a strong piece of evidence the the claims therein are fundamentally wrong, confusing and misleading and wrong. On Tue, Apr 29, 2014 at 2:34 PM, Felipe Lessa wrote: > Em 29-04-2014 15:31, John Lato escreveu: > > Regardless, that report is garbage. It's not worth the paper it's > > printed on! Maybe re-run it and upload new results? > > That's very harsh, why is it garbage? > > Cheers, =) > > -- > Felipe. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Tue Apr 29 19:00:29 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Tue, 29 Apr 2014 20:00:29 +0100 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: References: <535FD3F7.2080402@nh2.me> <535FD4BA.2010807@nh2.me> <535FD6AC.6080504@gmail.com> <535FD8F9.6080702@nh2.me> <535FF0B3.9060903@gmail.com> Message-ID: <535FF6CD.1000301@nh2.me> I think we are dealing with a much more trivial, technical issue here: It looks like http://htmlpreview.github.io and Criterion's Javascript do not play well together. If I wget the raw file, https://raw.githubusercontent.com/nh2/loop/master/results/bench-foldl-and-iorefs-are-slow.html, and view it in my browser, all the number reported are suddenly correct. Can you check if that works for you? On 29/04/14 19:55, Carter Schonwald wrote: > because the events are on millisecond and microsecond scales, yet the > means are being reported on the order of seconds. > > This is a strong piece of evidence the the claims therein are > fundamentally wrong, confusing and misleading and wrong. From mail at nh2.me Tue Apr 29 19:10:07 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Tue, 29 Apr 2014 20:10:07 +0100 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: <535FF6CD.1000301@nh2.me> References: <535FD3F7.2080402@nh2.me> <535FD4BA.2010807@nh2.me> <535FD6AC.6080504@gmail.com> <535FD8F9.6080702@nh2.me> <535FF0B3.9060903@gmail.com> <535FF6CD.1000301@nh2.me> Message-ID: <535FF90F.40509@nh2.me> Look, when I serve it via a different service, the report looks all fine: https://rawgit.com/nh2/loop/master/results/bench-foldl-and-iorefs-are-slow.html I should probably switch it to hosting it via Github pages once I figure out how to do that comfortably. > This is a strong piece of evidence the the claims therein are > fundamentally wrong, confusing and misleading and wrong. Now back to the claims! From darthdeus at gmail.com Tue Apr 29 19:15:18 2014 From: darthdeus at gmail.com (Jakub Arnold) Date: Tue, 29 Apr 2014 21:15:18 +0200 Subject: [Haskell-cafe] Why is this code slow? Message-ID: <6C2B5185A1884CE1A27EFEEB42D20170@gmail.com> Hey guys, in my stumbling over Reddit I happened to find the following comment http://www.reddit.com/r/programming/comments/248abo/range_comprehensions_c/ch56g7b, where the poster shows a simple algorithm which is really slow when implemented in Haskell, compared to a C++ counterpart which does it the same way. I?ve tried to figure this out, but my profiling skills don?t seem to be good enough for this. I?m not sure if this is somehow a limitation of list comprehensions, or if something else is wrong. -- Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Tue Apr 29 19:28:52 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 29 Apr 2014 20:28:52 +0100 Subject: [Haskell-cafe] Why is this code slow? In-Reply-To: <6C2B5185A1884CE1A27EFEEB42D20170@gmail.com> References: <6C2B5185A1884CE1A27EFEEB42D20170@gmail.com> Message-ID: <20140429192852.GC28890@weber> On Tue, Apr 29, 2014 at 09:15:18PM +0200, Jakub Arnold wrote: > in my stumbling over Reddit I happened to find the following comment > http://www.reddit.com/r/programming/comments/248abo/range_comprehensions_c/ch56g7b, > where the poster shows a simple algorithm which is really slow when > implemented in Haskell, compared to a C++ counterpart which does it the > same way. I have done my duty. From jwlato at gmail.com Tue Apr 29 20:59:42 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 29 Apr 2014 13:59:42 -0700 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: <535FF90F.40509@nh2.me> References: <535FD3F7.2080402@nh2.me> <535FD4BA.2010807@nh2.me> <535FD6AC.6080504@gmail.com> <535FD8F9.6080702@nh2.me> <535FF0B3.9060903@gmail.com> <535FF6CD.1000301@nh2.me> <535FF90F.40509@nh2.me> Message-ID: Yes, this link is much better, thanks. (Haven't had a chance to look at the claims yet). On Apr 29, 2014 12:10 PM, "Niklas Hamb?chen" wrote: > Look, when I serve it via a different service, the report looks all fine: > > > > https://rawgit.com/nh2/loop/master/results/bench-foldl-and-iorefs-are-slow.html > > I should probably switch it to hosting it via Github pages once I figure > out how to do that comfortably. > > > This is a strong piece of evidence the the claims therein are > > fundamentally wrong, confusing and misleading and wrong. > > Now back to the claims! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis.cardwell at extellisys.com Tue Apr 29 23:50:03 2014 From: travis.cardwell at extellisys.com (Travis Cardwell) Date: Wed, 30 Apr 2014 08:50:03 +0900 Subject: [Haskell-cafe] How to create a background program that monitors input (linux) In-Reply-To: References: Message-ID: <53603AAB.7080705@extellisys.com> On 2014?04?29? 23:55, EatsKittens wrote: > Essentially, I want to create a program that is simply ran in the > background, not in a terminal, that monitors keypresses and mouse presses > and takes certain actions on specific keypresses. Where to start? Perhaps you can get inspiration from XMonad [1]: http://code.haskell.org/xmonad/XMonad/Main.hsc s/^grabKeys ::/ Cheers, Travis ---- [1] http://xmonad.org/ From allbery.b at gmail.com Tue Apr 29 23:59:06 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 29 Apr 2014 19:59:06 -0400 Subject: [Haskell-cafe] How to create a background program that monitors input (linux) In-Reply-To: References: <535FC18C.9060602@nh2.me> Message-ID: On Tue, Apr 29, 2014 at 11:25 AM, Brandon Allbery wrote: > I never came across a way to simply monitor arbitray keypresses from a > background program and take action depending on them. For instance running > a system command whenever ctrl+alt+r is pressed. I should mention that this mechanism you're trying to use does not exist in Xlib. It can be done via the RECORD extension. I do not recommend it; among other things, X11 does not give programs "veto control" of event delivery --- so you could in theory use RECORD to do this (with significantly increased load over using the proper mechanism since you are seeing all key events) but you cannot prevent the triggering key(s) from also being delivered to the focused window. This is the wrong mechanism entirely for such things, operates at the wrong level, and is expensive (and potentially a security issue; consider what "all key events" means; this also means that the RECORD extension is often disabled in the interest of security). -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Wed Apr 30 01:16:25 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 29 Apr 2014 18:16:25 -0700 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: <535FD3F7.2080402@nh2.me> References: <535FD3F7.2080402@nh2.me> Message-ID: On Tue, Apr 29, 2014 at 9:31 AM, Niklas Hamb?chen wrote: > This is just a short notice that using > > foldl' (+) 0 [0..100000::Int] > > is over 10 times slower than using > > flip execState 0 $ > forLoop (0 :: Int) (< n) (+1) $ \i -> do > x <- get > put $! x + i > > with `loopFor` as on https://github.com/nh2/loop. > So this is interesting. The forLoop code gets compiled into a nice loop in core over unboxed Ints. The foldl' function OTOH still goes via a list. I expect it's not foldl' itself that's slow, rather that it doesn't fuse with the list producers in current GHCs. This may be improved in the future. Especially as the vectorized foldl' does fuse. > > Even using an IORef is twice as fast as the pure foldl' (but still 5 > times slower than strict State). > > The benchmark is at > > http://htmlpreview.github.io/?https://github.com/nh2/loop/blob/master/results/bench-foldl-and-iorefs-are-slow.html > . > > (All benchmarks are linked from https://github.com/nh2/loop.) > > You can see there that the problem is gone when using Vector.foldl', but > only for Int - for Word32 it persists. > > It seems that manual looping is beneficial even when dealing with prime > examples of pure code that GHC ought to optimize well. > That's why I suggested using vector in the first place. But it seems that Vector.enumFromTo could use some optimizations to help with some common cases. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Wed Apr 30 02:04:41 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Wed, 30 Apr 2014 03:04:41 +0100 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: References: <535FD3F7.2080402@nh2.me> Message-ID: <53605A39.3040507@nh2.me> On 30/04/14 02:16, John Lato wrote: > So this is interesting. The forLoop code gets compiled into a nice loop > in core over unboxed Ints. The foldl' function OTOH still goes via a > list. I expect it's not foldl' itself that's slow, rather that it > doesn't fuse with the list producers in current GHCs. This may be > improved in the future. Especially as the vectorized foldl' does fuse. It bothers me especially as the comments around `enumFromTo` seem to explicitly talk about deforestation. From rustompmody at gmail.com Wed Apr 30 08:21:38 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Wed, 30 Apr 2014 13:51:38 +0530 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: <5BDAE5D1-E900-4EC9-B13F-E6DDB2AD87C1@cs.otago.ac.nz> Message-ID: Hi Richard Thanks for a vigorous and rigorous appraisal of my blog post: http://blog.languager.org/2014/04/unicoded-python.html However this is a Haskell list and my post being not just a discussion about python but some brainstorming for how python could change, a detailed discussion about that is probably too off-topic here dont you think? So for now let me address just one of your points, which is appropriate for this forum. I'd be pleased to discuss the other points you raise off list. Also, while Ive learnt a lot from this thread, I also see some confusions and fallacies. So before drilling down into details and losing the forest for the trees, I'd prefer to start with a broad perspective rather than a narrow technological focus -- more at end. On Tue, Apr 29, 2014 at 11:04 AM, Richard A. O'Keefe wrote: > Before speaking of "Apl's mistakes", one should be > clear about what exactly those mistakes *were*. > I should point out that the symbols of APL, as such, > were not a problem. But the *number* of such symbols > was. In order to avoid questions about operator > precedence, APL *hasn't* any. In the same way, > Smalltalk has an extensible set of 'binary selectors'. > If you see an expression like > > a ?> b ~@ c > > which operator dominates which? Smalltalk adopted the > same solution as APL: no operator precedence. > > Before Pascal, there was something approaching a > consensus in programming languages that > ** tightest > *,/,div,mod > unary and binary +,- > relational operators > not > and > or > In order to make life easier with user-defined > operators, Algol 68 broke this by making unary > operators (including not and others you haven't > heard of like 'down' and 'upb') bind tightest. > As it turned out, this make have made life > easier for the compiler, but not for people. > In order, allegedly, to make life easier for > students, Pascal broke this by making 'or' > and 'and' at the same level as '+' and '*'. > To this day, many years after Pascal vanished > (Think Pascal is dead, MrP is dead, MPW Pascal > is dead, IBM mainframe Pascal died so long ago > it doesn't smell any more, Sun Pascal is dead, ...) > a couple of generations of programmers believe > that you have to write > (x > 0) && (x < n) > in C, because of what their Pascal-trained predecessor > taught them. > > If we turn to Unicode, how should we read > > a ? b ? c > > Maybe someone has a principled way to tell. I don't. > Without claiming to cover all cases, this is a 'principle' If we have: (?) :: a -> a -> b (?) :: b -> b -> c then ?'s precedence should be higher than ?. This is what makes it natural to have the precedences of (+) (<) (&&) in decreasing order. This is also why the bitwise operators in C have the wrong precedence: x & 0xF == 0xF has only 1 meaningful interpretation; C chooses the other! The error comes (probably) from treating & as close to the logical operators like && whereas in fact it is more kin to arithmetic operators like +. There are of course other principles: Dijkstra argued vigorously that boolean algebra being completely symmetric in (?,True) (?, False), ?, ? should have the same precedence. Evidently not too many people agree with him! ---------------------- To come back to the broader questions. I started looking at Niklas' link (thanks Niklas!) http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#unicode-syntax and I find that the new unicode chars for -<< and >>- are missing. Ok, a minor doc-bug perhaps? Poking further into that web-page, I find that it has charset=ISO-8859-1 Running w3's validator http://validator.w3.org/ on it one gets: No DOCTYPE found! What has this got to do with unicode in python source? That depends on how one sees it. When I studied C (nearly 30 years now!) we used gets as a matter of course. Today we dont. Are Kernighan and Ritchie wrong in teaching it? Are today's teacher's wrong in proscribing it? I believe the only reasonable outlook is that truth changes with time: it was ok then; its not today. Likewise DOCTYPE-missing and charset-other-than-UTF-8. Random example showing how right yesterday becomes wrong today: http://www.sitepoint.com/forums/showthread.php?660779-Content-type-iso-8859-1-or-utf-8 Unicode vs ASCII in program source is similar (I believe). My thoughts on this (of a philosophical nature) are: http://blog.languager.org/2014/04/unicode-and-unix-assumption.html If we can get the broader agreements (disagreements!) out of the way to start with, we may then look at the details. Thanks and regards, Rusi -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.is.fischer at googlemail.com Wed Apr 30 09:03:45 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Wed, 30 Apr 2014 11:03:45 +0200 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: Message-ID: <1484805.H7dKcJyEBg@linux-hpeb.site> On Wednesday 30 April 2014, 13:51:38, Rustom Mody wrote: > Without claiming to cover all cases, this is a 'principle' > If we have: > (?) :: a -> a -> b > (?) :: b -> b -> c > then ?'s precedence should be higher than ?. But what if (?) :: b -> b -> a? > This is what makes it natural to have the precedences of (+) (<) (&&) in > decreasing order. > > This is also why the bitwise operators in C have the wrong precedence: > x & 0xF == 0xF > has only 1 meaningful interpretation; C chooses the other! > The error comes (probably) from treating & as close to the logical > operators like && whereas in fact it is more kin to arithmetic operators > like +. That comes from `&` and `|` being logical operators in B. Quoth Dennis Ritchie (http://cm.bell-labs.com/who/dmr/chist.html in the section "Neonatal C"): > to make the conversion less painful, we decided to keep the precedence of > the & operator the same relative to ==, and merely split the precedence of > && slightly from &. Today, it seems that it would have been preferable to > move the relative precedences of & and ==, and thereby simplify a common C > idiom From rustompmody at gmail.com Wed Apr 30 10:24:08 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Wed, 30 Apr 2014 15:54:08 +0530 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: <1484805.H7dKcJyEBg@linux-hpeb.site> References: <1484805.H7dKcJyEBg@linux-hpeb.site> Message-ID: On Wed, Apr 30, 2014 at 2:33 PM, Daniel Fischer < daniel.is.fischer at googlemail.com> wrote: > > x & 0xF == 0xF > > has only 1 meaningful interpretation; C chooses the other! > > The error comes (probably) from treating & as close to the logical > > operators like && whereas in fact it is more kin to arithmetic operators > > like +. > > That comes from `&` and `|` being logical operators in B. Quoth Dennis > Ritchie > (http://cm.bell-labs.com/who/dmr/chist.html in the section "Neonatal C"): > > > to make the conversion less painful, we decided to keep the precedence of > > the & operator the same relative to ==, and merely split the precedence > of > > && slightly from &. Today, it seems that it would have been preferable to > > move the relative precedences of & and ==, and thereby simplify a common > C > > idiom > Nice! I learn a bit of history. Hope we learn from it! viz. Some things which are easy in a state of transition become painful in a (more) steady state. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustompmody at gmail.com Wed Apr 30 11:24:14 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Wed, 30 Apr 2014 16:54:14 +0530 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: <1484805.H7dKcJyEBg@linux-hpeb.site> References: <1484805.H7dKcJyEBg@linux-hpeb.site> Message-ID: On Wed, Apr 30, 2014 at 2:33 PM, Daniel Fischer < daniel.is.fischer at googlemail.com> wrote: > On Wednesday 30 April 2014, 13:51:38, Rustom Mody wrote: > > Without claiming to cover all cases, this is a 'principle' > > If we have: > > (?) :: a -> a -> b > > (?) :: b -> b -> c > > then ?'s precedence should be higher than ?. > But what if (?) :: b -> b -> a? > Sorry, missed that question tucked away :-) I did say a (not the) principle, not claiming to cover all cases! I guess it should be non-associative (ie infix without l/r) same precedence? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Apr 30 11:41:15 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 30 Apr 2014 13:41:15 +0200 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: <535FD3F7.2080402@nh2.me> References: <535FD3F7.2080402@nh2.me> Message-ID: <1398858075.4602.21.camel@kirk> Hi, Am Dienstag, den 29.04.2014, 17:31 +0100 schrieb Niklas Hamb?chen: > This is just a short notice that using > > foldl' (+) 0 [0..100000::Int] > > is over 10 times slower than using > > flip execState 0 $ > forLoop (0 :: Int) (< n) (+1) $ \i -> do > x <- get > put $! x + i > > with `loopFor` as on https://github.com/nh2/loop. Did you look at the GHC Core generated? When starting to investigate performance issues, reading Core simply is required ? otherwise it?s like search for a lost plain while refusing to look under the water surface. So can you compile your code with -ddump-simpl (and possibly flags -dsuppress-uniques and -dsuppress-module-prefixes that make it more readable) and compare the results: Any obvious differences, like unboxing to Int# used in one place and not in the other? If you need help deciphering core, paste the relevant bits in a mail to this thread and we can help you. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Wed Apr 30 11:42:36 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 30 Apr 2014 13:42:36 +0200 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: References: <535FD3F7.2080402@nh2.me> Message-ID: <1398858156.4602.22.camel@kirk> Hi, Am Dienstag, den 29.04.2014, 18:16 -0700 schrieb John Lato: > So this is interesting. The forLoop code gets compiled into a nice > loop in core over unboxed Ints. The foldl' function OTOH still goes > via a list. I expect it's not foldl' itself that's slow, rather that > it doesn't fuse with the list producers in current GHCs. This may be > improved in the future. Especially as the vectorized foldl' does > fuse. This should have improved in GHC 7.9, where I have fixed https://ghc.haskell.org/trac/ghc/ticket/7994 (making foldl a good consumer). Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From daniel.is.fischer at googlemail.com Wed Apr 30 12:35:49 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Wed, 30 Apr 2014 14:35:49 +0200 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: <1398858156.4602.22.camel@kirk> References: <535FD3F7.2080402@nh2.me> <1398858156.4602.22.camel@kirk> Message-ID: <29765981.hGEpjiEthV@linux-hpeb.site> On Wednesday 30 April 2014, 13:42:36, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 29.04.2014, 18:16 -0700 schrieb John Lato: > > So this is interesting. The forLoop code gets compiled into a nice > > loop in core over unboxed Ints. The foldl' function OTOH still goes > > via a list. I expect it's not foldl' itself that's slow, rather that > > it doesn't fuse with the list producers in current GHCs. This may be > > improved in the future. Especially as the vectorized foldl' does > > fuse. > > This should have improved in GHC 7.9, where I have fixed > https://ghc.haskell.org/trac/ghc/ticket/7994 (making foldl a good > consumer). Confirmed, foldl' (+) 0 [1 .. 5000000 :: Int] gets the very nice core Rec { Main.$wgo [Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType ] Main.$wgo = \ (w :: GHC.Prim.Int#) (ww :: GHC.Prim.Int#) -> case w of wild { __DEFAULT -> Main.$wgo (GHC.Prim.+# wild 1) (GHC.Prim.+# ww wild); 5000000 -> GHC.Prim.+# ww 5000000 } end Rec } with 7.9.20140425. The core for Integer is naturally not quite as nice, but still the list is eliminated. Thanks, Joachim. Cheers, Daniel From ok at cs.otago.ac.nz Wed Apr 30 12:38:18 2014 From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz) Date: Thu, 1 May 2014 00:38:18 +1200 Subject: [Haskell-cafe] Unicode Haskell source -- Yippie! In-Reply-To: References: <5BDAE5D1-E900-4EC9-B13F-E6DDB2AD87C1@cs.otago.ac.nz> Message-ID: I wrote >> If we turn to Unicode, how should we read >> >> a ??? b ??? c >> >> Maybe someone has a principled way to tell. I don't. Rustom Mody wrote: > > Without claiming to cover all cases, this is a 'principle' > If we have: > (???) :: a -> a -> b > (???) :: b -> b -> c > > then ???'s precedence should be higher than ???. I always have trouble with "higher" and "lower" precedence, because I've used languages where the operator with the bigger number binds tighter and languages where the operator with the bigger number gets to dominate the other. Both are natural enough, but with opposite meanings for "higher". This principle does not explain why * binds tighter than +, which means we need more than one principle. It also means that if OP1 :: a -> a -> b and OP2 :: b -> b -> a then OP1 should be higher than OP2 and OP2 should be higher than OP1, which is a bit of a puzzler, unless perhaps you are advocating a vaguely CGOL-ish asymmetric precedence scheme where the precedence on the left and the precedence on the right can be different. For the record, let me stipulate that I had in mind a situation where OP1, OP2 : a -> a -> a. For example, APL uses the floor and ceiling operators infix to stand for max and min. This principle offers us no help in ordering max and min. Or consider APL again, whence I'll borrow (using ASCII because this is webmail tonight) take, rotate :: Int -> Vector t -> Vector t Haskell applies operator precedence before it does type checking, so how would it know to parse n `take` m `rotate` v as (n `take` (m `rotate` v))? I don't believe there was anything in my original example to suggest that either operator had two operands of the same type, so I must conclude that this principle fails to provide any guidance in that case (like this one). > This is what makes it natural to have the precedences of (+) (<) (&&) in > decreasing order. > > This is also why the bitwise operators in C have the wrong precedence: Oh, I agree with that! > The error comes (probably) from treating & as close to the logical > operators like && whereas in fact it is more kin to arithmetic operators > like +. The error comes from BCPL where & and && were the same operator (similarly | and ||). At some point in the evolution of C from BCPL the operators were split apart but the bitwise ones left in the wrong place. > > There are of course other principles: > Dijkstra argued vigorously that boolean algebra being completely symmetric > in > (???,True) (???, False), ???, ??? should have the same precedence. > > Evidently not too many people agree with him! Sadly, I am reading this in a web browser where the Unicode symbols are completely garbled. (More precisely, I think it's WebMail doing it.) Maybe Unicode isn't ready for prime time yet? You might be interested to hear that in the Ada programming language, you are not allowed to mix 'and' with 'or' (or 'and then' with 'or else') without using parentheses. The rationale is that the designers did not believe that enough programmers understood the precedence of and/or. The GNU C compiler kvetches when you have p && q || r without otiose parentheses. Seems that there are plenty of designers out there who agree with Dijkstra, not out of a taste for well-engineered notation, but out of contempt for the Average Programmer. > When I studied C (nearly 30 years now!) we used gets as a matter of > course. > Today we dont. Hmm. I started with C in late 1979. Ouch. That's 34 and a half years ago. This was under Unix version 6+, with a slightly "pre-classic" C. A little later we got EUC Unix version 7, and a 'classic' C compiler that, oh joy, supported /\ (min) and \/ (max) operators. [With a bug in the code generator that I patched.] > Are Kernighan and Ritchie wrong in teaching it? > Are today's teacher's wrong in proscribing it? > > I believe the only reasonable outlook is that truth changes with time: it > was ok then; its not today. In this case, bull-dust! gets() is rejected today because a botch in its design makes it bug-prone. Nothing has changed. It was bug-prone 34 years ago. It has ALWAYS been a bad idea to use gets(). Amongst other things, the Unix manuals have always presented the difference between gets() -- discards the terminator -- and fgets() -- annoyingly retains the terminator -- as a bug which they thought it was too late to fix; after all, C had hundreds of users! No, it was obvious way back then: you want to read a line? Fine, WRITE YOUR OWN FUNCTION, because there is NO C library function that does quite what you want. The great thing about C was that you *could* write your own line-reading function without suffering. Not only would your function do the right thing (whatever you conceived that to be), it would be as fast, or nearly as fast, as the built-in one. Try doing *that* in PL/I! No, in this case, *opinions* may have changed, peoples *estimation* of and *tolerance for* the risks may have changed, but the truth has not changed. > > Likewise DOCTYPE-missing and charset-other-than-UTF-8. > Random example showing how right yesterday becomes wrong today: > http://www.sitepoint.com/forums/showthread.php?660779-Content-type-iso-8859-1-or-utf-8 Well, "missing" DOCTYPE is where it starts to get a bit technical. An SGML document is basically made up of three parts: - an SGML declaration (meta-meta-data) that tells the parser, amongst other things, what characters to use for delimiters, whether various things are case sensitive, what the numeric limits are, and whether various features are enabled. - a Document Type Declaration (meta-data) that conforms to the lexical rules set up by the SGML declaration and defines (a) the grammar rules and (b) a bunch of macros. - a document (data). The SGML declaration can be supplied to a parser as data (and yes, I've done that), or it can be stipulated by convention (as the HTML standards do). In the same way, the DTD can be - completely declared in-line - defined by reference with local amendments - defined solely by reference - known by convention. If there is a convention that a document without a DTD uses a particular DTD, SGML is fine with that. (It's all part of "entity management", one of the minor arcana of SGML.) As for the link in question, it doesn't show right turning into wrong. A quick summary of the sensible part of that thread: - If you use a tag to specify the encoding of your file, it had better be *right*. This has been true ever since tags first existed. - If you have a document in Latin 1 and any characters outside that range are written as character entity references or numeric character references, there is no need to change. No change of right to wrong here! - If you want to use English punctuation marks like dashes and curly quotes, using UTF-8 will let you write these characters without character entities or NCRs. This is only half true. It will let you do this conveniently IF your local environment has fonts that include the characters. (Annoyingly, in Mac OS 10.6, which I'm typing on, Edit|Special characters is not only geographically confused, listing Coptic as a *European* script -- last type I checked Egypt was still in Africa -- but it doesn't display any Coptic characters. In the Mac OS 10.7 system I normally use, Edit|Special characters got dramatically worse as an interface, but no more competent with Coptic characters. Just because a character is in Unicode doesn't mean it can be *used*, practically speaking.) Instead of saying that what is wrong has become or is becoming right, I'd prefer to say that what was impossible is becoming possible and what was broken (Unicode font support) is gradually getting fixed. - Some Unicode characters, indeed, some Latin 1 characters, are so easy to confuse with other characters that it is advisable to use character entities. Again, nothing about wrong turning into right. This was good advice as soon as Latin 1 came out. > Unicode vs ASCII in program source is similar (I believe). Well, not really. People using specification languages like Z routinely used characters way outside the ASCII range; one way was to use LaTeX. Another way was to have GUI systems that let you key in using LaTeX character names or menus but see the intended characters. Back in about 1984 I was able to use a 16-bit character set on the Xerox Lisp Machines. I've still got a manual for the XNS character set somewhere. In one of the founding documents for the ISO Prolog standard, I recommended, in 1984, that the Prolog standard. That's THREE YEARS before Unicode was a gleam in its founders' eyes. This is NOT new. As soon as there were bit-mapped displays and laser printers, there was pressure to allow a wider range of characters in programs. Let me repeat that: 30 years ago I was able to use non-ASCII characters in computer programs. *Easily*, via virtual keyboards. In 1987, the company I was working at in California revamped their system to handle 16-bit characters and we bought a terminal that could handle Japanese characters. Of course this was because we wanted to sell our system in Japan. But this was shortly before X11 came out; the MIT window system of the day was X10 and the operating system we were using the 16-bit characters on was VMS. That's 27 years ago. This is not new. So what _is_ new? * A single standard. Wait, we DON'T have a single standard. We have a single standard *provider* issuing a rapid series of revisions of an increasingly complex standard, where entire features are first rejected outright, then introduced, and then deprecated again. Unicode 6.3 came out last year with five new characters (bringing the total to 110,122), over a thousand new character *variants*, two new normative properties, and a new BIDI algorithm which I don't yet understand. And Unicode 7.0 is due out in 3 months. Because of this - different people WILL have tools that understand different versions of Unicode. In fact, different tools in the same environment may do this. - your beautiful character WILL show up as garbage or even blank on someone's screen UNLESS it is an old or extremely popular (can you say Emoji? I knew you could. Can you teach me how to say it?) one. - when proposing to exploit Unicode characters, it is VITAL to understand that the Unicode "stability" rules are and which characters have what stable properties. * With large cheap discs, large fonts are looking like a lot less of a problem. (I failed to learn to read the Armenian letters, but do have those. I succeeded in learning to read the Coptic letters -- but not the language(s)! -- but don't have those. Life is not fair.) * We now have (a series of versions of) a standard character set containing a vast number of characters. I very much doubt whether there is any one person who knows all the Unicode characters. * Many of these characters are very similar. I counted 64 "right arrow" characters before I gave up; this didn't include harpoons. Some of these are _very_ similar. Some characters are visibly distinct, but normally regarded as mere stylistic differences. For example, <= has at least three variations (one bar, slanted; one bar, flat; two bars, flat) which people familiar with less than or equal have learned *not* to tell apart. But they are three different Unicode characters, from which we could make three different operators with different precedence or associativity, and of course type. > My thoughts on this (of a philosophical nature) are: > http://blog.languager.org/2014/04/unicode-and-unix-assumption.html > > If we can get the broader agreements (disagreements!) out of the way to > start with, we may then look at the details. I think Haskell can tolerate an experimental phase where people try out a lot of things as long as everyone understands that it *IS* an experimental phase, and as long as experimental operators are kept out of Hackage, certainly out of the Platform, or at least segregate it into areas with big flashing "danger" signs. I think a *small* number of "pretty" operators can be added to Haskell, without the sky falling, and I'll probably quite like the result. (Does anyone know how to get a copy of the collected The Squiggolist?) Let's face it, if a program is full of Armenian identifiers or Ogham ones I'm not going to have a clue what it's about anyway. But keeping the "standard" -- as in used in core modules -- letter and operator sets smallish is probably a good idea. From mail at nh2.me Wed Apr 30 14:13:58 2014 From: mail at nh2.me (=?windows-1252?Q?Niklas_Hamb=FCchen?=) Date: Wed, 30 Apr 2014 15:13:58 +0100 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: <1398858075.4602.21.camel@kirk> References: <535FD3F7.2080402@nh2.me> <1398858075.4602.21.camel@kirk> Message-ID: <53610526.907@nh2.me> On 30/04/14 12:41, Joachim Breitner wrote: > Did you look at the GHC Core generated? When starting to investigate > performance issues, reading Core simply is required ? otherwise it?s > like search for a lost plain while refusing to look under the water > surface. Of course. A short look with ghc-core on import Data.List main = print (foldl' (*) 0 [0..100000::Int]) reveals that the original list traversal is still present: $wlgo = \ (ww_s1HD :: Int#) (w_s1HF :: [Int]) -> case w_s1HF of _ { [] -> ww_s1HD; : x_asn xs_aso -> case x_asn of _ { I# y_asz -> $wlgo (*# ww_s1HD y_asz) xs_aso } } There is not much point investigating further until collecting the responses from this list - as it turned out, you already fixed the problem. Thanks! For performance-critical code, it seems sensible for me to stick to my `forLoop` for now, as it works quite well with the existing GHCs and much less brain seems to be necessary to get that compile down to fast code. From mail at joachim-breitner.de Wed Apr 30 14:34:18 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 30 Apr 2014 16:34:18 +0200 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: <53610526.907@nh2.me> References: <535FD3F7.2080402@nh2.me> <1398858075.4602.21.camel@kirk> <53610526.907@nh2.me> Message-ID: <1398868458.28481.3.camel@kirk> Hi, Am Mittwoch, den 30.04.2014, 15:13 +0100 schrieb Niklas Hamb?chen: > For performance-critical code, it seems sensible for me to stick to my > `forLoop` for now, as it works quite well with the existing GHCs and > much less brain seems to be necessary to get that compile down to fast > code. I agree. I think one big problem is that RULES (e.g. list fusion) are great when they work, but it is very hard for the ?normal? Haskell programmer to confirm that they work as expected, let alone predict when they work. I don?t have a good solution, though. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From davidleothomas at gmail.com Wed Apr 30 14:57:54 2014 From: davidleothomas at gmail.com (David Thomas) Date: Wed, 30 Apr 2014 07:57:54 -0700 Subject: [Haskell-cafe] forLoop + strict State monad is much faster than foldl' In-Reply-To: <1398868458.28481.3.camel@kirk> References: <535FD3F7.2080402@nh2.me> <1398858075.4602.21.camel@kirk> <53610526.907@nh2.me> <1398868458.28481.3.camel@kirk> Message-ID: Maybe some means of asserting that a rule is applied? Hopefully by effect (this list should not appear in the core, or whatnot) rather than by naming the particular rule... On Wed, Apr 30, 2014 at 7:34 AM, Joachim Breitner wrote: > Hi, > > Am Mittwoch, den 30.04.2014, 15:13 +0100 schrieb Niklas Hamb?chen: >> For performance-critical code, it seems sensible for me to stick to my >> `forLoop` for now, as it works quite well with the existing GHCs and >> much less brain seems to be necessary to get that compile down to fast >> code. > > I agree. I think one big problem is that RULES (e.g. list fusion) are > great when they work, but it is very hard for the ?normal? Haskell > programmer to confirm that they work as expected, let alone predict when > they work. I don?t have a good solution, though. > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From miguelimo38 at yandex.ru Wed Apr 30 15:04:25 2014 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Wed, 30 Apr 2014 19:04:25 +0400 Subject: [Haskell-cafe] Escaping phantom type Message-ID: <2573311398870265@web21j.yandex.ru> Hi cafe! Assume I have some function foo :: A x -> B x Now, the type B is somewhat complicated. It consists of several parts. So, if we call foo twice, like let b1 = foo a b2 = foo a then it's possible that we'd use some parts of b1 and b2 together, mistakenly assuming they are from the same B, not from different ones. I want to exclude this possibility. So I introduce a phantom type, and the signature becomes this: foo :: A x -> exists y. B x y (of course that's not a legitimate Haskell, in reality I'll use some GADT) Now b1 and b2 would have different types, and we can't mix them up by mistake. So far so good. But let's assume that we want to use "foo" recursively. Without the safety precautions it would be easy: generateA :: B x -> OtherArgs -> A x ... b = foo (generateA b otherArgs) Unfortunately, we can't do the same thing with this safety net in place. If we do generateA :: B x y -> OtherArgs -> A x where x doesn't depend on y, then generateA would loose the phantom type, so let b = foo (generateA b otherArgs) in b and let b1 = foo (generateA b1 otherArgs) b = foo (generateA b1 otherArgs) -- sic! in b would be indistinguishable. And that is definitely not what we want. In reality, we want x to depend on y. Unfortunately, there are lots of possibilities regarding the way x would depend on y. I know for sure that there would be many different "generateA" functions, and I don't want to encode them all in types. I've come up with one solution: foo :: (forall y. exists x. ((B x y -> A x), (B x y -> z))) -> z This would work, as in the end I would be interested not in B, but in something that would have nothing to do with this phantom types. But that requires explicit CPS transformation, which makes the code difficult to read. Is there some way to simplify things? To make them easier to use? From mail at nh2.me Wed Apr 30 15:21:22 2014 From: mail at nh2.me (=?ISO-8859-1?Q?Niklas_Hamb=FCchen?=) Date: Wed, 30 Apr 2014 16:21:22 +0100 Subject: [Haskell-cafe] ANN: loop - fast for loops Message-ID: <536114F2.2060400@nh2.me> Announcing the first version of the loop package: http://hackage.haskell.org/package/loop This is for iterating over numeric or otherwise iteratable things in a fast fashion. Looks like C, runs like C. It's trivial, but very robust performance-wise and more independent of GHC smartness or non-smartness in regards to optimising alternatives like `forM_ [1..n]`. It comes with a lot of benchmarks. Contributions are very welcome. From mail at nh2.me Wed Apr 30 15:28:04 2014 From: mail at nh2.me (=?ISO-8859-1?Q?Niklas_Hamb=FCchen?=) Date: Wed, 30 Apr 2014 16:28:04 +0100 Subject: [Haskell-cafe] ANN: reinterpret-cast - byte-casting word-size numbers Message-ID: <53611684.3050402@nh2.me> Announcing the first version of the reinterpret-cast package: Hackage: http://hackage.haskell.org/package/reinterpret-cast Github: https://github.com/nh2/reinterpret-cast Takes the bit representation of a number and uses it for a different numeric type. This is reinterpret_cast from C++ and float f = 1.23; int i = * (int *) &f; from C. I started writing this because the PointCloudLibrary project (PCL) makes RGB colours available as an int-packed format cast to a float value - that's silly but oh the legacy. I was surprised that fast reinterpret casts are not readily available in base or at least GHC, but there are improvements going on (see links in the README). Meanwhile this package is for dealing with it. The way implemented here is the fastest possible way known to me as of now. In particular, it is faster than what data-binary-ieee754 does at the moment. Contributions are very welcome.