- ghc-devs - Haskell.org

Phabricator gifs
by Simon Peyton Jones 24 Jun '14

24 Jun '14

Is it possible to not get the hugely distracting and pixel-consuming gifs in Phabricator displays. Eg see the one below. Simon [cid:image001.png@01CF8EE0.70DAF510]

3 2

Associated type instances
by Simon Peyton Jones 24 Jun '14

24 Jun '14

Friends I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack. Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#… All of this arose when thinking about fixing Trac #9063. I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). Does anyone object? Thanks Simon The issue Consider this: class C a where type T a b :: * instance C [x] where type T [x] b = x -> b That is just what you'd expect. But currently this is allowed too: instance C [x] where type T [x] Int = x -> Int type T [x] Bool = Bool -> x That is, GHC 7.8 allows many associated type instances, provided they don't overlap. But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed: instance C [x] where type T [Int] b = b -> Int type T [Bool] b = Bool -> b Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like class D a where type S (b :: Bool) a :: * Now this would make some kind of sense: instance D [x] where type S True [x] = x -> x type S False [x] = x But for closed kinds, you really want a closed type family. So this would be better: instance D [x] where type S b [x] = SHelp x b type family SHelp x b where SHelp x True = x -> x SHelp x False = x So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange. All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect. My solution I propose to simplify substantially, as follows: * The "shared arguments" of an associated type are the argument positions that mention a type variable from the class header. So in class C above, the first argument position of T is "shared"; and in class D, the second argument position of S is shared. * A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have o type variables in the non-shared argument positions, and o an exact copy of the corresponding instance header type in the shared positions * For each associated type you can have o at most one default declaration in the class declaration o at most one type instance declaration in the class instance declaration

3 2

clang warnings
by Kazu Yamamoto 24 Jun '14

24 Jun '14

Hi, To test the coming GHC 7.8.3, I started to use the latest ghc-7.8 branch. Unfortunately, on my Mac, I saw many warnings which are not displayed with GHC 7.8.2: clang: warning: argument unused during compilation: '-fno-stack-protector' clang: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' clang: warning: argument unused during compilation: '-I test' clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' clang: warning: argument unused during compilation: '-I dist/build/autogen' clang: warning: argument unused during compilation: '-I dist/build/spec/spec-tmp' Is this a known issue? --Kazu

5 9

RE: New GHC feature proposal: Pattern families
by Simon Peyton Jones 23 Jun '14

23 Jun '14

Baldur (My name is Simon, not Peyton, incidentally. "Peyton Jones" is my last name.) I'm glad you are enjoying pattern synonyms. Thanks for identifying #9226, which I guess is you. I honestly don't understand your pattern family proposal. Would you like to write a wiki page somewhere describing the syntax typing (static semantics) desugaring (dynamic semantics) as clearly and precisely as you can, independent of prisms, and using the simplest possible examples to illustrate. By all means say that prisms are a more advanced application, and give examples to show how. But in general to specify a language feature you need a lot more than a couple of examples! Then you can ask GHC users what they think. I have to say that I'm cautious about adding further features to pattern synonyms until we've gotten more user experience with what we have. (Do you think the explicitly bidirectional stuff on the wiki page is important? To me that seems like the first thing a user might stumble over.) Incidentally, I'd really like to replace view patterns with https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative, another thing that is awaiting cycles. Copying ghc-devs for interest Thanks Simon | -----Original Message----- | From: Baldur Blöndal [mailto:baldurpet@gmail.com] | Sent: 18 June 2014 04:31 | To: Simon Peyton Jones; gergo(a)erdi.hu | Subject: New GHC feature proposal: Pattern families | | Hello Peyton and Gergo, | | I'm a master's student at Chalmers, a minor GHC contributor and have | written about the pattern synonyms extension | (https://www.fpcomplete.com/user/icelandj/Pattern%20synonyms) and | included is a proposal for an extension I call “pattern families” | allowing users to create patterns parameterized by an expression. I feel | like patterns don't get nearly as much attention as the type system and | this is my attempt to balance things out :) | | I discussed the proposal with Edward Kmett who suggested an example with | prisms and that I contact you two for comments. The syntax is still in | flux. | | Some motivating examples for your consideration. | | PRISM PATTERNS | | Edward suggested a pattern to match a prism which would look like this: | <edwardk> an example where you want it is if you want to use a pattern | synonym to match a prism <edwardk> foo (Match _Left a) = ... | [...] | <edwardk> the example of a single pattern that can match every prism | would be a nice example | | which would be quite easy to implement: | | | pattern Match prism a ← ((^? prism) → Just a) | | | | bar :: Either c (Either a b) → a | | bar (Match (_Right._Left) a) = a | | bar _ = error "Not a Right (Left ...)" | | This can be used for any prism: | | jsonBlob = "[{\"someObject\": {\"version\": [1,0,3]}}]" | | | | foo (Match (nth 0) (Match (key "someObject") (Match (key "version") | (Match (nth 1) a)))) = a | | ghci> foo jsonBlob | | Number 0.0 | | and defining more specilized patterns we can make it terser: | | pattern Get i a ← ((^? nth i) → Just a) pattern Key str a ← ((^? key | | str) → Just a) | | | | baz (Get 0 (Key "someObject" (Key "version" (Get 1 a)))) = a baz (0 | | `Get` "someObject" `Key` "version" `Key` 1 `Get` a) = a baz (a :→ | | "someObject" :⇒ "version" :⇒ 1 :→ a) = a | where | | pattern i :→ a ← Get i a | | pattern str :⇒ a ← Key str a | | So this is excellent for pattern matching on any sort of nested | structure: records, JSON, XML, HTML, ASTs, … Since this also supports | pattern matching on any value that satisfies a predicate. | | N+K PATTERNS | Generalizing n+k patterns: We create a pattern family indexed by its | first argument: | | | pattern (a :+) :: Num a ⇒ a → a | | k :+ n ← (unSucc k → Just n) -- [1] unSucc defined below | | where (a :+) indicates that 'k' is an index of the pattern family | allowing it to be supplied to the view pattern. | The pattern can be used as follows: | | fact 0 = 1 | | fact m@(1 :+ n) = m * fact n | | PATTERN MATCHING REGULAR EXPRESSIONS The pattern (:=~) is inspired | by the operator (=~) from Text.Regex.Posix.Wrap (regex-posix), note that | its second argument is the index here: | | pattern (:=~ String) :: RegexContext Regex a c ⇒ a → c | | n :=~ pattern ← ((=~ pattern) → n) | | Used as: | | vowels :: RegexContext Regex src tgt ⇒ src → tgt vowels (n :=~ | | "[aeiou]") = n | | | | ghci> vowels "honorificabilitudinitatibus" ∷ Int | | 13 | | where you can of course pattern match on the resulting value: | | | has5Vowels :: String → Int | | has5Vowels (5 :=~ "[aeiou]") = True | | has5Voewls _ = False | | TYPE INFERENCE | Here is an example of a snippet inferring the type of an if expression: | | | infer Γ (If cond t e) = | | case (infer Γ cond, infer Γ t, infer Γ e) of | | (Just TBool, Just τ₁, Just τ₂) | | | τ₁ == τ₂ = Just t₁ | | Here is how it might look with pattern families: | | | infer Γ (If (Infer Γ TBool) (Infer Γ τ₁) (Infer Γ τ₂)) | | | τ₁ == τ₂ = Just τ₁ | | (or even nicer if we use (:⇑) = Infer) | | infer Γ (If (Γ :⇑ TBool) (Γ :⇑ τ₁) (Γ :⇑ τ₂)) … | | IMPLEMENTATION | From what I can see this is a relatively straight-forward translation | into view patterns where a variable bound by a view pattern is an | “index” to the pattern family and unbound variables are regular | patterns. In the examples above I use special syntax for the index where | the type is included but even without any annotation it can be inferred | from context. | | If the proposal is fine by you I offer to do the implementation work, | all feedback welcome! | | Best regards, | Baldur Blöndal | | APPENDIX | | unSucc :: Int → Int → Maybe Int | | unSucc k n | | | n - k < 0 = Nothing | | | otherwise = Just (n - k) | |

2 1

Int-based lexer flag bitmask exhausted
by Herbert Valerio Riedel 23 Jun '14

23 Jun '14

Hello Simon (et al.), While doing #9224[1] as a finger-exercise to extend the lexer to support base-2 integer literals, I got stuck on the lexer extension map being represented as an 'Int', which (in GHC) is only guaranteed to hold least 32bits. -- for reasons of efficiency, flags indicating language extensions (eg, -- -fglasgow-exts or -XParallelArrays) are represented by a bitmap -- stored in an unboxed Int However, as all 32bits are already taken up by language extensions, and I'd need a 33th bit, I'm wondering how to proceed. Can we replace the 'Int' by an 'Int64' (or even better a Word64, ideally with a newtype or at least a type-synonym around it?) which would give us a bit more headroom while being semantically sound even for 'bitSize Int == 32'? [1]: https://ghc.haskell.org/trac/ghc/ticket/9224 Cheers, hvr

3 4

RE: [commit: ghc] master: Fix #9047 (b847481)
by Simon Peyton Jones 23 Jun '14

23 Jun '14

Something clever/important is going on here, but no `Note` explains what, or even references the ticket :-(. I know I'm obsessive about this, but I've spent too long staring at code wondering why it is the way it is, when a pointer to the relevant ticket and a few remarks would have made it all clear. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 23 June 2014 07:28 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Fix #9047 (b847481) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/b84748121e777d098198f2583d11a9 | 424c1b1650/ghc | | >--------------------------------------------------------------- | | commit b84748121e777d098198f2583d11a9424c1b1650 | Author: Austin Seipp <austin(a)well-typed.com> | Date: Mon Jun 23 00:07:10 2014 -0500 | | Fix #9047 | | Signed-off-by: Austin Seipp <austin(a)well-typed.com> | | | >--------------------------------------------------------------- | | b84748121e777d098198f2583d11a9424c1b1650 | compiler/main/DriverPipeline.hs | 46 ++++++++++++++++++++++------------ | ------- | compiler/main/DynFlags.hs | 2 ++ | compiler/main/SysTools.lhs | 7 +++++-- | 3 files changed, 32 insertions(+), 23 deletions(-) | | diff --git a/compiler/main/DriverPipeline.hs | b/compiler/main/DriverPipeline.hs index 39df2a1..b90a821 100644 | --- a/compiler/main/DriverPipeline.hs | +++ b/compiler/main/DriverPipeline.hs | @@ -1206,6 +1206,7 @@ runPhase (RealPhase (As with_cpp)) input_fn dflags | -- might be a hierarchical module. | liftIO $ createDirectoryIfMissing True (takeDirectory | output_fn) | | + ccInfo <- liftIO $ getCompilerInfo dflags | let runAssembler inputFilename outputFilename | = liftIO $ as_prog dflags | ([ SysTools.Option ("-I" ++ p) | p <- | cmdline_include_paths ] @@ -1220,7 +1221,9 @@ runPhase (RealPhase (As | with_cpp)) input_fn dflags | ++ (if platformArch (targetPlatform dflags) == | ArchSPARC | then [SysTools.Option "-mcpu=v9"] | else []) | - | + ++ (if ccInfo == AppleClang51 | + then [SysTools.Option "-Qunused-arguments"] | + else []) | ++ [ SysTools.Option "-x" | , if with_cpp | then SysTools.Option "assembler-with-cpp" | @@ -2129,26 +2132,27 @@ joinObjectFiles dflags o_files output_fn = do | let mySettings = settings dflags | ldIsGnuLd = sLdIsGnuLd mySettings | osInfo = platformOS (targetPlatform dflags) | - ld_r args ccInfo = SysTools.runLink dflags ([ | - SysTools.Option "-nostdlib", | - SysTools.Option "-Wl,-r" | - ] | - ++ (if ccInfo == Clang then [] | - else [SysTools.Option "-nodefaultlibs"]) | - ++ (if osInfo == OSFreeBSD | - then [SysTools.Option "-L/usr/lib"] | - else []) | - -- gcc on sparc sets -Wl,--relax | implicitly, but | - -- -r and --relax are incompatible for ld, | so | - -- disable --relax explicitly. | - ++ (if platformArch (targetPlatform dflags) == | ArchSPARC | - && ldIsGnuLd | - then [SysTools.Option "-Wl,-no-relax"] | - else []) | - ++ map SysTools.Option ld_build_id | - ++ [ SysTools.Option "-o", | - SysTools.FileOption "" output_fn ] | - ++ args) | + ld_r args cc = SysTools.runLink dflags ([ | + SysTools.Option "-nostdlib", | + SysTools.Option "-Wl,-r" | + ] | + ++ (if any (cc ==) [Clang, AppleClang, | AppleClang51] | + then [] | + else [SysTools.Option "-nodefaultlibs"]) | + ++ (if osInfo == OSFreeBSD | + then [SysTools.Option "-L/usr/lib"] | + else []) | + -- gcc on sparc sets -Wl,--relax implicitly, | but | + -- -r and --relax are incompatible for ld, so | + -- disable --relax explicitly. | + ++ (if platformArch (targetPlatform dflags) == | ArchSPARC | + && ldIsGnuLd | + then [SysTools.Option "-Wl,-no-relax"] | + else []) | + ++ map SysTools.Option ld_build_id | + ++ [ SysTools.Option "-o", | + SysTools.FileOption "" output_fn ] | + ++ args) | | -- suppress the generation of the .note.gnu.build-id section, | -- which we don't need and sometimes causes ld to emit a diff -- | git a/compiler/main/DynFlags.hs b/compiler/main/DynFlags.hs index | 7222af3..f82c404 100644 | --- a/compiler/main/DynFlags.hs | +++ b/compiler/main/DynFlags.hs | @@ -3757,6 +3757,8 @@ data LinkerInfo | data CompilerInfo | = GCC | | Clang | + | AppleClang | + | AppleClang51 | | UnknownCC | deriving Eq | | diff --git a/compiler/main/SysTools.lhs b/compiler/main/SysTools.lhs | index dc9642d..51d5af1 100644 | --- a/compiler/main/SysTools.lhs | +++ b/compiler/main/SysTools.lhs | @@ -788,12 +788,15 @@ getCompilerInfo' dflags = do | -- Regular clang | | any ("clang version" `isPrefixOf`) stde = | return Clang | + -- XCode 5.1 clang | + | any ("Apple LLVM version 5.1" `isPrefixOf`) stde = | + return AppleClang51 | -- XCode 5 clang | | any ("Apple LLVM version" `isPrefixOf`) stde = | - return Clang | + return AppleClang | -- XCode 4.1 clang | | any ("Apple clang version" `isPrefixOf`) stde = | - return Clang | + return AppleClang | -- Unknown linker. | | otherwise = fail "invalid -v output, or compiler is | unsupported" | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

building for Mac
by Mark Lentczner 23 Jun '14

23 Jun '14

When the bin-dists are built, can we have them built with a 10.6 or 10.7 target? If built that way, they should run on all greater OSes. I don't think there is a reason not to. The current bindists, built on Mavericks, seg fault 11 when run an 10.7 or earlier. - Mark

1 1

Case expressions in STG
by Tom Ellis 21 Jun '14

21 Jun '14

I am reading SPJ's seminal work "Implementing lazy functional languages on stock hardware: the Spinless Tagless G-machine" (1992). The paper is available here http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.3729 On p62 we see "The expression scrutinised by a case expression must eventually evaluate either to a primitive value or a constructor application.". This doesn't make sense to me. Isn't the following a valid STG program? What am I missing? Where is it specified that the scrutinee of a case expression cannot be of a function type? {x} \n {z} -> let f = \{x} \n {y} -> g x y in case f of f' -> f' z Thanks, Tom

3 7

Uniquable RdrName instance
by Jan Stolarek 20 Jun '14

20 Jun '14

Hi all, I just found myself in the need of Uniquable instance for RdrName. I'm surprised that such instance does not exist already because other datatypes like Name or OccName already have Uniquable instances. So, is there a reason why Uniquable instance for RdrName does not exist already (other than "it wasn't needed")? How should such an instance look like? I made an attempt: rdrNameUnique :: RdrName -> Unique rdrNameUnique (Unqual occName) = getUnique occName rdrNameUnique (Qual _ occName) = getUnique occName rdrNameUnique (Orig _ occName) = getUnique occName rdrNameUnique (Exact name ) = getUnique name But I suspect this might be wrong: - cases 1 and 4 simply return a Unique for the OccName/Name stored inside RdrName. I think this will assign the same Unique to RdrName and corresponding OccName/Name. Is this allowed? - cases 2 and 3 ignore the Module stored inside RdrName. Again, this assigns the RdrName with a Unique identical to OccNames stored inside it. Help appreciated. Janek

6 9

Proposal: Partial Type Signatures
by Thomas Winant 20 Jun '14

20 Jun '14

Dear GHC developers, Together with Tom Schrijvers, Frank Piessens and Dominique Devriese, I have been working on a proposal for adding *Partial Type Signatures* to GHC. In a partial type signature, annotated types can be mixed with inferred types. A type signature is written like before, but can now contain wildcards, written as underscores. The types of these wildcards or unknown types will be inferred by the type checker, e.g. foo :: _ -> Bool foo x = not x -- Inferred: Bool -> Boo The proposal also includes a form of generalisation which aligns with the existing generalisation that GHC does. We have written down a motivation (when and how might you use this) and details about the design and implementation on the following wiki page: https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures We have a (work in progress) implementation [1] of the feature based on GHC. It currently implements most of what we propose, but there are some remaining important bugs mostly concerning the generalisation. We also described our design and presented a formalisation based on the OutsideIn(X) formalism in a paper [2] presented at PADL'14. What we are hoping to get from the people on this list is any of the below: * Read the design, play with the implementation and tell us any comments you may have about the feature, its design and implementation. * Opinions on whether this feature might be acceptable in GHC upstream at some point (if not, we do not think it's worth developing the implementation much further). * Perhaps a code review or a discussion with someone more knowledgeable about the internals of GHC's type checker about how we might fix the remaining problems in our implementation (specifically, we could use some help with implementing the generalisation of partial type signatures). * Feedback on the `Questions and issues' section on the wiki page. Kind regards, Thomas Winant [1]: https://github.com/mrBliss/ghc-head/ [2]: https://lirias.kuleuven.be/bitstream/123456789/423475/3/paper.pdf Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

12 26