- ghc-tickets - Haskell.org

Re: [GHC] #7015: Add support for 'static'
by GHC 18 Sep '14

18 Sep '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Luite, much of what you say is cast in terms of an underlying implementation, whereas my blog post focuses as exclusively as possible on the ''specification'' of what the programmer sees. Can you recast your suggestions in those terms? For example: * What does it mean to say that "GHC should explicitly keep track of all static metadata"? How would a programmer be able to tell whether or not GHC did so. That is, what programmer-visible behaviour do you seek? * Again "It should be possible to build a list (like the Static Pointer Table) at link time for a library". This is presumably a statement about the implementation but again you must have in mind some user-visible behavior? What is it? * Again "Static names would propagate like typeclass instances". I don't really know what this means, but specifically how would a programmer know if this happened? Static names are not visible to the programmer in the design I suggest; I use them only so I can say something about a possible implementation. All the programmer sees is ordinary Haskell values and types (with one new type constructor, `StaticPtr`. * "`StaticName` should be reasonably robust..." Again, you must have in mind some user-visible behaviour. Here I think I do know what you might mean. If you have a client and server talking to one another, and you recompile one having made only small internal changes, it should still inter-work with the original client. Something like that perhaps? Clearly this isn't yet a precise statement and you might want to make it so. And so on. Do you see what I mean? On the question of "I think it would be really useful if there was a way to send type details with a more complete serialization of the construction", I don't understand well enough. I tried (perhaps inadequately) to describe a design in which type security was guaranteed without sending type representations or fingerprints at all. Of course, some higher-level guarantees might be gained by sending type reps, but that would be up to a client library built on top of the facilities GHC provides. Are you asking for any GHC support here, or simply saying something about what a client library might or might not chose to do? Sorry to be dense. Thanks Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #427: Random.StdGen slowness
by GHC 18 Sep '14

18 Sep '14

#427: Random.StdGen slowness -------------------------------------+------------------------------------- Reporter: remit | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: | Version: libraries/random | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * owner: rrnewton => ekmett -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/427#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #427: Random.StdGen slowness
by GHC 18 Sep '14

18 Sep '14

#427: Random.StdGen slowness -------------------------------------+------------------------------------- Reporter: remit | Owner: rrnewton Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: | Version: libraries/random | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: rrnewton (added) Comment: The "thunk-bomb" problem should be fixed in random 1.1. The redesign question is still, however, open. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/427#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8899: StdGen does not generate 0
by GHC 18 Sep '14

18 Sep '14

#8899: StdGen does not generate 0 ------------------------------------+------------------------------------- Reporter: novadenizen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `genRange` for `StdGen` returns `(0,2147483562)`. However, as far as I can tell, `StdGen` doesn't generate 0. This code performs 200 billion iterations of `next` on a `StdGen`. I ran it and it output `Nothing`. The probability that no 0 was generated by chance is approximately ''e^-200/2.147^'' =~ ''10^-40^''. {{{#!haskell import System.Random import Data.Int find0 :: StdGen -> Int64 -> Maybe Int64 find0 g0 n0 = aux g0 n0 where aux _ 0 = Nothing aux g r = let (v,g') = next g in if v == 0 then Just (n0 - r + 1) else aux g' (r-1) main :: IO () main = print $ find0 (mkStdGen 1234) 200000000000 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8899> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #4218: System.Random is way too lazy
by GHC 18 Sep '14

18 Sep '14

#4218: System.Random is way too lazy -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.1 Component: | Version: 6.12.3 libraries/random | Keywords: random stack Resolution: fixed | overflow Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 427, 7936 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * status: patch => closed * resolution: => fixed Comment: Shipped in random 1.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4218#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9602: compiling arithmoi with llvm 3.5.0-2.1 generates an LLVM compilation error
by GHC 18 Sep '14

18 Sep '14

#9602: compiling arithmoi with llvm 3.5.0-2.1 generates an LLVM compilation error -------------------------------------+------------------------------------- Reporter: ryantm | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hello. I know llvm 3.5.0 is not supported by GHC, but I thought it might be nice to have a report of a problem with it for the time when someone wants to start supporting it. I'm sorry if this is not a bug with GHC. I tried to compile arithmoi-0.4.1.1 via cabal install and here is the output received: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 $ cabal --version cabal-install version 1.20.0.3 using version 1.20.0.1 of the Cabal library $ uname -a Linux hostname 3.16.1-1-ARCH #1 SMP PREEMPT Thu Aug 14 07:40:19 CEST 2014 x86_64 GNU/Linux $ pacman -Q llvm llvm 3.5.0-2.1 $ cabal install arithmoi-0.4.1.1 Resolving dependencies... Configuring arithmoi-0.4.1.1... Building arithmoi-0.4.1.1... Preprocessing library arithmoi-0.4.1.1... [ 1 of 34] Compiling Math.NumberTheory.Primes.Sieve.Indexing ( Math/NumberTheory/Primes/Sieve/Indexing.hs, dist/dist-sandbox- f1ff1bf8/build/Math/NumberTheory/Primes/Sieve/Indexing.o ) You are using a new version of LLVM that hasn't been tested yet! We will try though... Alias must point to a definition i8* @"integerzmgmp_GHCziIntegerziType_Szh_static_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTypes_Izh_static_info$alias" Alias must point to a definition i8* @"base_GHCziReal_zdp1Integral_info$alias" Alias must point to a definition i8* @"stg_upd_frame_info$alias" Alias must point to a definition i8* @"base_GHCziReal_zdp1Real_info$alias" Alias must point to a definition i8* @"stg_ap_p_info$alias" Alias must point to a definition i8* @"base_GHCziNum_fromInteger_info$alias" Alias must point to a definition i8* @"base_GHCziReal_toInteger_info$alias" Alias must point to a definition i8* @"integerzmgmp_GHCziIntegerziType_integerToInt_info$alias" Alias must point to a definition i8* @"stg_ap_0_fast$alias" Alias must point to a definition i8* @"stg_ap_pp_info$alias" Alias must point to a definition i8* @"base_GHCziNum_zm_info$alias" Alias must point to a definition i8* @"stg_gc_unbx_r1$alias" Alias must point to a definition i8* @"base_GHCziReal_quotRem_info$alias" Alias must point to a definition i8* @"stg_sel_1_upd_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTypes_Izh_con_info$alias" Alias must point to a definition i8* @"stg_sel_0_upd_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTuple_Z2T_con_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTypes_ZC_static_info$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTypes_ZMZN_closure$alias" Alias must point to a definition i8* @"ghczmprim_GHCziTuple_Z0T_closure$alias" Alias must point to a definition i8* @"stg_newByteArrayzh$alias" Alias must point to a definition i8* @"stg_gc_unpt_r1$alias" Alias must point to a definition i8* @"arrayzm0zi5zi0zi0_DataziArrayziBase_UArray_con_info$alias" Alias must point to a definition i8* @"newCAF$alias" Alias must point to a definition i8* @"stg_bh_upd_frame_info$alias" Alias must point to a definition i8* @"base_GHCziST_runSTRep_info$alias" Alias must point to a definition i8* @"integerzmgmp_GHCziIntegerziType_smallInteger_info$alias" Alias must point to a definition i8* @"stg_ap_p_fast$alias" Alias must point to a definition i8* @"stg_ap_pp_fast$alias" LLVM ERROR: Broken module found, compilation aborted! Failed to install arithmoi-0.4.1.1 cabal: Error: some packages failed to install: arithmoi-0.4.1.1 failed during the building phase. The exception was: ExitFailure 1 }}} Ryan -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9602> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7015: Add support for 'static'
by GHC 18 Sep '14

18 Sep '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by luite): I agree with simonpj and rwbarton. My suggestion in the phab discussion (generating foreign exports) was merely something that could be done with the current tools, but now that the patch is going to be rewritten/improved there may be better options. Other than getting memory management sorted out, I think these are the minimum requirements to make it possible to implement static values properly on different backends: * GHC should explicitly keep track of all static metadata (hi files probably) * Static names would propagate like typeclass instances * It should be possible to build a list (like the Static Pointer Table) at link time for a library or program (and if desired, build a program that can produce this list at runtime) * `StaticName` should be reasonably robust against minor variations between compiles/backends * no backend/platform specific internal names * a source code location as an identifier for generated names is better than a simple counter * at least some simple safeguard against constructing an ill-typed heap object (like a type fingerprint) should be there As an aside, I think it would be really useful if there was a way to send type details with a more complete serialization of the construction (in terms of `Typeable`/`TypeRep` or similar) in the `StaticName` or at a higher level: * It would be possible to generate a more readable type error message if a fingerprint does not match (rather than using `show` on both sides) * Languages like Python and JavaScript could dynamically convert values * In conjunction with `GHC.Generics` or `Data.Data` one could use this to generate user interfaces that allow typesafe structured construction/editing of arguments (and dictionaries, when supported) And a final point on my wish list: It would be very useful if the `static` keyword for toplevel bindings would result in a `StaticName` that uses the original function name, rather than some generated name: {{{ #!haskell import qualified Data.Map as M -- this would guarantee that concat is in the static list concat :: [[a]] -> [a] concat = static (foldr (++) []) -- for functions that do pattern matching we could introduce a pragma {-# STATIC and #-} and :: [Bool] -> Bool and [] = True and (x:xs) = x && and xs -- or for exposing functions from other modules {-# STATIC M.fromList #-} }}} This would make it easier to have asymmetric CH programs, where one part is merely the callee, but does not include the code where the result from the call is used. I think this could also useful to implement a more flexible foreign exports mechanism for GHCJS, see https://github.com/ghcjs/ghcjs/issues/194 for some discussion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

17 Sep '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 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): I've made a major update to the wiki page. Here are a few things worth pointing out: In [wiki:InjectiveTypeFamilies#Proposedsyntax this section] I've listed all the syntax proposals made so far. I've also [http://www.haskell.org/pipermail/haskell-cafe/2014-September/116065.html mailed Haskell-cafe] so we can get some feedback from the community. I christened various flavours of injectivity as A, B and C :-) -- see [wiki:InjectiveTypeFamilies#Formsofinjectivity this section]. I will refer to them as such in the rest of this comment. I mailed Conal Elliot and he says he does not remember what was his use case for type families injective in only one argument. This means we only have use cases of the form A shown by Simon. Given that, I believe that it is best if we limit ourselves to implementing A. We can revise this design later if someone demonstrates compelling examples of B or C. I have outlined my idea for the algorithm that would verify users injectivity declarations in [wiki:InjectiveTypeFamilies#Implementationoutline this section]. Simon, please tell me if there are any misconceptions about how GHC's type inference works. After some thinking I am against inferring injectivity for closed type families - see my arguments in [wiki:InjectiveTypeFamilies#Inferringinjectivity this section]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:67> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7015: Add support for 'static'
by GHC 17 Sep '14

17 Sep '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Here's a comment from Phab that should feed into the design: The current implementation does not appear to keep the heap references alive correctly: {{{ {-# LANGUAGE StaticValues #-} module Main where import GHC.Ref import Control.Concurrent import System.Environment import System.Mem import System.Mem.Weak import Data.Numbers.Primes -- from Numbers -- Just a Ref to some CAF from another package so that we can deRef it when linked with -dynamic primes_ref :: Ref [Integer] primes_ref = static primes main = do as <- getArgs let z = primes!!(length as+200) print z performGC -- addFinalizer z (putStrLn "finalizer z") print z performGC threadDelay 1000000 print . fmap (!!300) =<< deRef primes_ref -- uncommenting the next line keeps primes alive and prevents the segfault -- print (primes!!300) }}} and {{{ $ ghc -dynamic -o primes primes.hs [1 of 1] Compiling Main ( primes.hs, primes.o ) Linking primes ... $ ./primes 1229 1229 Segmentation fault (core dumped) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7015: Add support for 'static'
by GHC 17 Sep '14

17 Sep '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Agreed. No way should the design mandate any particular implementation for `unStatic`! My current proposals are outlined here [blog:simonpj/StaticPointers]. There is haze around Plan A/B/C near the end, but I'm veering towards some variant of Plan A. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0