haskell-src-exts: Ticket Queryhttp://trac.haskell.org/haskell-src-exts/query?status=new&status=assigned&status=reopened&group=owner&row=description
haskell-src-exts is a library for parsing, printing and manipulating Haskell source code. Its aim is to support all extensions registered with cabal.en-UShaskell-src-extshttp://trac.haskell.org/haskell-src-exts/chrome/common/trac_banner.pnghttp://trac.haskell.org/haskell-src-exts/query?status=new&status=assigned&status=reopened&group=owner&row=description
Trac 0.11.1http://trac.haskell.org/haskell-src-exts/ticket/17
http://trac.haskell.org/haskell-src-exts/ticket/17#17: Test driver for pretty-printingTue, 26 May 2009 11:07:49 GMTgreenrd<p>
We currently have some tests for parsing in the Test directory. We need test driver code that lets us test pretty-printing as well.
</p>
<p>
It should be enough to test that HSE can parse its own pretty-printed output.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/17#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/208
http://trac.haskell.org/haskell-src-exts/ticket/208#208: Infix data declaration heads do not handle more than two parametersWed, 17 Nov 2010 09:42:10 GMTnibro<p>
The following program incorrectly fails to parse due to the <tt>p</tt> parameter:
</p>
<pre class="wiki">{-# LANGUAGE TypeOperators #-}
module IllDataTypeDeclTest where
data (f :+: g) p = L
</pre>Resultshttp://trac.haskell.org/haskell-src-exts/ticket/208#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/191
http://trac.haskell.org/haskell-src-exts/ticket/191#191: Fixity resolution improvementsSun, 18 Apr 2010 07:53:55 GMTNeilMitchell2<p>
Two related improvements:
</p>
<p>
1) If a parse results in a fixity error it should be reported through <a class="missing wiki" href="http://trac.haskell.org/haskell-src-exts/wiki/ParseError" rel="nofollow">ParseError?</a>, not by raising error.
</p>
<p>
2) The applyFixities function is very limited. A better signature would be:
</p>
<p>
applyFixities :: a -&gt; ([<a class="missing wiki" href="http://trac.haskell.org/haskell-src-exts/wiki/FixityError" rel="nofollow">FixityError?</a>],a)
</p>
<p>
Now when there is a fixity error you get back a list of the errors, and a revised document with as many fixities resolved as possible. This would be particularly useful for HLint: <a class="ext-link" href="http://code.google.com/p/ndmitchell/issues/detail?id=302"><span class="icon">http://code.google.com/p/ndmitchell/issues/detail?id=302</span></a>
</p>
<p>
And more generally, it should suit any user of HSE. With a simple <a class="missing wiki" href="http://trac.haskell.org/haskell-src-exts/wiki/FixityError" rel="nofollow">FixityError?</a> -&gt; <a class="missing wiki" href="http://trac.haskell.org/haskell-src-exts/wiki/ParseError" rel="nofollow">ParseError?</a> function the apply fixities could easily be reused for the main parsing.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/191#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/192
http://trac.haskell.org/haskell-src-exts/ticket/192#192: Incorrect position informationSun, 18 Apr 2010 07:56:39 GMTNeilMitchell2<p>
Given the module:
</p>
<pre class="wiki">foo = x where x = 1
y = 2
</pre><p>
The <a class="missing wiki" href="http://trac.haskell.org/haskell-src-exts/wiki/SrcInfo" rel="nofollow">SrcInfo?</a> on the <a class="missing wiki" href="http://trac.haskell.org/haskell-src-exts/wiki/PatBind" rel="nofollow">PatBind?</a> for foo extends to the very beginning of the y, so srcSpanEndLine = 5, rather than 1.
</p>
<p>
Niklas replied:
</p>
<p>
I can see how that can be problematic, but formally the scope of the where actually extends as far as to the y, where the implicit } is located. That said, I can't think of a situation where that behavior is actually what you want. So I guess misfeature, rather than bug. I'll have a look at it, but I fear it could be quite hard to get right.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/192#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/194
http://trac.haskell.org/haskell-src-exts/ticket/194#194: Bad parse error messageSat, 26 Jun 2010 10:09:37 GMTNeilMitchell2<pre class="wiki">&gt; :m Language.Haskell.Exts
Prelude Language.Haskell.Exts&gt; parseFileContents "data A = B {c :: D}}"
Loading package haskell-src-exts-1.9.0 ... linking ... done.
*** Exception: Internal error: empty context in popContext
</pre><p>
This parse error is very bad, and confuses users a lot!
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/194#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/195
http://trac.haskell.org/haskell-src-exts/ticket/195#195: Fails to parse (#*) operator with UnboxedTuples extension turned onSat, 14 Aug 2010 20:20:37 GMTNeilMitchell2<p>
Consider:
</p>
<pre class="wiki">{-# LANGUAGE UnboxedTuples, MagicHash #-}
(#*:) :: a
(#*:) = undefined
</pre><p>
GHC parses this just fine (as an operator), but HSE gets it wrong trying to treat it as an unboxed tuple. This bug was found by an HLint user: <a class="ext-link" href="http://code.google.com/p/ndmitchell/issues/detail?id=329"><span class="icon">http://code.google.com/p/ndmitchell/issues/detail?id=329</span></a>
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/195#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/196
http://trac.haskell.org/haskell-src-exts/ticket/196#196: Off by one line numbersSun, 15 Aug 2010 07:42:17 GMTNeilMitchell2<pre class="wiki">parseFileContents "{-# LINE 1 \"foo\" #-}\n\na=1"
</pre><p>
This puts the "a=1" bit on line 3, where it should be on line 2.
</p>
<p>
I think there may be two bugs in this area - I was trying to debug <a class="ext-link" href="http://code.google.com/p/ndmitchell/issues/detail?id=331"><span class="icon">http://code.google.com/p/ndmitchell/issues/detail?id=331</span></a> and it kept behaving strangely. Once this bug is fixed then I may have another one for you.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/196#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/197
http://trac.haskell.org/haskell-src-exts/ticket/197#197: Fixities in ParseMode.fixities should be qualifiedThu, 09 Sep 2010 05:33:40 GMTreinerp<p>
Consider parsing the expression
</p>
<pre class="wiki">(a P.+ b P.+ c, a Q.+ b Q.+ c)
</pre><p>
Since P.+ and Q.+ come from different modules, they could have different fixities. There seems to be no way to make HSE aware of this. It seems that the Fixity data type should contain a QOp rather than an Op.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/197#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/198
http://trac.haskell.org/haskell-src-exts/ticket/198#198: PrettyPrint does not include whereTue, 21 Sep 2010 16:21:15 GMTNeilMitchell2<pre class="wiki">Prelude Language.Haskell.Exts.Annotated&gt; prettyPrint $ fromParseResult $ parseFileContents "f = 1 where"
"f = 1"
</pre><p>
I would have expected "f = 1 where", with whatever layout you may care for.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/198#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/206
http://trac.haskell.org/haskell-src-exts/ticket/206#206: Parse error leads to exception with UnboxedTuplesFri, 12 Nov 2010 13:59:54 GMTNeilMitchell<p>
Parse error and then an exception thrown while pretty printing the parse error! All on HSE 1.9.4.
</p>
<pre class="wiki">Language.Haskell.Exts&gt; parseDeclWithMode defaultParseMode{extensions=[UnboxedTuples]} "(##) :: m"
ParseFailed (SrcLoc {srcFilename = "&lt;unknown&gt;.hs", srcLine = 1, srcColumn = 10}) "Left-hand side of type signature is not a variable: *** Exception: src\Language\Haskell\Exts\Pretty.hs:(1089,0)-(1094,21): Non-exhaustive patterns in function specialName
</pre>Resultshttp://trac.haskell.org/haskell-src-exts/ticket/206#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/207
http://trac.haskell.org/haskell-src-exts/ticket/207#207: Fixity resolution incorrectly handles shadowed operatorsTue, 16 Nov 2010 23:16:13 GMTbenmachine<p>
When an operator name is shadowed, haskell-src-exts continues to use the fixity from the outer scope. This is obviously wrong when the operator carries its own fixity declaration (I think this is merely a problem of adding the new fixities to the front of the list rather than the back) but in fact shadowing an operator without a fixity declaration should reset it to infixl 9 - so we have the somewhat trickier problem of detecting when <i>any</i> new operator names are introduced that might shadow an outer definition. In the extreme case with TH or a quasiquoter this is actually impossible, I think, but it would still be nice to respect the (admittedly quite rare) case of an operator name defined inline.
</p>
<p>
An example of where this would go wrong is the following definition that lambdabot gives for <tt>on</tt>:
</p>
<pre class="wiki">(*) `on` f = \x y -&gt; f x * f y
</pre><p>
In the RHS here, HSE would give <tt>*</tt> fixity 7, when it should really have fixity 9. In this case it wouldn't make a difference, but it's not hard to construct cases where it would.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/207#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/210
http://trac.haskell.org/haskell-src-exts/ticket/210#210: Parse errors when TransformListComp extension is enabledSat, 15 Jan 2011 01:49:30 GMTiago<p>
I'm experiencing many strange parse errors when parsing with all extensions enabled:
</p>
<p>
Parse error: l-i<br />
Parse error: m-n<br />
Parse error in expression: off_b +<br />
Parse error: group<br />
...
</p>
<p>
I know the code is fine because it actually compiles, the only thing I do before parse these files with haskell-src-exts is to run cpphs --noline over them, the output of cpphs is what I'm parsing.
</p>
<p>
I was able to isolate one of these faults (I could take a look on others if that helps):
</p>
<p>
The following module
</p>
<pre class="wiki">Prelude Language.Haskell.Exts&gt; f
"module Bar where\n\nimport Data.List ( group )\n\n"
</pre><p>
is not correctly parsed when all known extensions are activated
</p>
<pre class="wiki">Prelude Language.Haskell.Exts&gt; parseModuleWithMode (defaultParseMode{extensions=knownExtensions}) f
ParseFailed (SrcLoc {srcFilename = "&lt;unknown&gt;.hs", srcLine = 3, srcColumn = 20}) "Parse error: group"
</pre><p>
but parsing without any extension enabled works
</p>
<pre class="wiki">Prelude Language.Haskell.Exts&gt; parseModule f
ParseOk (Module (SrcLoc {srcFilename = "&lt;unknown&gt;.hs", srcLine = 1, srcColumn = 1}) (ModuleName "Bar") [] Nothing Nothing [ImportDecl {importLoc = SrcLoc {srcFilename = "&lt;unknown&gt;.hs", srcLine = 3, srcColumn = 1}, importModule = ModuleName "Data.List", importQualified = False, importSrc = False, importPkg = Nothing, importAs = Nothing, importSpecs = Just (False,[IVar (Ident "group")])}] [])
</pre><p>
Note: The exact version is the 1.10.1.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/210#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/211
http://trac.haskell.org/haskell-src-exts/ticket/211#211: Unable to parse strict annotations when used in a GADTSun, 16 Jan 2011 12:55:28 GMTiago<p>
haskell-src-exts is unable to parse the following module
</p>
<pre class="wiki">module Bar where
data Foo a where
Foo :: !a -&gt; Foo a
</pre><p>
but it is able to parse this
</p>
<pre class="wiki">module Bar where
data Foo a = Foo !a (Foo a)
</pre><p>
or this one
</p>
<pre class="wiki">module Bar where
data Foo a where
Foo :: a -&gt; Foo a
</pre>Resultshttp://trac.haskell.org/haskell-src-exts/ticket/211#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/212
http://trac.haskell.org/haskell-src-exts/ticket/212#212: Parse errors with family keywordSun, 23 Jan 2011 14:07:37 GMTNeilMitchell2<p>
Parsing the following fragments with <tt>import Language.Haskell.Exts; parseFile "Test.hs"</tt>, I get the results:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies #-}
f family = undefined
-- ParseFailed (SrcLoc {srcFilename = "Test.hs", srcLine = 2, srcColumn = 3}) "TemplateHaskell is not enabled"
</pre><pre class="wiki">{-# LANGUAGE TypeFamilies, TemplateHaskell #-}
f family = undefined
-- ParseFailed (SrcLoc {srcFilename = "Test.hs", srcLine = 2, srcColumn = 3}) "Parse error: family"
</pre><p>
Both these fragments are accepted by GHC. The <a class="missing wiki" href="http://trac.haskell.org/haskell-src-exts/wiki/TemplateHaskell" rel="nofollow">TemplateHaskell?</a> suggestion in the first case is not very good. This issue is based on a bug report against HLint, <a class="ext-link" href="http://code.google.com/p/ndmitchell/issues/detail?id=402"><span class="icon">http://code.google.com/p/ndmitchell/issues/detail?id=402</span></a> , and all results were under 1.10.1.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/212#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/213
http://trac.haskell.org/haskell-src-exts/ticket/213#213: Parse difference from GHC on bracketed instance headsSun, 13 Mar 2011 12:57:00 GMTNeilMitchell<p>
module A where
instance (Bounded a =&gt; Bounded [a]) where
</p>
<p>
This parses in GHC, but not in HSE. Originally reported by Eric Kow against derive, but would also effect hlint etc. It's possible GHC is in error here (I don't know the report parsing rules well enough), so this might need raising against GHC.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/213#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/214
http://trac.haskell.org/haskell-src-exts/ticket/214#214: Parse error on quasi quotesFri, 22 Apr 2011 11:16:44 GMTNeilMitchell<pre class="wiki">Prelude Language.Haskell.Exts.Annotated&gt; fmap (const ()) $ fromParseResult $ par
seFileContents "{-# LANGUAGE QuasiQuotes #-}\nfoo = [$q| a b]"
*** Exception: fromParseResult: Parse failed at [&lt;unknown&gt;.hs] (2:7): Unexpected
end of input while lexing quasi-quoter
</pre><p>
Reported by an HLint user as: <a class="ext-link" href="http://code.google.com/p/ndmitchell/issues/detail?id=424"><span class="icon">http://code.google.com/p/ndmitchell/issues/detail?id=424</span></a>
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/214#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/215
http://trac.haskell.org/haskell-src-exts/ticket/215#215: Support DoAndIfThenElse, part of Haskell 2010Sun, 05 Jun 2011 13:57:31 GMTNeilMitchell<p>
GHC 7.0 and Haskell 2010 both support the <a class="missing wiki" href="http://trac.haskell.org/haskell-src-exts/wiki/DoAndIfThenElse" rel="nofollow">DoAndIfThenElse?</a> extension, which allows:
</p>
<pre class="wiki">main = do
if True then print 0
else print 1
</pre><p>
It would be nice if haskell-src-exts did too.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/215#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/216
http://trac.haskell.org/haskell-src-exts/ticket/216#216: Indentation handled differently to GHCFri, 15 Jul 2011 17:59:56 GMTNeilMitchell2<p>
The following program works under GHC:
</p>
<pre class="wiki">main = f where
f = g where
g = putStrLn "hello world"
</pre><p>
But under HLint (and thus haskell-src-exts) gives:
</p>
<p>
Patch.hs:5:1: Parse error
Error message:
</p>
<blockquote>
<p>
Parse error: ;
</p>
</blockquote>
<p>
Also tracked as: <a class="ext-link" href="http://code.google.com/p/ndmitchell/issues/detail?id=442"><span class="icon">http://code.google.com/p/ndmitchell/issues/detail?id=442</span></a>
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/216#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/217
http://trac.haskell.org/haskell-src-exts/ticket/217#217: Arity mismatch errors have bad source positionTue, 13 Sep 2011 13:43:42 GMTNeilMitchell<p>
Given the file:
</p>
<pre class="wiki">foo a b = 1
foo a = 2
bar = 1
baz = 2
...
</pre><p>
The error about foo's arity will be reported at the very end of the file, not where foo occurs.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/217#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/218
http://trac.haskell.org/haskell-src-exts/ticket/218#218: Parse error on forallWed, 30 Nov 2011 20:28:12 GMTNeilMitchell<p>
As reported by an HLint user in <a class="ext-link" href="http://code.google.com/p/ndmitchell/issues/detail?id=504"><span class="icon">http://code.google.com/p/ndmitchell/issues/detail?id=504</span></a>, HSE can't deal with the \forall symbol. The following gives a parse error.
</p>
<pre class="wiki">{-# LANGUAGE UnicodeSyntax, ExplicitForAll #-}
module UniTest2 where
id1 ∷ ∀ a . a → a
id1 x = x
</pre>Resultshttp://trac.haskell.org/haskell-src-exts/ticket/218#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/219
http://trac.haskell.org/haskell-src-exts/ticket/219#219: Parse error on template haskell type splice with $Sat, 10 Dec 2011 21:10:44 GMTNeilMitchell<p>
The following code parses with GHC, but gives a parse error with HSE:
</p>
<pre class="wiki">{-# LANGUAGE TemplateHaskell #-}
unit x = [t| $x |]
</pre><p>
Reported in HLint and tracked as bug 514: <a class="ext-link" href="http://code.google.com/p/ndmitchell/issues/detail?id=514"><span class="icon">http://code.google.com/p/ndmitchell/issues/detail?id=514</span></a>
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/219#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/220
http://trac.haskell.org/haskell-src-exts/ticket/220#220: Parse error when TypeFamilies and ConstraintKinds collideMon, 09 Apr 2012 08:54:52 GMTNeilMitchell<p>
An HLint user reported: <a class="ext-link" href="http://code.google.com/p/ndmitchell/issues/detail?id=543"><span class="icon">http://code.google.com/p/ndmitchell/issues/detail?id=543</span></a>
</p>
<pre class="wiki">» cat ParseError.hs {-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE ConstraintKinds #-}
class Foo a where type Bar a
type Bazable a b = (Bar a ~ Maybe b)
baz :: Bazable a b =&gt; a -&gt; a
baz = id
</pre><p>
Gives: Parse error in type: Bar a ~ Maybe b
</p>
<p>
The failure only occurs when I have a <tt>~</tt> constraint in a constraint kind. ~ constraints normally work, and constraint kinds normally work, but together HSE explodes.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/220#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/221
http://trac.haskell.org/haskell-src-exts/ticket/221#221: Parse error with forall in classWed, 18 Apr 2012 14:55:10 GMTNeilMitchell<p>
The following code parses fine with GHC, but not HSE 1.13.2
</p>
<pre class="wiki">{-# LANGUAGE ScopedTypeVariables #-}
instance forall a. MyClass a =&gt; MyClass [a] where
</pre><p>
It gives the error:
</p>
<pre class="wiki">Illegal instance declaration
</pre><p>
Originally reported as a bug in HLint, <a class="ext-link" href="http://code.google.com/p/ndmitchell/issues/detail?id=544"><span class="icon">http://code.google.com/p/ndmitchell/issues/detail?id=544</span></a>
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/221#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/222
http://trac.haskell.org/haskell-src-exts/ticket/222#222: Poor parse error messageThu, 19 Apr 2012 15:24:25 GMTNeilMitchell<p>
The following snippet
</p>
<pre class="wiki">main = print $ "hello" ++ "world
-- any random junk that goes here gets added onto the character count
-- and the quote ends it with some garbage " module
</pre><p>
Gives:
</p>
<p>
Sample.hs:1:141: Parse error: module
</p>
<p>
The character count is crazy (there is no character 141 on the first line). In addition if I remove the module then it passes the parser, but GHC fails on it.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/222#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/223
http://trac.haskell.org/haskell-src-exts/ticket/223#223: Error message for RecordWildCards has incorrect columnFri, 24 Aug 2012 10:15:02 GMTNeilMitchell<p>
Given the source:
</p>
<pre class="wiki">foo Record{..} = xs
</pre><p>
The error message is:
</p>
<pre class="wiki">Sample.hs:2:14: Parse error, RecordWildCards is not enabled
</pre><p>
However, the .. goes from column 12 to 14, so column 12 would be a much better position for the error message. This shows up more visibly if you have an editor which is parsing on the fly and drawing red underlines.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/223#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/224
http://trac.haskell.org/haskell-src-exts/ticket/224#224: Parse error on type equality constraintsWed, 09 Jan 2013 18:56:50 GMTNeilMitchell<p>
See <a class="ext-link" href="http://code.google.com/p/ndmitchell/issues/detail?id=584"><span class="icon">http://code.google.com/p/ndmitchell/issues/detail?id=584</span></a>:
</p>
<pre class="wiki">type MyAddDb m = (MonadBaseControl IO m, MonadIO m, MonadLogger m, Functor m, PersistUnique m, PersistMonadBackend m ~ SqlBackend)
</pre>Resultshttp://trac.haskell.org/haskell-src-exts/ticket/224#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/225
http://trac.haskell.org/haskell-src-exts/ticket/225#225: Package uses the deprecated flag -fglasgow-extsMon, 04 Mar 2013 14:38:53 GMTNeilMitchell<p>
What steps will reproduce the problem?
1. cabal update
2. cabal install haskell-src-exts
</p>
<p>
What is the expected output? What do you see instead?
Expected: No installation errors
Instead: dist/build/Language/Haskell/Exts/InternalParser.hs:1:12:
</p>
<blockquote>
<p>
Warning: -fglasgow-exts is deprecated: Use individual extensions instead
</p>
</blockquote>
<p>
[ 1 of 22] Compiling Language.Haskell.Exts.Annotated.Syntax ( src/Language/Haskell/Exts/Annotated/Syntax.hs, dist/build/Language/Haskell/Exts/Annotated/Syntax.o )
</p>
<p>
As originally reported against HLint, see <a class="ext-link" href="http://code.google.com/p/ndmitchell/issues/detail?id=591"><span class="icon">http://code.google.com/p/ndmitchell/issues/detail?id=591</span></a>
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/225#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/226
http://trac.haskell.org/haskell-src-exts/ticket/226#226: Support for type level stringsWed, 10 Apr 2013 17:42:21 GMTNeilMitchell<p>
As per <a class="ext-link" href="https://code.google.com/p/ndmitchell/issues/detail?id=596"><span class="icon">https://code.google.com/p/ndmitchell/issues/detail?id=596</span></a>, it seems haskell-src-exts doesn't support type level strings.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/226#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/227
http://trac.haskell.org/haskell-src-exts/ticket/227#227: LambdaCase and MultiWayIf extensionsSat, 22 Jun 2013 20:22:29 GMTNeilMitchell<p>
From <a class="ext-link" href="https://code.google.com/p/ndmitchell/issues/detail?id=611"><span class="icon">https://code.google.com/p/ndmitchell/issues/detail?id=611</span></a> I got:
</p>
<p>
The <a class="missing wiki" href="http://trac.haskell.org/haskell-src-exts/wiki/LambdaCase" rel="nofollow">LambdaCase?</a> and <a class="missing wiki" href="http://trac.haskell.org/haskell-src-exts/wiki/MultiWayIf" rel="nofollow">MultiWayIf?</a> extensions, which became standard in GHC 7.6, don't seem to be recognized by HLlint, causing it to fail with a 'Parse error'.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/227#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/21
http://trac.haskell.org/haskell-src-exts/ticket/21#21: Missing support for the new qualified operator syntaxSun, 07 Jun 2009 12:30:07 GMTnibro<p>
Haskell' (whatever form it will come in) will likely have a different form of qualified operator syntax from Haskell98.
</p>
<pre class="wiki"> add x y = Prelude.(+) x y
subtract y = (`Prelude.(-)` y)
</pre><p>
Not that it matters, but I find this new syntax far preferable to Haskell98.
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#new-qualified-operators"><span class="icon">http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#new-qualified-operators</span></a>
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/21#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/24
http://trac.haskell.org/haskell-src-exts/ticket/24#24: Missing support for extensible record syntaxSun, 07 Jun 2009 12:39:36 GMTnibro<p>
Hugs has an extension called TRex, allowing extensible records. This introduces plenty new syntax, which would be nice to support.
</p>
<p>
<a class="ext-link" href="http://cvs.haskell.org/Hugs/pages/hugsman/exts.html#sect7.2"><span class="icon">http://cvs.haskell.org/Hugs/pages/hugsman/exts.html#sect7.2</span></a>
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/24#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/25
http://trac.haskell.org/haskell-src-exts/ticket/25#25: No support for restricted type synonymsSun, 07 Jun 2009 12:42:07 GMTnibro<p>
Hugs has an extension that lets a programmer restrict the scope of a defined type synonym. This is rather useless since the module system does it a lot better.
</p>
<pre class="wiki">type Table a b = [(a,b)] in
empty :: Table a b,
isEmpty :: Table a b -&gt; Bool,
add :: a -&gt; b -&gt; Table a b -&gt; Table a b,
search :: a -&gt; Table a b -&gt; Maybe b
empty = []
isEmpty = null
add a b t = (a,b):t
search = lookup
</pre><p>
Still, it's a registered extension and HSE should be able to support it without too much hassle.
</p>
<p>
<a class="ext-link" href="http://cvs.haskell.org/Hugs/pages/users_guide/restricted-synonyms.html"><span class="icon">http://cvs.haskell.org/Hugs/pages/users_guide/restricted-synonyms.html</span></a>
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/25#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/26
http://trac.haskell.org/haskell-src-exts/ticket/26#26: No support for HereDocumentsSun, 07 Jun 2009 12:46:10 GMTnibro<p>
Hugs allows a special way to write string literals with spliced variables in the middle:
</p>
<pre class="wiki">letter name = ``Dear $(name),
Here are some characters: \ ' ` ".
To learn more, send $$10 to the address below.''
</pre><p>
This would be quite tricky to support, both since it puts the layout rule temporarily out of it, but perhaps mostly due to the splices. A middle ground could be to simply ignore the splices and lex it all as a special form of string.
</p>
<p>
<a class="ext-link" href="http://cvs.haskell.org/Hugs/pages/users_guide/here-documents.html"><span class="icon">http://cvs.haskell.org/Hugs/pages/users_guide/here-documents.html</span></a>
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/26#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/27
http://trac.haskell.org/haskell-src-exts/ticket/27#27: No handling of CPP in codeSun, 07 Jun 2009 13:14:27 GMTnibro<p>
The hard part here is not to handle documents with CPP in them, we already use cpphs to un-literate code, it shouldn't be hard to run cpphs on it in full. But the question then is, is that really what we want to do? If we want to parse the source file, it would be interesting to be able to support <i>all possible</i> source trees that could result from application of CPP. That's a very different beast.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/27#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/50
http://trac.haskell.org/haskell-src-exts/ticket/50#50: please reject unhandled LANGUAGE pragmasTue, 23 Jun 2009 10:53:36 GMTganesh<p>
If a LANGUAGE pragma is unrecognised, I think it should be treated as a parse error. This would make it very clear what is going wrong with a file that requires that extension.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/50#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/54
http://trac.haskell.org/haskell-src-exts/ticket/54#54: Allow declaration of free variables (for functional logic programming)Tue, 07 Jul 2009 21:02:32 GMTholgersiegel74@…<p>
The functional logic language Curry (<a class="ext-link" href="http://curry-language.org/"><span class="icon">http://curry-language.org/</span></a>) has a syntax that is very similar to Haskell's. The major difference is that Curry allows one to declare free variables, like in
</p>
<pre class="wiki">foo = let x, y free in [x, y, n+z]
where n = 3
z free
</pre><p>
Supporting this syntax requires only small changes in haskell-src-exts: mainly a new language extension FreeVariables and a new constructor FreeDecl:
</p>
<pre class="wiki">data Extension
= ...
| FreeVariables
...
data Decl
= ...
| FreeDecl SrcLoc [Name]
...
</pre><p>
This would make it very easy to manipulate Curry source code in Haskell. (At the moment I'm thinking about patching haskell-source-exts for myself, but to have this modification in the official version would be a much cleaner solution)
</p>
<p>
The drawback is that this extension is not part of the language Haskell, so that the declarations in Language.Haskell.Exts.Extension will differ from those in Cabal's Language.Haskell.Extension module. (A simple workaround might be to abuse (UnknownExtension "FreeVariables") for this.)
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/54#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/190
http://trac.haskell.org/haskell-src-exts/ticket/190#190: Bad error message with misplaced }Wed, 24 Mar 2010 12:49:18 GMTnibro<pre class="wiki">module M (foo} where foo = 1
</pre><p>
The error message is not really user friendly:
</p>
<pre class="wiki">Internal error: empty context in lexStdToken
</pre>Resultshttp://trac.haskell.org/haskell-src-exts/ticket/190#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/199
http://trac.haskell.org/haskell-src-exts/ticket/199#199: failure to parse strict field in GADT style type declarationSat, 09 Oct 2010 20:14:03 GMTganesh<p>
This file parses fine in ghc:
</p>
<pre class="wiki">{-# LANGUAGE GADTs #-}
module Foo where
data X where
X :: !Int -&gt; X
</pre><p>
HSE (e.g. via hlint) fails to parse it with:
</p>
<pre class="wiki">Foo.hs:5:8: Parse error
Error message:
Parse error: !
Code:
data X where
&gt; X :: !Int -&gt; X
</pre><p>
This is with version 1.9.4 but that's not an available version.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/199#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/200
http://trac.haskell.org/haskell-src-exts/ticket/200#200: Missing support for record syntax in GADT declarationsSun, 10 Oct 2010 16:09:00 GMTganesh<p>
This code is supported by GHC 6.12 and up, but not by HSE:
</p>
<pre class="wiki">{-# LANGUAGE GADTs #-}
data Foo where
Foo :: { x :: Int } -&gt; Foo
</pre><p>
There's also an old-style syntax which would also be nice to have because darcs (which I'm currently trying to push through HSE) still supports GHC 6.10
</p>
<pre class="wiki">{-# LANGUAGE GADTs #-}
data Foo where
Foo { x :: Int } :: Foo
</pre>Resultshttp://trac.haskell.org/haskell-src-exts/ticket/200#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/201
http://trac.haskell.org/haskell-src-exts/ticket/201#201: Unicode character literalsSun, 10 Oct 2010 16:11:48 GMTganesh<pre class="wiki">c = '\x10ffff'
</pre><p>
provokes "Character constant out of range", whereas GHC is fine with it.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/201#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/202
http://trac.haskell.org/haskell-src-exts/ticket/202#202: MultiParamTypeClasses shouldn't be required for using themSun, 10 Oct 2010 16:13:39 GMTganesh<p>
In GHC, this code doesn't require <a class="missing wiki" href="http://trac.haskell.org/haskell-src-exts/wiki/MultiParamTypeClasses" rel="nofollow">MultiParamTypeClasses?</a> to be turned on, but HSE insists on it:
</p>
<pre class="wiki">foo :: MonadError e m =&gt; m ()
foo = fail "foo"
</pre>Resultshttp://trac.haskell.org/haskell-src-exts/ticket/202#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/209
http://trac.haskell.org/haskell-src-exts/ticket/209#209: Negative pattern parsingMon, 10 Jan 2011 04:23:26 GMTbenmachine<p>
One of the constructors for the <tt>Pat</tt> type is <tt>PNeg Pat</tt>, for negated patterns. But not only is the <tt>Pat</tt> field here way too general (since <tt>-n</tt> or <tt>-(x:xs)</tt> are not valid patterns), the only circumstances in which it *is* actually valid seem to be negated literals, which are either quite capable of storing that information in their literal, or quite inappropriate to be negated (and so should be an error). Notice that <tt>-1##</tt> is a <i>parse</i> error in GHC since word literals must be <i>non-negative</i> integers.
</p>
<p>
So there's firstly an arguable bug in that <tt>parsePat "-'a'"</tt> succeeds, producing <tt>ParseOk (PNeg (PLit (Char 'a')))</tt> which is nonsense, but there's also a wider question of whether we need <tt>PNeg</tt> at all, or whether we can drop it in favour of negation inside the literals. <tt>NegApp</tt> is clearly necessary on expressions, but there's no analogous negation of variables or compound constructions in patterns.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/209#changeloghttp://trac.haskell.org/haskell-src-exts/ticket/59
http://trac.haskell.org/haskell-src-exts/ticket/59#59: cabal install doesn't get happySat, 08 Aug 2009 17:39:41 GMTNeil Mitchell<p>
haskell-src-exts has an implicit dependency on happy for the parser. If happy isn't already installed then cabal install haskell-src-exts doesn't work, it would be great if this could be fixed. This problem has shown up for real users trying to install both derive and hlint - failing when installing haskell-src-exts because of the lack of happy.
</p>
<p>
Not sure how you fix this with Cabal, but someone on the cabal list might know.
</p>
Resultshttp://trac.haskell.org/haskell-src-exts/ticket/59#changelog