Re: [Haskell-cafe] Re: ANNOUNCE: haskell-src-exts 0.4.4
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: haskell-src-exts 0.4.4
On Wed, Dec 10, 2008 at 1:30 AM, Niklas Broberg [EMAIL PROTECTED] wrote: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: haskell-src-exts 0.4.4
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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: haskell-src-exts 0.4.4
On Wed, Dec 10, 2008 at 05:34:16PM +, 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: haskell-src-exts 0.4.4
Ross Paterson wrote: On Wed, Dec 10, 2008 at 05:34:16PM +, 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.0 + +++ new-haskell-src-exts/Language/Haskell/Exts/Build.hs 2008-12-10 17:46:47.0 + @@ -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.0 + +++ new-haskell-src-exts/Language/Haskell/Exts/Lexer.hs 2008-12-10 17:46:47.0 + @@ -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.hs2008-12-10 17:46:47.0 + +++ new-haskell-src-exts/Language/Haskell/Exts/ParseMonad.hs2008-12-10 17:46:47.0 + @@ -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.hs2008-12-10 17:46:47.0 + +++ new-haskell-src-exts/Language/Haskell/Exts/ParseUtils.hs2008-12-10 17:46:47.0 + @@ -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.ly2008-12-10 17:46:47.0 + +++ new-haskell-src-exts/Language/Haskell/Exts/Parser.ly2008-12-10 17:46:47.0 + @@ -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.hs2008-12-10 17:46:47.0 + +++ new-haskell-src-exts/Language/Haskell/Exts/Pretty.hs2008-12-10 17:46:47.0 + @@ -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
[Haskell-cafe] Re: ANNOUNCE: haskell-src-exts 0.4.4
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. Thanks a lot Chris, patch applied to the repo and will appear in the next release. Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: haskell-src-exts 0.4.4
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? Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: haskell-src-exts 0.4.4
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: haskell-src-exts 0.4.4
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: haskell-src-exts 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.
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: haskell-src-exts 0.4.4
The only pragmas supported by GHC that HSE supports are, to my knowledge, ANN and LINE. Umm, right, insert a does not in the proper place there... Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: haskell-src-exts 0.4.4
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
