- Glasgow-haskell-users

renamed GMP symbols in GHC
by Michal Konečný 10 Jan '12

10 Jan '12

Dear all, Several issues related to the way GMP is included in GHC were publicly discussed in the past with the goal of replacing GMP. As summarised in this wiki by Peter Tanski, the main issues were: (1) Licensing (2) Memory Structure; Simultaneous Access to GMP by Foreign (C) code in the Same Binary. My immediate concern is (2) as I develop programs that link with MPFR, which uses GMP. So far I got around the issue by compiling GHC with integer-simple. This is fine for me but I feel the need to recompile ghc may be hindering some people who would like to try my software that links with MPFR. I have therefore been looking for a way to overcome (2) that could make it to the default build of GHC. As suggested by Simon PJ in this email, a simple way to deal with issue (2) is to "*copy* GMP, changing all the function names". I recently found some time and had a go at implementing this suggestion and it turned out to be quite easy. I described my recipe to do such a "copy" here but currently I have been able to test it only on x86 Linux and GHC 7.2.1. I checked that the renaming makes a difference by running all QuickCheck tests of my AERN-Real-MPFR package. Some of these tests persistently fail when compiled with a standard GHC. All tests succeed with GHC/integer-simple and also with GHC 7.2.1 using the renamed GMP. I was wondering whether such a change (more polished and tested on all common platforms) could make it to the future official GHC releases. If the GHC developers would support this change, I would be happy to put more work into it. I think the following concrete changes would be required in the GHC distribution: (a) make a ghc build always use the bundled GMP (b) apply a renaming script onto the GMP tar before adding it to the GHC source bundle (c) rename symbols analogously in integer-gmp/cbits/* An alternative to (b) is to apply the renaming to the GMP sources just before building it. One thing I am not clear about is the impact such a change would have on lincensing. My understanding is that GHC sources include GMP sources and in the absence of an installed GMP library, they are statically linked into the integer-gmp package. (Does it mean that the integer-gmp package should be LGPL lincensed?) The suggested changes would mean that this kind of linking would happen always, not only when no other GMP library is available on the system. In either case, it seems to me that using integer-gmp as a shared library would still be OK for producing non-LGPL code. I would be grateful for your views and guidance. Best regards, Michal -- |o| Michal Konecny <mikkonecny(a)gmail.com> |o| http://www-users.aston.ac.uk/~konecnym/ |o| office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston

9 20

GHC 7.0.4 recursion while trying to derive type
by Bogdan Opanchuk 10 Jan '12

10 Jan '12

Hello, Consider the following code: {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, OverlappingInstances, UndecidableInstances, FunctionalDependencies #-} class Container a b | a -> b where make :: b -> a data Cont a = Cont a deriving (Show, Eq) instance Container (Cont a) a where make x = Cont x -- Part A instance (Container a b, Show a, Eq a, Num b) => Num a where fromInteger x = make (fromInteger x) d = fromInteger 3 :: Cont Integer -- Part B class Convertable a where fromInt :: Integer -> a instance Convertable Integer where fromInt = id instance (Container a b, Convertable b) => Convertable a where fromInt x = make (fromInt x) e = fromInt 3 :: Cont Integer main = do print d print e Part A and B are basically the same, the only difference being that A uses existing Num typeclass, and B creates a new one. The problem is that it compiles and works in GHC 7.2.2, but in 7.0.4 (which is the one included in the most recent Haskell Platform, that's why I bumped into this issue) part A generates the following error: t4.hs:17:31: Context reduction stack overflow; size = 21 Use -fcontext-stack=N to increase stack size to N $dNum :: Num b19 [ skipped ] $dNum :: Num b0 In the first argument of `make', namely `(fromInteger x)' In the expression: make (fromInteger x) In an equation for `fromInteger': fromInteger x = make (fromInteger x) My understanding is that in line "fromInteger x = make (fromInteger x)" compiler should take into account that 1) the signature for make is "make :: b -> a" 2) type b is known at the moment of creating instance (because a == Cont Integer, which is an instance of Container (Cont Integer) Integer). and cast "fromInteger x" to type b and pass it to make. In 7.0.4 part B (which is based on the same idea) works correctly, so it may have something to do with how fromInteger is defined in GHC guts. So, the question is, could anyone please tell me, is what I am trying to do actually correct, and what was changed from 7.0.4 to 7.2.2 to make it work? Thank you in advance. Best regards, Bogdan

3 5

ConstraintKinds and default associated empty constraints
by Bas van Dijk 09 Jan '12

09 Jan '12

I'm playing a bit with the new ConstraintKinds feature in GHC 7.4.1-rc1. I'm trying to give the Functor class an associated constraint so that we can make Set an instance of Functor. The following code works but I wonder if the trick with: class Empty a; instance Empty a, is the recommended way to do this: {-# LANGUAGE ConstraintKinds, TypeFamilies, FlexibleInstances #-} import GHC.Prim (Constraint) import Prelude hiding (Functor, fmap) import Data.Set (Set) import qualified Data.Set as S (map, fromList) class Functor f where type C f :: * -> Constraint type C f = Empty fmap :: (C f a, C f b) => (a -> b) -> f a -> f b class Empty a; instance Empty a instance Functor Set where type C Set = Ord fmap = S.map instance Functor [] where fmap = map testList = fmap (+1) [1,2,3] testSet = fmap (+1) (S.fromList [1,2,3]) Cheers and thanks for a great new feature! Bas

9 22

Test suite quality
by Joachim Breitner 09 Jan '12

09 Jan '12

Dear GHC-Team, to improve the quality of Haskell on Debian started to package the GHC testsuite in a package of its own, and will upload it to Debian so that it runs on all architectures and catches possible architecture-dependent bugs there. Using the released testsuite for 7.0.4 with that version of the compiler, and running it with SKIPWAY="optc profc optllvm" fast=YES I get this result: OVERALL SUMMARY for test run started at Sa 7. Jan 17:45:54 CET 2012 2612 total tests, which gave rise to 10986 test cases, of which 0 caused framework failures 8642 were skipped 2267 expected passes 59 expected failures 0 unexpected passes 18 unexpected failures Unexpected failures: 3586(normal) Chan001(normal) MVar001(normal) QSem001(normal) QSemN001(normal) SampleVar001(normal) T1969(normal) T3064(normal) T3087(normal) T3294(normal) T4316(ghci) T4801(normal) cgrun025(normal) driver027(normal) driver028(normal) ghci014(ghci) ghcpkg05(normal) regex003(normal) Is that normal to find unexpected failures of the release testsuite on a “normal” system? Would it be reasonable to have the released testsuite, at least in fast mode, complete without unexpected failures so that I can be sure that any unexpected failure implies some problem in the compiler? Should I file bug reports about unexpected failures found in the latest testsuite, once I get around to package and run that? And a minor request, in case someone feels like touching the test driver: It would be nice if the summary lists all library packages that are not installed but required by some test, i.e. the libraries that ought to be added to the Build-Dependency of the test suite to get a more complete coverage. I could not attach the build log, as it is too large, but you can find it here: http://people.debian.org/~nomeata/ghc-testsuite_7.0.4-1_amd64.build.gz Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

2 1

7.4.1-pre: Show & Integral
by Serge D. Mechveliani 09 Jan '12

09 Jan '12

пDear GHC team, ghc-7.0.1 assumes that Integral includes Show, and ghc-7.4.0.20111219 does not assume this. Which one agrees with Haskell-2010 ? Regards, ------ Sergei mechvel(a)botik.ru

5 4

Re: Records in Haskell
by Gábor Lehel 08 Jan '12

08 Jan '12

2012/1/8 Greg Weber <greg(a)gregweber.info>: > > > 2012/1/8 Gábor Lehel <illissius(a)gmail.com> >> >> Thank you. I have a few questions/comments. >> >> >> >> "The module/record ambiguity is dealt with in Frege by preferring >> modules and requiring a module prefix for the record if there is >> ambiguity." >> >> I think I see why they do it this way (otherwise you can't refer to a >> module if a record by the same name is in scope), but on the other >> hand it would seem intuitive to me to choose the more specific thing, >> and a record feels more specific than a module. Maybe you could go >> that way and just not give your qualified imports the same name as a >> record? (Unqualified imports are in practice going to be hierarchical, >> and no one's in the habit of typing those out to disambiguate things, >> so I don't think it really matters if qualified records shadow them.) > > > In the case where a Record has the same name as its containing module it > would be more specific than a module, and preferring it makes sense. I think > doing this inside the module makes sense, as one shouldn't need to refer to > the containing module's name. We should think more about the case where > module & records are imported. > >> >> >> "Expressions of the form x.n: first infer the type of x. If this is >> just an unbound type variable (i.e. the type is unknown yet), then >> check if n is an overloaded name (i.e. a class operation). [...] Under >> no circumstances, however, will the notation x.n contribute in any way >> in inferring the type of x, except for the case when n is a class >> operation, where an appropriate class constraint is generated." >> >> Is this just a simple translation from x.n to n x? What's the >> rationale for allowing the x.n syntax for, in addition to record >> fields, class methods specifically, but no other functions? > > > It is a simple translation from x.n to T.n x > The key point being the function is only accessible through the record's > namespace. > The dot is only being used to tap into a namespace, and is not available for > general function application. I think my question and your answer are walking past each other here. Let me rephrase. The wiki page implies that in addition to using the dot to tap into a namespace, you can also use it for general function application in the specific case where the function is a class method ("appropriate class constraint is generated" etc etc). I don't understand why. Or am I misunderstanding? > >> >> >> >> Later on you write that the names of record fields are only accessible >> from the record's namespace and via record syntax, but not from the >> global scope. For Haskell I think it would make sense to reverse this >> decision. On the one hand, it would keep backwards compatibility; on >> the other hand, Haskell code is already written to avoid name clashes >> between record fields, so it wouldn't introduce new problems. Large >> gain, little pain. You could use the global-namespace function as you >> do now, at the risk of ambiguity, or you could use the new record >> syntax and avoid it. (If you were to also allow x.n syntax for >> arbitrary functions, this could lead to ambiguity again... you could >> solve it by preferring a record field belonging to the inferred type >> over a function if both are available, but (at least in my current >> state of ignorance) I would prefer to just not allow x.n for anything >> other than record fields.) > > > Perhaps you can give some example code for what you have in mind - we do > need to figure out the preferred technique for interacting with old-style > records. Keep in mind that for new records the entire point is that they > must be name-spaced. A module could certainly export top-level functions > equivalent to how records work now (we could have a helper that generates > those functions). Let's say you have a record. data Record = Record { field :: String } In existing Haskell, you refer to the accessor function as 'field' and to the contents of the field as 'field r', where 'r' is a value of type Record. With your proposal, you refer to the accessor function as 'Record.field' and to the contents of the field as either 'Record.field r' or 'r.field'. The point is that I see no conflict or drawback in allowing all of these at the same time. Writing 'field' or 'field r' would work exactly as it already does, and be ambiguous if there is more than one record field with the same name in scope. In practice, existing code is already written to avoid this ambiguity so it would continue to work. Or you could write 'Record.field r' or 'r.field', which would work as the proposal describes and remove the ambiguity, and work even in the presence of multiple record fields with the same name in scope. The point is that I see what you gain by allowing record fields to be referred to in a namespaced way, but I don't see what you gain by not allowing them to be referred to in a non-namespaced way. In theory you wouldn't care because the non-namespaced way is inferior anyways, but in practice because all existing Haskell code does it that way, it's significant. > >> >> >> >> Later on: >> >> "- the function that updates field x of data type T is T.{x=} >> - the function that sets field x in a T to 42 is T.{x=42} >> - If a::T then a.{x=} and a.{x=42} are valid" >> >> I think this looks considerably ugly. Aren't there better >> alternatives? { T.x = }, { T.x = 42 }, { a.x = }, { a.x = 42 } maybe? >> (Does this conflict in some unfinesseable way with explicit layout >> contexts?) > > > I think this is one of those slightly different syntaxes that many people > will have an initial bad reaction to, however once they use it they will > like it just fine. The problem with what you are suggesting is that it would > be verbose when updating multiple fields at once. But we should investigate > if it is possible to have a syntax closer to the existing update syntax. Good point. > >> >> >> "the function that changes field x of a T by applying some function to >> it is T.{x <-}" >> >> Same comment on syntax applies. I believe this is a new feature? It >> would be welcome, albeit the overloading of <- is a bit worrisome >> (don't have better ideas at the moment, but I think there was a >> thread). I assume T.{x <- f}, a.{x <-}, and a.{x <- f} (whatever the >> syntax is) would also be valid, by analogy to the above? > > > Yes, new feature, so not necessary in the initial implementation. I > personally think Haskell should drop the monadic curly brackets which nobody > uses, but whatever syntax works is fine with me. > >> >> >> >> >> Re: Compatibility with existing records: based on (very) cursory >> inspection I don't see an obstacle to making it (near-)fully >> compatible - you would just be adding some new syntax, most >> significantly x.n. Backwards compatibility is a great advantage, so >> why not? >> >> >> >> Generalizing the syntax to arbitrary TDNR: I think I'm opposed to >> this. The problem is that in existing Haskell the vast majority of >> expressions (with the notable (and imho unfortunate) exception of >> (>>=)) flow from right to left. Going the other way with record fields >> isn't a big problem because it's simple and doesn't even feel like >> function application so much as member-selection (like modules), but >> if you were to allow any function you would soon end up with lengthy >> chains of them which would clash nastily with the surrounding code. >> Having to jump back and forth and switch directions while reading is >> unpleasant. OO languages have this problem and I don't envy them for >> it. And in particular having "a . b" mean "first do b, then do a", but >> "a.b" mean "do b to a" would be confusing. (You'd already have this >> problem with global namespace record field selectors, but at least >> it's localized.) > > > I agree - I think a.b or A.b should always mean tapping into a namespace and > not be generalized outside of that. > >> >> All of that said, maybe having TDNR with bad syntax is preferable to >> not having TDNR at all. Can't it be extended to the existing syntax >> (of function application)? Or least some better one, which is ideally >> right-to-left? I don't really know the technical details... >> >> Generalized data-namespaces: Also think I'm opposed. This would import >> the problem from OO languages where functions written by the module >> (class) author get to have a distinguished syntax (be inside the >> namespace) over functions by anyone else (which don't). > > > Maybe you can show some example code? To me this is about controlling > exports of namespaces, which is already possible - I think this is mostly a > matter of convenience. If I'm understanding correctly, you're suggesting we be able to write: data Data = Data Int where twice (Data d) = 2 * d thrice (Data d) = 3 * d ... and that if we write 'let x = Data 7 in x.thrice' it would evaluate to 21. I have two objections. The first is the same as with the TDNR proposal: you would have both code that looks like 'data.firstFunction.secondFunction.thirdFunction', as well as the existing 'thirdFunction $ secondFunction $ firstFunction data' and 'thirdFunction . secondFunction . firstFunction $ data', and if you have both of them in the same expression (which you will) it becomes unpleasant to read because you have to read them in opposite directions. The second is that only the author of the datatype could put functions into its namespace; the 'data.foo' notation would only be available for functions written by the datatype's author, while for every other function you would have to use 'foo data'. I dislike this special treatment in OO languages and I dislike it here. > > >> >> >> >> >> Another thing that would be nice is lenses to solve the >> nested-record-update problem - at least the room to add them later. >> Most of the proposed syntax would be unaffected, but you'd need some >> syntax for the lens itself... I'm not sure what it might be. Would it >> be terrible to have T.x refer to a lens rather than a getter? (I don't >> know how you'd refer to the getter then, so probably yeah.) Or maybe { >> T.x }, building backwards from { T.x = }? >> >> >> >> Another existing language very similar to Haskell whose record system >> might be worth evaluating is Disciple: http://disciple.ouroborus.net/. >> Unfortunately I couldn't find any specific page it seemed best to link >> to. > > > The syntax of DDC seems the same as this proposal. However, I could not find > any specific information either. The main things I remember being interesting about it are that it's based on lenses, and uses some kind of extensible projectors system to allow something similar to what you achieve with datatype-namespaces, namely 'virtual' record fields. But I haven't studied it in detail. > >> >> >> On Sun, Jan 8, 2012 at 2:40 AM, Greg Weber <greg(a)gregweber.info> wrote: >> > I have updated the wiki - the entry level page [1] compares the >> > different >> > proposals and points to a more fleshed out explanation of the Frege >> > proposal >> > [2]. >> > >> > I think I now understand the differences between the existing proposals >> > and >> > am able to provide leadership to move this forward. Let me summarize the >> > state of things: >> > There is a debate over extensible records that we are putting off into >> > the >> > future. Instead we have 2 proposals to make things better right now: >> > * an overloaded record fields proposal that still has implementation >> > concerns >> > * a name-spacing & simple type resolution proposal that is awaiting your >> > critique >> > >> > The Frege language originally had overloaded record fields but then >> > moved to >> > the latter system. The existing experience of the Frege language is very >> > fortunate for us as we now have some experience to help inform our own >> > decision. >> > >> > Greg Weber >> > >> > [1] http://hackage.haskell.org/trac/ghc/wiki/Records >> > [2] http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing >> > >> > >> > On Wed, Jan 4, 2012 at 7:54 AM, Greg Weber <greg(a)gregweber.info> wrote: >> >> >> >> The Frege author does not have a ghc mail list account but gave a more >> >> detailed explanation of how he goes about TDNR for records and how >> >> often it >> >> type checks without annotation in practice. >> >> >> >> A more general explanation is here: >> >> >> >> >> >> http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leader… >> >> >> >> He sent a specific response to Simon's mail list message, quoted below: >> >> >> >> Simon Peyton-Jones is absolutely correct when he notes: >> >> >> >> Well the most obvious issue is this. 3.2 says e.m = (T.m e) if the >> >> expression e has type t and the type constructor of t is T and there >> >> exists >> >> a function T.m But that innocent-looking statement begs the *entire* >> >> question! How do we know if "e has type t? >> >> >> >> The way it is done in Frege is such that, if you have a function that >> >> uses >> >> or updates (nondestructively, of course) a "record" then at least the >> >> type >> >> constructor of that record has to be known. This is no different than >> >> doing >> >> it explicitly with case constructs, etc., just here you learn the types >> >> from >> >> the constructors you write in the patterns. >> >> >> >> Hence, it is not so that one can write a function that updates field f >> >> to >> >> 42 for any record that contains a field f: >> >> >> >> foo x = x.{f=42} -- type annotation required for foo or x >> >> >> >> In practice this means you'll have to write a type annotation here and >> >> there. >> >> Often, the field access is not the only one that happens to some >> >> variable >> >> of record type, or the record is the result of another function >> >> application. >> >> In such cases, the type is known. >> >> I estimate that in 2/3 of all cases one does not need to write (T.e x) >> >> in >> >> sparsely type annotated code, despite the fact that the frege type >> >> checker >> >> has a left to right bias and does not yet attempt to find the type of x >> >> in >> >> the code that "follows" the x.e construct (after let unrolling etc.) >> >> I think one could do better and guarantee that, if the type of x is >> >> inferrable at all, then so will be x.e (Still, it must be more than >> >> just a >> >> type variable.) >> >> >> >> On Sun, Jan 1, 2012 at 2:39 PM, Greg Weber <greg(a)gregweber.info> wrote: >> >>> >> >>> >> >>> >> >>> On Sat, Dec 31, 2011 at 3:28 PM, Simon Peyton-Jones >> >>> <simonpj(a)microsoft.com> wrote: >> >>>> >> >>>> Frege has a detailed explanation of the semantics of its record >> >>>> implementation, and the language is *very* similar to Haskell. Lets >> >>>> just >> >>>> start by using Frege's document as the proposal. We can start a new >> >>>> wiki >> >>>> page as discussions are needed. >> >>>> >> >>>> >> >>>> >> >>>> If it’s a serious proposal, it needs a page to specify the design. >> >>>> Currently all we have is a paragraph on >> >>>> http://hackage.haskell.org/trac/ghc/wiki/Records, under “Better name >> >>>> spacing”. >> >>>> >> >>>> >> >>>> >> >>>> As previously stated on this thread, the Frege user manual is >> >>>> available >> >>>> here: >> >>>> >> >>>> http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf >> >>>> >> >>>> see Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type >> >>>> Declaration - Constructors with labeled fields) >> >>>> >> >>>> >> >>>> >> >>>> To all those concerned about Records: look at the Frege >> >>>> implementation >> >>>> and poke holes in it. >> >>>> >> >>>> >> >>>> >> >>>> Well the most obvious issue is this. 3.2 says >> >>>> >> >>>> e.m = (T.m e) if the expression e has type t and the type constructor >> >>>> >> >>>> of t is T and there exists a function T.m >> >>>> >> >>>> But that innocent-looking statement begs the *entire* question! How >> >>>> do >> >>>> we know if “e has type t? This is the route ML takes for arithmetic >> >>>> operators: + means integer plus if the argument is of type Int, float >> >>>> plus >> >>>> if the argument is of type Float, and so on. >> >>>> >> >>>> >> >>>> >> >>>> Haskell type classes were specifically designed to address this >> >>>> situation. And if you apply type classes to the record situation, I >> >>>> think >> >>>> you end up with >> >>>> >> >>>> >> >>>> http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields >> >>> >> >>> >> >>> More specifically I think of this as TDNR, which instead of the focus >> >>> of >> >>> the wiki page of maintaining backwards compatibility and de-surgaring >> >>> to >> >>> polymorphic constraints. I had hoped that there were different ideas >> >>> or at >> >>> least more flexibility possible for the TDNR implementation. >> >>> >> >>>> >> >>>> >> >>>> >> >>>> Well, so maybe we can give up on that. Imagine Frege without the >> >>>> above >> >>>> abbreviation. The basic idea is that field names are rendered unique >> >>>> by >> >>>> pre-pending the module name. As I understand it, to record selection >> >>>> one >> >>>> would then be forced to write (T.m e), to select the ‘m’ field. That >> >>>> is >> >>>> the, qualification with T is compulsory. The trouble with this is >> >>>> that >> >>>> it’s *already* possible; simply define suitably named fields >> >>>> >> >>>> data T = MkE { t_m :: Int, t_n :: Bool } >> >>>> >> >>>> Here I have prefixed with a (lower case version of) the type name. >> >>>> So >> >>>> we don’t seem to be much further ahead. >> >>>> >> >>>> >> >>>> >> >>>> Maybe one could make it optional if there is no ambiguity, much like >> >>>> Haskell’s existing qualified names. But there is considerable >> >>>> ambiguity >> >>>> about whether T.m means >> >>>> >> >>>> m imported from module T >> >>>> >> >>>> or >> >>>> >> >>>> the m record selector of data type T >> >>> >> >>> >> >>> If there is ambiguity, we expect the T to be a module. So you would >> >>> need >> >>> to refer to Record T's module: OtherModule.T.n or T.T.n >> >>> Alternatively these conflicts could be compilation errors. >> >>> Either way programmers are expected to structure their programs to >> >>> avoid >> >>> conflicting names, no different then they do now. >> >>> >> >>>> >> >>>> >> >>>> Perhaps one could make it work out. But before we can talk about it >> >>>> we >> >>>> need to see a design. Which takes us back to the question of >> >>>> leadership. >> >>>> >> >>>> >> >>> >> >>> I am trying to provide as much leadership on this issue as I am >> >>> capable >> >>> of. Your critique is very useful in that effort. >> >>> >> >>> At this point the Frege proposal without TDNR seems to be a small step >> >>> forward. We can now define records with clashing fields in the same >> >>> module. >> >>> However, without TDNR we don't have convenient access to those fields. >> >>> I am contacting the Frege author to see if we can get any more >> >>> insights >> >>> on implementation details. >> >>> >> >>>> >> >>>> Simon >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> We only want critiques about >> >>>> >> >>>> * achieving name-spacing right now >> >>>> >> >>>> * implementing it in such a way that extensible records could be >> >>>> implemented in its place in the future, although we will not allow >> >>>> that >> >>>> discussion to hold up a records implementation now, just possibly >> >>>> modify >> >>>> things slightly. >> >>>> >> >>>> >> >>>> >> >>>> Greg Weber >> >>>> >> >>>> >> >>>> >> >>>> On Thu, Dec 29, 2011 at 2:00 PM, Simon Peyton-Jones >> >>>> <simonpj(a)microsoft.com> wrote: >> >>>> >> >>>> | The lack of response, I believe, is just a lack of anyone who >> >>>> | can cut through all the noise and come up with some >> >>>> | practical way to move forward in one of the many possible >> >>>> | directions. >> >>>> >> >>>> You're right. But it is very telling that the vast majority of >> >>>> responses on >> >>>> >> >>>> >> >>>> http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leader… >> >>>> were not about the subject (leadership) but rather on suggesting yet >> >>>> more, incompletely-specified solutions to the original problem. My >> >>>> modest >> >>>> attempt to build a consensus by articulating the simplest solution I >> >>>> could >> >>>> think of, manifestly failed. >> >>>> >> >>>> The trouble is that I just don't have the bandwidth (or, if I'm >> >>>> honest, >> >>>> the motivation) to drive this through to a conclusion. And if no one >> >>>> else >> >>>> does either, perhaps it isn't *that* important to anyone. That said, >> >>>> it >> >>>> clearly is *somewhat* important to a lot of people, so doing nothing >> >>>> isn't >> >>>> very satisfactory either. >> >>>> >> >>>> Usually I feel I know how to move forward, but here I don't. >> >>>> >> >>>> Simon >> >>>> >> >>>> >> >>> >> >>> >> >> >> > >> > >> > _______________________________________________ >> > Glasgow-haskell-users mailing list >> > Glasgow-haskell-users(a)haskell.org >> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > >> >> >> >> -- >> Work is punishment for failing to procrastinate effectively. > > -- Work is punishment for failing to procrastinate effectively.

4 7

Finding the type of a hole
by Sean Leather 05 Jan '12

05 Jan '12

We're currently looking into so-called expression holes in GHC -- like the type goals of Agda -- and we've run into a problem of understanding. We have defined an expression, call it __ for now, for which we want to find the type after a program is type-checked. In tcExpr (TcExpr.lhs), we can see the type that arrives in the argument res_ty, but that does not appear to give the correct (or final?) type after applying zonkTcType. For example, if we have (__, __), then we find that both holes have some type "t" (as printed). We also see this in a module with declarations such as f = __ and g = __. When these are actually typed, they get unique type variables as expected. So, apparently, we're missing something in trying to find the proper type of a hole. Any suggestions on what we should do or look at? Note that we're currently working from 7.2.2, because we could not previously build HEAD. Thanks, Sean

2 1

filename corruption with -osuf in ghc-7.0.3
by Evan Laforge 04 Jan '12

04 Jan '12

I've noticed a strange behaviour with ghc's -osuf flag: % cat >Test.hs {-# LANGUAGE ForeignFunctionInterface #-} module Test where import Foreign foreign import ccall "wrapper" c_callback :: Int -> IO (FunPtr Int) % ghc-7.0.3 -v -c -osuf .hs.o Test.hs % ls Tes_stub.hs.o Test.hs Test_stub.c Test.hi Test.hs.o Test_stub.h Notice that the .o for the _stub.c has acquired the .hs.o suffix, but the last 't' of 'Test' was chopped off. I tried the same test with the latest ghc-7.4, and it doesn't generate a Test_stub.c at all, though there is a Test_stub.h. But I guess it sidesteps the question of whether -osuf should apply to the _stub.c (I feel like it shouldn't, since it's a c file compiled by cc, not by ghc). I'm curious about why ghc no longer seems to need _stub.c files. I'd test in more details, but runghc ghci for 7.4 is segfaulting unpredictably so I think there are larger problems here.

2 2

GHC compilation issue: How to work around bug #4374?
by Sanket Agrawal 03 Jan '12

03 Jan '12

I sent this question to Haskell Cafe list instead of this mailing list. So, my apologies for cross-posting. I have emailed a note to Haskell Cafe about this cross-posting. This mailing list seems more focused on GHC issues. I am getting the compilation error below during linking when building GHC 7.0.4 on RHEL5 (x86_64) using GHC 6.12.3 as the building compiler – I configured "make" to point to ncurses and libgmp installations. The issue seems to happen at the last stage of make - so close to getting GHC to build. I will appreciate pointers on how to work around the issue below. I don’t have root privileges on Linux box (otherwise I would have used justhub.org packages instead of going through this painful process). My apologies if this has already been discussed in this forum. I searched for the issue but could find only the GHC bug ticket below.**** ** ** GHC bug ticket: http://hackage.haskell.org/trac/ghc/ticket/4374 - it doesn’t have description on how to work around the bug.**** ** ** Compilation error:**** -----------------------**** ** ** $ C_INCLUDE_PATH=/efs/dist/fsf/ncurses/5.6/common/include/ncurses:/home/saagrawa/scripts/misc/libgmp/include LIBRARY_PATH=/efs/dist/fsf/ncurses/5.6/exec/lib:/home/saagrawa/scripts/misc/libgmp/lib make**** ===--- updating makefiles phase 0**** make -r --no-print-directory -f ghc.mk phase=0 just-makefiles**** ===--- updating makefiles phase 1**** make -r --no-print-directory -f ghc.mk phase=1 just-makefiles**** ===--- updating makefiles phase 2**** make -r --no-print-directory -f ghc.mk phase=2 just-makefiles**** ===--- updating makefiles phase 3**** make -r --no-print-directory -f ghc.mk phase=3 just-makefiles**** ===--- finished updating makefiles**** make -r --no-print-directory -f ghc.mk all**** "inplace/bin/ghc-stage1" libraries/integer-gmp/dist-install/build/GHC/Integer.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Type.dyn_o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o libraries/integer-gmp/dist-install/build/cbits/cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o `/usr/bin/find libraries/integer-gmp/dist-install/build -name "*_stub.dyn_o" -print` -shared -dynamic -dynload deploy -dylib-install-name /home/saagrawa/scripts/misc/ghc/7.0.4/lib/ghc-7.0.4/`basename "libraries/integer-gmp/dist-install/build/ libHSinteger-gmp-0.2.0.3-ghc7.0.4.so" | sed 's/^libHS//;s/[-]ghc.*//'`/`basename "libraries/integer-gmp/dist-install/build/ libHSinteger-gmp-0.2.0.3-ghc7.0.4.so"` -no-auto-link-packages -package ghc-prim-0.2.0.0 -o libraries/integer-gmp/dist-install/build/ libHSinteger-gmp-0.2.0.3-ghc7.0.4.so**** /efs/dist/fsf/gcc/4.4.3-build004/.exec/x86-64.rhel.5/libexec/gcc/x86_64-unknown-linux-gnu/4.4.3/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation R_X86_64_32 against `__gmpz_sub' can not be used when making a shared object; recompile with -fPIC**** libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value**** collect2: ld returned 1 exit status**** make[1]: *** [libraries/integer-gmp/dist-install/build/ libHSinteger-gmp-0.2.0.3-ghc7.0.4.so] Error 1**** make: *** [all] Error 2**** ** ** ** ** $ ls -ltr /home/saagrawa/scripts/misc/libgmp/lib|awk '{print $9,$10,$11}' ### verifying that the libgmp lib folder has dynamic libraries** ** ** libgmp.so.3.5.2***** libgmp.so.3 -> libgmp.so.3.5.2***** libgmp.so -> libgmp.so.3.5.2***** libgmp.la***** libgmp.a

1 0

testing 7.4.1-candidate
by Serge D. Mechveliani 02 Jan '12

02 Jan '12

Dear GHC team, I have tested ghc-7.4.0.20111219 on Debian Linux by 1) making it from source, 2) making it by itself, 3) making DoCon-2.12 and running its test. It looks all right. In installing DoCon, there appears a new point of installing the package Random, because Random has separated from GHC. So, I write in the DoCon-2.12 announce: ********************************************************** Used extra libraries (beyond Haskell-2010) -------------------- Set.Set, Map.Map -- of GHC, System.Random version 1.0.1.1 -- a separate from GHC library (written in Haskell) residing on http://hackage.haskell.org/package/random (first, install GHC, then use ghc to install Random). ********************************************************** Thanks to people who helped me with installing Random. I have downloaded System.Random-1.0.1.1 from http://hackage.haskell.org/package/random, unzipped it to a separate from ghc place -- call it $R, and installed it to a $R/inst by ghc --make Setup ./Setup configure --prefix=$R/inst -p ./Setup build -v ./Setup haddock ./Setup install -v After this, ghc-pkg list shows random-1.0.1.1 in the list, and now DoCon finds it. Regards, ------ Sergei mechvel(a)botik.ru

1 0