Re: [Haskell-cafe] partially applied data constructor and corresponding type
What you probably want are type level integers (naturals) Yury Sulsky used them in the message above - basically you can't use literal numbers 1,2,3,... etc as they are values of type Int (or Integer, etc...) instead you have to use type level numbers: data One data Two Work is ongoing for type level numbers in GHC and there are user libraries on Hackage so there is a lot of work to crib from. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HList with DataKinds [Was: Diving into the records swamp (possible GSoC project)]
Aleksandar Dimitrov wrote: I've been kicking around the idea of re-implementing HList on the basis of the new DataKinds [1] extension. The current HList already uses DataKinds (and GADTs), to the extent possible with GHC 7.4 (GHC 7.6 supports the kind polymorphism better, but it had a critical for me bug, fixed since then.) See, for example http://code.haskell.org/HList/Data/HList/HListPrelude.hs (especially the top of the file). or, better http://code.haskell.org/HList/Data/HList/HList.hs HList now supports both type-level folds and unfolds. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were datatype contexts removed instead of fixing them?
Dan Doel dan.doel at gmail.com writes: However, another thing to consider is that getting rid of data type contexts was accepted into the language standard. ... which means that implementers should be free to fix data type contexts however they like, as they are now complier extensions which won't conflict with standard Haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] text-icu on Windows
On Sat, 27 Apr 2013 22:56:32 +0200, John MacFarlane j...@berkeley.edu wrote: Hello café: I'd very much like to get text-icu working on Windows, as then I could ship pandoc binaries that do proper unicode collation in bibliographies. But I'm having a devil of a time. This may be due to my very limited Windows knowledge. Any help would be appreciated, especially from someone who actually has text-icu working on Windows. I was able to cabal install text-icu without errors. I used --extra-lib-dirs and --extra-include-dirs to point to the lib and include directories in the 32-bit binary distribution of icu4c. You don't need to change the .cabal file, if you specify the paths to the libraries and header files in environment variables, see: http://www.haskell.org/haskellwiki/Windows#Tools_for_compilation If there are DLLs missing, you can find out which, using cygcheck from the Cygwin project. Note, that you will get problems if you have both MinGW and Cygwin in your search path; it is best to specify the full path to cygcheck.exe, or copy cygcheck.exe to some location in the search path. Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HList records access time [was: Diving into the records swamp]
Aleksandar Dimitrov aleks.dimitrov at gmail.com writes:
Hi Aleksandar, I was hoping that Oleg himself would answer the second part
of your post, as he did the part re DataKinds:
Here's one thing I don't like about the current way HList-based
extensible record are represented (and used in OOHaskell [2]):
the access time is linear in
the number of records a certain type has.
Somehow just the thought of reorder the records in your
constructors to make your program go faster makes me cringe
a little.
Yes, it would me!
I thought that usually the instance matching for HList happens at compile
time(?) So reordering might make compiles faster, but that should be dealt
with before run-time(?)
I guess it matters whether the 'shape' of the HLists is knowable at
compile time, or the records are built 'on the fly' at run time.
Here's a possibly relevant idea that I would try for myself if only my day
job didn't get in the way of my life so much ;-(.
Instead of Type-Indexed Products (TIP's as the HList paper calls them),
how about Type-Indexed tuples (TIple's) like this:
instance Has (a, b)a where { get (x, _) = x; ... }
instance Has (a, b)b ...
instance Has (a, b, c) a ...
...
instance Has (a, b, c, d) a ...
...
(Note that the result type is not an argument to `get'; instead the type
is 'pulled' out by the demanding context.)
Then access to any element is 'flat' rather than having to walk down the
spine of an HList. (Again this needs being able to resolve instances at
compile time.)
The instances for any n-tuple overlap, and the result of get/set is not
confluent. This only matters if the same type appears twice in a tuple.
(Contrast that HList uses a 'Lacks' pseudo-constraint/instance failure.)
I hope Template Haskell would help with generating the instances for all
of the n-tuples -- otherwise it's a lot of boilerplate.
The tricky part comes with TIple-level combinations such as extend or
append. That might be where NewAxioms overlaps come in to calculate the
type of the result.
AntC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/04/13 00:08, Joe Nash wrote: Managed not to send to all: I think the reason markdown was the original suggestion was due to the fact it is a very widespread and popular syntax, and as Johan commented in the original thread, has to an extent won. Having a consistent, standard documentation syntax for Haskell is of course important, but this project also seeks to standardise the syntax beyond Haskell. I don't think standardising it beyond Haskell is the goal at all. I think that coming up with Markdown that doesn't repeat the mistakes of all the flavours out there is quite difficult in itself, but coming up with such Markdown AND making it making it flexible enough to be of any use with Haddock as is? I think it might be a little out of scope. Extending Haddock itself and providing a writer (and a new reader) for Pandoc will let you write Markdown if you please and then convert it to (and from) many of the formats supported by Pandoc. It may be hedging our bets, as a lot could change and markdown could suddenly fall from fame, but I believe the large variety of opposing markup languages are failing to gain traction in comparison and it is indeed a safe bet. While I don't think it will fall from fame overnight, it would be a shame to restrict people to just using Markdown because that's how all the extensions were implemented. If the flexibility of having it pandoc compatible is a desired feature, can this not be achieved through implementing markdown for haddock as well? Depending on what haddock specific features were required to be added to the superset, it may require only minimal changes to an existing markdown reader/writer in pandoc already. It can, but the restriction comment applies here as well. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRfPllAAoJEM1mucMq2pqXaKAP/20x2549NvfJgib9oitm1Qn8 CCpGRHdSw4xlIh0pHUE1MKyiJrGGgchuUErN2CJBOKXPhn1fgCWFKJyfOhcPbyr7 2Tpb9t++9G9u0JtIb6/UQpgy6RDXQAqOUs78KxRx3DCb3rYuT5TNpr5ynS58T1+9 7eGQXeUQwhCkKZH6EuIF0qTwxPTsMOAT66oRVnaZJFl2+rOBcw8ZmxMsHnk3bX9t VAR+ySwN4FWce6QZwGU43tMwFHoIxsKrmZ3ZydQPfwdQjJjFjCdTaZhtEYS1Hcvu gg0yU5mjO/1frauqjgC/qo4ez/JrJr5aYHrV91o5S2w0Wl7jfUADAIRDLfhAnTe6 shbiPPBPJeY7EAt6JEytHBmlbwZLyE3zrB0GhlhyaKY344Z5k5Woq2u6zInPx5gi rtiWOUbuerBl8autaKwnPa9i+DSmRwMD8esFIyUMyCbPOMj89YirZtxWGD+ol71i cnBXV8DbX9aYfR8c8U3WNeR8FTOvxKYEC8cc3xErsustrwFlDKzlJD41VGHVZvjB qayuRIR/qMy+fy+8UrxzCFQA32gtZ/ZmjfyHWXHhe2DujThmTi95PtgpLHe1Y2Nh hYuGhj6fqzFvSvSJkE2uWlNPVIu7viBcF1bQEZz07OdYuvU+GbA8OK8q3EzCq+l3 l5uWSedwC4cdyNRxigFS =cgRe -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
On 28 Apr 2013 11:33, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/04/13 00:08, Joe Nash wrote: Managed not to send to all: I think the reason markdown was the original suggestion was due to the fact it is a very widespread and popular syntax, and as Johan commented in the original thread, has to an extent won. Having a consistent, standard documentation syntax for Haskell is of course important, but this project also seeks to standardise the syntax beyond Haskell. I don't think standardising it beyond Haskell is the goal at all. I think that coming up with Markdown that doesn't repeat the mistakes of all the flavours out there is quite difficult in itself, but coming up with such Markdown AND making it making it flexible enough to be of any use with Haddock as is? I think it might be a little out of scope. I think my statement was a bit misleading there; I don't mean we should try to come up with a markdown flavour that is suitable for the whole internet to adopt as a standard, that is well beyond scope, as you sat. However, using markdown, even if it has differences and additional peculiarities to make it useful for haddock, is still to an extent bringing haddock in line with the other markdown users and strengthening that standard. Even with the differences there will be more similarities and it will be easier for users to move between other markdown flavours and our flavour than others and haddock syntax. Extending Haddock itself and providing a writer (and a new reader) for Pandoc will let you write Markdown if you please and then convert it to (and from) many of the formats supported by Pandoc. I do really like this idea, and expressed interest in it to John, but it adds additional complexity and dependencies for the documentation writer. Encouraging the writing of more and better documentation means removing as many barriers to doing so as possible, and having to run an additional conversion step to write in a nice syntax may impede that. Having said that, having to write in syntax you don't like also impedes that, so it may in fact encourage the writing of more/better documentation. It may be hedging our bets, as a lot could change and markdown could suddenly fall from fame, but I believe the large variety of opposing markup languages are failing to gain traction in comparison and it is indeed a safe bet. While I don't think it will fall from fame overnight, it would be a shame to restrict people to just using Markdown because that's how all the extensions were implemented. If the flexibility of having it pandoc compatible is a desired feature, can this not be achieved through implementing markdown for haddock as well? Depending on what haddock specific features were required to be added to the superset, it may require only minimal changes to an existing markdown reader/writer in pandoc already. It can, but the restriction comment applies here as well. Does it? If it is suitable to write in another markup and convert to haddock with pandoc, why is it more restrictive to write in another markup and convert to pandoc-markdown? Have I missed a point here? I think these are starting to form two projects with tangential, but slightly differing goals. It would be interesting to see the results if we diverged here and a proposal was submitted for both ideas. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/04/13 11:57, Joe Nash wrote: On 28 Apr 2013 11:33, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: If the flexibility of having it pandoc compatible is a desired feature, can this not be achieved through implementing markdown for haddock as well? Depending on what haddock specific features were required to be added to the superset, it may require only minimal changes to an existing markdown reader/writer in pandoc already. It can, but the restriction comment applies here as well. Does it? If it is suitable to write in another markup and convert to haddock with pandoc, why is it more restrictive to write in another markup and convert to pandoc-markdown? Have I missed a point here? Extending core Haddock allows us to: 1. Write in any of the Pandoc supported formats, including Markdown 2. Convert it to pure Haddock. This can then be converted back into a different format if need be. Extending Haddock with a Markdown extension allows us to: 1. Write the documentation in any of Pandoc supported formats (including our new Markdown) 2. Convert it from a Pandoc supported format to our Markdown extension as Haddock isn't expressive enough as is to be used. It's a question of being able to go from `Many formats - Pandoc - Many formats' and `Markdown extension - Pandoc - Many formats'. I think these are starting to form two projects with tangential, but slightly differing goals. It would be interesting to see the results if we diverged here and a proposal was submitted for both ideas. I think the goal is still the same: in the end, people will be able to use Markdown to document their code. The means of achieving the goal would give us a different final product that achieves the goal in a slightly different way. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRfQWCAAoJEM1mucMq2pqXSDYQAJDgstjhoDNctcvbQ6OagkOe TVrJ6V7jmSKHYHsQQziGAeEOmXgZ18UX5TEu5w+ZJ//Yf3zCulhMzAjy+jOqGFPY nOJM5kZL6e7udf/rfmrD8r4GKb3yQAvufJIVLZ8UmMZ3vCAqbOiUs7cKOVcgsoD/ nVs11ySfYfLrF64RGcMqJ6Y9AZMcv05UOOSI3aM++0rj96/34TWRwC5XvQqG08Y+ 8eEB0FZijpKFRwMS8eSrTvCTx93pZkRJpMuHawT19zmylvqoME5WCBkeiXrGUuXE VpYAU5ZZxkW03l65yHb8Ir6IB4kTvD09NprhReR5MRf0J4lbL7TX5WZhP/3APFPk on8gPn4XGqVyn93Y9GplfCCOGr6A1271xEwqOF5YV7Y6NkI/c+SBcPGitgBBE1SO 03BIjr02S9wUtk+Su3szXZ0rmU5/zTLgCAcH2aG1MfbV7tDTKrL6m/J80wjzNULQ nhfHPvqEtT/iH6G2BmyLTSuNUgakDYzA10LPRIuxgoCBaZr9mGcJ6wye/xWx6tud RcuG1a8BS02Xau+zPFKgbdp1UQ8sRW2wiqPsbvwHVMoXvJ1j8ro+Xcxv0+vmar67 tWnYRHH4WgG209j1mX3ssj0gWcFUaFHrPYR9Gpv154NxdOEFq32w9eZO1pXndo8f zW9RmOLRpqh30fX3E2iX =0um2 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language
On 27/04/13 15:21, Christopher Howard wrote: 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. You can use GHC on RHEL 5 machines, it's just very tedious to set up. A blog post I wrote a while ago describes the process: http://twdkz.wordpress.com/2011/12/21/installing-ghc-7-0-3-and-the-haskell-platform-on-rhel-5-6/ I still use this, though now I have an extra step to build build GHC 7.4.2 atop of 7.0.3. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were datatype contexts removed instead of fixing them?
On Sun, Apr 28, 2013 at 3:59 AM, harry volderm...@hotmail.com wrote: Dan Doel dan.doel at gmail.com writes: However, another thing to consider is that getting rid of data type contexts was accepted into the language standard. ... which means that implementers should be free to fix data type contexts however they like, as they are now complier extensions which won't conflict with standard Haskell. Except that people do build older programs with newer Haskell compilers, and it's bad to repurpose a syntax like that because it leads to strange errors. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
I think it's worth backing up here, and remembering the original point of the proposal, by thinking about what is and isn't a goal. I think I'd classify things like this: Goals: - Use a lightweight, common, and familiar core syntax for simple formatting. - Still allow haddock-specific stuff like links to other symbols. Non-Goals: - Compliance/compatibility with any specification or other system. - Have any kind of formal semantics. The essence of this proposal is about making Haddock come closer to matching all the other places where people type formatted text on the Internet. As Johan said, markdown has won. But markdown won because it ended up being a collection of general conventions with compatibility for the 95% of commonly used bits... NOT a formal specification. If there are bits of markdown that are just really, really awkward to use in Haddock, modify them or leave them out. I think the whole discussion is getting off on the wrong start by looking for the right specification against which this should be judged, when it's really just about building the most natural possible ad-hoc adaptation of markdown to documentation comments. Just doing the easy stuff, like switching from /foo/ to *foo* for emphasis, really is most of the goal. Anything beyond that is even better. Compatibility or compliance to a specification are non-issues: no one is going to be frequently copying documentation comments to and from other markdown sources. Haddock will unavoidably have its own extensions for references to other definitions anyway, as will the other system, so it won't be compatible. Let's just accept that. Formal semantics is a non-issue: the behavior will still be defined by the implementation, in that people will write their documentation, and if it looks wrong, they will fix it. We don't want to reason formally about the formatting of our comments, or prove that it's correct. Avoiding unpleasant surprises is good; but avoiding *all* possible ambiguous corner cases in parsing, even when they are less likely than typos, is not particularly important. If some ambiguity becomes a big problem, it will get fixed later as a bug. I think the most important thing here is to not get caught up in debates about advanced syntax or parsing ambiguities, or let that stop us from being able to emphasize words the same way we do in the whole rest of the internet. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were datatype contexts removed instead of fixing them?
Brandon Allbery allbery.b at gmail.com writes: ... which means that implementers should be free to fix data type contexts however they like, as they are now complier extensions which won't conflict with standard Haskell. Except that people do build older programs with newer Haskell compilers, and it's bad to repurpose a syntax like that because it leads to strange errors. Remembering data type contexts shouldn't break existing code, unless it's semantically broken already. (I'm sure that anyone could come up with a theoretical example of code which would break - but would it break any real-world code?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were datatype contexts removed instead of fixing them?
On Sun, Apr 28, 2013 at 10:29 AM, gs volderm...@hotmail.com wrote: Brandon Allbery allbery.b at gmail.com writes: ... which means that implementers should be free to fix data type contexts however they like, as they are now complier extensions which won't conflict with standard Haskell. Except that people do build older programs with newer Haskell compilers, and it's bad to repurpose a syntax like that because it leads to strange errors. Remembering data type contexts shouldn't break existing code, unless it's semantically broken already. (I'm sure that anyone could come up with a theoretical example of code which would break These statements are contradictory. - but would it break any real-world code?) I do not support that criterion. We use theory to ENSURE that no real-world code will break. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: Google Summer of Code, news
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
Re: [Haskell-cafe] Display an inferred type during compilation
Thanks all for your solutions!
Here is a summary:
- floating a value to the top level; then with -Wall GHC will give the type
since we didn't give a value,
- adding :: () to the value to check, GHC will complain equally,
- using TemplateHaskell (hereunder),
- waiting for the release of the next GHC with TypeHoles.
Corentin
On Sat, Apr 27, 2013 at 8:46 PM, Ilya Portnov port...@iportnov.ru wrote:
**
В письме от 27 апреля 2013 18:55:16 пользователь Corentin Dupont написал:
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
Hi.
What about TemplateHaskell? Smth like:
{-# LANGUAGE TemplateHaskell #-}
module DisplayType where
import Language.TH
displayTypeAtCompileTime :: Name - Q Exp
displayTypeAtComileTime name = do
reified - reify name
-- inspect reified structure, see TH haddock documentation
runIO $ putStrLn $ show theType
[| undefined |] -- you need to return some expression; since you are not
to use it's value, it may be even undefined, it seems.
###
{-# LANGUAGE TemplateHaskell #-}
module Main where
import DisplayType
main = do
...
$displayTypeAtCompileTime 'a
...
WBR, Ilya Portnov.
___
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] Why were datatype contexts removed instead of fixing them?
Alexander Solla alex.solla at gmail.com writes: I do not support that criterion. We use theory to ENSURE that no real-world code will break. By theoretical example, I meant something which you would never expect to find in use. Perhaps it was a poor choice of wording in an academically orientated forum :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were datatype contexts removed instead of fixing them?
On Sun, Apr 28, 2013 at 10:55 AM, gs volderm...@hotmail.com wrote: Alexander Solla alex.solla at gmail.com writes: I do not support that criterion. We use theory to ENSURE that no real-world code will break. By theoretical example, I meant something which you would never expect to find in use. Perhaps it was a poor choice of wording in an academically orientated forum :-) I understood that much. The problem is there is no good way to know what code we should expect. Real world code might be unexpected. Your criterion amounts to hoping no real world code breaks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Space leak in hexpat-0.20.3/List-0.5.1
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.Textas T import Control.Applicative (($)) import Control.Monad(forM_) import qualified System.IOas 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GSoC Push Notifications project - communicating with mobile devices
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
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
On 29/04/2013, at 3:26 AM, Chris Smith wrote: I think it's worth backing up here, and remembering the original point of the proposal, by thinking about what is and isn't a goal. I think I'd classify things like this: Goals: - Use a lightweight, common, and familiar core syntax for simple formatting. - Still allow haddock-specific stuff like links to other symbols. Non-Goals: - Compliance/compatibility with any specification or other system. - Have any kind of formal semantics. Why I find the idea of rejecting semantics appalling: Last week I was working with a documentation tool for another language which claims to be Markdown and where *bold* only allows one or more alphabetic words **bold** allows any text _italic_ only allows one or more alphabetic words __italic__ allows any text Today I had to revise some documentation for yet a third language which also claims to be Markdown and where *word* and _word_ both gave italics **word* and __word__ both gave bold. Oh, and the markup wasn't documented, because it was just Markdown, and everyone knows Markdown, right? The syntax I was using was legal syntax, but the semantics was not the semantics I expected and was not written down. I don't care how formal the syntax and semantics are, but I care very much how complete they are. Formal semantics is a non-issue: the behavior will still be defined by the implementation, in that people will write their documentation, and if it looks wrong, they will fix it. Sorry, but this is rubbish. If the semantics is not documented, then people will write their documentation, and it will look wrong, AND THEY WILL NEVER HAVE BEEN GIVEN A CLUE ABOUT WHAT TO WRITE INSTEAD. We don't want to reason formally about the formatting of our comments, or prove that it's correct. Avoiding unpleasant surprises is good; but avoiding *all* possible ambiguous corner cases in parsing, even when they are less likely than typos, is not particularly important. Hmm. Just today, again, looking at the revision list for a Markdown processor, I see comments like This changes the syntax from all previous versions... Code blocks and spans ... will now generate different output... (which reminds me that the author may not be able to fix the looks of their documentation because it may have been perfectly fine when they wrote it, and they may be unavailable when the semantics changes) Tweaked the rules ... this may affect existing content (see above) Sort-of fixed a bug ... Given Markdown's list creation rules, I'm not sure this *can* be fixed. (which is the kind of thing that happens when you decide a clear syntax and semantics are not necessary). If some ambiguity becomes a big problem, it will get fixed later as a bug. As the comment extracted above suggests, it may not be fixable. We may not care about compatibility with other dialects of Markdown, but we should care about compatibility between versions of Haddock. Damn! Why did Watts Humphrey have to die before he'd convinced the world that the cheapest way to fix bugs is to keep them out in the first place? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
On Sun, Apr 28, 2013 at 6:10 PM, Richard A. O'Keefe o...@cs.otago.ac.nzwrote: Damn! Why did Watts Humphrey have to die before he'd convinced the world that the cheapest way to fix bugs is to keep them out in the first place? I think that much has to do with the historical division in computer science. We have mathematics on the right hand, and electrical engineering on the wrong one. The electrical engineers were unduly influential in the 1960s, 70s, and 80s. The effects of such influence are still being felt. The average software developer thinks that mathematics, with its goody-two-shoes focus on soundness and validity, and all those hard to say words, is /too hard/. And as Kernighan once said, Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? I've been scoffed at during interviews for saying I solve problems on paper before I start typing! Obviously, names, types, and arrows on recycled printer paper are too clever by half. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
On Mon, Apr 29, 2013 at 8:42 AM, Alexander Solla alex.so...@gmail.comwrote: I've been scoffed at during interviews for saying I solve problems on paper before I start typing! That has to suck. I hope you're properly avenged when you find work in a savvier, respectful competitor and KICK THEIR ASSES! -- Kim-Ee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
On Apr 28, 2013 6:42 PM, Alexander Solla alex.so...@gmail.com wrote: I think that much has to do with the historical division in computer science. We have mathematics on the right hand, and electrical engineering on the wrong one. I've been called many things, but electrical engineer is a new one! My point was not anything at all to do with programming. It was about writing comments, which is fundamentally a communication activity. That makes a difference. It's important to keep in mind that the worst possible consequence of getting corner cases wrong here is likely that some documentation will be confusing because the numbering is messed up in an ordered list. Pointing out that different processors treat markdown differently with respect to bold or italics and such is ultimately missing the point. For example, I an aware that Reddit treats *foo* like italics while, say, Google+ puts it in bold... but I really don't care. What is really of any importance is that both of them take reasonable conventions from plain text and render them reasonably. As far as I'm concerned, you can flip a coin as to whether it ends up in bold or italics. That doesn't mean the choices should not be documented. Sure they should. But it seems ridiculous to sidetrack the proposal to do something nice by concerns about the minutiae of the syntax. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
On 29/04/2013, at 4:18 PM, Chris Smith wrote: My point was not anything at all to do with programming. It was about writing comments, which is fundamentally a communication activity. That makes a difference. It's important to keep in mind that the worst possible consequence of getting corner cases wrong here is likely that some documentation will be confusing because the numbering is messed up in an ordered list. The problem is not what it does to the formatting. The problem is what it does to *PEOPLE*. It wastes their time. Suppose there are 10,000 Haskell programmers (I have no idea what the true number of Haskell programmers who like to document is; I hope it's more) and they lose just 6 minutes a day working around glitches in their documentation tools. That's 1000 hours a day; call it 40 days of human life blown away in aggravation every day. To quote Jayne, Where does that get to be fun? Why is it acceptable to waste anyone's time with confusing documentation? Did anyone else read that Markdown-in-Haskell mentioned here recently whose author comments (quoting from memory) any random string of garbage is legal Markdown, so that there is no possibility of catching errors early; by definition in that processor there are no errors. Pointing out that different processors treat markdown differently with respect to bold or italics and such is ultimately missing the point. It may be missing your point, but it hits mine square in the bulls-eye. It wasn't just that they were *different*, it was that the difference wasn't *documented*, and I had to waste an hour of my *LIFE* that I will never get back because some lazy swine couldn't be buggered doing documentation. About a documentation tool. Savour the irony! That doesn't mean the choices should not be documented. Sure they should. If we agree that the semantics should be documented, what are we arguing about? But it seems ridiculous to sidetrack the proposal to do something nice by concerns about the minutiae of the syntax. Nobody is suggesting that the proposal should be *CHANGED*. So talk about sidetrack is unwarranted. The pathetic request from a suffering humanity is that the mark(up/down/sideways) should be *DOCUMENTED* clearly. As for minutiae of the syntax, *you* may call the fact that `` in the middle of a line and `` at the beginning of a line do different things minutiae of the syntax, but *I* call it wantonly squandering my few remaining hours because you think that no or confusing documentation is OK. The more I use Markdown, the better HTML looks. That is, the more effective HTML looks *AS A COMMUNICATION TOOL*, where effectiveness is measured in terms of the effort required to get the result you want. Other people may have other experiences, and that's wonderful. Having better documentation WILL NOT HURT THEM. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
