April 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

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

HSghc-prim-0.3.1.0.o: unknown symbol 'memcpy'
by M Farkas-Dyck 10 May '14

10 May '14

I just built stock ghc 7.8.1 against musl on Linux x86_64. I get this: $ ghci GHCi, version 7.8.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... ghc: /lib/ghc-7.8.1/ghc-prim-0.3.1.0/HSghc-prim-0.3.1.0.o: unknown symbol `memcpy' ghc: unable to load package `ghc-prim' $ memcpy is defined in /lib/libc.a; how can I link it in? I tried -lc and -opt-lc options to ghci, in vain.

2 4

GHC rewrite rules and constructor wrappers?
by Conal Elliott 06 May '14

06 May '14

I'm trying to sort out the relationship of GHC rewrite rules and constructor wrappers. I have rules like > "reify/(:<)" reifyEP (:<) = kPrim VecSP This rule seems to fire for `reifyEP ($W:<)` rather than `reifyEP (:<)`. If I'm tracking (uncertain), `($W:<)` inlines to `(:<)`. Sometimes I'm able to preserve the `$W` form, but sometimes I get the bare form when inlining a definition from another already-compiled module. In those cases, I don't know how to get my rules to fire. Advice and explanation appreciated, including pointers explanations of the role of these wrappers in GHC. -- Conal

2 1

RFC: include a cabal-install executable in future GHC releases
by Carter Schonwald 04 May '14

04 May '14

Hey everyone, I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install (aka cabal) executable, but not include the library deps of cabal-install that aren't already distributed with ghc.(unless ghc should have those deps baked in, which theres very very good reasons not to do.). currently if someone wants just a basic haskell install of the freshest ghc they have to install a ghc bindist, then do a boostrap build of cabal-install by hand (if they want to actually get anything done :) ). This is not a human friendly situation for folks who are new to haskell tooling, but want to try out haskell dev on a server style vm or the like! point being: It'd be great for haskell usability (and egads amounts of config time, even by seasoned users) the ghc bindists / installers included a cabal-install binary thoughts? -Carter

15 32

Removing -fext-core
by Austin Seipp 30 Apr '14

30 Apr '14

Hello all, Recently I was wondering something: is there any reason to keep -fext-core around? In particular, it's been broken for a while at this point, see GHC bug #5630[1] As far as I'm aware there really aren't any users of it still around these days, at least none working with a modern GHC. And it seems like if people were to need access to Core, they could use a plugin or some such to get direct access to what they want. Simon mentioned removing ExtCore in face of replacing it with IfaceSyn in the compiler. I'm not entirely sure how much work that would be to bring it all up to scratch if people needed it, but maybe it's worth thinking about. One other issue is a notion of semantics which is present in External Core, but we also now have a documented semantics for GHC's core language as well (which has evolved quite a bit), so I don't know how much that matters. So long story short: I don't think anyone is using it, maintaining it, and it seems subsumed by more recent events. Therefore, if nobody objects, I'd vote to remove -fext-core from GHC, unless someone is willing to step up and really maintain it. If you're using it, you should probably speak up soon I'd imagine... [1] https://ghc.haskell.org/trac/ghc/ticket/5630 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 4

how to compile non-dynamic ghc-7.8.2 ?
by John Lato 30 Apr '14

30 Apr '14

Hello, I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled (on 64-bit linux). I downloaded the source tarball, added DYNAMIC_GHC_PROGRAMS = NO to mk/build.mk, and did ./configure && ./make. ghc builds and everything seems to work (cabal installed a bunch of packages, ghci seems to work), however whenever I try to run Setup.hs dynamically (either 'runghc Setup.hs configure' or loading it with ghci and executing 'main') it dumps core. Compiling Setup.hs works, and nothing else has caused ghci to crash either (this email is a literate haskell file equivalent to Setup.hs). Building with DYNAMIC_GHC_PROGRAMS = YES works properly. With that in mind, I have a few questions: How should I compile a non-dynamic ghc? Is this a bug in ghc? Thanks, John L. * Setup.hs > import Distribution.Simple > main = defaultMain

6 9

Re: [core libraries] Re: Tightening up on inferred type signatures
by Ganesh Sittampalam 30 Apr '14

30 Apr '14

On 23/04/2014 20:04, dm-list-haskell-libraries(a)scs.stanford.edu wrote: > Edward Kmett <ekmett(a)gmail.com> writes: > >> You can wind up in perfectly legitimate situations where the name for the >> type you are working with isn't in scope, but where you can write a >> combinator that would infer to have that type. I'd hate to lose that. >> >> It is admittedly of marginal utility at first glance, but there are some >> tricks that actually need it, and it can also arise if a type synonym >> expands to a type that isn't exported or brought into scope, so trying to >> push this line of reasoning too far I is possibly not too productive. > > Good point. In particular, it's not weird at all want to export type > synonyms on their own, particularly where ghost type parameters are used > to select between only a few cases. Consider something like this > (inspired by postgresql-orm): Is there an abstraction being protected by only exporting the type synonym in cases like this? Cheers, Ganesh

2 2

Fwd: Type/type class information in GHC plugin
by Shen Chen Xu 27 Apr '14

27 Apr '14

Hello everyone, I would like to write a GHC plugin which adds wrapper to functions. Say I have a function addWrapper :: Ord a => (a -> b) -> a -> b which is supposed to transform (assuming the argument is in the Ord class) foo = \ x -> ... into foo = addWrapper (\ x -> ...) This works fine if I'm only interested in wrapping functions of type Int -> Int, in which case I make addWrapper to also have type addWrapper :: (Int -> Int) -> Int -> Int and use mkCoreApp to apply addWrapper to the right hand side. However, if I want it to be polymorphic as described above, the transformed GHC Core for an Int -> Int function should look like foo = addHook @ GHC.Types.Int @ GHC.Types.Int GHC.Classes.$fOrdInt (\ x -> ...) My question is, given the right hand side of foo, how do I construct the type/type class information inside Core shown above? Cheers, Shen

2 1