- Haskell-Cafe - Haskell.org

postgresql-pure released
by 岡本和樹 24 Oct '19

24 Oct '19

Hello. I published a library “postgresql-pure”, which is a PostgreSQL driver written in pure Haskell, a few days ago. This library is developed to aim: - to increase the performance on multi CPU core environments - to run on multi platform - to build it easier especially on Windows to remove the dependency on libpq, which is made by C - there is postgres-wire which is a fast implementation but it doesn't support Windows I confirmed that: - the performance was proportional to the number of cores - the performance on 12 cores were 28% better than postgres-wire, 300% better than postgresql-simple Both test cases are simple constant value queries like “SELECT 2147483647 :: int4, …” to decrease server's load. I'm writing a report about this development and I will send email again. Please try this and feel free to report issues. Best, Kazuki Okamoto Hackage: http://hackage.haskell.org/package/postgresql-pure GitHub: https://github.com/iij-ii/postgresql-pure

1 0

[CC2020] Paper registration deadline *extended*. Last CFP for the ACM SIGPLAN 2020 International Conference on Compiler Construction
by Gabriel Rodríguez Álvarez 23 Oct '19

23 Oct '19

ACM SIGPLAN 2020 International Conference on Compiler Construction (CC'20) co-located with CGO, PPoPP and HPCA San Diego, CA, USA February 22 - 23, 2020 https://conf.researchr.org/home/CC-2020 The ACM SIGPLAN 2020 International Conference on Compiler Construction (CC 2020) is interested in work on processing programs in the most general sense: analyzing, transforming or executing input programs that describe how a system operates, including traditional compiler construction as a special case. Original contributions are solicited on the topics of interest which include, but are not limited to: - Compilation and interpretation techniques, including program representation, analysis, and transformation; code generation, optimization, and synthesis; the verification thereof - Run-time techniques, including memory management, virtual machines, and dynamic and just-in-time compilation - Programming tools, including refactoring editors, checkers, verifiers, compilers, debuggers, and profilers - Techniques for specific domains, such as secure, parallel, distributed, embedded or mobile environments - Design and implementation of novel language constructs, programming models, and domain-specific languages CC 2020 is the 29th edition of the conference. From this year onwards, CC is an ACM SIGPLAN conference and will implement guidelines and procedures recommended by SIGPLAN https://www.sigplan.org. ============================================================================================== To subscribe to the CC announce mailing list, see cc_conference_announce(a)googlegroups.com To subscribe to the CC announce Twitter account, see @cc2020conf (https://twitter.com/cc2020conf) ============================================================================================== IMPORTANT DATES Abstract Submission: 25 October 2019 ***** EXTENDED ***** Paper Submission : 30 October 2019 Rebuttal : 4-6 December 2019 Artifact Submission: 13 December 2019 Author Notification: 24 December 2019 Final papers due : 15 January 2020 Conference : 22–23 February 2020 All submissions must be made electronically through the conference web site and include an abstract (100–400 words), author contact information, the full list of authors and their affiliations. Full paper submissions must be in PDF formatted printable on both A4 and US letter size paper. All papers must be prepared in ACM Conference Format using the 2-column acmart format. Papers should contain a maximum of 10 pages of text (in a typeface no smaller than 10 point) or figures, NOT INCLUDING references. There is no page limit for references and they must include the name of all authors (not {et al.}). Appendices are not allowed, but the authors may submit supplementary material, such as proofs or source code; all supplementary material must be in PDF or ZIP format. Looking at supplementary material is at the discretion of the reviewers. Submission is double blind and authors will need to identify any potential conflicts of interest with PC, as defined here: http://www.sigplan.org/Resources/Policies/Review/ (ACM SIGPLAN policy). Authors are encouraged to submit their artifacts for the Artifact Evaluation (AE). The Artifact Evaluation process is run by a separate committee whose task is to assess how the artifacts support the work described in the papers. To ease the organization of the AE committee, we kindly ask authors to submit their artifact at the latest 10 days after the rebuttal. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Additional information will be made available on the CC AE web page. Deadlines expire at midnight anywhere on earth. ORGANIZERS General Chair Louis-Noel Pouchet Colorado State University <pouchet AT colostate.edu> Program Chair Alexandra Jimborean Uppsala University <alexandra.jimborean AT it.uu.se> Artifact Evaluation Chairs Michel Steuwer University of Glasgow <Michel.Steuwer AT glasgow.ac.uk> Martin Kong University of Oklahoma Publicity Chair Gabriel Rodriguez University of A Coruna Web Chair Mihail Popov Uppsala University Steering Committee Bjorn Franke University of Edinburgh <bfranke AT inf.ed.ac.uk> Sebastian Hack Saarland University Manuel Hermenegildo IMDEA SW Institute and Technical U. of Madrid Peng Wu Huawei America Research Lab Ayal Zaks Intel and Technion, Israel Jingling Xue University of New South Wales, Australia Christophe Dubach University of Edinburgh Nelson J. Amaral University of Alberta Milind Kulkarni Purdue University Program Committee Apan Qasem AMD/Texas State University Bernhard Scholz University of Sydney Bettina Heim Microsoft Bilha Mendelson Optitura Brian Demsky UC Irvine Changhee Jung Purdue University Christian Schulte KTH EJ Park Los Alamos National Laboratory Delphine Demange Inria Dongyoon Lee Stony Brook University Fernando Magno Quintao Pereira UFMG Brazil Haowei Wu Google Manuel Hermenegildo IMDEA and T.U. Madrid Matin Hashemi Sharif University of Technology Michel Steuwer University of Glasgow Mila Dalla Preda University of Verona Nelson J. Amaral University of Alberta Philippe Clauss University of Strasbourg Pavlos Petoumenos University of Edinburgh Rumyana Neykova Brunel London Santosh Nagarakatte Rutgers University Sebastian Hack University of Saarland Tomofumi Yuki Inria Xu Liu College of William and Mary

1 0

Bristol Haskell Hackathon 2020
by Matthew Pickering 21 Oct '19

21 Oct '19

I have decided to organise an informal hackathon in Bristol at the start of next year. When 25th-26th January 2020 Where Merchant Venturers Building - University of Bristol Time 09:00 - 17:00 Anyone interested in Haskell is welcome to attend. Whether you are a beginner or an expert it would be great to meet you in Bristol. It is a no-frills hackathon, we’ll provide a room for hacking and wifi but expect little else! There will be no t-shirts, food, talks or other perks. The focus will be 100% on hacking and meeting other Haskell programmers. For further information about the event and how to register please refer to the dedicated page. https://mpickering.github.io/bristol2020.html Cheers, Matt

1 0

Re: [Haskell-cafe] Explicit approach to lazy effects For probability monad?
by Olaf Klinke 21 Oct '19

21 Oct '19

> It kind of seems like this can't work if >>= has type 'm a -> (a -> m b) > -> mb', assuming m a = (a,state). The second argument needs to have > type (m a -> m b) instead of (a -> m b), since the computation needs to > have access to the state produced by the first "m a" computation, in > order to (optionally) depend on the state thread for first computation. My earlier suggestion of using the pure reader monad is not useful for two reasons: (1) A single random number is shared among all sub-computations, which destroys statistical independence. (2) Multi-dimensional distributions arguably require more than a single floating point number to parametrize. Maybe the following two monads hint at a better way, although none of them exhibits the two desirable properties I suggested in my first reply. It seems that both exhibit the sequential nature that you want to avoid, if the underlying monad m is sequential (i.e. stateful). (a) The free monad over the reader functor. type Distribution a = Free ((->) Double) a = Pure a | Impure (r -> Free ((->) Double) a) This is a reader monad of functions (Double,Double,...,Double) -> a where the tuple length may be any finite number. -- @choose p@ chooses the first distribution with probability @p@. choose :: Double -> Distribution a -> Distribution a -> Distribution a choose p x y = Impure (\r -> if r <= p then x else y) -- Feed a random number generator into a distribution. -- You get to decide which monad that is. sample :: Monad m => m r -> Free ((->) r) a -> m a sample _ (Pure a) = pure a sample gen (Impure f) = (sample gen) =<< (fmap f gen) (b) A reader monad which passes copies of the random number generator around, not the generator state. Again, you get to choose which monad the random number generator lives in. type DistrT m a = ReaderT (m Double) m a ~ m Double -> m a -- 'chooseT' queries the random number generator once -- and then passes it down to either of the two choices. chooseT :: Monad m => Double -> DistrT m a -> DistrT m a -> DistrT m a chooseT p x y = ReaderT (\gen -> gen >>= (\r -> if r <= p then runReaderT x gen else runReaderT y gen)) sampleT = runReaderT :: DistrT m a -> m Double -> m a Apologies that I can not be any more helpful at the moment. But the topic really interests me, please do post any progress on haskell-cafe. Olaf

1 0

problem with servant and type constrains
by PICCA Frederic-Emmanuel 17 Oct '19

17 Oct '19

Hello, I have a type for my APi like this type SubscribeAPI a = "upload" :> ReqBody '[JSON] (JobSpecSub a) :> Post '[JSON] () type HomepageAPI = "homepage" :> QueryParam "id" Int :> Get '[HTML] Homepage type XdsMeAPI a = "xdsme" :> ReqBody '[FormUrlEncoded] XdsMeRequest :> Post '[JSON] (JobSpecSub a) type LogsAPI = "logs" :> ReqBody '[FormUrlEncoded] LogsRequest :> Post '[HTML] Html type ResumXdsAPI = "resumxds" :> ReqBody '[FormUrlEncoded] ResumXdsRequest :> Post '[HTML] Html type SessionIdAPI = "sessionid" :> ReqBody '[FormUrlEncoded] SessionIdRequest :> Post '[HTML] Html type MyApi a = SubscribeAPI a :<|> HomepageAPI :<|> XdsMeAPI a :<|> LogsAPI :<|> ResumXdsAPI :<|> SessionIdAPI myApi :: Job a => Proxy (MyApi a) myApi = Proxy When I try to write the handler for this API, I have this error message for the next code myAPIServer :: Job a => Beamline -> JobQueue a -> Server (MyApi a) myAPIServer beam jobQueue = handleJobSpec :<|> handleHomepage :<|> handleXdsMe :<|> handleLogs :<|> handleResumXds :<|> handleSessionId where handleJobSpec :: Job b => JobSpecSub b -> Handler () handleJobSpec jobSpec = liftIO $ enqueue jobSpec jobQueue • Couldn't match type ‘a’ with ‘b’ ‘a’ is a rigid type variable bound by the type signature for: myAPIServer :: forall a. Job a => Beamline -> JobQueue a -> Server (MyApi a) at src/Web.hs:235:1-66 ‘b’ is a rigid type variable bound by the type signature for: handleJobSpec :: forall b. Job b => JobSpecSub b -> Handler () at src/Web.hs:238:5-56 Expected type: JobQueue b Actual type: JobQueue a • In the second argument of ‘enqueue’, namely ‘jobQueue’ In the second argument of ‘($)’, namely ‘enqueue jobSpec jobQueue’ In the expression: liftIO $ enqueue jobSpec jobQueue • Relevant bindings include jobSpec :: JobSpecSub b (bound at src/Web.hs:239:19) handleJobSpec :: JobSpecSub b -> Handler () (bound at src/Web.hs:239:5) jobQueue :: JobQueue a (bound at src/Web.hs:236:18) myAPIServer :: Beamline -> JobQueue a -> Server (MyApi a) (bound at src/Web.hs:236:1) | 239 | handleJobSpec jobSpec = liftIO $ enqueue jobSpec jobQueue | ^^^^^^^^ I understand that I need to explain haskell that a ~ b. So my question is how can I do this :) thanks for your help Frederic

2 1

Re: [Haskell-cafe] stack: pandoc fails to build as dependency
by Olaf Klinke 17 Oct '19

17 Oct '19

>> [...] Can you get more info about what the linker error is? > Indeed, the linker exiting with status 1 without any stderr > message sounds like your linker is crashing. > take the last `ghc` invocation it makes, run that directly and add `-v` to that to get GHC's verbose output, which will show you the full linker invocation I don't know yet what causes the linker to crash, but I found a work-around: If I download any pandoc version, extract it and run `stack build` inside that directory, it is fine. So I created a symlink to that local pandoc dir inside my package root and made pandoc a part of my own package. Then everything builds all right. Hence there must be something going wrong when stack downloads and builds pandoc somewhere inside .stack-work/. It seems difficult to just run the last sub-command as Niklas suggests, because after the crash all the temporary files of the failed build are gone. But I'll keep investigating, thanks for the suggestions! Olaf

2 1

Windows, doctest and auxiliary FFI wrappers?
by Viktor Dukhovni 16 Oct '19

16 Oct '19

The Network.DNS library contains a bit of helper C-code for determining the default DNS servers on Windows. This code is linked in by Cabal, when building object code for the library on Windows. The library also has 140 "doctest" examples in the haddock comments, which I'd like to test on Windows via AppVeyor. I'm not having much luck making the dependency on the cbits visible to the GHCi invocations executed by "Test.Doctest". Does anyone have some experience getting this sort of thing to work? What I've tried: 1. Add "-liphlpapi" into the "doctest" command argument list, this proved necessary, but not sufficient. 2. Build a separate internal library (supported in Cabal 2.0 and later), which is a dependency of the main library and links in the C glue code, but this proved to be a significant rabbit hole... In fact approach 2 seems like the more promising one, but it runs into a substantial obstacles: a. Building internal libraries requires a "Simple" Cabal build, but the cabal-doctest package which automates compiling doctests, requires a "Custom" build type. :-( b. A Simple build, means abandoning cabal-doctest, and using "doctest" directly, but the new sandbox builds place package artefacts in locations that the command-line invoked by "Test.DocTest.doctest" does not know how to find. It appears that the "Custom" build from cabal-doctest is there for a good reason: it hooks into Cabal's build process, and has access to enough metatata, to generate wrapper code that invokes doctest with an argument list of the form: -XCPP -i -i<DISTDIR>/build/<ARCHDIR>/<GHCVER>/<PKG>-<VER>/build/autogen -i<DISTDIR>/build/<ARCHDIR>/<GHCVER>/<PKG>-<VER>/build -i<SRCDIR> -package-env=- -hide-all-packages -no-user-package-db -package-db=<CABALGLOBALSTORE>/<GHCVER>/package.db -package-db=<DISTDIR>/packagedb/<GHCVER> -package-db=<DISTDIR>/build/<ARCHDIR>/<GHCVER>/<PKG>-<VER>/package.conf.inplace -optP-include -optP<DISTDIR>/build/<ARCHDIR>/<GHCVER>/<PKG>-<VER>/build/autogen/cabal_macros.h ...visible packages... ...modules to doctest... which are needed for the extracted doctest fragments to find their dependencies. Hard-coding such arguments into the "Simple" build seems to work, but is hardly maintainable. I've not yet found an interface in the Cabal library that would divulge these magic strings as a function of the "pkg.cabal" file, something of the shape: cabalMagicGhcArgs :: FilePath -> IO [String] would make it possible to compute the arguments at runtime (rather than build-time) in a Simple build, without having to use a Custom build to machine-generate wrapper code. Other than the above, I'm out of ideas for now, any help much appreciated. -- Viktor.

1 1

Using GHCJS on firebase functions
by Ruben Astudillo 16 Oct '19

16 Oct '19

Dear list Has anyone used GHCJS on Firebase functions? How has it been your experience? Would you recommend it or offer al alternative?. -- -- Ruben -- PGP: 4EE9 28F7 932E F4AD

1 0

Avoiding code-duplication for what is roughly fmap
by Sebastiaan Joosten 15 Oct '19

15 Oct '19

Hi all, I'm writing a lot of code that looks like this: instance WhiteSpaced ClassItem where removeWS (Method a b c) = Method (removeWS a) (removeWS b) (removeWS c) removeWS (Declaration b) = Declaration (removeWS b) Typically, all the way at the end there's an instance that deviates (sometimes the deviating instances are somewhere in the middle). I need to do this for a lot of functions, and a lot of data types, and all I'm doing here is rewriting the data-type declaration in a different syntax (except that you do not know the types of a, b and c from the above). For the sake of maintainability, I want to avoid this code-duplication and focus only on the deviating instances. How to do better? I don't see how to use generics (in the hope of only writing 'instance WhiteSpaced ClassItem where' instead of the three lines above) for this: the types for a, b and c are all different here. Would this be easier with Template Haskell? (in the hope of only writing $(''something ClassItem) instead of the three lines above) My main concern is maintainability, an ideal solution is either a clear one-liner or a library import (in the same way that aeson allows me to use generics or Template Haskell without needing to know much about them). Other solutions are welcome too. Best, Sebastiaan

4 5

Re: [Haskell-cafe] Is join useful for every monad?
by Ruben Astudillo 15 Oct '19

15 Oct '19

On 14-10-19 16:45, Carter Schonwald wrote: > And while join is not at the moment in the Monad typeclass because of > newtype stuff Could you expand a bit on this? I remember this being on a Applicative-Monad proposal but I couldn't understand why it wasn't technically possible. -- -- Ruben -- PGP: 4EE9 28F7 932E F4AD

2 1