- Glasgow-haskell-users

Re: Regression in the typechecker in GHC 7.8.2
by John Wiegley 16 Jun '14

16 Jun '14

>>>>> Simon Peyton Jones <simonpj(a)microsoft.com> writes: > Copying ghc-devs. Oleg says: > | Sorry for reporting a problem via e-mail. It seems track no > | longer accepts anonymous (guest) submissions. When I tried to register > | the account I was told that my submission is a spam. The tracker is > | really well protected. > Can anyone help him? I'll open a ticket. This has been discussed before BTW: http://comments.gmane.org/gmane.comp.lang.haskell.ghc.devel/4239 So it looks like Herbert is the one to contact. John

1 0

AlternateLayoutRule
by John Meacham 10 Jun '14

10 Jun '14

Hi, I noticed that ghc now supports an 'AlternateLayoutRule' but am having trouble finding information about it. Is it based on my proposal and sample implementation? http://www.mail-archive.com/haskell-prime@haskell.org/msg01938.html https://ghc.haskell.org/trac/haskell-prime/wiki/AlternativeLayoutRule implies it has been in use since 6.13. If that is the case, I assume it has been found stable? I ask because I was going to rewrite the jhc lexer and would like to use the new mechanism in a way that is compatible with ghc. If it is already using my code, so much the better. John -- John Meacham - http://notanumber.net/

3 8

Command line options for forcing 98 and 2010 mode
by John Meacham 03 Jun '14

03 Jun '14

Something that would be useful is command line options that will make ghc conform to the standards in one shot. I have various programs that conform to the standards and the onlyrce of incompatibility is the changing options needed to get ghc to compile them. This is analogous to how hugs has the -98 flag and the C standard specifies that 'c99' is an alias to your C compiler that enforces full ISO c99 compatibility. I was thinking providing ghc98 and ghc2010 command aliases, or making an option '--std=haskell98'. another option would be to have -XHaskell98 also modify the package imports in addition to language features, but this may be undesireable as then it would behave differently when specified in a LANGUAGE pragma. John -- John Meacham - http://notanumber.net/

1 0

Data.Type.Equality.== works better when used at kind * -> * -> Bool
by adam vogt 31 May '14

31 May '14

Hello List, Given the following definitions: > class HEq (x :: k) (y :: k) (b :: Bool) | x y -> b > instance ((Proxy x == Proxy y) ~ b) => HEq x y b -- (A) > instance ((x == y) ~ b) => HEq x y b -- (B) The instance (A) lets HList compile, which can be reproduced with: darcs get http://code.haskell.org/~aavogt/HList/ cd HList cabal install -fnew_type_eq When I select instance (B) instead by uncommenting the alternative instance in Data/HList/FakePrelude.hs, one of the more informative type errors suggests that the == type family is getting stuck: Data/HList/Variant.hs:202:29: Warning: Could not deduce (HasField' (l Data.Type.Equality.== l) l (Tagged l (Maybe e) : v) (Maybe e)) arising from a use of ‘mkVariant’ from the context (ConvHList p, SameLength' v v, HMapCxt HMaybeF p v, le ~ Tagged l (Maybe e)) Does this suggest that type (==) should work with all kinds, as it would with: > type a == b = Proxy a `EqStar` Proxy b https://github.com/ghc/packages-base/blob/master/Data/Type/Equality.hs mentions "A poly-kinded instance is /not/ provided, as a recursive definition for algebraic kinds is generally more useful.", but are there instances of (==) that behave differently from the poly-kinded version? Regards, Adam

2 1

GHC 7.8.3 release
by Austin Seipp 31 May '14

31 May '14

Hello all, After a long week, I've finally gotten a little time to reply to emails, and I mainly have one question I'd like to ask. First, please direct your attention to this: https://ghc.haskell.org/trac/ghc/query?status=closed&status=merge&status=pa… This is the 7.8.3 milestone, but it only considers things that are: - 1) Fixed - 2) Going to be merged - 3) Are a patch to be still merged. That is, it is a solid representation of the difference between 7.8.2 and the 7.8 branch tip. The question is: when should we do the release? There are several bugs there that seem quite problematic for users - #9045, #7097, #9001, #8768 and #9078 in particular. If these bugs are really problematic (and I sort of feel they are) then the release can happen soon. I can do it within a week from now, and we could punt more to a 7.8.4 release. I ask this because my time to dedicate to GHC is a bit thin right now, so you must help me decide what's important! So please let me know - just a general vote in favor of doing it within some X timeframe (even 'real soon' or 'a week would be great') would be nice. PS: I apologize for the lack of status updates and brief email - my time for GHC has been in very short order the past two weeks in particular, and I've finally just returned to a computer (not mine) for right now to ask this. PPS: This might also impact the 7.10 schedule, but last Simon and I talked, we thought perhaps shooting for ICFP this time (and actually hitting it) was a good plan. So I'd estimate on that a 7.8.4 might happen a few months from now, after summer. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

10 10

Haskell Platform Update?
by Caitlin 31 May '14

31 May '14

Hi all. I was just wondering if an updated release for the Haskell Platform was planned in the neat future? The current schedule lists November of last year as being the time for release candidates.. Thanks, ~Caitlin

2 1

RFC: changes to -i flag for finding source files
by Simon Marlow 30 May '14

30 May '14

I want to propose a simple change to the -i flag for finding source files. The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, e.g. src/ Graphics/ UI/ Gtk/ Button.hs Label.hs ... where the top few layers are all empty. There have been proposals of elaborate solutions for this in the past (module grafting etc.), but I want to propose something really simple that would avoid this problem with minimal additional complexity: ghc -iGraphics.UI.Gtk=src the meaning of this flag is that when searching for modules, ghc will look for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than src/Graphics/UI/Gtk/Button.hs. The source file itself is unchanged: it still begins with "module Graphics.UI.Gtk.Button ...". The implementation is only a few lines in the Finder (and probably rather more in the manual and testsuite), but I wanted to get a sense of whether people thought this would be a good idea, or if there's a better alternative before I push it. Pros: - simple implementation (but Cabal needs mods, see below) - solves the deep directory problem Cons: - It makes the rules about finding files a bit more complicated. People need to find source files too, not just compilers. - packages that want to be compatible with older compilers can't use it yet. - you can't use '=' in a source directory name (but we could pick a different syntax if necessary) - It won't work for Cabal packages until Cabal is modified to support it (PreProcess and SrcDist and perhaps Haddock are the only places affected, I think) - Hackage will need to reject packages that use this feature without also specifying ghc >= 7.10 and some cabal-version too. - Are there other tools/libraries that will need changes? Leksah? Cheers, Simon

19 37

GHC 7.8.2 bindist for OS X with Xcode 4
by Christiaan Baaij 30 May '14

30 May '14

The Xcode 5 version of GHC 7.8.2, at http://www.haskell.org/ghc/download_ghc_7_8_2#macosx_x86_64, does not work on my machine where I only have Xcode 4 installed. Under the assumption that there are other people out there who also do not (want to) upgrade to Xcode 5, and don't like building GHC from source either, I've created bindists for GHC 7.8.2 that work with Xcode 4: https://www.dropbox.com/s/v6ax3itgjo0imy9/ghc-7.8.2-x86_64-apple-darwin.tar… https://www.dropbox.com/s/d5xpkoiia2tg0e4/ghc-7.8.2-x86_64-apple-darwin.tar… Is there a process through which I could perhaps get them added to: http://www.haskell.org/ghc/download_ghc_7_8_2#macosx_x86_64 ? I see that there are multiple releases for other platforms as well. -- Christiaan

1 0

Asserting that list fusing kicked in
by Joachim Breitner 26 May '14

26 May '14

Hi, for those of you who don’t follow Planet Haskell and haven’t seen my blog post¹ on it: I have created a (very) small library list-fusion-probe with an identity function fuseThis :: [a] -> [a] that will complain loudly (at run-time, for the time being) if the argument is not fused away. Using it might give you more confidence in that your code really fuses as well as you think it does. Greetings from TFP (where the invited talk by Geoffrey Mainland inspired me to write that), Joachim ¹ http://www.joachim-breitner.de/blog/archives/649-Does-list-fusion-work.html -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1

Future of DYNAMIC_GHC_PROGRAMS?
by harry 25 May '14

25 May '14

I need to build GHC 7.8 so that Template Haskell will work without shared libraries (due to a shortage of space). I understand that this can be done by turning off DYNAMIC_GHC_PROGRAMS and associated build options. Is this possibility going to be kept going forward, or will it be deprecated once dynamic GHC is fully supported on all platforms? -- View this message in context: http://haskell.1045720.n5.nabble.com/Future-of-DYNAMIC-GHC-PROGRAMS-tp57497… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

4 5