Hi all, I'm pleased to announce a new release for the haskell-src-exts package. haskell-src-exts 0.3.2 =========================== haskell-src-exts is a package for handling and manipulating Haskell source code. It is based on the haskell-src package that is part of the standard libraries, but extends this to support a number of syntactic extensions, e.g. MPTCs, fundeps, GADTs, TH etc. It is intended as a drop-in replacement for the standard haskell-src package, and exports the same functions and data types, plus some more. Apart from the more standard extensions supported by e.g. GHC, haskell-src-exts also provides support for HaRP (Haskell Regular Patterns) and HSX (Haskell Source with XML) syntax. Note that as of 0.3, haskell-src-exts /= HSX. * cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-... * darcs repo: darcs get http://code.haskell.org/HSP/haskell-src-exts === Changes from 0.2: === * Added support for - Indexed type families (including associated types/datatypes) - Explicit kind signatures - Standalone deriving * haskell-src-exts is now decoupled from hsx/trhsx and harp. - Modules renamed to Language.Haskell.Exts.* - Module Transform is removed from the package (now in package hsx) * New repository (i.e. darcs pull in an old repo won't work, use darcs get), containing only the haskell-src-exts package (no hsx or harp). * Builds with 6.8.2 (thanks Duncan Coutts) === Complete list of supported extensions === * Multi-parameter type classes (MPTCs) * Functional dependencies * Associated types, indexed type families * Liberal class and instance heads * Implicit parameters * Explicit kind signatures * Pattern guards * Generalized algebraic data types (GADTs) * Template Haskell (TH) * Universal and existential quantification (forall) * Empty data type declarations * Unboxed tuples (# #) * Standalone deriving * Regular patterns * Haskell XML, HSX style === Build Requirements === * happy >= 1.17 - It might work with 1.16 though I haven't tested. In that case change the cabal file. - It would work with older versions as well, though they insert a dependency on Array (haskell98) instead of Data.Array. If that's all you have to work with, update the cabal file with a dependency on haskell98. * Cabal >= 1.2 Patches are more than welcome. :-) Cheers, /Niklas
I'm pleased to announce a new release for the haskell-src-exts package.
Twice in two days even. :-) haskell-src-exts 0.3.3 - now with support for type equality constraints. cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-... darcs repo: http://code.haskell.org/HSP/haskell-src-exts Cheers, /Niklas
haskell-src-exts 0.3.2 ===========================
haskell-src-exts is a package for handling and manipulating Haskell source code. It is based on the haskell-src package that is part of the standard libraries, but extends this to support a number of syntactic extensions, e.g. MPTCs, fundeps, GADTs, TH etc. It is intended as a drop-in replacement for the standard haskell-src package, and exports the same functions and data types, plus some more.
Apart from the more standard extensions supported by e.g. GHC, haskell-src-exts also provides support for HaRP (Haskell Regular Patterns) and HSX (Haskell Source with XML) syntax.
Note that as of 0.3, haskell-src-exts /= HSX.
* cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-... * darcs repo: darcs get http://code.haskell.org/HSP/haskell-src-exts
=== Changes from 0.2: ===
* Added support for - Indexed type families (including associated types/datatypes) - Explicit kind signatures - Standalone deriving
* haskell-src-exts is now decoupled from hsx/trhsx and harp. - Modules renamed to Language.Haskell.Exts.* - Module Transform is removed from the package (now in package hsx)
* New repository (i.e. darcs pull in an old repo won't work, use darcs get), containing only the haskell-src-exts package (no hsx or harp).
* Builds with 6.8.2 (thanks Duncan Coutts)
=== Complete list of supported extensions ===
* Multi-parameter type classes (MPTCs) * Functional dependencies * Associated types, indexed type families * Liberal class and instance heads * Implicit parameters * Explicit kind signatures * Pattern guards * Generalized algebraic data types (GADTs) * Template Haskell (TH) * Universal and existential quantification (forall) * Empty data type declarations * Unboxed tuples (# #) * Standalone deriving * Regular patterns * Haskell XML, HSX style
=== Build Requirements ===
* happy >= 1.17 - It might work with 1.16 though I haven't tested. In that case change the cabal file. - It would work with older versions as well, though they insert a dependency on Array (haskell98) instead of Data.Array. If that's all you have to work with, update the cabal file with a dependency on haskell98.
* Cabal >= 1.2
Patches are more than welcome. :-)
Cheers,
/Niklas
Could this be used to add support for refactoring of source files containing language extensions? Because if I'm correct, the current most popular refactoring solution (I forgot the name) for Haskell does not support extensions. It would also be nice to add support for the arrows syntax :-) Cheers, Peter Verswyvelen www.anygma.com Niklas Broberg wrote:
I'm pleased to announce a new release for the haskell-src-exts package.
Twice in two days even. :-)
haskell-src-exts 0.3.3 - now with support for type equality constraints.
cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-... darcs repo: http://code.haskell.org/HSP/haskell-src-exts
Cheers,
/Niklas
haskell-src-exts 0.3.2 ===========================
haskell-src-exts is a package for handling and manipulating Haskell source code. It is based on the haskell-src package that is part of the standard libraries, but extends this to support a number of syntactic extensions, e.g. MPTCs, fundeps, GADTs, TH etc. It is intended as a drop-in replacement for the standard haskell-src package, and exports the same functions and data types, plus some more.
Apart from the more standard extensions supported by e.g. GHC, haskell-src-exts also provides support for HaRP (Haskell Regular Patterns) and HSX (Haskell Source with XML) syntax.
Note that as of 0.3, haskell-src-exts /= HSX.
* cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-... * darcs repo: darcs get http://code.haskell.org/HSP/haskell-src-exts
=== Changes from 0.2: ===
* Added support for - Indexed type families (including associated types/datatypes) - Explicit kind signatures - Standalone deriving
* haskell-src-exts is now decoupled from hsx/trhsx and harp. - Modules renamed to Language.Haskell.Exts.* - Module Transform is removed from the package (now in package hsx)
* New repository (i.e. darcs pull in an old repo won't work, use darcs get), containing only the haskell-src-exts package (no hsx or harp).
* Builds with 6.8.2 (thanks Duncan Coutts)
=== Complete list of supported extensions ===
* Multi-parameter type classes (MPTCs) * Functional dependencies * Associated types, indexed type families * Liberal class and instance heads * Implicit parameters * Explicit kind signatures * Pattern guards * Generalized algebraic data types (GADTs) * Template Haskell (TH) * Universal and existential quantification (forall) * Empty data type declarations * Unboxed tuples (# #) * Standalone deriving * Regular patterns * Haskell XML, HSX style
=== Build Requirements ===
* happy >= 1.17 - It might work with 1.16 though I haven't tested. In that case change the cabal file. - It would work with older versions as well, though they insert a dependency on Array (haskell98) instead of Data.Array. If that's all you have to work with, update the cabal file with a dependency on haskell98.
* Cabal >= 1.2
Patches are more than welcome. :-)
Cheers,
/Niklas
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On 17 mar 2008, at 23.53, Peter Verswyvelen wrote:
Could this be used to add support for refactoring of source files containing language extensions?
Because if I'm correct, the current most popular refactoring solution (I forgot the name) for Haskell does not support extensions.
HaRe - http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html
It would also be nice to add support for the arrows syntax :-)
Cheers, Peter Verswyvelen www.anygma.com
Niklas Broberg wrote:
I'm pleased to announce a new release for the haskell-src-exts package. Twice in two days even. :-) haskell-src-exts 0.3.3 - now with support for type equality constraints. cabal sdist: http:// hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src- exts-0.3.3 darcs repo: http://code.haskell.org/HSP/haskell-src- exts Cheers, /Niklas
haskell-src-exts 0.3.2 =========================== haskell-src- exts is a package for handling and manipulating Haskell source code. It is based on the haskell-src package that is part of the standard libraries, but extends this to support a number of syntactic extensions, e.g. MPTCs, fundeps, GADTs, TH etc. It is intended as a drop-in replacement for the standard haskell-src package, and exports the same functions and data types, plus some more. Apart from the more standard extensions supported by e.g. GHC, haskell-src-exts also provides support for HaRP (Haskell Regular Patterns) and HSX (Haskell Source with XML) syntax. Note that as of 0.3, haskell-src-exts /= HSX. * cabal sdist: http:// hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src- exts-0.3.2 * darcs repo: darcs get http://code.haskell.org/HSP/ haskell-src-exts === Changes from 0.2: === * Added support for - Indexed type families (including associated types/datatypes) - Explicit kind signatures - Standalone deriving * haskell-src-exts is now decoupled from hsx/trhsx and harp. - Modules renamed to Language.Haskell.Exts.* - Module Transform is removed from the package (now in package hsx) * New repository (i.e. darcs pull in an old repo won't work, use darcs get), containing only the haskell-src-exts package (no hsx or harp). * Builds with 6.8.2 (thanks Duncan Coutts) === Complete list of supported extensions === * Multi-parameter type classes (MPTCs) * Functional dependencies * Associated types, indexed type families * Liberal class and instance heads * Implicit parameters * Explicit kind signatures * Pattern guards * Generalized algebraic data types (GADTs) * Template Haskell (TH) * Universal and existential quantification (forall) * Empty data type declarations * Unboxed tuples (# #) * Standalone deriving * Regular patterns * Haskell XML, HSX style === Build Requirements === * happy >= 1.17 - It might work with 1.16 though I haven't tested. In that case change the cabal file. - It would work with older versions as well, though they insert a dependency on Array (haskell98) instead of Data.Array. If that's all you have to work with, update the cabal file with a dependency on haskell98. * Cabal >= 1.2 Patches are more than welcome. :-) Cheers, /Niklas _______________________________________________ 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
Could this be used to add support for refactoring of source files containing language extensions?
Because if I'm correct, the current most popular refactoring solution (I forgot the name) for Haskell does not support extensions.
I supppose you're talking about HaRe, that Thomas Schilling linked to. I have no idea how that system is built so I can't answer your question. But in principle I don't see why not. :-)
It would also be nice to add support for the arrows syntax :-)
Right, that's one of the few extensions missing, and as such it's pretty high on the todo list. I'll see what/ I can do about it (or when rather), or if anyone would send me a patch I'd be happy to include it. :-) Cheers, /Niklas
On 17 Mar 2008, at 23:41, Niklas Broberg wrote:
Could this be used to add support for refactoring of source files containing language extensions?
Because if I'm correct, the current most popular refactoring solution (I forgot the name) for Haskell does not support extensions.
I supppose you're talking about HaRe, that Thomas Schilling linked to. I have no idea how that system is built so I can't answer your question. But in principle I don't see why not. :-)
I believe that the limitation is that they use Programatica's parser to get an AST to run their refactorings on. I think they've looked several times at using ghc's apis to do this, but hit various problems. I think that the main problem is that no other parser preserves things like code layout and commenting, which is of course pretty critical to refactoring programs in a sane kind of way. Thanks Tom
I believe that the limitation is that they use Programatica's parser to get an AST to run their refactorings on. I think they've looked several times at using ghc's apis to do this, but hit various problems. I think that the main problem is that no other parser preserves things like code layout and commenting, which is of course pretty critical to refactoring programs in a sane kind of way.
I think the main issue was that we looked at the port too early. I believe GHC would offer everything in terms of position information but at the time of the port there were issues such as Strafunski traversing over GHC's AST (now made possible with derivable instances); together with time restraints and the learning curve of GHC's internals. There is a technical report available that details some of the work: (Porting HaRe to the GHC API) http://www.cs.kent.ac.uk/pubs/2005/2266/ Thanks, Chris.
Thanks
Tom _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Hi Nikolas,
I supppose you're talking about HaRe, that Thomas Schilling linked to. I have no idea how that system is built so I can't answer your question. But in principle I don't see why not. :-)
In principle it would actually be quite difficult. HaRe is Haskell 98, built upon the Programatica front end, and to use extensions would mean a port to a system that has extensions (ghc say) and a re-evaluation of all the current refactorings so that they work over extensions as well. Porting to a system like GHC would require an almost complete re-engineering of HaRe, and, although simple in theory, in practice it has so far presented some problems. With the exposure of the GHC API though, we hope to address this issue in the near future. Kind regards, Chris.
Do you have any program transformation DSL to make things easier? Or quickcheck tests or anything to make things easier? On 18 mar 2008, at 11.28, C.M.Brown wrote:
Hi Nikolas,
I supppose you're talking about HaRe, that Thomas Schilling linked to. I have no idea how that system is built so I can't answer your question. But in principle I don't see why not. :-)
In principle it would actually be quite difficult. HaRe is Haskell 98, built upon the Programatica front end, and to use extensions would mean a port to a system that has extensions (ghc say) and a re-evaluation of all the current refactorings so that they work over extensions as well.
Porting to a system like GHC would require an almost complete re- engineering of HaRe, and, although simple in theory, in practice it has so far presented some problems. With the exposure of the GHC API though, we hope to address this issue in the near future.
Kind regards, Chris. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Do you have any program transformation DSL to make things easier? Or quickcheck tests or anything to make things easier?
I'm not sure I follow how these would make the port easier? We don't have a DSL, but we do have a very sophisticated API: http://www.cs.kent.ac.uk/projects/refactor-fp/hare/API_Doc/RefacUtils.html There has been some work done by Huiqing to generate test cases using Quickcheck for Erlang refactoring: http://www.cs.kent.ac.uk/pubs/2007/2648/index.html Chris.
On 18 mar 2008, at 11.28, C.M.Brown wrote:
Hi Nikolas,
I supppose you're talking about HaRe, that Thomas Schilling linked to. I have no idea how that system is built so I can't answer your question. But in principle I don't see why not. :-)
In principle it would actually be quite difficult. HaRe is Haskell 98, built upon the Programatica front end, and to use extensions would mean a port to a system that has extensions (ghc say) and a re-evaluation of all the current refactorings so that they work over extensions as well.
Porting to a system like GHC would require an almost complete re- engineering of HaRe, and, although simple in theory, in practice it has so far presented some problems. With the exposure of the GHC API though, we hope to address this issue in the near future.
Kind regards, Chris. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (5)
-
C.M.Brown -
Niklas Broberg -
Peter Verswyvelen -
Thomas Davie -
Thomas Schilling