__color__	__group__	ticket	summary	component	version	milestone	type	owner	status	created	_changetime	_description	_reporter
3	Active Tickets	191	Fixity resolution improvements	other	1.8.x		bug report	nibro	new	2010-04-18T08:53:55Z+0100	2010-04-18T08:54:24Z+0100	"Two related improvements:

1) If a parse results in a fixity error it should be reported through ParseError, not by raising error.

2) The applyFixities function is very limited. A better signature would be:

applyFixities :: a -> ([FixityError],a)

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: http://code.google.com/p/ndmitchell/issues/detail?id=302

And more generally, it should suit any user of HSE. With a simple FixityError -> ParseError function the apply fixities could easily be reused for the main parsing.
"	NeilMitchell2
2	Active Tickets	208	Infix data declaration heads do not handle more than two parameters	parser	1.9.x		bug report	nibro	new	2010-11-17T09:42:10Z+0000	2010-11-17T09:43:34Z+0000	"The following program incorrectly fails to parse due to the {{{p}}} parameter:
{{{
{-# LANGUAGE TypeOperators #-}
module IllDataTypeDeclTest where
  
data (f :+: g) p = L
}}}"	nibro
3	Active Tickets	192	Incorrect position information	parser	1.8.x		bug report	nibro	new	2010-04-18T08:56:39Z+0100	2010-04-18T08:56:39Z+0100	"Given the module:

{{{ 
foo = x where x = 1
 
 
 
y = 2
}}}
 
The SrcInfo on the PatBind for foo extends to the very beginning of the y, so srcSpanEndLine = 5, rather than 1.

Niklas replied:

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.
"	NeilMitchell2
3	Active Tickets	194	Bad parse error message	parser	1.8.x		bug report	nibro	new	2010-06-26T11:09:37Z+0100	2010-06-26T11:09:37Z+0100	"{{{
> :m Language.Haskell.Exts
Prelude Language.Haskell.Exts> parseFileContents ""data A = B {c :: D}}""
Loading package haskell-src-exts-1.9.0 ... linking ... done.
*** Exception: Internal error: empty context in popContext
}}}

This parse error is very bad, and confuses users a lot!"	NeilMitchell2
3	Active Tickets	195	Fails to parse (#*) operator with UnboxedTuples extension turned on	parser	1.8.x		bug report	nibro	new	2010-08-14T21:20:37Z+0100	2010-08-14T21:20:37Z+0100	"Consider:

{{{
{-# LANGUAGE UnboxedTuples, MagicHash #-}
(#*:) :: a
(#*:) = undefined
}}}

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: http://code.google.com/p/ndmitchell/issues/detail?id=329"	NeilMitchell2
3	Active Tickets	196	Off by one line numbers	parser	1.8.x		bug report	nibro	new	2010-08-15T08:42:17Z+0100	2010-08-15T08:42:17Z+0100	"{{{
parseFileContents ""{-# LINE 1 \""foo\"" #-}\n\na=1""
}}}

This puts the ""a=1"" bit on line 3, where it should be on line 2.

I think there may be two bugs in this area - I was trying to debug http://code.google.com/p/ndmitchell/issues/detail?id=331 and it kept behaving strangely. Once this bug is fixed then I may have another one for you."	NeilMitchell2
3	Active Tickets	197	Fixities in ParseMode.fixities should be qualified	parser	1.8.x		bug report	nibro	new	2010-09-09T06:33:40Z+0100	2010-09-09T06:33:40Z+0100	"Consider parsing the expression

{{{
(a P.+ b P.+ c, a Q.+ b Q.+ c)
}}}

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."	reinerp
3	Active Tickets	205	MagicHash and trailing # causing a parse error	parser	1.8.x		bug report	nibro	new	2010-11-12T13:38:32Z+0000	2010-11-12T13:55:38Z+0000	"Given {{{int :: Int#}}} that fails to parse, but if I add a space at the end it passes.

{{{
Language.Haskell.Exts> parseDeclWithMode defaultParseMode{extensions=[MagicHash]} ""int :: Int#""
ParseFailed (SrcLoc {srcFilename = ""<unknown>.hs"", srcLine = 1, srcColumn = 12})
 ""Parse error: EOF""
Language.Haskell.Exts> parseDeclWithMode defaultParseMode{extensions=[MagicHash]} ""int :: Int# ""
ParseOk (TypeSig (SrcLoc {srcFilename = ""<unknown>.hs"", srcLine = 1, srcColumn =
 1}) [Ident ""int""] (TyCon (UnQual (Ident ""Int#""))))
}}}
"	NeilMitchell
3	Active Tickets	206	Parse error leads to exception with UnboxedTuples	parser	1.8.x		bug report	nibro	new	2010-11-12T13:59:54Z+0000	2010-11-12T13:59:54Z+0000	"Parse error and then an exception thrown while pretty printing the parse error! All on HSE 1.9.4.

{{{
Language.Haskell.Exts> parseDeclWithMode defaultParseMode{extensions=[UnboxedTuples]} ""(##) :: m""
ParseFailed (SrcLoc {srcFilename = ""<unknown>.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
}}}
"	NeilMitchell
3	Active Tickets	207	Fixity resolution incorrectly handles shadowed operators	parser	1.9.x		bug report	nibro	new	2010-11-16T23:16:13Z+0000	2010-11-17T09:36:24Z+0000	"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 ''any'' 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.

An example of where this would go wrong is the following definition that lambdabot gives for `on`:

{{{
(*) `on` f = \x y -> f x * f y
}}}

In the RHS here, HSE would give `*` 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."	benmachine
3	Active Tickets	210	Parse errors when TransformListComp extension is enabled	parser	1.10.0		bug report	nibro	new	2011-01-15T01:49:30Z+0000	2011-01-16T12:50:30Z+0000	"I'm experiencing many strange parse errors when parsing with all extensions enabled:

Parse error: l-i[[BR]]
Parse error: m-n[[BR]]
Parse error in expression: off_b +[[BR]]
Parse error: group[[BR]]
...

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.

I was able to isolate one of these faults (I could take a look on others if that helps):

The following module
{{{
Prelude Language.Haskell.Exts> f
""module Bar where\n\nimport Data.List ( group )\n\n""
}}}
is not correctly parsed when all known extensions are activated
{{{
Prelude Language.Haskell.Exts> parseModuleWithMode (defaultParseMode{extensions=knownExtensions}) f
ParseFailed (SrcLoc {srcFilename = ""<unknown>.hs"", srcLine = 3, srcColumn = 20}) ""Parse error: group""
}}}
but parsing without any extension enabled works
{{{
Prelude Language.Haskell.Exts> parseModule f
ParseOk (Module (SrcLoc {srcFilename = ""<unknown>.hs"", srcLine = 1, srcColumn = 1}) (ModuleName ""Bar"") [] Nothing Nothing [ImportDecl {importLoc = SrcLoc {srcFilename = ""<unknown>.hs"", srcLine = 3, srcColumn = 1}, importModule = ModuleName ""Data.List"", importQualified = False, importSrc = False, importPkg = Nothing, importAs = Nothing, importSpecs = Just (False,[IVar (Ident ""group"")])}] [])
}}}

Note: The exact version is the 1.10.1."	iago
3	Active Tickets	211	Unable to parse strict annotations when used in a GADT	parser	1.10.0		bug report	nibro	new	2011-01-16T12:55:28Z+0000	2011-01-16T12:55:28Z+0000	"haskell-src-exts is unable to parse the following module
{{{
module Bar where

data Foo a where
    Foo :: !a -> Foo a
}}}
but it is able to parse this 
{{{
module Bar where

data Foo a = Foo !a (Foo a)
}}}
or this one
{{{
module Bar where

data Foo a where
    Foo :: a -> Foo a
}}}"	iago
3	Active Tickets	212	Parse errors with family keyword	parser			bug report	nibro	new	2011-01-23T14:07:37Z+0000	2011-01-23T14:07:56Z+0000	"Parsing the following fragments with {{{import Language.Haskell.Exts; parseFile ""Test.hs""}}}, I get the results:

{{{
{-# LANGUAGE TypeFamilies #-}
f family = undefined
-- ParseFailed (SrcLoc {srcFilename = ""Test.hs"", srcLine = 2, srcColumn = 3}) ""TemplateHaskell is not enabled""
}}}

{{{
{-# LANGUAGE TypeFamilies, TemplateHaskell #-}
f family = undefined
-- ParseFailed (SrcLoc {srcFilename = ""Test.hs"", srcLine = 2, srcColumn = 3}) ""Parse error: family""
}}}

Both these fragments are accepted by GHC. The TemplateHaskell suggestion in the first case is not very good. This issue is based on a bug report against HLint, http://code.google.com/p/ndmitchell/issues/detail?id=402 , and all results were under 1.10.1."	NeilMitchell2
3	Active Tickets	213	Parse difference from GHC on bracketed instance heads	parser	1.10.0		bug report	nibro	new	2011-03-13T12:57:00Z+0000	2011-03-13T12:57:00Z+0000	"module A where
instance (Bounded a => Bounded [a]) where

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."	NeilMitchell
3	Active Tickets	214	Parse error on quasi quotes	parser	1.10.0		bug report	nibro	new	2011-04-22T12:16:44Z+0100	2011-09-14T20:49:55Z+0100	"{{{
Prelude Language.Haskell.Exts.Annotated> fmap (const ()) $ fromParseResult $ par
seFileContents ""{-# LANGUAGE QuasiQuotes #-}\nfoo = [$q| a b]""
*** Exception: fromParseResult: Parse failed at [<unknown>.hs] (2:7): Unexpected
 end of input while lexing quasi-quoter
}}}

Reported by an HLint user as: http://code.google.com/p/ndmitchell/issues/detail?id=424"	NeilMitchell
3	Active Tickets	215	Support DoAndIfThenElse, part of Haskell 2010	parser			bug report	nibro	new	2011-06-05T14:57:31Z+0100	2011-08-09T16:58:12Z+0100	"GHC 7.0 and Haskell 2010 both support the DoAndIfThenElse extension, which allows:

{{{
main = do
    if True then print 0
    else print 1
}}}

It would be nice if haskell-src-exts did too."	NeilMitchell
3	Active Tickets	216	Indentation handled differently to GHC	parser			bug report	nibro	new	2011-07-15T18:59:56Z+0100	2011-07-15T18:59:56Z+0100	"The following program works under GHC:

{{{
main = f where
    f = g where
    g = putStrLn ""hello world""
}}}

But under HLint (and thus haskell-src-exts) gives:

Patch.hs:5:1: Parse error
Error message:
  Parse error: ;

Also tracked as: http://code.google.com/p/ndmitchell/issues/detail?id=442"	NeilMitchell2
3	Active Tickets	217	Arity mismatch errors have bad source position	parser	1.10.0		bug report	nibro	new	2011-09-13T14:43:42Z+0100	2011-09-13T14:43:42Z+0100	"Given the file:

{{{
foo a b = 1
foo a = 2

bar = 1
baz = 2
...
}}}

The error about foo's arity will be reported at the very end of the file, not where foo occurs."	NeilMitchell
3	Active Tickets	218	Parse error on forall	parser			bug report	nibro	new	2011-11-30T20:28:12Z+0000	2011-11-30T20:28:12Z+0000	"As reported by an HLint user in http://code.google.com/p/ndmitchell/issues/detail?id=504, HSE can't deal with the \forall symbol. The following gives a parse error.

{{{
{-# LANGUAGE UnicodeSyntax, ExplicitForAll #-}

module UniTest2 where

id1 ∷ ∀ a . a → a
id1 x = x
}}}
"	NeilMitchell
3	Active Tickets	219	Parse error on template haskell type splice with $	parser			bug report	nibro	new	2011-12-10T21:10:44Z+0000	2012-12-06T10:46:55Z+0000	"The following code parses with GHC, but gives a parse error with HSE:

{{{
{-# LANGUAGE TemplateHaskell #-}
unit x = [t| $x |]
}}}

Reported in HLint and tracked as bug 514: http://code.google.com/p/ndmitchell/issues/detail?id=514"	NeilMitchell
3	Active Tickets	220	Parse error when TypeFamilies and ConstraintKinds collide	parser			bug report	nibro	new	2012-04-09T09:54:52Z+0100	2012-04-09T09:55:49Z+0100	"An HLint user reported: http://code.google.com/p/ndmitchell/issues/detail?id=543

{{{
» 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 => a -> a
baz = id
}}}

Gives: Parse error in type: Bar a ~ Maybe b

The failure only occurs when I have a `~` constraint in a constraint kind. ~ constraints normally work, and constraint kinds normally work, but together HSE explodes."	NeilMitchell
3	Active Tickets	221	Parse error with forall in class	parser			bug report	nibro	new	2012-04-18T15:55:10Z+0100	2012-04-18T15:55:10Z+0100	"The following code parses fine with GHC, but not HSE 1.13.2

{{{
{-# LANGUAGE ScopedTypeVariables #-}
instance forall a. MyClass a => MyClass [a] where
}}}

It gives the error:

{{{
Illegal instance declaration
}}}

Originally reported as a bug in HLint, http://code.google.com/p/ndmitchell/issues/detail?id=544"	NeilMitchell
3	Active Tickets	222	Poor parse error message	parser			bug report	nibro	new	2012-04-19T16:24:25Z+0100	2012-04-19T16:24:25Z+0100	"The following snippet

{{{
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
}}}

Gives:

Sample.hs:1:141: Parse error: module

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."	NeilMitchell
3	Active Tickets	223	Error message for RecordWildCards has incorrect column	parser			bug report	nibro	new	2012-08-24T11:15:02Z+0100	2012-08-24T11:15:02Z+0100	"Given the source:

{{{
foo Record{..} = xs
}}}

The error message is:

{{{
Sample.hs:2:14: Parse error, RecordWildCards is not enabled
}}}

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."	NeilMitchell
3	Active Tickets	224	Parse error on type equality constraints	parser			bug report	nibro	new	2013-01-09T18:56:50Z+0000	2013-01-09T18:56:50Z+0000	"See http://code.google.com/p/ndmitchell/issues/detail?id=584:

{{{
type MyAddDb m = (MonadBaseControl IO m, MonadIO m, MonadLogger m, Functor m, PersistUnique m, PersistMonadBackend m ~ SqlBackend)
}}}"	NeilMitchell
3	Active Tickets	225	Package uses the deprecated flag -fglasgow-exts	parser			bug report	nibro	new	2013-03-04T14:38:53Z+0000	2013-03-04T14:38:53Z+0000	"What steps will reproduce the problem?
1. cabal update
2. cabal install haskell-src-exts

What is the expected output? What do you see instead?
Expected: No installation errors
Instead: dist/build/Language/Haskell/Exts/InternalParser.hs:1:12:
   Warning: -fglasgow-exts is deprecated: Use individual extensions instead
[ 1 of 22] Compiling Language.Haskell.Exts.Annotated.Syntax ( src/Language/Haskell/Exts/Annotated/Syntax.hs, dist/build/Language/Haskell/Exts/Annotated/Syntax.o )

As originally reported against HLint, see http://code.google.com/p/ndmitchell/issues/detail?id=591"	NeilMitchell
3	Active Tickets	226	Support for type level strings	parser			bug report	nibro	new	2013-04-10T18:42:21Z+0100	2013-04-10T18:42:21Z+0100	As per https://code.google.com/p/ndmitchell/issues/detail?id=596, it seems haskell-src-exts doesn't support type level strings.	NeilMitchell
4	Active Tickets	190	Bad error message with misplaced }	parser	1.8.x		bug report	nibro	new	2010-03-24T12:49:18Z+0000	2010-03-24T12:50:31Z+0000	"{{{
module M (foo} where foo = 1
}}}
The error message is not really user friendly:
{{{
Internal error: empty context in lexStdToken
}}}"	nibro
4	Active Tickets	199	failure to parse strict field in GADT style type declaration	parser	1.8.x		bug report	nibro	new	2010-10-09T21:14:03Z+0100	2010-10-09T22:20:52Z+0100	"This file parses fine in ghc:
{{{
{-# LANGUAGE GADTs #-}
module Foo where

data X where
  X :: !Int -> X
}}}
HSE (e.g. via hlint) fails to parse it with:
{{{
Foo.hs:5:8: Parse error
Error message:
  Parse error: !
Code:
    data X where
  >   X :: !Int -> X
}}}

This is with version 1.9.4 but that's not an available version.



"	ganesh
4	Active Tickets	200	Missing support for record syntax in GADT declarations	parser	1.8.x		bug report	nibro	new	2010-10-10T17:09:00Z+0100	2010-10-10T17:09:00Z+0100	"This code is supported by GHC 6.12 and up, but not by HSE:
{{{
{-# LANGUAGE GADTs #-}

data Foo where
  Foo :: { x :: Int } -> Foo
}}}
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
{{{
{-# LANGUAGE GADTs #-}

data Foo where
  Foo { x :: Int } :: Foo
}}}
"	ganesh
4	Active Tickets	201	Unicode character literals	parser	1.8.x		bug report	nibro	new	2010-10-10T17:11:48Z+0100	2010-10-10T17:11:48Z+0100	"{{{
c = '\x10ffff'
}}}

provokes ""Character constant out of range"", whereas GHC is fine with it."	ganesh
4	Active Tickets	202	MultiParamTypeClasses shouldn't be required for using them	parser	1.8.x		bug report	nibro	new	2010-10-10T17:13:39Z+0100	2010-10-10T17:13:39Z+0100	"In GHC, this code doesn't require MultiParamTypeClasses to be turned on, but HSE insists on it:
{{{
foo :: MonadError e m => m ()
foo = fail ""foo""
}}}"	ganesh
4	Active Tickets	21	Missing support for the new qualified operator syntax	parser	1.9.x	Blue Sky	bug report	nibro	new	2009-06-07T13:30:07Z+0100	2010-11-17T09:31:15Z+0000	"Haskell' (whatever form it will come in) will likely have a different form of qualified operator syntax from Haskell98.
{{{
  add x y = Prelude.(+) x y
  subtract y = (`Prelude.(-)` y)
}}}
Not that it matters, but I find this new syntax far preferable to Haskell98.

[http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#new-qualified-operators]"	nibro
4	Active Tickets	24	Missing support for extensible record syntax	parser	1.9.x	Blue Sky	bug report	nibro	new	2009-06-07T13:39:36Z+0100	2010-11-17T09:31:39Z+0000	"Hugs has an extension called TRex, allowing extensible records. This introduces plenty new syntax, which would be nice to support.

[http://cvs.haskell.org/Hugs/pages/hugsman/exts.html#sect7.2]"	nibro
4	Active Tickets	25	No support for restricted type synonyms	parser	1.9.x	Blue Sky	bug report	nibro	new	2009-06-07T13:42:07Z+0100	2010-11-17T09:31:53Z+0000	"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.
{{{
type Table a b = [(a,b)] in
    empty :: Table a b,
    isEmpty :: Table a b -> Bool,
    add :: a -> b -> Table a b -> Table a b,
    search :: a -> Table a b -> Maybe b

empty = []
isEmpty = null
add a b t = (a,b):t
search = lookup
}}}
Still, it's a registered extension and HSE should be able to support it without too much hassle.

[http://cvs.haskell.org/Hugs/pages/users_guide/restricted-synonyms.html]"	nibro
4	Active Tickets	26	No support for HereDocuments	parser	1.9.x	Blue Sky	bug report	nibro	new	2009-06-07T13:46:10Z+0100	2010-11-17T09:32:34Z+0000	"Hugs allows a special way to write string literals with spliced variables in the middle:
{{{
letter name = ``Dear $(name),
Here are some characters: \ ' ` "".
To learn more, send $$10 to the address below.''
}}}
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.

[http://cvs.haskell.org/Hugs/pages/users_guide/here-documents.html] "	nibro
4	Active Tickets	27	No handling of CPP in code	parser	1.9.x	Blue Sky	bug report	nibro	new	2009-06-07T14:14:27Z+0100	2010-11-17T09:33:35Z+0000	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 ''all possible'' source trees that could result from application of CPP. That's a very different beast.	nibro
4	Active Tickets	50	please reject unhandled LANGUAGE pragmas	parser	1.9.x	Blue Sky	feature request	nibro	assigned	2009-06-23T11:53:36Z+0100	2010-11-17T09:35:00Z+0000	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.	ganesh
5	Active Tickets	59	cabal install doesn't get happy	parser	1.9.x	Blue Sky	bug report	nibro	reopened	2009-08-08T18:39:41Z+0100	2010-11-17T09:35:59Z+0000	"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.

Not sure how you fix this with Cabal, but someone on the cabal list might know."	Neil Mitchell
3	Active Tickets	198	PrettyPrint does not include where	prettyprinter	1.8.x		bug report	nibro	new	2010-09-21T17:21:15Z+0100	2010-09-21T17:22:13Z+0100	"{{{
Prelude Language.Haskell.Exts.Annotated> prettyPrint $ fromParseResult $ parseFileContents ""f = 1 where""
""f = 1""
}}}

I would have expected ""f = 1 where"", with whatever layout you may care for."	NeilMitchell2
4	Active Tickets	17	Test driver for pretty-printing	prettyprinter			feature request	greenrd	new	2009-05-26T12:07:49Z+0100	2009-09-04T13:26:25Z+0100	"We currently have some tests for parsing in the Test directory. We need test driver code that lets us test pretty-printing as well.

It should be enough to test that HSE can parse its own pretty-printed output."	greenrd
4	Active Tickets	209	Negative pattern parsing	syntax			bug report	nibro	new	2011-01-10T04:23:26Z+0000	2011-01-10T04:23:26Z+0000	"One of the constructors for the `Pat` type is `PNeg Pat`, for negated patterns. But not only is the `Pat` field here way too general (since `-n` or `-(x:xs)` 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 `-1##` is a ''parse'' error in GHC since word literals must be ''non-negative'' integers.

So there's firstly an arguable bug in that `parsePat ""-'a'""` succeeds, producing `ParseOk (PNeg (PLit (Char 'a')))` which is nonsense, but there's also a wider question of whether we need `PNeg` at all, or whether we can drop it in favour of negation inside the literals. `NegApp` is clearly necessary on expressions, but there's no analogous negation of variables or compound constructions in patterns."	benmachine
4	Active Tickets	54	Allow declaration of free variables (for functional logic programming)	syntax	1.9.x	Blue Sky	feature request	nibro	new	2009-07-07T22:02:32Z+0100	2010-11-17T09:35:35Z+0000	"The functional logic language Curry ([http://curry-language.org/]) has a syntax that is very similar to Haskell's. The major difference is that Curry allows one to declare free variables, like in
{{{
foo = let x, y free in [x, y, n+z]
   where n = 3
         z free
}}}

Supporting this syntax requires only small changes in haskell-src-exts: mainly a new language extension !FreeVariables and a new constructor !FreeDecl:

{{{
data Extension
  = ...
  | FreeVariables
  ...

data Decl
     = ...
     | FreeDecl SrcLoc [Name]
     ...
}}}

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)

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.)
"	holgersiegel74@…