May 2014 - Glasgow-haskell-users

PROPOSAL: Literate haskell and module file names
by Merijn Verstraaten 23 Aug '14

23 Aug '14

Ola! I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal. Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :) The report only mentions that "by convention" .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors. Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo. I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter. Pros: - Tool authors can more easily determine non-haskell content of literate haskell files - Currently valid module names will not break - Report doesn't specify behaviour, so GHC can do whatever it likes Cons: - Someone has to implement it - ?? Discussion: 4 weeks Cheers, Merijn

10 17

ghc -M
by Christian Maeder 09 Jul '14

09 Jul '14

Hi, using "ghc -M" with ghc-7.8.2 under linux. I got a message: You must specify at least one -dep-suffix (and a failure). http://www.haskell.org/ghc/docs/7.8.1/html/users_guide/separate-compilation… I've stopped using "ghc -M" now, but I think it should be documented better. Maybe dynamic linking complicated matters. Cheers Christian

1 1

AlternateLayoutRule
by John Meacham 11 Jun '14

11 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

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

01 Jun '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 01 Jun '14

01 Jun '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 31 May '14

31 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 27 May '14

27 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