September 2020 - Haskell-Cafe

Implementing parallelism using actors. How to improve the code.
by Luc Duponcheel 10 Sep '20

10 Sep '20

-- Hello, I am Luc Duponcheel. -- I started as a Haskell programmer, -- went to Java for a living, -- naturally evolved to Scala, -- and, being retired now, -- went back to my first love ... -- I am working on a library -- _______ __ __ _______ -- / ___ /\ / /\ / /\ / ___ /\ -- / /__/ / / _____/ / / / /_/__ / /__/ / / -- / _____/ / / ___ / / / ___ /\ /____ / / -- / /\____\/ / /__/ / / / /__/ / / \___/ / / -- /_/ / /______/ / /______/ / /_/ / -- \_\/ \______\/ \______\/ \_\/ -- v1.0 -- Program Description Based Programming Library -- author Luc Duponcheel 2020 - ... -- I started writing code in Scala (presented it at several conferences). -- I encountered issues with the fact that lazyness is not the default evaluation strategy. -- I switched to Haskell. -- In short: the library is about pointfree categorical programming -- (you may wish to have a look at ( https://www.youtube.com/watch?v=23VEcabMk7k (warning low sound volume)) -- below is some code with comments (you can load the code in ghci) -- it works fine but I want to get rid of the extra type class parameters x and w -- I tried to get rid of x and w in two ways -- . using forall -- . using a GADT -- -- both approaches failed -- -- the relevant code changes that I tried are commented out -- they are underneath the code that follows -- the code -- specifies parallelism -- and -- implements it using a dummy version of the hakka library -- (see https://hackage.haskell.org/package/hakka-0.2.0/docs/src/Hakka-Actor.html) -- first I need some language extensions {-# LANGUAGE TypeOperators #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE GADTs #-} -- next I need some imports import Control.Monad.IO.Class import Control.Monad.Trans.Class import Control.Monad.Trans.State.Strict import Control.Monad.Trans.Cont -- next some useful generic code infixr `c` infixr `d` f `c` g = f . g (f `d` g) h = f `c` g h -- -- parallel specification -- -- note the extra type class parameters x and w -- type z && y = (z, y) class Parallel x w to where par :: (z `to` x) -> (y `to` w) -> (z && y) `to` (x && w) -- -- parallel implementation -- -- o msg stands for message -- o mnd stands for monad -- o rst stands for result -- -- -- three actors involved -- -- o reactor -- - reacts by using a continuation cont when both -- . an x result (at left) -- . a w result (at right) -- have been received -- -- o leftActor -- - acts to send an x result (at left) to reactor -- -- o rightActor -- - acts to send a w result (at right) to reactor -- -- reactor sends both leftActor and rightActor a message to let them act -- data ActorRef = ActorRef newtype ActorContext msg = ActorContext msg newtype ActorT msg mnd z = ActorT { runActorT :: StateT (ActorContext msg) mnd z } deriving (Functor, Applicative, Monad, MonadFail, MonadTrans, MonadIO) actor :: String -> (msg -> ActorT msg IO ()) -> ActorT msg IO ActorRef actor name messageHandler = undefined become :: (msg -> ActorT msg IO ()) -> ActorT msg IO () become messageHandler = undefined (!) :: ActorRef -> msg -> ActorT msg IO () actorRef ! message = undefined newtype ReactiveT msg rst mnd z = ReactiveT { runReactiveT :: ContT rst (ActorT msg mnd) z } deriving (Functor, Applicative, Monad, MonadFail, MonadIO) newtype KleisliT mnd z y = KleisliT { runKleisliT :: z -> mnd y } type ReactiveParallelT msg rst mnd = KleisliT (ReactiveT msg rst mnd) data Message x w = LeftReact x | RightReact w | LeftAct | RightAct type ReactiveActorBasedParallelT x w = ReactiveParallelT (Message x w) () IO runReactiveActorBasedParallelT = runContT `d` runReactiveT `d` runKleisliT instance Parallel x w (ReactiveActorBasedParallelT x w) where par z2x y2w = KleisliT (\case (z, y) -> ReactiveT (ContT (\cont -> actor "reactor" (\case LeftReact x -> become (\case RightReact w -> cont (x, w) ) RightReact w -> become (\case LeftReact x -> cont (x, w) ) ) >>= \reactorRef -> actor "leftActor" (\case LeftAct -> runReactiveActorBasedParallelT z2x z (\x -> reactorRef ! LeftReact x) ) >>= \leftActorRef -> actor "rightActor" (\case RightAct -> runReactiveActorBasedParallelT y2w y (\w -> reactorRef ! RightReact w) ) >>= \rightActorRef -> leftActorRef ! LeftAct >> rightActorRef ! RightAct ) ) ) -- class Parallel to where -- data Message = forall x. LeftReact x | forall w. RightReact w | LeftAct | RightAct -- data Message where -- LeftReact :: x -> Message -- RightReact :: w -> Message -- LeftAct :: Message -- RightAct :: Message -- type ReactiveActorBasedParallelT = ReactiveParallelT Message () IO -- instance Parallel (ReactiveActorBasedParallelT IO) where -- __~O -\ <, (*)/ (*) reality goes far beyond imagination

2 2

Re: [Haskell-cafe] Cannot update a field in a record with a polymorphic type.
by Olaf Klinke 10 Sep '20

10 Sep '20

I take it that in the expression (defaultY ∷ ∀ α. Monoid α ⇒ Y α) {y = "c"} the compiler is not smart enough to infer that the concrete value of α is irrelevant for the outcome and therefore rejects the program. The obligation here is to prove that the function λ x. x {y = "c"} :: ∀ α. Y α -> Y String is constant across all possible values of α, which I guess is undecidable for general one-parameter types? Or is there a free theorem saying that whenever a function has this general type signature, then the α cannot possibly be used? This certainly fails if Y has more type parameters that remain constant in the expression: A type class could distinguish the extra type parameters even if at the value level the result is constant across all α. Olaf

5 8

Re: [Haskell-cafe] Constraints as a moveable feast?
by Anthony Clayden 10 Sep '20

10 Sep '20

> On *Tue Sep 1 21:18:40 UTC 2020, ** Richard Eisenberg wrote:* *> *I see the core idea as a fairly straightforward generalization of the "Partial Type Constructors" work Ah. Now I see a bit more of what you're getting at. We want as if the type synonym were an associated type family with a most-general instance class Num a => CPoint a where type Point a instance Num a => CPoint a where type Point a = (a, a) The semantics to be as the PTC paper, such that expanding `Point a` always requires a `CPoint a` instance, which will in turn want a `Num a`. And the expansion to be immediate (as with type synonyms) so that the client can put `Point a` in instance heads, for example. > But I really don't know what it means to expand without adding parens. ... what about > *pointX :: Point a -> a* *> ... *We don't want that type to expand to (Num a => (a, a)) -> a Ok, it was your using fancy type operators that put me off. We can represent the AST (and show the need for parens) by reverting to prefix syntax, within H98: pointX :: (->) (Point a) a -- needs parens around (Point a) And yes my naieve syntactic expansion would give the type you show, wot we do not want. AntC

1 0

Counterintuitive ScopedTypeVariables behaviour
by Tom Ellis 08 Sep '20

08 Sep '20

I have just noticed that with ScopedTypeVariables one can write the following bizarre definition -- Inferred signature: -- add :: Num a => a -> a -> a add (x :: a) (y :: b) = x + y The reason for this behaviour is that > in all patterns other than pattern bindings, a pattern type > signature may mention a type variable that is not in scope; in this > case, the signature brings that type variable into scope. https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… and the justification is that > Bringing type variables into scope is particularly important for > existential data constructors But this leads to a rather puzzling user experience. Was it really not possible to design this extension in a way that would allow bringing new type variables into scope locally but not allow them to unify with other type variables from outer scopes? To be more concrete, what I would like to see is a design where `k` is allowed because the type `a` (bound within a pattern) does not need to unify with anything but `k2` is not allowed because `a` is forbidden to unify with `b`. `k3` would also be forbidden (the type variables called `a` are actually distinct) as would `k4` (the type variable for the inferred signature would be fresh and distinct from `a`). I believe this design might lead to much less puzzling behaviour. Would it be possible (within a new extension, of course) or have I overlooked something? Tom data T = forall a. MkT [a] k :: T -> T k (MkT [t::a]) = MkT t3 where (t3::[a]) = [t,t,t] data T2 a = MkT2 [a] k2 :: T2 b -> T2 b k2 (MkT2 [t::a]) = MkT2 t3 where (t3::[a]) = [t,t,t] k3 :: T2 a -> T2 a k3 (MkT2 [t::a]) = MkT2 t3 where (t3::[a]) = [t,t,t] k4 (MkT2 [t::a]) = MkT2 t3 where (t3::[a]) = [t,t,t]

5 13

Cannot update a field in a record with a polymorphic type.
by Ignat Insarov 06 Sep '20

06 Sep '20

Hello. I have a problem trying to do something very simple. Consider this conversation with GHC: λ data Y α = Y {y ∷ α} λ defaultY = Y {y = mempty} λ :type defaultY defaultY :: Monoid α => Y α λ :type defaultY {y = "c"} ∷ Y String <interactive>:1:1: error: • Ambiguous type variable ‘α0’ arising from a use of ‘defaultY’ prevents the constraint ‘(Monoid α0)’ from being solved. Probable fix: use a type annotation to specify what ‘α0’ should be. These potential instances exist: instance Monoid a => Monoid (IO a) -- Defined in ‘GHC.Base’ instance Monoid Ordering -- Defined in ‘GHC.Base’ instance Semigroup a => Monoid (Maybe a) -- Defined in ‘GHC.Base’ ...plus 7 others (use -fprint-potential-instances to see them all) • In the expression: defaultY In the expression: defaultY {y = "c"} :: Y String Why does this not work?

4 5

call tree of cost centers in a .prof file
by Marco Zocca 05 Sep '20

05 Sep '20

Hi all, I don't understand the tree-shaped visualizations produced by profiteur, profiterole and ghc-prof-flamegraph . Specifically, I initially thought that cost centers that are displayed closer to the leaves would be due to calls higher up in the tree, but that doesn't seem to be the case. Example; I've produced this basic visualization with ghc-prof and Data.Tree.drawTree (which mirrors qualitatively what flamegraph et al. produce) : MAIN 100.0 | +- Main.trained 100.0 | | | +- ER.ML.Classification.logreg 99.2 | | | | | +- ER.ML.Classification.irls 96.4 | | | | | | | +- ER.ML.Classification.hessianC 30.3 | | | | | | | | | +- ER.Math.Matrix.outerD 30.3 | | | | | | | | | | | `- Main.binMixtureData 29.8 | | | | | | | | | | | +- ER.Math.Random.SplitMix.mvNormalSM 28.8 | | | | | | | | | | | | | `- ER.Math.Matrix.matVec 28.2 | | | | | | | | | | | `- ER.ML.Common.centerDataWMEC 1.0 It looks fine down to level 4 (trained calls logreg, which calls irls, which calls hessianC, which calls outerD), and then it stops making sense (binMixtureData is not ever called by outerD). Could someone please shed some light on this? Thank you in advance

2 1

ANN: hledger-1.19
by Simon Michael 02 Sep '20

02 Sep '20

I'm pleased to announce hledger 1.19 ! hledger is a robust, cross-platform, plain text accounting tool, with command-line, terminal and web UIs. It is a modern and largely compatible reimplementation of Ledger CLI with many improvements. You can use it to track time, money, investments, cryptocurrencies, inventory and more. See: http://hledger.org http://plaintextaccounting.org HIGHLIGHTS: New aregister and codes commands, more powerful CSV conditional rules, new sql output format, consistently default to flat mode, better colour control, cashflow report customisable like the others, more number/date/regexp parsing/validation, more speed. See all changes at https://hledger.org/release-notes . Thanks to release contributors Stephen Morgan, Dmitry Astapov, Michael Sanders, Henning Thielemann, Martin Michlmayr, and Colin Woodbury. GETTING STARTED: Many install methods are described at http://hledger.org/download. Here are three ways to build from source: stack update; stack install --resolver=lts hledger-lib-1.19 hledger-1.19 hledger-ui-1.19 hledger-web-1.19 --silent or: cabal v2-update; cabal v2-install hledger-1.19 hledger-web-1.19 hledger-ui-1.19 or: curl -sO https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… less hledger-install.sh bash hledger-install.sh While building, peruse https://hledger.org/start For help, see http://hledger.org#help-feedback and join us on Freenode (#hledger, http://irc.hledger.org) or via Matrix (#freenode_#hledger:matrix.org, http://riot.hledger.org) New and old users, contributors, sponsors, and all feedback are most welcome! Best, -Simon

1 0

[ANN] compact-sequences-0.2.0.0
by David Feuer 02 Sep '20

02 Sep '20

I am pleased to release the second version of the compact-sequences package, now with deques! Changes: * Add deques. * Change operator precedence. * Add a test suite. Thanks to David Himmelstrup for setting up the test and CI framework. * Clean up internals somewhat. * Add a proof of amortized bounds for the stack implementation. Thanks, Li-Yao Xia. There are still plenty of things to work on, and help is always welcome. David Feuer

3 5

Constraints as a moveable feast?
by Anthony Clayden 01 Sep '20

01 Sep '20

There's the makings of a cute feature in a very old Haskell Language report. (With thanks to the 'Partial Type Constructors' 2019 paper for ferreting this out.) type Num a => Point a = (a, a) 1990 v1.0 Haskell report. Yes that's a type synonym with a constraint. I'll give their examples, though they don't really demonstrate the potential: origin :: Point Integer -- we get Num a => wanted then discharged for free origin = (0, 0) -- although the appearance of zero wants Num a anyway scale :: (Num a) => a -> Point a -> Point a -- seems wrong to give explicit Num a scale w (x,y) = (w*x, w*y) -- the above sig would be inferred anyway The feature disappeared without trace in the next year's Language report. I'm thinking we should be able to write scale :: a -> Point a -> Point a -- get Num a for free by: scale :: a -> (Num a => (a, a)) -> (Num a => (a, a)) -- expand the synonym -- this sig currently illegal scale :: Num a => a -> (a, a) -> (a, a) -- float the constraints out to the implicit forall So this isn't specific to type synonyms: in general allow prefixing constraints to any sub-term in a type; type inference floats them to the front of the signature. You can kinda get the effect today (so I don't think this is entirely whacky), by cunning use of dummies and term-level combinators: typePoint :: Num a => (a, a) typePoint = undefined scale w xy = const (undefined `asTypeOf` xy `asTypeOf` typePoint) (w `asTypeOf` fst xy) -- inferred scale :: Num a => a -> (a,a) -> (a,a) (Putting a dummy undefined on RHS to show there's nothing up my sleeves, because the actual expression would unify to the right type anyway.) You can get maybe cleaner code with PatternSignatures. But it's all workarounds in terms/expressions. I want to do the Right Thing and get it accepted as a stand-alone signature. A couple of caveats: * Haskell 1990 didn't have MultiParam Type Classes; * nor existential quant. So if a nested constraint mentions both an existential tyvar with narrow scope and a universally quant'd tyvar, can't float out that constraint, have to reject the sig. The constraint in `type Num a => Point a = ...` appearing to the left of the introduced type syn, is also reminiscent of DatatypeContexts, so we could similarly float out the constraints from those appearing within a sig(?) And this would be a way to put constraints on newtypes similarly(?) (Can't put constraints on those currently, because there's not really a data constructor to bind the class dictionary to. Haskell 1990 didn't have newtypes.) Or is there something deeply anti-System FC here? AntC

2 1

[ANN] Accelerate v1.3
by Trevor McDonell 01 Sep '20

01 Sep '20

Hi all, On behalf of the Accelerate team, I'm happy to announce the release of version 1.3 of Accelerate: http://hackage.haskell.org/package/accelerate-1.3.0.0 This release includes many quality-of-life improvements for defining and using your own data types in embedded code. A summary of these new features is included in this release announcement. Generic Instances of Elt and Arrays are now derivable via Generic for simple (non-recursive Haskell'98) data types: data Point = Point Float Float Float deriving (Generic, Elt) At the scalar level we now also support *sum* data types: data Object = Sphere Point Float | Triangle Point Point Point deriving (Generic, Elt) Pattern synonyms Pattern synonyms for creating and accessing data types can now be defined and used, which in practice makes GHC's type checker far less angry than the old method of lift and unlift (which still exists). Pattern synonyms are used in the same way as you would a regular data constructor. Included are synonyms for tuples up to 16-tuples (T2, T3...) as well as indices (Z_, ::., I1, I2...) and other standard data types (Just_, True_, etc.) Defining your own pattern synonyms for product types can be done via the overloaded Pattern synonym at both the scalar: pattern Point_ :: Exp Float -> Exp Float -> Exp Float -> Exp Point pattern Point_ x y z = Pattern (x, y, z) ...and array levels: data State = State (Vector Point) (Vector Float) deriving (Generic, Arrays) pattern State_ :: Acc (Vector Point) -> Acc (Vector Float) -> Acc State pattern State_ { positions, masses } = Pattern (positions, masses) Note the syntax of the last example, which also generates the two accessor functions positions :: Acc State -> Acc (Vector Point) and masses :: Acc State -> Acc (Vector Float). This syntax is of course also available for use in Exp patterns. Defining pattern synonyms can also be achieved with the following TemplateHaskell splice (which is required for sum data types): mkPattern ''Object Embedded pattern matching This release also introduces support for *embedded pattern matching* via the new match operator, which allows us to reuse Haskell's case syntax in embedded code: intersect :: Exp Ray -> Exp Object -> Exp Bool intersect ray = match \case Sphere_ c r -> ... Triangle_ a b c -> ... Packages This release consists of the following packages: - accelerate-1.3.0.0 - accelerate-llvm-1.3.0.0 - accelerate-llvm-native-1.3.0.0 - accelerate-llvm-ptx-1.3.0.0 - accelerate-fft-1.3.0.0 - accelerate-examples-1.3.0.0 - accelerate-blas-0.3.0.0 - accelerate-bignum-0.3.0.0 - accelerate-io-1.3.0.0 - accelerate-io-array-0.1.0.0 - accelerate-io-bmp-0.1.0.0 - accelerate-io-bytestring-0.1.0.0 - accelerate-io-cereal-0.1.0.0 - accelerate-io-JuicyPixels-0.1.0.0 - accelerate-io-repa-0.1.0.0 - accelerate-io-vector-0.1.0.0 - colour-accelerate-0.4.0.0 - containers-accelerate-0.1.0.0 - hashable-accelerate-0.1.0.0 - gloss-accelerate-2.1.0.0 - gloss-raster-accelerate-2.1.0.0 - lens-accelerate-0.3.0.0 - linear-accelerate-0.7.0.0 - mwc-random-accelerate-0.2.0.0 - cuda-0.10.2.0 - cufft-0.10.0.0 - cublas-0.6.0.0 - cusparse-0.3.0.0 - cusolver-0.3.0.0 - nvvm-0.10.0.0 Contributors Special thanks to those who contributed to this release: - Trevor L. McDonell (@tmcdonell <https://github.com/tmcdonell>) - Joshua Meredith (@JoshMeredith <https://github.com/JoshMeredith>) - Ivo Gabe de Wolff (@ivogabe <https://github.com/ivogabe>) - David van Balen (@dpvanbalen <https://github.com/dpvanbalen>) - Jaro Reinders (@noughtmare <https://github.com/noughtmare>) - Alex Lang (@alang9 <https://github.com/alang9>) - Paul Wilson (@statusfailed <https://github.com/statusfailed>) - @lennonhill <https://github.com/lennonhill> - Travis Whitaker (@TravisWhitaker <https://github.com/TravisWhitaker>) - Roger Bosman (@rogerbosman <https://github.com/rogerbosman>) - Robbert van der Helm (@robbert-vdh <https://github.com/robbert-vdh>) - Sam (@sam-340453 <https://github.com/sam-340453>) - Lars van den Haak (@sakehl <https://github.com/sakehl>) - Rinat Striungis (@Haskell-mouse <https://github.com/Haskell-mouse>) - Viktor Kronvall (@considerate <https://github.com/considerate>) - Tom Smeding (@tomsmeding <https://github.com/tomsmeding>) - Ryan Scott (@RyanGlScott <https://github.com/RyanGlScott>)

2 2