May 2017 - Haskell-Cafe

matrix package maintenance
by Daniel Díaz Casanueva 17 May '17

17 May '17

Hallo Haskell-Cafe! I am the author and maintainer of the matrix package: http://hackage.haskell.org/package/matrix https://github.com/Daniel-Diaz/matrix For several reasons, mostly time related, I can't give this package the attention it deserves. GitHub issues are not being properly taken care of, and development stopped long time ago. Instead of leaving the package in this state, I thought about giving maintenance powers to anybody interested in continuing this work, or even change its direction in any (reasonable) way. I know the package has some users, so maybe any of you wants to do it. Otherwise, I guess I should try to allocate some time to at least fix some of the issues posted in GitHub. Meanwhile, sorry for the long waiting time that I have imposed on the users of this package that have reported problems or submitted PRs. King regards, Daniel Díaz.

3 2

Type Instance Partiality [was: [ghc-proposals/cafe] Partially applied type families]
by Anthony Clayden 17 May '17

17 May '17

> On Mon May 15 16:20:09 UTC 2017, Richard Eisenberg wrote: > ... > See my recent draft paper (expanding on the "What are type families" blog post) here: > http://cs.brynmawr.edu/~rae/papers/2017/partiality/partiality.pdf .. > it's really proposing dropping type families in favor of functional dependencies > -- but only for partial type families. ... Thanks for the paper - hard going for me! Yes I can see the sense in grounding type family instances with class instances as Associated Types. I'm not finding it helpful to bring in Functional Dependencies. Your paper only mentions them towards the end [Related Work]; it might be "inspired by" FunDeps, but they don't appear in the paper as such. I'm also not finding it helpful to bring in Instance Chains [despite Garrett's involvement]. There's one major attractive feature of Instance Chains that you kinda mention ["negations" in Related Work], but which closed classes can't support. I see this as a major weakness of your proposal. > The key observation is this: partiality in types is bizarre, and we don't want it. ... Huh? Nearly all type families (and class instances) are partial. You perhaps mean "don't want it" as purist type-theoreticians(?) As a developer of applications I definitely do want it: I want to write instances only for 'sensible' patterns, and have the compiler catch usages not supported by declared instances. Your examples include many from HList: all of those are partial. I mean there's instances (eliding some details): > instance HOccurs e (HCons e l') -- found the element > instance (HOccurs e l') -- search the tail > => HOccurs e (HCons e' l') -- not this element There's deliberately not: > -- instance HOccurs e HNil -- Fail: not found Let alone: > -- instance HOccurs e (Maybe a) -- not an HList! Even if we rewrite to DataKinds, GHC has no knowledge that there's a closed set of type constructors. The only type family that usually is total is the type equality test (yielding a type-level Boolean), and your Introduction tells me that's problematic. sheesh > So, any time we use a partial type family, > you need to have a class constraint around. > The class constraint ensures that we evaluate the type family > only within its defined domain. OK. Good. > Now tied to classes, partial type families are more like > convenient syntax for functional dependencies. You perhaps mean the effect achieved by declaring > class (F a b ~ c) => C a b c where ... constraints with Type Families on a class context? OK yes that achieves the effect of FunDeps. And it's more convenient syntax. > There is also treatment of partial closed type families > via a new construct, closed classes > (somewhat like instance chains but weaker). As you predicted, I dislike closed classes even more than closed families. Let me explain what feature of Instance Chains you've left out. [Section 3.1.2 "Explicit Failure" of the 2010 paper] Sometimes I deliberately want there to be no instance for some specific pattern. I typically can't achieve that with Overlapping Instances. So: * Instance Chains have an explicit `Fail` case. [good] * HList has an instance with a Fail constraint. [clumsy] (I.e. an instance constraint to a class with no instance. See HOccursNot with class Fail in the HList paper section 6 at "Static look-up") * Type family instances (currently) don't have constraints, so this is hard work to arrange. IOW what's going on is _deliberately_ a partial type function. > > I expect AntC would prefer disequality guards over closed classes. Yes. Because I can 'precision control' which instances are available. Take HOccursNot (validates an HList to make sure some element does not occur, typically in combo with making sure the list has exactly one occurrence): > class HOccursNot e l -- no methods! use for constraint only > instance HOccursNot e HNil > -- instance omitted, see below > instance (HOccursNot e l') > => HOccursNot e (HCons e' l') | e /~ e' -- guarded Without disequality guards, the HList paper has to insert a bogus overlapping instance for a matched element type: > instance (Fail (TypeFound e)) => HOccursNot a (HCons e l') > ... The big problem with branched instances is that it was > awkward to describe the overlap between two branched instances. > AntC might argue that, if we just had disequality guards, > it would all be much simpler. He might be right. This is an important point; we must be careful. The rule for instances with guards is: no overlaps! (That is, after taking guards into account.) That is how "to describe the overlap between two branched instances": there is no overlap. The heads might overlap, but the guards force them apart. Any sort of attempt to control overlap can be stymied by imports. A closed set of instances avoids that. (I would say at cost of needing to read all preceding instances to understand the conditions for a later instance.) With guards, I can attach all the conditions to the instance itself. And then compare to each other instance to validate no overlaps -- even for imports. How would I describe the semantics, within the formalism in your partiality paper? Section 6.3: "we use axioms [xi] to witness type family reductions. That is, if there is an equation `type F Int = Bool` in scope, then we have an axiom [xi] that proves `F Int ∼ Bool`." Ok for in scope > type F a | a /~ Int = Char we get an axiom: (F a ~ Char <=> a /~ Int) -- bi-implication. [Unashamedly stolen from the CHR work.] This axiom system is coherent providing there are no other equations for `F`. Note also with disequalities we get an inference rule: a /~ b, b ~ c ===> a /~ c AntC

1 0

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=H9bVt9bY=PmTBy4kCrMGUVAdD1A_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