- ghc-tickets - Haskell.org

[GHC] #10131: improve error message for build on noexec-mounted device
by GHC 18 Jun '15

18 Jun '15

#10131: improve error message for build on noexec-mounted device -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- i was building (in a sandbox) on a ramdisk that was accidentally mounted with the noexec flag. for example during the install of `vector`, you get an error like Loading package primitive-0.5.4.0 ... <command line>: can't load .so/.DLL for: somepath/.cabal-sandbox/lib/x86_64-linux- ghc-7.8.4/primitive-0.5.4.0/libHSprimitive-0.5.4.0-ghc7.8.4.so (somepath /.cabal-sandbox/lib/x86_64-linux- ghc-7.8.4/primitive-0.5.4.0/libHSprimitive-0.5.4.0-ghc7.8.4.so: failed to map segment from shared object) relevant output of `mount`: none on somepath type tmpfs (rw,nosuid,nodev,noexec,relatime,gid=103,user=lspitzner) this is by far no minimal test-case, but i hope my description of the problem is sufficient. if not, i can provide verbose output for my or other test-cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 17 Jun '15

17 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by jpbernardy): Ok, I am just pointing out that the implementation is weird from my point of view. I don't want to make a big fuss about this, but I feel that it's something that should be considered. I suppose in a few years someone may raise the issue again :) Regarding blame: The point is that if you get a value of an empty type in your context, it is the caller which is to blame. The proper way to report this blame at runtime is force the caller to produce the value, by forcing it. If you raise an exception yourself you get the blame instead, and so it is harder to track which code is really wrong. I think that a good entry point to the concept of blame is "Well-typed programs can't be blamed" http://homepages.inf.ed.ac.uk/wadler/topics/blame.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 17 Jun '15

17 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): @jpbernardy, I think there are couple of different issues involved here; 1. This patch doesn't change anything about GHC-derived method implementations. Standalone deriving was already generating this code, but the documentation isn't talking about this explicitly. (It's saying "GHC does not restrict the form of the data type. Instead, GHC simply generates the appropriate boilerplate code for the specified class, and typechecks it" https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/deriving.ht…) Generated methods are always well-typed, and it's using `error` this way. We merely made non-standalone deriving to work similarly on empty data types, which shouldn't be a problem for anyone, IMO. So the thing you're complaining about was already there for a long time now. We just change some things for consistency and document it. (Also, this patch improves the error message which is always good) 2. I feel like if we force arguments, someone will come here and complain about it too. For example, currently this code works fine: `let g = g in g == g` where type of `g` is empty. If we force it in a non-threaded runtime it'd just loop. (I don't fully understand types-as-contract argument, can you point me to some resources about that?) I also don't care myself, but I feel like we should make this working same as standalone deriving, and document how it is working. Changing standalone deriving for empty types can potentially break existing code, so this may be our only option forward. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 17 Jun '15

17 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by simonpj): What if the method does not have an `a` argument? `Read` is one example, but there are probably others. `Ix` perhaps. Still, I really don't care myself. What I want is for someone to be able to look in the user manual and correctly predict what derived instance you'll get for an empty data type. If you and osa1 agree, I bet everyone else will too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 17 Jun '15

17 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by jpbernardy): simonpj: I'm not sure we're talking about the same thing. The whole point of my request was that, for any class C a where all methods have an `a` argument, it is trivial to implement a meaningful instance C Foo for any empty type Foo. In fact, I am guessing that the instance generator for Eq and Ord generate case statements. So, one could just let the normal instance generator run, to get function definitions with empty case statements. I see now that the instance for Read is fine (because failure is the only option), but that is more than I was asking. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 17 Jun '15

17 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by simonpj): I'm losing the will to live on this one! > Please, consider forcing the arguments in all these instances, before failing. Not necessarily easy, if the argument is `[a]`, say rather than `a`. This is so much a corner case that what osa1 has implemented seems fine to me. On (3) I suppose that either you can make the `TcDeriv` code check for `isEnumerationOrEmpty` (simplest), or fix the table-generation stuff. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 17 Jun '15

17 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by jpbernardy): I just read the proposed documentation on Phabricator. There is something that I think is dissatisfying with the implementation. As I understand it, the contract expressed by an empty data type is that there should be no value inhabiting it. So, if a piece of program ever builds one, the blame should be assigned to that piece of code. However, it does not appear that the current implementation does this. Eg: (error "oops" :: Foo) `compare` (error "oops" :: Foo) should fail with "oops", not "compare on empty data type Foo" Similarly, a Read instance makes no sense imho. Please, consider forcing the arguments in all these instances, before failing. Finally, I realise that my original report was misleading. I am sorry for that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function
by GHC 17 Jun '15

17 Jun '15

#1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 4258 | Blocking: Related Tickets: 8326 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by osa1): * cc: omeragacan@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1498#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 17 Jun '15

17 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): I think in the worst case we should be able to consider empty types as enums and fix #2578 in a later stage -- e.g. while generating the "table". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10534: Data families + Coercible = unsafeCoerce
by GHC 17 Jun '15

17 Jun '15

#10534: Data families + Coercible = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts #-} module A where import Data.Coerce data family DF a silly :: Coercible (DF a) (DF b) => a -> b silly = coerce }}} {{{ {-# LANGUAGE TypeFamilies #-} module B where import A newtype instance DF a = MkDF () unsafeCoerce :: a -> b unsafeCoerce = silly }}} I get {{{ [1 of 2] Compiling A ( A.hs, interpreted ) [2 of 2] Compiling B ( B.hs, interpreted ) Ok, modules loaded: A, B. }}} Eep! Happily, the fix is very very simple: `TyCon.isDistinctAlgRhs` should return `False` for `DataFamilyTyCon`s. This fix is already in-flight for HEAD in Phab:D968, but this ticket serves to correct this problem in 7.10.2 before the release. Patch coming very shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10534> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6