- Haskell-Cafe - Haskell.org

INLINE pragmas on unexported accessor functions
by Timotej Tomandl 17 May '17

17 May '17

Hello, I have the following accessor function, which is not exported out of the module: {-# INLINE left #-} left :: forall k. (Ord k) => Node k ->Node k left NullNode = NullNode left (Node _ l _) = l just for completness the type of Node is data Node k = NullNode | Node k (Node k) (Node k) I have determined upon inspecting the Core from ddump-simpl, that the INLINE pragma makes no difference, as such I would like to ask what's the convention/rule of thumb in the case of INLINE/INLINABLE pragmas on unexported accessor functions? Timo

1 0

Well-behaved instances, guards [was: [ghc-proposals/cafe] Partially applied type families]
by Anthony Clayden 16 May '17

16 May '17

> On Tue May 16 01:26:00 UTC 2017, Anthony Clayden wrote: (Might as well write it up, while it's fresh in my mind.) >> On Mon May 15 16:20:09 UTC 2017, Richard Eisenberg wrote: >> I do have to say all this talk has made me think more >> about apartness constraints in FC, at least. >> They might be a touch simpler than the current story. >> > The trouble is that the semantics for overlap > has never been spelled out. > (Nor, I suspect the criterion for > a 'well-behaved' set of instances. > I can volunteer that for you.) A set of instances is well-behaved wrt overlap iff for each pairing of instances, one of: 1. The instances are apart. (No overlap.) 2. One of the instances is strictly more specific. (Total overlap.) IOW the two instances unify, producing a substitution; and that substitution is exactly the more specific instance. 3. Neither instance is more specific (Partial overlap.) IOW the two instances unify, producing a substitution; and that substitution is more specific than either. And 3b. There is a third instance at exactly that substitution. So each instance becomes case 2 overlapping that third. Example: > class C a b > instance C Int b -- (A) > instance C Char b -- (B) apart from (A), case 1 > instance C Int Int -- (C) more specific than (A), case 2 > instance C a Bool -- (D) partial overlap to (A), case 3 > instance C Int Bool -- (E) intersect of (A), (D), case 3a > instance C Char Bool -- (E') 'cos (D) also overlaps (B) For a compiler to police case 3b is too hard: * It needs search for a suitable intersecting instance, so can't be validated instance-by-instance. * That intersect might be in a different module, so works against separate compilation. * That intersect (if it's declared), might itself not be well-behaved. * That intersect might not be needed. (Perhaps there's no call needing `C Int Bool`.) so it would be superfluous to declare it. (For this reason GHC doesn't look for such an instance until/unless it finds a use site.) * For the intersect, perhaps the needed definition is the same as one of the other instances. Say, `C Int Bool` defined same as `C Int b`, but different to `C a Bool`. There's no way to express that: you must repeat the code. These difficulties are somewhat relaxed for type families (not class instances): If the unifying substitution yields equal rhs's for the two equations, the instances are accepted. Example > type instance F Int b = b > type instance F a Int = a Overlap at `F Int Int`. Under either equation the result is `Int`, so this is accepted. I suspect that even with a total overlap, case 2; when GHC is trying to select the instance, it's in a state of nervous cluelessness as to the grounds/evidence for why to select an instance. Particularly if it is to reject the more specific instance: Is it sure some use site can never unify more specifically? This must be particularly hard for repeated type vars (non-linear patterns in the instance head). > instance C Bool (a, a) -- vs > instance C Bool (a, b) How do instance guards help? They eliminate the need to search for case 3a. A set of (possibly guarded) instances is well-behaved wrt overlap iff for each pairing of instances, one of: 1. They are apart. (No overlap.) 4. They overlap, so unify producing a substitution; And 4b. Under that substitution into the guards, the guards force the instances apart. Note no need to consider any other instances. Furthermore we can validate looking purely at the instance decls (including guards), we don't need to delay to possibly ambiguous uses. Re-work instances (A) to (E) above: > instance C Int b | b /~ Int -- (A) guard to de-overlap (C) > instance C Char b -- (B) apart, no need for guards > instance C Int Int -- (C) most specific, no guards > instance C a Bool | a /~ Int, -- (D) de-overlap (A) > a /~ Char -- also de-overlap (B) > -- instance C Int Bool -- (E) not needed, treat as (A) > -- instance C Char Bool -- (E') not needed, treat as (B) Show how the guards for (D) force it apart from (A): The instance heads unify to `C Int Bool`. Substitute {a ~ Int, b ~ Bool} into the guards. For (A) we get (Bool /~ Int) ==> True. For (D) we get (Int /~ Int, Int /~ Char) ==> False. So one guard (at least) is False. They're apart. The guards also drive the grounds/evidence for resolving overlapping heads. Suppose a use site wants `C Char Bool`. There's two eligible heads: (B), (D). Substitute wanted {a ~ Char, b ~ Bool} into the guards. None for (B). For (D) (a /~ Int, a /~ Char) ==> False. So select (B). And to take the repeated type var example. Declare: > instance C Bool (a, b) | a ~ b -- (F) > instance C Bool (a, b) | a /~ b -- (G) Suppose a use site wants ` C Bool (Int, b')`. That is, b' is a unification variable, not yet resolved. Substitute {a ~ Int, b ~ b'} into the guards. We have (F) (Int ~ b'); (G) (Int /~ b') Neither True; neither False. They do tell us we must improve b', to resolve the selection. Instance guards are to apply just as much for type instances. (So they can be distributed at associated types.) Example > type instance F Int b = b > type instance F a Bool | a /~ Int = a Rules for guards: a) The guards are a comma-sep list of equal (~) or apart (/~) comparisons. b) The comparands must be same-kinded. (I'll leave the poly kinded case for Richard ;-) c) Can only use type vars from the head. (I.e. not introduce extra vars, which contexts can do.) d) No type functions -- too hard, and not injective. e) Can use wildcard `_` as a type place-holder. f) Can use Type constructors to arbitrary nesting. As an example of d), the classic > type instance IsaFunction ((->) a b) = True > type instance IsaFunction c | c /~ ((->) _ _) = False Note the False case must match plain `Int` and `Maybe c'` and `Either e c'`. So putting this is valid but wouldn't be general enough: > type instance IsaFunction (c a b) | c /~ (->) = False AntC

1 0

GUI for Servant clients?
by Ivan Lazar Miljenovic 16 May '17

16 May '17

I have a project where I'm using Servant to write a server. There will be some admin tasks involved (predominantly manual account sign-up, to restrict who is allowed to access it), and it will be much easier for the actual administrators to do so with a visual interface of some kind (because I somehow don't see them being able to use curl ;-) Whilst I could try and integrate web pages for the admin tasks into the server, from a separation of concerns and security pen-testing point of view, it would be preferable to instead expose the admin tasks as authenticated endpoints and use a client for that. Is there anything close to having a relatively automated solution to "here is the Servant API types, here is the workflow it should follow, now give me some webpages" (which I could preferably either package up using threepenny-gui, Electron or just a few HTML files I can email to the project admins - who all run Windows - to use)? It doesn't have to look pretty, just work. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

2 1

Position of a constraint in a function's signature
by Al Zohali 16 May '17

16 May '17

Dear Cafe! I've encountered quite strange behaviour in GHC (v8.0.2) and I would like to ask you to give me a hint. Suppose we have the following functions: ---- foo :: (Show a) => Int -> a -> [String] foo n = replicate n . show bar :: Int -> (Show a) => a -> [String] bar n = replicate n . show baz :: Int -> a -> (Show a) => [String] baz n = replicate n . show ---- This won't compile, and that is ok. But if we add `RankNTypes` extension, this will compile and (:t) will give us the same signature for all three functions. There are two things I cannot get: 1) Why do this even compile? I saw constraints being defined either in the beginning of a signature or right after `forall` expression. I thought that it was a rule (or convention), but it's not. Is this way of declaring constraints (in the middle of a signature) discouraged or can be considered as a bug? 2) Even if this was supposed to be so, why was the constraint in `baz` hoisted to the top? There are at least two ways to interpret that signature: ---- baz :: Int -> a -> forall a. (Show a) => [String] baz :: forall a. (Show a) => Int -> a -> [String] ---- Is there any reason why the second one was chosen?

3 3

Partially applied type families
by Soham Chowdhury 15 May '17

15 May '17

Relatedly, there is a sketch of something like a "case construct" on Richard's blog, where he talks about a "type instance where" syntax that allows closed interdependent sets of family instances. Is that something that was later found to be infeasible? On Fri, May 12, 2017, 17:53 <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > Today's Topics: > > 1. Re: Fast JSON validation - reducing allocations (Arjen) > 2. Re: Fast JSON validation - reducing allocations (David Turner) > 3. Re: [ghc-proposals/cafe] Partially applied type families > (Anthony Clayden) > > > > ---------- Forwarded message ---------- > From: Arjen <arjenvanweelden(a)gmail.com> > To: David Turner <dct25-561bs(a)mythic-beasts.com>, Haskell Cafe < > haskell-cafe(a)haskell.org> > Cc: > Bcc: > Date: Fri, 12 May 2017 12:16:45 +0200 > Subject: Re: [Haskell-cafe] Fast JSON validation - reducing allocations > On Fri, 2017-05-12 at 10:48 +0100, David Turner wrote: > > On 12 May 2017 at 09:27, Arjen <arjenvanweelden(a)gmail.com> wrote: > > > Maybe this is a silly question, and please let me know why if so, > > > but: > > > > > > Has anyone thought about parallelizing it for multiple messages in > > > order to "produce garbage faster"? While reducing allocation will > > > make > > > the single validations faster, doing multiple ones might improve > > > the > > > throughput per GC ratio. This assumes that the amount of live data > > > in > > > the heap is small, making GC sort of constant time, and having > > > multiple > > > cores available. > > > > Not a silly question at all. Adding the following incantation: > > > > `using` parListChunk 100 rseq > > > > does quite happily spread things across all 4 cores on my development > > machine, and it's certainly a bit faster. To give some stats, it > > processes ~24 events between GCs rather than ~6, and collects ~2MB > > rather than ~500kB. The throughput becomes a lot less consistent, > > however, at least partly due to some bigger GC pauses along the way. > > As Ben's statistics showed, our allocation rate on one thread is > > around 4TBps, which is already stressing the GC out a bit, and > > parallelising it doesn't make that problem any easier. > > > > I know in the OP I said "we have a stream" (accidental MLK misquote) > > but in fact there are a bunch of parallel streams whose number > > exceeds the number of available cores, so we don't anticipate any > > enormous benefit from spreading the processing of any one stream > > across multiple cores: single-threaded performance is what we think > > we should be concentrating on. > > > > Cheers, > > > > David > > > Apologies for spamming, but if you want more mutator time between > garbage collections, try increasing the nursery size. I get a lot less > time in GC and also much less sync's on GC (according to -s). It seems > to reduce the execution time by a third using something -A8M or -A64M > (quite extreem). In a large program, this effect might be less. > > kind regards, Arjen > > > > > > > ---------- Forwarded message ---------- > From: David Turner <dct25-561bs(a)mythic-beasts.com> > To: Arjen <arjenvanweelden(a)gmail.com> > Cc: Haskell Cafe <haskell-cafe(a)haskell.org> > Bcc: > Date: Fri, 12 May 2017 11:24:23 +0100 > Subject: Re: [Haskell-cafe] Fast JSON validation - reducing allocations > On 12 May 2017 at 11:00, Arjen <arjenvanweelden(a)gmail.com> wrote: > >> Happy to read that you have more success than I with parListChunk. >> I expect(ed) the sparks to be cheap, so this might help if the various >> incoming streams are very unbalanced in length and/or message sizes. >> I agree that multi-processing a single stream does not make much sense >> if you already have multiple concurrent streams. >> >> Nice to see that adding on parallelism in Haskell (GHC) is that easy >> (in this case) and with a very good speed-up factor! >> >> kind regards, Arjen >> > > Ah, ok, this is strange. The production system is definitely faster with > the parallel strategy (on one stream) but my Criterion benchmarks are much > slower. I've updated the code and results on Github ( > https://github.com/DaveCTurner/json-validator) Probably not going to be > able to look at the parallel version much more, but thought you might like > a look. > > Cheers, > > > > > ---------- Forwarded message ---------- > From: Anthony Clayden <anthony_clayden(a)clear.net.nz> > To: haskell-cafe(a)haskell.org > Cc: > Bcc: > Date: Fri, 12 May 2017 22:46:45 +1200 > Subject: Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type > families > > 2 days ago Richard Eisenberg (and mniip) wrote: > > > ... > > On incremental improvements / the "half-baked" nature of > > type families: I agree completely. ... > ["half-baked" is Richard quoting mniip] > > > ... the weird place of type families in the language. > > It is my hope that Dependent Haskell will obviate > > a lot of these concerns, allowing us to deprecate > > type families as we know them > > (you would just use an ordinary function in types > > instead). > > I don't want to sidetrack the github discussion > on mniip's proposal. > https://github.com/ghc-proposals/ghc-proposals/pull/52 > > So please explain here in what way > type families are "half baked". > > The part of type families I find > hard to use and hard to reason about > is closed type families. > I'd be very happy to deprecate them, > if there was something that did overlaps better. > > >From what I can make out, though, > in Richard's Dissertation, > they can't be promoted to "ordinary functions > in types". > > If the closed equations were ordinary > functions in types, you could go: > > > type family F a b > > type instance F Int b = b > > type instance F a Bool | a /~ Int = a > > -- non-unifiability guard > > With no need for a closed sequence of choices. > > Is this the "case-like computations" > others talk about on the proposal? > > > AntC > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

2 1

eta-expansion and cost of extra thunk on ghc
by Ruben Astudillo 15 May '17

15 May '17

Dear list On a class, we recently discussed the join function for a (State s) value (we where implementation Monad passing through Functor) join :: State s (State s a) -> State s a join outstate = State $ \s0 -> let (innerstate, s1) = runState outstate s0 in runState innerstate s1 On this, we eta-expand outstate to in a sense "pattern match" on what we know about it. We were thinking on the cost of the extra wrapping we do here for this "pattern matching". Because eta-expanding is one a of the 3 primitive operations on lambda calculus, we concluded it should be free (modulo presence of seq). Is this true on ghc? -- -- Ruben

2 1

Why is Megaparsec treating these two operators differently?
by Jeffrey Brown 14 May '17

14 May '17

I used Text.Megaparsec.Expr to write a minimal (56 lines) 2-operator recursive parser. It's on github[1]. It outputs a binary tree of the following form: data AExpr = Var String | Pair AExpr AExpr deriving (Show) The operator table supplied to makeExprParser defines two operators, # and ##. ## binds after #, but both of them refer to the same function, the Pair constructor of the AExpr data type: aOperators :: [[Operator Parser AExpr]] aOperators = [ [ InfixN # symbol "#" *> pure (Pair) ] , [ InfixN # symbol "##" *> pure (Pair) ] ] The # operator works in isolation: > parseMaybe aExpr "a # b" Just (Pair (Var "a") (Var "b")) Parentheses work with the # operator: > parseMaybe aExpr "(a # b) # (c # d)" Just (Pair (Pair (Var "a") (Var "b")) -- whitespace added by hand (Pair (Var "c") (Var "d"))) And the # and ## operators work together as intended: > parseMaybe aExpr "a # b ## c # d" Just (Pair (Pair (Var "a") (Var "b")) -- whitespace added by hand (Pair (Var "c") (Var "d"))) But the ## operator in isolation does not parse! > parseMaybe aExpr "a ## b" Nothing [1] https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/howt… -- Jeff Brown | Jeffrey Benjamin Brown Website <https://msu.edu/~brown202/> | Facebook <https://www.facebook.com/mejeff.younotjeff> | LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown>(I often miss messages here) | Github <https://github.com/jeffreybenjaminbrown>

3 6

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 165, Issue 19
by Keith Ramsay 14 May '17

14 May '17

On 5/12/17, haskell-cafe-request(a)haskell.org <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Haskell IDE Engine users? (Alan & Kim Zimmerman) > 2. Fast JSON validation - reducing allocations (David Turner) > 3. Re: Fast JSON validation - reducing allocations (Bardur Arantsson) > 4. Re: Fast JSON validation - reducing allocations (David Turner) > 5. Re: Fast JSON validation - reducing allocations (Bardur Arantsson) > 6. Re: Fast JSON validation - reducing allocations (Eric Seidel) > 7. Re: Fast JSON validation - reducing allocations (Ben Gamari) > 8. Re: Fast JSON validation - reducing allocations (Ben Gamari) > 9. Re: Fast JSON validation - reducing allocations (David Turner) > 10. Re: Fast JSON validation - reducing allocations (Ben Gamari) > 11. Re: Fast JSON validation - reducing allocations (David Turner) > 12. Re: Fast JSON validation - reducing allocations (Arjen) > 13. Re: Fast JSON validation - reducing allocations (David Turner) > 14. Re: Fast JSON validation - reducing allocations (Arjen) > 15. Re: Fast JSON validation - reducing allocations (Arjen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 11 May 2017 16:02:17 +0200 > From: "Alan & Kim Zimmerman" <alan.zimm(a)gmail.com> > To: haskell <haskell-cafe(a)haskell.org> > Subject: [Haskell-cafe] Haskell IDE Engine users? > Message-ID: > <CANma%3DH9bVt9bY%3DPmTBy4kCrMGUVAdD1A_sWWmc96EazrkmM3Ug(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Stupid question, but is anyone using/integrating HIE into anything at the > moment? > > I am considering rearranging the internals to orient it toward being mainly > a Language Server Protocol backend , and I want to see who would be > affected. > > Alan >

1 0

natVal straight to Word#
by Timotej Tomandl 13 May '17

13 May '17

Hi, I am using type-level naturals constrained to be at max the size of Word#, as such I have found myself casting the type-level naturals first to Integer and then to Word# like this type MaxConstraint a=a<=MaxNat toNatural :: forall n. (MaxConstraint n,KnownNat n)=>Natural n toNatural = Natural (integerToWord (natVal (Proxy :: Proxy n))) where MaxNat is the hard-coded value of maxBound :: Word for now, type MaxNat=18446744073709551615 My data type and the constrained constructor for Natural are data Natural (x::Nat) where Natural :: (MaxConstraint x)=>{-# UNPACK #-} !Word# -> Natural x I have tried to eliminate the integerToWord cast from toNatural, yet I have failed at doing so. As such I would like to ask, if anyone has some insight, whether it is possible to eliminate this one step of indirection. The only option I came up with is writing GHC plugin to do this. Timo

4 3

Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families
by Anthony Clayden 13 May '17

13 May '17

> On Sat May 13 06:40:47 UTC 2017, mniip wrote3: >> On Fri, May 12, 2017 at 01:22:35PM -0400, Richard Eisenberg wrote: >> >> My interpretation of mniips use of this descriptor was .. > That is very much correct, but what I was exactly referring to was not > the necessary limitations of type families (such as inability of partial > application) but rather their unnecessary limitations. For example only > being able to pattern-match at the top-level, or, with > InjectiveTypeFamilies, lack of 'result arg1 -> arg2' type injectivity. Don't we get limited injectivity through type family calls appearing in Equality constraints? > class (F a b ~ c) => C a b c We might have: > type instance F Int b = b And a use site which gives (a ~ Int). Then we can improve via (b ~ c). >> I agree that closed type families are bizarre and perhaps a misfeature >> -- though I think they are a good incremental step toward something better. > Closed type families have proven very useful to me, ... Thanks mniip. Yes useful to me too. (As a major user of HList-alikes.) > so I don't agree with calling them a misfeature, ... I think there were plenty of people suggesting other ways to achieve the same end. If "something better" comes out of the experience, we've lost 7~8 years of opportunity. > however I can see where you're coming from : > throughout the entire language we enforce the notion that we > can't have a "proof of type inequality" and then > closed type families give us just that. I don't like calling it "type inequality". It's proof of non-unifiability. And the rules for that are easy to write down. (Admittedly a bit messy to apply in practice.) The key fact is that Oleg et al demonstrated how it worked way back in 2004. And it works in Hugs! I don't see what's so hard. > Indeed, their semantics could be made more apparent. Disequality guards make it blimmin obvious. As described in Sulzmann & Stuckey 2002. AntC

1 0