August 2017 - ghc-tickets

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 16 Aug '17

16 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): Replying to [comment:74 jscholl]: I have been trying to write something similar down in https://github.com /ghc-proposals/ghc-proposals/compare/master...phadej:bytearray-literals It has a different syntax, which I think makes more sense than double- hash. Ben have given some comments already (they are inline in proposal text, so I remember them). He is worried about ByteArray#s code size, and I'm proposing similar "let's rewrite them to Addr# when possible" approach. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:83> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14121: ghc master requires -XTypeInType where 8.2.1 does not
by GHC 16 Aug '17

16 Aug '17

#14121: ghc master requires -XTypeInType where 8.2.1 does not -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This was found while building https://hackage.haskell.org/package/foundation with ghc head. The following code is reduced from Basement.Primitive.Error: {{{ {-# LANGUAGE MagicHash, PolyKinds, RankNTypes #-} module FoundationRegression where import GHC.Prim import GHC.Types (RuntimeRep) error :: forall (r :: RuntimeRep) . forall (a :: TYPE r) . String -> a error s = raise# undefined }}} This compiles works with 8.2.1, but fails on master: {{{ $ /opt/ghc/8.2.1/bin/ghc -c FoundationRegression.hs $ /opt/ghc/head/bin/ghc -c FoundationRegression.hs FoundationRegression.hs:7:17: error: Variable ‘r’ used as both a kind and a type Did you intend to use TypeInType? | 7 | error :: forall (r :: RuntimeRep) . forall (a :: TYPE r) . String -> a | ^^^^^^^^^^^^^^^^^ }}} After adding a TypeInType language pragma the program is accepted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #3474: Add a strict variant of iterate to Data.List
by GHC 16 Aug '17

16 Aug '17

#3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: new Priority: normal | Milestone: 8.2.2 Component: libraries/base | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): I suppose a modification from `fold'` 's document is OK: -- | The strict version of 'iterate'. -- It ensures that each step of the iterating is forced to weak head normal form before next step, avoiding the collection of thunks that would otherwise occur. This is often what you want to strictly step a function which produces a single, monolithic result (e.g. (+1)). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3474#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14124: add shrink prim-op for other array type
by GHC 16 Aug '17

16 Aug '17

#14124: add shrink prim-op for other array type -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This issue arised in the recently PR to bring unified array interface to primitive: https://github.com/haskell/primitive/pull/64 . In that issue andrewthad ask if we want to keep `shrikArr` API. My guts feels that it's possible for other type of array as well since it's just the same closure overwrite thing. So i'm asking for adding such prim-op here. I suppose we should provide `getSizeOfXXX` prim-op which consume a state token for other array type as well since the array size is not referential transparent now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14124> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #3474: Add a strict variant of iterate to Data.List
by GHC 16 Aug '17

16 Aug '17

#3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: new Priority: normal | Milestone: 8.2.2 Component: libraries/base | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Can you suggest some language? I would be happy to add it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3474#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3474: Add a strict variant of iterate to Data.List
by GHC 16 Aug '17

16 Aug '17

#3474: Add a strict variant of iterate to Data.List -------------------------------------+------------------------------------- Reporter: mux | Owner: (none) Type: proposal | Status: new Priority: normal | Milestone: 8.2.2 Component: libraries/base | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by winter): * status: closed => new * resolution: wontfix => * milestone: Not GHC => 8.2.2 Comment: Today a friend asked me the exactly problem, i.e. why `iterate (+1) 1 !! 100000000` cost 8G ram. This is surprising because most people are expecting GC should chase the list and the whole computation should run in O(1) space. But as soon as i checked the definition of `iterate`, i realize it's no possible to run in O(1) space, we're simply not forcing the `f (f ... (f x))` chain at all. So i came to this ticket. Adding `iterate'` may not be enough: we have to add document to notify people to watch out! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3474#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 16 Aug '17

16 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): After thinking about this for a while, i think a better solution for literal problem is to overhaul the `OverloaddedStrings` extension, because the problem is created by it: without it we can't even use rewrite rules to get the `Addr#` at all. I think i will make a GHC proposal finally, but let me sketch a little bit on my idea: 1. Currently when `OverloaddedStrings` is enabled, we consider a string literal polymorphric by translating them to `fromString ...`, where `fromString` is a method from `IsString` type class. 2. This makes desugaring literal into `String` the first step in during literal compiling, and at this very step we choose to use `unpackCString# addr#` to desugar the literal. 3. Now we have a problem with the fixed desugaring scheme, it's not flexible enough to give arise a `ByteArray#` based representation, no matter what rewrite-rules are applied afterwards. 4. So i proposal to solve the problem directly at this language extension level, besides `IsString`, i propose to add following typeclass: {{{ class IsPlainAddr a where fromPlainAddr :: Addr# -> a class IsAsciiByteArray a where fromAsciiByteArray :: ByteArray# -> a class IsU8ByteArray a where fromU8ByteArray :: ByteArray# -> a -- maybe someone want utf-16 desugaring? we can add later }}} 5. Together with `IsString`, these typeclasses are special when `OverloaddedStrings` is enabled, we will try to find an instance of the type which we are overloading: If we have a `"Foo" :: Foo`, we will try to find a instance for `Foo` among these classes, the priority of those instances can have an arbitrary order as long as we document it clearly. 6. Once an instance is found, we do desugaring depending on the instance spec, and directly inject `fromXXX "xxx"#` into code, if the sourcecode codepoint can't be encoded with the instance spec, we issue a compile waring. 7. If we failed to find an instance from above, we issue an compile error. 8. Now a library author can choose to implement a type class which suit his/her need. 9. This solution can also be extended to handle `OverloadedLists`, e.g. we can add following typeclass for desugaring list literals: {{{ class IsIntList a where fromIntList :: ByteArray# -> a class IsWordList a where fromWordList :: ByteArray# -> a class IsInt8List a where fromInt8List :: ByteArray# -> a ... }}} 10. When `OverloaddedLists` is enabled, we will try to find an instance of these special classes, and transform the list into `ByteArray#` according to the instance spec, if there're overflowing we issue warnings. If later, people ask for new format of literal desugaring, we add new typeclasses and done, old code continue to work, and new code will got a compile error on old compilers. BTW. I think this is what we called "解铃还需系铃人" in chinese ; ) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:82> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 15 Aug '17

15 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Replying to [comment:74 jscholl]: > Thinking about the problem again I decided to try to add {{{ByteArray#}}} literals to GHC. The idea is the following: > - Use {{{"foo"##}}} as syntax for {{{ByteArray#}}}s. This is in essence my try for a {{{String#}}} type. > - Provide > {{{#!haskell > unpackStringLit# :: ByteArray# -> [Char] > {-# INLINE[1] unpackStringLit# #-} > unpackStringLit# ba# = > unpackCStringWithLen# (byteArrayContents# ba#) (sizeofByteArray# ba#) > }}} > - Compile {{{"foo"}}} as {{{unpackStringLit# "foo"##}}} > - Let rewrites fire in phase 2. > - In phase 1, inline {{{unpackStringLit#}}} and let rules rewrite it to {{{unpackCStringWithLen# "foo"# 3#}}} > - Thus most {{{ByteArray#}}}s should get eliminated and binary size should stay more or less the same. > - If someone rewrites something like {{{ByteString.pack (unpackStringLit# lit)}}}, the literal is not eliminated and emitted to the binary. Thus a {{{ByteString}}} literal can increase binary size. However, I think this is what we want because we save making a copy of the data. > - The downside is that turning optimization off causes the compiler to create a {{{ByteArray#}}} for every string literal instead of a c-string. GHCi will also allocate {{{ByteArray#}}}s instead of string literals directly. > The problem is, old `Addr#` unpacking differ from `ByteArray#` unpacking in that they are not the same encoding: they don't agree on how `\NUL` char get encoded, (at least I'm expecting `ByteArray#` is standard UTF-8 encoded). So you can't cast them with rewrite rules like that: you have to mention the encoding pitfall. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:81> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 15 Aug '17

15 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): I don't think it's a good idea to change the string literal desguaring: there're too many libraries rely on the old `Addr#` desugaring behaviour, changing it will break them. And null terminate modified UTF-8 strings are useful: for example a filepath literal. It's also more compact, which is why we choose it in the first place. So no matter what, i will ask that new desugaring literals should be added together with a new syntax, e.g. the primitive version has already differ in syntax: `##` vs `#`. I would propose adding a new syntax `""...""`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:80> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9352: Allow `State# s` argument/result types in `ccall` FFI imports
by GHC 15 Aug '17

15 Aug '17

#9352: Allow `State# s` argument/result types in `ccall` FFI imports -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: #9218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This ticket is to allowing code like {{{#!hs {-# LANGUAGE UnliftedFFITypes #-} {-# LANGUAGE MagicHash #-} module M where import GHC.Exts foreign import ccall unsafe "foo" c_foo :: Int# -> State# s -> State# s foreign import ccall unsafe "bar" c_foo :: Int# -> State# s -> (# State# s, Int# #) }}} See also discussion in #9218 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9352> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10