Fellow Haskelleers, it is my pleasure to announce the new release of the haskell-src-exts package, version 0.4.4: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-... darcs get http://code.haskell.org/HSP/haskell-src-exts The new feature in this release is support for pragmas. haskell-src-exts-0.4.4 supports all pragmas supported by GHC, with the exception of option-level pragmas (LANGUAGE, OPTIONS_GHC etc) that appear before the module header. The reason these are not yet supported is simply time, there's no real difficulty involved in supporting them too and I will surely get there eventually. 0.4.4 is backwards incompatible with 0.4.3 for two constructors: * The Module constructor (:: Module) now has an extra argument of type 'Maybe WarningText', used for deprecated modules. * The ImportDecl constructor (:: ImportDecl) now has an extra argument of type Bool, stating whether the SOURCE pragma has been used for the import. The full list of pragmas supported by 0.4.4 is: SOURCE, RULES, DEPRECATED, WARNING, INLINE, NOINLINE, SPECIALISE, CORE, SCC, GENERATED and UNPACK. Cheers and Happy Haskelling, /Niklas
Niklas Broberg wrote:
Fellow Haskelleers,
it is my pleasure to announce the new release of the haskell-src-exts package, version 0.4.4:
The full list of pragmas supported by 0.4.4 is: SOURCE, RULES, DEPRECATED, WARNING, INLINE, NOINLINE, SPECIALISE, CORE, SCC, GENERATED and UNPACK.
Ah, excellent. The hprotoc program generates possibly mutually recursive modules and when it does these need fixing up by hand to add SOURCE pragmas and boot files. I could use your new package to automatically break the recursion. Interesting. Thanks, Chris
The full list of pragmas supported by 0.4.4 is: SOURCE, RULES, DEPRECATED, WARNING, INLINE, NOINLINE, SPECIALISE, CORE, SCC, GENERATED and UNPACK.
The newly released version 0.4.4.1 adds to the list of pragmas supported by adding support for the following: LANGUAGE, OPTIONS, OPTIONS_{GHC, HUGS, NHC98, YHC, HADDOCK, your tool here}, INCLUDE and CFILES. The LANGUAGE pragma is checked for well-formedness (a comma-separated list of constructors) but no validation of the constructors is done. The other pragmas all have their contents unchecked and passed along as is. Apart from this, HSE now also parses any unrecognized pragma in option (e.g. LANGUAGE), declaration (e.g. RULES) or expression (e.g. SCC) position, allowing user-customized pragmas. Unrecognized pragmas in other positions will (unfortunately) give a parse error. If this ever means a problem for you - let me know! The only pragmas supported by GHC that HSE supports are, to my knowledge, ANN and LINE. I may add support for these in a near future, though I believe the syntax for the ANN pragma is still a bit in flux. Note that source files containing these pragmas can still be parsed by HSE, just like any other unrecognized pragmas in proper positions.
0.4.4 is backwards incompatible with 0.4.3 for two constructors: * The Module constructor (:: Module) now has an extra argument of type 'Maybe WarningText', used for deprecated modules. * The ImportDecl constructor (:: ImportDecl) now has an extra argument of type Bool, stating whether the SOURCE pragma has been used for the import.
0.4.4.1 is backwards incompatible with 0.4.4 by adding yet another argument to the Module constructor (:: Module) of type [OptionPragma], used to list the pragmas preceding the beginning of the module proper. Cheers and happy haskelling, /Niklas
On Sun, Dec 7, 2008 at 10:28 PM, Niklas Broberg
The full list of pragmas supported by 0.4.4 is: SOURCE, RULES, DEPRECATED, WARNING, INLINE, NOINLINE, SPECIALISE, CORE, SCC, GENERATED and UNPACK.
The newly released version 0.4.4.1 adds to the list of pragmas supported by adding support for the following: LANGUAGE, OPTIONS, OPTIONS_{GHC, HUGS, NHC98, YHC, HADDOCK, your tool here}, INCLUDE and CFILES. The LANGUAGE pragma is checked for well-formedness (a comma-separated list of constructors) but no validation of the constructors is done. The other pragmas all have their contents unchecked and passed along as is.
Apart from this, HSE now also parses any unrecognized pragma in option (e.g. LANGUAGE), declaration (e.g. RULES) or expression (e.g. SCC) position, allowing user-customized pragmas. Unrecognized pragmas in other positions will (unfortunately) give a parse error. If this ever means a problem for you - let me know!
The only pragmas supported by GHC that HSE supports are, to my knowledge, ANN and LINE. I may add support for these in a near future, though I believe the syntax for the ANN pragma is still a bit in flux. Note that source files containing these pragmas can still be parsed by HSE, just like any other unrecognized pragmas in proper positions.
0.4.4 is backwards incompatible with 0.4.3 for two constructors: * The Module constructor (:: Module) now has an extra argument of type 'Maybe WarningText', used for deprecated modules. * The ImportDecl constructor (:: ImportDecl) now has an extra argument of type Bool, stating whether the SOURCE pragma has been used for the import.
0.4.4.1 is backwards incompatible with 0.4.4 by adding yet another argument to the Module constructor (:: Module) of type [OptionPragma], used to list the pragmas preceding the beginning of the module proper.
Cheers and happy haskelling,
Are SrcSpan's on the TODO list? -- Cheers, Lemmih
On Wed, Dec 10, 2008 at 1:30 AM, Niklas Broberg
Are SrcSpan's on the TODO list?
Seeing how this is the first I hear of them, I can't say that they have been, but they could be. :-)
Could you give me a rundown on what usecases you'd need SrcSpans for, and where HSE currently fails you in this regard?
Many editors can find source spans in error messages and highlight the indicated code. Source analysing tools such as HPC or global dead code eliminators often need to annotate the code. These are just the use cases I've personally encountered. I'm sure there are more just waiting to be developed. -- Cheers, Lemmih
Hi Niklas,
Apart from this, HSE now also parses any unrecognized pragma in option (e.g. LANGUAGE), declaration (e.g. RULES) or expression (e.g. SCC) position, allowing user-customized pragmas. Unrecognized pragmas in other positions will (unfortunately) give a parse error. If this ever means a problem for you - let me know!
This is likely to be a problem for me :-) I certainly have OPTIONS_DERIVE and CATCH pragmas that I've inserted into various programs over time. I think failing on an unrecognised pragma is probably a bad idea, when ignoring a pragma is usually perfectly safe. Thanks Neil
* Neil Mitchell
Apart from this, HSE now also parses any unrecognized pragma in option (e.g. LANGUAGE), declaration (e.g. RULES) or expression (e.g. SCC) position, allowing user-customized pragmas. Unrecognized pragmas in other positions will (unfortunately) give a parse error. If this ever means a problem for you - let me know!
This is likely to be a problem for me :-)
I certainly have OPTIONS_DERIVE and CATCH pragmas that I've inserted into various programs over time. I think failing on an unrecognised pragma is probably a bad idea, when ignoring a pragma is usually perfectly safe.
Even more, An implementation is not required to respect any pragma, but the pragma should be ignored if an implementation is not prepared to handle it.[1] Related question: why does not Language.Haskell.Syntax[2] (from haskell-src) represent comments or pragmas in any way? 1. http://www.haskell.org/onlinereport/pragmas.html 2. http://www.haskell.org/ghc/docs/latest/html/libraries/haskell-src/Language-H... -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain
Apart from this, HSE now also parses any unrecognized pragma in option (e.g. LANGUAGE), declaration (e.g. RULES) or expression (e.g. SCC) position, allowing user-customized pragmas. Unrecognized pragmas in other positions will (unfortunately) give a parse error. If this ever means a problem for you - let me know!
This is likely to be a problem for me :-)
I certainly have OPTIONS_DERIVE and CATCH pragmas that I've inserted into various programs over time.
Are you sure that would be a problem? Seems to me that OPTIONS_DERIVE would appear in the same position as any other OPTIONS pragma, in which case HSE will handle it just fine. I don't know where CATCH would appear, but intuitively it sounds like something that would appear as an expression (or statement which is really just an expression), in which case HSE will handle it too. It's only pragmas appearing in "surprising" locations that would cause HSE to balk.
I think failing on an unrecognised pragma is probably a bad idea, when ignoring a pragma is usually perfectly safe.
Well, I have a dilemma here. To ignore a pragma, I need to ignore it at the lexer stage, since once I've passed a lexed token to the parser it needs to be handled in some way, or a parse error ensues. It's not hard to have a set of recognized pragmas that pass the lexer stage, and discard any others as comments. However, I am not fully satisfied with this approach, the reason being that I've had feature requests for HSE to allow for custom, user-defined pragmas. I can't ignore unrecognized pragmas *and* allow custom pragmas. The safe way is obviously to be conservative, but it is also the way that gives the users the least power over pragmas. There is also the option to lex all pragmas, and then pollute the parser so that every primitive could be an unrecognized pragma followed by the actual primitive. That would make it safe in all instances, and user-custom pragmas could be allowed in predefined positions, and discarded by the parser in others. But the cost would be quite high in terms of parser complexity. I could potentially also add the possibility for unknown pragmas to appear in all other positions too - types, patterns etc. But that too would be quite a lot of extra machinery for something that would most likely be used very rarely at best. I'm torn and welcome all input on this matter. Cheers, /Niklas
Hi Niklas,
I certainly have OPTIONS_DERIVE and CATCH pragmas that I've inserted into various programs over time.
Are you sure that would be a problem? Seems to me that OPTIONS_DERIVE would appear in the same position as any other OPTIONS pragma, in which case HSE will handle it just fine. I don't know where CATCH would appear, but intuitively it sounds like something that would appear as an expression (or statement which is really just an expression), in which case HSE will handle it too. It's only pragmas appearing in "surprising" locations that would cause HSE to balk.
Ah, so its not unrecognised pragmas, but pragmas in unrecognised places? In that case that's fine. The CATCH pragmas go at the statement level, so are fairly standard in terms of placement. Thanks Neil
On Thu, 2008-12-04 at 19:04 +0100, Niklas Broberg wrote:
Fellow Haskelleers,
it is my pleasure to announce the new release of the haskell-src-exts package, version 0.4.4:
So when will we simply declare that haskell-src-exts is the new haskell-src? :-) That implementation is widely acknowledged to be limited and less than useful. For example it cannot even do the identity transform on Haskell98 programs because it omits brackets in expressions with infix operators. Duncan
(CC libraries)
So when will we simply declare that haskell-src-exts is the new haskell-src? :-)
I talked about this with Ross Paterson at one point, and his main objection (which I very much agree with) was that haskell-src-exts doesn't let you *optionally* handle extensions, so in some cases valid H98 programs will be discarded due to syntax stealing (e.g. $x from TH). I've had ideas for how to fix this shortcoming for a long while, but never really had the time to actually implement it. It is still my hope and goal that haskell-src-exts will replace the haskell-src package, when it is ready to do so. What do others think about this? Cheers, /Niklas
Is there anyway to track down and fix why haskell-src-exts-0.4.4.1 still gets "haddock: parse error in doc string" when I try to get cabal to haddock the package?
On Wed, Dec 10, 2008 at 05:34:16PM +0000, ChrisK wrote:
Is there anyway to track down and fix why haskell-src-exts-0.4.4.1 still gets
"haddock: parse error in doc string"
when I try to get cabal to haddock the package?
Line numbers would be handy. In this case, the problem is the "Original:" line in some of the module headers.
Ross Paterson wrote:
On Wed, Dec 10, 2008 at 05:34:16PM +0000, ChrisK wrote:
Is there anyway to track down and fix why haskell-src-exts-0.4.4.1 still gets
"haddock: parse error in doc string"
when I try to get cabal to haddock the package?
Line numbers would be handy.
In this case, the problem is the "Original:" line in some of the module headers.
Indeed, I just found that. I wonder where in the universe this is documented. Oh well. I also had to change -- $x and -- $( comments. A "darcs diff -u" patch is attached. Cheers, Chris diff -rN -u old-haskell-src-exts/Language/Haskell/Exts/Build.hs new-haskell-src-exts/Language/Haskell/Exts/Build.hs --- old-haskell-src-exts/Language/Haskell/Exts/Build.hs 2008-12-10 17:46:47.000000000 +0000 +++ new-haskell-src-exts/Language/Haskell/Exts/Build.hs 2008-12-10 17:46:47.000000000 +0000 @@ -1,7 +1,6 @@ ----------------------------------------------------------------------------- -- | -- Module : Language.Haskell.Exts.Build --- Original : Language.Haskell.Syntax -- Copyright : (c) The GHC Team, 1997-2000, -- (c) Niklas Broberg 2004 -- License : BSD-style (see the file LICENSE.txt) diff -rN -u old-haskell-src-exts/Language/Haskell/Exts/Lexer.hs new-haskell-src-exts/Language/Haskell/Exts/Lexer.hs --- old-haskell-src-exts/Language/Haskell/Exts/Lexer.hs 2008-12-10 17:46:47.000000000 +0000 +++ new-haskell-src-exts/Language/Haskell/Exts/Lexer.hs 2008-12-10 17:46:47.000000000 +0000 @@ -2,7 +2,6 @@ ----------------------------------------------------------------------------- -- | -- Module : Language.Haskell.Exts.Lexer --- Original : Language.Haskell.Lexer -- Copyright : (c) The GHC Team, 1997-2000 -- (c) Niklas Broberg, 2004 -- License : BSD-style (see the file LICENSE.txt) @@ -83,8 +82,8 @@ | THDecQuote -- [d| | THTypQuote -- [t| | THCloseQuote -- |] - | THIdEscape (String) -- $x - | THParenEscape -- $( + | THIdEscape (String) -- dollar x + | THParenEscape -- dollar ( | THVarQuote -- 'x (but without the x) | THTyQuote -- ''T (but without the T) diff -rN -u old-haskell-src-exts/Language/Haskell/Exts/ParseMonad.hs new-haskell-src-exts/Language/Haskell/Exts/ParseMonad.hs --- old-haskell-src-exts/Language/Haskell/Exts/ParseMonad.hs 2008-12-10 17:46:47.000000000 +0000 +++ new-haskell-src-exts/Language/Haskell/Exts/ParseMonad.hs 2008-12-10 17:46:47.000000000 +0000 @@ -2,7 +2,6 @@ ----------------------------------------------------------------------------- -- | -- Module : Language.Haskell.Exts.ParseMonad --- Original : Language.Haskell.ParseMonad -- Copyright : (c) The GHC Team, 1997-2000 -- License : BSD-style (see the file libraries/base/LICENSE) -- diff -rN -u old-haskell-src-exts/Language/Haskell/Exts/ParseUtils.hs new-haskell-src-exts/Language/Haskell/Exts/ParseUtils.hs --- old-haskell-src-exts/Language/Haskell/Exts/ParseUtils.hs 2008-12-10 17:46:47.000000000 +0000 +++ new-haskell-src-exts/Language/Haskell/Exts/ParseUtils.hs 2008-12-10 17:46:47.000000000 +0000 @@ -2,7 +2,6 @@ ----------------------------------------------------------------------------- -- | -- Module : Language.Haskell.Exts.ParseUtils --- Original : Language.Haskell.ParseUtils -- Copyright : (c) Niklas Broberg 2004, -- (c) The GHC Team, 1997-2000 -- License : BSD-style (see the file LICENSE.txt) diff -rN -u old-haskell-src-exts/Language/Haskell/Exts/Parser.ly new-haskell-src-exts/Language/Haskell/Exts/Parser.ly --- old-haskell-src-exts/Language/Haskell/Exts/Parser.ly 2008-12-10 17:46:47.000000000 +0000 +++ new-haskell-src-exts/Language/Haskell/Exts/Parser.ly 2008-12-10 17:46:47.000000000 +0000 @@ -2,7 +2,6 @@
----------------------------------------------------------------------------- -- | -- Module : Language.Haskell.Exts.Parser -> -- Original : Language.Haskell.Parser -- Copyright : (c) Niklas Broberg 2004, -- Original (c) Simon Marlow, Sven Panne 1997-2000 -- License : BSD-style (see the file LICENSE.txt) diff -rN -u old-haskell-src-exts/Language/Haskell/Exts/Pretty.hs new-haskell-src-exts/Language/Haskell/Exts/Pretty.hs --- old-haskell-src-exts/Language/Haskell/Exts/Pretty.hs 2008-12-10 17:46:47.000000000 +0000 +++ new-haskell-src-exts/Language/Haskell/Exts/Pretty.hs 2008-12-10 17:46:47.000000000 +0000 @@ -2,7 +2,6 @@
-- | -- Module : Language.Haskell.Exts.Pretty --- Original : Language.Haskell.Pretty -- Copyright : (c) Niklas Broberg 2004, -- (c) The GHC Team, Noel Winstanley 1997-2000 -- License : BSD-style (see the file LICENSE.txt) diff -rN -u old-haskell-src-exts/Language/Haskell/Exts/Syntax.hs new-haskell-src-exts/Language/Haskell/Exts/Syntax.hs --- old-haskell-src-exts/Language/Haskell/Exts/Syntax.hs 2008-12-10 17:46:47.000000000 +0000 +++ new-haskell-src-exts/Language/Haskell/Exts/Syntax.hs 2008-12-10 17:46:47.000000000 +0000 @@ -2,7 +2,6 @@ ----------------------------------------------------------------------------- -- | -- Module : Language.Haskell.Exts.Syntax --- Original : Language.Haskell.Syntax -- Copyright : (c) Niklas Broberg 2004, -- (c) The GHC Team, 1997-2000 -- License : BSD-style (see the file LICENSE.txt)
participants (7)
-
ChrisK -
Duncan Coutts -
Lemmih -
Neil Mitchell -
Niklas Broberg -
Roman Cheplyaka -
Ross Paterson