ANN: haskell-src-exts-1.0.0
Fellow Haskelleers, It is with great pleasure I hereby announce the first stable release of the haskell-src-exts package, version 1.0.0! haskell-src-exts is a package for Haskell source code manipulation. In particular it defines an abstract syntax tree representation, and a parser and pretty-printer to convert between this representation and String. It handles (almost(*)) all syntactic extensions to the Haskell 98 standard implemented by GHC, and the parsing can be parametrised on what extensions to recognise. I wish to thank the glorious Haskell community, for giving me the chance to work on this project as part of Haskell.org's GSoC programme, but also for simply being such a nice place to be! Special thanks to everyone who helped me with testing and bug reports during the final stretch of release candidates, in particular the many excellent reports from Ganesh Sittampalam, Sebastian Fischer, and Neil Mitchell who is also mentoring the project. You're all awesome! haskell-src-exts-1.0.0: ================= Via cabal: cabal install haskell-src-exts-1.0.0 Via darcs: darcs get http://code.haskell.org/haskell-src-exts On hackage: http://hackage.haskell.org/package/haskell-src-exts-1.0.0 Changes from 0.5.7, the last release candidate: ====================================== * CPP lines are no longer ignored, which means haskell-src-exts will now invariably give a parse error on files with CPP pragmas in them. CPP is not supported by haskell-src-exts, and this is more intuitive than parsing e.g. all branches of an #if pragma, which is invariably give unintended results. * Fixed a stupid introduced bug where extensions passed int he parse mode were ignored. * fromParseOk is now exported, not just defined (doh). * ScopedTypeVariables now implies TypeOperators, as per GHC. I'm sure there are more implications that are missing from haskell-src-exts, I will add them as I find out about them. Thanks once again, and Happy Haskell Hacking to all! Cheers, /Niklas (*) The only two exceptions are NewQualifiedOperators and UnicodeSyntax.
It is with great pleasure I hereby announce the first stable release of the haskell-src-exts package, version 1.0.0!
There's a kind of programming work that have great intelectual impact, as it lets you see your code in diferent ways. Yours, however, is of a special kind, as it has a physical impact on those who use it. With haskell-src-exts, all the time I'm typing Haskell I feel less pain in my fingers, since now I can get beautifull pretty-printed code with no thumb pain. Haskell is now a more pleasant experience.
It handles (almost(*)) all syntactic extensions to the Haskell 98 standard implemented by GHC, (...)
(*) The only two exceptions are NewQualifiedOperators and UnicodeSyntax.
How far is Unicode from beeing parsed? It doesn't seem to be a huge step (from my ill-informed viewpoint), and it would not let behind those who are happy to be able to declare names in their own native language. (Oh, and sorry for resorting to politically correct blackmail...) Best, Maurício
Hi Maurício,
How far is Unicode from beeing parsed? It doesn't seem to be a huge step (from my ill-informed viewpoint), and it would not let behind those who are happy to be able to declare names in their own native language. (Oh, and sorry for resorting to politically correct blackmail...)
Unicode in identifiers and symbols actually already works, assuming you don't use the non-Unicode-aware parseFile, parseFileWithExts or parseFileWithMode (which all use Prelude.readLine). What doesn't work is to use the Unicode versions of special symbols like ->, => etc. I'm waiting for a stable and blessed unicode-aware text package to replace utf8-string, before we have one of those then my support would only be half-hearted at best. But in the mean time you can use the readLine provided by utf8-string, and then parseFileContents on that, which should give you the politically correct names. ;-) Cheers, /Niklas
participants (2)
-
Maurício -
Niklas Broberg