Re: [Haskell-cafe] Lifting IO actions into Applicatives
Tom Ellis wrote: Shouldn't it be an *Applicative* constraint? class Applicative t = ApplicativeIO t where liftIO :: IO a - t a and require that liftIO (pure x) = pure x liftIO (f * x) = liftIO f * liftIO x Seems like ApplicativeIO makes more sense than MonadIO, which is unnecessarily restrictive. With planned Functor/Applicative/Monad shuffle, the former could completely replace the latter. In fact, it even makes sense to define it as FunctorIO, with the only laws being that liftIO commutes with fmap and preserves id, i.e., that it is a natural transformation. (Those laws are also needed for ApplicativeIO and MonadIO.) Since Haskell is not dependently typed and we specify laws only as human-readable comments, should we define only FunctorIO and then just specify in the comments the additional laws that should be satisfied for Applicative and Monad? Or should we have equivalent definitions that differ only in the laws that are expected to be satisfied? Or should the different definitions have different superclass constraints? Let's get it right this time and not create yet another Functor/Applicative/Monad mess. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lifting IO actions into Applicatives
Dan Burton wrote: From what you've said, it sounds like you can already write: serverSide :: IO a - Form a This seems elegant enough to me for your needs. Just encourage it as an idiom specific to Forms. myBlogForm = Blog $ titleForm * serverSide getCurrentTime * contentsForm Could you abstract `serverSide` out into a typeclass, such as ApplicativeIO? Sure. but why bother? The point is, you've got the specialization you need already. In my opinion, this is the nicest answer to the original question about yesod forms. But the more general question that it led to is an interesting and important one. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with mailman at projects.haskell.org
The mailman daemon process on the server apparently exited for some reason. I restarted it, and now mail traffic seems to be going through normally again. -Yitz On Sun, May 12, 2013 at 9:21 PM, Carter Schonwald carter.schonw...@gmail.com wrote: I've had this problem too. Was trying to sign up for the llvm HS lib list but cant. I asked on Haskell irc and no one seems to know who admins the lists currently. On May 12, 2013 7:24 AM, Tim Docker t...@dockerz.net wrote: Hi, Has anyone noticed problems with the mailman instance running at projects.haskell.org? As best I can see there are no new posts in any of the hosted list archives since mid April. I know that there have been posts made to ch...@projects.haskell.org in May, and these have neither be distributed or archived. I've not had a response from mail...@projects.haskell.org. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with mailman at projects.haskell.org
Quite possible, though I did see some messages going through from two days ago when the mailman daemon went south. Anyone who sent out an important message to one of those lists during the past two days should double check that it now went out to the list. -Yitz On Tue, May 14, 2013 at 12:17 AM, Tim Docker t...@dockerz.net wrote: Thanks - I can confirm all is working again. I believe than, within some time window. some messages may have been dropped. Tim On 14/05/13 07:06, Yitzchak Gale wrote: The mailman daemon process on the server apparently exited for some reason. I restarted it, and now mail traffic seems to be going through normally again. -Yitz On Sun, May 12, 2013 at 9:21 PM, Carter Schonwald carter.schonw...@gmail.com wrote: I've had this problem too. Was trying to sign up for the llvm HS lib list but cant. I asked on Haskell irc and no one seems to know who admins the lists currently. On May 12, 2013 7:24 AM, Tim Docker t...@dockerz.net wrote: Hi, Has anyone noticed problems with the mailman instance running at projects.haskell.org? As best I can see there are no new posts in any of the hosted list archives since mid April. I know that there have been posts made to ch...@projects.haskell.org in May, and these have neither be distributed or archived. I've not had a response from mail...@projects.haskell.org. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
Johan Tibell wrote: I suggest that we implement an alternative haddock syntax that's a superset of Markdown. Here is a previous thread on this exact topic, from five years ago: http://www.haskell.org/pipermail/haskell-cafe/2008-February/039846.html It mentions a few additional shades of bikeshed color that have not yet been proposed in the current thread. Enjoy, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Recursive timezone-loading function
Hi David, David Thomas wrote: https://github.com/dlthomas/tzcache A small bit of code, but seems likely to be useful enough that I figured I should share. Thanks for sharing this! 1) Does this already exist somewhere I missed? I haven't seen it anywhere. 2) It seems silly to make this its own library - any suggestions where it could be added? If you feel it is appropriate, I would be willing to add it to timezone-olson. Does anyone else have an opinion about it? 3) Is the traverse-a-directory-and-populate-a-map pattern one worth abstracting? If so, where should that go? I think the proper abstraction would be a more general fold or traversal over a directory structure. Some languages have something like that (e.g., os.walk in Python). But look how simply it worked out for you in Haskell - perhaps that's why there doesn't seem to be a standard function for this anywhere. That said, it might be interesting to have this as a lens-package-style traversal. 4) Presently, it's a static cache entirely pre-loaded. This seems fine, as it's not a terribly huge amount of data, but it's worth noting. Yes. The total amount of timezone data in the world is likely to continue increasing at a significantly slower rate than Moore's law. 5) Any comments on the code generally? Improvements? Complaints? I like your code. I'm not sure how well this brute-force mapM recursion would scale over a timezone directory structure with, say, millions of nodes. But that's not the use case here at all. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Adding to / subtracting from a LocalTime?
Adde Nilsson wrote: Ok, do you know of any way to add/subtract without converting to UTC and back? Brandon Allbery wrote: I'm not sure I'd do that in any environment, since usually libraries don't deal with the result crossing a daylight/summer time change (and those that do, surprise surprise, normalize to UTC). Didn't know, thanks. Back in Haskell land my conclusion is that if you're planning on doing pure date calculations you have to pass a TimeZone as well. For that to work near clock changes, you need to have the latest summer time/DST policies coded in your app so that you can pass the correct TimeZone. You also need hand-coded logic to handle clock times that occur twice, and clock times that never occur at all, due to changes of clock. shameless-plug An alternative is to use the timezone-series package. Your timezone series knows about the latest clock change policies if you create it from an up-to-date Olson timezone file using the timezone-olson package. http://hackage.haskell.org/package/timezone-series http://hackage.haskell.org/package/timezone-olson /shameless-plug Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
Bryan O'Sullivan wrote: A substantial number of the difficulties I am encountering are related to packages specifying upper bounds on their dependencies. This is a recurrent problem, and its source lies in the recommendations of the PVP itself I think the PVP recommendation is good, though admittedly one that in practice can be taken with a grain of salt. Publishing supposedly stable and supported packages with no upper bounds leads to persistent build problems that are tricky to solve. A good recent example is the encoding package. This package depends on HaXML = 1.19, with no upper bound. However, the current version of HaXML is 1.23, and the encoding package cannot build against it due to API changes. Furthermore, uploading a corrected version of encoding wouldn't even solve the problem completely. Anyone who already has the current version of encoding will have build problems as soon as they upgrade HaXML. The cabal dependencies are lying, so there is no way for cabal to know that encoding is the culprit. Build problems caused by missing upper bounds last forever; their importance fades only gradually. Whereas it is trivially easy to correct an upper bound that has become obsolete, and once you fix it, it's fixed. For actively maintained packages, I think the problem is that package maintainers don't find out promptly that an upper bound needs to be bumped. One way to solve that would be a simple bot that notifies the package maintainer as soon as an upper bound becomes out-of-date. For unresponsive package maintainers or unmaintained packages, it would be helpful to have some easy temporary fix mechanism as suggested by Joachim. Joachim also pointed out the utility of upper bounds for platform packaging. Why throw away much of the robustness of the package versioning system just because of a problem we are having with these trivially easy upper-bound bumps? Let's just find a solution for the problem at hand. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is protocol-buffers package maintainer reachable?
Johan Tibell wrote: If Chris is indeed out of the loop we should find a new maintainer. Mark and I are also interested in the future of protocol buffers in Haskell. Also, Chris is the maintainer of some regex packages that are in the Haskell Platform. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems installing Data.Encoding package
Pēteris Paikens wrote: I'm stuck at trying to get Data.Encoding package functional. Cabal gives the following error message: This is caused by a problem with the cabal file in the encoding package. Often it causes the entire GHC package system to get confused, as pointed out by Brandon. The problem is that encoding depends on HaXML, but only sets a lower bound for the version of HaXML (= 1.19) with no upper bound. The encoding package does not work with the current version of HaXML. There have been several bumps of the major version number of HaXML (1.22 1.19). A lot of people have been experiencing problems due to this bug. I am including the person listed as the maintainer of the encoding package in the CC to this message. I hope that the bug will soon be fixed. In the meantime, you can edit the cabal file of the encodings package manually. (Set its version number to something weird, with extra components, to avoid future problems.) Hope this helps, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data newtype differences. Today: strictness
Yves Parès wrote: Is there some litterature expliciting in a less empiric way than I did the differences like this between data and newtype? I've never come against such documentation through all my learning of Haskell, yet I think it's an important point. Roman Cheplyaka wrote: See the Haskell report, section 3.17.2 Informal Semantics of Pattern Matching [1]. And section 4.2.3 of the report [2] addresses exactly your points very explicitly: A type created by newtype differs from an algebraic datatype in that... The following examples clarify the differences between data (algebraic datatypes), type (type synonyms), and newtype (renaming types)... Regards, Yitz [1] http://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-63.17.2 [2] http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-740004.2.3 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Serializing UTCTimes
Bas van Dijk wrote: What's the recommended way for serializing (with the cereal package) an UTCTime? Serialize the Day part as an Integer using toModifiedJulianDay/ModifiedJulianDay, (Note that Day is not a constructor, it's just the name of the type.) Serialize the DiffTime as a Rational, as Ertugrul said. I'm now using the datetime package Why? It just obscures the time library. But I will have to look at the code of datetime to see if I'm not losing precision. You are losing precision. If you only care about time to the nearest second, you can truncate the Rational of the DiffTime (don't round, because this may be the last second of a day) and then use fromIntegral to deserialize. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OpenAL bindings?
Jason Dagit wrote: Looks like the repo [1] for the OpenAL bindings that Sven Panne created [2] is no longer available. I assume this is a result of The Great Server Outage of 2011 [3]. [1] http://darcs.haskell.org/packages/OpenAL/ [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OpenAL [3] http://www.haskell.org/pipermail/haskell-cafe/2011-February/088829.html No, darcs.haskell.org is not the community server. It is a separate server that seems to be located at Galois. I see that the following darcs repositories are available on the community server: http://code.haskell.org/OpenAL/OpenAL http://code.haskell.org/OpenAL/ALUT Hope this helps, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] DB vs read/show for persisting large data
Yves Parès wrote: (^^ Michael just outposted [1] me). [1] I don't know if there is such a word. Sorry, I'm french. If there wasn't before, there is now. It's a great word! (Et je suis en effet un anglophone.) -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No instance for (Read POSIXTime)
dokondr wrote: All I actually need is some way to get *seconds* since epoch from the system, so I could manipulate them as integers. Well, you already have that - that's exactly what POSIXTime is. It is a numerical type, an instance of the RealFrac class. So perhaps you can do all of your calculations within that type itself, without converting it to anything else. If you really do need to convert it, *please* don't do that by going all the way to String and back! Just cast it or convert like you would any other numerical type. To make it a Fractional, like Float, Double, or Rational, use realToFrac. Since POSIX allows time to be specified with granularity much finer than seconds, the POSIXTime type is not an instance of Integral. (Even on operating systems where POSIX does happen to be counted in whole seconds.) So to get to an Integral type, you'll need to use some kind of rounding function, like round, floor, or ceiling. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting off many/some from Alternative
Gregory Crosswhite wrote: could we split the some/many methods out from Alternative? They simply don't make sense except in a subset of possible Alternatives --- in most cases they just result in an infinite loop... That is a very good point. I would be in favor of such a change, even though it would be somewhat disruptive. I suspect that there are not more than a couple of packages out there that make active use of the some/many instances of Alternative; it is really only parser packages that need some/many, and users most likely use the versions included with the packages themselves rather than the Alternative version. No, I have *tons* of modules that contain parser code and import those. I suspect many others do too. But I am prepared to bite the bullet; this is a real wart. It thus makes sense for there to be some subclass of Alternative called something like Consumptive that contains these methods. Brandon Allbery wrote: Parsive I like that better. But let's not get stuck on bikeshedding. I'm in favor no matter what name is chosen. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] No instance for (Read POSIXTime)
dokondr wrote: When I try to read POSIXTime... No instance for (Read POSIXTime)... What should I do to provide Read instance for POSIXTime? Short answer: if you are thinking about this as a moment in time that could be parsed from the usual kind of string representation for that, you probably want to use UTCTime in your data type, not POSIXTime. If you really, really want to represent it internally as POSIXTime, then you should read those strings as UTCTime and then convert them to POSIXTime to store in your data type. I.e., in that case don't make your data type an instance of Read. POSIXTime is just a type alias for NominalDiffTime, i.e., a quantity of time between two moments. This is what the Show instance looks like: Prelude Data.Time realToFrac 100 :: NominalDiffTime 100s By convention, the Read instance would expect a string in that format. Generally people aren't interested in that, so there is no Read instance. Even if you did want to parse that, you would just parse it as a number and then use realToFrac, as I did above. The rule of thumb is: always represent moments in time as a UTCTime. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why doesn't this work? (palindrome :: IO)
Brandon Allbery wrote: case () of () | s == reverse s - putStrLn palindrome _ - putStrLn nope Tom Murphy wrote: This is kind of a hack of case, though. I think what the OP was looking for is isPalindrome word | (word == reverse word) = putStrLn (word ++ is a palindrome) | otherwise = putStrLn (word ++ is not a palindrome) Erm? It's as much of a hack of case as yours is, since the above is actually using case. I agree with Tom here. While it's true that the compiler internally desugars to case, that low-level compiler transformation doesn't have much to do with the best way to write clear code. I find that case often creates code that is more confusing and bug-prone. Except when what I really want to express is pattern matching, *and* there is some specific reason here why I don't want to use a named function in a let or where binding. Altogether, it doesn't come up very often for me. And even for styles that use case more than I do, certainly there is room to call the use of the case () idiom a hack. (Even though I'll admit that I do use it sometimes.) Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 1p function for NonEmpty
Hi Edward, I started @telling you on #haskell, but it has become too long for that. :) The following functions would be nice additions to Data.List.NonEmpty in the semigroups package: replicate1p :: Whole n = n - a - NonEmpty a take1p :: Whole n = n - NonEmpty a - NonEmpty a splitAt1p :: Whole n = n - NonEmpty a - (NonEmpty a, [a]) Also, your warnings in the haddocks about blowing up on negative arguments don't seem to be needed for take, drop, and splitAt. We could avoid the problem with negative arguments for (!!) too by providing an alternative for Whole numbers. But in that case the function would still be partial, so I'm not sure if it's worth it. I wish there were some way to get Whole to default to Natural. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 1p function for NonEmpty
I wrote: The following functions would be nice additions to Data.List.NonEmpty in the semigroups package... Here are two more requests: maximum, minimum :: Ord a = NonEmpty a - a Two more unsafe Prelude functions become safe! Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] timezone-series, timezone-olson dependencies
Ben Gamari wrote: Is there a reason why the current version of the timezone-series and timezone-olson packages depend on time1.3? With time 1.4 being widely used at this point this will cause conflicts with many packages yet my tests show that both packages work fine with time 1.4. Could we have this upper bound bumped to 1.5? Done. The version of each package was bumped to 0.1.2 to support the new dependency. Also, catTZ.hs had been missing from the darcs repo, though it is included in the hackage distribution package. Thanks for the heads-up, Ben! Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Time zones and IO
Ben Gamari wrote: Recently I've been working on an iCalendar parser implementation with support for recurrence rules. For the recurrence logic, I've been relying on Chris Heller's excellent time-recurrence package. Unfortunately, it seems we have both encountered great difficulty in cleanly handling time zones... tz = unsafePerformIO getCurrentTimeZone Ouch... Passing the current timezone as an argument seems heavy-handed and reveals the leakiness of the CalendarTimeConvertible abstraction. Short of making toCalendarTime an action, can anyone see a suitable way of refactoring CalendarTimeConvertible to avoid unsafe IO? Well, timezone info definitely is something from the outside world, and it even changes over time (very slowly). So it's IO. Yet just about all of what your library does is pure. So passing timezone info as a parameter to pure functions is the most straightforward approach. You would pass the timezone as a parameter to all pure functions that need it. If the need for the tz parameter is ubiquitous, it might then be worth it to use a pure reader monad of some kind. As a convenience, you might provide one or more functions that do the timezone lookup, do the pure calculation, and return the result in IO. All of that does require refactoring CalendarTimeConvertible though, yes. I think the use of unsafePerformIO is a pretty sure sign that the design of CalendarTimeConvertible could use some improvement. Perhaps a TimeZoneInfo monad is in order, exposing lookup of arbitrary (through timezone-olson) as well the current timezone? It seems like this would be inconvenient and overkill, however. I agree. This whole calculation is pure, really. It would be a shame to force the entire thing into an impure monad just because of timezones. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage feature request: E-mail author when a package breaks
I wrote: This would be nice. However, there would have to be a way for it to be turned on and off by the author. (Spam is not nice.) Ketil Malde wrote: This is where it stranded the last time, IIRC. That sentiment makes me a bit uneasy; so you are the official maintainer of a package on Hackage, but you do not want to hear about it when it fails to compile? You are absolutely right about this. In fact, besides build failures, it probably would be a good idea for each maintainer to get, say, one automated email per month with a summary of all the packages that person is officially maintaining, even when there are no build failures. So I'm changing my vote to +1. But let's think about why the instinctive reaction is to be hesitant about this. First of all, an automated system like a build bot can go wrong. What guarantee is there that I won't be flooded with emails when that happens, if I can't shut it off myself? Second, let's say someone decides they don't want to be maintainer anymore. Are they married for life? There is currently no way to remove a package. I guess they would have to upload a new version with no maintainer. I am just a little worried that if uploading to Hackage requires agreeing to unlimited uncontrollable spamming by a bot, it may cause some good packages not to be uploaded by people who are hesitant to agree to that. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage feature request: E-mail author when a package breaks
Gregory Crosswhite wrote: could [Hackage] have a feature where when a working package breaks with a new version of GHC the author is automatically e-mailed? This would be nice. However, there would have to be a way for it to be turned on and off by the author. (Spam is not nice.) Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] blanket license for Haskell Platform?
Eric Y. Kow wrote: So I'm combining Haskell software with some non-free/closed source work. I was wondering what sort of effort it would take to organise a blanket license for everything in the Haskell Platform, and whether it would be worthwhile to anybody... - My user is concerned that a large number of having a large number of individual licenses even though textually identical modulo author, date, etc would mean a big hassle getting their lawyers and their user's lawyers to sign off on each and every license I agree that this is an important issue. I think we should focus on the primary requirement that Haskell software written for a commercial environment should not create usability issues from a legal perspective. If we clarify that question carefully, then as an important FOSS community we might be able to send the question to the EFF and get some guidance about how best to proceed. SPDX sounds interesting; I'd like to hear more about it. Besides that, it may not be as impractical as you think to have mass license assignment and/or copyright assignment as a medium-term goal for the platform. There has been talk about the Haskell community joining the Software Freedom Conservancy (as Darcs did). If that happens, it will give us a solid legal foundation for assigning assets such as these to the community as a non-profit organization. (Although I haven't heard anything recently, and Yale U. is still the registrant of the haskell.org domain.) I wonder if this is a sort of thing we could tie to the IHG... It would be great if the IHG could help push this effort. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hello Haskell
Daniel Fischer wrote: Just for the record, not a newcomer, and has non-spam messages Conrad Parker wrote: There was a recent hotmail exploit, with people reporting their account sent spam... No exploit is needed. It is trivial for an impostor to seem as if he is sending email from someone else's account, and spammers do that all the time. There is nothing special about Hotmail. There are some ways to detect that kind of fraud. One method is SPF, which is currently being pushed by Google and some other email providers: http://openspf.org/ Unfortunately, Mailman, or at least the version we are currently using on all of our servers, does not support this AFAIK. In fact, our domains do not even have SPF records themselves yet. So all mail from our mailing lists is flagged as suspicious by Google and many other providers. I hope that will be fixed soon. It's true, even when a system like SPF is in place, it is still possible to bypass it by breaking in to an email account and actually sending the spam from there. But we have not yet reached the point where such an exploit is even needed. For now, we are just relying on the classic method of using a server-side spam filter. This incident seems to have gotten past that. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The best way to call Java from Haskell?
Dmitri wrote: I need to call Stanford NLP Parser from Haskell (unfortunately Haskell does not have a similar one)... Just out of curiosity, why do you not consider GF at all similar? To an outsider like me, there does appear to be quite a bit of similarity. http://www.grammaticalframework.org/ Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell i18n best practices
Thanks for all the great information provided in this thread. The wiki page that Paulo originally linked had Vasyl's fantastic documentation for using his hgettext package, but it did not mention any of the other methods we discussed. I moved the gettext documentation to its own linked page and tried to collect together the general information from this thread. Please take a moment and look it over. Correct any mistakes I made. http://haskell.org/haskellwiki/Internationalization_of_Haskell_programs Rogan, especially, please look it over. I really had to read between the lines to come up with a clear and concise description of GF and what it does, so I may have gotten it wrong. Felipe, I put your wonderful example on its own linked page. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirely great?
Chris Smith wrote: class Ord a = Range a where... Before adding a completely new Range class, I would suggest considering Paul Johnson's Ranged-sets package: http://hackage.haskell.org/package/Ranged-sets Ranges have many more natural operations, and interactions with other classes, than you mention. The Ranged-sets package is well thought out and general. It distinguishes carefully between discrete and non-discrete types, and provides appropriate instances for the standard types. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Attoparsec: Limiting Parsers to N Bytes, or Combing Parsers?
Evan Laforge wrote: hex2 = (+)$ ((*16)$ higit)* higit higit = subtract (fromEnum '0')$ satisfy isHexDigit color = Color$ hex2* hex2* hex2 Twan van Laarhoven wrote: How is subtract (fromEnum '0') supposed to convert a hex digit to an Int or Word8? I think you need digitToInt (or an equivalent function) for that. Right. How about: color = Color $ hex2 * hex2 * hex2 hex2 = mkHex2 $ hexit * hexit hexit = satisfy isHexDigit mkHex2 h1 h0 = fst . head $ readHex [h1, h0] Or, if you are fanatic about safety like I am, you might even write: mkHex2 h1 h0 = maybe 0 fst . listToMaybe $ readHex [h1, h0] Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Solving the configuration problem with parametrized modules
Joachim Breitner wrote: ...Usually in Haskell, you’d determine them in the main function and then pass them in an argument to all functions needing them, or you wrap that in a monad... The big downside is the verbosity of the approach: A lot of parameters need to be passed, and if one such value is suddenly required in a function where it was not before, this function’s signature and all functions using it have to be modified. I'm struggling to understand what problem you are trying to solve. We're talking about passing a single parameter - a record type, or a shallow tree, or something else extremely simple. In the monadic case, we're adding a single Reader component to the transformer stack. I'm currently working on a large system, consisting of hundreds of modules and tens of thousands of lines of code. There are hundreds of configuration parameters, coming from configuration files, modules of compiled-in constants, and the UI. Different subsets of the parameters are needed in various subsystems. Doing that in Haskell has been an absolute pleasure, much much simpler than in any other language I've used for a system of this size. (I'll spare you the horror of what I had to do once for a large system written in C++...) I barely have to think about it - the types reflect the relationships between the configuration and the various parts of the system, and Haskell's type system does the rest automatically, guaranteeing correctness. What else could you ask for? Also, I expect that the explicit passing causes a small performance penalty. We're been processing gigabytes of data - doing non-trivial operations including a kind of image recognition and more - so far with nearly imperceptible delay. The bottleneck, if there is one, will certainly not be the configuration subsystem. I know some Haskell libraries use constructor hiding, or even the data-default package which uses generics, to add more flexibility to the configuration system. But I don't feel the need even for those. I certainly wouldn't dream of dragging in type-level olegery, unsafe coercion, implicit parameters and other experimental extensions. Simplicity just works. What case are you thinking about? A system several orders of magnitude more complex? Some special case that creates difficulty? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal #3339: Add (+) as a synonym for mappend
Brandon Allbery wrote: Anything useful has to be modified to depend on SemiGroup as well to get mconcat or its replacement; that's why you jumped the proposal to begin with Not at all. Types with Monoid instances need an additional instance, a Semgroup instance, in order to be able to use '' instead of mappend. mconcat is not involved in this discussion. That is the current situation. I am advocating leaving it that way. As others have noted, this is a rather intrusive change to the Haskell ecosystem. Exporting from Data.Monoid is the intrusive change. I am strongly against it. In the long run, it will create ugliness and inconvenience to our class system, which has enough problems as it is. I advocate leaving things as they are. If individual library authors wish to add a Semigroup instance to their Monoid instances as a convenience, which is harmless, I think that would be wonderful. But that is a separate issue. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New releases and BSD3 license
Thanks for the more permissive licenses. And most of all, thanks for all your great work on HDBC as maintainer. Thanks and good luck to Nicolas. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contacting Planet Haskell admins
Hi Michael, Don is no longer involved in planet AFAIK. The administrator of planet-haskell is Antti-Juhani Kaijanaho. I'll send you his email address off list. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Typeable class is changing
I wrote: Please respond to this thread if you own a package that will be affected by this change. Responding to my own request, here are some more packages that use mkTyCon explicitly: Ashley Yakeley's time package, which is part of the Haskell Platform. My timezone-series package, because it is based on the time package. John Millikin's xml-types package. My dtd-types and dtd-text packages, because they are based on the xml-types package. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Typeable class is changing
Jon Fairbairn wrote: There’ll be a replacement for mkTycon (mkTycon3), so you can still do manual instances… Right, it should be easy to fix manual Typeable instances. It's just that if no action is taken, they will eventually break. So it's good to make sure that there is public awareness, and for the community to have awareness about the scope of the changes that need to be made. Also, we should clarify that AFAIK everyone agrees that this is a welcome improvement to Typeable. We are just trying to smooth the upgrade process so that it does not cause unexpected inconvenience to users of the various libraries on Hackage. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The Typeable class is changing
Simon Marlow has announced[1] on the Haskell Libraries list that the Typeable class is changing. The standard way to create a Typeable instance is just to derive it. If you do that, you will not be affected by this change. But it seems that many packages create Typeable instances by explicitly using mkTyCon. If your package does this, it will eventually break, after a deprecation period. Please respond to this thread if you own a package that will be affected by this change. Can someone who has quick access to the entire contents of Hackage please do a grep and find out exactly which packages on Hackage will be affected? Thanks. -Yitz [1] http://www.haskell.org/pipermail/libraries/2011-July/016546.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
I wrote: Not exactly. A TimeZone in Data.Time doesn't really represent a time zone - it represents a specific clock setting in a time zone. Ashley Yakeley wrote: I still regret this! I should have called it TimeOffset or somesuch. Oh, it's not your fault. Every other time library in the world calls that a time zone. You've gotten so many other more substantial things right that so many others got wrong. This name is nothing to worry about. To get a TimeZoneSeries, representing a time zone with all of its known clock changes throughout history and some years into the future, use the timezone-olson package[2] to read an Olson time zone file. On Linux and Mac OS X systems, Olson time zone files are available in the directory /usr/share/zoneinfo. Leap second data is there too, so it should be possible to create a Data.Time.Clock.TAI.LeapSecondTable from it. No, unfortunately. There is a place in the data structure for leap second information, but no live Olson file has every populated it AFAIK. That's not so important though. There have been very few leap seconds in history, and they occur rarely. Their release cycle has been slower than the usual release cycle of software packages. So this is something that could easily be done manually. Also, it might be worth creating an OS-specific package that dealt with the filepaths for you, so for instance you could read in a TimeZoneSeries given a time zone name such as America/Los_Angeles. That would be nice. Perhaps a higher priority would be to add support for Windows, where the Olson data is in the registry rather than in the file system. Right now, people on Windows are still dependent on asking a favor from their friends to lend them copies of the latest Olson files. Another important enhancement would be support for POSIX rules. Olson files still supply explicit clock changes for about two decades into the future. But I believe that will gradually end now that the new Olson file format supports POSIX rules for clock changes beyond the last one explicitly specified. (And besides being supported, recently released Olson files actually do contain the POSIX rules. So does the Windows registry.) Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: Data.Time
Ashley, heads up! I am CCing you on this message because I think a problem has been found with Data.Time.Format. Please see below. Daniel Patterson wrote: I've found most of the time library to be quite useful, but the parsing to be worthless The API for parsing and rendering time in Data.Time is based on the standard API for that in C - like the libraries in most languages. It's pretty standard stuff. I'm sure it can be improved upon though. If you have a useful alternative time parsing library, please release it on Hackage. Specifically, the formatTime function, if it ever strips out padding (by zeros or spaces), results in a time that is unparseable. The fact that formatTime and parseTime are not capable of being inverses of each other seems like a major flaw, Well, it is possible to render dates and times in a way that loses information, so you can't expect those to be complete inverses of each other. when you think that this is not a parseable date: 2011/1/30 (because the month must be padded by zeros). Hmm, that does seem wrong. The C API allows that to be parsed using the format %Y/%m/%d, since the leading zero for %m and %d are optional when parsing. See, for example, http://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html I am including Ashley as a CC on this. Perhaps he will fix it. It looks like the function parseValue is wrong for the following format letters: CdHIjmMSuwW. For each of those, decimal n should replaced by something that requires at least 1 digit and allows up to n. Then the various instances of ParseTime should be checked, but they should be OK because they all seem to use read. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
Joe Healy wrote: One of the points I found non obvious were the fact that local time is just that. There is no knowledge of the actual timezone in the data type. If you wish to store that, it needs to be stored alongside. Erik Hesselink wrote: Isn't that what ZonedTime [1] is for? Not exactly. A TimeZone in Data.Time doesn't really represent a time zone - it represents a specific clock setting in a time zone. Clock settings periodically change in a time zone - e.g., to or from summer time, or due to government decree. A ZonedTime is a LocalTime together with a specific clock setting in a time zone. There is no guarantee that the clock setting was actually in effect at the given LocalTime. So a ZonedTime is only useful if you have checked separately that it is consistent, or if you don't care. ZoneSeriesTime in the timezone-series package[1] more accurately represents a moment in time in a given time zone. There the moment is represented as a UTCTime, not a LocalTime. The reason is that a LocalTime in a time zone does not necessarily represent a unique moment. When the LocalTime happens to be near a clock change, it can represent zero moments or more than one moment. To get the LocalTime from a ZoneSeriesTime, use the function zoneSeriesTimeToLocalTime. To get a TimeZoneSeries, representing a time zone with all of its known clock changes throughout history and some years into the future, use the timezone-olson package[2] to read an Olson time zone file. On Linux and Mac OS X systems, Olson time zone files are available in the directory /usr/share/zoneinfo. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
Oops, forgot the references: ZoneSeriesTime in the timezone-series package[1]... To get a TimeZoneSeries, representing a time zone with all of its known clock changes throughout history and some years into the future, use the timezone-olson package[2] [1]http://hackage.haskell.org/package/timezone-series [2]http://hackage.haskell.org/package/timezone-olson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: Data.Time
Ashley Yakeley wrote: This was fixed in time-1.2.0.5. From the haddock for parseTime: Supports the same %-codes as formatTime, including %-, %_ and %0 modifiers. Great, glad to hear this was recently fixed. I installed the latest version of the time package, and it works. It is important to note that this works differently than the usual strptime behavior, though. For example, %m in Data.Time is an alias for %0m, whereas %m in strptime means the same as %-m in Data.Time (optional leading zero). Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible bug in GHC 7.0.3
Ryan Ingram wrote: So this is definitely a GHC bug, but I think the problem is probably triggered by this line: instance Serializable a b = IResource a I don't think this is a valid instance declaration without a functional dependency on Serializable, as it's impossible to know which type 'b' to use in the methods of IResource. That's not exactly the reason why that line is a problem. The methods of IResource don't use b. Presumably, some of the methods of Serializable don't mention b either, and those could be used in the instance. But what exactly does this instance mean? Where does the implicit forall b go? For this to make any sense, it would need to be: -- Illegal syntax for instance instance (forall b. Serializable a b = IResource a) I don't think it has ever been specified whether it is legal to have free type variables as parameters of a multi-parameter class in the superclass context of an instance declaration, and if so, how to interpret that. Haskell 98/2010 does seem to allow it for single-parameter classes, but there the obvious meaning would be just to ignore those parts of the context. In any case, GHC does seem to be getting very confused. Here is a smaller test case. While it does not trigger the crash, it does cause GHC to give a seemingly nonsensical error message: module ClassContextBug where class A a class B b instance A a = B b ClassContextBug.hs:5:17: Illegal instance declaration for `B b' (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use -XFlexibleInstances if you want to disable this.) In the instance declaration for `B b' I believe this is valid Haskell 98, so GHC should accept it. But even if not, what GHC is claiming in the error message is simply not true. I would like to add this to the bug report. Alberto, have you filed the bug report yet? Can you please post a link? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible bug in GHC 7.0.3
Daniel Fischer wrote:
No, the instance head is just a type variable, not a type constructor
applied to type variables
Oops, you're right. GHC was telling the truth, I should have
paid closer attention!
Fixing my minimal example, I get:
{-# LANGUAGE MultiParamTypeClasses, UndecidableInstances #-}
module ClassContextBug where
class A a oops
class B b
data D d = D d
instance A a oops = B (D a)
and now GHC compiles it happily.
So it's the derived Read instance in this context that
is causing the problem. Here is a slightly smaller test
case that triggers the bug:
{-# LANGUAGE MultiParamTypeClasses, UndecidableInstances #-}
module Bug where
class A a oops
data D d = D d
instance A a oops = Read (D a)
data E e = E (D e) deriving Read
Thanks,
Yitz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
Tony Morris wrote: I recently set out to write a library that required a decent time library. Having only had a flirt with Data.Time previously, I assumed it would be robust like many other haskell libraries. I don't know about consensus, but I have been massively let down. I won't go in to the details... Data.Time is in some ways like Haskell itself. Though at first glance it seems a little daunting, in reality its semantic correctness makes it easier to use, not harder, than any of its alternatives in any language that I know (and I am proficient in quite a few). Once you have caught on, it is difficult to settle for anything less. The biggest shortcoming, in my opinion, is that the documentation assumes that the reader is very familiar with the Haskell type system, and with viewing type signatures and instance lists as an integral and central part of the documentation. In particular, Haskell's standard numeric type classes and the conversion functions between them play a central role in the API of Data.Time. But you wouldn't realize that unless you have read the type signatures and instance lists in the Haddocks very carefully, and have thought about it for a while. Another problem, as Malcolm pointed out, is that because of the sheer size of the library, a quick-start guide for the common cases would be extremely helpful for newcomers. What other issues have you noticed? is there a reasonable alternative to Data.Time If I am right, and there is no alternative, I see no option but to take an excursion into writing my own. No. There are several alternatives, but I have never seen anything that has come close to Data.Time. Before you undertake writing a whole new time library, why not try writing some improved documentation for Data.Time first? I think that would give the most immediate benefit to the community, and I'm sure it would improve the quality of whatever library of your own you end up writing. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 7.0.3 / Win32: Data.Time library?
Dmitri O.Kondratiev wrote: I have: ds1 = 10/11/2009 7:04:28 PM ds2 = 10/17/2009 8:48:29 AM t1 = readTime defaultTimeLocale %m/%d/%Y %l:%M:%S %p ds1 :: UTCTime t2 = readTime defaultTimeLocale %m/%d/%Y %l:%M:%S %p ds2 :: UTCTime dif = diffUTCTime t2 t1 I need to: 1) Find how many complete days elapsed between t1 and t2 It depends what you mean by complete days. If you just mean how many periods of 24 hours of UTC, without caring about things like local clock changes for summer time, then it's just this: floor $ dif / (24 * 60 * 60) Otherwise, see below. 2) Find UTCTime for a moment 6 days after t1, in other words time equal to t1 + 6 * 24 hours. addUTCTime (6 * 24 * 60 * 60) t1 Questions: 1) Is there any library function that will convert (diff = diffUTCTime t2 t1) to a data structure similar to a tuple (days, hours, mins, secs) where 'days' is a whole number of days in my 'diff'' interval, and similar for 'hours', 'mins' and 'secs' in the tuple above? If what you mean is amounts of UTC time, then just use the diffs as floating point numbers. Divide and floor, as above. You don't need any special functions. As you can see, things are easy as long as you stay in UTC. Often that is a little sloppy, but if it is good enough for your program, use it. 2) What is the 'right way' of adding days to UTCTime? Should I add just equivalent number of seconds or should I convert UTCTime to Data.Time.Calendar.Day type first and then use 'addDays' function? If what you need is days, hours, etc. as concepts of local time, and you care about things not going wrong in the unusual case of a change of clock, then yes, you need to convert to local time and do your calculations there. 3) How to convert UTCTime to Data.Time.Calendar.Day and back to UTCTime? If you stay in UTC, it's easy: a UTCTime is made up of a Day and a DiffTime. Suppose you need days in a certain time zone, not UTC. If you already know for each of your input times whether it is standard time or summer time in that time zone, then here is an outline of how: 1. Create a TimeZone for each of standard time and summer time. 2. Use utcToLocalTime with the appropriate TimeZone to convert each input UTCTime to a LocalTime. 3. Use diffDays. If all you care about is days, compare the TimeOfDay with or to see if you need to adjust the number of days by one. Or work with the hours, minutes, and seconds of the TimeOfDay directly. If you don't already know whether your input times are in summer time, then you need the timezone-olson and timezone-series packages. Here is an outline: 1. Get the Olson time zone file provided by your operating system for the time zone in question. On Linux and Mac OS X, it's in /usr/share/zoneinfo. On Windows it's in a binary format in the registry, Unfortunately, we don't have a parser for that format yet, so your best bet for now is to get the Olson files you need from a non-Windows computer. 2. Use a function in the timezone-olson package to read the Olson file and get a TimeZoneSeries. 3. Use utcToLocalTime' from the timezone-series package to get a LocalTime for each of your input times. Then continue as in #3 above. Actually, we started out with parsing a time string, and we have been assuming all along that it represented UTC. As always, that is the easy case. You're also OK if the time string has an explicit offset from UTC, like -0400 for EDT in the U.S. Otherwise, you'll have to parse those strings as LocalTime, not UTCTime. If the LocalTime is what you need, great. If not, use a TimeZone or TimeZoneSeries, as above, to get back to UTCTime. Hope this helps, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 7.0.3 / Win32: Data.Time library?
Dmitri O.Kondratiev wrote:
It would also help to see a simple example of parsing 10/11/2009 7:04:28
PM to time and date objects.
Let's assume that 10/11/2009 means October 11, as in the U.S.
Then you can use:
import System.Locale (defaultTimeLocale)
import Data.Time
thatMoment :: Maybe UTCTime
thatMoment = parseTime defaultTimeLocale %m/%d/%Y %l:%M:%S %p
10/11/2009 7:04:28 PM
Then use diffUTCTime to subtract two UTCTime and
get the amount of time between them. The resulting object
can then be used as if it is a regular floating point number
in units of seconds, or you can use the functions in Data.Time
that treat it specially as an amount of time.
There are many options for the format string and locale that will
affect how the date is parsed - the order of month and day,
leading zeros or leading spaces, upper case or lower case AM or PM
(or 24-hour clock), etc. You can also get different behavior on
parsing failure by using readTime or readsTime instead of parseTime.
For details, see:
http://www.haskell.org/ghc/docs/7.0.3/html/libraries/time-1.2.0.3/Data-Time-Format.html
http://www.haskell.org/ghc/docs/7.0.3/html/libraries/old-locale-1.0.0.2/System-Locale.html#t:TimeLocale
http://www.haskell.org/ghc/docs/7.0.3/html/libraries/old-locale-1.0.0.2/src/System-Locale.html#TimeLocale
As an example of modifying the locale, let's say you want to use a and p
instead of AM and PM, as is customary in some parts of the world.
Then you can say:
myLocale = defaultTimeLocale {amPm = (a,p)}
and then use myLocale instead of defaultTimeLocale.
Hope this helps,
Yitz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SIGPLAN Programming Languages Software Award
The SIGPLAN Programming Languages Software Award For 2011, the winners of the award are Simon Peyton Jones and Simon Marlow of Microsoft Research, Cambridge, for GHC Congratulations! Well deserved recognition for visionary ideas backed by so many years of hard work. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Attoparsec concatenating combinator
Bryan O'Sullivan wrote: Now that I think of it: in principle, you could write a specialised concat that would check the pointer/offset/length combinations of its arguments and, if they all abutted perfectly, would just return a new view into that same array, sans copying. Gregory Collins wrote: The blaze-builder might work for this also, this is exactly the problem it's designed for. Simon Meier wrote: Using a Builder for concatentation makes sense... However, ...some low-level meddling is probably required... I'm inclined look into that... These are great ideas for further exploiting the bytestring/text specialization of this parser library for super speed. Thanks! Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
I wrote: You almost never want to use UndecidableInstances when writing practical programs in Haskell. When GHC tells you that you need them, it almost always means that your types are poorly designed, usually due to influence from previous experience with OOP. wren ng thornton wrote: That's a bit unfair. There are many kinds of type-level hackery which require UndecidableInstances but are (a) perfectly safe for practical use, and (b) have nothing to do with OOP. One particularly trivial example that comes to mind is: newtype Mu f = Mu (f (Mu f)) I agree. I've even used that one (well, something similar anyway). Oleg wrote: It seems that UndercidableInstances keep getting a bad rap. There are legitimate and decidable applications of UndercidableInstances. These applications have nothing to do with OOP, or HList for that matter... That extension should not be categorically stigmatized. I'm sorry if I came across as giving it a bad rap, or stigmatizing it. That was certainly not my intention. There are plenty of excellent techniques that use this and other GHC extensions; accomplished Haskellers should have them in their toolbox. But I stand by my statement, which is coming from my perspective as a professional Haskell software developer, not a PL researcher. Perhaps I should clarify it though. I am making two claims: 1. In everyday practical Haskell programming, it is very unusual that a technique requiring direct use of UndecidableInstances is the right tool for the job. Of course, that observation is colored by my own experience, but I believe that it is generally true. 2. If a person is surprised by the GHC error suggesting that UndecidableInstances is needed and is struggling with understanding it, then it is almost certain that person has inappropriately used OOP thinking in trying to design a Haskell program. Experienced Haskellers familiar with those techniques do not get the error. Or they get it and say, Oops, forgot the UndecidableInstances. Whereas most programmers coming to Haskell have had OOP experience. The first thing that happens when they try to write a program in Haskell of any significant complexity is the UndecidableInstances error. It happened to me, too. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
Scott Lawrence wrote: I'm modelling text in a markov-model-like way. I have an actual markov model (albeit one in which X_n depends on a fixed range X_n-1 .. X-n-k). I'm vaguely anticipating the presence of other models: class Model m a | m - a where lexemes :: m - Set a genFunc :: m - [a] - ProbDist a Generally, we don't start out with a type class. Type classes are great for the special situations in which they are needed (although you can do pretty well without them even then), but first let's get the basic concepts. Perhaps a model is just a function: type Model a = Ord a = Set a - [a] - ProbDist a or something like that. Having that working, I'm trying to estimate the information entropy of a model entropy :: (Model m) = m - Double Perhaps just a function: entropy :: Model a - Double I still don't know enough details about what you're doing, so my types are probably off. But I hope you get the idea. If that's not general enough, you may introduce more functions, or some data types. Those give you a huge amount of power - remember that data types can take multiple type parameters (without any GHC extension), they can have functions as their parameters, etc. Or, perhaps you'll even get to the point where you'll need a type class, but that's pretty far down the road, and what you would need it for is very different than what a class is in OOP - they are different concepts. Hope this helps, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
I wrote: You almost never want to use UndecidableInstances when writing practical programs in Haskell. When GHC tells you that you need them, it almost always means that your types are poorly designed, usually due to influence from previous experience with OOP. Gábor Lehel wrote: Are you sure you weren't thinking of OverlappingInstances here? I haven't seen as much scorn heaped upon Undecidable. Sorry, I didn't mean to come across as heaping scorn on anything. :) Having come from OOP myself, I know that at first you don't realize the power and beauty of functional programming. The vast majority of programming problems have a beautiful solution without stepping outside of Haskell 98. One of the symptoms of thinking about a problem in OOP style rather than functionally is that you immediately find yourself needing all of those kinds of type system extensions, which just end up adding a huge amount of unneeded complexity. Once you are fluent and comfortable with functional thinking, you can learn about the many other tools and techniques that are available and when it is best to apply them. I must admit that even while designing and implementing large systems, I haven't found myself needing anything involving either UndecidableInstances or OverlappingInstances for several years. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
Scott Lawrence wrote: But... this prevents me from storing more information in a Model in the future. While I don't really anticipate needing too (I can see this function covering all likely use cases), it does seem sorta restrictive. I tend not to think about storing information inside of things. I just write functions that do the computations I need - their types describe the desired inputs and outputs. Data types group them together into logical structures that reflect what I want to do. Where the information is coming from and where it is going then remains a totally independent issue. It is a different part of the program. That is actually more flexible, not restrictive. Kind of like the MVC design pattern. The IO monad, which keeps the parts of the program that interact with outside world separate, helps us think in this way. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
Scott Lawrence wrote:
type Model a = (Ord a) = Set a -- the set of lexemes
- [a] -- the original text to model
- [a] -- list of previous lexemes
- ProbDist a -- the next lexeme
and then
entropy :: Model a - Set a - [a] - Double
or perhaps more simply
entropy :: [a] - ProbDist a - Double
Those all look reasonable.
Then in order to get a consistent interface to various models, I'm going
to need a typeclass. (Which is required to use a single function name on
multiple datatypes, yes?)
Why is it important to use the same function name? If you
have two different functions that do two different things, they
can have two different names.
If further down the line you need to write a function that is independent
of the model, the types of its arguments will show you what you
need to do.
I suppose the alternative is something like
data Model a = Markov {...} | OtherModel
Is that the functional solution? It seems to preclude the possibility of
separating the markov-specialized code and the other specialized code.
Right, it doesn't sound like that's the way to go here.
Regards,
YItz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
Gregory Collins wrote: Surprisingly enough, mtl uses UndecidableInstances, so almost every practical Haskell program uses it in one way or another. The library uses it, you don't use it directly in your program. Anyway, transformers does the job when you need to build on the basic monad transformers. You only need the UndecidableInstances stuff when you need to write functions that work for multiple different monad stacks and you are using type classes to define common interfaces. I find that to be a messy approach. There's almost always a better way. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
Chris Smith wrote: I had to abandon a plan to introduce Haskell in a class I taught this past semester [12 to 13 years old] because of issues with getting it installed on the Macintosh laptops that some of the students had. Truth is, you obviously don't need support for FFI development in that kind of situation. Hugs used to fill this niche. Now that Hugs isn't so well supported anymore, there is a void to be filled. On the other hand, Mark Lentczner has been doing a great job lately with the Haskell Platform installer for the Mac. So even though the full power of GHC isn't needed here, it is becoming really easy to get Haskell installed and working on a Mac in seconds. Apart from the need for XCode, which seems to be the last remaining issue. For now, at least, Malcolm's idea of an XCode 3 DVD seems to be a workaround. We'll see what happens with Lion though... Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: dtd-text DTD parser and renderer, V0.1.1.0
The dtd-text package[1] provides a parser and renderer for XML DTDs. It implements most of the parts of the W3C XML specification relating to DTDs, and is compatible with versions 1.0 and 1.1 of the specification.[2] The parser and renderer operate on Haskell DTD objects from the dtd-types[3] package. The parser is based on the attoparsec-text[4] parser library. Version 0.1.1.0 adds the first preliminary version of the renderer, based on the blaze-builder[5] package. Synopsis: -- Parse a DTD without parameter entity resolution. -- See the attoparsec-text package for information -- about how to use this parser. dtd :: Parse DTD -- Parse a DTD from a Data.Text.Lazy while resolving -- references to internal parameter entities. If you -- are not sure which interface to use, use this one. dtdParse :: L.Text - DTD -- Parse a DTD from a Data.Text.Lazy while resolving -- references to internal and external parameter entities. -- Supply the values of the external parameter references -- using a SymTable, where type SymTable = M.Map Text L.Text dtdParseWithExtern :: SymTable - L.Text - DTD -- Create a builder to render a DTD. -- See the blaze-builder package for information -- about how to use this builder. buildDTD :: DTD - Builder Enjoy, Yitz [1] http://hackage.haskell.org/package/dtd-text [2] http://www.w3.org/TR/2008/REC-xml-20081126/ [3] http://hackage.haskell.org/package/dtd-types [4] http://hackage.haskell.org/package/attoparsec-text [5] http://hackage.haskell.org/package/blaze-builder ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: dtd-text DTD parser, V0.1.0.0
I wrote: I really should have edited the Cabal description of this package before I uploaded it. Max Rabkin wrote: Could you upload a bugfix version with an accurate description? This could be very frustrating to a random hackage-brower who hasn't read the announcement (or me, in a few months, having forgotten this announcement). Well, it was up for a day anyway while I was offline. I fixed it by making the description come true - I've uploaded a new version that does have the renderer. Hope that's OK. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: dtd-text DTD parser, V0.1.0.0
The dtd-text package[1] provides a parser for XML DTDs. It implements most of the parts of the W3C XML specification relating to DTDs, and is compatible with versions 1.0 and 1.1 of the specification.[2] The result of the parse is a Haskell DTD object from the dtd-types[3] package. This first preliminary version of dtd-text, version 0.1.0.0, requires at least version 0.3.0.1 of dtd-types. Synopsis: -- Parse a DTD from a Data.Text.Lazy: dtdParse :: L.Text - DTD That should usually be all you need. -- Or, for advanced users, if the DTD contains external -- parameter entities and you want to supply their values: dtdParseWithExtern :: SymTable - L.Text - DTD -- where type SymTable = M.Map Text L.Text I really should have edited the Cabal description of this package before I uploaded it. It promises an attoparsec-text parser and blaze-builder renderer for DTDs. First of all, the renderer is vaporware - I haven't written it yet. Just the parser was quite a bit of work, so I decided to release it before even starting on the renderer. Second, although dtd-text does use attoparsec-text, and does export parsers for all of the significant components of a DTD, those parsers are of limited usefulness on their own. It turns out that in order to support the full algorithm specified in the spec for parameter entity resolution, which is rather imperative in nature, two layers of parsing are necessary. So the dtd-text package also has some internal plumbing so that it can present a simple interface. This is a very preliminary alpha release. All I can say so far is that it compiles on my machine (GHC 7.0.2 on 64 bit Linux), and that I tested it against a huge, extremely complicated DTD, and it seems to have done the RIght Thing. Since there are likely to be bugs that I will need to fix soon, I will wait until then to fix the package description. More about external parameter entities, for advanced users: As mentioned above, this parser does not attempt to go out and fetch the values of external references for you from files and URLs. If you need to extract information from the DTD before you fetch them yourself, such as system IDs and public IDs, you might be able to get them by applying parseDTD to all or part of the DTD as an initial parse. The parser tries very hard to give partial results when things are missing, while still doing its best to avoid problems like looping references. So if your DTD has many deeply intertwined external parameter entities, this parser may not be very practical for you; on the other hand, I personally have never seen such a DTD in the wild. A final caveat: this version of dtd-text does not yet support conditional sections. Enjoy, Yitz [1] http://hackage.haskell.org/package/dtd-text [2] http://www.w3.org/TR/2008/REC-xml-20081126/ [3] http://hackage.haskell.org/package/dtd-types ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: dtd-types 0.3.0.1
The dtd-types[1] package provides types for processing XML DTDs in Haskell. These types are intended to be compatible with and extend the set of types provided by John Millikin's xml-types package[2]. This version, 0.3.0.1, was released in support of the dtd-text package[3]. It includes some major changes to some of the names, as well as some bug fixes. In particular, all names relating to XML attributes which used to begin with the prefix Attr or attr have been changed to begin with att or Att instead. The EntityContent type has been renamed to EntityValue. These are much more consistent with nomenclature in the XML specs. At this point, the dtd-types package should start becoming a bit more stable, since it is now being used by other packages. Enjoy, Yitz [1] http://hackage.haskell.org/package/dtd-types/ [2] http://hackage.haskell.org/package/xml-types/ [3] http://hackage.haskell.org/package/dtd-text/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Attoparsec concatenating combinator
I wrote: I was thinking of even lower level: allocating a moderate chunk of memory and writing the results directly into it consecutively as a special case. Bryan O'Sullivan wrote: Surely that would save only one copy compared to creating a list of results and then concatenating them, no? I'd be a little surprised if it proved worthwhile. If behind the scenes the concat is copying directly from slices of the original input, then no, in principle we're not saving much then. I thought there were *two* copies going on. It might be possible to keep the byte count only in the special case of a concatenating combinator, but that would require some work to implement. Thanks as usual for the fantastic work, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
Scott Lawrence wrote: More specifically, I have class Model m a | m - a where ... class Entropy d where ... instance (Model m a) = Entropy m where ... The first line requires MultiParamTypeClasses and FunctionalDependencies... the third requires UndecidableInstances... Is this likely to cause a problem? Yes. You almost never want to use UndecidableInstances when writing practical programs in Haskell. When GHC tells you that you need them, it almost always means that your types are poorly designed, usually due to influence from previous experience with OOP. Your best bet is to step back and think again about the problem you are trying to solve. What is the best way to formulate the problem functionally? That will lead you in the right direction. Please feel free to share more details about what you are trying to do. We would be happy to help you work out some good directions. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Attoparsec concatenating combinator
Bryan O'Sullivan wrote: I'd like a no-copy combinator for the same reasons, but I think it's impossible to do without some low-level support. I wrote: ...does the internal representation easily admit such a combinator? Not very easily. Internally, attoparsec maintains just three pieces of data for its state... If there was a bytes consumed counter, it would be possible to write a try-like combinator I was thinking of even lower level: allocating a moderate chunk of memory and writing the results directly into it consecutively as a special case. I think Data.ByteString.Internal.create might do the trick. In fact, some of the existing basic attoparsec combinators, like takeWhile, could use that kind of treatment. The question is whether you want to dip that low into the ByteString implementation. Part of the problem is that there doesn't seem to be any way to allocate contiguous memory in GHC and then release only part of it. So even ByteString itself is doing extra copying. That is another reason why I think there may be some serious performance gains to be had by exposing those internals in attoparsec. [Duncan: Did you notice that the Haddocks for Data.ByteString.Internals and a few others haven't been building lately?] Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Attoparsec concatenating combinator
Mario Blažević wrote: I don't know if this helps, but the incremental-parser library has exactly the combinator you're looking for. Wow, that is a beautiful implementation of a general parser library. So much simpler than Parsec. Thanks for pointing it out. Why are you hiding those nice Monoid classes in the parser package? Shouldn't it be a separate package? Edward Kmett has also been adding some nice Monoid abstractions lately. I haven't been following all of it. I wonder how yours and his relate. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] License of hslogger, HDBC, etc.
John Goerzen wrote: I've decided that I'm OK with re-licensing hslogger, HDBC, and well all of my Haskell libraries (not end programs) under 3-clause BSD. Thanks John! -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Attoparsec concatenating combinator
I often find while using attoparsec and attoparsec-text that I need to match a number of text parsers consecutively and concatenate the result. By text parser I mean Parser ByteString for attoparsec and Parser Text for attoparsec-text. It seems the best I can do is to collect them all in a list and then apply concat. But that still copies the text several times. Is there a combinator that does this without all that copying? If not, does the internal representation easily admit such a combinator? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: dtd-types 0.2.0.0
The dtd-types package provides types for processing XML DTDs in Haskell. These types are intended to be compatible with and extend the set of types provided by John Millikin's xml-types package. The consensus seems to be to leave this as a separate package and not to merge it with xml-types. This version fixes a number of issues with the preliminary version. Among those issues were: omission of processing instructions, pointed out by John Millikin, and Haddock problems pointed out by Michael Snoyman. Thanks! Hackage: http://hackage.haskell.org/package/dtd-types/ Darcs: http://code.haskell.org/dtd/dtd-types Enjoy, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Please add a method for optimized concat to the Semigroup class
Edward Kmett wrote: I felt I should probably mention that ultimately what was done is I moved NonEmpty all the way down into semigroups and chose sconcat :: NonEmpty a - a at it was the closest analogue to the current mconcat behavior. So, request accomodated. ;) Indeed, this is an excellent solution. Thanks! -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: dtd-types 0.0.0.1
The dtd-types package provides types for processing XML DTDs in Haskell. These types are intended to be compatible with and extend the set of types provided by John Millikin's xml-types package. This is a very preliminary first version, pending discussion by the community on the web-devel list about integration with xml-types, and any other issues that might come up. Hackage: http://hackage.haskell.org/package/dtd-types/ Darcs: http://code.haskell.org/dtd/dtd-types Enjoy, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Escaping of string literals
Michael Snoyman wrote: main = do fromAddr - unsafePackAddressLen 7 $(return $ LitE $ StringPrimL 123\0\456) print fromAddr let fromStr = S.pack $ map (toEnum . fromEnum) $(return $ LitE $ StringL 123\0\456) print fromStr I get the result: 123\192\128\45 123\NUL456 Well, the haddocks for StringPrimL say: A primitive C-style string, type Addr# You obviously can't have a null byte in the middle of a C-style string. So GHC is replacing it with an invalid UTF-8 representation of a null byte, the best it can do under the circumstances. Then you just get those bytes back when you read them as a byte string. Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: time-recurrence-0.1
I wrote: It's not a good idea for a basic time library to introduce possible crashes. At least you should provide an alternative safe interface. Similarly for toEnum. Chris Heller wrote: are you suggesting something like doing modulo arithmetic rather than calling error on undefined values? Well, the standard safe interface would just wrap the return type in Maybe, like fromGregorianValid does. Then you might use it something like this: maybe [] (map moment . take 5 . recurBy 10 [] . Daily) maybeStartDate Using modulo arithmetic for toEnum would indeed make the function safe, but I'm not sure that would give the results that users are expecting. For the start date of a recurrence, though, you are right that you might be able to do better than just using Maybe. Suppose you had a function that rounds an invalid Gregorian date forward to the nearest valid date. Then a user that asks for a recurrence starting with, say, Feb. 30 would get dates starting at the beginning of March, which is probably what was intended. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: time-recurrence-0.1
Moving the discussion from haskell to haskell-cafe. Chris Heller wrote: http://github.com/hellertime/time-recurrence A library for generating and inspecting recurring times. Very nice. Please put it up on hackage so we can see the haddocks, try it out easily, etc. hoping to solicit some feedback on its design. Very well done. I have been think about recurrence rules, too. Version 2 Olson timezone files contain POSIX rules to specify clock change rules for times later than the last one listed in the timezone series. Currently, the timezone-series package ignores those. I like your introduction of symbolic months and weekdays. The numeric-only interface of Data.Time for those things leads to messiness like multiple functions depending on how you number the weekdays. That logic should be moved out to a separate interface. You are correct that it is worth creating a separate module for that. Please do so! Include neater versions of the corresponding functions from Data.Time. Another comment - I would have used fromGregorianValid instead of fromGregorian. It's not a good idea for a basic time library to introduce possible crashes. At least you should provide an alternative safe interface. Similarly for toEnum. The general direction is to have something that works much like the RRULE portion of the iCalendar (RFC 5545) specification. I have decided avoid strict RFC compliance at this time. Ashley Yakeley wrote: At one point I investigated a really generalised version of this, including an abstract syntax type and perhaps a way of parsing some useful subset of English expressions into it. However I got stuck on such things as any day after the sixth Sunday of a month In order to prove that today was not such a day, it would have know that sixth Sunday of a month never happens. Simply searching into the past for one would never terminate. Either I would have to restrict the language, or assert the beginning of time (not necessarily a bad solution). I don't see why you would need to make any such restrictions. There would only be a finite number of primitive comparison types, and since your language would be total, any expression could be reduced to the primitive ones in a finite number of steps. Then it would just be a matter of arithmetic on sets of ranges; see, for example, http://hackage.haskell.org/package/Ranged-sets That allows for half-infinite and infinite ranges as well. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to incorporate Haskell.org
Don Stewart wrote: The haskell.org committee... has decided to incorporate haskell.org as a legal entity. This email outlines our recommendation, and seeks input from the community on this decision. Thanks, good news! And thanks for posting to multiple lists for maximum public notification to the community. Can the committee now designate a single list for further discussion please? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Those damned parentheses
Eitan Goldshtrom wrote: f p = putStrLn $ (show (Main.id p)) ++ - message received Brandon S Allbery KF8NH wrote: f p = putStrLn $ (show $ Main.id p) ++ = message received wren ng thornton w...@freegeek.org wrote: f p = putStrLn $ show (Main.id p) ++ - message received f p = putStrLn $ (show . Main.id) p ++ - message received f p = putStrLn $ ((show . Main.id) p) ++ - message received f p = putStrLn $ (show . Main.id $ p) ++ - message received f p = putStrLn ((show . Main.id $ p) ++ - message received) etc. I think the clearest way to write it is: f = putStrLn . (++ - message received) . show . Main.id Not because it happens to be point-free, but because it is the combinator approach. You apply functions one after the other, each with its own simple meaning and purpose. If I were to describe to someone in words what this function does, I would say something like: Apply Main.id, turn it into a string, tack a message onto the end, and print it. So why not write it that way in Haskell? One of the nicest features of Haskell is that the combinator approach is often so natural. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Those damned parentheses
Andrew Butterfield wrote: Why not indeed ? Roel van Dijk wrote: import Control.Category ( () ) f = Main.id show (++ - message received) putStrLn Indeed, I agree. I sometimes do that, too, when I want to emphasize the idea of applying tools one after the other. But most often I just use traditional function composition notation. That reminds us of the connection with mathematical functions. It also raises less eyebrows when other people read my code and see ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Those damned parentheses
Andrew Butterfield wrote: Why not indeed ? Roel van Dijk wrote: import Control.Category ( () ) f = Main.id show (++ - message received) putStrLn Indeed, I agree. I sometimes do that, too, when I want to emphasize the idea of applying tools one after the other. But most often I just use traditional function composition notation. That reminds us of the connection with mathematical functions. It also raises less eyebrows when other people read my code - some people immediately panic when they see an import from Control.Category or Control.Arrow. :) Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Please add a method for optimized concat to the Semigroup class
Hi Edward, Thanks much for the very useful semigroups package. When using it in practice, it would be very useful to have an analogue to the mconcat method of Monoid. It has the obvious default implementation, but allows for an optimized implementation for specific instances. That turns out to be something that comes up all the time (at least for me) in real life. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Please add a method for optimized concat to the Semigroup class
Stephen Tetley wrote: Does it have an obvious default implementation, bearing in mind it we might really want a total function? sconcat [] = error Yikes - I wish this was total! sconcat [a] = a sconcat (a:as) = a sconcat as Holger Siegel wrote: You have to provide the neutral element by yourself: a [] = a a (b:bs) = a b bs Yes, I think that would be the best interface. At first glance, one would be tempted to do something like returning a Maybe, as is often done in these kinds of cases. But here, the whole point of Semigroup is that we don't know what to do when the list is empty, so getting a Nothing result in that case is unhelpful. To illustrate the point, let's look at the conversion between those two approaches: sconcatNonempty x xs = fromJust . sconcat $ x : xs sconcatMaybe (x:xs) = Just $ sconcat x xs sconcatMaybe _ = Nothing I would much rather write sconcatMaybe when needed than to have to write unsafe code like sconcatNonempty. Presumably it's actually safe, since you would expect implementations to provide a result whenever the list is non-empty. But the type no longer provides that guarantee. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Please add a method for optimized concat to the Semigroup class
Stephen Tetley wrote: There is that formulation, though usually I find I need to do it with an alternative instead: altconcat alt [] = alt altconcat _ (a:as) = go a as where go acc [] = acc go acc (b:bs) = go (acc b) bs But the whole reason we need this as a method is for the case that consecutive appends is inefficient. Both are kind of, sort of bringing you up to a Monoid though... altconcat and sconcatMaybe are doing that, because you need to decide what to do with an empty list when you define the instance. Holger's interface is not doing that, because the type does not require you to say anything about the case of an empty list in the instance. Another approach would be to depend on one of the packages that provides a non-empty list type, such as the NonEmptyList package. But I don't think this simple case justifies another dependency. You can wrap Holger's function in one of those types easily enough if you need to. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Please add instance Semigroup Text
Hi Edward, Could you please add a Semigroup instance for Text? Once you're doing that, I suppose you'd also want to add it for lazy Text and both kinds of ByteStrings. But what I currently need is strict Text. The reason, of course, is that in complex calculations is *so* much more readable than `mappend`. Obviously WrappedMonoid is useless there. Hmm, and now for Semigroup and Monoid we start down the same path as for Functor and Monad... Or should we give back to Monoid and use something different for Semigroup? That doesn't seem very nice either... Well, in the meantime, you really will make my life easier if you could add some more Semigroup instances for popular Monoids. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Please add a method for optimized concat to the Semigroup class
Edward Kmett wrote: sconcat :: [a] - a - a with either the semantics you supplied or something like sconcat = appEndo . mconcat . map diff The sconcat we have been discussing is sconcat = flip $ appEndo . getDual . mconcat . map (Dual . Endo . flip ()) (avoiding the use of Dual.diff.Dual so that we don't need to define dualUnDual or some such messiness) But it was somewhat unsatisfying, in part because of the need for a seed element. Only because, as you said, there is no standard non-empty list type. Another unsatisfying detail is no definition is in any way shape or form canonical when folding over a list. While our definition doesn't look any better than the others when expressed in terms of those combinators, it certainly seems to be the most natural when defined directly as Holger did. It's also the direct analogue of mconcat when viewed as the same type with lists replaced by non-empty lists. I'm sure that's the definition most users will expect. But I would be happy with whichever you supply. ...I'm more than happy to add it if only for symmetry with Data.Monoid, but I'd be much happier doing so with a compelling example where it actually sped things up I'm currently doing some recognition algorithms on heterogeneous collections of graphical elements on a 2D canvas. Many types of elements have a location and a rectangular extent. You can often combine them, but there is no unit element because even an empty element needs to have a specific location. It would be very slow to combine a list of them incrementally; instead, you find the minimum and maximum X and Y coordinates, and combine the content using a fast algorithm. (I originally used Monoid instances by augmenting types with locationless empty elements. But that made a mess of my code and introduced a myriad of bugs and potential crashes. These are definitely semigroups, not monoids.) I'm sure there are countless other natural examples of semigroups in the wild, and that the typical non-trivial ones will benefit from an optimized sconcat. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Please add instance Semigroup Text
I wrote: Could you please add a Semigroup instance for Text? Edward Kmett wrote: Unfortunately, I don't think I can really bring myself to do either. I was deliberately trying to keep the number of dependencies for the semigroups as low as possible... You are quite right. These should really be defined in their respective packages. I don't think it's too onerous for them to add a dependency on semigroups, even before you reverse the few lightweight dependencies that semigroups has. Bryan O'Sullivan wrote: I'd strongly recommend writing an instance for the text package's Builder type instead. Vastly more efficient for non-trivial jobs. Well, in my case, I'm iterating over many small Texts, slicing and dicing small groups of them in various ways to look for overlaps, and splicing the pieces back together in different combinations. It's quite fast as it is; what I'm looking for is to make the formulas look simpler and more understandable. I doubt that builders will be any help for that. Whereas using from semigroups instead of `T.append` or `mappend` is a huge help. Apart from my own use case, semigroups are a simple and fundamental idiom that I think will become much more widely used as people become more aware of them. Just like every Monad should have a Functor instance, every Monoid should have a Semigroup instance. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Local copy of hackageDB
José Pedro Magalhães wrote: I want to use cabal-install on a machine without internet access. Work is ongoing for a version of hackage that you can just install on your own server. Perhaps the people working on that can comment about the status. If all you want is a barebones server that you can upload packages to for use via cabal-install, you can get: http://hackage.haskell.org/package/yackage Hope this helps, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Local copy of hackageDB
José Pedro Magalhães wrote: Thanks, but I don't really need a functional server or anything; I just want to have a local copy of Hackage on disk (latest versions only will do) and tell cabal-install to use that instead of the web. If you have the package tarball, you can unpack it manually and then type cabal install (with no package name) inside that directory. Regarding yackage, I don't think I can open ports on that machine either... You don't need to open the port. With the -l flag yackage only uses the port on localhost. There are sometimes problems with that in the latest version, but that will be fixed in the next release. But anyway, it sounds like you indeed may not need a server at all. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding of Haskell source files
+1 for UTF-8 only. Brandon Moore wrote: ...I don't see much to be gained by prohibiting other encodings. Universal portability of Haskell source code with respect to its encoding is to be gained. We can achieve that simplicity now with almost no cost. Why miss the opportunity? In particular, I have read that systems set up for east asian scripts often use UTF-16 as a default encoding. Default encoding is not an issue for any normal source code editing tool. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Encoding of Haskell source files
malcolm.wallace wrote: BOM is not part of UTF8, because UTF8 is byte-oriented. But applications should be prepared to read and discard it, because some applications erroneously generate it. For maximum portability, the standard should be require compilers to accept and discard an optional BOM as the first character of a source code file. Tako Schotanus wrote: That's not what the official unicode site says in its FAQ: http://unicode.org/faq/utf_bom.html#bom4 and http://unicode.org/faq/utf_bom.html#bom5 That FAQ clearly states that BOM is part of some protocols. It carefully avoids stating whether it is part of the encoding. It is certainly not erroneous to include the BOM if it is part of the protocol for the applications being used. Applications can include whatever characters they'd like, and they can use whatever handshake mechanism they'd like to agree upon an encoding. The BOM mechanism is common on the Windows platform. It has since appeared in other places as well, but it is certainly not universally adopted. Python supports a pseudo-encoding called utf8-bom that automatically generates and discards the BOM in support of that handshake mechanism But it isn't really an encoding, it's a convenience. Part of the source of all this confusion is some documentation that appeared in the past on Microsoft's site which was unclear about the fact that the BOM handshake is a protocol adopted by Microsoft, not a part of the encoding itself. Some people claim that this was intentional, part of the extend and embrace tactic Microsoft allegedly employed in those days in an effort to expand its monopoly. The wording of the Unicode FAQ is obviously trying to tip-toe diplomatically around this issue without arousing the ire of either pro-Microsoft or anti-Microsoft developers. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can't connect to local yackage server
On Mac OS X 10.6.7, after upgrading to yackage 0.1.0.1: After running yackage -l, I cannot connect to it even directly from localhost. I get the message: This Yackage server only talks to local clients On a Linux server it seems to work fine though. On the Mac, when I do telnet localhost I get: Trying ::1... Could it be that yackage 0.1.0.1 doesn't recognize the IPv6 notion of localhost? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't connect to local yackage server
I wrote: After running yackage -l, I cannot connect to it even directly from localhost. I get the message: This Yackage server only talks to local clients Michael Snoyman wrote: ...it doesn't sound like your problem is caused by the mis-behaving Yackage code: it *should* give you a permission denied error message. Does the connection work if you just run yackage normally, i.e. without -l? Yes, as a work-around I'm running it without -l, with the firewall set to block incoming connections to the port. It's working fine that way. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Please allow variation in the Yackage page title
Could you please add a way of varying the title of the Yackage web page? That would make it much easier to work with multiple Yackages at once. For my particular setup, including its port number in the web page title would do the trick. But perhaps the easiest and most general thing would be to add a command-line option for setting the title. Using multiple Yackages is a very simple yet powerful technique to keep cabal versions straight. You can use it to group package versions in various ways - versions that you are currently hacking on, versions that have stabilized but you are not releasing yet while you work on other related packages, versions shared by various teams and subteams of developers, etc. Multiple Yackages are especially useful in combination with cabal-dev, but currently you have to fiddle a little bit to get cabal-dev to use a modified cabal config file. See: http://www.haskell.org/pipermail/haskell-cafe/2011-March/090492.html Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] timezone-series and timezone-olson
Hi Manfred, I am copying this response to the Haskell Cafe mailing list. Manfred Lotz wrote: ...I'm trying to figure out how to use your packages to get the time in a different timezone. Do you have an example how to do that? What I want for example is to provide the timezone preferably like this: US/Eastern, and get the time information like for example this: US/Eastern DST EDT 2011.03.27 05:20:52 The pieces I like to get are: Summertime indicator, TZ abbrev and the date resp. time in that timezone. If you are willing to hard-code the offset of the timezone, you don't need my packages. You only need them if you need your program to reflect accurately whether summer time is/was in effect at the given time at the given location, or if the timezone changed at some time in history. I assume that you are starting with a UTCTime object, constructed in one of the usual ways using the time package. Get the timezone information provided by the operating system. On anything other than Windows, that means reading the timezone file for that zone. On Windows the information is in the registry, but unfortunately we don't have an interface for reading it from there yet. The best I can suggest for now is to copy timezone files from a non-Unix computer. Assuming you have the timezone file that you need - let's say it is in the directory /usr/share/zoneinfo as typical for Linux and Mac - here is how to code it: do ... tzs - getTimeZoneSeriesFromOlsonFile /usr/share/zoneinfo/America/New_York let usEastern = utcToLocalTime' tzs utc Then, to format the time as you require, use the formatTime function from the time package. Hope this helps, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Saving changes to cabal config in cabal-dev
Thanks for the fantastic cabal-dev tool! Is there any convenient way to save changes to the package-specific cabal config file in cabal-dev? When I make changes to cabal-dev/cabal.config, cabal-dev seems to scribble over them next time I run it. The only solution I have found so far is to run cabal-dev install once (ignoring the errors) to create the cabal-dev directory and cabal.config, make a copy of cabal.config with a different name, edit it as needed, and then use a long-winded --config=... option for every subsequent run cabal-dev. The changes I need to make are as follows: - remote-repo-cache is wrong for Mac OS X - add more remote-repo lines for our local yackage servers. Note that the first is global, so it would be nice to have a way to make that change once globally for all packages. Whereas the second is, in general, package specific. We find local yackage servers much simpler to use and far more powerful than using add-source. You can organize packages by project, team, specific developers, etc. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IPv6 issues for (code|community).haskell.org?
Erlend Hamberg wrote: When I wanted to get the newest xmonad code from darcs today¹ it was really, really slow... Being on an IPv6 network, and having been burnt by similar problems before, I tried adding IPv4 address for code.haskell.org in /etc/hosts... This fixed the issue ...Connecting to code.haskell.org in a Web browser also takes minutes, while e.g. http://ipv6.google.com/ works perfectly. Thanks for the report. I submitted a ticket for this. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can't download haskell-mode for emacs: directory is empty
Richard Cobbe wrote: I'm trying to see if I'm running the latest version of haskell-mode.el. Unfortunately, the download link at the top of http://www.haskell.org/haskellwiki/Haskell_mode_for_Emacs points to a directory with nothing in it. Is there somewhere else I should be looking? It is still disabled after the hack attack on community.haskell.org. However, the darcs repository for the project has been re-enabled. It is at: http://code.haskell.org/haskellmode-emacs/ The link on the wiki page points to a directory that is supposed to contain tar archives of the current version and a number of previous versions of the project. The project owners need to check them over and verify that they were not compromised during the security breach. Once they do that and notify the community.haskell.org admins, that content will also be re-enabled. Hope this helps, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A practical Haskell puzzle
Brandon Moore wrote: This code produces and uses a table of all allowed combinations. I think this makes it easier to understand why the code works (and is H98). It's just as easy to make a direct version that produces one requested composition in linear time, so I haven't worried whether lazy evaluation of this table works nicely. Given that you are allowing serializing and deserializing at every step, you're right that it's not hard to do it in Haskell 98. I'm not convinced that you gain anything by building that big table though. Anyway, my idea was to try to find a solution that does not require the runtime cost of serializing and deserializing at every step just to solve a type problem. Sorry I didn't make that more clear in my statement of the problem. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A practical Haskell puzzle
Eric Mertens wrote: (but I've had my head in Agda lately) Indeed, coming across this problem tempted me to abandon the real world and take refuge in Agda. http://hpaste.org/44469/software_stack_puzzle Wow, so simple, and no higher-rank types! This is the best solution yet. I am now truly in awe of the power of GADTs. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A practical Haskell puzzle
Brandon Moore wrote: My solution does not serialize and deserialize between every pair of layers. Ahhh, I see! Sorry I didn't look closely enough the first time. Yes, this is a very nice Haskell 98 solution! This code produces and uses a table of all allowed combinations. I think this makes it easier to understand why the code works (and is H98). I'm not sure I understand why that is so. It's just as easy to make a direct version that produces one requested composition in linear time, so I haven't worried whether lazy evaluation of this table works nicely. Well, for the table solution to really qualify, that would need to work out. Otherwise, I'm not sure it's much better than just building that many boilerplate definitions in some automated way and compiling them. Could you please elaborate a bit more on what you mean by the direct version? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A practical Haskell puzzle
Thanks to everyone for the nice solutions to this puzzle, here and on reddit: http://www.reddit.com/r/haskell/comments/fu6el/a_practical_haskell_puzzle/ There were two basic approaches. One was to use GADTs and higher-rank types to reduce the amount of type trickery needed. One nice example is apfelmus' solution here in this thread, and several people on reddit suggested using use thrists package: http://hackage.haskell.org/package/thrist The other approach is to use some kind of generics. In any case, there does not appear to be any reasonable way to handle this simple and common situation in Haskell without extensions. I challenge the Haskell community to add these extensions to the Haskell standard in Haskell 2012! Lennart proposed using type-level numbers and reification, but I'm not sure about the full details of that solution. Does it use Haskell extensions, and if so, which ones? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A practical Haskell puzzle
You have written a large software system in Haskell. Wishing to play to Haskell's strength, you have structured your system as a series of composable layers. So you have data types Layer1, Layer2, ... and functions layer2 :: Layer1 - Layer2 layer3 :: Layer2 - Layer3 ... etc. Of course you'll want to be able to run any range of the layers separately, at least for testing and debugging purposes if not for the functionality itself. So your UI module (command line or whatever) that launches your application provides a data type data Layers = Layers Int Int that indicates which layers to run, and functions deserialize1 :: L.ByteString - Layer1 deserialize2 :: L.ByteString - Layer2 ... serialize1 :: Layer1 - L.ByteString serialize2 :: Layer2 - L.ByteString ... etc. Now you need a function runLayers :: Layers - L.ByteString - L.ByteString so that the effect is for example runLayers (Layers 4 6) = serialize6 . layer6 . layer5 . deserialize4 Typically there could be 20 or 30 layers, so writing out each case could result in hundred of boilerplate definitions for runLayers. Scripting the generation of all that boilerplate, e.g. using TH, doesn't seem very attractive either. On the other hand, it seems silly to have to use super-advanced type olegery for such a trivially simple yet centrally important component of the system. What is the best way to write runLayers? Feel free to change the details of the above design, as long as it meets the functionality requirements expressed. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: unordered-containers - a new, faster hashing-based containers library
Gwern Branwen wrote: You could look at them yourself; I attached the files. Max Bolingbroke wrote: Frankly I am surprised how much size gets used. It seems that making it fast is more important than I thought. Johan Tibell wrote: IntMap (which shares data structure with HashMap) only hash O(n) size. I wonder if people avoid using IntMap because of this. Another common usage for Map is as a functional integer-indexed random access array. Once I implemented the standard algorithm for random shuffle of a list using Data.Map Int. It was much nicer than the STArray version, in my opinion. But when I tried switching to Data.IntMap, hoping to make it faster, I was devastatingly disappointed. Now I understand why. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Using IsString with attoparsec
I wrote: I suggest adding the following type-specialized variants to Data.Attoparsec.Char8: (*.) :: Applicative f = f a - f ByteString - f a (*.) = (*) (.*) :: Applicative f = f ByteString - f a - f a (.*) = (*) Bryan O'Sullivan wrote: Sounds reasonable. Send a patch? Felipe Almeida Lessa wrote: Done! It will be in attoparsec-text 0.8.2.0. Fantastic.! Felipe, thanks so much for this patch, and for the IsString instance in attoparsec-text. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
