__color__,ticket,summary,component,version,priority,severity,milestone,owner,status,created,_changetime,_description,_reporter 2,5610,"Improve ""Unacceptable argument type in foreign declaration"" error message",Compiler (Type checker),7.6.1-rc1,high,,7.4.1,,new,2011-11-07T07:48:30-0800,2012-09-18T02:18:53-0700,"Using ghc 1ece7b27a11c6947f0ae3a11703e22b7065a6b6c, zlib fails to build, {{{ $ cabal install zlib Resolving dependencies... Configuring zlib-0.5.3.1... Preprocessing library zlib-0.5.3.1... Building zlib-0.5.3.1... [1 of 5] Compiling Codec.Compression.Zlib.Stream ( dist/build/Codec/Compression/Zlib/Stream.hs, dist/build/Codec/Compression/Zlib/Stream.o ) Codec/Compression/Zlib/Stream.hsc:857:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall unsafe ""static zlib.h inflateInit2_"" c_inflateInit2_ :: StreamState -> CInt -> Ptr CChar -> CInt -> IO CInt Codec/Compression/Zlib/Stream.hsc:857:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall unsafe ""static zlib.h inflateInit2_"" c_inflateInit2_ :: StreamState -> CInt -> Ptr CChar -> CInt -> IO CInt Codec/Compression/Zlib/Stream.hsc:857:1: Unacceptable result type in foreign declaration: IO CInt Safe Haskell is on, all FFI imports must be in the IO monad When checking declaration: foreign import ccall unsafe ""static zlib.h inflateInit2_"" c_inflateInit2_ :: StreamState -> CInt -> Ptr CChar -> CInt -> IO CInt Codec/Compression/Zlib/Stream.hsc:865:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall unsafe ""static zlib.h inflate"" c_inflate :: StreamState -> CInt -> IO CInt Codec/Compression/Zlib/Stream.hsc:865:1: Unacceptable result type in foreign declaration: IO CInt Safe Haskell is on, all FFI imports must be in the IO monad When checking declaration: foreign import ccall unsafe ""static zlib.h inflate"" c_inflate :: StreamState -> CInt -> IO CInt Codec/Compression/Zlib/Stream.hsc:872:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_ :: StreamState -> CInt -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt Codec/Compression/Zlib/Stream.hsc:872:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_ :: StreamState -> CInt -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt Codec/Compression/Zlib/Stream.hsc:872:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_ :: StreamState -> CInt -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt Codec/Compression/Zlib/Stream.hsc:872:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_ :: StreamState -> CInt -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt Codec/Compression/Zlib/Stream.hsc:872:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_ :: StreamState -> CInt -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt Codec/Compression/Zlib/Stream.hsc:872:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_ :: StreamState -> CInt -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt Codec/Compression/Zlib/Stream.hsc:872:1: Unacceptable result type in foreign declaration: IO CInt Safe Haskell is on, all FFI imports must be in the IO monad When checking declaration: foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_ :: StreamState -> CInt -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt Codec/Compression/Zlib/Stream.hsc:884:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall unsafe ""static zlib.h deflate"" c_deflate :: StreamState -> CInt -> IO CInt Codec/Compression/Zlib/Stream.hsc:884:1: Unacceptable result type in foreign declaration: IO CInt Safe Haskell is on, all FFI imports must be in the IO monad When checking declaration: foreign import ccall unsafe ""static zlib.h deflate"" c_deflate :: StreamState -> CInt -> IO CInt cabal: Error: some packages failed to install: zlib-0.5.3.1 failed during the building phase. The exception was: ExitFailure 1 }}}",bgamari 2,4879,Deprecate exports,Compiler,7.0.1,high,,7.8.1,,new,2011-01-05T02:04:57-0800,2012-09-12T04:08:11-0700,"== Motivation == During the library submission process there's sometimes the desire to have the ability to deprecate an export from a module. For example [http://article.gmane.org/gmane.comp.lang.haskell.libraries/14524 during the discussing] about ticket #4422, I would have liked the ability to deprecate the exports of the `String` functions: `lines`, `words`, `unlines` and `unwords` from `Data.List` in favour of importing them from `Data.String`. However I wasn't able to do so, so these exports remain. Similarly, [http://article.gmane.org/gmane.comp.lang.haskell.libraries/14925 during the discussion] about ticket #4865, Ian also desired to deprecate the export of `catch` from `System.IO.Error` but was unable to do so. == Syntax == To deprecate an export simply place a `DEPRECATE` pragma for the export inside the export list, as in: {{{ module Data.List ( ... {-# DEPRECATE lines ""Exported from Data.String instead"" #-} , lines ... ) where ... }}} Another design might be to have a different pragma as in: {{{ {-# DEPRECATE_EXPORT lines ""Exported from Data.String instead"" #-} }}} But I find the former much prettier and more obvious. == Semantics == If the `lines` export from `Data.List` is deprecated the following should raise deprecation warnings: * Directly importing a deprecated export: {{{ import Data.List (lines) }}} * Referring to a deprecated export: {{{ import Data.List foo = lines }}} If you import the same symbol from different modules and only some of them are deprecated exports then referring to the symbol won't give a deprecation warning. For example the following should not give deprecation warnings: {{{ import Data.List import Data.String foo = lines }}} === What exports can be deprecated? === * Functions. * Types. * Classes. * Constructors. Possible syntax: {{{ module A ( {-# DEPRECATE T(C1) ""The export of C1 is deprecated"" #-} T(C1, C2, C3) ) where }}} * Modules. Possible syntax: {{{ module A ( {-# DEPRECATE module B ""The export of module B is deprecated"" #-} module B ) where }}} The semantics of deprecating a module export is that you get deprecation warnings for all symbols from module `B` that you refer to inside a module that imports `A`. (Does that make sense?)",basvandijk 2,5218,Add unpackCStringLen# to create Strings from string literals,Compiler,7.0.3,high,,7.8.1,igloo,new,2011-05-25T01:48:28-0700,2013-03-22T03:22:03-0700,"GHC insert calls to `unpackCString#` to convert string literals to `String`s. Libraries like bytestring use rewrite rules to match on this call to optimize code like `pack (unpackCString# s)`. If GHC would instead use a version of unpackCString#, say unpackCStringLen#, that includes the (statically known) length, creating `ByteString`s from literals could be a constant time operation instead of a linear time operation. Another use case, which motivated this ticket, is appending string literals to builders (e.g. using `Data.Binary.Builder.fromByteString`). For small strings the most efficient way to append a string to the builder is to copy the statically allocated string directly into the builder's output buffer. If the string length was known statically, we could do this efficiently using `memcpy` or even using a small unrolled loop. ",tibbe 2,5910,Holes with other constraints,Compiler (Type checker),7.5,high,,7.8.1,,new,2012-03-02T02:59:29-0800,2012-10-02T09:19:45-0700,"Hello. As can be seen on http://hackage.haskell.org/trac/ghc/wiki/Holes and http://www.haskell.org/pipermail/glasgow-haskell-users/2012-January/021670.html, we've been working on adding holes to GHC. I'm opening this ticket about a specific problem I've been having, and I hope someone has a suggestion of how to do it correctly. As holes work quite similarly to implicit parameters (see the wiki-page for a comparison), we started out in the same way as implicit parameters. Typechecking of a hole generates a constraint (a new type of constraint), and the constraint solver will try to find the right type for each hole. The difference is that hole constraints never show up in a type, but their type is printed separately. This currently works correctly for simple typechecking, but it has some problems when other constraints are generated too. A simple example: {{{ test :: String test = show _h }}} Here, the {{{_h}}} denotes a hole named ""h"". If this function is defined like this inside a module it will currently fail: {{{ test2.hs:2:8: No instance for (Show a0) arising from a use of `show' The type variable `a0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) In the expression: show (_h) In an equation for `test': test = show (_h) Failed, modules loaded: none. }}} The problem is that the {{{Show}}} constraint is still there. If the type signature is omitted and the monomorphism restriction off, we can see that the types found are: {{{ Found the following holes: _h :: GHC.Show.Show a => a ... test :: Show a => String }}} The problem is the {{{Show a}}} that is irrelevant to the actual type of {{{test}}}, but nevertheless it's there. How do other approaches handle this? '''undefined''': {{{ test :: String test = show undefined }}} Gives the same ambiguity error, even if the signature is omitted. '''Implicit parameters''': {{{ test = show ?h }}} This works, but generates the following type signature: {{{ test :: (Show a, ?h::a) => String }}} So, as I'd want to use it, this is wrong. It has the right ingredients, but I'd want: {{{ test :: (?h :: (Show a) => a) => String }}} For implicit parameters the difference doesn't matter too much, as implicit parameters are still parameters: they still show up in the type signature. A hole is not required to be a parameter, so it's more important that every constraint only shows up where it's necessary. So the problem is that I don't know how to select from the constraints only those that are applicable to the expression/function itself, and those that apply to which of the holes. I've tried typechecking all of the holes first, but I don't know how to determine how to change the constraint set after that. If you need more information about how it currently works, or have any feedback on this approach, please let me know. I'm still quite unfamiliar with the architecture of GHC. :) ---- I'm attaching a patch against the master branch on git with my current work in case someone is interested in trying it. Note that the code generation is pretty much a stub and it will panic if you try to run a function with a hole. It will print the holes of an expression if you invoke {{{:t}}} (it doesn't currently print the holes when loading a module, but it should still print them with {{{:t}}} on a function from the module). Also, I do not recommend building stage 1 with this, as some packages have some issues. Easiest is to build stage 1 and the packages without these changes and then applying the patch and then building only stage 2.",xnyhps 2,7266,Allow fractional-looking integer literals,Compiler,7.6.1,high,,7.8.1,,new,2012-09-23T23:02:01-0700,2013-03-25T18:20:00-0700,"Haskell 2010 (2.5, 6.4.1) specifies that there are integer literals and floating literals, which are of types `(Num a) => a` and `(Fractional a) => a` respectively. This is mostly reasonable, because a `Rational` in general can't be converted to an arbitrary `Num` instance. However, there are many specific cases where specifying an integer with compact ""floating literal"" syntax is reasonable (e.g. `1.2e6` instead of `1200000`). It's possible to do that for any floating literal constant which also happens to be an integer. Several people have asked for that behavior. Attached is a patch for a proposed extension, `NumDecimals`, that implements it. Note on #2245: The current fix won't work on converted floating literals, because it involves a special case for `FractionalLit` (the right thing to do is probably to generalize that solution, but doing that properly might be complicated). So with the extension enabled, `1e400` would be pretty-printed as an integer (just like 0400 is pretty-printed). Unlike the example in #2245, though, no information is lost -- floating literals would just be printed in integer form.",shachaf 2,7300,Allow CAFs kept reachable by FFI to be forcibly made unreachable for GC,Compiler (FFI),7.4.1,high,,7.8.1,,new,2012-10-05T04:14:54-0700,2012-10-08T01:34:07-0700,"CAFs used by a foreign exported function are kept reachable the entire session because GHC can't know when the function will be called from C. If such a CAF is an evolving expression, like an FRP network, a space leak occurs because (I'm guessing) the thunks that build up during iteration go all the way back to the initial CAF, and the GC can't start collecting because it considers the CAF reachable. According to JaffaCake on the #haskell IRC channel, the runtime is capable of sovling this problem, it just needs a function that tells it to consider the specific CAF unreachable. It is then the responsibility of the user to not call the foreign exported function after the CAF is forced unreachable.",absence 3,7835,"ghc --make: allow passign .cmm, .c and .hs files in one command line",Compiler,7.6.2,normal,,,,new,2013-04-14T00:36:01-0700,2013-04-14T00:36:01-0700,"TL;DR: Allow users to make one run: {{{ $ ghc --make Test.hs TestPrim.hs test-prims.cmm -o t }}} instead of series: {{{ $ ghc -c test-prims.cmm $ ghc --make test-prims.o Test.hs TestPrim.hs }}} The buildable example is located at: https://github.com/trofi/cmm-example I'll just quote my email sent to ghc-devs@ a while ago: {{{ > Hi guys! > > Today I've tried to write a minimal [1] test case for ghc on ia64 > (it SIGSEGVs there). > > The test case consists of a .cmm and some .hs modues. > > I tried to build them in one run as: > $ ghc --make Test.hs TestPrim.hs test-prims.cmm -o t > ghc: cannot compile this file to desired target: test-prims.cmm > Usage: For basic information, try the `--help' option. > > Thus had to use > ${GHC} -c test-prims.cmm > ${GHC} --make test-prims.o Test.hs TestPrim.hs > > What do you think of allowing to use .c, .cmm and similar > files along with .hs files to make one-shot builds a bit easier? > > If noone is opposed I'll fill a request on bugtracker. > > Thanks! > > [1]: https://github.com/trofi/cmm-example }}}",slyfox 3,7843,GHC should be able to list all possible command line options,Driver,7.6.2,normal,,,jstolarek,patch,2013-04-17T00:45:57-0700,2013-04-25T07:33:36-0700,"I would be happy to have automatic completion of command-line options in GHC. For that we need GHC to be able to list all its possible command line options, similarly to cabal's `--list-options` option.",jstolarek 3,7845,RebindableSyntax should allow rebinding tuples and lists,Compiler,7.7,normal,,,,new,2013-04-18T22:34:05-0700,2013-04-18T22:34:05-0700,"e.g. {{{ {-# LANGUAGE RebindableSyntax #-} module StrictPrelude where data [] a = [] | !a : [a] data () = () data (,) a b = (,) !a !b }}} ",exbb2 3,7847,Maintain per-generation lists of weak pointers,Runtime System,7.7,normal,,,,patch,2013-04-19T02:51:55-0700,2013-05-06T02:21:35-0700,"Currently the runtime system keeps a list of all live weak pointers, and traverses it once every (major or minor) GC. This is very slow if the program keeps many weak pointers alive. Some comments in the rts source suggest that it should be using one weak pointer list per generation, so these patches implement that. The attached test program tries to imitate the memory behavior of code that uses a particular FRP library. The patches make the program 3x faster on my machine. One problem I can see with the patches is that it creates a race condition between finalizeForeignPtr and addForeignPtrFinalizer. I'm not even sure what the correct behavior is when addForeignPtrFinalizer is called after finalizerForeinPtr.",akio 3,7870,"Compilatio​n errors break the complexity encapsulat​ion on DSLs, impairs success in industry",Compiler (Type checker),7.7,normal,,,,new,2013-04-27T01:59:03-0700,2013-05-05T11:02:16-0700,"From the paper ""Scripting the Type Inference Process"" -Bastiaan Heeren Jurriaan Hage S. Doaitse Swierstra: ... Combinator languages are a means of defining domain specific languages embedded within an existing programming language, using the abstraction facilities present in the latter. However, since the domain specific extensions are mapped to constructs present in the underlying language, all type errors are reported in terms of the host language, and not in terms of concepts from the combinator library. In addition, the developer of a combinator library may be aware of various mistakes which users of the library can make, something which he can explain in the documentation for the library, but which he cannot make part of the library itself. ...As a result, the beginning programmer is likely to be discouraged from pro-gramming in a functional language, and may see the rejection of programs as a nuisance instead of a blessing. The experienced user might not look at the messages at all. Definitively this is probably the biggest barrier for the acceptance of Haskell on Industry. We need to start with something not as sophisticated as the Helium paper ""Scripting the Type Inference Process"", but maybe a partial implementation of the techniques mentioned, so that the development can be enhanced in the future. Maybe some kind of library that permits postprocessing of GHC errors and/or the identification of points in the current type checker where some kind of rules can be defined by the programmer can be the first step. ",agocorona 3,7883,enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?,Compiler,7.7,normal,,,carter,new,2013-05-02T13:38:14-0700,2013-05-20T02:39:02-0700,"LLVM provides a number of atomicity / memory ordering primitives. currently the CAS primops exposed at the CMM level are ffi'd inline assembly fun calls. this means that for certain concurrency primops, we've got fun calls within funcalls that could be easily inlined if we did it in a more llvm direct way. A notable example of this is the implementation of {{{ stg_atomicModifyMutVarzh }}} relevant basic llmv docs are the following [http://llvm.org/docs/LangRef.html#cmpxchg-instruction Atomic llvm ops] [http://llvm.org/docs/Atomics.html semantics of the various ordering levels] relevant locations in the ghc source [https://github.com/ghc/ghc/blob/master/includes/stg/SMP.h#L170 CAS inline assembly] [https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L282 defn of atomicModifyMutVar cmm code] Based upon my reading of the relevant GHC cmm code, and reading the semantics of the LLVM operations, the right level of atomic ordering in the generated bit code would be ""SequentiallyConsistent"". a first step would be to modify the CMM -> LLVM pass to substitute the cas funcall with the right llvm operation. This ''' SEEMS ''' like it'd be very very easy to do and low hanging fruit. Theres a few upsides that ''' might ''' come out of this. 1. would be easy to augment to also provide a doubleCAS primitive, which would be useful in writing various lock free data structures. 2. would increase the portability / ease of retargeting new platforms / hardware via LLVM. (not needing to worry about the target's memory consistency model / write new cases of inline assembly) 3. (this would need benchmarks) could potentially improve the performance of certain heavy concurrency operations by eliminating a funcall in an otherwise tight loop. 4. Theres probably other interesting possible upside, such as perhaps having more of the rts be nicely writeable in CMM? (esp since theres now native funcall support) 5. Also would make the CMM memory model a bit more explicit perhaps? This seems like a *relatively* managable patch to write. I'm up for spending time on this if, should it work, it'd be likely to be merged in. it'd also be a good warm up for a number of other things I want to do, including http://hackage.haskell.org/trac/ghc/ticket/5567#comment:10 ",carter 3,7895,Warning for literal overflow,Compiler,7.6.3,normal,,,,new,2013-05-07T11:53:19-0700,2013-05-07T22:58:48-0700,"Using ghc 7.6.3, the following compiles without warnings on -Wall: {{{ import Data.Word test :: Word8 test = 300 main = print test }}} I expected this to issue a warning like: ""Warning: literal overflow on line 4"". I know GCC for example does this and it would be nice if GHC did this too. ",acube 3,7855,Use optimizer for more information about incomplete pattern matches,Compiler (Type checker),7.7,normal,,,,new,2013-04-22T01:17:39-0700,2013-05-10T13:45:59-0700,"This mail gave me an idea that was too cute not to write down (though I don't expect it to be implemented any time soon), http://www.haskell.org/pipermail/haskell-cafe/2013-April/107775.html The observation is that the typechecking phase is not necessarily the best point in time to check for pattern coverage exhaustiveness: if we tentatively stub in a default case with an error, and after optimization passes, we find that this case has been eliminated, then in fact there was no pattern coverage incompleteness. So, the strategy would be to defer reporting certain coverage failures until we can do actually check if there are any problems later. Obviously if no predicates or view patterns (or similar things) are involved, then there is no point in attempting to defer it, but otherwise this could help reduce warnings in code that make heavy use of these features.",ezyang 3,7860,Add more bit fiddling functions to 'integer-gmp',libraries (other),7.6.3,normal,,,,patch,2013-04-23T15:20:23-0700,2013-04-28T07:16:40-0700,"Current implementation of 'integer-gmp' uses only a subset of ""bit fiddling"" features, [http://gmplib.org/manual/Integer-Logic-and-Bit-Fiddling.html provided] by the GMP library. The ones missing are: {{{ * mpz_popcount * mpz_setbit * mpz_clrbit }}} I think it would be nice to add these functions in addition to 'testBitInteger'. Would you accept a patch?",lebedev 3,7863,Verbosity level for quieter Template Haskell,Template Haskell,7.6.3,normal,,,,new,2013-04-25T14:14:53-0700,2013-04-29T07:17:38-0700,"In projects with large numbers of dependencies, use of template haskell can cause very large amounts of output that aren't particularly interesting. However, it seems that the only verbosity level that quiets template haskell output is -v0, which also turns off normal indications of build progress. It would be pleasant to have a way to turn off template haskell loading messages while retaining the rest of -v1 output.",dolio 3,7867,Allow template-haskell to communicate with itself between compilation units through the interface file,Template Haskell,7.6.3,normal,,,,infoneeded,2013-04-26T07:40:55-0700,2013-04-29T06:52:26-0700,"I'd like to be able to have something like this in the Q monad: {{{ type MessageName = String -- or something better, I don't know writeIface :: (Quasi q, Serializable a) => MessageName -> a -> q () readIfaces :: (Quasi q, Serializable a) => MessageName -> q [a] }}} Or instead of returning `[a]`, I'm of course fine with a `Monoid`, I just need the gathered results for every occurrance of the MessageName. This has to be in the interface file, because I'd like this to work through compilation units, like class instances, I'd like to get every result in the readIfaces call that is ever imported from the current module (transitive closure). Please note, that in a very hacky way this is already possible to do by abusing classes. Namely, I create an empty class for my message type. When I want to send a message, I create a new empty datatype named for the message and I make this an instance of the class. Then on the receiving side I just have to reify the class and I will receive all my instance names/messages. This came up while implementing the `HFlags` library: http://hackage.haskell.org/package/hflags Maybe I shouldn't be proud of this, but we currently do the hacky way explained above. I would love to have a clean approach.",errge 3,7881,Warning for pointless ranges like [5..2],Compiler,7.6.3,normal,,,,new,2013-05-02T10:31:08-0700,2013-05-03T00:52:29-0700,"Haskell beginners sometimes tend to write ranges like [3..1] or [5..2] and assume that the result will be [3,2,1] or [5,4,3,2]. This is not the case of course. I suggest that literals like [5..2] generate a warning at compile time, analogous to: ""Foo.hs:32: Warning: Literal list [5..2] evaluates to [] because 5 > 2 and the default step size is +1. Replace the literal with the empty list or with [5,4..2] to suppress this warning."" In my opinion this should only be a compile time warning, not a runtime warning. If a > 3 and b is < 3 and you write [a..b] the result is still [], but that mistake can only be caught at runtime, and requires an additional run-time check. In some cases it may even be the desired behaviour to let [a..b] evaluate to [] if a>b. On the other hand, a literal expression like [5..2] is most likely an error, because if the user would expect [5..2] to evaluate to [], he would simply write [].",mpe 3,7902,Add support for byte endianness swapping exposed as a primops,Compiler,7.7,normal,,,,patch,2013-05-09T20:40:36-0700,2013-05-15T22:52:16-0700,"Add support for W32 and W64 endianness swapping as a new primops (bSwap32# and bSwap64#), supported by code generator change in llvm and ncg to generate efficient code (i.e. X86's bswap instruction support). For other NCG architectures (powerpc, sparc) provide support by 2 ghc-prim C functions.",tab 3,7922,adding direct *.c -> object code (*.o/so/dylib) support to compilation driver,Compiler,7.7,normal,,,,new,2013-05-20T14:29:32-0700,2013-05-21T15:32:22-0700,"currently when GHC is used as the compilation driver for C code, it will always compile the C code (*.c) to assembly (*.s) and then in a subsequent phase map the assembly to the various object formats. Thusly: the feature request I have is adding support to ghc (perhaps via indication through a new flag) for running the C compiler as something like {{{ gcc source.c -c }}} rather than {{{ gcc source.c -s -c }}} (these are not necessarily the right flags, but rather a strawman representation of the difference). on certain operating systems, notable OS X, the system provided Assembler (to which there is no, more up to date, alternative) does not support / understand all of the instructions that gcc or clang will emit. Notably, as a general rule, compiling c code with -march=native flag *should not* break. However, on OS X on recent hardware, -march=native will use AVX SIMD instructions / registers if available, which the mac os x assembler doesn't understand. and thus an end user trying to build some haskell and c-code locally will have a very odd error that will take a bit of effort to understand. this took a bit of ef Likewise, when doing -fllvm compilation, the *.c-> *.s phase just slows down the compilation process period. I'm still learning the ghc compilation driver architecture, but it seems like this would be a relatively minimal change, and it'd be valuable along a number of atrributes This is not",carter 3,2595,Implement record update for existential and GADT data types,Compiler,6.8.3,normal,normal,6.12 branch,,new,2008-09-15T07:00:45-0700,2011-01-07T04:27:22-0800,"Ganesh writes: The most important thing for me is supporting record update for existentially quantified data records, as in the error below. In general I also find working with code that involves existential type variables quite hard work - for example I can't use foo as a record selector either, even if I immediately do something that seals the existential type back up again. I don't understand this stuff well enough to be sure whether it's an impredicativity issue or not, though. {{{ Foo.hs:11:8: Record update for the non-Haskell-98 data type `Foo' is not (yet) supported Use pattern-matching instead In the expression: rec {foo = id} In the definition of `f': f rec = rec {foo = id} }}} Program is: {{{ {-# LANGUAGE Rank2Types #-} module Foo where data Foo = forall a . Foo { foo :: a -> a, bar :: Int } x :: Foo x = Foo { foo = id, bar = 3 } f :: Foo -> Foo f rec = rec { foo = id } g :: Foo -> Foo g rec = rec { bar = 3 } }}} Simon says: Ah now I see. The relevant comment, `TcExpr` line 465, says {{{ -- Doing record updates on -- GADTs and/or existentials is more than my tiny -- brain can cope with today }}} Should be fixable, even with a tiny brain. ",simonpj 3,849,Offer control over branch prediction,Compiler,6.4.2,normal,normal,7.6.2,,new,2006-08-08T07:23:41-0700,2013-03-25T04:26:14-0700,"So now that GHC is so good at producing really fast low level code (see ByteString benchmarks) we start to encounter low level gubbins where to get the fastest possible code we need slightly more influence over branch prediction. In the code for ByteString's 'writeStrUp/Dn' functions we're doing a tight loop writing bytes to memory. The first version looks much like this: {{{ loop fp n off s = case next s of Done -> return $! PS fp 0 off Skip s' -> loop fp n off s' Yield x s' -> do withForeignPtr fp $ \p -> pokeByteOff p off x loop fp n (off+1) s' }}} When we get to the end of a memory block we need to double the size of the memory block and carry on. So this adds an additional conditional test into this loop. {{{ loop fp n off s = case next s of Done -> trimUp fp n off Skip s' -> loop fp n off s' Yield x s' | n == off -> realloc fp n off s' x | otherwise -> do withForeignPtr fp $ \p -> pokeByteOff p off x loop fp n (off+1) s' }}} There are dramatic differences between equivalent forms of code. Just by reversing the order of the (n==off) test one form I can process 50Mb of data in 0.20 seconds and in the other it takes 0.34 seconds. That is: {{{ | n == off -> realloc fp n off s' x | otherwise -> do ... }}} vs {{{ | n /= off -> do ... | otherwise -> realloc fp n off s' x }}} I think that this is all down to branch prediction and the arrangement of basic blocks. On a modern CPU correctly predicted branches are nearly free while mis-predicted branches are very costly due to stalled pipelines etc. In gcc they have a branch prediction framework. It annotates conditionals with prediction information. It then uses that during code generation to do things like arranging basic blocks so that unlikely blocks are moved out of line. It gets the prediction information from a few sources. One is a simple static branch predictor, for example branches back to to the beginning of a loop are likely to be taken and branches to error functions are not. gcc even has a profile feedback system to find the real probabilities of branches from a sample run of the program. It also has a user annotation {{{__builtin_expect()}}} which many C projects use in the form of a macro: {{{ if (unlikely(x==0)) { ... }}} The Linux kernel uses this fairly heavily to move error handling code out of the main 'fast path' code. Anyway, so what I wish is that I could write something like: {{{ loop fp n off s = case next s of Done -> {-# UNLIKELY #-} trimUp fp n off Skip s' -> loop fp n off s' Yield x s' | n == off -> {-# UNLIKELY #-} realloc fp n off s' x | otherwise -> do withForeignPtr fp $ \p -> pokeByteOff p off x loop fp n (off+1) s' }}} The best approximating effect that I can use at the moment is to make the unlikely realloc branch a local function in a where clause but mark it with {{{ {-# NOINLINE #-} }}} so that the code for the realloc case doesn't pollute the tight loop for the normal fast case. Then the other approximation is fiddling with the logic of the binary test and looking at the benchmarks. The combination of these two techniques makes a dramatic difference to the speed. However I do need more control to do it reliably, while I was able to make it work for writeStrUp, I could not find a combination to work for writeStrDn - we loose about 50% performance when we add the realloc branch. So a slightly more reliable method to hint at the likelihood of conditionals would make this kind of low level code faster and easier to write. Some time ago as a quick hack I did add a branch prediction annotation to the CMM conditional constructor. I only used it in the C backend to turn it into uses of gcc's {{{__builtin_expect()}}}. I also didn't connect it to the front end so I didn't have any high level static branch prediction (which could be done by looking for branches with recursive calls or calls to error etc). The only place I did actually use it was in the heap check and stack check. I assumed that it would be advantageous to predict heap and stack overflow branches as not taken. It was only a quick hack - I didn't do any benchmarks to see if it had any effect. Anyway, just a thought, and of course not something we should be thinking about 'til post 6.6. Duncan",simonpj 3,1965,Allow unconstrained existential contexts in newtypes,Compiler,6.8.1,normal,minor,7.6.2,,new,2007-12-08T13:02:05-0800,2012-09-12T04:11:57-0700,"Declarations like {{{ newtype Bar = forall a. Bar (Foo a) }}} ought to be allowed so long as no typeclass constraints are added. Right now, this requires data rather than newtype. ",guest 3,3085,warn about language extensions that are not used,Compiler,6.10.1,normal,normal,7.6.2,,new,2009-03-11T11:03:32-0700,2012-09-12T04:11:57-0700,"When I put `{-# OPTIONS_GHC -Wall -Werror #-}` in my source file, I don't get compiler warnings about redundant language extensions that I enabled in that file. For example if I write `{-# LANGUAGE GeneralizedNewtypeDeriving #-}` in the file, but I never do newtype deriving, the compiler could give me a warning. It would be nice if the compiler gave warnings about this, since after refactoring, some language extensions might not be needed anymore, and hence should be removed since fewer language extensions mean more stable and portable code no? ",PVerswyvelen 3,3217,Make GHCi have separate flags for interactive Haskell expressions,Compiler,6.10.2,normal,normal,7.6.2,,new,2009-05-11T05:17:58-0700,2012-09-12T04:11:57-0700,"It's becoming clear that in GHCi we want to have a separate set of command-line flags for * Compiling Haskell expressions typed at the GHCi prompt * Compiling entire modules, eg via `:load` Examples of this need are: * We already have an ad-hoc difference in the way that type-class defaults are applied: http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules * In #3202 there's a well-argued request to change behaviour of the monomorphism restriction So the new feature would consist of: * The `InteractiveContext` should contain a set of `DynFlags` used for compiling command-line Haskell expressions (the ''interactive `DynFlags`'') * The `:set` command would change both the `DynFlags` maintained by GHCi for compiling entire modules (the ''batch `DynFlags`''), and the interactive `DynFlags`. * A new `:seti` command to change the interactive flags * Just possibly a `:setb` command to set the batch flags but leave the interactive ones unchanged. Arguably it'd be good to have a command to display the current flag settings (of either `DynFlags`) but that's another blob of work.",simonpj 3,3693,Show stack traces,Runtime System,6.10.4,normal,,7.6.2,,new,2009-11-25T22:36:09-0800,2013-01-20T17:23:48-0800,"Debugging stack overflows can be very difficult, because GHC gives very little information as to exactly what is overflowing. Showing a basic stack dump (on crash, or in the ghci debugger) would be enormously helpful. (Entered after spending two days trying to determine the cause of a stack overflow, before discovering it was a GHC bug [3677], which would have been apparent immediately if I could have only seen a callstack.) ",jpet 3,3984,Handle multiline input in GHCi history,GHCi,6.12.1,normal,,7.6.2,,new,2010-04-13T00:14:02-0700,2012-09-12T04:11:59-0700,"GHCi accepts multiline input in the form of: {{{ Prelude> :{ Prelude| let f = do Prelude| print ""Hello"" Prelude| print ""World"" Prelude| :} }}} OR of the form: {{{ Prelude> :set +m Prelude| let f = do Prelude| print ""Hello"" Prelude| print ""World"" Prelude| Prelude> }}} However, recalling mulitline input from history (with the key or ) recalls it as its individual lines, not the whole input. Ideally multiline should be one history entry and allow proper editing of the recalled text.",aavogt 3,4092,Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64#,Compiler,6.12.2,normal,,7.6.2,,new,2010-05-24T08:57:54-0700,2012-09-12T04:11:59-0700,"There are currently two ways to compute the ulp of double numbers with GHC : * Calling a C function, which requires to allocate a pointer. This is way too expensive when using interval arithmetic (for instance), that compute two ULPs at each arithmetic operations. * Programming it by hand in haskell with GHC primitive operations, which requires using unsafeCoerce# : this does not work in GHC 6.12.2. unsafeCoerce# should work, and there should be a primitive ulp# function in GHC, operating on Doubles at least. By the way, here is my haskell code using C for computing it : {{{ foreign import ccall unsafe ""math.h frexp"" c_frexp::CDouble->(Ptr CInt)->IO () foreign import ccall unsafe ""math.h ldexp"" c_ldexp::CDouble->CInt->IO CDouble ulp::Double->Double ulp x=unsafePerformIO $ do expon<-alloca (\e->do c_frexp (realToFrac x) e peek e) (c_ldexp 0.5 $ expon-52) >>= return.realToFrac }}}",malosh 3,4102,Bit manipulation built-ins,libraries/base,6.12.2,normal,,7.6.2,,new,2010-05-28T19:00:28-0700,2012-09-12T04:11:59-0700,"So far Haskell/GHC lacks more HL bit manipulation instructions which on many platform can be compiled to single instruction. Probably the good guide are those implemented in LLVM: - byte swap - population count - number of leading zeros - number of trailing zeros All of them can be implemented in terms of Data.Bits - however not quite in efficient way (like looping over patterns).",uzytkownik 3,4385,Type-level natural numbers,Compiler (Type checker),,normal,,7.6.2,diatchki,new,2010-10-11T16:22:51-0700,2013-05-08T09:00:11-0700,"Natural numbers at the type-level have many uses, especially in contexts where programmers need to manipulate data with statically known sizes. A simple form of this feature has been present in many programming languages for a long time (e.g., sub-range types in Pascal, array type in C, etc.). The feature is particularly useful when combined with polymorphism as illustrated by more recent programming languages (e.g., Cyclone, BlueSpec, Cryptol, Habit). Existing features of Haskell's type system---such as polymorphism, kinds, and qualified types---make it particularly suitable for adding support for type level naturals in a natural way! Indeed, there are quite a few Haskell libraries available on Hackage that implement support for type-level numbers in various forms. These libraries are being used by other packages and projects (e.g., the Kansas Lava project, and the type-safe bindings to the LLVM library). Supporting natural number types directly in the compiler would help these projects, and others, by improving on the existing libraries in the following ways: * a standard implementation, * a better notation, * better error messages, * a more efficient implementation, * more complete support for numeric operations. I have started on an implementation of this feature, and my GHC branch is available in a darcs repository at the following URL: {{{ http://code.galois.com/darcs/ghc-type-naturals/ }}} ",diatchki 3,4470,Loop optimization: identical counters,Compiler,,normal,,7.6.2,,new,2010-11-04T03:25:50-0700,2012-09-12T04:12:00-0700,"Consider the small program below, where 'f' has to counters 'i' and 'j'. Both are completely identical; the only difference is that 'i' is used to change 's', while 'j' changes 'm'. It would be beneficial to have GHC transform 'f' into something like 'ff' so that one register less is required. Neither GHC nor LLVM perform this optimization. Code of this kind occurs when one uses the ""vector library"". See this discussion: [http://www.haskell.org/pipermail/glasgow-haskell-users/2010-November/019446.html] {{{ {-# LANGUAGE BangPatterns #-} module Main where import Criterion.Main f :: Int -> Int -> Int -> Int -> Int f !i !j !s !m | i == 0 = s+m | otherwise = f (i-1) (j-1) (s + i+1) (m + j*5) g :: Int -> Int g !k = f k k 0 0 ff :: Int -> Int -> Int -> Int ff !i !s !m | i == 0 = s+m | otherwise = ff (i-1) (s + i+1) (m + i*5) gg :: Int -> Int gg !k = ff k 0 0 {- main = do print $ g 20 print $ gg 20 -} main = defaultMain [ bench "" g"" $ whnf g 20 -- 67.9ns , bench ""gg"" $ whnf gg 20 -- 64.5ns ] }}} Function 'f' produces this core: {{{ $wf = \ (ww_s1uU :: Int#) (ww1_s1uY :: Int#) (ww2_s1v2 :: Int#) (ww3_s1v6 :: Int#) -> case ww_s1uU of wild_B1 { __DEFAULT -> $wf (-# wild_B1 1) (-# ww1_s1uY 1) (+# (+# ww2_s1v2 wild_B1) 1) (+# ww3_s1v6 (*# ww1_s1uY 5)); 0 -> +# ww2_s1v2 ww3_s1v6 } }}} 'wild_B1' and 'ww1_s1uY' should be merged in this case. The attached source is above program.",choenerzs 3,4900,DEPENDS pragma,Compiler,,normal,,7.6.2,,new,2011-01-17T19:58:43-0800,2013-01-07T20:19:11-0800,"Since a seemingly-growing amount of Haskell code is using Template Haskell to read and include data from external sources, it would be nice if GHC recognized a pragma for specifying additional build dependencies for a source file. Such a pragma could be required to appear before the module headers, and look like: {-# DEPENDS ""file.dat"" #-} ghc --make would add it to other dependencies when deciding what modules to rebuild. The file would NOT be one that's generated by some other build step, but rather play the role of an additional source file, so it would have no effect on the order of compiling modules. My gut says to just make it an error if the file does not exist. One example of a place this is called for is Michael Snoyman's Yesod and external hamlet files (e.g., hamletFile in the hamlet package). These are plastered all over the place with warnings that if you use them, GHC will no longer automatically rebuild everything it needs to.",cdsmith 3,4937,"Remove indirections caused by sum types, such as Maybe",Compiler,7.0.1,normal,,7.6.2,,new,2011-01-31T14:27:58-0800,2013-01-31T23:41:10-0800,"While null pointers cause correctness issues in languages that allow them, they do have one benefit over `Maybe` when used to represent nullable values: they allow encoding the absence of a value cheaply. Using `Maybe` to represent a nullable value adds an extra indirection (pointer) to get to the wrapped value. We could use the bits set by pointer tagging to encode that the pointer points directly to the value, rather than to an intermediate constructor. I believe JHC takes this approach. A motivating example is this implementation of a hash array mapped trie (HAMT): A HAMT stores key/value pairs and subtrees in two arrays. {{{ data Node k v = MkNode (Array (Maybe k)) (Array (Either v (Node k v)) }}} Iff index `i` in the first array is `Nothing`, the second array contains a Node at index `i`, otherwise it contains a value. Adding an extra indirection, using `Maybe` or `Either`, adds both space (in terms of extra points and data constructor headers) and time (in terms of additional cache misses and branches). ",tibbe 3,5075,CPR optimisation for sum types if only one constructor is used,Compiler,7.0.3,normal,,7.6.2,simonpj,new,2011-04-01T14:03:24-0700,2013-04-28T07:14:53-0700,"Inspired by #3138, it might be useful for StrAnal to detect functions such as the following where only one of the data constructors for a sum type are CPRed: {{{ loop x = case x < 10 of True -> Left x; False -> loop (x*2) }}} We can usefully transform to: {{{ $wloop x = case (case x < 10 of True -> Left x; False -> loop (x*2)) of Left y -> (# y #) loop x = case loop x of (# y #) -> Left y }}} Attached patch implements this behaviour. Most of the complication in the new code occurs because adding a DataCon field to the Demand data type means that we have to define a separate IfaceDemand type for storage in interface files. The patch validates but I haven't done any tests on nofib. I have confirmed that the new optimisation hits on some examples, though.",batterseapower 3,5108,Allow unicode sub/superscript symbols in both identifiers and operators,Compiler (Parser),7.1,normal,,7.6.2,,new,2011-04-12T08:47:59-0700,2012-09-12T04:12:01-0700,"While #4373 permits {{{ Prelude> let v₁ = 1 }}} the following is rejected {{{ Prelude> let m >>=₁ f = undefined :0:10: lexical error at character '\8321' }}} Identifiers with non-numeric subscripts are not accepted either: {{{ Prelude> let vₐ = 1 :0:6: lexical error at character '\8336' }}} I wrote a small patch that makes such definitions possible. 1. A new unicode Alex macro, {{{$subsup}}}, is introduced and added to {{{$idchar}}}, {{{$symchar}}}, and {{{$graphic}}} 2. A unicode code point is classified as {{{$subsup}}} by {{{alexGetChar}}} iff either of the following holds: a. The code point is annotated with or in [http://www.unicode.org/Public/UNIDATA/UnicodeData.txt] b. It is the [DOUBLE/TRIPLE/QUADRUPLE] PRIME (U+2032, U+2033, U+2034, U+2057) ",mikhail.vorozhtsov 3,5239,"Em-dash for ""--"" with UnicodeSyntax.",Compiler (Parser),7.0.3,normal,,7.6.2,,new,2011-06-04T19:17:04-0700,2012-12-11T11:57:39-0800,"It would be neat if the UnicodeSyntax extension supported the Unicode ""—"" EM DASH (U+2014) character as an alternative for the ""--"" single-line comment introduction character sequence. One possible objection I can anticipate is that its use could be confusing when using a monospace font, but it seems unjust to let that hold back those of us who have liberated ourselves from monospace. :-) ",Eelis- 3,5364,Access RTS flag values from inside Haskell programs,libraries/base,7.3,normal,,7.6.2,,new,2011-07-30T16:30:56-0700,2012-09-12T04:12:02-0700,"Strictly speaking, it is already possible to do this since includes/rts/Flags.h exports RtsFlags, which can be accessed with a mini wrapper function. We should add this wrapper function so we can import it, and then write code which reads out the contents of all the various parameters so that users can introspect this at runtime. Maybe put them in the GHC.RTS module.",ezyang 3,5392,Warnings about impossible MPTCs would be nice,Compiler,7.0.4,normal,,7.6.2,,new,2011-08-08T10:06:16-0700,2012-09-12T04:12:03-0700,"In the following class declaration: {{{ {-# LANGUAGE MultiParamTypeClasses #-} class C a b where f :: a -> a }}} it is possible to declare this class, and to make instances of it, but it will be impossible to ever call `f`, even with `unsafeCoerce` and other evil attempted workarounds. It seems fairly easy for GHC to spot this situation, where a method doesn't mention all of the class arguments, and it might save some confusion for newbies. I remember trying pretty hard when I was first learning haskell to tell GHC which instance I wanted there, but obviously failed quite miserably.",pumpkin 3,5429,Docase notation as GHC extension,Compiler,,normal,,7.6.2,tomasp,new,2011-08-24T16:40:49-0700,2012-09-12T04:12:03-0700,"Many monads provide additional combinators for ''parallel composition'', ''choice'' and ''aliasing''. In our Haskell Symposium 2011 paper (http://www.cl.cam.ac.uk/~tp322/papers/docase.html) we call a monad with these 3 additional combinators a '''joinad'''. The monads that implement (some of) these three operations include: * '''Par monad''' for parallel programming implements ''parallel composition'' (run two computations in parallel) and ''aliasing'' (start computation and access the result in multiple other computations) and can be extended to support (non-deterministic) ''choice'' * '''Parsers''' can implement ''parallel composition'' as an intersection of languages (parse the same input using multiple parsers), which is useful for encoding validation rules and ''choice'' (use the result of a first parser that succeeds). * '''Other monads''' that can be considered include the `Orc` monad (for concurrent orchestration) and the encoding of CHP (Communicating Haskell Processes). The proposal is to implement the a GHC extension that allows the `docase` notation for working with ''joinads''. Using the `Par` monad as an example, the following snippet implements a function `all` which tests whether a predicate holds for all leaves of a tree: {{{ all :: (a -> Bool) -> Tree a -> Par Bool all p (Leaf v) = return (p v) all p (Node left right) = docase all p left, all p right of False, ? -> return False ?, False -> return False allL, allR -> return (allL && allR) }}} The left and right sub-trees are processed in parallel (using ''parllel composition''). The special pattern `?` denotes that the corresponding computation does not have to complete in order for the clause to match. This means that the first two clauses implement short-circuiting behavior (and can match even if the other branch is still being processed). The operations used by the desugaring are expected to have the following types: * `mzip :: m a -> m b -> m (a, b)`[[br]]This operation has been added by the recent patch that re-implements ''monad comprehensions'', so we can reuse it. * `morelse :: m a -> m a -> m a`[[br]]The operation has the same type as `mplus` from `MonadPlus`, but we require an operation that is left-biased. One possible option is to add `MonadOr` type class as suggested in http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal. * `malias :: m a -> m (m a)`[[br]]The operation ""starts"" a computation and returns a handle for accessing the result. It has been used e.g. by the authors of the `Orc` monad. For many simpler monads, this can be implemented as monadic `return`. ===Feedback=== I would appreciate any feedback from GHC users and developers! In particular, here are some general, as well as more specific questions that I've heard in the past: * What existing monads can implement the interface? (I believe there are quite a few of them including `Par`, Parsers, `Orc`, CPH, but I'd love to know about more.) * What to do about monads that implement only some operations? Currently, the `malias` operation has default implementation. If a `docase` notation has just a single clause, then `morelse` is not required. If it has multiple clauses, each having just a single ''binding pattern'' (non `?`) then `mzip` is not required. * The laws - the paper includes detailed discussion about laws (e.g. why `mzip` should be symmetric and why `morelse` should have left-biase). Does the community agree with the laws, or do you suggest some changes? * Syntax seems to be a tricky question - the notation intentionally resembles `case`, but it takes a list of arguments (of type `m a1`, ..., `m an`), so it is not using ''tuple syntax''. Is there any better alternative? * Correspondence with ''monad comprehensions'' - the `docase` notation can express parallel composition in a similar way as ''monad comprehensions''. I think this parity is a good thing. However, it allows more expressivity in one direction (by adding choice) and less in another (no group/order by comprehensions). Do you think this is a good ballance?",tomasp 3,5462,Deriving clause for arbitrary classes,Compiler,7.2.1,normal,,7.6.2,,new,2011-09-05T08:23:45-0700,2012-09-12T04:12:04-0700,"Currently, you can use a `deriving` clause, or standalone-deriving declaration, only for * a built-in class like `Eq` or `Show`, for which GHC knows how to generate the instance code * a newtype, via the ""newtype-deriving"" mechanism. However, Pedros's new generic-default mechanism means that it makes perfect sense to write this: {{{ data T a = ...blah..blah... deriving( Generic ) instance C a => C (T a) -- No 'where' clause }}} where C is some random user-defined class. Usually, an instance decl with no 'where' clause would be pretty useless, but now that we have [http://www.haskell.org/ghc/dist/current/docs/html/users_guide/type-class-extensions.html#class-default-signatures default method signatures], in conjunction with `deriving( Generic )`, the instance ''can'' be useful. That in turn leads to a desire to say {{{ data T a = ...blah..blah... deriving( Generic, C ) }}} which is even more compact. Is the extra compactness worth it? Presumably we'd only want to do this for some specified classes C, so we'd need some way to say this at C's declaration site. Something like: {{{ class C where op :: a -> a default op :: blah => a -> a op = {-# DERIVABLE C #-} -- This says you can say -- data T = ... deriving( C ) }}} I'm a bit dubious about whether the payoff justifies the cost, but I'm recording the idea in this ticket.",simonpj 3,5467,Template Haskell: support for Haddock comments,Template Haskell,7.2.1,normal,,7.6.2,,new,2011-09-06T21:50:31-0700,2012-12-17T01:47:46-0800,"I would like Template Haskell to be aware of Haddock comments. Here's a concrete example. The data-accessor-template package (http://hackage.haskell.org/package/data-accessor-template) can be used as follows: {{{ {-# LANGUAGE TemplateHaskell #-} module Example where import Data.Accessor import Data.Accessor.Template data MyRecord = MyRecord { field1_ :: Int -- ^ a field , field2_ :: Int -- ^ another field } deriveAccessors ''MyRecord -- produces these: -- field1, field2 :: Accessor MyRecord Int }}} We would like the values {{{field1}}} and {{{field2}}} to inherit the documentation from {{{field1_}}} and {{{field2_}}}, but there is no way to automate this in Template Haskell -- or even to document {{{field1}}} and {{{field2}}} by hand! I would like Template Haskell to support this. There are two related features required to make this work: firstly, the {{{Dec}}} datatype needs to be extended to support Haddock comments; secondly, {{{reify}}} needs to return these comments. I suspect the second feature may require significant plumbing to work in the general case, because I believe that {{{.hi}}} files don't store Haddock comments. A tolerable compromise in this particular example would be to only reify comments for things defined in the current module. A possible API would be {{{ data Dec = ... | DocD Name String -- attach the given docstring to the given name | SigD Name Type (Maybe [String]) -- a type signature, with a possibly-empty docstring for each argument and for the result type ... }}} The {{{DocD}}} constructor is new, but the {{{SigD}}} constructor is unfortunately a modification of the current {{{SigD Name Type}}} constructor. We make this modification to support comments of this form: {{{ f :: Int -- ^ The 'Int' argument -> Float -- ^ The 'Float' argument -> IO () -- ^ The return value }}} A possible API for reifying comments would be {{{ reifyDocs :: Name -> (Maybe String, Maybe [String]) -- documentation string; documentation for individual arguments }}} Reiner",reinerp 3,5542,"also parse class/instance declarations as ""HEAD <= CONTEXT where""",Compiler (Parser),7.2.1,normal,,7.6.2,,new,2011-10-09T09:17:15-0700,2012-09-12T04:12:05-0700,"When looking at a list of instance declarations, it can be difficult to visually locate the instance heads. In particular, the varying size of the contexts means that it's difficult to align the instance heads without introducing extraneous white-space. I suggest allowing the head to come first (like all other declarations), so that the varying context lengths no longer prevent easy identification of the class/instance heads. For example, I think it's easier to see which instances are being declared in this following list of (,) instances {{{ instance Bounded (a, b) <= (Bounded a, Bounded b) where … instance Eq (a, b) <= (Eq a, Eq b) where … instance Functor ((,) a) where … instance Ord (a, b) <= (Ord a, Ord b) where … instance Read (a, b) <= (Read a, Read b) where … instance Show (a, b) <= (Show a, Show b) where … }}} than it is with the default syntax {{{ instance (Bounded a, Bounded b) => Bounded (a, b) where … instance (Eq a, Eq b) => Eq (a, b) where … instance Functor ((,) a) where … instance (Ord a, Ord b) => Ord (a, b) where … instance (Read a, Read b) => Read (a, b) where … instance (Show a, Show b) => Show (a, b) where … }}} A more compelling example would involve multiparameter type classes and juxtaposition of instances for different combinations of types. (Bonus: the proposed ordering might even help beginner grasp that the instance context is not used for instance selection.)",nfrisby 3,5556,Support pin-changing on ByteArray#s,Compiler,7.2.1,normal,,7.6.2,,new,2011-10-13T16:02:03-0700,2012-09-12T04:12:05-0700,"I'm mostly posting this here as a chance for discussion for this feature, as I've wanted it a few times before and because Roman Leshchinskiy mentioned it on reddit and reminded me. IIRC, the basic idea was to have an operation like: {{{ pin# :: ByteArray# -> ByteArray# }}} Then you could say: {{{ let y = pin# x }}} and y would have the same contents as x but be pinned. Whether it is the same memory block as x would be implementation-dependent but with GHC, it would be. When GHC would garbage collect y, it would unpin x (if x is still alive). You would also have unpin# so if you said: {{{ let z = unpin# y }}} then z will become unpinned when y is garbage collected. I mostly care because it's unfortunate to have to decide up front whether you want to suffer from memory fragmentation or to support foreign bindings. This could for example let us break the distinction between Data.Vector.Unboxed and Data.Vector.Storable. From a higher level, you might have a `withPinned` function that would temporarily pin (without copying) an array while you make foreign calls with it (even across multiple foreign calls), and then would unpin it when you're done. I'm not sure what this would entail on the actual GC/runtime side of things, but I figured it'd be worth discussing.",pumpkin 3,5590,"""guarded instances"": instance selection can add extra parameters to the class",Compiler (Type checker),7.2.1,normal,,7.6.2,simonpj,new,2011-10-27T22:19:55-0700,2012-09-12T04:12:05-0700,"Disclaimer: the same semantics can currently be achieved without this syntax. So this is mostly a Parser request, though I've made it a Type Checker request because some type errors would probably need to be aware of the language extension. More on this at the bottom. We'll start with a demonstration. Just some ancillary declarations for now. {{{ class Sat t where dict :: t data True; data False type family Pred (p :: * -> *) a type family Left a; type instance (Either l r) = l type family Right a; type instance (Either l r) = r data Path p a where Here :: p a -> Path p a L :: Path p l -> Path p (Either l r) R :: Path p r -> Path p (Either l r) }}} The objective of these declarations is to allow us to define some `Pred`icate `p` and use the `Sat` class to find a path leading through a tree of `Either`s to a type that satisfies that `Pred`icate. These next three declarations use the new syntax, as I'm imagining it. {{{ -- NB new syntax: `guard' keyword, the pipe after the instance head, -- and a comma-separated list of types after that instance guard Sat (Path a) | Pred p a, Pred (Path p) (Left a), Pred (Path p) (Right a) -- now we match on the instance guards, using the same pipe syntax instance Sat (p a) => Sat (Path p a) | True , satl , satr where dict = Here dict instance Sat (Path p l) => Sat (Path p (Either l r)) | False, True , satr where dict = SL dict instance Sat (Path p r) => Sat (Path p (Either l r)) | False, False, True where dict = SR dict }}} The `guard` declaration asserts that any instance of `Sat` with a head that ''would'' overlap a la `OverlappingInstances` with {{{Path a}}} shall be disambiguated via the comma-separated list of types following the pipe. In this example, the subsequent three instances, which would traditionally overlap, are indeed disambiguated by their additional ""instance head guards"" (cf. HList's type-level programming style: [http://www.haskell.org/haskellwiki/GHC/AdvancedOverlap AdvancedOverlap]). We can currently simulate this syntax by declaring a variant class of `Sat' which takes an extra parameter and thread the instance guards through that. Unfortunately, this workaround is repetitive, misses out on the better type error messages possible with specific Type Checker support, and it's just a bother. {{{ class Sat_ a anno where dict_ :: anno -> a instance (anno ~ (Pred p a, Pred (Path p) (Left a), Pred (Path p) (Right a)), Sat_ (Found a) anno) => Sat (Path p a) where dict = dict_ (undefined :: anno) instance Sat (p a) => Sat_ (Path p a) (True, satl, satr) where dict_ _ = Here dict … }}} In the spirit of #4259, [TypeFunctions/TotalFamilies total type families], and [http://www.haskell.org/haskellwiki/GHC/AdvancedOverlap AdvancedOverlap], this syntax could be enriched and thereby promoted to an actual Type Checker extension. Replacing the comma-separated list of types in the `guard` declaration with a sequence of contexts would be appropriate syntax for explicitly making instance selection sensitive to those contexts. The instance head guards could then just be a type boolean (wired-in to the compiler, now) indicating whether the context was satisfied. A `True` would bring that context's consequences to bear within both the instance's own context and its declarations. For example, we could do without the `Left` and `Right` type families. {{{ instance guard Sat (Path a) | (Pred p a) (a ~ Either l r, Pred (Path p) l) (a ~ Either l r, Pred (Path p) r) instance Sat (p a) => Sat (Path p a) | True satl satr where dict = Here dict … }}}",nfrisby 3,5619,Shorter qualified import statements,Compiler,7.2.1,normal,,7.6.2,,new,2011-11-09T05:32:16-0800,2012-09-12T04:12:06-0700,"I would like to be able to write imports like {{{ import qualified Data.Vector as V (Vector, fromList) import Data.Vector ((!), (//)) }}} as a single statement, like {{{ import qualified Data.Vector ((!), (//)) as V (Vector, fromList) }}} Which seems to be compatible with the current import statement.",YvesPares 3,5647,"CLI option to silence ""Loading package foo ... linking ... done"" output",Compiler,7.2.1,normal,,7.6.2,,new,2011-11-19T07:46:17-0800,2012-09-12T04:12:06-0700,"When building libraries with GHC that require compile-time evaluations, such as TemplateHaskell, the per-compilation unit progress output, i.e. {{{ [ n of N] Compiling Foo.Bar.Doo ( ... ) }}} is flooded with several {{{ Loading package foo ... linking ... done. }}} lines for each library required by the interpreted compile-time code. Although this information is definitely useful for tracking down compile-time linking issues, its a bit too verbose IMHO. I couldn't find any CLI option, to selectively disable just those linker messages, but keep the compilation progress output, therefore I'd hereby request the feature to provide a CLI option to disable outputting just those `Loading package ...` message while keeping everything else as is.",hvr 3,5672,parBufferWHNF could be less subtle,libraries (other),7.2.1,normal,,7.6.2,duncan,new,2011-12-02T08:51:29-0800,2012-09-12T04:12:07-0700,"I would suggest modifying `parBufferWHNF` as follows, with the `{- x ``seq`` -}` actually included. {{{ parBufferWHNF :: Int -> Strategy [a] parBufferWHNF n0 xs0 = return (ret xs0 (start n0 xs0)) where -- ret :: [a] -> [a] -> [a] ret (x:xs) (y:ys) = y `par` (x : ({-x `seq`-} ret xs ys)) ret xs _ = xs -- start :: Int -> [a] -> [a] start 0 ys = ys start !_n [] = [] start !n (y:ys) = y `par` start (n-1) ys }}} The point of the extra `x ``seq`` ` is so that consumers that do not evaluate the list element before evaluating the next cons cell don't get such surprising loss of parallelism. For example non-strict left folds like `sum` will rush to the end of the list spine without evaluating the list elements, and then evaluate the elements later. That does not work well with the `parBufferWHNF` strategy. Adding the extra `seq` fixes it. Note that in this case I think `seq` or `pseq` would work.",duncan 3,5687,Friendly Interface for auto-completion of GHCi,GHCi,7.2.1,normal,,7.6.2,,new,2011-12-07T19:26:42-0800,2012-09-12T04:12:07-0700,"Now the GHCi can do TAB completion when running in term. But in Emacs/Inf-Haskell mode, TAB completion doesn't work. It should be great that if GHCi support the command like ""complete"" in GDB. If GHCi supports this, it's easy to implement TAB completion in Emacs/Inf-Haskell mode.",linsumang 3,5787,Add instances to ZipList,libraries/base,7.2.2,normal,,7.6.2,,infoneeded,2012-01-16T19:01:31-0800,2013-03-24T15:49:34-0700,"There was a reasonably uncontroversial vote on the libraries list to add common derived instances (Eq, Ord, Show, Read) to ZipList, which currently only has Functor and Applicative. I have made the change on my local ghc build and it seems to build, but I can't get validate to pass. I'm not sure if it's my own fault, but considering I only made a one-line change, it seems odd. I'll attach a patch once I make sure it wasn't my fault.",pumpkin 3,5813,Offer a compiler warning for failable pattern matches,Compiler,7.2.2,normal,,7.6.2,,new,2012-01-24T02:30:20-0800,2012-09-12T04:12:09-0700,"This started off with a mailing list discussion: [http://www.mail-archive.com/haskell-cafe@haskell.org/msg96517.html]. The problem is that the following code produces no compile-time warning and results in a runtime error: {{{ data MyType = Foo | Bar deriving Show test :: Monad m => m MyType -> m () test myType = do Foo <- myType return () main :: IO () main = test $ return Bar }}} This is in contrast to the rest of pattern matching, which would warn about unmatched patterns, e.g.: {{{ data MyType = Foo | Bar deriving Show test :: Monad m => m MyType -> m () test myType = do x <- myType case x of Foo -> return () main :: IO () main = test $ return Bar }}} I understand that this style of code may be very useful in some circumstances when paired with a Monad providing a sensible fail implementation, and is especially used in list comprehensions. However, this is allowing an easily catchable static error to slip through our fingers. I recommend we add a new compiler warning to catch incomplete patterns in do-notation binding. I believe this warning should not apply to list comprehensions. Ideally, this warning would be turned on by -Wall.",snoyberg 3,5823,FFI and CAPI needs {-# INCLUDE #-} back?,Compiler,7.5,normal,,7.6.2,,new,2012-01-28T12:01:13-0800,2012-09-12T04:12:09-0700,"Now that we have CAPI, do we want `{-# INCLUDE #-}` back? ",igloo 3,5834,Allow both INLINE and INLINABLE for the same function,Compiler,7.5,normal,,7.6.2,,new,2012-01-30T13:45:08-0800,2012-09-12T04:12:10-0700,"Sometimes you really want both. Here is a small example: {{{ module T where foo :: Num a => a -> a -> a foo x y = x+y+1 }}} {{{ module U where import T appl :: (a -> b) -> a -> b {-# NOINLINE appl #-} appl f x = f x bar :: Int -> Int -> Int bar x y = appl foo x y }}} If I mark `foo` as `INLINE`, then GHC generates this code for `bar`: {{{ bar1 :: Int -> Int -> Int bar1 = foo @ Int $fNumInt bar :: Int -> Int -> Int bar = \ (x_aa0 :: Int) (y_aa1 :: Int) -> appl @ Int @ (Int -> Int) bar1 x_aa0 y_aa1 }}} Whereas with `INLINABLE`, we get a nice specialisation but, of course, not guarantees with respect to inlining. In general, it seems that requiring a function to inline when it is saturated and requiring it two specialise when it isn't are two different things and shouldn't be mutually exclusive.",rl 3,5835,Make better use of known dictionaries,Compiler,7.5,normal,,7.6.2,,new,2012-01-30T14:02:11-0800,2012-09-12T04:12:10-0700,"Example: {{{ data T a where T :: Eq a => a -> T a foo :: a -> T a -> Bool {-# INLINE foo #-} foo x = \(T y) -> x == y appl :: (a -> b) -> a -> b {-# NOINLINE appl #-} appl f x = f x bar :: T Int -> Bool bar t = appl (foo 42) t }}} GHC generates this for `bar`: {{{ bar2 :: Int bar2 = I# 42 bar1 :: T Int -> Bool bar1 = \ (ds_dhk :: T Int) -> case ds_dhk of _ { T $dEq_agz y_aa4 -> == @ Int $dEq_agz bar2 y_aa4 } bar :: T Int -> Bool bar = \ (t_aga :: T Int) -> appl @ (T Int) @ Bool bar1 t_aga }}} Note how it want to get the `Eq` dictionary for `Int` from `T`. But we know the `Eq Int` instance without inspecting `T` and `bar` could be significantly simplified if we used that.",rl 3,5850,Greater customization of GHCi prompt,GHCi,7.4.1,normal,,7.6.2,,new,2012-02-06T17:50:57-0800,2012-09-12T04:12:10-0700,"GHCi is bit more than a Haskell interpreter. With the {{{:!}}} and {{{:cd}}} commands, we have trivial access to the shell, making it often unnecessary to leave GHCi. For this reason GHCi has become my *de facto* primary shell. The GHCi prompt therefore needs to show a bit more than just Haskell information. Most importantly, the current working directory is often important to me. [http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/ghci-commands.html We can indeed customize the GHCi prompt] using {{{:set prompt}}}. This takes the form of a string with a single escape sequence: {{{%s}}}, which is replaced with a list of currently loaded modules. Most shells allow arbitrary user customization of the prompt. The {{{bash}}} prompt has [http://tldp.org/HOWTO/Bash-Prompt-HOWTO/bash-prompt-escape-sequences.html numerous escape sequences for useful information], and if those aren't enough, it allows [http://tldp.org/HOWTO/Bash-Prompt-HOWTO/x279.html arbitrary command calls]. GHCi should gain similar customization abilities. Ways to implement this may include: 1. addition of more escape sequences, like {{{%pwd}}}. 2. addition of a single extra escape sequence with one parameter (an external command call), like like {{{%call(pwd --logical)}}}. 3. redesigning the {{{:set prompt}}} option to take not a {{{String}}} but a Haskell function, like {{{[Module] -> IO String}}}. Option 2 would probably have the best power-to-simplicity ratio.",JamesFisher 3,5925,Add inline version of newArray#,Compiler,7.4.1,normal,,7.6.2,,new,2012-03-09T17:26:54-0800,2013-05-10T08:58:32-0700,"It'd would be nice to have an inline version of `newArray#` so that allocation of small arrays is cheaper (e.g. the heap check could be paired up with other heap checks.) I see two possible designs: 1. Add a branch to `newArray#` that checks the requested size and either allocates inline or out-of-line. 2. Add a new primop e.g. `newSmallArray#` that always allocates inline. I would lean towards (2). While (1) is equal to (2) in the case when the size is statically known (assuming that GHC can discover that fact through enough inlining at the Cmm level), there are cases where the programmer knows that the size is small, without knowing the exact size. This happens e.g. when you use arrays to represent small variable-length tuples (e.g. in the `unordered-containers` package.)",tibbe 3,5927,"A type-level ""implies"" constraint on Constraints",Compiler (Type checker),7.4.1,normal,,7.6.2,,new,2012-03-11T09:55:32-0700,2013-03-12T08:15:26-0700,"I have a datatype: {{{ data Exists c where Exists :: c a => a -> Exists c }}} I have an instance for it: {{{ instance Show (Exists Show) where show (Exists a) = show a }}} And that's alright, as far as it goes: any Exists Show can indeed itself be shown. But I want more. I want to be able to say: {{{ instance (c `Implies` Show) => Show (Exists c) where show (Exists a) = show a }}} In other words, I want to be able to say that any (Exists c) where the constraint c implies Show can be shown. For example, if Num still had a Show constraint, I wouldn't want to have to write a separate instance Show (Exists Num) to be able to show an Exists Num; I would want to be able to write a single instance (along the lines of the above) which works for both. GHC clearly has this information: it lets me use a function of type {{{forall a. Eq a => a -> r}}} as one of type {{{forall a. Ord a => a -> r}}}, but not vice versa, so it knows that Ord implies Eq, but not vice versa. I've attached a file which demonstrates this and a couple of other examples. What's not completely clear to me is what would be the appropriate way to be able to ask it about this. An Implies constraint to parallel the (~) constraint would work, but with what syntax? (Just straightforwardly call it Implies?) And what semantics -- what would be the kind of Implies? It's notable that in the above example its arguments aren't of type Constraint, but rather * -> Constraint, and for (* -> *) -> Constraint it could similarly work, and with MPTCs * -> * -> Constraint and (* -> *) -> (* -> *) -> Constraint and * -> (* -> *) -> Constraint and so on probably also make sense... but I have no idea how to formalize this, where the boundaries lie, and whether it makes any kind of sense. I can try to think harder about it if that would help, but hopefully the outlines of the situation are more immediately obvious to someone on the GHC team.",illissius 3,5942,implement POSIX confstr() in System/Posix/Unistd.hsc,libraries/unix,7.4.1,normal,,7.6.2,,new,2012-03-14T17:49:11-0700,2012-09-12T04:12:13-0700,,clint 3,7105,Better names for derived SCCs of instances,Profiling,7.4.2,normal,,7.6.2,simonmar,new,2012-07-30T02:03:00-0700,2012-09-12T04:12:15-0700,"Currently, -fprof-auto generated SCCs are named after their function name, which isn't very helpful if you have a dozen types in Types.hs and the profile is telling you that much time is spend in ""compare"" and ""put"" in that very module. It's even more painful if those instances are derived and you can't easily add manual annotations. I suggest annotating instance declarations in general with their concrete type, such as ""compare/Foo"" and ""compare/Bar""",ksf 3,7693,Flush .hp file at the end of each sample,Runtime System,7.7,normal,,7.6.3,,merge,2013-02-15T03:16:58-0800,2013-04-12T17:03:26-0700,"Tools like hp2any-graph reads a .hp file as it's being written to. However writing to .hp files is currently block-buffered, causing a delay until the latest sample can be read. The attached patch adds a call to fflush every time a complete sample is written.",akio 3,3647,unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions,Compiler (Parser),6.10.4,normal,trivial,7.8.1,igloo,new,2009-11-07T12:19:08-0800,2012-10-25T09:28:53-0700,"it's easy to accidentally cut and paste a -XExtentionName from a ghc error message into one's {-#LANGUAGE ...#-} pragma, and then one has to track down the problem when that doesn't work. it would be nice if -XExtentionName were accepted in the pragma list. even though -X is ghc specific, i don't see that it hurts anything to be lenient in the pragma format accepted (a warning could be produced to indicate that the program will not be portable). also, the ghc error message indicating that an extension should be added should print out a message that would make for easy cut and paste without modification into *either* one's language pragma or command line -X extension args. see http://hackage.haskell.org/trac/ghc/ticket/3616#comment:8.",eflister 3,4259,Relax restrictions on type family instance overlap,Compiler (Type checker),6.12.1,normal,,7.8.1,,new,2010-08-16T07:43:56-0700,2013-04-04T10:06:11-0700,"The following reduced fragment of some real code is rejected, but could be accepted, by GHC: {{{ {-# LANGUAGE TypeFamilies, EmptyDataDecls #-} data True type family LessEq a b :: * type instance LessEq a a = True type instance LessEq (f a) (f b) = LessEq a b }}} GHC says: {{{ Conflicting family instance declarations: type instance LessEq a a -- Defined at /home/richards/.random/tf.hs:5:14-19 type instance LessEq (f a) (f b) -- Defined at /home/richards/.random/tf.hs:6:14-19 }}} This is entirely in line with the documentation, which requires the RHS to be structurally equivalent in the case of overlap. However, this rule is too restrictive. In the absence of -XUndecidableInstances, neither termination nor soundness would be sacrificed if the rule were relaxed to require extensional equality /after/ expanding the types as far as possible. In particular (absent -XUndecidableInstances), such an expansion must terminate for the same reason that type families terminate in general. For soundness, suppose the resulting system is unsound, and consider the smallest type family application which has two possible distinct expanded types. We know the RHS of those types are equal after a partial expansion of only smaller (hence sound by minimality) type family applications, resulting in a contradiction. In order to retain soundness in the presence of -XUndecidableInstances, any pair of type instances, where either instance could not be compiled without -XUndecidableInstances, would continue to use the current syntactic equality rule.",lilac 3,5941,Add compilation stage plugins,Compiler,7.4.1,normal,,7.8.1,,new,2012-03-14T17:25:28-0700,2012-09-27T04:58:09-0700,"There are several different tools that could be written using one of GHC's intermediate ASTs, like the post type-checking `HsSyn Id`. These can today be written as separate programs, using the GHC API. An example of such a program would be a CTAGS-on-steroids tool that would let you, as part of compilation, output a file containing all the names in the program, together with their source locations and types. This file could then be used to implement a type and qualified names aware grep. However, compiling every file twice, once normally and once using this hypothetical tool, just to get that additional output file, is wasteful. It would be better if we could specify a plugin that would run at one of a few well defined places in the pipeline e.g. after renaming or type checking. Those plugins could be passed the data structures (e.g. `HsSyn Id`) created by GHC and then perform some arbitrary action (e.g. write to a file or modify the AST.)",tibbe 3,5972,option to suppress (Monomorphic) record selector functions,Compiler,,normal,,7.8.1,igloo,new,2012-03-27T15:32:41-0700,2012-10-07T09:00:27-0700,"This proposal is a modest step towards freeing up the record fieldname namespace, without in any way pre-judging how the 'narrow namespace issue' might get addressed. There is to be a compiler flag (suggestion) -XNoMonoRecordFields. (Default value ‑XMonoRecordFields, to give H98 behaviour.) -XNoMonoRecordFields suppresses creating the field selector function from the field name in a record-style data declaration. Suppressing the function frees up the namespace, to be able to experiment with various record/field approaches -- including the 'cottage industry' of Template Haskell solutions. In particular, this means we can declare more than one record type within a module using the same field name. For background, details, use cases, see: http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/NoMonoRecordFields (Contrast ticket #3356 {-# LANGUAGE NoTraditionalRecordSyntax #-}, which suppresses far too much (IMHO).)",AntC 3,6018,Injective type families,Compiler,7.4.1,normal,,7.8.1,simonpj,new,2012-04-18T09:22:24-0700,2013-04-05T09:21:56-0700,"Injective type families have been discussed several times on the mailing list and identified as a potentially useful feature. I've naively attempted a proof-of-concept in GHC. It's almost certainly incorrect and probably breaks the type system, but I thought it best to put it here and see if it can be made workable. In summary, my changes are: * Add a new keyword, {{{injective}}}, which is available only when the {{{TypeFamilies}}} extension is enabled. Injective families may then be defined thus: {{{ injective family F a :: * type instance F Int = Bool type instance F Bool = Int injective family G a :: * type instance G a = a }}} Syntax is of course completely changeable; I've simply picked one of the possible designs. Hopefully this won't be subjected to too much bike-shedding. * Add the constructor {{{InjFamilyTyCon}}} to {{{TyConRhs}}} and the family flavour {{{InjectiveFamily}}} to {{{HsSyn}}}. Again, I've opted to encode injectivity as a flavour rather than (say) a {{{Bool}}} attached to type families. This is a completely arbitrary choice and may be utterly stupid. * Altered the definition of decomposable {{{TyCon}}}s to include injective families ({{{isDecomposableTyCon}}}). This effectively introduces a typing rule that says if we have {{{(F a ~ F b)}}} then we can deduce {{{(a ~ b)}}} ({{{TcCanonical}}}). * Modified the unifier so that it will attempt to replace saturated injective families with their left-hand sides where possible ({{{TcUnify}}}). This means that in a function such as: {{{ f :: F a -> F a f = ... }}} The type of {{{f False}}} is inferred as {{{F Int}}} (i.e., {{{a}}} is no longer ambiguous). Some things work, some things don't. For example, the attached file typechecks, but if I actually try to evaluate {{{f False}}} I get nothing (not even a Segmentation fault). See what you think. ",lunaris 3,6024,"Allow defining kinds alone, without a datatype",Compiler (Type checker),7.5,normal,,7.8.1,,new,2012-04-19T09:12:01-0700,2013-01-25T07:52:58-0800,"Sometimes we want to define a kind alone, and we are not interested in the datatype. In principle having an extra datatype around is not a big problem, but the constructor names will be taken, so they cannot be used somewhere else. A contrived example: {{{ data Code = Unit | Prod Code Code data family Interprt (c :: Code) :: * data instance Interprt Unit = Unit1 data instance Interprt (Prod a b) = Prod1 (Interprt a) (Interprt b) }}} We're only interested in the constructors of the data family `Interprt`, but we cannot use the names `Unit` and `Prod` because they are constructors of `Code`. The suggestion is to allow defining: {{{ data kind Code = Unit | Prod Code Code }}} Such that `Code` is a kind, and not a type, and `Unit` and `Prod` are types, and not constructors. Note that using ""data kind"" instead of just ""kind"" means the word ""kind"" does not have to be a reserved keyword. You could also think you would want to have datatypes that should not be promoted: {{{ data K data type T = K }}} But I don't see a need for this, as the fact that the `K` constructor is promoted to a type does not prevent you from having a datatype named `K`.",dreixel 3,6084,Add stg_ap_pnnv and related call patterns,Runtime System,7.4.1,normal,,7.8.1,simonmar,infoneeded,2012-05-08T04:49:44-0700,2013-03-26T10:10:12-0700,"In the implementation of bytestring encoding and decoding libraries, the call patterns stg_ap_pnnv and stg_ap_nnv occur very often. These call patterns are required to avoid boxing the pointers denoting the start and end of the memory area to write to/read from. The first 'p' often stems from using continuation passing style or from a record of configuration paramters. For example, the type of a bytestring builder looks about as follows. {{{ newtype Builder = Builder ((Addr# -> Addr# -> IO BuildSignal) -> Addr# -> Addr# -> IO BuildSignal) }}} The first Addr# is the pointer to the next free byte and the second Addr# is the pointer to the first byte after the buffer being filled. The current implementation of the bytestring builder in the bytestring-0.10. library however uses {{{ newtype Builder = Builder ((Ptr Word8 -> Ptr Word8 -> IO BuildSignal) -> Ptr Word8 -> Ptr Word8 -> IO BuildSignal) }}} as the benchmarks demonstrated that the repeated boxing is cheaper than the unknown calls implemented through a series of stg_ap_p, stg_ap_n, stg_ap_n, stg_ap_v calls. I therefore suggest adding the following call patterns ppnnv, pnnv, nnv, and nv. to allow more efficient implementations of bytestring and text decoding/encoding. Note that the 'ppnnv' is used for a constant environment, a continuation, and a range resulting in a side-effecting function.",SimonMeier 3,6089,Allow declaration splices inside declaration brackets,Template Haskell,7.4.1,normal,,7.8.1,simonpj,new,2012-05-11T07:08:48-0700,2012-10-09T10:29:07-0700,"I would like to be able to write code like: {{{ {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH decs :: Q [Dec] decs = [d| data MyType = MyCon | MyOtherCon val1 :: MyType val1 = MyCon val2 :: MyType val2 = MyOtherCon $( do let mkFun v i = [| if $v == i then val1 else val2 |] [d| fun3 x = $(mkFun [| x |] 3) fun4 x = $(mkFun [| x |] 4) |] ) |] }}} but GHC says: {{{ $ ghci decSplices.hs GHCi, version 7.5.20120420: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( decSplices.hs, interpreted ) decSplices.hs:15:15: Declaration splices are not permitted inside declaration brackets Failed, modules loaded: none. }}} As far as I can see there is no technical reason why this couldn't work, with a splice within a declaration bracket splitting the declarations into 3. The declarations before the splice would be renamed, typechecked etc first, then those in the splice, and finally those after the splice. ",igloo 3,6135,Unboxed Booleans,Compiler,7.4.1,normal,,7.8.1,jstolarek,patch,2012-05-31T00:22:48-0700,2013-05-22T12:45:05-0700,"Right now the only way to compare two integers is with primops that produce boxed bools: {{{ <# :: Int# -> Int# -> Bool ==# :: Int# -> Int# -> Bool }}} To consume the resulting {{{Bool}}} we need a case-expression, which introduces branches into the core IR and object code. Case expressions are bad in the presence of heavy inlining because case-of-case performed by the GHC simplifier tends to duplicate code (like in DPH and Repa programs). Mis-predicted branches are bad in object code because they stall the pipeline. Consider the following expression: {{{ case x <# 0# || x >=# aWidth || y <# 0# || y >=# aHeight of True -> ... False -> ... }}} This is very common in array programming. Ideally, it should turn into some straight-line code to compute the flag, and then a single branch instruction once we've worked out what alternative to take. However, as the only way to consume the {{{Bool}}}s produced by the comparisons is to introduce more case expressions, we end up with *four* cases in the core IR. What I want is this: {{{ data Bool# (.<#) :: Int# -> Int# -> Bool# (.==#) :: Int# -> Int# -> Bool# (.||#) :: Bool# -> Bool# -> Bool# case x .<# 0# .||# x .>=# aWidth .||# y .<# 0# .||# y .>=# aHeight of True# -> ... False# -> ... }}} Bool# is the type of one bit integers. I can compute with them algebraically and be sure that I'll get at most one branch instruction in the resulting object code. ",benl 3,7015,Add support for 'static',Compiler,7.4.2,normal,,7.8.1,,new,2012-06-20T02:25:05-0700,2012-10-14T09:12:24-0700,".. as described in ""Towards Haskell in the Cloud"".",edsko 3,7021,Tuple (and other exotic predicates) not yet handled in Template Haskell,Template Haskell,7.5,normal,,7.8.1,,new,2012-06-21T12:09:27-0700,2012-10-11T14:12:13-0700,"Say I make the following declarations: {{{ {-# LANGUAGE ConstraintKinds #-} type IOable a = (Show a, Read a) foo :: IOable a => a foo = undefined }}} It is currently impossible to {{{reify}}} {{{foo}}} in Template Haskell. This also comes up when using nested lists of constraints in Template Haskell quotes.",goldfire 3,7048,Add the ability to statically define a `FunPtr` to a haskell function,Compiler,7.4.2,normal,,7.8.1,,new,2012-07-04T08:52:49-0700,2012-11-26T04:20:03-0800,"Lauri Alanko [http://haskell.1045720.n5.nabble.com/Static-non-exported-stubs-td5713489.html suggests] that there should be a way to define a callback to a haskell function statically (i.e. without using a dynamic wrapper). It is currently possible to do so only by exporting the function and reimporting it as a function pointer: {{{ foreign export ccall ""my_callback"" myCallback :: IO () foreign import ccall ""&my_callback"" myCallbackPtr :: FunPtr (IO ()) }}} but of course this not ideal because it creates an extra symbol (and is quirky). A possible new syntax could be: {{{ foreign import ccall myCallbackPtr :: FunPtr (IO ()) = myCallback }}} or variations thereof. We probably want to keep `import` (rather than `export` or some new keyword), since this declaration brings something into scope, like a normal FFI import.",pcapriotti 3,7081,arrow analogs of lambda case and multi-way if,Compiler,7.5,normal,,7.8.1,,new,2012-07-16T12:01:46-0700,2012-10-14T10:41:52-0700,"GHC has now support for lambda case and multi-way if (see ticket #4359). It would be good if arrow variants of these features would be implemented. There are three things that should be considered: Lambda case expressions should have analog {{{proc}}} expressions where {{{ proc case pat_1 -> cmd_1 ... pat_n -> cmd_n }}} desugars to {{{ proc fresh -> case fresh of pat_1 -> cmd_1 ... pat_n -> cmd_n }}} Lambda case expressions should also have analog arrow commands where {{{ \ case pat_1 -> cmd_1 ... pat_n -> cmd_n }}} desugars to {{{ \ fresh -> case fresh of pat_1 -> cmd_1 ... pat_n -> cmd_n }}} Multi-way if expressions should have analog arrow commands where {{{ if | cond_1 -> cmd_1 ... cond_n -> cmd_n }}} desugars to {{{ case () of _ | cond_1 -> cmd_1 ... | cond_n -> cmd_n }}} Identifiers {{{pat_i}}}, {{{cond_i}}}, and {{{cmd_i}}} denote patterns, boolean expressions, and arrow commands, respectively. Bug #7071 has to be fixed before starting with this ticket.",jeltsch 3,7104,Add tryWriteTBQueue to Control.Concurrent.STM.TBQueue,libraries (other),7.4.2,normal,,7.8.1,simonmar,new,2012-07-29T20:38:09-0700,2012-10-14T10:55:39-0700,"I'd like a ""try"" variant of writeTBQueue, so part of my application can react to the queue overflowing by returning a ""queue is full"" status. Attached is a series of patches, the last of which adds {{{writeTBQueue}}}. The other patches fix a couple minor issues: * Force capacity computations, so a long series of {{{readTBQueue}}} calls won't lead to a stack overflow. * Guard against negative queue size given to {{{newTBQueue}}} and {{{newTBQueueIO}}}. ---- While we're at it, I have a couple general questions about retry and orElse: * Is {{{atomically (retry `orElse` return ())}}} guaranteed to not be interruptible by an asynchronous exception when exceptions are masked? * Is there a performance benefit to avoiding retry when possible? I'd imagine not, since this should only involve throwing away a few transaction log entries. If {{{atomically (retry `orElse` return ())}}} is guaranteed to not be interruptible, and if there is no performance benefit to avoiding retry, then it seems there's little point in having any of the try* functions. In the documentation for Control.Exception, it lists operations that are guaranteed to not be interruptible. One of them is: * STM transactions that do not use retry This is a useful property, and is expected of any ""try"" function. However, {{{tryReadTBQueue}}} ""uses"" {{{retry}}}. I did a quick test, and it looks like {{{atomically (retry `orElse` return ())}}} is not interruptible: {{{ import Control.Concurrent import Control.Concurrent.STM import Control.Exception import Control.Monad repeatSTM :: STM () -> IO () repeatSTM = replicateM_ 50000000 . atomically main :: IO () main = do finished <- newEmptyMVar tid <- mask_ $ forkOS $ do repeatSTM (retry `orElse` return ()) putMVar finished () threadDelay 100000 killThread tid -- should wait for the thread to run to completion putStrLn ""Let's see if the thread finished..."" takeMVar finished putStrLn ""Yes, it did."" }}} Is this guaranteed in general? That is, if the transaction does retry calls, but the transaction as a whole does not retry due to orElse, is the transaction guaranteed to not be interruptible?",joeyadams 3,7140,Allow type signature in export list,Compiler (Type checker),,normal,,7.8.1,,new,2012-08-13T08:54:27-0700,2012-10-16T06:13:43-0700,"In response to the new InstanceSigs extension in the 7.6.1 RC1, waterlight on Reddit suggested the following: ""While we're at it, why not also allow type signatures in export lists? People tend to add them anyway as comments, just because it's useful documentation. Checking for consistency would be nice."" The desired syntax, therefore, is something like this: {{{ {-# LANGUAGE ExportSigs #-} module Foo ( foo :: Bar -> Baz , Blah ( Blip :: a -> Blah a , Bloop :: Blah Int ) , Quux ( quux :: Quux q => a -> q a , qux :: Quux q => q (q ()) ) ) where ... }}} where all of the type annotations here are optional, and can be '''no less restrictive''' than the corresponding type signatures provided at the definition site, if provided (whether that be in that file's own code, or imported from another file). This would have non-trivial interaction with -fno-warn-missing-signatures, and consequently, with #2526. There may also be non-trivial interaction with GADTs, if we allow exported constructors to be annotated with a type signature. This idea was vaguely referenced by #1404, to which igloo responded: ""Type sigs in export lists might be nice, as some people seem to like giving them as comments which then get out of sync with the actual types."" If we are to consider this sort of thing for Haskell', we should try it out as a GHC extension first.",drb226 3,7158,GHCi commands case insensitive,GHCi,7.6.1-rc1,normal,,7.8.1,,new,2012-08-17T09:21:11-0700,2012-11-16T08:15:22-0800,"Because GHCi commands start with a colon, it frequently happens to me that my shift key is still down and I accidentally type :R instead of :r, which gives an error. I'm not sure how common this is, but I've seen at least one more person do it. As it seems unlikely that people define commands that differ only by case, it might be an option to disregard the case altogether when parsing the commands.",Oblosys 3,7169,Warning for incomplete record field label used as function,Compiler,7.7,normal,,7.8.1,,new,2012-08-20T07:37:12-0700,2013-04-24T06:28:27-0700,"Consider the following definition: {{{ data Foo = Bar { frob :: Int } | Baz { frob :: Int, quux :: Bool } }}} It would be great if GHC could produce a warning if I use {{{quux}}} as a function somewhere in my code, as calling {{{quux}}} on a {{{Foo}}} constructed with {{{Bar}}} will cause a runtime error. On the other hand, every use of {{{frob}}} is OK. Currently, to find such problems, I have to first figure out which field labels are incomplete and then search for those, ignoring their uses as a proper field label (in construction or pattern matching).",goldfire 3,7181,Add documentation on heap-profile file format.,Documentation,7.4.2,normal,,7.8.1,,new,2012-08-23T06:30:35-0700,2012-10-20T13:53:05-0700,"GHC docs currently lack of .hp file format specification. This trends people to make incorrect assumptions on file format. For example authors of hp2any-core package attemt to use haskell read function to read job title, but actually profiler outputs unescaped values between quotation marks, so approach fails when quoted string contains backslashes. I suggest to add more documentation on file format, especially how numeric values, strings and dates represented.",schernichkin 3,7204,Use a class to control FFI marshalling,Compiler,7.4.2,normal,,7.8.1,,new,2012-08-31T03:54:42-0700,2012-10-15T17:53:10-0700,"There has been a string of tickets concerning argument/result types for `foreign` declarations: #3008, #5529, #5610, #5664. This ticket suggest a new idea that Simon and I came up with this morning. The current story is that a `newtype` can only be used in an FFI decl if the newtype's data constructor is in scope. This is enshrined in the FFI spec, but it's inconvenient and somewhat controversial. But suppose instead the ability to be passed to a `foreign` call was controlled by a class? Thus {{{ class Marshal a where type RepType a marshal :: a -> RepType a unMarshal :: RepType a -> a instance Marshal Int where type RepType Int = Int marshal = id unMarshal = id newtype Age a = MkAge a instance Marshal a => Marshal (Age a) where type RepType (Age a) = RepType a marshal (Age x) = marshal x unMarshal x = Age x }}} An author can control whether a newtype is marshalable by making it an instance of `Marshal` (or not). Moreover `newtype deriving` will work just fine on class `Marshal` so you can write {{{ newtype Age a = MkAge a deriving( Marshal ) }}} The FFI stub generation machinery would do the following. Given a declaration {{{ foreign import foo :: T -> IO S }}} it will generate a Haskell `foo` thus: {{{ foo :: T -> S foo t = case (marshal t) of I# x# -> case ""ccall foo x#"" of r# -> unMarshal (F# r#) }}} (I'm being a bit sloppy about the IO part, becuase it's not part of the main point here.) In this example I've assumed that (after some type-level reductions) {{{ RepType T = Int RepType S = Float }}} but it should be OK provided the `RepType T` reduces to one of a fixed set of primitive types that GHC knows how to marshal. So the rules become that an argument type `T` must satisfy two conditions: * `T` must be an instance of `Marshal` * `(RepType T)` must reduce to one of a fixed family of primitive types, `Int`, `Float` and so on. ",simonpj 3,7253,Top-level bindings in ghci,GHCi,7.6.1,normal,,7.8.1,,new,2012-09-19T05:12:53-0700,2012-10-14T20:15:29-0700,"ghci now supports most of the declarations. However, it doesn't support the most basic and common type of declaraion — pattern and function bindings! E.g. {{{ Prelude> a = 1 :2:3: parse error on input `=' }}} I realise that, if implemented, they would have somewhat different semantics than in Haskell modules — e.g. with respect to recursion. But even if they behaved in the same way as top-level monadic let-bindings, they would still be very useful for two reasons: 1. If you're doing quick experiments in ghci, ""let a=1"" is more than twice as long as ""a=1"", and that makes a difference. 2. Novices are often confused when they are told that they have to use one syntax for definitions in modules and another in ghci. ",Feuerbach 3,7263,Add derived Show instances to GHC.Generics,GHC API,7.7,normal,,7.8.1,dreixel,new,2012-09-23T05:30:13-0700,2012-10-15T18:05:02-0700,This would make it easier to learn to use generics by exploration from GHCi.,dag 3,7275,Give more detailed information about PINNED data in a heap profile,Compiler,7.6.1,normal,,7.8.1,igloo,new,2012-09-28T05:36:36-0700,2012-10-15T18:00:21-0700,"This is particularly useful when tracking down memory leaks due to retaining (sub)bytestrings which themselves retain larger bytestrings. At the moment, all the profile tells us is that this memory is ""PINNED"" but it doesn't give us any info at all as to where the memory was allocated.",edsko 3,7283,Specialise INLINE functions,Compiler,7.7,normal,,7.8.1,,new,2012-09-30T16:13:18-0700,2013-04-12T07:54:50-0700,"Quick summary: At the moment, INLINE means inline a function if it is fully applied and '''don't use its unfolding''' otherwise. I think we might want to change this to INLINE a function if it is fully applied and '''treat it as to INLINABLE''' otherwise. Here is a small example: {{{ module T where f :: Num a => a -> a {-# INLINE [1] f #-} f = \x -> x+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1 g :: Num a => a -> a {-# INLINE [1] g #-} g x = x+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2+2 h :: Num a => a -> a {-# INLINABLE [1] h #-} h x = x+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3+3 apply :: (a -> b) -> a -> b {-# NOINLINE apply #-} apply f x = f x }}} {{{ module U where import T ff :: Int -> Int -> Int ff x y = apply f x + apply f y gg :: Int -> Int -> Int gg x y = apply g x + apply g y hh :: Int -> Int -> Int hh x y = apply h x + apply h y }}} With -O2 -fno-cse (CSE does optimise this example but doesn't solve the problem of intermediate code bloat), GHC produces the following: * The RHS of `f` is duplicated since it is inlined twice - '''bad'''. * `g` is neither inlined nor specialised since it isn't fully applied - '''bad'''. * `h` is specialised but its RHS isn't duplicated - '''good'''. But of course, `h` isn't guaranteed to be inlined even if it is fully applied which, in the real-world examples I have in mind, is '''bad'''. I think `INLINE [n] f` should mean that: 1. `f` will always be inlined if it is fully applied, 2. `f` will be specialised when possible, 3. specialisations of `f` will also be `INLINE [n]`. I don't think it's possible to achieve this effect at the moment. If we treated `INLINE [n]` as `INLINABLE [n]` until the function is fully applied, we would get exactly this, though, except for 3 which probably isn't too hard to implement. Now, if I understand correctly, INLINABLE also means that GHC is free to inline the function if it wants but the function isn't treated as cheap. I think it would be fine if we did this for unsaturated `INLINE` functions rather than not inlining them under any circumstances. The original motivation for only inlining when fully applied was code bloat in DPH. But IIRC that only happened because INLINE functions were always cheap and so GHC was very keen to inline them even when they weren't saturated which wouldn't be the case with my proposal. We would have to check how this affects DPH and related libraries, though.",rl 3,7285,mkWeakMVar is non-compositional,Compiler,7.6.1,normal,,7.8.1,,new,2012-10-01T04:29:55-0700,2013-03-11T05:10:32-0700,"In base 4.6 `addMVarFinalizer` is deprecated in favour of `mkWeakMVar` of type {{{ mkWeakMVar :: MVar a -> IO () -> IO (Weak (MVar a)) }}} This type makes it inherently non-compositional. For instance, if we have a larger datatype T that contains an MVar somewhere inside then there in no way to define mkWeakT in terms of mkWeakMVar; instead, mkWeakT would have to be defined along the lines of {{{ mkWeakT :: T a -> IO () -> IO (Weak (T a)) mkWeakT m@(MkT (MVar m#) _) f = IO $ \s -> case mkWeak# m# m f s of (# s1, w #) -> (# s1, Weak w #) }}} It would be better if the type of mkWeakMVar would change to {{{ mkWeakMVar :: MVar a -> v -> Maybe (IO ()) -> IO (Weak v) }}} (i.e., following `mkWeak` rather than `mkWeakPtr`). (The same comment goes for related functions such as mkWeakIORef.)",edsko 3,7330,Data Parallel Haskell (DPH) isn't usable yet.,Compiler,7.6.1,normal,,7.8.1,benl,new,2012-10-14T20:20:53-0700,2012-10-15T17:57:04-0700,"This is a place holder ticket for people that try to use DPH and find problems or missing features. DPH is still deeply experimental, and we don't expect you to be able to do anything useful with it yet. However, it may work well enough to compile and run programs, depending on your particular example. The compiled executables are likely to work, but they will be very slow (like 10 - 100x slower than they should be). If you'd like to try DPH out anyway then feel free to give it a shot. Further questions and comments should be directed to benl@ouroborus.net. No need to open a ticket here in the GHC trac. ",benl 3,7331,Allow the evaluation of declaration splices in GHCi,GHCi,7.6.1,normal,,7.8.1,,new,2012-10-14T20:48:29-0700,2013-04-12T08:50:09-0700,"As it stands GHCi cannot evaluate declaration splices because all splices are assumed to be expression splices: {{{ > $( [d| a = True |] ) :1:4: Couldn't match expected type `Language.Haskell.TH.Syntax.Exp' with actual type `[Language.Haskell.TH.Syntax.Dec]' ... }}}",parcs 3,7335,Need for extra warning pragma for accidental pattern matching in do blocks,Compiler,7.6.1,normal,,7.8.1,,new,2012-10-16T00:18:30-0700,2013-04-12T08:55:36-0700,"There are a few functions (actually monadic actions) where it's almost always an error to pattern match on the result, e.g.: {{{ (x,y) <- rpar $ ... -- this is wrong! (x,y) <- unsafeInterleaveIO $ ... -- this is also wrong! }}} We can help users by warning when they do this. To do this sensibly we would need a new warning pragma. Here's a suggestion: {{{ {-# WARN_DO_PATTERNMATCH unsafeInterleaveIO ""You don't want to use pattern matching directly on the result of unsafeInterleaveIO because that will immediately force the IO to be done, defeating the intention of lazily deferring it."" #-} unsafeInterleaveIO :: IO a -> IO a unsafeInterleaveIO = ... {-# WARN_DO_PATTERNMATCH rpar ""You don't want to use pattern matching directly on the result of rpar because that will immediately wait for the result to be evaluated, defeating the intention of doing it in parallel."" #-} par :: Strategy a par = ... }}} The warning message should probably suggest using a ~ lazy irrefutable match. Perhaps that bit of the message should be generated rather than taken from the string in the pragma, since it can provide the actual pattern the user used, with the extra ~. As far as I can tell, this is only needed in a 'do' context, not a pure 'case' context.",duncan 3,7337,GHC does not generate great code for bit-level rotation,Compiler,7.6.1,normal,,7.8.1,,new,2012-10-16T11:38:46-0700,2013-04-12T08:56:07-0700,"I'm working on some hashing functions at the moment, and I notice that GHC generates an {{{or}}} and a pair of shifts for a rotate. The LLVM back end is smart enough to recover the code's intent via strength reduction and emit a single {{{rot}}} instruction, but the regular code generator emits three instructions.",bos 3,7346,Allow the use of `deriving` for GHC generics,Compiler,7.7,normal,,7.8.1,dreixel,new,2012-10-19T03:24:59-0700,2013-04-12T09:14:32-0700,"Currently, a class that makes use of generic default methods (via the `DefaultSignatures`) extension can be instantiated by providing an empty instance declaration. I propose to allow the use of `deriving` as well: 1. Standalone deriving should be usable for a class not only for the specific set of classes supported by GHC now, but in addition for any class, if ( * there's at least one generic default given for a method of the class, and * there are generic or normal default implementations for *all* methods of the class. There are a number of advantages of this solution over the empty instance declaration: we make it explicit that something generic is going on here; we ensure at compile time that we're not missing an implementation of a method; and we come syntactically closer to built-in derivable classes. In cases where a conflict arises between current GHC semantics and the proposed semantics (for example, when newtype-deriving is involved, I guess), I propose to stick with current GHC semantics, but I'm open for other suggestions. 2. I'd also like for normal `deriving` to be useful under the same conditions as above. For normal `deriving` GHC has to figure out the class context automatically. I propose that if normal `deriving` is used, GHC uses the same heuristic for figuring out the class context that it uses for `Eq` in the case of `*`-kinded classes, and for `Functor` in the case of `* -> *`-kinded classes. That may not be optimal or even wrong. But in such cases, standalone deriving can still be used.",kosmikus 3,7395,DefaultSignatures conflict with default implementations,Compiler,7.6.1,normal,,7.8.1,,new,2012-11-05T11:05:29-0800,2013-04-12T11:13:53-0700,"Default signatures cannot be used with default implementations. This is quite annoying for the hashable package, as we'd like to provide both options to the user. See the attached test case.",cgaebel 3,7401,"Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.",Compiler,7.6.1,normal,,7.8.1,,infoneeded,2012-11-09T00:33:40-0800,2013-04-14T05:25:01-0700,"On a ""phantom datatype"" D, one gets the message: {{{ Can't make a derived instance of `Eq D': `D' must have at least one data constructor }}} However there is a trivial, correct instance of Eq D: {{{ instance Eq D where (==) = undefined }}} ",jpbernardy 3,7413,runghc (runhaskell) should be able to reload code on editing,Compiler,7.6.1,normal,,7.8.1,,new,2012-11-13T13:00:22-0800,2013-04-12T11:46:24-0700,"Hot code reloading on file edit is an incredibly useful feature for server development. Right now several Haskell web frameworks are able to reload code on file edits, however there does not seem to be a simple way to use code reloader from one of them without finding yourself up to the neck in the framework. It seems to me that the best thing what can be done is a flag to runghc / runhaskell: {{{ runghc --reload MyServer.hs }}} It should watch for changes in the main file and all imported modules (or at least imported modules in the current folder). A nice addition would be an ability to specify more files to watch {{{ runghc --reload-watch *.some.weird.haskell.js --reload MyServer.hs }}} ",va1en0k 3,7414,plugins always trigger recompilation,Compiler,7.6.1,normal,,7.8.1,,new,2012-11-13T16:29:15-0800,2013-04-12T11:53:34-0700,"When compiling code with a ghc plugin, e.g. '''ghc -O -fplugin SomePlugin Main.hs''', recompilation is triggered for every module. This can make plugins difficult to use in environments with many modules shared between executables. Since a plugin is a GHC library, I would like to propose that plugin arguments and interface hashes be included in the dependencies for compiled modules, in a similar way to how compiler flags are already included. This would enable ghc to avoid recompilation of modules when using plugins, provided that the plugin and plugin options haven't changed.",jwlato 3,7427,Proposal: Add setEnv/unsetEnv to System.Environment,libraries/base,7.6.1,normal,,7.8.1,,patch,2012-11-18T11:29:25-0800,2013-04-28T04:23:15-0700,"I propose to add setEnv/unsetEnv to System.Environment, so that it is easier to write applications that behave the same on POSIX and Windows systems. Here is the [http://www.haskell.org/pipermail/libraries/2012-October/018560.html corresponding thread] on the libraries mailing list. The proposal was overall supported. A patch is attached.",SimonHengel 3,7459,deriving Generic does not work with TypeLits,Compiler,7.6.1,normal,,7.8.1,dreixel,new,2012-11-29T07:35:56-0800,2013-04-12T13:28:41-0700," {{{ {-# LANGUAGE DataKinds, KindSignatures #-} {-# LANGUAGE DeriveGeneric #-} import GHC.TypeLits import GHC.Generics data F (a :: Symbol) data X = X (F ""hello"") deriving Generic }}} Trying to derive Generics instance for simple datatype with Symbol inside but GHC complains: {{{ Can't make a derived instance of `Generic X': X must not have unlifted or polymorphic arguments In the data declaration for `X' }}} I found that this could be fixed by adding single line to isTauTy: {{{ --- a/compiler/typecheck/TcType.lhs +++ b/compiler/typecheck/TcType.lhs @@ -899,6 +899,7 @@ mkTcEqPred ty1 ty2 isTauTy :: Type -> Bool isTauTy ty | Just ty' <- tcView ty = isTauTy ty' isTauTy (TyVarTy _) = True +isTauTy (LitTy _) = True isTauTy (TyConApp tc tys) = all isTauTy tys && isTauTyCon tc isTauTy (AppTy a b) = isTauTy a && isTauTy b isTauTy (FunTy a b) = isTauTy a && isTauTy b }}} ",maxtaldykin 3,7492,Generic1 deriving: Can we replace Rec1 f with f :.: Par1?,Compiler,7.7,normal,,7.8.1,dreixel,new,2012-12-09T12:17:06-0800,2013-04-12T14:01:17-0700,"It seems like `Rec1 f` is isomorphic to `f :.: Par1`. Is it possible and beneficial to replace the former with the latter and deprecate/remove `Rec1`? 1. Currently, a parameter type is found in `Par1` or `Rec1`. By removing `Rec1`, there would be only one place for parameters. This simplifies generic functions. 2. It is in the interest of reducing redundancy in the representation, something that appears to be consistent with the design of the representation types (e.g. using the same type for multiple meanings).",spl 3,7494,Allow compatible type synonyms to be the return type of a GADT data constructor.,Compiler (Type checker),7.4.1,normal,,7.8.1,,new,2012-12-10T07:23:32-0800,2013-04-12T14:04:50-0700,"Please consider adding support for something like: {{{ {-# LANGUAGE GADTs #-} data Steps s y where Yield :: y -> FK s y -> FK s y Done :: Steps s y newtype M y s a = M { unM :: (a -> FK s y) -> FK s y } type FK s y = s -> Steps s y }}}",topi 3,7495,Rebindable list syntax?,Compiler,7.6.1,normal,,7.8.1,,new,2012-12-10T14:20:31-0800,2013-04-12T14:08:39-0700,"First, sorry if I've missed an earlier request for this in trac; a few searches did not turn up anything relevant. I've recently taken to doing a lot of work with heterogenous lists (thanks to the DataKinds work) and find the forced-cons-and-nil style of writing lists (e.g. ""a:+b:+c:+HN"") to be sort of unpleasant. Would it be possible to allow rebinding list-literal syntax? Off the top of my head I think something like the following might be workable, if only I could stop [] and (:) from being in scope, even with -XNoImplicitPrelude. (Example requires -XDataKinds -XFlexibleInstances -XGADTs -XMultiParamTypeClasses -XTypeOperators) {{{ class HasNil a where ([]) :: a isNil :: a -> Bool class HasCons e l l' | e l -> l', l' -> e l where (:) :: e -> l -> l' uncons :: l' -> Maybe (e,l) -- For homogeneous lists... instance HasNil [a] where ([]) = ([]) isNil = null instance (a ~ a1, a ~ a2) => HasCons a [a1] [a2] where (:) = (:) uncons [] = Nothing uncons (x:xs) = Just (x,xs) -- For HLists... data HList as where HN :: HList '[] (:+) :: a -> HList as -> HList (a ': as) instance HasNil (HList '[]) where ([]) = HN isNil = const True instance (a ~ a1, as ~ as1) => HasCons a (HList as) (HList (a1 ': as1)) where (:) = (:+) uncons (a :+ as) = Just (a,as) }}}",nwf 3,7509,Changing the second prompt. :{ modules| No setting available to change.,Compiler,7.6.1,normal,,7.8.1,igloo,new,2012-12-18T22:30:14-0800,2013-04-12T16:00:35-0700,"In order to change the main prompt it's as simple as a single command. {{{ :set prompt ""> "" }}} However, in order to change the second prompt, you'd have to go into the ghci source code, and remove code or wrap existing code to add a switch/configuration for it. Example.. {{{ > :{ Prelude| }}} As of the reason to having a configurable prompt, when you have many modules, this list can become annoying fast and so many have disabled showing the modules. Yet we can't do this with the second prompt.",m30w 3,7544,GHC downloads are unsigned,Build System,7.6.1,normal,,7.8.1,igloo,new,2013-01-02T00:12:34-0800,2013-04-12T15:11:00-0700,"Hi, I recently came across a feature that is patched in 7.6 but not in 7.4; cause to upgrade. The Haskell website has binary downloads, ie http://www.haskell.org/ghc/download_ghc_7_6_1#x86_64linux but there are no SHA1 hashes or GPG signatures. This may seem like busy work, but it's important to know who is building software and how it was built. Would it be possible to first of all post md5sums or sha1sums of the builds, and then down the road get that file GPG signed by someone responsible for the process? Not sure where best to file this; sorry for noise if this is the wrong place. AfC",afcowie 3,7606,Stride scheduling for Haskell threads with priorities,Runtime System,7.7,normal,,7.8.1,ezyang,new,2013-01-18T02:10:18-0800,2013-04-23T08:24:53-0700,"Currently, GHC uses a round-robin scheduler for Haskell threads, with some heuristics for when threads should be bumped to the front of the queue. This patch set replaces this scheduler with 'stride scheduling', as described by Waldspurger and Weihl '95, which is an efficient, deterministic method for scheduling processes with differing priorities. Priorities are assigned by giving 'tickets' to threads; a thread with twice as many tickets as another will run twice as often. I’d like to replace the round-robin scheduler completely with this scheduler. Here are nofib benchmarks comparing the old scheduler to the new: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -0.0% -52.2% -18.8% -18.6% -83.1% Max +1.0% +4.2% +4.9% +5.1% +7.7% Geometric Mean +0.1% -2.8% -0.9% -0.9% -2.9% }}} Here are some technical details: * Without any changes to ticket values, scheduling behavior should be functionally identical to round-robin. (By default, new threads, including the IO thread, get allocated the max nubmer of tickets possible.) This is not quite identical, since our heap does not have FIFO property (see below.) * The current patch-set uses a very simple (e.g. undergrad level) resizable-array backed heap to implement the priority queue; we can play some tricks to reduce the memory footprint of the priority queue (e.g. using the container_of macro to eliminate the extra keys store); and a more fancy data structure would make it easier for us to surgically remove entries or reweight them, but I wanted to keep overhead low. If anyone has a pet implementation of priority queues in C feel free to swap it in. Right now, this only affects the uses of promoteInRunQueue() in Messages.c; I still need to check if #3838 has regressed. * We get three new primops: `setTickets#`, `getTickets#` and `modifyTickets#`. We don't support creating threads with specific numbers of tickets (mostly because that would have added an annoyingly large set of extra primops); instead, you're expected to spawn a thread which gets max-ticket allocation, and then weight it down. * `_link` is no longer used for linking TSOs in the run queue. I have tried my best to stamp out any code which operated on this assumption, but I may have missed some. * Modifying a TSO's tickets takes out the scheduler lock; the hope is that this operation is quick and rare enough that a global lock here is not too bad. * We are unfortunately stuck with some magic constants w.r.t. ticket values: 1 << 20 is the maximum number of tickets our implementation is hard-coded to support. * Sleeping and blocked tasks do not get any 'bonus' for being blocked. * In an ideal world, when a thread hits a black hole, it should temporarily give its tickets to the thread evaluating the black hole, so it will unblock more quickly. Unfortunately, implementing this is pretty complicated (the blackhole evaluating thread could die; or it could get stuck on a blackhole itself and need to gift its tickets; it shouldn't be able to give away the tickets it was gifted.) So this implementation leaves that out. Similar semantics for MVars are probably possible, but will require userland assistance too. I haven't prepared a patch to base yet with a user-level API, but here is a proposed draft: {{{ type Tickets = Int -- | Maximum number of tickets we support a thread having. (Currently 2 >> 20) -- Note that this doesn't bound the *global* maximum tickets. maxTickets :: Tickets -- | Changes the number of tickets allocated to a thread. The ticket count must -- not be less than or equal to zero, or greater than maxTickets. (Corresponds -- to setTickets# primop) setTickets :: ThreadId -> Tickets -> IO () -- | Returns the number of tickets currently allocated to a thread. (Corresponds to -- getTickets# primop) getTickets :: ThreadId -> IO Tickets -- | Atomically performs a linear transformation on the number of tickets a thread; -- e.g. scaling the number of tickets by a rational number, adding another fixed -- set of tickets, and then returning the number of 'leftover' tickets from the operation; e.g. -- if the net amount of tickets is reduced, then the returned result is positive; -- if the net amount of tickets is increased, the returned result is negative. -- In the absence of concurrent threads, the following property holds forall -- t, m and x: -- -- do r <- getTickets t -- d <- scaleTickets t m x -- r' <- getTickets t -- return (r == r' + d) -- -- If the scaling would reduce the number of tickets below zero or increase the -- number of tickets beyond maxTickets, this function will instead fail with -- an exception. This function will be subject to some rounding error; powers of two -- are, however, likely to be exact. (Corresponds to modifyTickets# primop; note -- that the sentinel value for failure is maxTickets + 1, since it is impossible for -- a thread's ticket value to change by that much.) modifyTickets :: ThreadId -> Ratio Int -> Tickets -> IO Tickets -- | Forks a new thread, transferring some percentage of tickets from the current -- thread to it (so the net number of tickets stays constant.) Fails if the rational -- is greater than 1 or less than or equal to zero, or if there are not enough tickets -- in the current thread. forkIOWith :: IO a -> Ratio Int -> IO ThreadId }}}",ezyang 3,7619,Make worker-wrapper unbox data families,Compiler,7.7,normal,,7.8.1,simonpj,new,2013-01-23T00:54:46-0800,2013-04-12T16:03:38-0700,"I noticed that the worker-wrapper optimization doesn't unbox arguments whose type is a data family instance. For example in this module: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE BangPatterns #-} module Foo where data family Foo a data instance Foo Int = FooInt Int Int foo :: Foo Int -> Int foo (FooInt a b) = loop a b where loop 0 y = length $ replicate y b loop x !y = loop (mod y x) x foo1 :: (Int, Int) -> Int foo1 (a, b) = loop a b where loop 0 y = length $ replicate y b loop x !y = loop (mod y x) x }}} foo and foo1 both get worker-wrapper applied, with worker functions of the following types: {{{ $wfoo :: Foo Int -> Int# $wfoo1 :: Int# -> Int# -> Int# }}} It would be nice if $wfoo could get the same type as $wfoo1. This issue happened in real life with unboxed vectors from the vector package, resulting in a lot of boxing with unboxed vector constructors immediately followed by unboxing.",akio 3,7633,"Checkable ""minimal complete definitions""",Compiler,7.6.1,normal,,7.8.1,,new,2013-01-27T21:10:46-0800,2013-04-30T08:07:56-0700,"#6028 suggested warning on cyclic unimplemented defaults. This doesn't work for the reasons mentioned there, among others (also e.g. [http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/Control-Applicative.html#g:2 `Alternative`] has mutually recursive `some` and `many` methods, which shouldn't be warned about). Figuring out when to warn automatically seems hard. But Haskell already has an ad-hoc mechanism for specifying which methods need to be implemented: A ""minimal complete definition"" specified in the comments of almost every class definition that has optional methods. Unfortunately comments are aren't compiler-checked. It seems that the simplest solution would be to specify these in a way that the compiler can understand. The obvious approach is to add a pragma for it in the class definition. In particular, one could write a pragma for each ""minimal set"" of definitions, and the compiler could warn if none of them are implemented (and suggest which methods to implement). This lets us keep the convenience of default method implementations without losing safety. Without any pragmas, the compiler could fall back to the set ""all methods without defaults"", which is what it uses now. It might look something like this: {{{ class Functor m => Monad m where return :: a -> m a (>>=) :: m a -> (a -> m b) -> m b m >>= f = join (fmap f m) join :: m (m a) -> m a join m = m >>= id {-# MINIMAL return, join #-} {-# MINIMAL return, (>>=) #-} class Eq a where (==), (/=) :: a -> a -> Bool x == y = not (x /= y) x /= y = not (x == y) {-# MINIMAL (==) #-} {-# MINIMAL (/=) #-} }}}",shachaf 3,7635,SafeHaskell implying other options,Compiler,7.6.1,normal,,7.8.1,,new,2013-01-28T08:07:12-0800,2013-04-12T16:36:41-0700,"There have been several type checker bugs -- including #7453 and #7354 -- that have led to type-checker unsafeCoerce/panic/etc., which is a problem under SafeHaskell. In many cases the issue is caught by `-dcore-lint`. I'm not sure how much overhead core-linting has, but it seems like it could be a good idea to turn it on by default at least when SafeHaskell is on. Right now it's listed as a ""compiler debugging option"", but it seems that common wisdom is that you should use it if you care about security. Should you also use `stg-lint`/`cmm-lint`? Any other options? This should be clearly documented. Relatedly: Earlier today someone was running a Haskell-evaluating IRC bot. It was running with SafeHaskell, but also happened to have GeneralizedNewtypeDeriving turned on, which made it possible to derive `unsafeCoerce`. Should more care be taken that unsafe options are never turned on at the same time as SafeHaskell? (Continued from #7354.)",shachaf 3,7637,split-objs not supported for ARM,Compiler,7.7,normal,,7.8.1,,new,2013-01-29T06:51:40-0800,2013-04-12T16:37:09-0700,As reported in http://www.haskell.org/pipermail/ghc-devs/2013-January/000198.html,singpolyma 3,7647,UNPACK polymorphic fields,Compiler,7.6.1,normal,,7.8.1,simonpj,new,2013-01-31T21:16:56-0800,2013-04-12T16:54:34-0700,"comment:9:ticket:3990 mentions the possibility of unpacking polymorphic fields. To quote: […] What I mean by ""polymorphic unpack"" is this: {{{ data Poly a = MkP Bool {-# UNPACK #-} a data Mango = MkMango {-# UNPACK #-} (Poly Int) }}} Now a value of type Poly t would be represented using two pointer fields, as usual (ie the UNPACK would have no direct effect on Poly). But a Mango value would be represented thus: {{{ data Mango = MkMangoRep Bool Int# MkMango :: Poly Int -> MangoRep MkMango (MkP b (I# i)) = MkMangoRep b i -- Pattern match (MkMango p -> rhs) -- is transformed to (MkMangoRep b i -> let p = MkP b (I# i) in rhs }}} Something like that would be rather nice. This ticket is just a reminder. Thanks,[[br]] /Liyang",liyang 3,7676,Unify patterns and function bindings,Compiler,7.7,normal,,7.8.1,,new,2013-02-08T18:50:52-0800,2013-04-13T04:46:55-0700,"The following program: {{{ a | True = 1 a | False = 2 }}} produces an error (on 7.4.1 and 7.7.2012117): {{{ Conflicting definitions for 'a' }}} The following two examples produce no error: {{{ b | True = 1 | False = 2 c _ | True = 1 c _ | False = 2 }}} I would expect `a`, `b`. and `c ()` to have identical behaviour.",Mathnerd314 3,7718,ios patch no 8: adjustor pools,Compiler,7.7,normal,,7.8.1,,patch,2013-02-25T04:15:32-0800,2013-05-12T15:18:43-0700,"""Adjustor"" is the term used for a C function pointer that allows C code to call back to Haskell. Normally these are generated at runtime. However, the iOS kernel doesn't allow self-modifying code. So, on iOS we use a pool of precompiled adjustors of a fixed size, and this patch is the implementation for that. It consists of three parts: 1. A POOLSIZE pragma, that is used like this: {{{ foreign import ccall safe ""wrapper"" {-# POOLSIZE 100 #-} mkDelegate :: IO () -> IO (FunPtr (IO ())) }}} This patch makes this pragma work on all platforms, but it'll have no effect on platforms other than iOS. I am not sure what the procedure is for additions of pragmas. Do pragmas require {-# LANGUAGE xx #-} ? Anyway, please review whether the approach taken here is acceptable. 2. The Haskell code in the compiler to generate the stubs for the pooled adjustors. 3. The runtime system's implementation of pooled adjustors in C. ",StephenBlackheath 3,7724,cross-compile to iOS,Compiler,7.7,normal,,7.8.1,,new,2013-02-26T03:28:56-0800,2013-04-13T05:21:54-0700,"A bug for the whole task of cross-compiling to iOS, so we can block it by the individual tasks.",StephenBlackheath 3,7741,Add SIMD support to x86/x86_64 NCG,Compiler,7.7,normal,,7.8.1,,new,2013-03-05T04:42:42-0800,2013-04-13T05:41:50-0700,"ghc-7.7.20130301 has SIMD support. But only LLVM backend supports SIMD currently. If we want to use SIMD, we should use LLVM backend. I request to add SIMD support to x86/x86_64 NCG.",shelarcy 3,7746,Support loading/unloading profiled objects from a profiled executable,Runtime System,7.7,normal,,7.8.1,ezyang,new,2013-03-06T23:08:07-0800,2013-04-13T05:52:15-0700,"This is closely related to #3360, but it is a bit less ambitious and should be possible to implement without too many extra changes to the byte code compiler and interpreter (e.g. we just have to teach the linker how to handle things). Here is a simple test program off of 'plugins' to get working: {{{ {-# LANGUAGE ScopedTypeVariables #-} import System.Plugins.Make import System.Plugins.Load import Data.List boot :: FilePath -> IO () boot path = do r <- make path [""-prof""] case r of MakeSuccess _ p -> do r' <- load p [] [] ""result"" case r' of LoadSuccess _ (v :: Int) -> print v LoadFailure msg -> print msg MakeFailure es -> putStrLn (""Failed: "" ++ intercalate "" "" es) main = do boot ""Foo.hs"" }}} where Foo.hs is {{{ module Foo where result = 2 :: Int }}} Here are the things that, as far as I can tell, need to be handled: * We should ensure consistency between the host and the object file being uploaded. For example, if you load an un-profiled object file into a profiled binary, GHC will eat all your puppies. A simple way to do this is look for a symbol (e.g. CC_LIST) which is only ever exported when something is profiled and barf it is encountered. * This current code fails with {{{test: Foo.o: unknown symbol `CC_LIST'}}}, much the same way GHCi used to fail. This particular problem is (I think) that we don’t store CC_LIST and other externsymbols in our global hash table, so the linker thinks that they don’t exist, when they do. CC_LIST and friends should be special-cased or added to the table. * We don’t run ctors which setup CC_LIST with all of the cost-centres from the loaded module; we need to teach the linker to do that (that's the {{{/* ignore constructor section for now */}}}) * We need to come up with some sensible way of unloading cost-centres from CC_LIST and friends; we could make CC_LIST doubly-linked and then just excise the cost-centre in a destructor, but freeing the actual allocated CostCentre is more difficult. For now, we might just live with the memory leak, but see wiki:""Commentary/ResourceLimits#Memoryleaks"" for a possible better implementation strategy. But that’s it; everything else should work normally. Something similar should apply to ticky builds. Something we will have to think about is how to handle these special-cases as we move from static objects to dynamic objects and push more of the runtime linking burden to the standard libraries.",ezyang 3,7751,Incremental heap census,Profiling,7.7,normal,,7.8.1,ezyang,new,2013-03-07T15:50:40-0800,2013-04-13T05:53:47-0700,"At the moment, a heap census forces a major garbage collection, because a heap census is always traverses the entire heap, and the only time when there is no slop is right after a major GC. What would be nice is if we only carried out heap census on portions of the heap which were *immediately* GC'd; i.e. an incremental census. The question, then, is how do we reconstruct full heap state from only a partial census? In particular, how do we know if an object that was previously present got collected or got promoted? If we always assume that it got collected (the naive implementation), a promoted object will disappear from the census, and only mysteriously reappear when we do a full census. The trick we want to employ is to save the starting pointer of all of the generations: while the entire generation is not slop free, the remainder of the first block and all of the later blocks are. I believe this is sufficient to reconstruct full heap state. #4225 has related discussion.",ezyang 3,7763,Resource limits for Haskell,Profiling,7.7,normal,,7.8.1,ezyang,patch,2013-03-11T21:50:20-0700,2013-04-12T17:17:21-0700,"{{{ commit 1f5eb79cc278fd64ee3f1f4249ea3b7404f62ba1 Author: Edward Z. Yang Date: Thu Mar 7 13:53:31 2013 -0800 Primops and runtime support for space resource limits. This patch adds support for resource limits in Haskell, especially for monitoring and triggering events when portions of Haskell code exceed memory usage and/or allocation. The system is described in more detail at. http://hackage.haskell.org/trac/ghc/wiki/Commentary/ResourceLimits This patch adds the following types: CostCentre# - non-GCd pointer to CostCentre struct CostCentreStack# - non-GCd pointer to CostCentreStack struct Listener# - GC'd object for listening to pointer events and the following primops: ccToAddr addrToCC ccsToAddr addrToCCS newCC# setCCSOf# withCCS# pushCC# queryCCS# listenCCS# unlistenCCS# These previously existing primops have had their types changed, mainly for better type safety (replacing Addr# with CostCentreStack#) getCCSOf# getCurrentCCS# We add the following new RTS options: -hl equivalent to -hc but also keeps census information in-memory for access and does not write out a *.hp file -xf modified cost-centre stack semantics, where function entries never modify the stack (so only CAFs and explicit set CCCS affect cost-centres). To utilize these new features, compile with -prof and run with +RTS -hl -xf }}} See also http://hackage.haskell.org/trac/ghc/wiki/Commentary/ResourceLimits Probably the most dodgy parts of the patch is the primop code for {{{withCCS#}}}, and some of the refactoring of the heap profiler.",ezyang 3,7767,"""internal error: evacuate: strange closure type 154886248"" crash",Runtime System,7.6.2,normal,,7.8.1,,new,2013-03-13T07:31:10-0700,2013-04-13T06:20:49-0700,"I have a simple Main.hs that uses the GHC API to produce a '''ParsedModule'''. I then use ghc-vis this value, which is when I get: {{{ Starting ... Setting dynamic flags ... Guessing and adding target ... Analyze dependencies ... Getting module summary ... Parsing module ... Main: internal error: evacuate: strange closure type 154886248 (GHC version 7.6.2 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 7583 abort ./Main }}} Here is the Main.hs: {{{ {-# LANGUAGE CPP #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE RecordWildCards #-} {- See the following link for additional details about the API: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API -} module Main where import Module import RdrName import OccName import BasicTypes --import Bag --import HsDecls --import Control.Monad import Control.Exception (throw) import GHC hiding (loadModule) import SrcLoc import MonadUtils import GHC.Paths (libdir) import HscTypes --import DynFlags import Unsafe.Coerce --import Bag (bagToList) --import Outputable --import Name import Data.Typeable import Text.Show import Data.Foldable(forM_) import GHC.Exts --import GHC.HeapView import GHC.Vis main :: IO () main = do doMain getLine return () --libdir = ""/Library/Frameworks/GHC.framework/Versions/7.6.2-x86_64/usr/lib"" doMain = do putStrLn ""Starting ..."" runGhc (Just libdir) $ do -- liftIO $ putStrLn ""Setting dynamic flags ..."" dflags <- getSessionDynFlags setSessionDynFlags (dflags) -- liftIO $ putStrLn ""Guessing and adding target ..."" -- guessTarget :: GhcMonad m => String -> Maybe Phase -> m Target target <- guessTarget ""Test.hs"" Nothing -- addTarget :: GhcMonad m => Target -> m () addTarget target --liftIO $ putStrLn ""Loading all targets ..."" --_ <- load (LoadUpTo modName) liftIO $ putStrLn ""Analyze dependencies ..."" -- depanal :: GhcMonad m => -- [ModuleName] -- ^ excluded modules -- -> Bool -- ^ allow duplicate roots -- -> m ModuleGraph modGraph <- depanal [] False let modName = mkModuleName ""Test"" liftIO $ putStrLn ""Getting module summary ..."" -- getModSummary :: GhcMonad m => ModuleName -> m ModSummary modSummary <- getModSummary modName liftIO $ putStrLn ""Parsing module ..."" --data ParsedModule = ParsedModule { pm_mod_summary :: ModSummary -- , pm_parsed_source :: ParsedSource -- , pm_extra_src_files :: [FilePath] } -- type ParsedSource = Located (HsModule RdrName) -- type Located e = GenLocated SrcSpan e -- parseModule :: GhcMonad m => ModSummary -> m ParsedModule parsedMod <- parseModule modSummary liftIO $ vis liftIO $ view parsedMod ""parsedMod"" --let parsedSrc = pm_parsed_source parsedMod ----walkLocSource parsedSrc ----typecheckModule :: GhcMonad m => ParsedModule -> m TypecheckedModule --liftIO $ putStrLn ""Type checking module ..."" --typedMod <- typecheckModule parsedMod ----let parsedMod = tm_parsed_module typedMod ----walkLocSource (pm_parsed_source parsedMod) --let rnSource = tm_renamed_source typedMod ----walkRenamedSource rnSource ---- desugarModule :: GhcMonad m => TypecheckedModule -> m DesugaredModule --liftIO $ putStrLn ""Desugaring module ..."" --desugaredMod <- desugarModule typedMod return () }}} I have built it using: {{{ ghc --make -L/usr/lib -package ghc Main.hs -threaded }}} ",rodlogic 3,7808,data families and TH names do not mix well (e.g. cannot use TH deriving),Template Haskell,7.6.2,normal,,7.8.1,,new,2013-04-03T08:20:02-0700,2013-04-13T08:17:31-0700,"lots of Haskell libraries have TH functions like: {{{ deriveJSON :: Name -> Q [Dec] }}} (e.g. aeson package for deriving JSON conversion) They're used like {{{ data Foo = Foo This That $(deriveJSON ''Foo) }}} the `deriveJSON` reifies the Name and expects to find that the name refers to a data type, from which it finds the data constructors and generates the appropriate code. Now, this doesn't work when the data type we want to derive an instance for is defined using a data family: {{{ class FooClass a where data Foo a ... instance FooClass Bar where data Foo Bar = Bar This That $(deriveJSON ''Foo Bar) -- ??? }}} We'd like to make the type Foo Bar an instance of the class (e.g. To/FromJSON) but `deriveJSON` expects a Name, and there is no name for this data type, its ""name"" is `Foo Bar` but obviously that's not a `TH.Name`. Of course in general a name for a type application doesn't make sense, but for data family instances what other way do we have to refer to them?",duncan 3,95,GHCi :edit command should jump to the the last error,GHCi,None,normal,minor,_|_,,new,2002-11-11T06:18:49-0800,2009-11-17T04:34:07-0800,GHCi has a `:edit` command for editing the current source file. Hugs's command of the same name automatically jumps the editor to the location of the last error; it would be nice if GHCi's did the same.,martijnislief 3,110,Cygwin binaries,None,None,normal,minor,_|_,,new,2003-01-14T20:46:10-0800,2009-12-09T14:00:41-0800,"{{{ A complete set of binaries for ghc and ghci under cygwin would be really nice. Using the win32-version works, but is far from satisfying. GHCI does not recognize the arrow keys, thus no command history (annoying errors instead) and I've heard others complain about problem with linking, since win32-ghc uses it's own gcc. I tried to compile ghc myself, but gave up after a few hours. Please compile it and include it in cygwin's auto-update system. }}}",fizzgig 3,284,RPM doesn't support --prefix,Build System,None,normal,minor,_|_,juhp,new,2004-12-12T17:54:24-0800,2009-11-18T03:42:17-0800,"{{{ After installing ghc for linux using rpm with --prefix=/usr/local, the ghc scriipt incorrectly thinks the libraries etc are in /usr: #!/bin/sh GHCBIN=""/usr/lib/ghc-6.2.2/ghc-6.2.2""; TOPDIROPT=""-B/usr/lib/ghc-6.2.2""; # Mini-driver for GHC exec $GHCBIN $TOPDIROPT ${1+""$@""} After editing, at least the compiler actually starts up :) }}}",skaller 3,285,hp-ux 11.11 binaries,None,None,normal,minor,_|_,,new,2004-12-20T14:20:03-0800,2009-07-17T17:33:31-0700,"Looks like there hasn't been a binary dist for ghc in a very long time, any chance we could see one soon?",amyhr 3,368,Provide a Java Backend,Compiler,None,normal,minor,_|_,,new,2005-04-28T05:20:57-0700,2010-07-19T09:39:57-0700,"{{{ I hope the GHC provide a JVM backend. also: 1. GHC compile hs to bytecode(name as klass) like what javac and klass can be packed as kjar(like jar in java) 2. an KVM interpret the klass bytecode and translate it to java .class, then execute it on JVM. the KVM can be write in haskell also. now, a pure java based GHC and KVM can be used on JVM like 1. ghc.kjar contains the ghc compiler 2. happy.kjar contains the happy compiler 3. kvm.kjar contains the KVM 4. kvm.jar contains the bootstrap kvm that can be run on JVM. }}}",rainbowang 3,393,functions without implementations,Compiler (Type checker),None,normal,normal,_|_,simonpj,new,2005-05-26T03:53:23-0700,2009-11-27T06:58:35-0800,"{{{ Allow to declare a function by only supplying its type signature. This feature shall enhance rapid prototyping by fixing an interface but leaving some functions unimplemented. Currently this can be (only) simulated by supplying dummy implementations, like f :: ... f = undefined Since it is possible to supply dummy data types by ""data T"" (not followed by ""=""), allowing functions without implementations seems almost to be a logical consequence. Surely, the compiler should emit warnings for missing implementations. It would be nice if such function declarations via type signatures could be repeated at any position within a module. }}}",c_maeder 3,436,Declare large amounts of constant data,Compiler,None,normal,minor,_|_,,new,2005-08-11T01:42:42-0700,2008-09-30T08:51:00-0700,"{{{ Simon Marlow wrote in Bug#635718: ""It is true that GHC doesn't have a good way to declare large amounts of constant data. This is a shortcoming, but not a bug (please by all means submit a feature request)."" Submitting as requested:) }}}",ajk 3,472,Supertyping of classes,Compiler (Type checker),None,normal,minor,_|_,,new,2005-10-20T11:34:34-0700,2012-06-30T23:50:19-0700,"see [http://repetae.net/john/recent/out/supertyping.html Supertyping Suggestion for Haskell] example: {{{ class Num a <= Group a where (+) :: a -> a -> a negate :: a -> a }}} apart from multiple inheritance, it could work like this: {{{ import Prelude hiding ((+),negate) import qualified Prelude ((+),negate) class Group a where (+) :: a -> a -> a negate :: a -> a instance Num a => Group a where (+) = (Prelude.+) negate = Prelude.negate }}} - coeus_at_gmx_de",nobody 3,728,switch to compacting collection when swapping occurs,Runtime System,6.4.1,normal,major,_|_,,new,2006-03-16T02:11:55-0800,2010-07-21T05:07:41-0700,"One avenue for tuning the GC to work better in low memory conditions is for it to auto-switch to compacting collection when swapping is happening. We can detect swapping using {{{getrusage()}}} on Unix systems. See: [http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009863.html]",simonmar 3,750,"Set -M, -H, -c and other memory-related values based on available virtual/physical memory",Runtime System,6.4.1,normal,normal,_|_,,new,2006-04-19T01:25:15-0700,2009-11-16T05:06:51-0800,"From John Meacham: perhaps if `-M` is not otherwise set, {{{getrlimit(RLIMIT_AS,..)}}} could be called and the maximum heap size set to just under that, since it is the point that the OS will forcefully kill the program anyway. Ravi Nanavati would like to be able to set the value to a percentage of physical RAM, e.g. `prog +RTS -H256m -M95% -RTS'. Bulat Ziganshin would like to be able to do the same with `-c`.",simonmar 3,881,Improve space profiling for references,Profiling,6.4.2,normal,normal,_|_,,new,2006-08-31T05:52:22-0700,2013-02-22T02:19:31-0800,"GHC's great space profiling tools don't appear to be much help when your leaked memory is stored in references (IORefs, StablePtrs, etc). I had a real-life case where the allocation profile showed me where the leaked data came from, and I could guess that it was being held by some reference, but I couldn't tell which one. Retainer set profiling showed a big suspicious entry for ""SYSTEM"", but I couldn't find any way to pinpoint the problem. (It ended up being a missing freeStablePtr in hsgnutls, found by code inspection.) Here's a contrived example that just allocates a bunch of IORefs: {{{ import Control.Monad import Data.IORef main = repeatM (newIORef [1,2,3]) repeatM io = liftM2 (:) io (repeatM io) }}} Retainer set profiling shows everything in ""SYSTEM"". None of the other profiling methods say anything interesting either. What I'd like to get, I think, is (1) your memory is being held in IORefs (2) allocated by this cost center and (3) being retained by this cost center. I guess I'm looking for something like a memory profiler for a traditional language. Andrew Pimlott Simon Marlow comments: ""The relevant predicate ""is retainer"" is pretty much built into the retainer profiler, and it returns true only for thunks if I recall correctly. Being able to tweak this, or maybe just install a better default would be an improvement.",simonpj 3,910,--make should have a -j flag for parallel building,Compiler,6.4.2,normal,normal,_|_,,new,2006-09-27T01:30:42-0700,2013-05-13T06:10:20-0700,"It should be possible to give --make a -j flag, similar to make's, to tell it to use multiple proceses to build modules. This would allow executables, libraries and cabal packages to be built faster for people with multiple CPUs.",igloo 3,960,Lexical call site string,Compiler,6.6,normal,normal,_|_,,new,2006-10-24T03:56:54-0700,2011-04-02T09:11:41-0700,"A function that returns the lexical call site of the current function when an exception occurs. I'm thinking primarily of ""head []"", but the same principle would apply to other functions. A dynamic traceback is not necessarily possible in a lazy language, but when ""head"" gets called on an empty list there must be somewhere in the program that actually said ""head"", even if it was not evaluated at the time or included in a closure or something. That way when I get a ""head: empty list"" I don't need to grep my program for ""head"" calls: I know where head was called from and can start looking there. Examples: * If I just have a function ""foo = head"" then it will report that the caller was ""foo"". * If I have a function ""bar x y = ..."" and subsequntly say ""baz x = bar (x * 2)"" then an exception in ""bar"" will report the caller as ""baz"". I know there is a -x profiler option to get a sort of dynamic traceback, but I find it frequently just tells me the error is in ""CAF.List"", which isn't very informative. I'm guessing at a difficulty of 1 week as I don't know the GHC internals. I'm guessing that the call site is going to have to be a hidden parameter passed in to each function call, or alternatively hard-coded when a function is in-lined.",paul@… 3,1262,RecursiveDo in Template Haskell,Template Haskell,6.6,normal,normal,_|_,,new,2007-04-02T19:38:24-0700,2013-01-28T13:59:54-0800,I really want mdo support in Template Haskell! Thanks!,philip.weaver@… 3,1273,would like to print partial application values when at a breakpoint,GHCi,6.7,normal,normal,_|_,,new,2007-04-12T09:29:26-0700,2008-09-30T08:51:16-0700,I'd like to be able to examine partial application values when at a breakpoint.,guest 3,1316,add warning for local type signatures that use the same type variable names as outer type signatures,Compiler,6.6.1,normal,normal,_|_,simonpj,new,2007-05-01T15:09:19-0700,2013-01-21T15:48:50-0800,"for a (poor) example, {{{ f :: a -> a f x = x where g :: a --this is (forall x. x) not the 'a' from f's type signature -- So, warn about this signature. g = undefined }}} Because it is likely to be confusing, as well as interfering with any possibility of the type variables being considered scoped by default. In fact, this may be a helpful/explanatory message in cases where there will also be a type error due to the type variables not actually being scoped. (although, detecting those cases particularly and giving a recommended solution for how to give such a type signature, would be a more difficult endeavor (what to recommend?))",Isaac Dupree 3,1318,add warning for prefix negate operator and flag to replace it with negative numeric literals,Compiler (Parser),6.6.1,normal,normal,_|_,,new,2007-05-01T16:41:35-0700,2013-01-21T15:49:24-0800,"This is tracking a few things relating to the notion that Haskell's single prefix operator, ""`-`"", should not exist and ""`-1`"" should parse as a single token anyway. See http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/11954 If there is a LANGUAGE option for this, what should it be called; and what should the ghc flags be called? Should turning off prefix negation and turning on negative numeric literals be separately controllable? This sort of question (exactly what should be implemented) is probably half the difficulty here.",Isaac Dupree 3,1399,better support for developing threaded applications in ghci,GHCi,6.6.1,normal,normal,_|_,,new,2007-05-31T07:03:18-0700,2009-04-11T14:23:24-0700,"The haskell threads model has the appealingly simple property that the main thread determines the lifetime of your program. Once the main thread completes, all other threads are killed. However this doesn't apply when iteratively developing at the ghci command-line. If, for example, you run `main` from the ghci prompt, you regain control of the prompt when your main thread terminates, but any threads spawned by it will keep running. This is particularly irksome if some of them hold onto OS resources (e.g. listening TCP sockets) as you find you can't run your code more than once due to resource issues. It is possible to solve this problem explicitly by killing all the threads yourself at the end of `main`, but that amounts to adding a special `ghci` workaround to your code, because you wouldn't need that to compile as a standalone application. I don't have a specific proposal on the best solution. One would be to alter `ghci`'s semantics so that after the completion of every interactively entered `IO a` action you reap all new threads that have been created. The disadvantage of this would be that it inhibits some interesting kinds of debugging exploring where you deliberately fork some threads from ghci and then communicate with them. A more general solution would be some kind of `:command` to run either with-or-without the reaper-like function as preferred.",guest 3,1404,allow more type signatures,Compiler (Type checker),6.6.1,normal,normal,_|_,,new,2007-06-01T12:55:37-0700,2013-01-21T20:05:19-0800,"(idea triggered by #393) Allow multiple copies of a type-signature in a module, such that it is an error if they're not equivalent, but they don't have to be syntactically equal ( {{{f :: ShowS}}} {{{f :: String -> String}}} is okay). It would also be nice to allow any name in scope at top-level (even if imported) to be given a type signature. But that raises a question: can these type signatures give a more specific type than that of the raw imported function, the way normal function type signatures can with regards to their implementation? Use cases: (1. making sure multiple implementations give the same interface, generally varying by #ifdef) (2. asserting that something's type can be specified in two different weird ways). I don't really want to abandon having a type-signature right above every function definition even if it is a duplicate. (1.) would be fixed by allowing type signatures in export lists instead. I suppose these could be more restrictive than in the module and not affect the module, e.g. {{{ module X (idN :: Int -> Int, true) where idN n = n true :: Bool true = idN True }}}",Isaac Dupree 3,1407,Add the ability to :set -l{foo} in .ghci files,GHCi,6.6.1,normal,minor,_|_,igloo,new,2007-06-01T22:06:10-0700,2013-01-12T11:06:09-0800,"Currently it appears that library flags like -lidn can only be passed on the command line of ghci, but it would be convenient (and more consistent) to be have to have them able to work from the .ghci file. Attempts to do so are silently ignored in both 6.4.2 and 6.6. The only other place it would make sense to pass it would be as something like OPTIONS_GHC, but that results in ""unknown flags in {-# OPTIONS #-} pragma: -lidn"" in 6.4.2 and appears to be silently ignored in 6.6.",guest 3,1409,Allow recursively dependent modules transparently (without .hs-boot or anything),Compiler,6.10.2,normal,normal,_|_,,new,2007-06-04T06:42:28-0700,2013-01-06T18:48:19-0800,"Essentially, compile strongly-connected sets of modules like single modules are compiled (they have to have the same default and monomorphism-restriction, so it is like compiling one module, after the module/import fixpoint and name resolution are done). This can increase the amount of recompilation necessary compared to using .hs-boot files, so it is probably desirable to still allow those. Of course, manually keeping .hs-boot files and {-#SOURCE#-} pragmas around (and synchronized with the real code) is a nuisance (though informative if one cares about minimizing the amount of recursion). I suspect that there can be situations where one level of export-subsets via .hs-boot files is not sufficient... (which would be one reason it wouldn't be easy to ""just"" treat a subset of each .hs file as its .hs-boot). When not using --make mode, ghc would have to find the minimal module cycles somehow, and put just one "".hi-boots"" or "".his"", and .o I think, file somewhere (next to an arbitrary one of the modules I guess) in order that the compilation isn't repeated pointlessly for each module. And deal with which compiler flags are used. Maybe better not to allow it without --make. In --make mode, such hackery should not be needed. This might also help deal with (work around?) such existing bugs with recursive modules and --make: #930 , #1072 , #1133 . The modules having different OPTIONS_GHC or LANGUAGE pragmas might still be tricky or impossible to accept, depending which ones they are and how much implementation effort it's worth investing in allowing that. (Although, class instances being overlappable might be advantageous to have implemented a per-class not per-module specification anyway, for example, so pragmas that affect less than the whole module could be added more easily.)",Isaac Dupree 3,1444,Template Haskell: add proper support for qualified names in non-splicing applications,Template Haskell,6.6.1,normal,normal,_|_,,new,2007-06-20T19:34:17-0700,2013-01-22T08:12:38-0800,"For the uninitiated, Derive is an application of Template Haskell that can generate external Haskell code (depending on how you use it) instead of having it spliced into a module. Template Haskell was not designed for this, and it shows in the handling of qualified names. For example: {{{ Prelude> '[] GHC.Base.[] Prelude> 'True GHC.Base.True Prelude> '(*) GHC.Num.* Prelude Data.Array.Unboxed> ''UArray Data.Array.Base.UArray }}} It would be nice if Template Haskell could instead use public names, where available, so that Derive and similar tools would be able to use qualified names (and the quoting syntax without fear of their ending up pointing into the middle of no-mans-land, or even GHC-only land. This would also mean that users of Derive via TH splicing wouldn't need to import so many modules that the derivings depend on.",SamB 3,1451,Provide way to show the origin of a constraint,Compiler (Type checker),6.6.1,normal,normal,_|_,,new,2007-06-22T04:25:14-0700,2013-01-22T08:15:17-0800,"For a complex type (A b, C d, E e) => Something a b e -> Int, provide a way to given the query: where does A b come from? Respond with the line number of a function that causes that constraint. This should of course also work for non-Haskell 98 constraints. This issue comes up when one by accident calls a function in the wrong layer of a monadic transformer stack.",iampure@… 3,1475,Adding imports and exports with Template Haskell,Template Haskell,6.8.2,normal,normal,_|_,,new,2007-07-01T04:43:16-0700,2013-03-25T04:07:35-0700,"(wished for by Adrian Hey in http://www.haskell.org/pipermail/template-haskell/2007-June/000598.html) It would be useful to be able to add module exports with TH, although I'm not sure exactly how it would be done. Perhaps something like {{{ $( do n <- newName ""foo"" let d = funD n ... addExport (varE n) return [d] }}} but at the point we call `addExport` the typechecker doesn't know that there will be a declaration for the name. Less useful, as TH names include the package and module of the name's definition, is the ability to add module imports. However, this can still be used to get a kind of dynamic binding effect, either with `mkName`'s names or plain Haskell code, e.g.: {{{ $( addImport (if ... then '''Data.ByteString else '''Data.ByteString.Lazy) (mkName ""BS"") ) foo :: BS.ByteString foo = BS.append ... }}} (we'd actually probably want a datatype that mirrors Haskell import decls more closely).",igloo 3,1477,ghci shouldn't link entire package,GHCi,6.6.1,normal,normal,_|_,,new,2007-07-01T06:09:30-0700,2008-09-30T08:51:24-0700,"In this thread: http://www.haskell.org/pipermail/glasgow-haskell-users/2007-January/011839.html Alistair Bayley requests that ghci only link against parts of a package that are actually needed (like ld does) as: {{{ With Takusen, all modules, including the DBMS-specific modules, are compiled into a single library. At present we have 3 DBMS's: Sqlite, Oracle, and PostgreSQL. For example, suppose you had just the Oracle DBMS client libraries installed, and you write a program which only uses the Oracle modules from Takusen. When you link, the gnu ld program attempts to resolve the symbols in only the modules that you've used. You don't need to have PostgreSQL or Sqlite installed, and the linker ignores these modules from the package archive. This is quite nice, because we can distribute the entire library as a single package, and it will work even if the user does not have all of the DBMS client libraries installed. In contrast, when ghci (or runhaskell) attempts to link it tries to resolve all of the symbols in the PostgreSQL and Sqlite modules, and fails because you don't have them installed. The result is that a user of Takusen can't easily use the library with ghci/runhaskell ""out of the box"", unless they have the full set of DBMS client libraries installed. There are a couple of workarounds, but they're both a bit fiddly, so it'd be nicer (from my POV) if the ghci linker behaved like gnu ld. }}}",igloo 3,1480,Template Haskell should allow reification of modules,Template Haskell,6.6.1,normal,normal,_|_,,new,2007-07-01T11:43:25-0700,2013-03-26T22:57:02-0700,"It should be possible to reify a module from a splice. If the module is thisModule then it would only tell you about things above the current splice. This comes up quite often; for example: In http://www.haskell.org/pipermail/haskell-cafe/2007-June/027205.html Brent Yorgey wants to get a list of top-level functions names prop_* in order to build a runQuickCheckProps function. In http://www.haskell.org/pipermail/haskell-cafe/2007-June/026493.html Neil Mitchell wants to get all the data/newtype declarations in a module in order to declare Typeable and Data instances for them.",igloo 3,1532,Implicit parameters are not available in breakpoints,GHCi,6.7,normal,normal,_|_,,new,2007-07-13T04:26:55-0700,2013-01-23T01:29:20-0800,We may want to leave this for after 6.8,mnislaih 3,1791,heap overflow should generate an exception,Runtime System,6.8,normal,blocker,_|_,,new,2007-10-21T07:08:48-0700,2013-01-26T14:48:33-0800,"I want to use the -M option for the goals that are stated in the manual. {{{ ./TestProgram +RTS -M5m -RTS }}} Expected output: {{{ Something like ""out of heap space"" }}} Actual result: {{{ Machine going into a state where it swaps memory }}} This is the code for TestProgram: {{{ import Control.Monad.ST import Data.Array.ST import Data.Array.MArray import Data.Array.Base(unsafeNewArray_) main = print (runST (do make_empty_table >> return ())) make_empty_table:: ST s (STArray s (Int, Int) (Maybe ep)) make_empty_table = unsafeNewArray_ ((1, 1), (16384, 16384)) }}} This was tested with 6.9.20071018 on an athlon-xp, and confirmed by dcoutts also on x86-64 with ghc-6.8.0.20071015. ",guest 3,1800,Template Haskell support for running functions defined in the same module,Template Haskell,7.7,normal,normal,_|_,,new,2007-10-24T04:59:20-0700,2013-03-25T03:54:32-0700,"Currently TH has the following restriction: You can only run a function at compile time if it is imported from another module. That is, you can't define a function in a module, and call it from within a splice in the same module. This is a pain. It should be fixed. See http://www.haskell.org/pipermail/template-haskell/2007-October/000619.html, for example. ",simonpj 3,1826,unable to list source for should never occur,GHCi,6.8.1,normal,normal,_|_,,new,2007-11-04T05:34:43-0800,2013-01-26T15:50:09-0800,"I get the very unhelpful ""unable to list source for "". I would like to get one of the following two responses, the last one is best. {{{ Do this and that to list source }}} {{{ We currently cannot list source, because you did and that Do you still want to list source although it requires to do that and that(for example automatically recompiling and reexecuting it until the same program point) [Y/n]? }}}",guest 3,1830,Automatic derivation of Lift,Template Haskell,6.8.1,normal,normal,_|_,,new,2007-11-04T13:03:12-0800,2013-01-26T15:47:55-0800,"This feature request was brought up in this template-haskell thread[1]: There are apparently two implementation alternatives: 1) Merge Ian's th-lift library[2] with the mainstream template-haskell library 2) Implement ""instance Data a => Lift a"" (requires allowing undecidable and overlapping instances) in template-haskell. Since Data can be derived automatically by GHC, such an instance would imply automatic derivation of Lift as well. [1] http://www.haskell.org/pipermail/template-haskell/2007-October/000635.html [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/th-lift-0.2",guest 3,1921,change default to support extensions that involve a change of syntax,Compiler,6.8.1,normal,normal,_|_,,new,2007-11-23T12:09:23-0800,2008-09-30T08:51:37-0700,"Use of a lot of extensions is obvious from the non-haskell-98 syntax they require. GHC should default to supporting these extenions with a flag to tell the use what extensions are in use. GHC should require that extensions that change the meaning of an already valid haskell-98 file should appear in pragmas in the source file. More radical: GHC should not allow extenions flags on the command line. ",alex 3,1974,"length ""foo"" doesn't work with -XOverloadedStrings",Compiler,6.8.1,normal,minor,_|_,,new,2007-12-12T04:00:04-0800,2012-09-06T18:49:42-0700,"The extensions to the defaulting rule for -XOverloadedStrings aren't sufficient to make {{{length ""foo""}}} typecheck without an annotation. The reason is that we end up with a constraint {{{IsString [a]}}}, and we would somehow have to decide to instantiate a to Char to get the hoped-for behaviour. It would be nice if this could be made to work (perhaps just with -XExtendedDefaultRules), if a solution can be found without too much hacking.",ganesh 3,2041,Allow splicing in concrete syntax,Template Haskell,6.8.2,normal,normal,_|_,,new,2008-01-13T14:05:09-0800,2011-12-16T08:09:52-0800," Template Haskell tends to lag behind GHC extensions, so it might be nice to allow concrete syntax to be returned, e.g. something like {{{ f = $( return (RawE ""5 + 6"") ) }}} There wouldn't be any need to restrict it to the top level, e.g. this would also be allowed: {{{ f = $( return (InfixE (IntE 5) '(+) (RawE ""6"")) ) }}} One possible disadvantage is that it might result in TH languishing even further behind, as there is less incentive to fill in the gaps. Also, if a module splices in a raw expression from a TH library, what extensions should be enabled when parsing the string? Should we use the extensions enabled for the module, or should the `RawE` constructor specify the extensions to be used? We actually have this problem already, as (for example) when instances are spliced in we might need !OverlappingInstances enabled, so just using the extensions enabled for the module would be consistent. ",igloo 3,2101,Allow some form of type-level lemma,Compiler,6.8.2,normal,normal,_|_,,new,2008-02-15T15:04:44-0800,2008-09-30T08:51:41-0700,See http://www.haskell.org/pipermail/haskell/2008-February/020230.html,guest 3,2180,"Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock",Runtime System,6.9,normal,minor,_|_,Baughn,new,2008-03-27T10:40:00-0700,2009-07-24T10:44:02-0700,"The runtime system's deadlock detection, being a debugging feature, rightly doesn't break a deadlock if there's any chance a signal will do so later. However, if the only installed signal is XCPU - cpu time-limit exceeded - then that will almost never happen in practice; any program that does want to wait for it will be waiting quite literally years. As such, it seems best if XCPU is left out of the signal-detection logic. The attached patch does this.",Baughn 3,2200,big static random access arrays,Compiler,6.8.2,normal,normal,_|_,,new,2008-04-06T13:39:23-0700,2008-09-30T08:54:54-0700," These would be unlike `StorableArray`s because they would be available at compile time, and would be pure values. They would amount to arrays of bytes, of course, but it'd be nice if they could be `(Storable a) => StaticArray a` and we could walk down them or randomly access them to get the `a` values out of them. They should be capable of storing hundreds of thousands of `Int`s. What are some functions that work on these arrays? We need just one: {{{ indexInto :: (Storable a) => StaticArray a -> Word -> a }}} Then we can make a `Monad` to walk up and down the array. It will be some `State` hybrid. No `IO`. A bright person could implement static `Trie`s, `RoseTree`s and other things using this `Monad` -- storing the offsets mixed in with the data in an unholy mess and skipping forward or backward, leveraging ""the world’s most beautiful imperative language."" It's been suggested (SamB) that this should be implemented in Template Haskell. Important features of this array relative to other arrays and lists in Haskell: Specificity of Index:: A machine `Word` since that contains the finest grained pointer. When indexing into a `Storable a`, the index is multiplied by `sizeOf (undefined :: a)`. Static Nature:: Exists to facilitate large static constants. The array does not support any append or delete operations, there is no way to change any of its values and it can not be copied.",jsnx 3,2207,Load the interface details for GHC.* even without -O,Compiler,6.8.2,normal,normal,_|_,,new,2008-04-10T08:01:41-0700,2013-02-07T08:02:36-0800,"Neil says: I just tried compiling the following program: {{{ foo = (1 :: Int) == (2 :: Int) }}} with `ghc --ddump-simpl`, and no optimisation flags, in GHC 6.6.1 The resultant code is: {{{ Test.foo = case GHC.Base.$f2 of tpl_X8 { GHC.Base.:DEq tpl1_B2 tpl2_B3 -> tpl1_B2 (GHC.Base.I# 1) (GHC.Base.I# 2) } }}} GHC has introduced dictionaries in this example. In comparison, Yhc and nhc wouldn't introduce dictionaries here, as the type class desugaring knows the type of the item is fixed, and makes a direct call to the appropriate function. If the desugaring was changed, it would make programs in GHCi run faster, would reduce the size of programs, and would speed up the optimiser, as it would have less to do. I am not sure how much additional work this would require in the simplifier, but if it was minimal, the gains would probably be worth it. The reason nothing happens is that without -0 GHC does not load the unfoldings for anything from interface files, including `GHC.Base`. Idea: even without -O, load the unfoldings from GHC.* modules. That would pick up a lot of very fundamental stuff, and might, as Neil says, make compilation faster. Relatively easy to try. But would need a good nofib run to test the effects. Any takers? I'd point you at what to change. Simon",simonpj 3,2344,oddity with package prefixes for data constructors,GHCi,6.9,normal,normal,_|_,,new,2008-06-04T15:56:15-0700,2008-09-30T08:51:50-0700,"consider {{{ $ ./ghc-6.9.20080514/bin/ghcii.sh GHCi, version 6.9.20080514: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :browse Data.Time.Clock getCurrentTime :: IO UTCTime newtype DiffTime = time-1.1.2.0:Data.Time.Clock.Scale.MkDiffTime Data.Fixed.Pico newtype NominalDiffTime = time-1.1.2.0:Data.Time.Clock.UTC.MkNominalDiffTime Data.Fixed.Pico data UTCTime = UTCTime {utctDay :: time-1.1.2.0:Data.Time.Calendar.Days.Day, utctDayTime :: DiffTime} newtype UniversalTime = ModJulianDate {getModJulianDate :: Rational} addUTCTime :: NominalDiffTime -> UTCTime -> UTCTime diffUTCTime :: UTCTime -> UTCTime -> NominalDiffTime picosecondsToDiffTime :: Integer -> DiffTime secondsToDiffTime :: Integer -> DiffTime }}} there is only one time package installed, so i'm surprised to see any package prefixes at all here {{{ $ ./ghc-6.9.20080514/bin/ghc-pkg.exe find-module Data.Time.\* c:/fptools/ghc/ghc-6.9.20080514\package.conf: time-1.1.2.0 }}} but by what system do some things get prefixes and others don't? are there any invisible modules that need the distinction, or is this an output bug?",claus 3,2403,caching for runghc (runhaskell),Compiler,,normal,normal,_|_,jsnx,new,2008-06-28T22:18:59-0700,2008-09-30T08:54:56-0700,"I'd like `runghc` to compile and cache scripts, so they will run fast after the first shot. This could be available via a command line option, special name (`runhaskello`), or be governed by a config file -- I'm open to suggestions here. I still haven't quite worked out how to do this -- I'll have more ideas about the layout of the cache in a few days. I'm making a feature request of it not because I want someone else to do it, but rather because I'd like it to be accepted once I finish it and I wouldn't want to invest all the time and trouble in reworking `runghc` if it's just going to be rejected.",jsnx 3,2427,Allow compilation of source from stdin,Compiler,6.8.3,normal,minor,_|_,,new,2008-07-07T09:19:12-0700,2013-02-22T17:43:28-0800,"Hiya. So, as part of how the Hint library (a wrapper around the GHC API operates), it has to generate a file in /tmp containing module boilerplate and the supplied code of interesting, and it then evaluates it*. But for my mueval code (which uses Hint), I'd like to disable file creation entirely through resource limits, and so it would be much better for Hint if it could instead just create the string and pipe it right into GHC. This avoids any file creation (which may not be possible for any number of reasons besides resource limits, like LiveCDs or read-only disks). But in my experiments, and those of #haskell, GHC determinedly blocks any attempt - you can't simply pipe it in with |, you can't use /dev/stdin, can't use one of the file descriptors, etc. So what I would like is to be able to do: {{{ $ echo ""import qualified Data.List\nmain = print $ Data.List.intersperse 'f' ""ggggg"" ""fgfgfgfgfgfg"" }}} (Why can't I use ghc -e? Doesn't do imports of any kind, and if mueval is to replicate lambdabot's functionality, it needs to be able to import many libraries qualified.**) * It has to do this roundabout hackish thing because alas, the GHC API seems to allow functions from any module whatsoever to be called as long as they are named qualified, even if the appropriate module had not been allowed in. The magnitude of this as a security hole is obvious. ** Why qualified? Too many of the basic libraries have name collisions. Can't remove them, as it'd be silly to have only half the base libraries or whatever, but can't just blindly import them as you'll get conflicts.",guest 3,2456,"For higher kinds, instance declarations need quantification in the context",Compiler,6.9,normal,normal,_|_,,new,2008-07-21T00:30:24-0700,2013-02-02T12:18:43-0800,"{{{ $ rm -f DerivingError.o DerivingError.hi; ghc --make DerivingError.hs [1 of 1] Compiling DerivingError ( DerivingError.hs, DerivingError.o ) /var/folders/C0/C0SledGV2RaxbU+8ZLDnVU+++TI/-Tmp-//ghc27223_0/ghc27223_0.s:6080:0: FATAL:Symbol _XxG_srt already defined. }}}",ronwalf 3,2630,"installed packages should have a src-dirs field, for access to optionally installed sources",Package system,6.9,normal,normal,_|_,,new,2008-09-28T06:08:52-0700,2009-04-27T03:53:00-0700,"In a typical ghc+packages installation, there are no Haskell sources. That makes life difficult for source-code-based tools, such as Haddock or HaRe (as far as I can see from `--show-iface` output, not even the import hierarchy is visible anymore?). (1) It would be useful if Ghc Api clients and Ghc users could easily find the matching source for installed packages, via a `src-dirs` field in the installed package description (if field is empty, no source has been installed). (2) It would be useful if matching sources could easily be added for installed packages. This would require editing the package description. Should there be an `edit` command for `ghc-pkg`? (3) An alternative to a `src-dirs` field would be to install sources in a separate source-package database, as long as it is easy to find the source from the binary package.",claus 3,2742,The -> in ViewPatterns binds more weakly than infix data constructors.,Compiler,6.10.1,normal,normal,_|_,,new,2008-11-04T14:09:21-0800,2013-03-24T23:44:11-0700,"The following code, essentially taken from the ViewPatterns page on the wiki doesn't seem to parse correctly. {{{ mymap f [] = [] mymap f (x : mymap f -> xs) = f x : xs }}} However, this does: {{{ mymap f [] = [] mymap f (x : (mymap f -> xs)) = f x : xs }}} (though it triggers bug #2395 about overlapping patterns) It would seem nicer to make the view pattern arrow bind ''tighter'' than any infix data constructors.",guest 3,2893,"Implement ""Quantified contexts"" proposal",Compiler,6.10.1,normal,normal,_|_,,new,2008-12-23T01:41:20-0800,2013-03-12T06:55:14-0700,"See: http://haskell.org/haskellwiki/Quantified_contexts Motivating example is collapsing insomeway-identical classes such as Monoid and MonadPlus into a single class (with accompanying functions).",porges 3,2895,"Implement the ""Class System Extension"" proposal",Compiler,6.10.1,normal,normal,_|_,,new,2008-12-23T17:27:30-0800,2012-02-28T20:30:57-0800,"See: http://haskell.org/haskellwiki/Class_system_extension_proposal Executive summary: 1. Class and instance declarations would allow method implementations to be given for any methods in the class or any ancestor class. 2. Whenever an instance declaration is visible there would always be a full set of instance declarations for all ancestor classes, by supplementing the set of explicitly given instance declarations that are visible in a module by automatically generated implicit instance declarations. 3. The most specific method implementation would always be chosen (ie prefer an explicit instance method over a class method and prefer a subclass method to a superclass method) 4. Modules would only export explicit instance declarations ",porges 3,3021,A way to programmatically insert marks into heap profiling output,Profiling,6.10.1,normal,normal,_|_,,new,2009-02-11T19:23:39-0800,2012-10-02T15:58:14-0700,"This would be useful for e.g. marking compiler phases. Hmm, this would be more useful if the ""MARK"" record type had a string field...",SamB 3,3205,Generalized isomorphic deriving,Compiler,6.10.2,normal,normal,_|_,,new,2009-05-03T13:58:19-0700,2009-05-24T11:57:24-0700,"A newtype is isomorphic to the type that it is based on. For example, newtype A = A Int is isomorphic to Int, so it is possible to automatically derive all of Int's instance for A. It would be nice if this could be extended to other datatypes that were isomorphic to each other. For example, this would work {{{ data K a = K a a a instance C (K a) where ... data L a = L a a a deriving (Eq,C<-K,Show) }}} where the {{{C<-K}}} notation means ""derive an instance of C for this type that is 'the same as' the instance of C for K"". The compiler would have to check that K and L were actually isomorphic. I don't know if this is possible with the current internals of GHC, but it would be cool if it would be done. My main usage scenario would be deriving things for single-argument data constructors based on tuples; for example for serialization classes.",ajd 3,3215,Valgrind support,Runtime System,6.10.3,normal,trivial,_|_,,new,2009-05-10T10:51:52-0700,2012-03-26T12:29:21-0700,"This is based on code in gtk2hs. {{{ $ valgrind -q ./finalizer_queue finalizer_queue: internal error: stg_ap_v_ret (GHC version 6.10.3 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Killed }}} Unfortunately this test doesn't crash without Valgrind. My guess is that this bit is the problem: {{{ finalizer <- fixIO $ \dPtr -> mkThunk $ do freeHaskellFunPtr callback freeHaskellFunPtr dPtr }}} Perhaps the documentation should say not to do this?",cmcq 3,3283,Selective disabling of unused bind warnings,Compiler,6.10.2,normal,normal,_|_,,new,2009-06-07T22:31:04-0700,2009-11-21T08:04:59-0800,"I like to compile with -fwarn-unused-binds to keep my code clean, but I think a couple of extra flags to control this would be useful: * -fno-warn-unused-fields which would turn off warnings for record field names that were not used. I know you can prefix them with _, but then when you do use them then you have to change the name, etc. * A {-# USED f, g, h, ... #-} pragma to tell the compiler not to warn about the functions given in the pragma. I can see how especially the second could be controversial as it introduces an incompatibility, but I think both of these features could be put to good use. Not very high priority, though.",ajd 3,3447,Class restrictions on type instances,Compiler,6.10.4,normal,normal,_|_,,new,2009-08-21T08:33:09-0700,2009-08-26T04:20:18-0700,"I'm using type families to implement bools and integers on type level. There is a class BoolT with with two instances and type families representing usual boolean functions, e.g. NotT. By semantics of NotT, implication (BoolT a) => (BoolT (NotT a)) holds, but I cannot specify this to compiler, and using BoolT with NotT is painful. So I think there must be syntactic construction to restrict type family instances to some class, something like {{{ type family NotT a with (BoolT a) => (BoolT (NotT a)) }}} or {{{ class BoolT a where type NotT a with BoolT (NotT a) }}} ",LysikovVV 3,3490,Relax superclass restrictions,Compiler,6.10.4,normal,minor,_|_,,new,2009-09-08T00:34:38-0700,2009-11-06T02:56:08-0800,"Doaitse points out that we currently reject {{{ class C a b | a -> b where class C a b => D a where }}} on the grounds that 'b' is not in scope in the second class decl. (Only type variables in the ""head"", namely (D a), can be mentioned in the superclass context.) My response to him was as follows. The easiest way forward is to re-express your program using type functions. Then class C will have just a single type parameter (a), with the 'b' part being expressed by a type function. That would resolve the problem rather nicely. Medium term, I think the Right Thing is to allow a class declaration {{{ class Q => C a b }}} (where Q is a context) if and only iff the type {{{ forall ab. Q => C a b }}} is unambiguous. What does ""unambiguous"" mean? As it happens, we are working on nailing that down right now. For example, here is a stupid but unambiguous declaration: {{{ type family F a class (b ~ F a, Eq b) => C a }}} I do not know of any non-stupid examples that would be rejected by the current rule, but there might be some. I'll open a ticket because I'd like to get to this when we have the other pieces working. ",simonpj 3,3541,Allow local foreign imports,Compiler (FFI),6.10.4,normal,normal,_|_,,new,2009-09-25T07:06:01-0700,2009-11-16T05:11:56-0800,"I have no idea the level of difficulty this would entail, but it would be rather nice to be able to import foreign functions at scopes other than the top level. When writing glue code, especially for C++ where I often want to catch and haskellize exceptions, I find myself using wrappers quite a bit, for example: {{{ foreign import ccall ""foo.h foo"" raw_foo :: CString -> IO () foo :: String -> IO () foo s = withCString s raw_foo }}} Where I only want ""foo"" exported from the module. It's not that big a deal to list explicit exports, I know, but I would like to be able to say instead: {{{ foo :: String -> IO () foo s = withCString s raw_foo where foreign import ccall ""foo.h foo"" raw_foo :: CString -> IO () }}} In addition to reducing clutter in the top level namespace, it makes for less clutter on the left margin of the code, making it easier to scan through function names visually.",mokus 3,3545,As-patterns for type signatures,Compiler (Type checker),6.11,normal,normal,_|_,,new,2009-09-27T14:14:30-0700,2009-11-03T04:01:46-0800,"The proposal: in any type signature, the presence of type variable x@pat matches the type specified by pat, and replaces any occurrences of the type variable x with pat. In particular, this might be comparable to defining type x (free variables in pat) = pat with scope solely to the right of the as-pattern. Alternately, it might be compared to an equality constraint (x ~ pat).",LouisWasserman 3,3557,CPU Vector instructions in GHC.Prim,Compiler (NCG),6.11,normal,normal,_|_,,new,2009-10-02T09:41:39-0700,2012-01-25T05:33:26-0800,"It would be nice to have support for vector unit (MMX, SSE, AltiVec, and so on) operations in GHC. Currently Data Parallel Haskell cannot utilize vector units due to GHC's lack of support. Those vector operations could be nicely used to get e.g. stereo signal processing for the price of mono signal processing. Maybe those operations could be added to GHC.Prim, or because there are so many, to a new module, GHC.Prim.Vector. ",guest 3,3577,Complete support for Data Parallel Haskell,Data Parallel Haskell,6.13,normal,normal,_|_,rl,new,2009-10-12T03:27:33-0700,2010-03-15T01:19:33-0700,I'm going to open this as a placeholder for all the things the vectoriser can't do yet.,rl 3,3583,Default view patterns,Compiler,6.10.4,normal,normal,_|_,,new,2009-10-13T16:28:15-0700,2013-03-25T19:16:10-0700,as useful for code like http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10699#a10699 : Provide a unified left-hand interface for [] and Seq with the same syntax as current lists.,ksf 3,3601,"When running two or more instances of GHCi, persistent history is only kept for the first one",GHCi,6.10.4,normal,minor,_|_,,new,2009-10-20T08:55:06-0700,2009-11-20T11:02:51-0800,"The file `~/.ghc/ghci_history` maintains the command history for the first running GHCi instance. No persistent history is kept for concurrently running ghci processes. See #2050. bash provides an option of setting `shopt -s histappend`, which makes all bash instances share the same history file. Perhaps writing to the same file would be somewhat silly in the case of GHCi, but writing to .ghci_history.2 or similar could be one solution. Alternatively, a command within GHCi to dump the current instance's command history to a file would work also.",arnar 3,3615,GHCi doesn't allow the use of imported data contructors,GHCi,6.10.4,normal,minor,_|_,,new,2009-10-27T09:03:31-0700,2009-11-05T09:00:05-0800,"There are two modules in this simplified scenario. The main module is Main.hs and contains the following three lines of code. {{{ module Main where import Imp (D(..)) main = print D1 }}} Module Imp contains a single data type definition: {{{ module Imp where data D = D1 | D2 deriving Show }}} Now, when I compile Main everything works. GHCi doesn't complain when it loads the main module either, but it doesn't allow me to construct D on its command line. This makes no sense to me. {{{ $ ghc --make Main.hs [1 of 2] Compiling Imp ( Imp.hs, Imp.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main D1 $ ghci Main.hs GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Ok, modules loaded: Main, Imp. Prelude Main> D1 :1:0: Not in scope: data constructor `D1' Prelude Main> }}} ",blamario 3,3769,Add manpages for programs installed alongside ghc,Documentation,6.12.1,normal,,_|_,,new,2009-12-16T14:48:44-0800,2012-10-02T15:56:01-0700,"The following programs installed with GHC (specifically, using the Mac OS X installer, though I suspect this applies to all platforms) do not have manpages: * `ghc-pkg` * `ghci` (Technically, its manpage is the same as `ghc`'s, but there's no `ghci.1` symlink to `ghc.1`, so `man ghci` fails to find anything.) * `haddock` * `hp2ps` * `hpc` * `hsc2hs` * `runghc` * `runhaskell` I think that's all of them. I realize that not all of these programs (e.g., `haddock`) are truly part of GHC, but the ones that are still need manpages. If the problem is that writing *roff is hard, and you don't mind mooching off other languages, might I refer you to [http://perldoc.perl.org/perlpod.html POD]/[http://perldoc.perl.org/pod2man.html pod2man]?",Minimiscience 3,3814,Compile to more than one (sub)-architecture,Compiler,6.12.1,normal,,_|_,,new,2010-01-09T16:36:40-0800,2013-01-21T01:23:43-0800,"GHC, as far as I can tell, can only compile files for one architecture (let's call it the ""host architecture""). This brings some problems... The biggest of which is that we lose the option of building for 32/64 bits in one of the ""hybrid"" architectures (For example, in x86_64-linux or i386-darwin) If I build a ghc in a x86_64 linux I will only get the x86_64 code generator and not the i386 generator. This will stop me from building a program which links with a library that only has a 32-bit version. If I want a GHC which will only compile for the i386, I will have to cross-compile, which is not very pretty. The same will happen on the Mac OS X side (even though the x86_64-darwin port is still on its way...). But GHC ""should"" (IMHO) be able to do like GCC and be able to generate code for both architecturess (i386 and x86_64), through the usage of compiler flags (which would also be passed to any gcc sub-process, if need be). At least if it is installed in a x86_64 (and PPC, if PPC64 is supported) system. Even better would be to do like LLVM's llc which enables a user to generate an assembly file for a target architecture from any other architecture. Example of an LLVM target list: {{{ filcab@fry:/stuff/src> llc --version Low Level Virtual Machine (http://llvm.org/): llvm version 2.7svn DEBUG build with assertions. Built Jan 10 2010 (00:25:59). Host: x86_64-unknown-linux-gnu Host CPU: core2 Registered Targets: arm - ARM c - C backend cellspu - STI CBEA Cell SPU [experimental] cpp - C++ backend mips - Mips msil - MSIL backend ppc64 - PowerPC 64 sparc - Sparc x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 }}}",filcab 3,3919,Or-patterns as GHC extension,Compiler,,normal,,_|_,,new,2010-03-14T05:33:29-0700,2010-06-13T03:44:59-0700,"Or-patterns is a way of grouping together patterns that match to the same value. A construct like {{{ fun 0 _ = E fun _ 0 = E }}} Could more concisely be written as, for example {{{ fun 0 _ || _ 0 = E }}} As a concrete example why this is beautiful and how it could look, see ''Red-black trees in a functional setting, C. Okasaki'' [1]. I don't know enough about GHC internals to know the obvious way to implement this, but I would gladly give it a try given pointers in the right direction. [1] http://www.eecs.usma.edu/webs/people/okasaki/jfp99.ps",BjornEdstrom 3,4091,Parse error on curried context of instance declaration,Compiler,6.12.2,normal,,_|_,,new,2010-05-24T06:36:08-0700,2010-06-14T00:55:58-0700,"Assume we have the following classes: {{{ class C1 a; class C2 a; class C3 a; class C4 a }}} GHC allows you to write a type with an uncurried context, as in: {{{ foo :: (C1 a, C2 b, C3 c) => a -> b -> c }}} It also allows you to write a type with a curried context, as in: {{{ foo :: C1 a => C2 b => C3 c => a -> b -> c }}} However it is not allowed to use this curried style of contexts in instance declarations, as in: {{{ instance C1 a => C2 b => C3 c => C4 (SomeType a b c) }}} Is this intentional?",basvandijk 3,4370,Bring back monad comprehensions,Compiler,6.12.3,normal,,_|_,,new,2010-10-06T00:43:21-0700,2013-05-07T23:26:21-0700,"George Giorgidze writes: My colleagues and I are working on Haskell [http://www-db.informatik.uni-tuebingen.de/files/weijers/IFL2010complete.pdf embedded DSL for data-intensive and data-parallel applications]. The idea is to provide the Haskell list prelude combinators to manipulate database-resident data. The combinators are not executed in Haskell runtime, instead they are compiled down to SQL, executed on relational database systems and the results are marshalled back to Haskell for further in-heap processing or generation of new database-able embedded programs. Although programming with the standard list processing combinators is feasible, the embedded programs are much more concisely formulated using the list comprehension notation, especially, when extended with [http://research.microsoft.com/en-us/um/people/simonpj/papers/list-comp/ 'order by' and 'group by' constructs]. Unfortunately, in Haskell, the list comprehension notation is only available for processing lists. In order to support the list comprehension notation, we have built a quasiquter that desugars the list comprehension notation, but, instead of generating code using the Haskell list prelude combinators the quasiquter generates code that uses list processing combinators from our embedded language. Although the quasiquoting approach worked for us, it has a number of drawbacks: * Introduces extra syntactic noise * Error messages are hard to understand as they refer to enerated code * Needs to be re-implemented for every list-based embedded language One way to address the aforementioned drawbacks is to define our queries as a monad (similar to list monad) and use the monad comprehension notation. The do notation can be used but it is less suited for query languages. Unfortunately monad comprehensions were removed from Haskell, prior to Haskell 98. However, I think that the notation is extremely useful not only for lists, but for other list like data structures, list-based query languages (see above), maybe even for wider range of EDSLs and monads. I think the feature deserves to be supported at least as a GHC language extension. Thus, I would like to propose to design and implement the monad comprehension notation as a GHC language extension. I am willing to invest some time and contribute to this effort. One can also look at how recently introduced 'order by' and 'group by' constructs generalise to monad comprehensions. If that works, one could implement even more ""stylish"" monad comprehension notation. Feedback from GHC users and developers would be very much appreciated. * Do you think that this is a good idea? * Would you use monad comprehensions (if available) for your library/EDSL/application? * Do you think that it would be hard to integrate this extension into current GHC codebase? * Have you already thought about how to generalise 'order by' and 'group by' to monad comprehensions? * Have you already thought about how to address the original objections to the monad comprehension notation? ",simonpj 3,4894,Missing improvement for fun. deps.,Compiler (Type checker),7.1,normal,,_|_,,new,2011-01-16T19:16:09-0800,2011-05-01T02:51:29-0700,"The problem is illustrated by the following example: {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} class F a b | a -> b f :: (F a b, F a c) => a -> b -> c f _ = id Results in the following error: Could not deduce (b ~ c) from the context (F a b, F a c) bound by the type signature for f :: (F a b, F a c) => a -> b -> c at bug.hs:6:1-8 `b' is a rigid type variable bound by the type signature for f :: (F a b, F a c) => a -> b -> c at bug.hs:6:1 `c' is a rigid type variable bound by the type signature for f :: (F a b, F a c) => a -> b -> c at bug.hs:6:1 Expected type: b -> c Actual type: b -> b In the expression: id In an equation for `f': f _ = id }}} The issue seems to be related to Note [When improvement happens] in module TcInteract. It states that two ""givens"" do not interact for the purposes of improvement. As far as I understand, the correct behavior should be to generate a new given equality, justified by the functional dependency on the class. This is also related to bug #1241: in order to justify an improvement by functional dependency, we have to check that all instances are consistent with the dependency. Otherwise, the above function would turn into an ""unsafe cast"" function. ",diatchki 3,5082,Emit warnings when conflicting flags are supplied,Compiler,7.1,normal,,_|_,,new,2011-04-03T06:10:54-0700,2011-04-03T06:50:45-0700,"Many command line flags can be thought of as modifying some GHC's internal flag state. We do this so that we can override flags in one place by re-specifying the flag later, e.g. ghc -fno-new-codegen ... -fnew-codegen While this is handy, it can cause some interesting unexpected behavior where a user modifies a flag in some place (for example, the command line), and the flag gets subsequently overridden by another location (for example, an OPTIONS_GHC pragma). What would be useful is if GHC could report when some internal option is modified by multiple places, and say which one ""won"" in the end.",ezyang 3,5144,Pattern synonyms,Compiler,,normal,,_|_,,new,2011-04-20T04:33:21-0700,2012-10-12T07:59:23-0700,"Lennart would like pattern synonyms. Something like {{{ pattern con var1 … varN = pat }}} where ‘pattern` is a new keyword. * Perhaps there should be a way to give a type as well, so the `con` could be `(con :: type)`. * The `rhs` is type checked as a usual pattern, i.e., in the global environment. * The `pat` should bind exactly `var1` .. `varN`. * Recursive pattern synonyms are not allowed. With `con` in scope it can be used like any other constructor in a pattern, and the semantics is simply by expansion. It would have been very nice if `con` could be used in expressions as well, but I don’t see how that could work with view patterns. Perhaps view patterns could be extended to make them bidirectional. My rationale for wanting pattern synonyms is that I sometimes have pattern matching with a lot of complex repetition in them. I’ve even resorted to using CPP in the past, and that just shows that Haskell is lacking some abstraction mechanism. If pattern synonyms could be made to work in the presence of view pattern it would offer a mechanism for normal pattern matching on abstract types, since the abstract type could export some pattern synonyms and you’d not be able to tell of those were real constructors or not. I’ve not tried implementing this, but I think SHE has something like it. ",simonpj 3,5324,Locally-scoped RULES,Compiler,7.0.3,normal,,_|_,,new,2011-07-14T21:21:24-0700,2011-07-26T23:19:39-0700,"I'd like the following to compile: {{{ module A where f = g where {-# RULES ""g/h"" g = h #-} g = undefined h = undefined }}} This doesn't currently compile, because all RULES have to be top-level. However, GHC permits SPECIALISE pragmas at local scope; the following compiles: {{{ module Test where f :: Num a => a -> a f = g where {-# SPECIALISE g :: Int -> Int #-} g :: Num b => b -> b g x = x + x }}} (Admittedly, this example discards the specialisation, but more interesting examples don't.) I only point out that the SPECIALISE pragma succeeds, because the user manual has the comment that rules subsume the 'Obsolete SPECIALIZE syntax', but in this case they don't. I've got a real example where I would like locally-scoped RULES, but it is rather long, so I will post it as a comment.",reinerp 3,5344,CSE should look through coercions,Compiler,7.0.3,normal,,_|_,simonpj,new,2011-07-25T05:45:12-0700,2011-11-07T15:59:18-0800,"This is probably a known limitation of the CSE pass, but there doesn't appear to be a ticket so I'll make one. Consider the module: {{{ module M where newtype Id a = Id a f (a, b) = (Id a, b) g (a, b) = (a, b) }}} Compiling this with {{{ghc -ddump-simpl -dsuppress-all -O2}}}, we get {{{ g = \ (@ t_adf) (@ t1_adg) (ds_ddl :: (t_adf, t1_adg)) -> ds_ddl f = \ (@ t_adi) (@ a_adj) (ds_ddn :: (a_adj, t_adi)) -> case ds_ddn of _ { (a_aaW, b_aaX) -> (a_aaW `cast` ..., b_aaX) } }}} We see that {{{g}}} shares its argument tuple, but {{{f}}} allocates a new copy of it. Ideally {{{f}}} would also share its argument tuple, and would look like this: {{{ f = \ (@ t_adi) (@ a_adj) (ds_ddn :: (a_adj, t_adi)) -> ds_ddn `cast` ... }}}",reinerp 3,5416,Local modules and Template Haskell declaration splices,Compiler,7.2.1,normal,,_|_,,new,2011-08-16T06:29:39-0700,2011-08-25T09:48:24-0700,"Sometimes you want a Template Haskell splice to expand to a bunch of declarations, ''some of which are not visible to the context''. A trivial example might be {{{ module M where $(f 4) ====> expands to module M where helper = ...blah... real_fun = ...helper.... }}} But `helper` is only a helper function for `real_fun` and should not be exported by M, nor should it conflict with other definitions in M. See #5398 for a more concrete example, and (at the end) a speculative suggestion for ""local modules"" that might be a good design. Another thing you might want is for a splice to expand into some import declarations that bring some new stuff into scope. That too might be possible using this design. Prioity uncertain, details very uncertain. I'm just making the ticket to keep track of the idea.",simonpj 3,5476,Cap memory usage for one thread without disrupting other threads,Runtime System,7.2.1,normal,,_|_,,new,2011-09-09T15:27:12-0700,2011-09-16T05:32:29-0700,"I would like to be able to programmatically guard against runaway memory usage by a thread. If it occurs, I want to be able to handle it gracefully, and I do not want other threads to be disrupted. Note: I [http://stackoverflow.com/questions/7297654/how-to-cap-memory-usage-of-haskell-threads asked this on StackOverflow] a few days ago. The paragraph below is copied from the question. For example, suppose I want to write a server, hosting a scripting language interpreter, that users can connect to. It's Turing-complete, so programs could theoretically use unlimited memory or time. Suppose each client is handled with a separate thread. If a client writes an infinite loop that consumes memory very quickly, I want to ensure that the thread consumes no more than, say, 1 MB of memory, before being alerted with an exception. I do not want other users to be affected when that happens. Ideally, it would be a function like this: {{{ catchHeapOverflow :: Int64 -> IO a -> IO a -> IO a catchHeapOverflow limitBytes handler action = ... }}} It sets a memory usage limit for the current thread (and any child threads, ideally). If this limit is surpassed while performing the action, it invokes the handler (with the usage limit lifted). Granted, the notion of a thread using too much memory makes less sense when objects are shared between threads. Should a thread be blamed for pointing to a lot of memory that another thread gave it? I don't know. Should a thread be blamed for consuming a lot of memory while evaluating a thunk? Absolutely. In my opinion, handling the edge cases perfectly is not as important as being able to do this at all. As long as the user performs all the necessary calculations in one thread and does not export unforced thunks to other threads, s/he should be fine.",joeyadams 3,6030,Typeclass constraint should pick the OverloadedString type.,Compiler,7.4.1,normal,,_|_,,new,2012-04-21T22:04:22-0700,2012-05-01T15:22:07-0700,"{{{ {-# LANGUAGE OverloadedStrings #-} import Data.Text as T class NoDefault a where noDefault :: a -> Text instance NoDefault T.Text where noDefault = id main = print (noDefault ""Hello!"") }}} {{{ default.hs:7:15: Ambiguous type variable `a0' in the constraints: (NoDefault a0) arising from a use of `noDefault' at default.hs:7:15-23 (Data.String.IsString a0) arising from the literal `""Hello!""' at default.hs:7:25-32 Probable fix: add a type signature that fixes these type variable(s) In the first argument of `print', namely `(noDefault ""Hello!"")' In the expression: print (noDefault ""Hello!"") In an equation for `main': main = print (noDefault ""Hello!"") }}}",GregWeber 3,7261,ghci's :info and :browse break encapsulation,GHCi,7.6.1,normal,,_|_,,new,2012-09-21T13:02:29-0700,2013-04-12T09:09:45-0700,"In ghci, :info shows representations of abstract data types. I consider this undesirable, since it breaks abstraction and confuses users. Example: {{{ Prelude> :m +Data.Unique Prelude Data.Unique> :i Unique newtype Unique = Data.Unique.Unique Integer -- Defined in `Data.Unique' }}} I would expect it to behave in the same way as Haddock does, i.e. just show ""data Unique"". Same about the :browse command.",Feuerbach 3,7291,hp2ps should cope with incomplete data,Profiling,7.6.1,normal,,_|_,,new,2012-10-02T16:02:52-0700,2012-10-21T08:55:48-0700,"So that it can be run while the program is generating the profiling data. Anyone who would reimplement hp2ps (e.g. #3024) would probably fix this along, but still this is an issue on its own, hence I’m opening a separate ticket. If someone feels like hacking on it, beware: hp2ps is written in C.",nomeata 3,7662,Improve GC of mutable objects,Runtime System,7.7,normal,,_|_,,new,2013-02-05T02:14:47-0800,2013-04-23T08:34:17-0700,"Haskell is a purely functional language at its core, but it can be also used for workloads involving mutation; it is for these workloads that our GC can be pretty poorly tuned (historically, we’ve fixed these issues case-by-case when they were causing problems for users, e.g. #650). Fortunately, the question of generational garbage collection in the face of lots of mutability is a well-studied one (c.f. the JVM) so this bug asks whether or not we can systematically appropriate any of the machinery developed here for GHC. Some ideas include: * Utilizing card marking at the page level for write barriers, instead of our current mutable lists, * Separating mutable and immutable (and lazy) data on the heaps, to make the previous scheme more likely to work well, * Organizing our generations in different pages, so that checking the generation of any object is as simple as a pointer comparison, * Figure out if we can do better than permanently keeping all mutable arrays permanently on the mutable list (which is really killer when you have lots of tiny mutable arrays), * More mutable closure types to remove the indirection that would normally result from an IORef (actually, you can UNPACK these, and I’m not 100% what happens in that case; it depends on how MutVar#s are represented) There’s probably more things but this is just a start to get things rolling. Test cases and benchmarks also appreciated!",ezyang 4,2614,"Enumeration of values for `Sys.Info.os`, `Sys.Info.arch`",libraries/base,6.8.3,low,minor,7.6.2,mjg,new,2008-09-20T01:39:58-0700,2012-09-12T04:12:16-0700,"It is desirable to have an enumeration of values that might end up in `Sys.Info.os` and `Sys.Info.arch`. Only after much reading of Cabal files and such have I learnt that the former includes (at least) `linux`, `darwin`, `windows` and `freebsd`. (And not, for example, `win32`.) This is only a minor annoyance and I will likely never need to bother with it again -- though I guess I'm still not sure what Solaris is called -- probably `solaris` -- I've got the pattern now, but it would have been much better to see a list.",jsnx 4,3052,ghc FFI doesn't support thiscall,Compiler (FFI),6.10.1,low,normal,7.6.2,,new,2009-02-27T03:59:35-0800,2012-09-12T04:12:16-0700,"The ghc FFI does not support the ""thiscall"" calling convention. This is the calling convention used by Microsoft C++ for calling methods. It's like the stdcall calling convention, except that the ""this"" pointer is passed in ECX. Without this calling convention it's impossible to interact with (Msft) C++ objects. ",augustss 4,3372,Allow for multiple linker instances,Compiler,,low,normal,7.6.2,,new,2009-07-14T15:25:01-0700,2013-03-06T23:03:12-0800,"Right now there is only one RTS linker with a single symbol table.This means, for example, that one cannot have multiple instances of the GHC interpreter in the same process running simultaneously. ",jcpetruzza 4,3373,GHC API is not thread safe,GHC API,,low,normal,7.6.2,,new,2009-07-14T15:31:26-0700,2012-09-12T04:12:16-0700,There are some items of global state (the {{{NameCache}}} and the {{{PackageInterfaceTable}}}) that should be protected. One can workaround this by using a mutex and only invoking GHC API operations in one thread at a time.,jcpetruzza 4,3464,Find import declaration importing a certain function,GHCi,6.10.4,low,normal,7.6.2,,new,2009-08-26T04:40:38-0700,2012-09-12T04:12:17-0700,"Given the command {{{ :find foo }}} , find all import declaration that import this symbol. Example: {{{ > *ModA *ModB *ModC are loaded. }}} Suppose the modules all export Data.List. So, given {{{ module ModX(module Data.List) where import Data.List }}} with X \in {A,B,C} Now, when one currently does :i for a function in Data.List, one gets back that it is defined in Data.List, but that's not the information the user is interested in. The user wants to know which _modules_ define a certain symbol, so in this case it should say that modules ModA, ModB and ModC brought that symbol into scope. The user-interface could also simply be :i as it is now, but with one extra line saying where it was imported. ",fasta 4,3483,"Some mechanism for eliminating ""absurd"" patterns",Compiler,6.10.4,low,normal,7.6.2,,new,2009-09-02T18:09:00-0700,2012-09-12T04:12:17-0700,"This is to help with type-level programming and doing dependent-like programming in Haskell. {{{ data TEq :: * -> * -> * where TEq :: TEq a a -- This declaration fails to compile because bringing (Int ~ Bool) -- into scope on the RHS is unsound. broken :: TEq Int Bool -> Int broken TEq = 1 -- Proposal: -- ""!"" replaces ""="" in function declaration to say ""this pattern is absurd"" proposal :: TEq Int Bool -> r proposal TEq ! -- If, for some reason the pattern match succeeds, -- (basically, someone broke type safety with unsafeCoerce) -- the result could be something like calling: -- error ""absurd pattern at FILE:LINE"" }}} I'm not sure that ""!"" works with Haskell's syntax, but it does call attention to the pattern. The idea is that anywhere that putting ""= some_rhs"" would cause the compiler to fail because it can prove that the type environment is unsound in some fashion, you could use ""!"" to give a valid function definition. The same extension would be used for case statements, of course. See also #2006, which is related in spirit if not in implementation.",ryani 4,3547,Improve granularity of UndecidableInstances,Compiler,6.10.4,low,normal,7.6.2,,new,2009-09-28T05:00:29-0700,2012-09-12T04:12:18-0700,"Currently, as a LANGUAGE pragma, UndecidableInstances can only be set once per file: Assuming that there are enough occasions where one would only need to enable it for one or two instances in a bigger source and considering that the warnings emitted if UndecidableInstances is not set are actually useful, it makes sense to support enabling the extension only on a per-instance basis. proposed syntax: {{{ {-# LANGUAGE UndecidableInstances #-} [code] {-# NOLANGUAGE UndecidableInstances #-} }}}",ksf 4,3619,allow to set ghc search path globally (a'la CPATH),Compiler,6.10.4,low,normal,7.6.2,,new,2009-10-28T06:48:12-0700,2012-09-12T04:12:18-0700," I'd like a mechanism for ghc similar to setting the CPATH variable for gcc. I'd like ghc to look in the given list of paths every time it compiles something, without me having to retype the flags. For ghci there is .ghci, but it gets ignored when I run ghc. ",tari3x 4,3632,"lift restrictions on records with existential fields, especially in the presence of class constraints",Compiler,6.10.4,low,normal,7.6.2,,new,2009-11-02T13:19:40-0800,2012-09-12T04:12:18-0700,"the attached file demos the use of a record with an existential field with a class constraint. it shows several cases where lifting the current restrictions on accessing and updating this field would be both well-defined and useful. here is the record definition; the dur field is existential, but constrained to be in class NoteDur. {{{ data Note = forall x . NoteDur x => Note { midiNum :: Int -- 0-255 , vel :: Int -- 0-255 , chan :: Int -- 0-15 , measure :: Integral a => a , beat :: Int , subdiv :: RealFrac a => a -- % of beat , dur :: x } }}} here is a walk through of places in the code where the current restrictions are unnecessary and intrusive: 1. lines 64-95 -- these functions wouldn't be necessary if record update syntax were enabled for both existential and non-existential fields. i know 6.12 introduces it for non-existentials, but i don't see why it isn't also possible for existential fields (even without a class constraint). lines 33-35 and 60 show how much nicer it is to use regular updater syntax in this case. 2. Line 142. The same is true for existential accessors when there is a class constraint -- there's no need to restrict this situation because the accessor can have type: {{{ fieldName :: (SomeClass x) => Record -> x }}} line 142 shows a case where this would be very nice to have. 3. line 100 + 107 -- the foralls could be implicit (maybe offer an extention that would allow them to be implicit) 4. lines 134-136 compared to 138-139 show how additional factoring could be achieved if one were allowed to pattern match on the type of an existential with class constraints. 5. lines 124-127 show how it would be nice to have existential classes 6. lastly, allow curried updater functions: `(rec {field = }) 5` instead of `(\x -> (rec {field = x})) 5`",eflister 4,3645,Layout and pragmas,Compiler (Parser),6.10.4,low,normal,7.6.2,,new,2009-11-07T04:40:23-0800,2012-09-12T04:12:18-0700,"With this module: {{{ {-# LANGUAGE DeriveDataTypeable, FlexibleContexts #-} module Foo where }}} GHC 6.12 says: {{{ Cannot parse LANGUAGE pragma Expecting comma-separated list of language options, each starting with a capital letter E.g. {-# LANGUAGE RecordPuns, Generics #-} }}} but this should probably be allowed. See #3519, #3616. ",igloo 4,3699,Wildcards in type functions,Compiler,6.10.4,low,,7.6.2,,new,2009-11-27T02:01:09-0800,2012-09-12T04:12:19-0700,"I would like to be able to use wildcards in type synonym family instances, so that I can write: {{{ type instance ErrorAlg (f :>: _) e a = ErrorAlg f e a }}} ",MartijnVanSteenbergen 4,3701,allow existential wrapper newtypes,Compiler,6.10.4,low,,7.6.2,,new,2009-11-28T12:42:04-0800,2012-09-12T04:12:19-0700,"Consider this OO-style thing, a class Compiler, and a most general instance MkCompiler: {{{ class Compiler c where getInstalledPackages :: c -> IO [String] data GHC = GHC { } data NHC = NHC { } ghc :: GHC ghc = GHC { } nhc :: NHC nhc = NHC { } instance Compiler GHC instance Compiler NHC data MkCompiler where MkCompiler :: Compiler c => c -> MkCompiler instance Compiler MkCompiler where getInstalledPackages (MkCompiler c) = getInstalledPackages c compilers :: [MkCompiler] compilers = [MkCompiler ghc, MkCompiler nhc] }}} There's two language features we want to make this really nice: 1. Letting us call the data type `Compiler` rather than `MkCompiler`. That would mean separating the class and type namespaces. 2. Letting us derive the Compiler instance for `MkCompiler`. For the latter we would want either: {{{ newtype MkCompiler where MkCompiler :: Compiler c => c -> MkCompiler deriving Compiler }}} or {{{ data MkCompiler where MkCompiler :: Compiler c => c -> MkCompiler deriving Compiler }}} The advantage of the first is that newtype deriving already exists as a concept so that's nice and consistent. The problem is we do not allow newtypes that use existentials. From an implementation point of view, it's clear that the representations cannot be equal because of the need to store the class dictionary. From a semantic point of view however it's not obvious that existentials with class contexts are illegitimate in newtypes. The underlying implementation would of course have to be an extra layer of boxing, so like data but with the pattern match behaviour newtype.",duncan 4,3753,Make ghci's -l option consistent with GNU ld's -l option,GHCi,6.12.1,low,,7.6.2,,new,2009-12-15T01:50:26-0800,2012-09-12T04:12:20-0700,"Currently, ghci accepts -l options of the format -lxyz. On Linux, this is treated as a request for libxyz.so. The GNU ld -l option is more flexible. It accepts either -lxyz or -l xyz. Also, it accepts -l:filename or -l :filename. When this form is used, the filename is not modified by prepending ""lib"" and appending "".so"". I request that GNU ld's -l forms be accepted by ghci.",hgolden 4,3786,showing function arguments when stopped at its definition,GHCi,6.12.1,low,,7.6.2,,new,2009-12-25T05:00:00-0800,2012-09-12T04:12:21-0700,"It would be cool if GHCi debugger could grab not only the free variables in the selected expression but, in one case, a bit more. The case is when we stop at a function definition the first time (when just entering it). In this case, the debugger should provide the bindings for the function arguments. If a function uses pattern matching or when there are multiple equations with different formal argument names then there may not be any suitable name for the for the actual argument value. Because of this, we introduce the function argument names like: _arg1, _arg2, ... _argN. Numbering starts from 1 for the first formal argument of a function.[[BR]] The special _argN names should be provided always, even when there is a unique name for the argument in the source code. This request was discussed here: http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/17204",phercek 4,3869,RTS GC Statistics from -S should be logged via the eventlog system,Runtime System,6.12.1,low,,7.6.2,,new,2010-02-07T22:38:13-0800,2012-09-12T04:12:21-0700,"The -Sfilename option to the RTS gives useful GC statistics, but it's hard to correlate these with other events, particularly to see if GC is interrupting critical sections in mutator threads. If the same information were instead logged via the eventlog system (perhaps enabled via a ""-lg"" option) one could get more insight into the garbage generation and collection behaviour of one's program. Note that it's probably not necessary also to store the information given at the end of the run with both ""-s"" and ""-S"", though it may be interesting to contemplate moving this sort of thing into the eventlog file as well.",cjs 4,3895,"""Fix"" pervasive-but-unnecessary signedness in GHC.Prim",Compiler,,low,,7.6.2,,new,2010-02-22T12:51:28-0800,2012-09-12T04:12:21-0700,"I'm talking about the array primitives in particular: {{{ writeFloatArray# :: MutableByteArray# s -> Int# -> Float# -> State# s -> State# s }}} Conceptually, a Word# makes more sense as the index for all the array functions. I'm not even sure what the semantics are if the Int# is negative... is it checked? The three scenarios I can think of are: Negativity is checked, and you get an exception. Negativity is unchecked, and you get to write to memory that comes before your array. Negativity is ignored, and the back-end treats the Int# like a Word# already. I think the switch would be worthwhile in all of those cases, and could be hidden in higher-level APIs that still use Int for indexes with a simple int2Word#. Eventually we might even migrate to Word-based APIs at that level?",pumpkin 4,3980,System.Posix.Signals should provide a way to set the SA_NOCLDWAIT flag,libraries/unix,6.12.1,low,,7.6.2,,new,2010-04-11T11:24:40-0700,2012-09-12T04:12:22-0700,"Since FreeBSD and OpenBSD don't conform to POSIX.1-2001 regarding the creation of zombie processes, “installHandler sigCHLD Ignore Nothing” just isn't enough to stop zombies from piling up. They do, however, support the SA_NOCLDWAIT flag to sigaction, and an interface for it would be useful to have. The motivation is this: http://thread.gmane.org/gmane.comp.lang.haskell.xmonad/9780 More info: http://en.wikipedia.org/wiki/SIGCHLD",Liskni_si 4,4016,Strange display behaviour in GHCi,Compiler,6.12.2,low,,7.6.2,,new,2010-04-26T03:08:57-0700,2012-09-12T04:12:23-0700,"Kazu encountered another GHCi oddity. Try "":browse Prelude"" in GHCi. With 6.12 we get {{{ data Integer = integer-gmp:GHC.Integer.Type.S# GHC.Prim.Int# | integer-gmp:GHC.Integer.Type.J# GHC.Prim.Int# GHC.Prim.ByteArray# }}} Why do we get the `integer-gmp:` prefix? There is no ambiguity here. (GHC 6.10 didn't do this, but that's because `Integer` was in the `base` package, whereas now `Integer` is in `integer-gmp`.) ",simonpj 4,4020,Please consider adding support for local type synonyms,Compiler (Type checker),6.12.2,low,,7.6.2,,new,2010-04-26T17:33:29-0700,2012-09-12T04:12:23-0700,"I would really like to be able to put a type synonym in a where clause. I'm willing to specify {{{LANGUAGE ScopedTypeVariables, LiberalTypeSynonyms}}}. For an example use case, please see line 202 of the attachment. ",nr 4,4052,Two sided sections,Compiler,6.12.2,low,,7.6.2,,new,2010-05-07T05:38:27-0700,2012-09-12T04:12:24-0700,"Allow sections to be functions of two arguments: {{{ ( # c ## ) a b === a # c ## b }}} Where the associativities of ''#'' and ''##'' are then used.",aavogt 4,4096,New primops for indexing: index*OffAddrUsing# etc,Compiler,6.12.2,low,,7.6.2,,new,2010-05-25T08:36:53-0700,2012-09-12T04:12:24-0700,"Here's an email from Roman, and response from Simon. Making a ticket so it's kept as an idea. In package vector, primitive vectors (the ones that `Data.Vector.Unboxed` is built on top of) are represented as follows (`ByteArray` and friends are wrappers for various GHC primitives provided by package primitive): {{{ data Vector a = Vector Int -- offset into the ByteArray Int -- length ByteArray -- data }}} This representation supports cheap slicing which is quite crucial. However, indexing into such vectors is a bit more expensive than necessary: {{{ index (Vector i _ arr) j = indexByteArray arr (i+j) }}} Ultimately, this requires 2 additions to get the element's address: {{{ + ((i + j) * ) }}} I'd like to always allocate pinned `ByteArrays` and store the starting address of the vector instead of the offset: {{{ data Vector a = Vector Addr Int ByteArray }}} This would make indexing cheaper as it would require only one addition: {{{ index (Vector addr i _) = indexOffAddr addr i }}} This is quite a big deal if indexing happens in an inner loop (some algorithms become up to 20% faster). Of course, the backend could optimise the offset-based version by performing partial redundancy elimination but it doesn't and it probably wouldn't get all interesting cases even if it did. So the second version is better. The problem is that I can't implement it because I must touch the `ByteArray` after accessing the memory. This results in code like this which hides the constructor, breaking various optimisations: {{{ case indexIntOffAddr# addr# i# of { n# -> case touch# arr# realWorld# of { _ -> I# n# }} }}} After thinking about this for a while, I came up with two possible solutions. One is to provide a ""pure"" version of touch#: {{{ use# :: o -> o' -> o' }}} such that use# x y = y. This would change the code above to: {{{ I# (use# arr# (indexIntOffAddr# addr# i#)) }}} I don't know how to implement this, though, because use# would have to be able to return arbitrary (unboxed) types and the code generator doesn't really seem to support this. A perhaps simpler solution is to add a new set of primitives: {{{ indexIntOffAddrUsing# :: o -> Addr# -> Int# -> Int# ... }}} These would take an additional argument which they'd touch and otherwise ignore. The code would then become: {{{ I# (indexIntOffAddrUsing# arr# addr# i#) }}} Incidentally, the `index*OffAddr#` primitives don't seem to be used anywhere. [Not true: there are a handful of uses of `index*OffAddr#` in libraries/base, mainly GHC.Base.] Simon replies: `indexIntOffAddrUsing#` seems like the way to go, I can't think of a better alternative. ",simonpj 4,4114,Add a flag to remove/delete intermediate files generated by GHC,Compiler,6.10.4,low,,7.6.2,,new,2010-06-02T14:37:46-0700,2013-01-27T09:43:51-0800,"See for example http://stackoverflow.com/questions/1411089/how-to-stop-ghc-from-generating-intermediate-files or http://www.haskell.org/pipermail/xmonad/2010-May/010180.html / Currently GHC generates *.o and *.hi files for executables, possibly quite a few. They take up space, filenames, and interfere with tab-completion. (And they may be worse than that. I occasionally see users in #xmonad who seem to have subtle compilation issues after upgrades linked to stale .hi and .o files.) There doesn't seem to be any good way to remove the intermediates for a program like Xmonad. They can't be redirected to /dev/null, it's a potential security problem to redirect them to /tmp, and removing them manually is difficult (Xmonad could hardwire in removeFiles of 'xmonad.o' and 'xmonad.hi', but what about the arbitrary user modules in ~/.xmonad/lib? Now one needs to start working with globs or utilities like 'find'...). Of course, GHC knows precisely what's being generated, and could easily remove them. So another flag in the line of -fforce-recompilation seems warranted; perhaps -fforce-no-intermediates?",guest 4,4128,Can't capture classes inside a template haskell type quotation,Template Haskell,6.12.1,low,,7.6.2,,new,2010-06-08T16:01:14-0700,2012-09-12T04:12:25-0700,"GHC rejects the following: {{{ {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH class C a where data X = X fmap return $ instanceD (cxt []) [t| C $(conT ''X) |] [] }}} with the error: {{{ test.hs:5:23: Class `C' used as a type In the Template Haskell quotation [t| C $(conT 'X) |] In the second argument of `instanceD', namely `[t| C $(conT 'X) |]' In the expression: instanceD (cxt []) [t| C $(conT 'X) |] [] }}} This is frustrating, since that quotation would have resulted in exactly the TH AST fragment I wanted, had the error not occurred. Instead I must resort to: {{{ instanceD (cxt []) (appT (conT ''Storable) (conT ''X)) [] }}} Incidentally, the error message produced is wrong: The error says 'X whereas I wrote ''X.",lilac 4,4180,do not consider associativity for unary minus for fixity resolution,Compiler (Parser),6.12.3,low,,7.6.2,,new,2010-07-08T08:25:47-0700,2012-09-12T04:12:26-0700,"1. currently an expression ""1 + - 1"" is rejected, because ""1 + (-1)"" looks as being bracketed to the right, whereas + and - are left associative. However, no other bracketing is possible, so ""1 + - 1"" is unambiguous and should not be subject to further fixity resolution. 2. if an infix expressions starts with an unary minus, the associativity should not matter for the unary minus. Why should ""- 1 ## 1"" be rejected for a right- or non-assoc operator ""##""? Precedence alone is sufficient to decide between ""(- 1) ## 1"" and ""- (1 ## 1)"". The latter choice is taken for a higher precedence of the infix operator and the former choice should always be taken for an equal or lower precedence as is done for ""- 1 + 1"", but without looking at associativity! I'll attach an alternative fixity resolution in the spirit of 10.6 of http://www.haskell.org/~simonmar/haskell-2010-draft-report-2/haskellch10.html ",maeder 4,4210,LLVM: Dynamic Library Support,Compiler (LLVM),6.13,low,,7.6.2,dterei,new,2010-07-23T06:05:31-0700,2013-05-15T00:28:26-0700,"dynamic library status: {{{ * Supported: Linux 64bit, Mac OSX 64bit * Unsupported: Linux 32bit, Mac OSX 32bit, Windows 32bit }}} The LLVM backend doesn't support dynamic libraries at the moment. LLC supports a flag called '-relocation-mode' that can be used to support this, it takes the following options: {{{ default - let the target choose. static - static code. pic - PIC code. dynamic-no-pic - Dynamic references but static code }}} This roughly corresponds to GHC -fPIC, and -dynamic flags. Linux: Simply adding the correct flag to LLC seems to work fine. Mac OSX, Windows: Adding the correct flag doesn't work at all, all programs segfault.",dterei 4,4213,LLVM: Add support for TNTC to LLVM compiler suite,Compiler (LLVM),6.13,low,,7.6.2,dterei,new,2010-07-23T06:44:14-0700,2012-09-12T04:12:27-0700,"At the moment we handle TNTC in the LLVM backend in two different ways: Linux/Windows: We use the GNU As subsections feature to order sections. Works very nicely. Slight hack in that we create special section names that contain comments. (Asm injection) Mac: Mac assembler doesn't support the GNU As subsections feature, so we post-process the assembly code produced by llc. Both these methods (especially Mac) are hacks. It would be better to extend LLVM to support the TNTC feature.",dterei 4,4222,Template Haskell lets you reify supposedly-abstract data types,Compiler,6.12.3,low,,7.6.2,,new,2010-07-26T04:02:46-0700,2012-09-12T04:12:28-0700,"Serguey Zefirov writes ([http://www.haskell.org/pipermail/haskell-cafe/2010-July/079802.html on Haskell cafe]) ""Data.Map.Map and Data.Set.Set are exported abstractly, without exposing knowledge about their internal structure. I cannot directly create my own class instances for them because of that. But I found that I can write Template Haskell code that could do that - those data types could be reified just fine."" Good point. It's not quite clear what a better design should be. Haskell controls data abstraction by whether or not the constructors of the data type are exported. But they might be exported by the module that ''defined'' them, but ''not'' to ""clients"" of the data type. So the data type is abstract to some importers but concrete to others. So when should TH let you reify the representation of a data type? Maybe it should let you do so iff * The data constructors of the data type are in scope (somehow) at the reification site So, to take an example: {{{ module Conc( T(..), Blah(..) ) where data T = T1 | T2 Blah data Blah = A | B module Abs( T, Blah ) where import Conc module ReifyA where import Abs foo = reify ''T module ReifyC where import Conc foo = reify ''T }}} So the `reify` in `ReifyC.foo` would ""see"" the data constructors of `T`, but not the one in `ReifyA`. But this approach raises related questions. * What if some, but not all, of `T`'s data constructors are in scope? * What if the data constructors are all in scope, but some mention a type that is not in scope? For example, suppose type `Blah` is not in scope, but you reify `T`? * At the moment, when you reify a data type you get its `Dec`. But if `T` is abstract, what `Dec` can we give it? Just giving it an empty constructor list seems wrong; after all, it might really ''be'' a zero-constructor data type. I suspect we may want a richer data type for `Info` (ie what `reify` returns). All these require design thinking. Does anyone want to lead that debate? Otherwise things will probably stay as they are. I've labelled this as a feature request, although it is a kind of bug, because of this design component. ",simonpj 4,4230,Template Haskell: less type checking in quotations?,Compiler,7.6.3,low,,7.6.2,,new,2010-07-30T06:33:19-0700,2013-05-09T01:38:34-0700,"This ticket introduces two related Template Haskell design questions. It's inspired by several other tickets, for which these issues are the underlying cause * #4135 * #4128 * #4170 * #4125 * #4124 ----------------------- = ISSUE 1 = Consider this module {{{ module M where import ... f x = x $(th1 4) h y = k y y $(th2 10) }}} In our present setup we typecheck down to the first splice, run the splice, then typecheck to the second splice, run that, and so on. But GHC's main structure is: * parse * rename (resolve lexical scopes) * typecheck The above setup makes this impossible. We can't even rename the definition of h until we've run the splice $(th1 4) because that might be what brings k into scope. All this is a bit hard to explain to users. Now suppose that instead we did the following. * Typecheck and run '''top-level''' splices in the renamer That is, when the renamer finds a top-level splice: * rename it * typecheck it * run it * replace the splice by the result of running it * and then rename *that* as if that's what the user had written in the first place But what about nested quotes? eg {{{ $(th1 [| f x |]) }}} Well we can't typecheck that quote, because we don't have a type for f and x, because we are in the renamer. But we don't '''need''' to typecheck the quote to be able to typecheck and run the splice! Remember, we already have a staging restriction that only imported functions can be '''run''' in a top-level splice. So the proposal would mean that we don't attempt to typecheck those nested quotes. Instead they'll be checked after the top-level splice is run, the result spliced in, and the whole shebang typechecked in the context of the program as a whole. This defers the error message, but not too muce, since typechecking the output of the splice is what will happen next. This approach would have a number of rather compelling advantages: * It would allow us to show the program after renaming and splice expansion, but before typechecking. That's quite helpful. It makes it easier to say that we * rename the program, and then * typecheck the program Remember, GHC is also a Haskell library, and the current story (a bit of renaming, a bit of typechecking, then a bit more renaming and a bit more typechecking) complicates the API. * Geoff Mainland's quasi-quotation mechanism is run in the renamer (because it can expand to patterns) so it would make all the TH stuff more consistent. * Even more exciting, we could support pattern splices, thus {{{ f $(g 4) = x+y }}} because the splice $(g 4) would be typechecked and run, perhaps expanding to (x,y), say, by the renamer *before* it goes on to do scope-analysis on x+y. This is exactly why quasiquoting *can* do pattern splicing at the moment, and TH cannot. [[BR]][[BR]] This would fix a long-standing infelicity in TH, namely the absence of pattern splices. * In the same way we could support local declaration splices (which are currently ruled out) {{{ f x = let $(g [| x |]) in .... }}} * At the top level we could get rid of the top-to-bottom bias. We could allow, say {{{ f x = x+x $(th [| g |] [| f |]) g y = y+1 }}} One disadvantage is that it'd ""bake in"" the staging restriction that a splice can only (typecheck and) run functions imported from another module. Currently this is only an implementation restriction, which in principle might be lifted. On the other hand, I have no plans to lift it, and in practice people don't complain about it. ------------------ = ISSUE 2 = Consider this: {{{ f :: Q Type -> Q [Dec] f t = [d| data T = MkT $t; g (MkT x) = g+1 |] }}} This function f returns a declaration splice, declaring T and g. You'll see that the constructor MkT takes an argument whose type is passed (as a quotation) to f -- a type splice. The difficulty is that we can't typecheck the declaration of 'g' until we know what $t is; and we won't know that until f is called. So * we can't really typecheck the declaration quote at all In the case of '''term''' splices in a quotation we can simply give them type (forall a. a), which never gets in the way. But there is no equivalent for *type* splices. An analogous problem occurs in other declaration splices, for example {{{ f t = [d| instance C $t where ... |] }}} Here GHC's check that an instance decl is always of form {{{ instance C (T a b c) }}} falls over, again because we don't know what $t will be. It's hard to see what to do about this. * We could get rid of type splices (but people like them) * We could refrain from typechecking quotations *at all* I have users asking me for exactly this: #4125, #4135 * We could refrain from typechecking *declaration* quotes. But the problem still happens for terms {{{ [| let { f :: $t; f = e } in .. |] }}} * We could refrain from typechecking any quotation that included a type splice. This is probably the most benign: it switches off the type checker just when it's problematic, and it's very predictable when that is. Awkward to implement though. Do you have any other ideas? ---------------------- = DISCUSSION = The two issues are related of course, because both involve doing less typechecking of quotations. That seems a pity, because it'd lose one of TH's advantages -- that of typechecking meta programs rather than just typechecking the output of the meta programs. And in the case of ISSUE 2, error messages might get delayed, perhpas to another module altogether. However, we deliberately designed TH so that it ''is'' possible to get a type error when typechecking the result of a type-correct top-level splice. Reason: we use type Exp rather than (Exp t) as in MetaML. That gave us (a lot) more flexibility. Apart from anything else, declaration splices would be problematic in the MetaML approach. Seen in that light, the proposals here just move a bit further in the direction of flexibility, at the cost of somewhat-increased danger of errors being reported later than is ideal. ",simonpj 4,4316,"Interactive ""do"" notation in GHCi",GHCi,7.0.3,low,,7.6.2,,new,2010-09-14T21:57:53-0700,2012-09-12T04:12:30-0700,"Enable GHCi to run commands under StateT monad based on IO or maybe even any other monad based on IO. So that you could for example exec a state and ""fall"" into this monad. This could be generalized by supporting interactive ""do"" notation. Currently doing something like: {{{ (flip execStateT) state $ do }}} raises ""Empty 'do' construct"" warning, but GHCi could go into interactive mode where it would be possible to write one command after another and it would execute them.",mitar 4,4329,GHC.Conc modifyTVar primitive,Compiler,6.12.3,low,,7.6.2,,new,2010-09-21T13:18:14-0700,2012-09-12T04:12:30-0700,"I would like modifyTVar as a 'write-only' primitive supported by GHC's STM. The semantic definition is: > modifyTVar :: TVar a -> (a -> a) -> STM () > modifyTVar v f = readTVar v >>= writeTVar v . f However, explicitly reading then writing the TVar introduces unnecessary interference between transactions. The value held by the TVar does not affect the behavior of the transaction. modifyTVar should not interfere with other transactions that only writeTVar or modifyTVar. Even if a non-interfering implementation isn't feasible due to the underlying implementation of GHC's STM, providing the function would provide a point for a transparent upgrade in the future. ",dmbarbour 4,4340,Add alignment to hsc2hs template,Compiler (FFI),6.12.3,low,,7.6.2,,new,2010-09-25T15:19:42-0700,2012-09-12T04:12:30-0700,"I think [http://www.haskell.org/haskellwiki/FFICookBook#Working_with_structs commonly used]: {{{ #let alignment t = ""%lu"", (unsigned long)offsetof(struct {char x__; t (y__); }, y__) }}} should be added to official hsc2hs template. What are cons to that?",mitar 4,4426,Simplify the rules for implicit quantification,Compiler,6.12.3,low,,7.6.2,,new,2010-10-22T01:19:18-0700,2012-09-12T04:12:31-0700,"This thread http://www.haskell.org/pipermail/glasgow-haskell-users/2010-October/019360.html convinced me that GHC's rules for implicit quantification are unnecessarily complicated. ------------- == The current spec == The current spec seems to be this: * Define an ""implicit quantification point"" to be (a) the type in a type signature `f :: type` if `type` does not start with `forall`; or (b) a type of form `(context => type)`, that is not immediately enclosed by an explicit `forall` * At each implicit quantification point 'ty', working outside in, GHC finds all the type variables a,b,c in 'ty' that are not already in scope, and transforms 'ty' to (forall a,b,c. ty). Note that * The argument of a constructor is not an implicit quantification point, so that {{{ data Foo = MkFoo (a -> a) }}} is an error, and does not mean {{{ data Foo = MkFoo (forall a. a->a) }}} * Implicit quantification points may be nested but the inner ones are effectively no-ops. Example {{{ f :: Int -> (Eq a => a -> a) -> Int }}} There are two quantification points: the whole type, and the `(Eq a => ...)`. But when the outer quantification point wraps forall a around it, the inner quantification point has no free variables to quantify. So we get {{{ f :: forall a. Int -> (Eq a => a -> a) -> Int }}} -------------- == The new proposal == The proposed new rule is this: * Implicit quantification applies only to an entire user type signature that does not start with `forall`. * For such signatures, find all the type variables a,b,c in the signature that are not already in scope, and prefix the signature with `forall a,b,c.` I believe that the only observable changes in behaviour would be * In a data type declaration {{{ data Foo = MkFoo (Eq a => a -> a) }}} you'd get an error ""a is not in scope"", just as you would with {{{ data Foo = MkFoo (a->a) }}} To me this seems more consistent behavour. * Inside an ''explicit'' `forall` you would get no ''implicit'' `foralls`: {{{ f :: forall a. (Eq b => b->b) -> a -> a }}} would yield ""b is not in scope"", whereas at present it behaves like {{{ f :: forall a. (forall b. Eq b => b->b) -> a -> a }}}",simonpj 4,4429,Ability to specify the namespace in mkName,Template Haskell,6.12.3,low,,7.6.2,reinerp,new,2010-10-22T20:49:04-0700,2013-02-07T17:54:54-0800,"Given {{{ data Foo data Bar = Foo }}} If we do {{{reify (mkName ""Foo"")}}} then we get the information about ""{{{Foo}}} the type"", and not about ""{{{Foo}}} the constructor"". (This is problematic, say, for a quasiquoter {{{ [qq| ... Foo ... |] }}} because the quasiquoter is forced to use {{{mkName ""Foo""}}} as the {{{Name}}} for reify -- the forms {{{'Foo}}} and {{{''Foo}}} are unavailable to it.) I would like a way around this problem. It seems like it would be enough to communicate the namespace to {{{mkName}}}, so that the ambiguity no longer exists.",reinerp 4,4442,Add unaligned version of indexWordArray#,libraries (other),7.1,low,,7.6.2,,new,2010-10-26T08:02:17-0700,2012-09-12T04:12:31-0700,"`indexWordArray#` takes an offset in whole words, making it impossible to do unaligned reads on platforms that support such reads. This has performance implications for some programs e.g. implementations of !MurmurHash. I propose we add versions of `indexWord*Array` that take byte offsets. The user is responsible for only using those on platforms that support them and the implementation is free to crash if they're used elsewhere. ",tibbe 4,4453,Allow specifying .hi files of imports on command line in batch mode,Compiler,6.12.3,low,,7.6.2,,new,2010-10-29T07:31:29-0700,2012-09-12T04:12:31-0700,"It is useful for a build agent (e.g. cabal, or makefile) to have full control over the search path. Reasons you might want to do this are below. The way a build agent can do this is to instruct ghc not to do any searching at all, using the flag `-i` which sets the search path to empty. Then the build agent has to supply ghc with all the `.hs` files that are needed, e.g.: {{{ ghc --make -i Foo.hs Bar.hs }}} (any imports outside of these modules, or the package modules will fail) This no-search scheme works in `--make` mode but not in batch mode. For that we need to be able to say: {{{ ghc -i -c Foo.hs ghc -i -c Bar.hs Foo.hi }}} That is, we need to be able to specify the .hi files of imported modules on the command line. A build agent may want to do this so that it is insulated from the particular choices of ghc's search path semantics and/or have different choices. For example, ghc prefers modules in local .hs/.hi files to package modules while the build agent may want the reverse in some circumstances. Apart from search path policy, it makes sense for a build agent to take this approach simply for correctness and simplicity. A correct build agent must track dependencies absolutely precisely, so it has to know which specific .hi files ghc will pick anyway. It is simpler for the build agent to tell ghc those .hi files rather than trying to precisely arrange things to match ghc's search behaviour.",duncan 4,4459,Polymorphic Data.Dynamic,GHC API,7.1,low,,7.6.2,vivian,new,2010-10-31T04:52:01-0700,2012-09-12T04:12:32-0700,"At some point in the compilation process an expression acquires a fully-specified, possibly polymorphic, type. If we add an operation that join that type and that expresssion, say `TypedAny`, then we can implement the part of #4316 requested by mitar. In GHCi we can evaluate `HValue`s '''and also''' string them together with `bind` statements. The function {{{ applyDynamic :: TypedAny -> TypedAny -> Maybe TypedAny }}} includes in its implementation a dictionary lookup and possible dynamic object linking for class methods. the function {{{ fromDynamic :: TypedAny -> Maybe a }}} like `applyDynamic`, runs the typechecker at runtime to unify (and possibly link) the dynamic type (!TypedAny) and the static type (a). ''Conjecture '' Since we already have `typecase` (classes), with type families, this feature provides/simulates dependent types.",vivian 4,4466,Add extension for type application,Compiler,6.12.3,low,,7.6.2,,new,2010-11-02T12:48:41-0700,2013-04-30T11:40:04-0700," In http://www.haskell.org/pipermail/libraries/2010-October/014761.html we discussed adding an extension for explicit type application. The main stumbling block is syntax. For example, we would like to be able to write something to the effect of {{{ (Just @ Char) 'a' }}} and also to be able to pattern match types, e.g. {{{ f ((Just @ t) x) = (Right @ String @ t) x }}} For a more useful example: {{{ data T where MkT :: forall a. a -> (a -> Int) -> T f (MkT @ a x g) = g (x::a) }}} Possible suggested syntaxes to make something of type {{{ Maybe (forall a. a->a) }}} were: {{{ Just @ (forall a. a->a) id (@ has another meaning in patterns) Just[forall a. a->a] id (pvs, opal, HasCASL with paramterized modules; conflicts with Haskell list syntax) Just {forall a. a->a} id (Agda) #Just (forall a. a->a) id @Just (forall a. a->a) id (coq) }}} In the last 2 cases we would presumably have something like {{{ Just :: forall a . a -> Maybe a Just :: Char -> Maybe Char #Just :: /\ a . a -> Maybe a #Just Char :: Char -> Maybe Char }}} and similarly {{{ #map :: /\ a b . (a -> b) -> [a] -> [b] }}} ",igloo 4,4479,Add Type Directed Name Resolution,Compiler (Type checker),7.5,low,,7.6.2,,new,2010-11-06T12:50:22-0700,2012-09-12T04:12:32-0700,"A request to implement [http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution type-directed name resolution], as [http://hackage.haskell.org/trac/haskell-prime/ticket/129 proposed] for Haskell'.",gidyn 4,4520,"startup code on Windows should use SetDllDirectory("""")",Runtime System,7.0.1,low,,7.6.2,,new,2010-11-22T08:14:30-0800,2012-09-12T04:12:33-0700,"See [http://blogs.msdn.com/b/oldnewthing/archive/2010/11/10/10088566.aspx Raymond's blog] about (un)safe dll loading. He points to a [http://support.microsoft.com/kb/2389418 support article] which recommends that new programs use `SetDllDirectory("""")` to prevent the problem (it's not the default because that'd break old programs). In the GHC context, this could go in the startup code for standalone executables. It is a process-scope property so changing it is not appropriate for DLL startup.",duncan 4,4806,Make error message more user friendly when module is not found because package is unusable,Compiler,7.0.1,low,,7.6.2,,new,2010-11-29T23:33:26-0800,2012-09-12T04:12:33-0700,"Make error message more user friendly when module is not found because package is unusable. Currently it just reports that module is missing (the same as it even would not be installed) but then checking with `ghc-pkg find-module` shows package correctly. Chasing '-v' output around can then show you this but it would be easier that you would immediately get a helpful message. ",mitar 4,4815,Instance constraints should be used when deriving on associated data types,Compiler,6.12.3,low,,7.6.2,,new,2010-12-03T07:34:23-0800,2012-09-12T04:12:33-0700,"Consider this program: {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts #-} class Eq (Associated a) => Foo a where data Associated a instance Foo a => Foo (Maybe a) where data Associated (Maybe a) = AssociatedMaybe (Associated a) deriving (Eq) }}} This does not compile, giving this error message: {{{ /Users/mbolingbroke/Junk/Repro.hs:9:40: No instance for (Eq (Associated a)) arising from the 'deriving' clause of a data type declaration at /Users/mbolingbroke/Junk/Repro.hs:9:40-41 Possible fix: add an instance declaration for (Eq (Associated a)) or use a standalone 'deriving instance' declaration instead, so you can specify the instance context yourself When deriving the instance for (Eq (Associated (Maybe a))) }}} However, this is surprising because I clearly state that a is Foo, and hence (Associated a) has an Eq instance by the superclass constraint on Foo. If I point this out explicitly using standalone deriving it works: {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts #-} {-# LANGUAGE StandaloneDeriving, FlexibleInstances #-} class Eq (Associated a) => Foo a where data Associated a instance Foo a => Foo (Maybe a) where data Associated (Maybe a) = AssociatedMaybe (Associated a) -- deriving (Eq) deriving instance Foo a => Eq (Associated (Maybe a)) }}} So I think the default behaviour for ""deriving"" on an associated data family should be to include the constraints from the enclosing instance. For now the workaround is just to use standalone deriving.",batterseapower 4,4823,Loop strength reduction for array indexing,Compiler,7.1,low,,7.6.2,,new,2010-12-07T08:46:09-0800,2012-09-12T04:12:33-0700,"Indexing into a `ByteArray#` in a loop is currently more expensive than working on a `ForeignPtr` due to lack of strength reduction. Pointer arithmetic is cheaper than using base + offset indexing. We could convert indexing into pointer arithmetic if it weren't for the GC being able to move objects around. Tom Rodriguez had the following to say about Java HotSpot and loop strength reduction: > ""The server compiler doesn't do explicit loop strength reduction though it can get a bit of it as a result of other transformations loop invariant code motion. I've played a bit with doing it more explicitly but had some difficulty getting benefit from it. The resulting pointers are handled by the notion of derived pointers. These are interior pointers that are tracked along with their base pointers. At the beginning of GC the offset from the base of the derived pointer is saved and the pointer is converted to the base and after GC the offset is added back in. That part all happens automatically. Searching for DerivedPointer will lead you to the relevant code."" Perhaps it's an idea we could try?",tibbe 4,4913,Make event tracing conditional on an RTS flag only,Runtime System,7.0.1,low,,7.6.2,,new,2011-01-21T05:53:00-0800,2012-09-12T04:13:24-0700,"The current event tracing mechanism is enabled at link time by linking in one of two different versions of a C function, one being a no-op function. We could allow users to enable/disable tracing using a RTS flag instead, making event logging more convenient to use. At the same time we would introduce tracing levels. Design: Add a static memory location where the current tracing level is stored: {{{ uint tracelevel = 0; }}} Modify `GHC.Exts.traceEvent` to read {{{ foreign import ccall unsafe ""&tracelevel"" :: Ptr Word traceEvent :: String -> IO () traceEvent msg = if unsafePerformIO (peek tracelevel) > 0 then do withCString msg $ \(Ptr p) -> IO $ \s -> case traceEvent# p s of s' -> (# s', () #) else return () }}} and (optionally) add some more functions that log at different trace levels. This should be no slower than the current system. With inlining this should result in a load and a branch at the call site. The load should be cheap as the value is likely to be in cache (as it never changes). The branch should be easy to predict as it's always the same. With some cooperation from the code generator we could make sure that the branch is always cheap. ",tibbe 4,4921,report ambiguous type variables more consistently,Compiler (Type checker),7.0.1,low,,7.6.2,,new,2011-01-26T23:21:18-0800,2012-09-12T04:13:24-0700,"{{{ {-# LANGUAGE MultiParamTypeClasses #-} module Amb where class C a b where f :: (a,b) instance C Int Char where f = undefined {- x = fst f /home/saizan/snippets/Amb.hs:7:8: Ambiguous type variables `a', `b' in the constraint: `C a b' arising from a use of `f' at /home/saizan/snippets/Amb.hs:7:8 Possible cause: the monomorphism restriction applied to the following: x :: a (bound at /home/saizan/snippets/Amb.hs:7:0) Probable fix: give these definition(s) an explicit type signature or use -XNoMonomorphismRestriction Failed, modules loaded: none. -} {- y = fst f :: Int /home/saizan/snippets/Amb.hs:21:8: No instance for (C Int b) arising from a use of `f' at /home/saizan/snippets/Amb.hs:21:8 Possible fix: add an instance declaration for (C Int b) In the first argument of `fst', namely `f' In the expression: fst f :: Int In the definition of `y': y = fst f :: Int Failed, modules loaded: none. -} }}} Both x and y have the same problem, there isn't enough type information to let the typechecker decide on an instance, so it seems they should produce similar error messages. In particular, the error for y is quite confusing since it can be reasonably interpreted as saying there's no type b for which there's an instance C Int b, which in fact is not true, so i think explicitly mentioning the ambiguity like in the first message would help many to understand the problem better. I can see though that an ""instance C Int b"" could make sense, more often than C a b, so maybe ""Possible fix: add an instance declaration for (C Int b)"" should be conserved, even if it still has the problem of expressing that the second argument needs to be a variable.",Saizan 4,4959,Warning about variables with leading underscore that are used anyway,Compiler (Parser),7.0.1,low,,7.6.2,,new,2011-02-14T10:09:29-0800,2012-09-12T04:13:25-0700,"I use -Wall all the time, which includes -fwarn-unused-binds and -fwarn-unused-matches that warn about variable bindings that are not used. It already spotted lots of mistakes for me. You can suppress the warning by prepending an underscore '_' to a variable name. However, I have recently seen code, where variable names with leading underscores are regularly used, where other programmers might have chosen trailing underscores or primes. I suspect that the programmer was not aware, that he disabled warnings about unused bindings this way. Thus I like to have a warning about underscored variables that are used in the sense of the definition given for -fwarn-unused-binds in http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html. We still have to decide whether this warning should be part of -Wall or -fwarn-unused-binds or whether there should be a separate option like -fwarn-used-underscored-binds. ",Lemming 4,4980,Warning about module abbreviation clashes,Compiler,7.0.1,low,,7.6.2,,new,2011-02-24T14:12:46-0800,2012-09-12T04:13:25-0700,"Please add the option -fwarn-module-rename-collision that makes GHC to do the following: If GHC encounters an import situation like {{{ module Main where import qualified Data.A as A import qualified Control.A as A }}} then GHC should emit a warning like {{{ Main.hs:3:0: Main.hs:4:0: Warning: Both Data.A and Control.A are renamed to A. An identifier like A.ident can only be resolved, if it is either in Data.A or Control.A. Better rename both modules to different names. }}} Reason for this warning is, that if 'ident' is from Data.A as of writing Main, and later another variable named 'ident' is added to Control.A, then A.ident can no longer be resolved in Main. That is, by accidental module rename collisions even qualified imports carry the risk of future name collisions. Related to #4977 ",Lemming 4,5016,Make Template Haskell: -ddump-splices generate executable code,Template Haskell,7.0.2,low,,7.6.2,,new,2011-03-11T17:15:12-0800,2012-09-12T04:13:25-0700,"http://hpaste.org/44711/testsunpackedhs I am Aur Saraf, reachable sonoflilit @ don't-be-evil. I wanted to edit some code that was autogenerated by TH with Michael Snoyman's Persistent library (version 0.3.1.3). So I ran it through ghc --make -ddump-splices 2>&1 | less, and in a copy of my original file replaced the TH with the splices. It wouldn't compile, so I googled like crazy and eventually asked for help on #haskell, where the kindly kmc helped me get it to compile. We identified several inaccuracies in the pretty printer. I had to do a few things, among them: * Delete some instances of the keyword ""instance"": {{{ 02:12 < kmc> oh, i think the problem is simply that you don't use the kw ""instance"" for associated types 02:12 < kmc> only for standalone family instances 02:12 < kmc> sorry i didn't remember that earlier 02:13 < kmc> so ghc / TH is being imprecise with how it outputs generated asstype instances [..] 02:14 < kmc> well splices generate abstract syntax trees 02:15 < kmc> and i guess the AST for a family instance inside or outside a class instance is the same 02:15 < kmc> but the concrete syntax differs 02:15 < kmc> and the pretty-printer for that AST is not taking that into account }}} * Change many illegal identifiers: {{{ 01:51 < kmc> sonoflilit, it looks like TH is generating names of the form x[a2ur] 01:51 < kmc> which aren't valid Haskell identifiers 01:52 < kmc> i don't know if that's related to your problem 01:52 < kmc> but it seems to be a reason why this dumped splice won't work as-is }}} * Remove {}s: {{{ 02:23 < sonoflilit> { entityDef _ = Database.Persist.Base.EntityDef 02:24 < sonoflilit> TestsUnpacked.hs:47:4: parse error on input `{' 02:25 < kmc> oh i think ""entityDef _ = ..."" starts off the methods part of the type class instance 02:25 < kmc> so that brace should move to right after ""instance PersistEntity Person where"" 02:25 < kmc> or probably, not exist }}} (also, in other parts of the file) * Fix empty data declarations: {{{ 02:24 < kmc> at line 137-139 you have three ""data instance""s with no right-hand side 02:26 < kmc> does ""data Foo ="" actually work 02:26 < kmc> as an alternative to ""data Foo"" 02:27 < sonoflilit> hmm, tested, no 02:27 < sonoflilit> and you need a special extension to allow ""data Foo"" }}} (I needed to `{-# LANGUAGE EmptyDataDecls #-}`, as well as remove the ""="" from the lines) * Change some wacky syntax: {{{ 02:33 < sonoflilit> kmc: what's wrong with my line 192's ->? 02:33 < sonoflilit> It gives an error after I solved all the { errors 02:36 < kmc> sonoflilit, not sure... try rewriting that pattern as ((x_a3pU,_):_) 02:37 < kmc> that use of qualified infix *should* work 02:37 < kmc> also it keeps using { } to override layout but then not inserting ; 02:39 < kmc> oh ""GHC.Types.[]"" 02:39 < kmc> probably isn't right 02:40 < kmc> unqualify that mo'fo' }}} * Add all sorts of imports: {{{ TestsUnpacked.hs:21:19: Not in scope: type constructor or class `GHC.Int.Int64' TestsUnpacked.hs:31:18: Not in scope: type constructor or class `Web.Routes.Quasi.Classes.SinglePiece' [..] TestsUnpacked.hs:186:20: Not in scope: data constructor `Database.Persist.Base.SqlString' TestsUnpacked.hs:187:26: Not in scope: data constructor `Database.Persist.Base.PersistString' }}} * Copy code from a library because it was private: {{{ TestsUnpacked.hs:67:29: Not in scope: `Database.Persist.TH.apE' }}} * Add parentheses to type constructor definitions: {{{ TestsUnpacked.hs:40:24: `Maybe' is not applied to enough type arguments PersonColorEq Maybe String | becomes PersonColorEq (Maybe String) | }}} * Eventually I gave up at: {{{ TestsUnpacked.hs:61:4: The equation(s) for `toPersistFields' have four arguments, but its type `Person -> [SomePersistField]' has only one In the instance declaration for `PersistEntity Person' TestsUnpacked.hs:87:4: The equation(s) for `persistUpdateToValue' have two arguments, but its type `Update Person -> PersistValue' has only one In the instance declaration for `PersistEntity Person' }}} What I'd recommend the person who takes this bug is to follow my steps to reproduce and then again and again until the file compiles with as few manual changes as possible (perhaps the added language extension and imports are unavoidable, all else is clearly a bug).",guest 4,5059,Pragma to SPECIALISE on value arguments,Compiler,7.0.3,low,,7.6.2,,new,2011-03-29T01:34:49-0700,2012-09-12T04:13:26-0700,"I've sometimes found myself wishing for this pragma to get some ""partial evaluation on the cheap"". The idea is to allow something like: {{{ defaultOpts :: Options defaultOpts = ... {-# SPECIALISE f defaultOpts :: Int -> Int #-} f :: Options -> Int -> Int f opts x = ... f opts ... }}} This would desugar into this additional code: {{{ {-# RULES ""f/spec"" f defaultOpts = f_spec_1 #-} f_spec_1 = (\opts x -> ... ... f opts ...) defaultOpts -- NB: body of f duplicated }}} The hope is that the simplifier and RULE matcher will tidy this up so we get a nice loop back to f_spec_1 with the body of the function specialised for the particular opts. This is useful when functions are called often with particular arguments. An example would be where ""f"" is an edit-distance function which takes costs to be assigned to each edit, strings to be compared and returns an integer distance. In my library, the costs are given almost always going to be the default ones so I want to make that case fast, but I want to allow the user to supply their own set. This pragma is somewhat subsumed by: 1. SpecConstr, if the options are algebraic data/literals that are also scrutinised by the body of f 2. Static argument transformation, except that the RULE based strategy achieves more code sharing compared to SAT I think that pragma might be a relatively simple to implement nice-to-have feature.",batterseapower 4,5171,Misfeature of Cmm optimiser: no way to extract a branch of expression into a separate statement,Compiler,7.0.3,low,,7.6.2,,new,2011-05-06T03:14:36-0700,2012-09-12T04:13:28-0700,"AFAIK, optimisations in Cmm are performed using cmmMachOpFold. However, this function is pure and does not allow detaching a branch of expression in order to make sure that it is executed only once. Let's say we have (Op1 arg1 arg2) and we want to transform it to (Op2 arg1 (Op3 arg2 arg1)). Doing this would mean that arg1 would be computed more than once. Instead, the following should be possible: {{{ arg1_reg <- arg1 (Op2 arg1_reg (Op3 arg2 arg1_reg)) }}} The lack of this feature already stops one of optimisations from happening in most cases. See: {{{ CmmReg _ <- x -> -- We duplicate x below, hence require -- it is a reg. FIXME: remove this restriction. }}} in CmmOpt.hs. There is a number of other useful optimisations which can be implemented only with this feature available.",rtvd 4,5197,Support static linker semantics for archives and weak symbols,Runtime System,7.0.3,low,,7.6.2,,new,2011-05-13T12:16:41-0700,2012-09-12T04:13:29-0700,"While looking at #5004, I had a go at getting the GHCi linker to load the LLVM libs, as in making this work: `ghci -package llvm`. This involves loading a whole bunch of LLVM*.a files and linking them against the C and C++ standard libs. This in turn requires a few more features in the GHCi linker: * support for weak symbols * search archives only on demand * support .oS files in archives The last is trivial. The first is not so hard to do. When the linker finds a definition of a weak symbol, if there's already a symbol with that name in the symbol table then we just ignore the new one. When resolving symbols if we find an unresolved weak symbol we just give it the value zero. Doing this is enough to load .e.g libstdc++.a and libc.a (rather than libc.so). The next part is a bit more work. When you give system static linker some .a files, it only uses them to provide definitions for unresolved symbols in the main target. In particular it is fine for two .a files to provide definitions of the same symbol because the linker just looks for the first. (This is in contrast to duplicate symbols in the main .o input files). On linux, both libm and libc define some of the same symbols, such as `__isinf`. Similarly, there is a problem that the GHCi linker predefines the `atexit` symbol, but that is also defined by `libc.a`. So for the GHCi linker to load both libm and libc then it has to follow the standard semantics for linking archives. Currently it treats an archive as a request to link all the .o files in that archive. Probably it is not sensible to go as far as implementing the full standard static linking semantics in the GHCi linker. It's of somewhat questionable value since we mainly need it for linking Haskell code, not C/C++ code. Nevertheless, if we do need this, then the attached Linker.c has a partial implementation. It does the weak symbols and `.oS` files in archives.",duncan 4,5219,need a version of hs_init that returns an error code for command-line errors,Runtime System,7.0.3,low,,7.6.2,,new,2011-05-25T08:25:42-0700,2012-09-12T04:13:29-0700,"This ticket is extracted from Roman's comment in #4464: `hs_init` simply aborts if it doesn't like the RTS arguments which is quite unhelpful for dynamic libraries. I took me a day to find out that an application crash was caused by a failing hs_init (because of the -rtsopts problem). I would like to add a check for this to our code but there doesn't seem to be a way to do this. It would be much nicer if hs_init returned a failure/success code, at least for dynamic libraries. To which I responded: If hs_init needs to return an error condition rather than aborting, then we need to define a new API for that, and fix setupRtsFlags. I don't think we need to do this for every case of stg_exit and certainly not for barf: these are all internal error conditions and we have no sensible way to recover. ",simonmar 4,5248,Infer type context in a type signature,Compiler (Type checker),7.0.3,low,,7.6.2,,new,2011-06-09T12:02:22-0700,2012-09-12T04:13:30-0700,"If I have code such as {{{ class Foo f where foo :: a -> f a data Bar f a = Foo f => Bar {bar :: f a} instance Foo (Bar f) where foo a = Bar (foo a) }}} GHC will demand `Foo f =>` on the instance declaration, even though this can be inferred from the definition of Bar. I understand ''why'' this is happening, but it should not be necessary to repeat information already given. Some code violates DRY dozens of times because of this limitation.",gidyn 4,5266,Licensing requirements and copyright notices,None,,low,,7.6.2,,new,2011-06-19T10:50:13-0700,2012-09-12T04:13:30-0700,"I'm not sure where or how to bring this up, but I figured I would inform you that complying with the licensing requirements to distribute executables programmed in Haskell (using GHC) seems to be tiresome. I have a personal project written in Haskell and Lua, and I recently tried to make sure that I comply with the necessary requirements to distribute it. My result was a 1660-line copyright file (http://www.houeland.com/kol/docs/copyright), which I believe is excessive. This mostly stems from the use of BSD-style licenses for libraries, which require copyright notices to be reproduced for redistributions in binary form. Many of them are based on code from the GHC project + the Haskell 98 Report + the Haskell Foreign Function Interface specification. I think it would be nice if at least those parts could clearly be distributed using only one reproduction of the GHC license (including allowing derived binary forms to not include the restrictions against claiming to be definitions of the Haskell 98 Language / Foreign Function Interface). Currently the GHC-based libraries have licenses that say they're derived from GHC and include the GHC license notice. The libraries are listed as BSD3 in cabal files, but it's not clear to me that the statement actually covers licensing for the entirety of the library (developments after the split), and whether all GHC-based libraries can currently be distributed using a single copyright notice. Generally, many of the other available Haskell libraries also seem to use BSD-style licenses, which can be a hassle to comply with for binary redistributions, mostly when dependencies also use separate BSD-style licenses that must be included. Having a 'default' license in the Haskell community that's similar to Boost or zlib instead of BSD3 might be preferable for the many smaller libraries available. Many of the libraries actually have different licenses (but similar ones such as MIT, or people modifying parts of their license file) while being listed as BSD3 in cabal files. I don't know exactly what you can do about this, but an easier licensing landscape for binary redistributions would certainly be nice. (And possibly tools for automatically listing licensing restrictions and producing copyright notices accurately.) ",houeland 4,5273,error and undefined should print a location,Compiler,7.1,low,,7.6.2,,new,2011-06-24T11:50:14-0700,2012-09-12T04:13:31-0700,"The Control.Exception.assert function has a very nice hack so it prints a location together with the message. Could we please have that feature for 'error' and 'undefined' as well? I just had the case where in one of 83 installed packages some idiot has an error message that just says 'dataTypeConstrs', which makes it very tedious to figure out what to fix. Yes, I can recompile everything for profiling, but that takes another two hours, which is why I'd prefer location information. (BTW, hbc had location info for those.)",augustss 4,5288,Less noisy version of -fwarn-name-shadowing,Compiler,7.0.3,low,,7.6.2,,new,2011-06-28T15:26:26-0700,2012-09-12T04:13:31-0700,"I would like a flag that warns about name-shadowing in more restricted circumstances than the current flag. I.e. I would like examples like these not to produce a warning: {{{ foo x = .. where bar x = ... }}} {{{ baz z = do z <- .... z ... return z }}} But I would like these to produce one: {{{ foo x = .. where x = ... x ... }}} {{{ baz z = mdo z <- .... z ... return z }}} Basically warn when a definition shadows *itself*. My motivation is that code like my first two examples is almost never an error in my experience, but my last two examples almost always are examples of my accidentally building a loop that evaluates to _|_.",batterseapower 4,5296,Add explicit type applications,Compiler (Type checker),7.0.3,low,,7.6.2,,new,2011-07-03T10:30:35-0700,2013-04-30T11:39:13-0700,"This example is derived from code in my application. It works, but I can't add a signature to it. In other places it is preventing some code from compiling at all. {{{ {-# LANGUAGE KindSignatures, MultiParamTypeClasses, RankNTypes #-} {-# OPTIONS -Wall #-} module Test where class C t1 t2 m where method :: Int -> m t2 f :: forall t1 t2 (m :: * -> *). C t1 t2 m => Int -> m t2 f x = method x }}}",dsf 4,5308,Generalize -msse2 command line flag to -msse,Compiler,7.0.4,low,,7.6.2,,new,2011-07-07T10:21:51-0700,2012-09-12T04:13:32-0700,"I'm looking into adding support for the `popcnt` instruction. The instruction should be used if the user specifies `-msse4.2`*. I think we should generalize the `-msse2` flag to be just `-msse` followed by a version number. * Although not formally part of the SSE 4.2 instruction set, the `popcnt` instruction was added at the same time. GCC enables the `popcnt` instruction if you specify `-msse4.2`, so I thought it'd be reasonable for us to do so as well. ",tibbe 4,5918,hsc2hs forces wordsize (i.e. -m32 or -m64) to be the choice of GHC instead of allowing a different (or no/default choice),hsc2hs,7.4.1,low,,7.6.2,,new,2012-03-07T13:56:09-0800,2012-09-12T04:13:34-0700,"I am not sure whether to call this a bug as it does not cause a failure of GHC but a failure of UHC which also uses hsc2hs. The problem occurs when UHC builds for a different wordsize than GHC, in particular UHC 64 bits, GHC 32 bits. The wrapper then forces -m32 when running hsc2hs via the environment variable HSC2HS_EXTRA. This cannot be turned off. A (temporary) solution is to uncomment the following lines in the wrapper script /usr/bin/hsc2hs: {{{ # -c*) HSC2HS_EXTRA=;; # --cc=*) HSC2HS_EXTRA=;; }}} This turns off the extra flags when a C compiler is explicitly specified, amongst which the -m32, and just lets the user define (or not define) the required flags when another compiler is explicitly used. ",Atze 4,3977,Support double-byte encodings (Chinese/Japanese/Korean) on Windows,libraries/base,6.13,low,,7.8.1,batterseapower,new,2010-04-10T23:38:50-0700,2013-05-10T14:56:28-0700,"localeEncoding uses the console code page for text file encoding/decoding for single-byte encoding environment on Windows. But GHC.IO.Encoding.CodePage.Table doesn't have double-byte encodings (Chinese/Japanese/Korean), now. Its current state often causes problem on double-byte encoding environment. * http://hackage.haskell.org/trac/hackage/ticket/658 * http://hackage.haskell.org/trac/hackage/ticket/659 I know we can solve problem by using hSetEncoding with utf8 or othere UTF-* encodings. But it's not good solution. According to previous Windows patch, GHC.IO.Encoding.CodePage.Table doesn't support double-byte encodings because Windows' shared library support doesn't work. * http://www.haskell.org/pipermail/cvs-libraries/2009-September/011289.html * http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=packages/base;a=commitdiff;h=20090913022126-9f663-2bb505cf915b18313bf41a25853d9d13d7444feb.gz {{{ Currently we do not support double-byte encodings (Chinese/Japanese/Korean), since including those codepages would increase the table size to 400KB. It will be straightforward to implement them once the work on library DLLs is finished. }}} I think Windows' shared library support works now. Because #3879 is closed. So, how about add supporting double-byte encodings (Chinese/Japanese/Korean) on Windows?",shelarcy 4,307,Implicit Parameters and monomorphism,None,None,low,minor,_|_,,new,2005-02-16T09:01:08-0800,2009-07-17T17:34:58-0700,"{{{ http://www.haskell.org/pipermail/haskell-cafe/2005-January/008571.html Notes some oddness with recursive binding of implicit parameters. Roughly, giving a type signature to a function with implicit params causes its bindings to act recursively, despite what section 7.4.5.2 of the user's guide says. }}}",nobody 4,1192,"GHC-only IOErrorType constructors, and is*Error(Type) functions",Compiler,6.6,low,minor,_|_,,new,2007-03-04T05:22:45-0800,2013-01-22T08:43:30-0800,"Currently we don't have `is*Error` and `is*ErrorType` functions for those constructors of `IOErrorType` below the `GHC only` comment. It would be nice to add them, but better still to make the constructors known to the other implementations first.",igloo 4,1231,deprecation warnings are reported too often,Compiler,6.6,low,normal,_|_,simonpj,new,2007-03-16T04:18:36-0700,2013-01-21T15:00:00-0800,"Not so much a bug, more an annoyance. In some code which is designed to work on multiple compiler platforms, there are some system dependencies such as the name/location of non-standard libraries. Accordingly, I gather all such deps into a single module SysDeps.hs, which is heavily reliant on cpp #ifdefs, but whose only purpose is to re-export the non-standard entities needed by the rest of the project. So far so good. Now it turns out that ghc-6.6 has deprecated some of the non-standard libraries. Fair enough, I would expect to see the deprecation warnings when I compile SysDeps.hs. But in fact, I see multiple deprecation warnings - one for every deprecated entity, used in any module. So instead of seeing 5 or so warnings, nicely localised to a single module, I see 40 or so, smeared out across the whole project. An example: {{{ Import.hs:9:28: Warning: Deprecated use of `unpackPS' (imported from SysDeps, but defined in Data.PackedString): use Data.ByteString, Data.ByteString.Char8, or plain String. }}} As you can see, the warning mechanism is aware that it is doing a transitive closure over imports. But really, I'd prefer it not to, and instead to report the deprecation only in the directly-importing module.",malcolm.wallace@… 4,1311,newtypes of unboxed types disallowed - documentation bug and/or feature request,Compiler,6.6.1,low,normal,_|_,,new,2007-04-29T10:32:19-0700,2008-09-30T08:52:06-0700,"Tested in 6.6.1 and today's 6.7 (which claims to be version 6.7.20070418), {{{newtype FastBool = FastBool Int#}}} doesn't work. However this is not documented in the unboxed-types documentation in the User's Guide that lists similar restrictions http://www.haskell.org/ghc/docs/latest/html/users_guide/primitives.html Similarly (maybe), in phantom type arguments, even in GADTs where kind inference could be at work {{{data Boo a where Boo :: Int# -> Boo Int#}}} doesn't work. I tried {{{newtype ( FastBool :: # ) = ...}}} , and {{{data Boo ( a :: # ) where...}}} , which just confused GHC. Is there a reason that coercions of unlifted types shouldn't work, or is it just unimplemented? (inspired by looking at GHC's compiler/utils/FastTypes.lhs and thinking that using newtypes instead of type synonyms in places like that would improve type-safety)",Isaac Dupree 4,1388,Newbie help features,GHCi,6.6.1,low,trivial,_|_,,new,2007-05-28T07:49:25-0700,2009-11-16T05:07:15-0800,"Often a newbie comes to #haskell and asks why something doesn't work in ghci. There are at least two cases: ""why doesn't type Bar = (Char, Int) work""? and ""why doesn't f = 1 work?"" (that is function definitions) It wouldn't be much work to recognize these cases and then give the user some hints on putting those definitions into a file, etc. Another case where error messages can be improved is the following: type Foo = (char, int) -- the intention is clear, but the error message might not be clear to a new user. Suggestion: when the parsed type variables are the same modulo case to an existing core type(Int, Bool, Array, etc) and Foo doesn't take those type parameters, tell the user he needs to use proper casing.",guest 4,1628,warning(s) for using stolen syntax that's not currently enabled,Compiler,6.6.1,low,normal,_|_,,new,2007-08-22T09:02:38-0700,2013-01-26T14:24:56-0800,"Turning on `-fglasgow-exts` makes {{{f x = id$x}}} break. I propose having a flag to warn about things like this, enabled by `-Wall`. To be precise, ""stolen syntax"" is syntax that means something valid in (usually) Haskell98 and something different with some extension enabled. If there are syntax-stealing extensions implemented by other non-GHC compilers, we may want to warn about those too. (This includes all keywords, possibly other words like ""forall"", ""exists"", ""family"", unicode symbols for `->` and others...) If anyone actually agrees on or implements a (optional) change to unary-minus, this would subsume the warning aspects of #1318.",Isaac Dupree 4,1768,More flexible type signatures for data constructors,Compiler,6.6.1,low,normal,_|_,,new,2007-10-10T02:29:29-0700,2013-01-26T14:41:01-0800,"See [http://article.gmane.org/gmane.comp.lang.haskell.cafe/29409], and the rest of the thread. The idea is to allow data constructor declarations to have things like this: {{{ type Foo = Int -> Bool -> T data T where C :: Foo }}} This is a silly example, but the idea is not to require the arrows to be all visible at top level, and to allow the result type to be something other than visibly `T` itself. I'm recording this as a feature request, since it came up on Haskell Cafe, but I'm not sure that I like it. The type signatures in data type declarations are pretty special: notably, they allow record syntax, and support strictness annotations.",simonpj 4,2204,Improve 'patterns not matched' warnings,Compiler,6.8.2,low,trivial,_|_,,new,2008-04-08T10:17:45-0700,2010-02-19T11:40:30-0800,"Compiling the following with `-fwarn-incomplete-patterns`: {{{ module Asdf where f :: String -> Int f ""0"" = 0 g :: Int -> Int g 0 = 0 }}} Yields: {{{ asdf.hs:4:0: Warning: Pattern match(es) are non-exhaustive In the definition of `f': Patterns not matched: [] (GHC.Base.C# #x) : _ with #x `notElem` ['0'] (GHC.Base.C# '0') : (_ : _) asdf.hs:7:0: Warning: Pattern match(es) are non-exhaustive In the definition of `g': Patterns not matched: GHC.Base.I# #x with #x `notElem` [0#] }}} Losing the 'GHC.Base' stuff along with the various octothorpes would make the error messages a lot nicer. Ideally it'd be something like `Patterns not matched: x where x `notElem` [0]` for the second case, for instance.",Deewiant 4,2708,Error message should suggest UnboxedTuples language extension,Compiler (Parser),6.9,low,minor,_|_,,new,2008-10-18T15:51:12-0700,2008-11-27T20:14:40-0800,"If I compile this code: {{{ module Foo where import GHC.Integer foo x y = case x `quotRemInteger` y of (# y, z #) -> 42 }}} I get: {{{ foo.hs:7:5: Parse error in pattern }}} It would be better if the error message suggested using {{{-XUnboxedTuples}}}.",tim 4,2896,Warning suggestion: argument not necessarily a binary operator,Compiler,6.10.1,low,normal,_|_,,new,2008-12-23T23:12:32-0800,2008-12-29T05:36:24-0800,"As an example: {{{ let fn (+) = 1; fn x = 2 in fn 1 }}} The suggested warning is that: if an argument to a function consists entirely of characters which are symbols (all isSymbol), and the type of that argument isn't (a -> b -> c), then produce a warning. Suggested wording is something along the lines of ""Warning: the argument '(+)' isn't necessarily a binary operator, although it looks like one. This may be confusing to readers of your code.""",porges 5,1365,-fbyte-code is ignored in a OPTIONS_GHC pragma,GHCi,6.6.1,lowest,minor,7.6.2,,new,2007-05-19T11:19:08-0700,2012-09-12T04:13:36-0700,"When loading a bunch of modules in ghci with ''-fobject-code'', it seems reasonable to be expect that individual ''GHC_OPTIONS -fbyte-code'' pragmas will have the effect of loading individual modules via the bytecode backend.",mnislaih 5,1379,Allow breakpoints and single-stepping for functions defined interactively,GHCi,6.7,lowest,normal,7.6.2,,new,2007-05-25T13:49:06-0700,2013-01-22T08:34:06-0800,"Steps to reproduce (from ghc-HEAD sources for 25 May 2007): {{{ Prelude> let fib n = if n < 2 then 1 else fib (n-1) + fib (n-2) Prelude> let main = print $ fib 30 Prelude> :break fib ghc-6.7.20070515: panic! (the 'impossible' happened) (GHC version 6.7.20070515 for i386-unknown-linux): nameModule fib{v apa} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude> }}}",Michael D. Adams 5,1420,Automatic heap profile intervals,Profiling,6.7,lowest,minor,7.6.2,,new,2007-06-08T10:56:52-0700,2012-09-12T04:13:37-0700,"When doing heap profiling it is sometimes hard to know what a good sampling interval is. Make it too small and it takes forever, make it too coarse and the resolution is bad. In hbc the default setting was to automatically adjust the interval. It starts out very small, but as samples accumulate it gets larger and larger. This is a nice compromise.",guest 5,1534,"[Debugger] Watch on accesses of ""variables""",GHCi,6.7,lowest,normal,7.6.2,,new,2007-07-13T14:03:31-0700,2012-09-12T04:13:39-0700,"I would like to put a ""watch"" on certain parts of records. With such a watch in place, when writing to such a part of a record (e.g. foo{bar = 2} a new break point would be activated and the current line number would be shown somewhere. I believe the ""watch"" terminology is used in other debuggers. Often such a breakpoint will halt in a set_foo_bar function. This obviously would be the wrong result. The result should be a chain of calls like in the output of -xc. The user should be able to quickly move through such chains (with showing line numbers, etc).",iampure@… 5,1574,Broken link testing,Documentation,6.6.1,lowest,normal,7.6.2,,new,2007-08-01T15:22:46-0700,2013-01-26T13:18:22-0800,"On http://www.haskell.org/ghc/dist/current/docs/ the link ../users_guide/index.html is broken. Suggested fix to make sure this never happens again: let a broken link analyser be part of the build bots.",iampure@… 5,1721,Make GHCi print the entire result of an interactive 'bind' statement,Compiler,6.6.1,lowest,normal,7.6.2,,new,2007-09-20T00:39:56-0700,2013-01-26T14:32:38-0800,"Suppose {{{ foo :: Int -> IO (Maybe Int, Bool) }}} Then here's a GHCi interaction: {{{ Prelude> foo 3 (Just 3,True) -- Entire result printed Prelude> (Just x, _) <- foo 3 3 -- Value of x printed Prelude> (Just x, y) <- foo 3 -- Nothing at all printed Prelude> (_, _) <- foo 3 -- Nothing at all printed Prelude> }}} GHCi prints the result of a bind, `p <- e`, if and only if the pattern `p` binds exactly one variable. This is a bit odd; you get no info if it binds more than one. A different and simpler behaviour would be to print the entire result every time. That is, all the commands above would print `(Just 3, True)`. I'm recording this ticket so that we remember the suggestion. I don't know for sure if it's a good one. Add comments if you have an opinion",simonpj 5,1885,Improve CPR analysis,Compiler,6.8.1,lowest,normal,7.6.2,simonpj,new,2007-11-13T04:49:04-0800,2013-01-26T14:58:41-0800,"When a function returns a ''nested'' data structure, GHC should expose that fact to the caller. This can make a very big difference in inner loops. A good example is the following message (from GHC users http://www.haskell.org/pipermail/glasgow-haskell-users/2007-November/013454.html). Compile the attached files thus: {{{ ghc --make Unpacked.hs -O2 -cpp -DPOLY_SAME }}} and similarly with `DPOLY_OTHER`. The `POLY_OTHER` case does a lot more allocation because a key function isn't inlined. {{{ $wa_r1Wb :: GHC.Prim.Addr# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, OtherP.C GHC.Float.Double (OtherP.C GHC.Float.Double (OtherP.C GHC.Float.Double ())) #) [GlobalId] [Arity 2 NoCafRefs Str: DmdType LL] $wa_r1Wb = \ (ww_s1S5 :: GHC.Prim.Addr#) (w_s1S7 :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.readDoubleOffAddr# @ GHC.Prim.RealWorld ww_s1S5 0 w_s1S7 of wild2_a1xI { (# s2_a1xK, x_a1xL #) -> let { ipv_XGd [Just L] :: GHC.Prim.Addr# [Str: DmdType] ipv_XGd = GHC.Prim.plusAddr# ww_s1S5 8 } in case GHC.Prim.readDoubleOffAddr# @ GHC.Prim.RealWorld ipv_XGd 0 s2_a1xK of wild21_X1yK { (# s21_X1yN, x1_X1yP #) -> case GHC.Prim.readDoubleOffAddr# @ GHC.Prim.RealWorld (GHC.Prim.plusAddr# ipv_XGd 8) 0 s21_X1yN of wild22_X1yU { (# s22_X1yX, x2_X1yZ #) -> (# s22_X1yX, OtherP.C @ GHC.Float.Double @ (OtherP.C GHC.Float.Double (OtherP.C GHC.Float.Double ())) (GHC.Float.D# x_a1xL) (OtherP.C @ GHC.Float.Double @ (OtherP.C GHC.Float.Double ()) (GHC.Float.D# x1_X1yP) (OtherP.C @ GHC.Float.Double @ () (GHC.Float.D# x2_X1yZ) GHC.Base.())) #) } } } }}} ",simonpj 5,1894,Add a total order on type constructors,Compiler (Type checker),6.8.1,lowest,normal,7.6.2,,new,2007-11-14T11:22:11-0800,2013-01-26T20:04:49-0800,"Several proposals for ExtensibleRecords can be implemented as libraries if type constructors can be ordered globally. This proposal is to add built-in types: {{{ data LabelLT data LabelEQ data LabelGT type family LabelCMP }}} such that, for any two datatypes {{{ data N = N data M = M }}} the instance {{{LabelCMP N M}}} takes one of the values {{{LabelLT, LabelEQ, LabelGT}}} depending on the lexicographic ordering on the fully-qualified names of {{{N}}} and {{{M}}}. ",guest 5,2075,hpc should render information about the run in its html markup,Code Coverage,6.8.2,lowest,normal,7.6.2,andy@…,new,2008-02-04T14:31:15-0800,2013-01-26T17:28:11-0800,"To check if a generated coverage test is up to date, it would be useful to have hpc annotate its generated output with the date of the run, the compiler version, and OS info. Perhaps also information about which packages were included in the build.",dons 5,2104,Add Labels,Compiler,6.8.2,lowest,normal,7.6.2,,new,2008-02-17T02:53:55-0800,2012-09-12T04:13:45-0700,"This is an alternative to #1894 to support the implementation of ExtensibleRecords. This version is more complex, but both more orthogonal to the rest of the language, and supports better record features. 1. Add a new syntactic class[[BR]] label -> ( {{{'}}} (small | large | digit) {small | large | digit | {{{'}}} }),,,, A label {{{'name}}} is interpreted as a conid at the value level, and as a tycon at the type level, with an implicit declaration: {{{ data 'name = 'name }}} but with global scope, so the same label in different modules is the same value/type. 2. Add a built-in one-parameter type class {{{Label}}} with no methods, and for each label {{{'name}}} an implicit instance {{{ instance Label 'name where }}} No other instances of {{{Label}}} are allowed. 3. Add a built-in type synonym family {{{LabelCMP}}} of kind {{{* -> * -> *}}}. For every pair of labels {{{'name1}}} and {{{'name2}}}, one of the instances {{{ LabelCMP 'name1 'name2 = LabelLT LabelCMP 'name1 'name2 = LabelEQ LabelCMP 'name1 'name2 = LabelGT }}} is implicitly defined, depending on the lexicographic order of {{{'name1}}} and {{{'name2}}}. No other instances of {{{LabelCMP}}} are allowed. (The types {{{LabelLT}}}, {{{LabelEQ}}} and {{{LabelGT}}} are datatypes with no constructors, which can be declared in a library.) ",barney 5,2110,Rules to eliminate casted id's,Compiler,6.8.2,lowest,normal,7.6.2,,new,2008-02-18T08:07:14-0800,2013-01-14T17:55:28-0800," Some people (e.g. jedbrown, who originally brought this up) have/use C libraries that deal with arrays of doubles (i.e. CDouble) that they would like to use from Haskell code, with the Double type (perhaps there are instances of some classes for Double, but not CDouble). In jedbrown's case he has a CArray datastructure that wraps the C array and is an instance of Haskell's IArray. However, people doing this sort of thing tend to care a lot about performance, so don't want to spend O(n) time doing O(n) allocation. Thus the temptation is to make the assumption that CDouble == Double, and to create the `CArray i Double` directly. The more correct way to do it would be to make a `CArray i CDouble` and then use `amap realToFrac` to convert it to a `CArray i Double`. However, I don't believe that GHC is currently smart enough to optimise away `amap realToFrac`. Let's look at a simpler example: {{{ cdoubles :: [CDouble] cdoubles = read ""foo"" doubles :: [Double] doubles = map realToFrac cdoubles }}} (here `map` is playing the role of `amap`). The core for this looks like (very simplified) {{{ Q.a1 = \ (ds_aMc :: Foreign.C.Types.CDouble) -> ds_aMc Q.doubles = GHC.Base.map (Q.a1 `cast` ) Q.cdoubles }}} It looks to me that if we could produce {{{ Q.doubles = GHC.Base.map (id `cast` ) Q.cdoubles }}} instead then we might be able to have a rule {{{ forall mumble . map (id `cast` mumble) = id `cast` mumble' }}} The major problem, as far as I can see, is how to construct the `mumble'`. Does that sound plausible? ",igloo 5,2119,explicitly importing deprecated symbols should elicit the deprecation warning,Compiler,6.8.2,lowest,normal,7.6.2,,new,2008-02-22T19:12:31-0800,2012-09-12T04:13:45-0700,"If we explicitly import but do not use a deprecated function then ghc does not give the deprecation warning. {{{ module Foo where {-# DEPRECATED foo ""don't use foo please, use ..."" #-} foo = ... }}} {{{ module Bar where import Foo (foo) }}} This is a bit annoying since it means client packages do not get any notification that some function is going to disappear but they would break if it does disappear. Or to look at it another way, it prevents me removing old deprecated functions because I don't want to break client programs but I have no way of communicating that to the author of a program that is importing but is no longer using the deprecated function. My real world example is the Cabal lib and lhs2tex's Setup.hs file. It is importing `Distribution.Simple.LocalBuildInfo.mkDataDir` (which is deprecated in the current released Cabal version) but the Setup.hs is not actually using it, so the author got no indication that it should not be imported anymore. In the development version of Cabal I'd already removed this deprecated function since I assumed we'd given everyone plenty of warning. I'll have to go add `mkDataDir` back.",duncan 5,2135,Warn if functions are exported whose types cannot be written,Compiler,6.8.2,lowest,normal,7.6.2,,new,2008-03-04T14:59:42-0800,2012-09-12T04:13:45-0700,"It should be possible to warn if a function is exported from a module whose type is hidden, and thus the function's type can't be written down directly by the user. With the proliferation in type level programming in Haskell (and its use in libraries), situations can arise where functions are exported from a module which can be used, but whose type cannote be written, but where the type is complex enough that it really is required to write it down for the code to compile. This happened recently in the takusen library. A warning for this situation would help authors of libraries avoid this situation. ",dons 5,2168,ghci should show haddock comments for identifier,GHCi,6.8.2,lowest,normal,7.6.2,,new,2008-03-22T02:05:06-0700,2012-09-12T04:13:55-0700,"This came up in comp.lang.haskell recently: http://groups.google.com/group/comp.lang.haskell/msg/ae69f720377e7a3f I like the idea. Immediate thoughts: * if ghci reads the source file, it can read haddock annotations * if ghci reads the interface file only (for library modules), it needs to find the installed documentation On the other hand the requested feature is a typical IDE functionality (cf. Eclipse/show source/show javadoc) and it's perhaps a bit much to require that from ghci. ",j.waldmann 5,2215,:disable command to disable breakpoints,GHCi,6.9,lowest,major,7.6.2,,new,2008-04-11T10:23:41-0700,2013-01-29T08:35:50-0800,"Okay, I've finally gotten around to trying the debugger, and I noticed that there don't seem to be any commands to disable or reenable breakpoints. These would be really nice, and probably not too difficult. The names should be {{{:disable}}}and {{{:enable}}}. (That's what I expected them to be.) Man, I wish there was a severity between ""normal"" and ""major""...",SamB 5,2258,ghc --cleanup,Compiler,6.8.2,lowest,normal,7.6.2,,new,2008-05-01T15:51:29-0700,2013-01-27T09:44:12-0800,"calling `ghc --make` generates a lot of files, `.o`, `.hi`, `.exe`, `.exe.manifest`, .. moreover, those files may be in different directories, etc. a nice way to get rid of all those leftovers would be a `ghc --cleanup`, with the same options and parameters as `ghc --make`, which would delete everything that `ghc --make` would generate.",claus 5,2269,Word type to Double or Float conversions are slower than Int conversions,Compiler,6.8.2,lowest,normal,7.6.2,dons@…,new,2008-05-07T16:17:36-0700,2012-09-12T04:13:57-0700,"We have int2Double# and int2Float# primitives, but not equivalent ones for Word types. We may need word2Double# too, for Words* to be fully first-class performance-wise. This means we have to do extra tests in the Num instances for Word types to implement 'fromIntegral': {{{ toInteger (W# x#) | i# >=# 0# = smallInteger i# | otherwise = wordToInteger x# where i# = word2Int# x# }}} Now, for some types, we work around this: {{{ ""fromIntegral/Int->Word"" fromIntegral = \(I# x#) -> W# (int2Word# x#) ""fromIntegral/Word->Int"" fromIntegral = \(W# x#) -> I# (word2Int# x#) ""fromIntegral/Word->Word"" fromIntegral = id :: Word -> Word }}} and so on for other Word/Int types. And all is fine. The problem comes up for Float and Double. For Int, we can write: {{{ ""fromIntegral/Int->Float"" fromIntegral = int2Float ""fromIntegral/Int->Double"" fromIntegral = int2Double int2Float :: Int -> Float int2Float (I# x) = F# (int2Float# x) int2Double :: Int -> Double int2Double (I# x) = D# (int2Double# x) }}} But we can't write these rules for Word types. The result is a slow down on Word conversions, consider this program: {{{ main = print . sumU . mapU (fromIntegral::Int->Double) $ enumFromToU 0 100000000 }}} When in lhs is Int, we get this nice code: {{{ $wfold :: Double# -> Int# -> Double# $wfold = \ (ww_s18k :: Double#) (ww1_s18o :: Int#) -> case ># ww1_s18o 100000000 of wild_a14T { False -> $wfold (+## ww_s18k (int2Double# ww1_s18o)) (+# ww1_s18o 1); True -> ww_s18k }}} But for Word types, we get: {{{ $wfold :: Double# -> Word# -> Double# $wfold = \ (ww_s1gN :: Double#) (ww1_s1gR :: Word#) -> case gtWord# ww1_s1gR __word 100000000 of wild_a1do { False -> case case >=# (word2Int# ww1_s1gR) 0 of wild1_a1cS { False -> case word2Integer# ww1_s1gR of wild11_a1d9 { (# s_a1db, d_a1dc #) -> case {__ccall __encodeDouble Int# -> ByteArray# -> Int# -> State# RealWorld -> (# State# RealWorld, Double# #)}_a1bT s_a1db d_a1dc 0 realWorld# of wild12_a1bX { (# ds1_a1bZ, ds2_a1c0 #) -> ds2_a1c0 } }; True -> int2Double# (word2Int# ww1_s1gR) } of wild1_a1bM { __DEFAULT -> $wfold (+## ww_s1gN wild1_a1bM) (plusWord# ww1_s1gR __word 1) }; True -> ww_s1gN } }}} Which is to be expected, and the running time goes from: {{{ $ time ./henning 5.00000000067109e17 ./henning 1.53s user 0.00s system 99% cpu 1.534 total }}} To: {{{ $ time ./henning 5.00000000067109e17 ./henning 4.57s user 0.00s system 99% cpu 4.571 total }}} So not too bad, but still, principle of least surprise says Word and Int should behave the same. Should we have a word2Double# primop?",dons 5,2333,Emit a warning if an INLINE function is a loop breaker,Compiler,6.8.2,lowest,normal,7.6.2,,new,2008-06-03T08:02:50-0700,2012-09-12T04:13:57-0700,"If a function is marked INLINE by the user, but can't be inlined because it is a loop breaker, then it would be good to emit a warning of some kind. ",simonpj 5,2340,Improve Template Haskell error recovery,Template Haskell,6.8.2,lowest,normal,7.6.2,,new,2008-06-04T08:47:53-0700,2012-09-12T04:13:57-0700,"Marc Weber wants better error recovery in TH's Q monad: http://www.haskell.org/pipermail/template-haskell/2008-May/000666.html The Quasi monad is defined thus: {{{ class (Monad m, Functor m) => Quasi m where -- Fresh names qNewName :: String -> m Name -- Error reporting and recovery qReport :: Bool -> String -> m () -- Report an error (True) or warning (False) -- ...but carry on; use 'fail' to stop qRecover :: m a -> m a -> m a -- Recover from the monadic 'fail' -- The first arg is the error handler -- Inspect the type-checker's environment qReify :: Name -> m Info qLocation :: m Loc -- Input/output (dangerous) qRunIO :: IO a -> m a }}} A sensible change (but it would be a change) would be to change `qRecover` thus: {{{ qRecover :: m a -> ([(Bool,String)] -> m a) -> m a -- (qRecover q f) runs the action `q`, collecting all the messages -- emitted by `qReport`. If the action `q` calls the monad `fail`, -- these messages are passed to `f`. If the action `q` does not call -- `fail`, the messages are retained in the monad, just as if the -- `qRecover` was not there. }}} Comments? This would be quite easy to implement in 6.10. Simon",simonpj 5,2345,":browse limitations (browsing virtual namespaces, listing namespaces)",GHCi,6.8.2,lowest,normal,7.6.2,,new,2008-06-04T16:16:25-0700,2012-09-12T04:13:58-0700,"1. :browse cannot be used with virtual namespaces: {{{ import Prelude () import qualified Data.List as Folds(foldr) import qualified Data.Maybe as Folds(maybe) }}} {{{ *Main> :browse *Main Folds.foldr :: (a -> b -> b) -> b -> [a] -> b Folds.maybe :: b -> (a -> b) -> Data.Maybe.Maybe a -> b *Main> :browse *Folds Could not find module `Folds': Use -v to see a list of the files searched for. }}} it would be useful if GHCi's :browse supported this Haskell module system feature, allowing ""virtual"" namespaces to be browsed just like ""real"" ones. 2. to use :browse, one needs to know the precise module name when using some packages, like OpenGL, i never can remember where in the hierarchy their modules are placed, so i can't even get started :browsing them. (a) it would be useful if `ghc-pkg` functionality was part of the `GHC API`, and accessible from within GHCi, or if GHCi knew which instance of `ghc-pkg` it is associated with (`:!ghc-pkg field OpenGL exposed-modules` does not work unless the ghc-pkg in the PATH happens to match the GHCi in use..). (b) it would be nicer if GHCi's `:browse` itself had an option to list available namespaces matching a pattern, so that one could narrow down to what one wants to `:browse`",claus 5,2365,Warn about suspicious flags in OPTIONS_GHC pragmas,Compiler,6.8.2,lowest,normal,7.6.2,,new,2008-06-16T13:48:44-0700,2013-01-27T11:13:03-0800,"We should warn if suspicious flags are given in `OPTIONS_GHC` pragmas; in particular, if any `-XLanguage` flag is used.",igloo 5,2460,provide -mwindows option like gcc,Compiler,6.8.2,lowest,normal,7.6.2,,new,2008-07-21T07:32:28-0700,2012-09-12T04:14:00-0700,"provide a command line option -mwindows (aka main windows) to compile and link the code as a windows executable (i.e. WinMain). This is mearly a matter of passing through the option to gcc and would be trivial to implement. see #2459 for full discussion. Why Bother ? To enahnce ""User Friendliness"" and encourage gui users on win32 aka wxHaskell and Gtk2Hs users to produce application with ""Native"" look and feel.",jvl 5,2514,Add/Expose Binary API that allows dumping of any GHC Binary instance,GHC API,6.9,lowest,normal,7.6.2,nominolo,new,2008-08-12T14:37:50-0700,2012-09-12T04:14:00-0700,"Serialising Names requires that a symbol table is being provided in the BinHandle so that a string can be mapped to an index in the symbol table. API clients like Haddock need this so they can use all Binary instances of GHC data types. Whether a symbol table is provided or not is best reflected in the type (using phantom types / type labels). For example: {{{ data Put symtab a = ... data Symtab instance Monad (Put b) where ... instance Put a Foo where ... instance Put Symtab Name where ... runPut :: ... -> Put () a -> IO a putWithSymtable :: ... -> Put Symtab a -> IO a }}} Similarly for a Get monad (feature suggested by David Waern)",nominolo 5,2522,Warning for missing export lists,Compiler,6.8.3,lowest,minor,7.6.2,,new,2008-08-18T21:01:59-0700,2013-02-02T19:20:27-0800,"It occurred to me that it would be nice to have a warning for modules that lack an export list. Obviously not everybody prefers to write export lists for all their modules, but that's why it would be an optional warning. (It would also be handy to use in conjunction with {{{-fwarn-unused-binds}}}.) If there is already such a flag, then the task is to add it to the users' guide, since I don't see it there :-)",tim 5,2526,warn about missing signatures only for exported functions,Compiler,6.8.3,lowest,normal,7.6.2,,new,2008-08-20T13:14:20-0700,2013-02-02T19:29:14-0800,"The -fno-warn-missing-signatures option results in warnings if signatures are not declared for any top-level functions. Many Haskell users prefer to declare type signatures only for exported functions, which are part of the module's interface, not for all functions. It would be nice to have an option that issued warnings iff any exported functions lacked explicit signatures.",fergushenderson 5,2531,Prune duplicates in ghci history,GHCi,6.8.3,lowest,normal,7.6.2,,new,2008-08-21T14:57:24-0700,2012-09-12T04:14:01-0700,"When we enter the same expressions in ghci, all of them go in to history. It'd be useful to have an option to eliminate duplicate expressions before storing them in ghci history. We can also consider doing this for storing ghci history as a file.",venkat 5,2550,Add an option to read file names from a file instead of the command line,Compiler,6.9,lowest,normal,7.6.2,,new,2008-08-27T12:47:30-0700,2012-09-12T04:14:01-0700,"As discussed in the following thread: http://www.haskell.org/pipermail/haskell-cafe/2008-August/046494.html Add an option to look for modules using manifest files, rather than assuming that the filesystem contains a hierarchy of directories that exactly matches the module hierarchy. This is desirable for the following reasons: * It avoids an ugly and ad hoc dependency between two unrelated domains. * In large and complex projects, it allows the project manager more flexibility in using directory structure to organize teams and manage complex version control setups. * It avoids problems caused by mismatch between the filesystem and the module hierarchy, such as a non-hierarchical file system or incompatibilities in the way files are named. * It allows for more than one module per file. This is helpful because the module system is the only way to achieve encapsulation in Haskell, so the system needs to be as lightweight and flexible as possible. It also makes it easier to share and distribute Haskell programs when it is most convenient to do so as a single file, such as literate Haskell via email.",YitzGale 5,2598,Avoid excessive specialisation in SpecConstr,Compiler,6.8.3,lowest,normal,7.6.2,,new,2008-09-16T02:37:31-0700,2013-03-07T08:51:46-0800,"This ticket captures an email thread so it doesn't get lost. Consider this (from `haddock/src/Haddock/Backends/Hoogle.hs`): {{{ dropComment (' ':'-':'-':' ':_) = [] dropComment (x:xs) = x : dropComment xs dropComment [] = [] }}} This desugars thus: {{{ dropComment xs = case xs of (C# x1 : xs1) -> case x1 of ' '# -> case xs1 of (C# x2:xs2) -> case x2 of '-' -> .... DEFAULT -> dropComment (C# x2 : xs2) DEFAULT -> ... [] -> ... }}} I have elided the branches that are less interesting, and I have done a bit of multi-level pattern matching to save space. The thing to notice is this: at the recursive call, we know that the argument is a cons, with C# at the front. So `SpecConstr` dutifully creates a specialized version. And similarly for ''each subsequent character''! Indeed, if the match fails after matching `(' ': '-' : )` prefix, the recursive call even knows that the first char is `'-'`! Hence we get as many specializations as we have characters in the input match. So `SpecConstr` is behaving as expected. Can anyone think of a heuristic to squash this behavior? At the moment we take the first N specializations and then stop. One heuristic might be ""if there are lots of recursive calls, don't specialize"". But that is very close to ""if there are lots of specializations, drop some"". Mind you, perhaps we should be more vigorous still: ""if there are more than N, don't do any"" on the grounds that randomly choosing the first few is unlikely to be useful. Any thoughts? ",simonpj 5,2600,Bind type variables in RULES,Compiler,6.8.3,lowest,normal,7.6.2,simonpj,new,2008-09-16T04:29:22-0700,2013-02-02T19:51:30-0800,"Roman writes: here's an example I came across while working on the recycling paper and which I subsequently forgot about. Suppose we have: {{{ {-# LANGUAGE Rank2Types #-} module T where class T t where to :: [a] -> t a from :: t a -> [a] tmap :: (a -> a) -> t a -> t a {-# RULES ""myrule"" forall f x. from (tmap f (to x)) = map f (from (to x)) #-} }}} Alas, this fails with: {{{ Ambiguous type variable `t' in the constraint: `T t' arising from a use of `to' at T.hs:12:40-43 Probable fix: add a type signature that fixes these type variable(s) }}} Of course, I'd like the t on the rhs to be the same as on the lhs but I don't see how to tell this to GHC. Is it actually possible? The only solution I've found was to add a dummy argument to 'to': {{{ to' :: t a -> [a] -> t a to = to' undefined {-# RULES ""myrule"" forall f t x. from (tmap f (to' t x)) = map f (from (to' t x)) #-} }}} That's ugly, of course. Am I missing something or is this just impossible to do with the current system? ",simonpj 5,2640,Treat -X flags consistently in GHCi,Compiler,6.8.3,lowest,normal,7.6.2,,new,2008-10-02T01:25:25-0700,2012-09-12T04:14:02-0700,"Currently GHCi treats -X language extension flags as follows: the -X extension applies to both code typed to the GHCi prompt, and to modules loaded by GHCi. This happens whether the -X flag is given on the command line when invoking GHCi, or in a `:set` command. But there is one exception! The `-XExtendedDefaultRules` flag applies ''only'' to modules loaded by GHCi. For code typed at the GHCi prompt, the `-XExtendedDefaultRules` flag is always on, and cannot be switched off. This is (a) inconsistent and (b) awkward if you ''want'' to switch it off. Talking to Simon, the Right Thing seems to be to this: * GHCi should maintain two sets of flag settings: one for the GHCi prompt, and one for loaded modules * The two flat-sets are initialised identical, except that `-XExtendedDefaultRules` is set for GHCi. * Command-line flags are applied to both flag-sets. * The `:set` command affects both flag-sets * Add a new `:set-local` command to affect the GHCi prompt flag-set only. * (It's probably not worth a command that affects only the loaded modules.) It's not clear how urgent this is. Add yourself to cc list if you care, and add a comment. Simon",simonpj 5,2641,Revise the rules for -XExtendedDeafultRules,Compiler,6.8.3,lowest,normal,7.6.2,,new,2008-10-02T01:31:47-0700,2012-09-12T04:14:02-0700,"The `-XExtendedDefaultRules` flag is very liberal about type-class defaults. Perhaps too liberal: {{{ > *Main> quickCheck (\xs -> reverse xs == xs) > +++ OK, passed 100 tests. }}} Not good (reverse on lists is not the identity function). I expect a type error! Reason: reverse on list of () is indeed the identity function! [http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules The rules] are currently these: * All of the classes Ci are single-parameter type classes. * At least one of the classes Ci is numeric, or is Show, Eq, or Ord. Maybe we should tighten up the second rule to say: * '''All''' of the classes Ci is numeric, or is Show, Eq, or Ord. Then the Quickcheck example would not bogusly succeed in typechecking, because there's an `Arbitrary` constraint involved. This ticket is to record the idea and canvas opinion. Record thoughts below. See also * #2853 * #2854",simonpj 5,2648,Report out of date interface files robustly,GHCi,7.6.3,lowest,normal,7.6.2,,new,2008-10-03T01:42:32-0700,2013-05-03T03:56:54-0700,"Suppose `X.hi` refers to `Y.f77`, but `Y.hi` is out of date and has no `f77`. Then you get a bad crash: {{{ (GHC version 6.8.3 for i386-unknown-mingw32): tcIfaceGlobal (local): not found: Please report this as a GHC bug }}} The solution lies within our grasp: * X.hi already contains a fingerprint for Y.hi * So, we should simply check Y.hi's fingerprint when we suck it in (Currently we do this fingerprint checking only for the module we are currently compiling, to see if the bits it depends on have changed.) Simon",simonpj 5,2721,Newtype deriving doesn't work with type families,Compiler,6.10.1,lowest,normal,7.6.2,,new,2008-10-21T19:12:52-0700,2012-09-12T04:14:03-0700,"This assumes `-XTypeFamiles -XGeneralizedNewtypeDeriving`. Example: {{{ class C a where type T a foo :: a -> T a instance C Int where type T Int = Int foo = id newtype N = N Int deriving(C) }}} This happily produces an `instance C N` but no `type instance T N`. It should either (preferably) generate {{{ type instance T N = Int }}} or fail. The example also compiles if `T` is a data family (the `Int` instance needs to be change accordingly). It should probably fail in this case. BTW, this also compiles fine, with rather dramatic consequences: {{{ type family T a class C a where foo :: a -> T a type instance T Int = Int instance C Int where foo = id type instance T N = Double newtype N = N Int deriving(C) }}} I guess this last example is the same bug as #1496. I wonder if the deriving clause could generate something like: {{{ instance T Int ~ T N => C Int }}} ",rl 5,2737,add :tracelocal to ghci debugger to trace only the expressions in a given function,GHCi,6.8.3,lowest,normal,7.6.2,,new,2008-11-03T12:14:25-0800,2012-09-12T04:14:04-0700,"As there is :steplocal, there should be also :tracelocal. It would keep history of evaluations within a given function. When an acces to a variable is needed it would be searched first in the selected expression and if not found the search would continue in the expressions from the trace history. If the value used would originate from the trace history it should be indicated so in the output: at the end or beginning of the output there would be the list of identifiers which values were taken from trace history. This would avoid the tedious task of searching the trace history manually and moreover it would limit the history to the interesting parts (so hopefully the current depth of 50 would be enough). :tracelocal should take an optional argument which defines the function to trace. Similar options as for a breakpoint specification (:break command) would be fine. It might be usefull to associate the tracelocal trace with breakpoint and having an option to set it on for given breakpoint (in such a case it would be possible to add tracelocal flag for a breakpoint). Note that the results from the trace history may not be from the expected scope but the same problem is with ""printf debugging"" which is an efficient way to debug Haskell programs now too. The list of identifiers which were taken from trace history (while evaluating an interactively entered expression) should be provided because of the posibility to get values from an unexpected scope. This should be a cheap way to make ghci debugger better than just plain ""printf debugging"", especially when used together with scriptable breakpoints (where one could script each breakpoint individually - not only all of them at once with :set stop). The best solution from user point of view would be just to provide access to all the variables which are in scope in a given expression (not just the free ones) but it is believed that it would introduce too much overhead. Here is the url of the thread head where this proposal started to evolve: http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015840.html",phercek 5,2803,bring full top level of a module in scope when a breakpoint is hit in the module,GHCi,6.8.3,lowest,normal,7.6.2,,new,2008-11-23T10:57:18-0800,2012-09-12T04:14:04-0700,"It should do something like {{{:module + *ModuleWhereBreakpointWasHit}}} and remove the added top level symbols of {{{ModuleWhereBreakpointWasHit}}} when we leave it. The goal is so that the functions which are in scope when we hit a breakpoint are readily available for investigations of the values stored in the free variables of the selected expression. This feature request is a consequence of the dicsussion in this ticket http://hackage.haskell.org/trac/ghc/ticket/2740#comment:4 ... and a realated thing: When I do something like {{{:module + ModName}}} and later I do {{{:module + *ModName}}} then the non-exported symbols from {{{ModName}}} are not added into the scope.",phercek 5,2836,Data.Typeable does not use qualified names,Compiler,6.10.1,lowest,minor,7.6.2,,new,2008-12-01T15:32:56-0800,2012-09-12T04:14:05-0700,"The !TyCon in Data.Typeable does not provide the qualified type name. This can be very annoying if you try to use a !TypeRep as a stored representation of a type (within a run it's OK with the equality on !TypeRep). I suggest that the !TyCon be enhanced to contain a qualified name, but that the current API be maintained, except for adding some new functions to access qualified name. If prodded I could provide the Data.Typeable implementation and the fix to ghc. ",guest 5,2945,add command :mergetrace,GHCi,6.10.1,lowest,normal,7.6.2,,new,2009-01-13T06:36:56-0800,2012-09-12T04:14:06-0700,"Currently trace history is stored in ""Resume"" context. I'm not aware of any good reason for this but it results in problems during debugging. The point is that one cannot extend currently active trace history using "":trace "" while stopped at breakpoint. The nested trace history is extended instead. But the nested history is freed when the "":trace "" command finishes so there is no access to the trace data. This makes it hard to investigate why the output of the trace command looks the way it was printed: it is not possible to investigate values of variables which contributed to the value. A discussion about the reasons for global trace history is here: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-January/016436.html",phercek 5,2946,tracing should be controled by a global flag,GHCi,6.10.1,lowest,minor,7.6.2,,new,2009-01-13T08:12:01-0800,2012-09-12T04:14:06-0700,"Instead of "":trace"" and "":trace "" command there should be one command "":set trace on/off"" and a new command "":debug "". "":set trace"" would control a global flag indicating whether tracing should be active or not. If tracing is active then:[[BR]] * "":continue"" would behave like current "":trace"",[[BR]] * forcing a value using "":force "" woudl work like current "":trace "" but ignoring breakpoitns,[[BR]] * "":debug "" would work like current "":trace "",[[BR]] * and "":main ..."" would start Main.main with tracing on from the very beginning.[[BR]] If tracing is not active then "":continue"", "":force"", "":main"" would behave like they do now and "":debug "" would be the same as current """". Reasoning: I believe people use tracing to get access to variables which are not free in the selected scope but which contributed to values in the selected scope. So if they want variable availability they want tracing on all the time if they care about speed they want tracing off all the time. With this change request accepted they do not need to remember which command to use to continue or to print a forced value. When an is an argument to a ghci command and tracing is on then trace hisotry is extended, if tracing is off then trace history is not extended, if is typed on the ghci command line directly then tracing is never extended. This change is not that important for manual ussage but it helps to simplify custom defined ghci comamnds/scripts (which e.g. will not need to take care whether to use "":continue"" or "":trace"" based on a global flag). This would also allow to start tracing from the very beggining of "":main"" instead of setting a break at Main.main with a script set to "":trace"" and then running "":main ..."". Related discussion is here: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-January/016436.html I do not know about other usage patterns for which the current state of tracing UI is better. If you do know then vote against this.",phercek 5,2950,show breakpoint numbers of breakpoints which were ignored during :force,GHCi,6.10.1,lowest,trivial,7.6.2,,new,2009-01-14T07:36:19-0800,2012-09-12T04:14:06-0700,"Extend message ""*** Ignoring breakpoint"" (which is printed during :force evalutation) so that it contains basic information about the breakpoint ignored. Add at least the breakpoint number.",phercek 5,2986,:info printing instances often isn't wanted,GHCi,6.10.1,lowest,normal,7.6.2,Remi,new,2009-01-28T14:56:54-0800,2013-03-25T04:22:18-0700,":info shows all instances of types/classes, which often obscures the info I'm actually interested in. See the output of e.g. "":info Show"" or "":info [] Maybe Int"": The class and types are rather lost in between the instances. My proposal is to add an option to suppress the printing of instances. With the attached patch for 6.10.1 (although it applies to HEAD too), "":info -Show"" will only print the class.",Remi 5,3000,:break command should recognize also nonexported top level symbols in qualified IDs,GHCi,6.10.1,lowest,normal,7.6.2,,new,2009-02-03T06:11:23-0800,2012-09-12T04:14:07-0700,"When a breakpoint is defined for a qualified function name ('' (''' conid . ''')+ '''varid''' ''). Then the name should be found even when it is not exported (i.e. when varid is not in the export list).[[BR]] The qualification ensures no ambiguity can happen so it should be allowed since it is line number independent which means breakpoint definitions sourced with "":."" would be more robust against code modifications.",phercek 5,3032,would be nice if -fno-code and --make worked together,Compiler,6.8.2,lowest,normal,7.6.2,,new,2009-02-16T11:46:10-0800,2012-09-12T04:14:07-0700,"We had a Cabal feature request to omit linking to make it quicker in the use case that we just want to check that a package typechecks ok. Omitting liking is good but we could save more time by omitting code generation too. The `-fno-code` would seem to be what we want in this case but it looks like it only works with batch mode and not `--make` mode. What happens at the moment when one uses `-fno-code --make` is that ghc cannot find the dependent modules, though it is not clear that it is actually looking for `.hi` files in any particular location. This is with 6.8.2, I've not checked with 6.10 but I assume it is the same. So if it looks like it would not be too hard to do, then letting `-fno-code` work with `--make` would be occasionally useful. The expected result would be to write out the `.hi` files for all the modules but not the corresponding `.o` files. When combined with `-O0` we might hope it to be a bit quicker than normal builds. Of course it would not work in the case of template Haskell, but Cabal would just avoid using `-fno-code` if the package uses TH.",duncan 5,3122,Enhance --info,Compiler,6.10.1,lowest,normal,7.6.2,duncan,new,2009-03-24T08:31:01-0700,2012-09-12T04:14:09-0700,"We should: * Add things like C compiler, assembler, linker, libdir into the `--info` output * Generalise `--print-libdir` such that `--print-foo` prints the foo field from the `--info` output. ",igloo 5,3123,make INLINE work for recursive definitions (generalized loop peeling/loop unrolling),Compiler,6.11,lowest,normal,7.6.2,,new,2009-03-25T09:48:55-0700,2012-09-12T04:14:09-0700,"Inlining refers to the unfolding of definitions, ie replacing uses of identifiers with the definitions bound to them. Doing this at compile time can expose potential for other optimizations. As described in the User Guide, this is currently limited to non-recursive definitions, to avoid non-terminating recursion in the inliner. Unfolding Recursions Since many definitions in non-trivial programs are either recursive themselves or are built from recursion combinators, leaving recursion out of inlining alltogether is a serious limitation, especially in view of the encoding of loops via tail recursion. In conventional languages, loop transformations such as loop unrolling are at the heart of optimizing high performance code (for a useful overview, see Compiler Transformations for High-Performance Computing, ACM Computing Surveys, 1994). As a consequence, many performance-critical Haskell programs contain hand-unrolled and hand-peeled recursions, which is error-prone and obscures declarative contents. More details, examples, and an informal spec: wiki:Inlining",claus 5,3140,(Windows?) GHCi doesn't load hierachical modules,GHCi,6.10.1,lowest,normal,7.6.2,,new,2009-04-02T07:17:39-0700,2012-09-12T04:14:09-0700,"On Windows, if you double-click a `*.hs` file, GHCi starts up and loads the corresponding module. Usually this works fine, however... it seems to trip over on hierachical module names. Specifically: * Create file `Foo\Bar.hs` containing a module `Foo.Bar` that imports `Foo.Baz`. * Create file `Foo\Baz.hs` containing a module `Foo.Baz`. * Double-click on `Foo\Bar.hs`; GHCi whines that it can't find `Foo.Baz` in the search path. This happens regardless of whether either of the modules is compiled or not. An easy work-around is to invoke GHCi from the command prompt with the CWD below the `Foo` folder. But it's kind of tedious to have to do that. Note that if `Foo.Bar` doesn't import anything (or only modules from packages) then it works just fine. GHCi just doesn't seem to be able to find source files in the current folder if they have hierachical names.",Orphi 5,3192,Add dynCompileCoreExpr :: GhcMonad m => Bool -> Expr CoreBind -> m Dynamic to ghc-api,GHC API,6.10.2,lowest,normal,7.6.2,,new,2009-04-25T07:08:23-0700,2012-09-12T04:14:09-0700,"The above function would behave much like dynCompileExpr, but skipping the front end. This is extremely useful for tools that are able to produce core code easily themselves from internal data structures. The Bool would indicate (as with compileCoreModule) whether to invoke the simplifier.",guest 5,3251,split rts headers into public and private,Runtime System,6.10.2,lowest,normal,7.6.2,,new,2009-05-21T05:29:24-0700,2012-09-12T04:14:10-0700,"C code calling into the rts, eg to initialise it, uses header files like `HsFFI.h` or `RtsAPI.h`. However these header files that describe the public API of the rts are installed in `$libdir/ghc-x.y/include` where as the standard location for public header files should be `$prefix/include/ghc-x.y`. The private header files that are only used by `.hc` files when compiling `-fvia-C` should remain where they are. So this would involve identifying which headers are public and which are private. Once we have a set of public header files it might be nice to provide a `pkg-config` .pc file to make it easy for C programs to locate the header files and libraries. Eg it should be possible to compile and link a C program that uses the RTS public API with just: {{{ gcc -o main main.c `pkg-config --cflags --libs ghc-rts-6.12.1` }}} and this would supply the flags like {{{ -I/usr/include/ghc-6.12.1 -lHSrts -L/usr/lib/ghc-6.12.1 }}} Note that `pkg-config` supports both shared and static libs (ie allows specifying the extra private deps of a static lib, eg `-lm -ldl` etc).",duncan 5,3282,How to start an emacs editor within ghci asynchronously with :edit filename.hs :set editor emacs & don't go,GHCi,6.10.2,lowest,normal,7.6.2,,new,2009-06-07T14:15:01-0700,2013-01-02T01:40:19-0800,"Hi Haskell Team, if i set my editor to "":set editor emacs &"" and - say- want to edit my aaa.hs file , I enter "":edit aaa.hs"", the ghci console answers: ""/bin/sh: a.hs: not found"", instead of opening emacs asynchronously. ("":set editor nohup emacs"" does not help either) then while editing emacs even i can enter commands ? into ghci, but they are not performed at all. GHCi's work goes on not before I close emacs. help is appreciated, Hape - Novice ;-) ",petersonx 5,3314,Add compilation date to +RTS --info,Compiler,6.10.2,lowest,normal,7.6.2,,new,2009-06-20T01:30:29-0700,2012-09-12T04:14:10-0700,"I don't know how hard this would be, but it would be nice to add a timestamp in +RTS --info to show the date/time when the program was compiled. Additionally, it would be nice to be able to get at this programmatically - System.Info would seem a logical place. (Presumably if the program is interpreted rather than compiled, the ""compilation time"" would be the current time.)",Orphi 5,3452,Show type of most recent expression in GHCi,GHCi,6.10.4,lowest,normal,7.6.2,,new,2009-08-22T22:24:30-0700,2012-09-12T04:14:11-0700,"Currently, any expression resulting in a value with no `Show` instance results in an error message. This is confusing for new users (especially if they don't yet understand typeclasses) and overly verbose for experienced users. Instead, the REPL should simply display the type of the expression, as if the user had used `:t`.",ozy 5,3870,Avoid Haddock-links to the Prelude,Documentation,6.12.1,lowest,,7.6.2,,new,2010-02-08T04:33:34-0800,2012-09-12T04:14:14-0700,"If you're generating documenatation that links to the base package, you will see that some links to standard types go to the `Prelude` and some to the hierarchical libararies. For example, `Int` goes to `Prelude.Int`, while `Either` goes to `Data.Either.Either`. This happens because the `Prelude` imports some types from the hierarchical libraries, while some are imported directly from internal GHC modules (e.g. `GHC.Base`). In the first case, the hierarchical module is choosen as the best place to link to since it's closer than the `Prelude` in the topological sort to the original module. In the latter case, the hierarchical module and the `Prelude` are of equal number of imports away from the original module, so none is considered a better place to link to. In this case one of the modules is arbitrarily chosen and it happens to be the `Prelude`. I think it would be nice if the links would always go to the hierarchical libraries. Maybe the best way to achieve that would be to add `{-# OPTIONS_HADDOCK NotHome #-}` to the `Prelude`. This flag is not yet documented (I should get around to that). It tells Haddock to prefer linking to another module if one is available.",waern 5,17,Separate warnings for unused local and top-level bindings,Compiler,None,lowest,minor,_|_,,new,2001-10-24T16:56:32-0700,2009-11-20T13:31:57-0800,"{{{ I'd like separate warnings for local and top-level unused binds. I often have ""unused"" top-level functions which I use from ghci. I'd like to avoid warnings for these while retaining the warnings for unused local bindings (which can always be eliminated by prefix the name with an underscore.) }}}",magunter 5,860,CPP fails when a macro is used on a line containing a single quote character,Compiler,6.4.2,lowest,minor,_|_,,new,2006-08-10T03:18:02-0700,2013-01-20T22:36:05-0800,"CPP is nice when you need a quick-and-dirty solution, but one little stumbling block is that macros are not expanded when the line contains a single quote character (as in function names ending in ""prime"" - let x' = MACRO x in...). One solution is of course to break the line between the macro and the quote, but it'd be nice to have a CPP that was just a ''bit'' more clever. -k",ketil@…