September 2013 - ghc-devs

RE: Proposal: Improving the IsString String instance
by Simon Peyton-Jones 10 Sep '13

10 Sep '13

(redirecting to ghc-devs) Thomas Let's be clear what is happening here. After all the dust has settled we call TcSimplify.applyDefaultingRules to look at a bunch of unsolved constraints and generate new, extra constraints that might help solve them. Thus if we see (Eq a, Num a) we might generate the extra constraint (a ~ Integer) to try to help solve them. Now, what you want to do is to spot a constraint like (IsString [a]), and generate (a ~ Char). Now it's true that the current machinery in findDefaultableGroups is set up to look for constraints of form (C a), because that's what the rules say. If you change the rules you'll need to change the code. But I'm not even sure what the new rule *are*. The current GHCi defaulting rules are documented here: http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluat… The first thing to do is to write down the exact new rules that you are trying to implement. Simon | -----Original Message----- | From: Thomas Schilling [mailto:nominolo@googlemail.com] | Sent: 09 September 2013 23:24 | To: Ganesh Sittampalam | Cc: Simon Peyton-Jones; Edward Kmett; Haskell Libraries | Subject: Re: Proposal: Improving the IsString String instance | | I took a stab at implementing this. Having a superclass would probably | make the implementation simpler. | | I can't figure out the proper way to add a "C [a] = <ty>" constraint to | the simplifier. The defaulting mechanism currently just looks tries | combinations of "a := <ty>" for all the candidate types. If "a" is not | just a type variable this needs to be add another wanted constraint, but | I couldn't find a function that satisfies that purpose. (Even though I | read the OutsideIn(X) journal paper a while ago, the type checker code | does indeed seem nearly impenetrable -- there's still some boxy | unification code in TcUnify, and it's not clear how that interacts with | the new solver.) | | Anyway, if someone can point out how I to turn "setWantedTyBind tv ty" | into something like "setWantedEquality ty1 ty2" I can implement it. | Otherwise, I'd have to use use some rather gnarly hack that special- | cases "C [a] = <ty>" to "a := Char" iff "<ty> == String" | | / Thomas | | On 29 Aug 2013, at 08:03, Ganesh Sittampalam <ganesh(a)earth.li> wrote: | | > I'd be marginally in favour of the new class + simpler defaulting | rule. | > | > This is mostly on the philosophical ground that it's better to compose | > existing features than to introduce new ones. | > | > It also feels like it might be more future-proof/flexible, though I | > can't think of a compelling example. A weak one is that someone might | > want to work with Array Char or similar. | > | > On 27/08/2013 08:29, Simon Peyton-Jones wrote: | >> PS: I'm not convinced that it's worth the overhead of adding a new | class. Modifying the defaulting rules would probably be enough, although | it does involve one new feature, namely that it must default IsString | [beta] as well as IsString alpha. | >> | >> Simon | >> | >> | -----Original Message----- | >> | From: Simon Peyton-Jones | >> | Sent: 27 August 2013 08:27 | >> | To: 'Ganesh Sittampalam'; Edward Kmett | >> | Cc: Haskell Libraries | >> | Subject: RE: Proposal: Improving the IsString String instance | >> | | >> | If I understand aright, the problem is that we end up with | constraints | >> | like | >> | IsString alpha | >> | or | >> | IsString [beta] | >> | where alpha or beta are otherwise-unconstrained unification | variables. | >> | Under those circumstances we'd like to default to IsString String. | >> | | >> | This is *exactly* what the current type-class-defaulting mechanism | does. | >> | Eg with (show 3) you get (Show alpha, Num alpha) and want to choose | >> | alpha to be something sensible. | >> | | >> | We've already extended it for GHCi | >> | | http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive- | >> | evaluation.html#extended-default-rules | >> | | >> | I don't think this would be controversial. The path seems to be: | >> | propose a concrete extension to the rules, | >> | specify when it's enabled | >> | get everyone to agree | >> | provide a patch (relevant code is in | >> | TcSimplify.applyDefaultingRules) | >> | | >> | Simon | >> | | >> | | -----Original Message----- | >> | | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf | Of | >> | | Ganesh Sittampalam | >> | | Sent: 26 August 2013 21:55 | >> | | To: Edward Kmett | >> | | Cc: Haskell Libraries | >> | | Subject: Re: Proposal: Improving the IsString String instance | >> | | | >> | | Couldn't it work (with suitable extensions to the list of blessed | >> | | classes) with Henning's IsCharList suggestion? The unresolved | >> | constraint | >> | | would be IsCharList a. | >> | | | >> | | On 26/08/2013 21:47, Edward Kmett wrote: | >> | | > The problem is ExtendedDefaultRules only works when the whole | type | >> | is | >> | | > unknown. If we know part of the type e.g. that it is [a] for | some a | >> | as | >> | | > we figure out from length, or that it is (f a), then it doesn't | kick | >> | | in. | >> | | > | >> | | > print works because "hello" :: (IsString a, Show a) => a | >> | | > | >> | | > knows nothing about the argument a | >> | | > | >> | | > and Show is included in the EDR list of blessed classes. | >> | | > | >> | | > If at the repl you turn on OverloadedStrings and EDR | >> | | > | >> | | > showList "hello" "" | >> | | > | >> | | > will still blow up, because it can know you have an argument | [a] | >> | with | >> | | a | >> | | > Show a constraint on it, and IsString [a], so it fails to meet | the | >> | | > fairly simplistic conditions required by EDR. | >> | | > | >> | | > -Edward | >> | | > | >> | | > | >> | | > On Mon, Aug 26, 2013 at 4:34 PM, Dag Odenhall | >> | <dag.odenhall(a)gmail.com | >> | | > <mailto:dag.odenhall@gmail.com>> wrote: | >> | | > | >> | | > |ExtendedDefaultRules| already provides this to some | extent, for | >> | | > example it makes |print "hello"| work without type | information. | >> | | > | >> | | > | >> | | > | >> | | > On Mon, Aug 26, 2013 at 10:09 PM, Dan Burton | >> | | > <danburton.email(a)gmail.com | <mailto:danburton.email@gmail.com>> | >> | | wrote: | >> | | > | >> | | > Just to throw another curveball at this conversation, | what | >> | | about | >> | | > a general, ad-hoc solution for 'typeclass defaults'? | The | >> | logic | >> | | > goes like this: Is there an "ambiguous type variable" | error | >> | | due | >> | | > to the use of the IsString typeclass? Try defaulting to | the | >> | | > String instance. If that doesn't work, try defaulting | to | >> | Text. | >> | | > Repeat for a finite, explicit list of instances. If | none of | >> | | > these defaults are successful, type error. | >> | | > | >> | | > We have hard-coded this sort of behavior into the Num | class. | >> | | Why | >> | | > not just provide this general capability for arbitrary | >> | | classes? | >> | | > Or at least hard-code it into IsString as well. | >> | | > | >> | | > In the absence of this sort of solution, +1 to Edward's | >> | | original | >> | | > proposal. | >> | | > | >> | | > The "o" proposal is not viable because the oft-needed | parens | >> | | > make it confusing and irritating to the new Haskeller. | >> | | > | >> | | > -- Dan Burton | >> | | > | >> | | > | >> | | > On Mon, Aug 26, 2013 at 12:41 PM, Henning Thielemann | >> | | > <lemming(a)henning-thielemann.de | >> | | > <mailto:lemming@henning-thielemann.de>> wrote: | >> | | > | >> | | > | >> | | > On Mon, 26 Aug 2013, Gabriel Gonzalez wrote: | >> | | > | >> | | > I'm guessing this is sarcastic, but I just want | to | >> | | > clarify what I understood Henning's proposal to | be. | >> | | > He's not saying we should provide an `o` | function | >> | in | >> | | > the standard library, but rather encourage | users to | >> | | > define their own. | >> | | > | >> | | > | >> | | > Yes. I would be ok if packages provide this | function, | >> | but | >> | | I | >> | | > would urge programmers to import that explicitly. | >> | | > | >> | | > | >> | | > This one liner would take the place of the | current | >> | | line | >> | | > that they devote right now to | `OverloadedStrings` . | >> | | > | >> | | > | >> | | > right | >> | | > | >> | | > | >> | | > However, the analogy is still apt since the | exact | >> | same | >> | | > line of reasoning applies to overloaded numeric | >> | | > literals where we currently rely on defaulting | to | >> | | solve | >> | | > this problem. | >> | | > | >> | | > | >> | | > I always use -Wall and thus I am warned about when | >> | | > defaulting takes place. Thus I am confident that I | do | >> | not | >> | | > rely on defaulting in my code. | >> | | > | >> | | > _______________________________________________ | >> | | > Libraries mailing list | >> | | > Libraries(a)haskell.org | <mailto:Libraries@haskell.org> | >> | | > http://www.haskell.org/mailman/listinfo/libraries | >> | | > | >> | | > | >> | | > | >> | | > _______________________________________________ | >> | | > Libraries mailing list | >> | | > Libraries(a)haskell.org <mailto:Libraries@haskell.org> | >> | | > http://www.haskell.org/mailman/listinfo/libraries | >> | | > | >> | | > | >> | | > | >> | | > _______________________________________________ | >> | | > Libraries mailing list | >> | | > Libraries(a)haskell.org <mailto:Libraries@haskell.org> | >> | | > http://www.haskell.org/mailman/listinfo/libraries | >> | | > | >> | | > | >> | | > | >> | | > | >> | | > _______________________________________________ | >> | | > Libraries mailing list | >> | | > Libraries(a)haskell.org | >> | | > http://www.haskell.org/mailman/listinfo/libraries | >> | | > | >> | | | >> | | | >> | | _______________________________________________ | >> | | Libraries mailing list | >> | | Libraries(a)haskell.org | >> | | http://www.haskell.org/mailman/listinfo/libraries | >> | >> _______________________________________________ | >> Libraries mailing list | >> Libraries(a)haskell.org | >> http://www.haskell.org/mailman/listinfo/libraries | >> | > | > | > _______________________________________________ | > Libraries mailing list | > Libraries(a)haskell.org | > http://www.haskell.org/mailman/listinfo/libraries

1 0

习李执政/经济走势与经营对策
by 庾轲葳 10 Sep '13

10 Sep '13

1 0

如何激励下属创造最佳业绩
by 怀荷觅 10 Sep '13

10 Sep '13

1 0

Control Your Appetite! No More Calorie Counting!
by Pure Garcinia Cambogia 10 Sep '13

10 Sep '13

100% Organic Weight Loss! http://www.fbadacieiodous.biz/2190/29/71/156/432.12tt64201835AAF17.php To Unsub - http://www.fbadacieiodous.biz/2190/29/71/156/432.12tt64201835AAF10.html PO Box 26452 Minneapolis, MN 55426 UNITED NATIONS Secretary-General Ban Ki-moon is recommending a 15 percent reduction in the number of U.N. troops in Haiti and an examination of whether a peacekeeping operation is still the best way to support the impoverished Caribbean nation.In a report to the U.N. Security Council circulated Tuesday, Ban said he intends to discuss with Haiti's government and member states the best way for the U.N. to continue contributing to "greater stability and development in the country."Ban said he will explore the option of replacing the peacekeeping mission, known as MINUSTAH, "with a smaller, more focused assistance mission by 2016" and include proposals on the way forward in his next report in March 2014.In the meantime, he recommended reducing MINUSTAH's military strength from 6,270 to 5,021 by June 2014. ve Boone and other past mascots a retirement ceremony in the upcoming academic year.The image of Denver Boone was originally designed by a Walt Disney artist and named by a UD student back in 1968 .The cartoony figure, which sports a scruffy beard and a raccoon skin cap, is reminiscent of the Daniel Boone character from the 1950s TV show based on the real-life pioneer.Boone was a legend of early American history and the archetypal hero of the American Western Frontier.Later, his image and legend fell victim to revisionist history as he became associated with the forceful displacement of Native Americans from their land.So how closely linked are Denver Boone and Daniel Boone?Any association of the Denver Boone caricature with America's pioneer hero, Daniel Boone, is misguided, said Randell Jones, historian and author of the book In the Footsteps of Daniel Boone.Mythology and Fess Parker aside, it is well documented that Daniel Boone never wore a coonskin cap. Neither did he wear a beard. Moreover, any exploits by him west of Missouri are speculative at best.

1 0

利用微-信平台创造更大利益空间
by 罗德君 10 Sep '13

10 Sep '13

1 0

Trac 8244 (remove the dependency on Cabal)
by JP Moresmau 09 Sep '13

09 Sep '13

Hello, I've been looking at http://ghc.haskell.org/trac/ghc/ticket/8244, following the discussions: -http://www.mail-archive.com/haskell-cafe@haskell.org/msg107850.html -http://www.haskell.org/pipermail/ghc-devs/2013-March/000762.html This is basically about the fact that GHC-as-a-library as a dependency on the Cabal library, which causes all kinds of grief for tools using the GHC API (can't upgrade Cabal). The ticket has a nice dependency diagram, thanks to lemao. So I tried to see what could work. This is what I've done so far: - created a new distribution-base library (the name avoids any reference to Cabal, don't know if it's wise) - build that library instead of Cabal in stage0 and stage1 - reference that library instead of Cabal in ghc.cabal, pkg-pkg.cabal, Cabal.Cabal - add the dependency when building ghc-cabal and ghc-tags, both need the full Cabal anyway. The distribution-base library contains the following modules: - Distribution.Compat.ParseUtils: the bits of Cabal's Distribution.ParseUtils we need - Distribution.Compat.ReadP: Cabal's ReadP - Distribution.InstalledPackageInfo: Cabal's Distribution.InstalledPackageInfo - Distribution.License: Cabal's Distribution.License - Distribution.ModuleName: Cabal's Distribution.ModuleName - Distribution.Package: Cabal's Distribution.Package minus the Dependency type and related functions (unused in GHC) - Distribution.PackageIndex: the bits of Cabal's Distribution.Simple.PackageIndex we need - Distribution.Text: Cabal's Distribution.Text - Distribution.Utils: the bits of Cabal's Distribution.Simple.Utils we need Note that Distribution.Version is not needed by GHC, even though it used to import it, it only used the datatype from base, and the Data instance I've moved to Distribution.Package. I've created a new Cabal module called Distribution.Dependency since the Dependency type is not needed, in the Cabal source code it's mainly imports that need to change. All seems to build on my machine. It doesn't really help the build itself since Cabal is still needed for ghc-cabal, but at least the GHC API does not require the Cabal library any more. What do you think? Is it a step in the right direction? Thanks JP -- JP Moresmau http://jpmoresmau.blogspot.com/

1 0

OverloadedRecordFields status update
by Adam Gundry 09 Sep '13

09 Sep '13

Hi ghc-devs, I have been working on a new extension, OverloadedRecordFields, and it is now essentially feature-complete. Unfortunately, I doubt it will make it into 7.8, as the changes are quite extensive, but I hope to get it in HEAD soon thereafter. I would really appreciate comments on the design [1], for which there is a prototype implementation [2] that works in GHC 7.6.3. If you'd like to review the code, you can check out the overloaded-record-fields branch from the Github repositories [3, 4], and there are notes on the implementation on the wiki [5]. Thanks! Adam [1] http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan [2] https://github.com/adamgundry/records-prototype [3] https://github.com/adamgundry/ghc [4] https://github.com/adamgundry/packages-base [5] http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Impleme…

2 4

Alex and new Bool primops
by Jan Stolarek 09 Sep '13

09 Sep '13

I am refactoring new Bool primops (#6135). There was a discussion on core-libraries-commitee list and the decision was made that we should keep names of primops we used so far and change their type signature (right now HEAD has different names for new primops and reuses old names for compatibility wrappers). I've changed names of the primops and removed the wrappers but I can't bootstrap GHC because old primops are hardwired into Alex. I get this build error when attempting to build stage 2 compiler: compiler/stage2/build/Lexer.hs:2348:34: Couldn't match expected type ‛Bool’ with actual type ‛Int#’ In the first argument of ‛(&&)’, namely ‛(offset >=# 0#)’ In the expression: (offset >=# 0#) && (check ==# ord_c) In the expression: if (offset >=# 0#) && (check ==# ord_c) then alexIndexInt16OffAddr alex_table offset else alexIndexInt16OffAddr alex_deflt s compiler/stage2/build/Lexer.hs:2348:53: Couldn't match expected type ‛Bool’ with actual type ‛Int#’ In the second argument of ‛(&&)’, namely ‛(check ==# ord_c)’ In the expression: (offset >=# 0#) && (check ==# ord_c) In the expression: if (offset >=# 0#) && (check ==# ord_c) then alexIndexInt16OffAddr alex_table offset else alexIndexInt16OffAddr alex_deflt s And indeed, looking at Lexer.hs I see: alex_scan_tkn user orig_input len input s last_acc = (...) -- some irrelevant code here (!(new_s)) = if (offset >=# 0#) && (check ==# ord_c) then alexIndexInt16OffAddr alex_table offset else alexIndexInt16OffAddr alex_deflt s So to compile GHC, Alex would need to generate different code for GHC 7.6.3 and below, and different for GHC 7.7 and above (or alternatively it could generate #if pragmas), but this means we'd need to update Alex. I created compatibility module within GHC called ExtsCompat46 and tried adding it to list of imported modules, but in generated Lexer.hs Alex adds a bunch of other modules among which is GHC.Exts, which conflicts with import of ExtsCompat46: compiler/stage1/build/Lexer.hs:2349:41: Ambiguous occurrence `>=#' It could refer to either `ExtsCompat46.>=#', imported from `ExtsCompat46' at compiler/parser/Lexer.x:79:1-19 or `GHC.Exts.>=#', imported from `GHC.Exts' at compiler/stage1/build/Lexer.hs:75:1-15 (and originally defined in `ghc-prim:GHC.Prim') Again, we would need updated version of Alex to generate correct code (also, this would break in the future after removing that compatibility module). I don't see a way out of this. Help? Janek

3 4

RE: newtype wrappers
by Simon Peyton-Jones 09 Sep '13

09 Sep '13

| However, there is perhaps a middle road: what if much of the | infrastructure is merged, without the user-facing feature? From a user's | point of view, these coercions feel much more like a library than a | language feature. Yes, the instances appear out of thin air, but | otherwise, the 'coerce' function is totally normal-looking. Unless I'm | mistaken, there is no new syntax. If we merge much (all?) of the | implementation but don't export "coerce" and "Coercible" anywhere, then we | can continue to tinker with the design in HEAD, and perhaps release with | 7.8.2. Does that make sense? Yes. We did this with type families in 7.4. Much of the infrastructure was there, but it wasn't an advertised feature so we did not feel constrained (for example) to apply bug fixes to the 7.4 branch. Let's do the same here. Essentially a full impl, but simply not advertised. OK? Note to other ghc-devs. The issue under discussion is whether to merge Joachim's "newtype wrapper" feature. I'm keen to do so because it's very cool. But arguably the design needs some time to "settle". Proposed outcome is to merge the code but not advertise the feature, like we did for type functions in 7.4. Simon | | Richard | | On Sep 7, 2013, at 1:41 PM, Simon Peyton-Jones <simonpj(a)microsoft.com> | wrote: | | > For a release we want | > * A stable design | > * An implementation that works pretty reliably | > It doesn't have to do everything; and we can improve the impl | incrementally. | > | > Let's see what Richard thinks | > | > Simon | > | > | -----Original Message----- | > | From: Joachim Breitner [mailto:mail@joachim-breitner.de] | > | Sent: 07 September 2013 18:37 | > | To: Simon Peyton-Jones | > | Cc: Richard Eisenberg (eir(a)cis.upenn.edu) | > | Subject: Re: newtype wrappers | > | | > | Hi, | > | | > | Am Samstag, den 07.09.2013, 17:17 +0000 schrieb Simon Peyton-Jones: | > | > I'm beginning to think that newtype wrappers might be done enough to | > | > put into 7.8. (Feature freeze is on Friday.) | > | > | > | > What do you think? It's a very attractive new feature, and fits | > | > nicely with the new roles. | > | | > | I'm reluctant; I haven't even started to think what happens when I try | > | to coerce between more fancy stuff like newtype families. Maybe it all | > | works smoothly (after all, this is Haskell and the code typechecks), | but | > | I'm not too confident. | > | | > | Furthermore there is some code smell in the way I mark the newtype | > | constructors as used, where I had to drill a hole in the TcS | > | abstraction. | > | | > | If you are not worried about these, then it just remains to | > | * extend the user documentation and | > | * add coerce and Coercible to GHC.Exts. | > | which is certainly possible to do until Friday. | > | | > | Greetings, | > | Joachim | > | | > | -- | > | Joachim "nomeata" Breitner | > | mail(a)joachim-breitner.de * http://www.joachim-breitner.de/ | > | Jabber: nomeata(a)joachim-breitner.de * GPG-Key: 0x4743206C | > | Debian Developer: nomeata(a)debian.org | >

2 1

A build problem on Mac
by Kazu Yamamoto 09 Sep '13

09 Sep '13

Hi, I cannot build GHC head on Mac today: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-7.7.20130907 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.0 -package array-0.4.0.2 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0 -package containers-0.5.3.1 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.1 -package transformers-0.3.0.0 -package unix-2.7.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2 -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/deSugar/Coverage.lhs -o compiler/stage2/build/Coverage.o -dyno compiler/stage2/build/Coverage.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20130907 for i386-apple-darwin): expectJust block_order Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/build/Parser.o] Error 1 make[1]: *** Deleting file `compiler/stage2/build/Parser.o' make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 --Kazu

4 11