- ghc-tickets - Haskell.org

Re: [GHC] #6018: Injective type families
by GHC 17 Jul '14

17 Jul '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #4259 | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:41 jstolarek]: > This is beyond my knowledge - I would require some guidance here. But if it's possible to implement injective type families without this change then I would postpone it until later and possibly consider it a separate task. Yes, it's possible, but there are some circumstances in which users could say that GHC gives an erroneous type error, in that GHC would manifestly have enough knowledge to make progress but doesn't. I agree that you should go ahead without this piece, though! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 17 Jul '14

17 Jul '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #4259 | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:40 goldfire]: > I'm still not sold on the concrete syntax involving `result`, despite having introduced that idea myself. I like the `(**)` suggestion here a bit more: http://www.haskell.org/pipermail/ghc-devs/2014-July/005492.html So, to be precise, with this syntax the examples from the wiki page would look like this: {{{ type family F a b c | F -> a b c type family G a b c | G -> a b type family H a b c | H a -> b c, H b -> a c, H c -> a b type family J a b c | J a -> b c, J b -> a c }}} I did not propose to use the notation like `H b -> a c` because I thought it might mislead people to think that: a) `H` could be partially applied; b) some parameters of `H` could be skipped (ie. we can apply it to `b` without first applying to `a`). Luckily, this is not a blocking issue for the rest of implementation. It should only affect 3 files in the parser, so it can be changed later. > Separately, a change to Core will be necessary to really make this work in all cases. > > (...) > > All that said, this use case is obscure, and the primary push for injective type families does not seem to require a change to Core. It is worth implementing without this piece. But, the idea came up in conversation, and I thought I should record it. This is beyond my knowledge - I would require some guidance here. But if it's possible to implement injective type families without this change then I would postpone it until later and possibly consider it a separate task. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 17 Jul '14

17 Jul '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #4259 | -------------------------------------+------------------------------------- Comment (by goldfire): I'm still not sold on the concrete syntax involving `result`, despite having introduced that idea myself. I like the `(**)` suggestion here a bit more: http://www.haskell.org/pipermail/ghc-devs/2014-July/005492.html Separately, a change to Core will be necessary to really make this work in all cases. {{{ data X a where MkX :: (F b c ~ a) => b -> c -> X a }}} Say `F` is injective (in both arguments). After pattern-matching on `MkX ... :: X (F Int Bool)`, we will probably want to discover that `b` is `Int` and `c` is `Bool`. To do so, we will need to decompose the `(F b c ~ a)` coercion, using the '''left''' and '''right''' (or perhaps '''nth''') coercion forms. These currently don't work over type families, and for good reason. However, if a type family is injective, then these ''could'' be made to work over type families. With the update to Core, we would probably want to make sure we don't lose type safety, though! All that said, this use case is obscure, and the primary push for injective type families does not seem to require a change to Core. It is worth implementing without this piece. But, the idea came up in conversation, and I thought I should record it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7379: rangeTest test fails on Windows
by GHC 16 Jul '14

16 Jul '14

#7379: rangeTest test fails on Windows -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.1 libraries/random | Keywords: Resolution: | Operating System: Unknown/Multiple Differential Revisions: | Type of failure: None/Unknown Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: rrnewton (added) * status: new => patch Comment: https://github.com/haskell/random/pull/5 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7379#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8013: Strange closure type error building hs-kqueue on FreeBSD
by GHC 16 Jul '14

16 Jul '14

#8013: Strange closure type error building hs-kqueue on FreeBSD -------------------------------------+------------------------------------- Reporter: ahktenzero | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 (LLVM) | Keywords: Resolution: worksforme | Operating System: FreeBSD Differential Revisions: | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: infoneeded => closed * resolution: => worksforme -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8013#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 16 Jul '14

16 Jul '14

#7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: jstolarek AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Operating System: Unknown/Multiple Resolution: | Type of failure: GHC rejects Differential Revisions: Phab:D72 | valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => Phab:D72 Comment: I created a phabricator revisionfir this ticket: Phab:D72 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8902: Test for RTLD_NEXT, RTLD_DEFAULT broken on Linux
by GHC 16 Jul '14

16 Jul '14

#8902: Test for RTLD_NEXT, RTLD_DEFAULT broken on Linux ------------------------------------+--------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/unix | Version: 7.8.1-rc2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Building 7.8.1RC2 on openSUSE, I see this: {{{ [ 2270s] checking return type of unsetenv... int [ 2270s] checking for RTLD_NEXT from dlfcn.h... no [ 2270s] checking for RTLD_DEFAULT from dlfcn.h... no [ 2270s] checking for RTLD_LOCAL from dlfcn.h... yes }}} The manual says that both RTLD_NEXT and RTLD_DEFAULT exist. Setting priority to low as I don't see any failures because of that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8902> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1487: unix package: test needed for getLoginName
by GHC 16 Jul '14

16 Jul '14

#1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thomie Type: bug | Status: closed Priority: lowest | Milestone: Component: | Version: libraries/unix | Keywords: Resolution: fixed | Operating System: Linux Differential Revisions: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Test Case: Difficulty: Easy (less | Blocking: than 1 hour) | Blocked By: | Related Tickets: #8293 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: Merged in [https://github.com/haskell/unix/commit/cad1ef27bb0a51bc68ebadb1297de1ae05be… unix] package: Enable test for getLoginName Fixes #1487. Make use of no_stdin test option, introduced explictly for this purpose in fa52a8c9d8eae5e3fc4c0cf0e5672875e161e05c -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1487#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 16 Jul '14

16 Jul '14

#7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: jstolarek AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Operating System: Unknown/Multiple Resolution: | Type of failure: GHC rejects Differential Revisions: | valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:43 ross]: > Replying to [comment:42 jstolarek]: > > I'm able to compile > > > > {{{ > > test :: Arrow a => a i i > > test = proc n -> do > > returnA -< n > > }}} > > > > using the new desugaring, which was not possible earlier. > > I wouldn't have expected any change in the handling of this. Hm... I just realized I probably misunderstood one thing. My desugaring is slightly different, but this is easy to fix. > If we're allowing rebinding, that should be type-checked and desugared exactly as if it were written > > {{{ > test :: Arrow a => a i i > test = proc n -> (returnA -< n) `thenA` (returnA -< n) > }}} I believe that my implementation is doing exactly this. It's just that types don't match. > For the default `thenA`, > {{{ > thenA :: Arrow a => a (e,s) b -> a (e,s) c -> a (e,s) c > u `thenA` v = arr id &&& u >>> arr fst >>> v > }}} > we have a1 = a2 = a, s1 = s2 = () and t = i, but with rebinding they'd be taken from the type of `thenA`, which could be anything matching the type in the above inference. At the moment my implementation does not work even for default `thenA`. I keep looking at the desugaring of monadic do-notation trying to figure out where did I go wrong. I guess the discussion here is more about the details of my implementation. To keep in line with [http://www.haskell.org/pipermail /ghc-devs/2014-July/005562.html recent decisions] I will move it to [https://phabricator.haskell.org/ Phab]. I'll post the link once I've created a new phabricator revision. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9278: GHCi crash:
by GHC 16 Jul '14

16 Jul '14

#9278: GHCi crash: ------------------------------------------+------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: crash, dynamic linking | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9277 | ------------------------------------------+------------------------------- Given an Objective-C object file referencing a symbol available in a system framework, interactive GHCi 7.6.3 crashes in an odd fashion. Start with an Objective-C source file, defining a function to be used via the FFI: {{{ $ cat >foo.m <<EOF #import <Foundation/Foundation.h> BOOL is_main_thread() { return [NSThread isMainThread]; } EOF }}} {{{ $ cat >Main.hs <<EOF module Main where foreign import ccall "is_main_thread" isMainThread :: IO Bool main :: IO () main = do mt <- isMainThread print mt EOF }}} Non-interactive GHC 7.6.3 works as expected: {{{ $ clang -c -o foo.o foo.m }}} {{{ $ ghc -framework Foundation -o foo foo.o Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking foo ... }}} {{{ $ ./foo True }}} Interactive GHCi 7.6.3 crashes: {{{ $ ghci -framework Foundation foo.o Main.hs GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) foo.o ... done Loading object (framework) Foundation ... done final link ... done Ok, modules loaded: Main. > main 2014-07-07 12:28:21.811 ghc[37395:1103] *** NSForwarding: warning: selector (0x10ddef328) for message 'isMainThread' does not match selector known to Objective C runtime (0x7fff8ea15881)-- abort 2014-07-07 12:28:21.813 ghc[37395:1103] +[NSThread isMainThread]: unrecognized selector sent to class 0x7fff75535280 2014-07-07 12:28:21.814 ghc[37395:1103] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[NSThread isMainThread]: unrecognized selector sent to class 0x7fff75535280' *** First throw call stack: ( 0 CoreFoundation 0x00007fff8bb4825c __exceptionPreprocess + 172 1 libobjc.A.dylib 0x00007fff85029e75 objc_exception_throw + 43 2 CoreFoundation 0x00007fff8bb4b02d +[NSObject(NSObject) doesNotRecognizeSelector:] + 205 3 CoreFoundation 0x00007fff8baa6322 ___forwarding___ + 1010 4 CoreFoundation 0x00007fff8baa5ea8 _CF_forwarding_prep_0 + 120 5 ??? 0x000000010ddef31a 0x0 + 4527682330 6 ??? 0x000000010ddf02f5 0x0 + 4527686389 ) libc++abi.dylib: terminating with uncaught exception of type NSException Abort trap: 6 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9278> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3