April 2013 - Haskell-Cafe

Fwd: [darcs-users] Google Summer of Code
by Guillaume Hoffmann 30 Apr '13

30 Apr '13

---------- Forwarded message ---------- From: Ganesh Sittampalam <ganesh(a)earth.li> Date: 2013/4/25 Subject: [darcs-users] Google Summer of Code To: darcs-users <darcs-users(a)darcs.net> Hi, darcs.net will participating in Google Summer of Code this year, under the umbrella of haskell.org - Google will be allocating 1 or 2 extra slots specifically for Darcs. Time is a little short, as we'd originally thought this arrangement was coming to an end: the student application deadline is 1900UTC on next Friday (May 3rd). Please see http://darcs.net/GSoC for ideas and what to do next if you are interested in participating. The most important thing is to get in touch with us informally asap. Many thanks to Guillaume Hoffmann both for making our initial application to be a separate organisation (which was unfortunately rejected), and then for talking to Google and establishing that our existing arrangement of having a dedicated slot under the haskell.org umbrella could continue. Cheers, Ganesh _______________________________________________ darcs-users mailing list darcs-users(a)darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users

1 0

Re: [Haskell-cafe] GSoC Push Notifications project - communicating with mobile devices
by Kristopher Micinski 29 Apr '13

29 Apr '13

On Mon, Apr 29, 2013 at 4:46 PM, Marcos Pividori <marcospividori(a)gmail.com> wrote: > Hi, thanks for your response! this really help me. > > * About the code in Spanish: I will replace it for an English version in the > next weeks. As Michael said, I had to write it in Spanish because it was a > project for my university. Sorry, I know it is not clear now. > No worries, I don't think this makes it bad, just harder to read for English speakers > * Kristopher, thanks for your comments and availability. Yes, I am looking > to provide a Haskell API to interface with these different push notification > services. I know that maybe it isn't enough to fill up a summer, so I will > get into account this ideas you gave me. I am thinking about some useful > tools I could provide to people programming for mobile devices. I would also be interested in hearing about what you come up with. I have a lot of experience with mobile hacking, and I'd be glad to help you validate ideas as they come to you, or point you at related material. >>"I would suggest also adding to your schedule writing up a >> Yesod app which has "back and forth" communication with a device, >> seeing what common problems pop up, and then writing an API for >> handling *that* as well. (That may broaden the scope of your project >> enough.)" > > I created this "back and forth" communication for the project I mentioned > before. But, a lot of things could be improved. For example, about > mantaining a state of the connection and being able to manage with a lot of > devices at the same time. (As I implemented this, I think it wont work > really well with a lot of devices). And I could develop a demo app for each > OS (Android, iOS, Windows Phone, etc) to manage this communication. > I 'll continue investigating, every contribution is welcome! The key aspects are to use Haskell to write as little as boilerplate code as possible. Then identify the common elements of the API for each and write a common API. That strikes me as the simple part. I'm not sure if it's sensible or not, but maybe it would be possible to formalize this "back and forth" computation using something similar to session types. Maybe next steps would be to automatically take the types in the program and generate a contract for the JSON sent between the device and server, which might give you some fun experience in type level programming. This is very hand wavy, so I'm not sure if that's realistic or not... Kris

1 0

GSoC proposal: Haskell AST-based refactoring and API upgrading tool
by Niklas Hambüchen 29 Apr '13

29 Apr '13

I would like to propose the development of source code refactoring tool that operates on Haskell source code ASTs and lets you formulate rewrite rules written in Haskell. Objective --------- The goal is to make refactorings easier and allow global code changes that might be incredibly tedious to do in a non-automated way. By making these transformations convenient, we can make it easier to maintain clean code, add new features or clean up leftovers faster, and reduce the fear and effort to upgrade to newer versions of packages and APIs. Transformations --------------- First, here are a few operations you would use this tool for. Some of them are common operations you would also do in other programming languages, some are more specific to Haskell. * Changing all occurrences of "import Prelude hiding (catch)" to "import qualified Control.Exception as E" * Replacing all uses of a function with that function being imported qualified or the other way around * Adding a field to data constructor a record, setting user-supplied defaults for construction and destruction: -- Suppose you want to change one of these data User = User { name :: String, age :: Int } data User = User String Int -- into one of these data User = User { name :: String, age :: Int, active :: Bool } data User = User String Int Bool -- the refactoring tool could perform, in all relevant locations: show (User name age) = ... show (User name age _) = ... -- and also this transformation: ... u { name = "deleted" } ... ... u { name = "deleted", active = False } ... -- or equivalently with records. -- Special cases could be taken care of as specified, such as -- "whenever an object of [this User type] has -- of its records passed into some function 'email', do this -- now only if the user is active, so modify all relevant code -- email (name u) -- to -- if (active u) then email (name u) else return () -- Other examples include adding a position counter to attoparsec. * Adding a type parameter to a type -- This happens a lot on monad transformer stacks, e.g. newtype MyMonad a b c = MyMonad (ReaderT a (WriterT b ... -- and as you would probably agree on, this is not the most -- comfortable change to make; in big project this can mean -- hour-long grinding. -- It has also recently happened in the basic underlying types -- of packages like conduit and pipes. * Adding a new transformer around a monad * Addressing problems like mentioned in http://blog.ezyang.com/2012/01/modelling-io/: "There is one last problem with this approach: once the primitives have been selected, huge swaths of the standard library have to be redefined by “copy pasting” their definitions ..." * Extracting a value into a let or where clause * Renaming a variable, and all its occurrences that are semantically same variable (based on its scope) * Changing the way things are done, such as: * Replacing uses of fmap with <$>, also taking care of the corresponding import, and such cases were partial application is involved * Replacing uses of "when (isJust)" to "forM_" * Making imports clearer by adding all functions used to the file to the import list of the module that gets them in scope * Finding all places where an exported function does not have all its arguments haddock-documented. * Performing whole-project refactorings instead of operating on single files only, allowing operations like "Find me all functions of this type, e.g. Maybe a -> (a -> m a) -> m a in the project and extract them into this new module, with the name 'onJust'." Some of the problems above can be tried to address using regex-based search and replace, but this already fails in the simplest case of "import Prelude hiding (catch)" in case there is more than that imported from Prelude or newlines involved in the import list. Transformation on the AST are much more powerful, and can guarantee that the result is, at least syntactically, valid. No text base tool can do that. Other uses ---------- In addition to being able to perform transformations as mentioned above, the refactoring tool as a library can be leveraged to: * Support or be the base of code formatting tools such as haskell-stylish, linters, style/convention checkers, static analyzers, test coverage tools etc. * Implement automatic API upgrades. Imagine the author of a library you use deprecates some functions, introduces replacements, adds type parameters. In these cases, it is very clear and often well-documented which code has to be replaced by what. The library author could, along with the new release, publish "upgrade transformations" that you can apply to your code base to save most of the manual work. These upgrade transformations could be either parts of the packages themselves or be separately maintained and refined on the feedback of users applying them to their code bases. This could allow the Haskell community to keep up their fast pace while making API breakage a non-problem. Automation is what makes us deal well with test suites, source control, error checking. Taking the pain out of this will increase people's incentive to upgrade their code an to keep it well-maintained by easy refactorings. This concept of automatic code upgrades would, to my knowledge, be quite unique in the programming language world, and the possibility to have this is, as many things, the result of Haskell's excellent type system. In comparison to dynamic and "unsafe" languages, we actually have a lot of information around that we can use to write powerful and expressive tools. Splitting into GSoC tasks ------------------------- I think that the project is too large for one summer and should be split into two parts: 1. Implementation of a "full-source" transformation-enabling AST 2. The transformation engine and API / DSL About 1: Creating a full-source AST Existing parsers for Haskell tend to throw away information that is not necessary for compiling the code. Of course this is not good for a code-to-code transformation tool, stripping comments or whitespace the programmer cares about is not an option. haskell-src-exts has gained support for comments around version 1.1 (as another GSoC project?), but still comments are treated as foreigners, given to you in a list detached from the AST; their positions are specified with integers, which means that when you modify the AST, you have to take care to adjust the comments as well. The problem seems to be that haskell-source-exts is made for parsing, its AST is made for transformations. I have yet to see a tool that actually *modifies* haskell-src-exts's AST - most of them use it for parsing, and then apply some form of pretty-printing to get back to code. We need an AST that contains *all* information about the original source code, which means render . parse = id; this is why I called it "full source" AST. Also, this AST should have all elements available in a way that encourages modification and does not discriminate against operations like re-indentation or alignment. I like to think of this as something that could eventually be part of ghc, in a pipeline like GHC's parser -> full-source AST -> reduced AST that strips parts irrelevant for compilation -> usual compilation pipeline I am thinking of this being in a GHC environment because it would guarantee that it is up-to-date with the currently supported language extensions etc. However, I also see that this might slow down development and make things harder, so at least for the beginning it might be better to do it as as a normal library; I would love to get feedback on this. It might be a good idea to start with GHC's or haskell-source-exts parser and modify them to obtain the full-source AST. I believe though that it would be beneficial if the AST would be to a certain extent be decoupled from the parser, such that other people could write other parsers (e.g. using other parsing libraries like Parsec, attoparsec, uu-parsinglib, trifecta) that produce the same compatible AST type. I believe that creating this AST makes a GSoC project for itself, and that it would be beneficial for all efforts processing Haskell as a source language. About 2: Transformation engine and how to write transformations Transformations should be Haskell code that operates on the AST. They would be similar to how you write TemplateHaskell in a way, yet much easier and more intuitive to use in most cases. I suggest the creation of a monadic DSL that allows you to select and match those parts of the code you are interested in, perform some case analysis and computation to determine how you want to transform it, and then give you convenient ways to express your changes in that DSL. Functions in this DSL would roughly belong to one of the kinds * finding/matching * transforming/rewriting. I have not thought about how this DSL would exactly look like, but I could imagine myself writing a high-level transformation like this: is <- getImports let matching = filter (importsFunction "catch") . filter (hasModuleName "Prelude") mapM_ (rewrite . removeImportFunction "catch") matching One of the priority goals of this GSoC project is making this API convenient; transformations should read more naturally and be much shorter than equivalent TemplateHaskell. This extensive, convenience oriented monadic DSL should aim to have a reasonably large set of functions, and "do things for you" even if you could build them yourself with three or four combinators. It should base itself on a minimal set of core transformations. I think that the Haskell community has a lot of expertise, especially from parsing libraries, in creating this core API + convenience combinators duo, that could aid the GSoC student to get this right. Along with this way to specify transformations, a transformation engine has to be constructed which can perform them somewhat efficiently over large code-bases. While speed should should not be a main target for this project and functionality and expressiveness are the main goals, the transformation engine should be designed at least with speed in mind, which can be worked on at a later stage outside of the GSoC project. This second part of the proposal should result in a library to perform transformations and an executable that can apply them to a folder of source files. Possible extensions and follow-up projects ------------------------------------------ * Interactive refactoring tool The refactoring tool could be driven by an interactive application that lets you write some transformations, apply them to your code base, view the diffs and build the project; on build failures or otherwise not-complete transformations it would allow to refine your transformations, or write custom special cases for selected files, line ranges or functions. This way you could quickly upgrade your code base in a fast write-check-repeat cycle. * An API upgrade infrastructure As mentioned above, transformations could be published along with new software packages that allow their dependants to easily upgrade their code to the latest API version with minimal manual effort. An infrastructure or standard way of way of doing this could be established. For now, I think that package maintainers would publish their upgrade transformations in their projects' or separate code repositories, and users would apply them with the refactoring tool as needed. I can also imagine a more dedicated infrastructure though, where API upgrades are stored on Hackage or a similar database. Summary ------- This proposal contains two GSoC projects that I believe to be reasonably sized for one summer each. I think that they make good projects according to GSoC standards as they are focused, feasible, and aimed at creating real-world code that bring a clearly visible benefit. The entry barrier is not too high since knowledge of compiler or runtime internals is not required. However, applicants should probably have a fairly good understanding of parsers and how they are dealt with in Haskell, and be somewhat familiar with the Haskell community in order to find sources of good feedback and for being able to judge whether the tools being created would be convenient for the community to use. Discussion ---------- Now I would be glad to get some responses on this proposal; I have written a bit of text, but it is still a very rough idea and I would love to hear your thoughts about it.

6 6

Fwd: Google Summer of Code, news
by Marcos Pividori 29 Apr '13

29 Apr '13

Greetings, I am a Computer Science student from Argentina. I am interested in working this summer in a project related to Haskell for the Google Summer of Code. I have been discussing my idea with Michael Snoyman in order to have a clearer idea. Now, I would like to know the community interest in this project. I want to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. To pass a subject, I have recently worked with Yesod (a Web Framework based in Haskell) developing a server to comunicate with Android-powered devices through Google Cloud Messaging. (It is available: https://github.com/MarcosPividori/Yesod-server-for-GCM ) To develop this project, I have read a lot about this service and Yesod libraries, and I developed two programs, a server written in Haskell and an Android application for mobile phones. Also, I developed an EDSL to write programs which exchange information with the devices. I would be grateful if you could give me your opinion about this project and the proposal I am starting to write. *Proposal GSoC 2013:* *Abstract* The aim of this project is to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. The fact is that every company is developing Push Notification services, and these are very similar. Then, I want to find the fundamental concepts to construct a library which enable to configure the options for the different services and send messages easily. When I say they are very similar, I refer to the fact that they all are asynchronous, best-effort services that offers third-party developers a channel to send data to apps from a cloud service in a power-efficient manner. The most popular are: - Google Cloud Messaging (Android) - Apple Push Notification Service (iPhone / iPad) - Microsoft Push Notification Service (Windows Phone) - BlackBerry Push Service (BlackBerry) - Windows Push Notification Services (Windows 8) - etc. *Motivation and expected benefits* I think my idea would be very useful because it will allow all Haskell developers to open to a new world of mobile devices and to build useful programs/services that interact with them. Pushing data to smartphones provides users with instant access to desired updates as they happen, such as news and weather, sports scores, stock prices and other time-sensitive content. The push services provide an efficient way to quickly push timely information updates to many smartphones at once, in a centrally managed and controlled manner. Generally, you can also be very selective in who you send information to, including individual customers or many customers (multicast). This services minimizes the impact on the smartphones battery life. Instead of actively checking for new data, the applications can remain closed. Once the data is delivered, the application can be launched in the background to process it as needed. This processes offer an alternative to other less efficient methods, such as polling, where a device regularly polls an application server to see if new content is available. The main differences between the services, refer to details as: the maxim payload length, the quality of service, queueing the messages or not, and the time limit for this, the way the messages are handled in the devices, etc. As all the libraries to access to these services are developed in Java, I thought that it would be a good idea to offer an option to Haskell programmers. Taking advantage of the similarity of these services, I could develop a very adaptable library which fits the necessities for each one and at the same time offer an abstraction to the user. *Deliverables.* * An API library to build and send messages including: - GCM and a demo Android app. - APN and a demo iOS app. - Microsoft Push Notification Service (Windows Phone) and a demo app. - Documentation for all the code developed. Including the explantation on how to use the server library and how to try the demo apps. * A demo server taking advantage of this libraries to communicate with the demo apps through push notifications. * Optionally: (Only in the case that I finalize the rest of the objectives before the deadline) - API for communication through BlackBerry Push Service (BlackBerry). - API for communication through Windows Push Notification Services (Windows 8). *Technical Considerations* I have to complete this.... *Timeline* May 27: (Accepted students announced) - 'Community Bonding Period' (~1 month) + Get to know mentor(s). + Refine this proposal with mentor(s). + Set up svn accounts. + Set up a wiki page or blog for this project. + Make sure that everything is ready for coding. + Try to involve the community as much as possible, ask for new ideas/suggestions/etc. June 17: (Start of the program) - 'Library to use the GCM Service' (Total: ~4 weeks) + Familiarize with the GCM service and understand the details related. (~1 week) + Develope the server library to send GCM messages and a demo Android app. (~2 weeks) + Document all the code developed, and check details. (~1 week) - 'Library to use the APNS Service' Part 1 (Total: ~2 weeks) + Familiarize with the APNS service and understand the details related. (~1 week) + Start to develope the server library to send APNS Push Notifications and a demo iOS app. (~1 week) July 29: (Midterm evaluation period begins) - 'Midterm evaluation period' (~1 week) + Submit the midterm review. August 2: (Midterm evaluation deadline) - 'Library to use the APNS Service' Part 2 (Total: ~2 weeks) + Continue to develope the server library to send APNS Push Notifications and a demo iOS app. (~1 week) + Document all the code developed, and check details. (~1 week) - 'Library to use the MPNS Service' (Total: ~4 weeks) + Familiarize with the MPNS service and understand the details related. (~1 week) + Develope the server library to send MPNS Push Notifications and a demo Windows Phone app. (~2 weeks) + Document all the code developed, and check details. (~1 week) September 16: (Suggested pencils down date) - 'Pencils down' (~1 week) + Final code clean up. + Present library to the community and analyze feedback. September 23: (Firm pencils down date) - 'Summing up' (~1 week) + Submit Final Code to Google. + Present final evaluation. + Analyze possible future work and document it. September 23: (Final evaluation deadline) *About myself and my interest in this project* -------

4 3

GSoC Push Notifications project - communicating with mobile devices
by Marcos Pividori 29 Apr '13

29 Apr '13

Sorry, I am resending this email because I didn't write a correct title before. ------- Greetings, I am a Computer Science student from Argentina. I am interested in working this summer in a project related to Haskell for the Google Summer of Code. I have been discussing my idea with Michael Snoyman in order to have a clearer idea. Now, I would like to know the community interest in this project. I want to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. To pass a subject, I have recently worked with Yesod (a Web Framework based in Haskell) developing a server to comunicate with Android-powered devices through Google Cloud Messaging. (It is available: https://github.com/MarcosPividori/Yesod-server-for-GCM ) To develop this project, I have read a lot about this service and Yesod libraries, and I developed two programs, a server written in Haskell and an Android application for mobile phones. Also, I developed an EDSL to write programs which exchange information with the devices. I would be grateful if you could give me your opinion about this project and the proposal I am starting to write. *Proposal GSoC 2013:* *Abstract* The aim of this project is to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. The fact is that every company is developing Push Notification services, and these are very similar. Then, I want to find the fundamental concepts to construct a library which enable to configure the options for the different services and send messages easily. When I say they are very similar, I refer to the fact that they all are asynchronous, best-effort services that offers third-party developers a channel to send data to apps from a cloud service in a power-efficient manner. The most popular are: - Google Cloud Messaging (Android) - Apple Push Notification Service (iPhone / iPad) - Microsoft Push Notification Service (Windows Phone) - BlackBerry Push Service (BlackBerry) - Windows Push Notification Services (Windows 8) - etc. *Motivation and expected benefits* I think my idea would be very useful because it will allow all Haskell developers to open to a new world of mobile devices and to build useful programs/services that interact with them. Pushing data to smartphones provides users with instant access to desired updates as they happen, such as news and weather, sports scores, stock prices and other time-sensitive content. The push services provide an efficient way to quickly push timely information updates to many smartphones at once, in a centrally managed and controlled manner. Generally, you can also be very selective in who you send information to, including individual customers or many customers (multicast). This services minimizes the impact on the smartphones battery life. Instead of actively checking for new data, the applications can remain closed. Once the data is delivered, the application can be launched in the background to process it as needed. This processes offer an alternative to other less efficient methods, such as polling, where a device regularly polls an application server to see if new content is available. The main differences between the services, refer to details as: the maxim payload length, the quality of service, queueing the messages or not, and the time limit for this, the way the messages are handled in the devices, etc. As all the libraries to access to these services are developed in Java, I thought that it would be a good idea to offer an option to Haskell programmers. Taking advantage of the similarity of these services, I could develop a very adaptable library which fits the necessities for each one and at the same time offer an abstraction to the user. *Deliverables.* * An API library to build and send messages including: - GCM and a demo Android app. - APN and a demo iOS app. - Microsoft Push Notification Service (Windows Phone) and a demo app. - Documentation for all the code developed. Including the explantation on how to use the server library and how to try the demo apps. * A demo server taking advantage of this libraries to communicate with the demo apps through push notifications. * Optionally: (Only in the case that I finalize the rest of the objectives before the deadline) - API for communication through BlackBerry Push Service (BlackBerry). - API for communication through Windows Push Notification Services (Windows 8). *Technical Considerations* I have to complete this.... *Timeline* May 27: (Accepted students announced) - 'Community Bonding Period' (~1 month) + Get to know mentor(s). + Refine this proposal with mentor(s). + Set up svn accounts. + Set up a wiki page or blog for this project. + Make sure that everything is ready for coding. + Try to involve the community as much as possible, ask for new ideas/suggestions/etc. June 17: (Start of the program) - 'Library to use the GCM Service' (Total: ~4 weeks) + Familiarize with the GCM service and understand the details related. (~1 week) + Develope the server library to send GCM messages and a demo Android app. (~2 weeks) + Document all the code developed, and check details. (~1 week) - 'Library to use the APNS Service' Part 1 (Total: ~2 weeks) + Familiarize with the APNS service and understand the details related. (~1 week) + Start to develope the server library to send APNS Push Notifications and a demo iOS app. (~1 week) July 29: (Midterm evaluation period begins) - 'Midterm evaluation period' (~1 week) + Submit the midterm review. August 2: (Midterm evaluation deadline) - 'Library to use the APNS Service' Part 2 (Total: ~2 weeks) + Continue to develope the server library to send APNS Push Notifications and a demo iOS app. (~1 week) + Document all the code developed, and check details. (~1 week) - 'Library to use the MPNS Service' (Total: ~4 weeks) + Familiarize with the MPNS service and understand the details related. (~1 week) + Develope the server library to send MPNS Push Notifications and a demo Windows Phone app. (~2 weeks) + Document all the code developed, and check details. (~1 week) September 16: (Suggested pencils down date) - 'Pencils down' (~1 week) + Final code clean up. + Present library to the community and analyze feedback. September 23: (Firm pencils down date) - 'Summing up' (~1 week) + Submit Final Code to Google. + Present final evaluation. + Analyze possible future work and document it. September 23: (Final evaluation deadline) *About myself and my interest in this project* -------

2 2

Looking for portable Haskell or Haskell like language
by Christopher Howard 29 Apr '13

29 Apr '13

Hi. I've got this work situation where I've got to do all my work on /ancient/ RHEL5 systems, with funky software configurations, and no root privileges. I wanted to install GHC in my local account, but the gnu libc version is so old (2.5!) that I can't even get the binary packages to install. I've had success installing some other simple functional languages (like CLISP) on these same systems, so I was wondering if there was perhaps another language very similar to Haskell (but presumably simpler) with a super portable compiler easily built from source, which I could try. I'll admit -- I haven't tried the HUGS compiler for Haskell. The quick description didn't make it sound much more portable than GHC, but I guess I could try it if I heard some good reasons to think it would be more portable. -- frigidcode.com

13 13

Space leak in hexpat-0.20.3/List-0.5.1
by wren ng thornton 28 Apr '13

28 Apr '13

Hello all, So I'm processing a large XML file which is a database of about 170k entries, each of which is a reasonable enough size on its own, and I only need streaming access to the database (basically printing out summary data for each entry). Excellent, sounds like a job for SAX. However, after whipping up a simplified version of the program using hexpat, there's a space leak. Near as I can tell, it's not a problem with my code, it's a problem with Data.List.Class (or hexpat's use thereof). The simplified code follows, just compile it for profiling and use hp2ps to see what I mean. The file I'm running it on can be found at: ftp://ftp.monash.edu.au/pub/nihongo/JMdict.gz Any ideas on what the problem really is, or how to fix it? ---------------------------------------------------------------- ---------------------------------------------------------------- module JMdict (main) where import Text.XML.Expat.SAX (SAXEvent(..)) import qualified Text.XML.Expat.SAX as SAX import Text.XML.Expat.Tree (NodeG(..)) import qualified Text.XML.Expat.Tree as DOM import qualified Text.XML.Expat.Proc as Proc import qualified Text.XML.Expat.Internal.NodeClass as Node import qualified Data.ByteString.Lazy as BL import Data.Char (isSpace) import Data.Text.IO as TIO import qualified Data.Text as T import Control.Applicative ((<$>)) import Control.Monad (forM_) import qualified System.IO as IO import qualified System.Environment as Sys (getArgs) import qualified System.Exit as Sys (exitFailure) import qualified System.Directory as Sys (doesFileExist, getPermissions, readable) ---------------------------------------------------------------- -- | A variant of 'Control.Monad.unless' for when the boolean is -- also monadic. unlessM :: Monad m => m Bool -> m () -> m () unlessM mb handle = do b <- mb if b then return () else handle -- | If the file does not exist or is not readable, then crash the -- program. assertFileExistsReadable :: FilePath -> IO () assertFileExistsReadable file = do unlessM (Sys.doesFileExist file) $ do IO.hPutStrLn IO.stderr $ "No such file: "++file Sys.exitFailure unlessM (Sys.readable <$> Sys.getPermissions file) $ do IO.hPutStrLn IO.stderr $ "File not readable: "++file Sys.exitFailure main :: IO () main = do files <- Sys.getArgs forM_ files $ \file -> do assertFileExistsReadable file countElements 0 . filter (not . isWhitespace) . dropPreamble . SAX.parse SAX.defaultParseOptions =<< BL.readFile file where dropPreamble (StartElement t _ : xs) | t == T.pack "JMdict" = xs dropPreamble (_:xs) = dropPreamble xs dropPreamble [] = [] isWhitespace (CharacterData c) | T.all isSpace c = True isWhitespace _ = False countElements :: Int -> [SAXEvent T.Text T.Text] -> IO () countElements n [] = print n countElements n xs = case anyElement xs of (Left err, xs') -> fail $ show err ++": "++ show (take 3 xs') (Right ell, xs') -> do print (n+1) (countElements $! n+1) xs' ---------------------------------------------------------------- data ElementError = EmptyStream | NoStartElement | EndOfStream | InvalidXML deriving (Read, Show, Eq) -- | Split an event stream into an initial element and the remainder -- of the stream. Use 'DOM.saxToTree' to convert the element to a -- tree. anyElement :: (Eq tag) => [SAXEvent tag text] -> (Either ElementError [SAXEvent tag text], [SAXEvent tag text]) anyElement = start where start [] = (Left EmptyStream, []) start xxs@(x:xs) = case x of StartElement t _ -> loop [t] (x:) xs _ -> (Left NoStartElement, xxs) loop _ _ [] = (Left EndOfStream, []) loop [] k xs = (Right (k []), xs) loop tts@(t:ts) k xxs@(x:xs) = step (k . (x:)) xs where step = case x of StartElement t' _ -> loop (t':tts) EndElement t' | t' == t -> loop ts | otherwise -> \_ _ -> (Left InvalidXML, xxs) _ -> loop tts ---------------------------------------------------------------- ----------------------------------------------------------- fin. -- Live well, ~wren

1 0

Why were datatype contexts removed instead of "fixing them"?
by harry 28 Apr '13

28 Apr '13

If I understand correctly, the problem with datatype contexts is that if we have e.g. data Eq a => Foo a = Foo a the constraint Eq a is thrown away after a Foo is constructed, and any method using Foos must repeat Eq a in its type signature. Why were these contexts removed from the language, instead of "fixing" them? PS This is following up on a discussion on haskell-beginners, "How to avoid repeating a type restriction from a data constructor". I'm interested in knowing whether there's a good reason not to allow this, or if it's just a consequence of the way type classes are implemented by compilers.

10 17

Display an inferred type during compilation
by Corentin Dupont 28 Apr '13

28 Apr '13

Hi Cafe, can I ask the compiler to display the type of an inferred value during compile time? It would be great if I can output a string during compilation with the type. A little bit like running :type in GHCi, but without GHCi... Because running GHCi is sometime painful (I have to clean my code first). I'm thinking of something like: main :: IO () main = do a <- someCode displayTypeAtCompileTime a return () $ ghc -c test.hs test.hs:4:3: your type is: Foo Thanks, Corentin

3 3

Diving into the records swamp (possible GSoC project)
by Adam Gundry 28 Apr '13

28 Apr '13

Hi, I am hoping to do a GSoC project this year working on GHC, and have been pointed in the direction of the records issue (in particular, the desire to overload field names). This has been discussed on-and-off for years, and while there are lots of ideas [1], little has been implemented in GHC itself. The plan would be to implement a solution to the "narrow issue" of overloaded field names, along the lines of Simon PJ's SORF proposal (on the wiki). This would provide a basis for experimentation with first-class record types. While there are still design issues to resolve, the broad plan is clear and I'm confident it can be implemented in a summer and without overly restricting future record system designs. Does this sound like a reasonable strategy? I'd appreciate comments and criticism, although arguing about the details of the design should perhaps wait. (A little about me: I'm a PhD student working on type inference for Haskell and dependent types, with about four years' Haskell experience including work on big type-system related projects. I am familiar with the theory behind GHC, but I haven't worked on the code before.) Thanks, Adam Gundry [1] http://hackage.haskell.org/trac/ghc/wiki/Records

6 11