__color__,__group__,ticket,summary,component,version,type,owner,status,created,_changetime,_description,_reporter
3,,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,,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,,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,,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,,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,,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,,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,,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,,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,,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,,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,,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,,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,,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
3,1.10.0,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,1.10.0,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,1.10.0,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,1.10.0,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,1.10.0,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,1.8.x,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
3,1.8.x,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,1.8.x,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,1.8.x,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,1.8.x,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,1.8.x,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,1.8.x,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
3,1.8.x,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,1.8.x,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
4,1.8.x,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,1.8.x,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,1.8.x,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,1.8.x,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,1.8.x,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
2,1.9.x,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,1.9.x,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
4,1.9.x,21,Missing support for the new qualified operator syntax,parser,1.9.x,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,1.9.x,24,Missing support for extensible record syntax,parser,1.9.x,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,1.9.x,25,No support for restricted type synonyms,parser,1.9.x,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,1.9.x,26,No support for HereDocuments,parser,1.9.x,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,1.9.x,27,No handling of CPP in code,parser,1.9.x,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,1.9.x,50,please reject unhandled LANGUAGE pragmas,parser,1.9.x,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
4,1.9.x,54,Allow declaration of free variables (for functional logic programming),syntax,1.9.x,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@…
5,1.9.x,59,cabal install doesn't get happy,parser,1.9.x,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