- Haskell-Cafe - Haskell.org

Call for papers: DBPL 2019
by Alvin Cheung 04 Jan '19

04 Jan '19

The 17th International Symposium on Database Programming Languages https://pldi19.sigplan.org/track/dbpl-2019-papers Phoenix, Arizona, USA June 23, 2019 hosted as part of PLDI 2019 Call for Papers For over 25 years, DBPL has established itself as the principal venue for publishing and discussing new ideas at the intersection of databases and programming languages. Many key contributions in query languages for object-oriented data, persistent databases, nested relational data, and semistructured data, as well as fundamental ideas in types for query languages, were first announced at DBPL. Today, this creative research area is broadening into a subfield of data-centric computation, currently scattered among a range of venues. DBPL is an established destination for such new ideas and solicits submissions from researchers in databases, programming languages or any other community interested in the design, implementation or foundations of data-centric computation. Scope ----- DBPL solicits practical and theoretical papers in all topics at the intersection of databases and programming languages. Papers emphasizing new topics or emerging areas are especially welcome. Suggested, but not exclusive, topics of interest for submissions include: - Compiling Query Languages to Modern Hardware - Data-Centric Programming Abstractions, Comprehensions, Monads - Data Integration, Exchange, and Interoperability - Data Synchronization and Bidirectional Transformations - Declarative Data Centers (e.g., distributed query processing, serverless computing platforms, social computing platforms, etc) - Emerging and Nontraditional Data Models - Language-Based Security in Data Management - Language-Integrated Query Mechanisms - Managing Uncertain and Imprecise Information - Metaprogramming and Heterogeneous Staged Computation - Programming Language Support for Data-Centric Programming (e.g., databases, web programming, machine learning, etc) - Query Compilation and In-memory Databases - Query Language Design and Implementation - Query Transformation and Optimization - Schema Mapping and Metadata Management - Semantics and Verification of Database Systems - Stream Data Processing and Query Languages - Type and Effect Systems for Data-Centric Programming Author Guidelines ----------------- Prospective authors are invited to submit full papers in English presenting original research. Submitted papers must be unpublished and not submitted for publication elsewhere. Submissions should be no more than 10 pages long, excluding references, in the two-column ACM proceedings format, following PLDI’s formatting requirements (https://pldi19.sigplan.org/track/pldi-2019-papers#Call-for-Papers) Each submission should begin with a succinct statement of the problem and a summary of the main results. Authors may provide more details to substantiate the main claims of the paper by including a clearly marked appendix at the end of the submission, which is not included in the page limit and is read at the discretion of the committee. At least one author of each accepted paper must attend the symposium to present their work. Short papers of at most 4 pages (same format as long papers) describing work in progress, demos, research challenges or visions are also welcome. Accepted short papers may be included or excluded from the formal proceedings, whichever the author(s) prefer. Full and short papers are both due on the deadline, February 15, 2019. Instructions on how to submit will be posted on the symposium website noted above. Review is single-blind, so authors do not need to anonymize their submissions. PC submissions are allowed, except for the co-chairs. Important Dates --------------- - Paper Submission: February 15, 2019 - Notification: March 29, 2019 - Final versions due: April 16, 2019 - Symposium: June 23, 2019 Proceedings ----------- Accepted papers will appear as part of the PLDI Proceedings for DBPL 2019. Program Committee ----------------- *Program Co-Chairs* Alvin Cheung, University of Washington Kim Nguyễn, Université Paris-Sud *Program Committee* William Cook, University of Texas at Austin Vasiliki Kalavri, ETH Harshad Kasture, Oracle Oleg Kiselyov, University of Tsukuba Sam Lindley, University of Edinburgh Tiark Rompf, Purdue University Stefanie Scherzinger, OTH Regensberg Amir Shaikhha, EPFL / University of Oxford Avi Shinnar, IBM Guido Wachsmuth, Oracle Melanie Wu, Pomona College History ------- The 17th Symposium on Data Base Programming Languages (DBPL 2019) continues the tradition of excellence initiated by its predecessors in Roscoff, Finistere (1987), Salishan, Oregon (1989), Nafplion, Argolida (1991), Manhattan, New York (1993), Gubbio, Umbria (1995), Estes Park, Colorado (1997), Kinloch Rannoch, Scotland (1999), Marino, Rome (2001), Potsdam, Germany (2003), Trondheim, Norway (2005), Vienna, Austria (2007), Lyon, France (2009), Seattle, Washington (2011), Riva del Garda, Italy (2013), Pittsburgh, Pennsylvania (2015), Munich, Germany (2017). DBPL was affiliated with VLDB from 1999-2013 and in 2017. In 2015, it is affiliated with SPLASH for the first time and in 2019, it is affiliated with PLDI for the first time.

1 0

Concordium is hiring
by Bas Spitters 03 Jan '19

03 Jan '19

Concordium is the first ID/KYC ready blockchain network. Concordium focuses strongly on software quality and uses languages such as haskell, rust and Coq. There are a number of positions available at the offices in either Aarhus, Zurich, London and Marbella. In exceptional cases is off-site work possible. There is a preference for people with a relevant PhD or master's degree. https://www.concordium.com/careers/ In particular, the Concordium Aarhus office has a strong background in functional programming and type theory, and is looking to strengthen this team. There is a tight collaboration with the scientists at the Concordium Blockchain Research Center at Aarhus University. The center is also advertising several PhD and postdoc positions. https://www.iacr.org/jobs/#1717

1 0

Maybe type filtered
by Damien Mattei 03 Jan '19

03 Jan '19

i had filtered a [Maybe Text] type to remove Nothing from the list and now i want to put the result in a [Text] type but the compiler complains about the incompatible type : (bd_rows_WDS :: [Only (Maybe Text)]) <- query conn qry_head_WDS (Only (name::String)) -- remove the records having N°BD NULL let fltWDS :: [Only Text] = Prelude.filter (\(Only a) -> case a of Nothing -> False Just a -> True) bd_rows_WDS Prelude> :load UpdateSidonie [1 of 1] Compiling Main ( UpdateSidonie.hs, interpreted ) UpdateSidonie.hs:282:33: error: • Couldn't match type ‘Maybe Text’ with ‘Text’ Expected type: [Only Text] Actual type: [Only (Maybe Text)] • In the expression: Prelude.filter (\ (Only a) -> case a of Nothing -> False Just a -> True) bd_rows_WDS In a pattern binding: fltWDS :: [Only Text] = Prelude.filter (\ (Only a) -> case a of Nothing -> False Just a -> True) bd_rows_WDS In the expression: do conn <- connect defaultConnectInfo {connectHost = "moita", connectUser = "mattei", connectPassword = "sidonie2", connectDatabase = "sidonie"} (rows :: [(Text, Double)]) <- query_ conn "SELECT Nom,distance FROM AngularDistance WHERE distance > 0.000278" (names :: [Only Text]) <- query_ conn "SELECT Nom FROM AngularDistance WHERE distance > 0.000278" let resLstNames = Prelude.map fromOnly names .... | 282 | let fltWDS :: [Only Text] = Prelude.filter (\(Only a) -> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Failed, no modules loaded. how can id do the type conversion,now i'm sure there is no more Nothing values?

3 3

remove Maybe
by Damien Mattei 03 Jan '19

03 Jan '19

i had filtered a [Maybe Text] type to remove Nothing from the list and now i want to put the result in a [Text] type but the compiler complains about the incompatible type : (bd_rows_WDS :: [Only (Maybe Text)]) <- query conn qry_head_WDS (Only (name::String)) -- remove the records having N°BD NULL let fltWDS :: [Only Text] = Prelude.filter (\(Only a) -> case a of Nothing -> False Just a -> True) bd_rows_WDS Prelude> :load UpdateSidonie [1 of 1] Compiling Main ( UpdateSidonie.hs, interpreted ) UpdateSidonie.hs:282:33: error: • Couldn't match type ‘Maybe Text’ with ‘Text’ Expected type: [Only Text] Actual type: [Only (Maybe Text)] • In the expression: Prelude.filter (\ (Only a) -> case a of Nothing -> False Just a -> True) bd_rows_WDS In a pattern binding: fltWDS :: [Only Text] = Prelude.filter (\ (Only a) -> case a of Nothing -> False Just a -> True) bd_rows_WDS In the expression: do conn <- connect defaultConnectInfo {connectHost = "moita", connectUser = "mattei", connectPassword = "sidonie2", connectDatabase = "sidonie"} (rows :: [(Text, Double)]) <- query_ conn "SELECT Nom,distance FROM AngularDistance WHERE distance > 0.000278" (names :: [Only Text]) <- query_ conn "SELECT Nom FROM AngularDistance WHERE distance > 0.000278" let resLstNames = Prelude.map fromOnly names .... | 282 | let fltWDS :: [Only Text] = Prelude.filter (\(Only a) -> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Failed, no modules loaded. how can id do the type conversion,now i'm sure there is no more Nothing values?

2 1

MVar considered harmful
by Станислав Черничкин 02 Jan '19

02 Jan '19

Recently I had an interesting discussion on MVars with cats-effect library designers. Cats-effect brings MVar synchronization primitive along with other IO stuff to the Scala programming language. I tried to persuade them to include some Control.Concurrent.MVar’s functions to the library but has failed completely. Moreover, now I think that MVar is a poor choice for basic synchronization primitive. Your may find discussion here https://github.com/typelevel/cats-effect/issues/451 and event try to advocate, tl;dr. Anyway, what is so wrong with MVar? 1. It’s complex. Each MVar has 2 state transitions, each may block. 2. It does not play well in presence of asynchronous exceptions. More specifically, `take` and `put` operations should be balanced (each `take` must be followed by `put`) this force programmer to mask asynchronous exceptions during the MVar acquisition and since `take` function may block, this will delay task cancelation. Well, you may argue what the `takeMVar` function is actually interruptible, but I’m going to show an easier approach which renders interpretability magic unnecessary. What could be the sensible alternative? Guy from the cats-effect suggested me IVar + atomic reference (IORef). This pattern separates concern of blocking (synchronization) from the atomic mutation. So everything can be represented as atomic reference with IVar inside. Just look at this beautiful mutex implementation https://github.com/ovotech/fs2-kafka/blob/master/src/main/scala/fs2/kafka/i… (By ”beautiful” I mean approach itself of course, but not the Scala’s syntax. Scala is one of most ugliest girls after C++ I was forced to date with by my employer for money. Thankfully he didn’t force me to do the same things with her grandma Java). For people who don’t read Scala, the approach is fairly simple. Each thread which want to touch mutex, will create IVar, atomically swap it in the IORef masked (note, that IORef’s operations non-blocking), unmask and wait for previous become available IVar *unmasked*. Then it will either perform it’s operations or fail due to the interruption or exception and trigger newly installed IVar anyway. It just works. Without any «interruptible» magic. So, which benefits can we get? 1. Simpler implementation of basic primitives. Obliviously IORef is fairly simple. IVar is also mind be simpler than MVar, and possibly faster (just “possibly”, I don’t know how it’s implemented, but I guess lesser state transitions implies less logic). 2. Simplified deadlock analysis. Really, we have only IVar with only one state transition and only one potentially blocking operation. 3. Magicless support of interruptions. We don’t need to separate mask/uninterruptibleMask anymore, because all updates are non-blocking, and all waits are unmasked.

10 15

Jan 2019- Membership of the Group
by William Fearon 01 Jan '19

01 Jan '19

1 0

A few questions about unsafe IO
by Qingbo Liu 31 Dec '18

31 Dec '18

Dear Cafe, I am reading an article on HaskellWiki about unsafe IO[1]. It gives the guideline about usage of unsafeDupablePerformIO: "If you need extra speed, and it's acceptable for the action to be performed multiple times, and it's acceptable if this action is canceled halfway through its execution, use unsafeDupablePerformIO.” Inside `ByteStirng` module[2], I noticed that when converting [Char] to ByteString, it uses unsafeDupablePerformIO to allocate space for the ByteString, as the following code shows (important information highlighted): packChars :: [Char] -> ByteString packChars cs = unsafePackLenChars (List.length cs) cs : unsafePackLenBytes :: Int -> [Word8] -> ByteString unsafePackLenBytes len xs0 = unsafeCreate len $ \p -> go p xs0 where go !_ [] = return () go !p (x:xs) = poke p x >> go (p `plusPtr` 1) xs unsafeCreate :: Int -> (Ptr Word8 -> IO ()) -> ByteString unsafeCreate l f = unsafeDupablePerformIO (create l f) -- | A way of creating ByteStrings outside the IO monad. The @Int@ -- argument gives the final size of the ByteString. -- | Create ByteString of size @l@ and use action @f@ to fill it's contents. create :: Int -> (Ptr Word8 -> IO ()) -> IO ByteString create l f = do fp <- mallocByteString l withForeignPtr fp $ \p -> f p return $! PS fp 0 l {-# INLINE create #-} -- | Wrapper of 'mallocForeignPtrBytes' with faster implementation for GHC -- mallocByteString :: Int -> IO (ForeignPtr a) mallocByteString = mallocPlainForeignPtrBytes {-# INLINE mallocByteString #-} The doc of `mallocPlainForeignPtrBytes`, however, explicitly says that no finalizer is added for the allocated memory. So my question is: would not the allocation code in ByteString module cause memory leaks? The doc of `unsafeDupablePerformIO` mentions that it "duplicated IO actions is only run partially, and then interrupted in the middle without an exception being raised”. Thus, it might happen that we have already allocated the memory but then the action is interrupted, without reclaiming the memory. [1] https://wiki.haskell.org/Evaluation_order_and_state_tokens [2] http://hackage.haskell.org/package/bytestring-0.10.8.2/docs/src/Data.ByteSt… Best Regards, Qingbo Liu

2 2

Taking over the udev package
by Leif Warner 30 Dec '18

30 Dec '18

I'm offering to take over the "udev" package on hackage. I have some code which depends on it, as well as a PR to allow it to build on GHC 8.4, among other things: https://github.com/pxqr/udev/pull/5 It looks like the author, Samvel Truzyan, has been inactive on GitHub and Twitter for the past couple of years. Ilya Portnov might also be a good candidate to maintain this package - Ilya has the wacom-daemon package on hackage which depends on udev, and also has previously submitted a PR which has been merged to the udev package. -Leif Warner

1 0

Fwd: IO monad use
by Damien Mattei 29 Dec '18

29 Dec '18

---------- Forwarded message --------- From: Damien Mattei <damien.mattei(a)gmail.com> Date: Sat, Dec 29, 2018 at 9:46 AM Subject: IO monad use To: Damien MATTEI <damien.mattei(a)gmail.com> again an annoying error with my code, i want to apply sort of MAP on list resut of my database IO accessed extracting info with another query, queries works both but i can not MAP or if i can i do not know how to SHOW the result, here is the code: lstNamesBD <- mapM (\(Only name) -> do let nameStr = Text.unpack name bd <- getBD conn nameStr (nameStr,bd)) names it fails to compile with this error: Prelude> :load UpdateSidonie [1 of 1] Compiling Main ( UpdateSidonie.hs, interpreted ) UpdateSidonie.hs:203:33: error: • Couldn't match type ‘(,) String’ with ‘IO’ Expected type: IO (Maybe Float) Actual type: (String, Maybe Float) • In a stmt of a 'do' block: (nameStr, bd) In the expression: do let nameStr = unpack name bd <- getBD conn nameStr (nameStr, bd) In the first argument of ‘mapM’, namely ‘(\ (Only name) -> do let nameStr = ... bd <- getBD conn nameStr (nameStr, bd))’ | 203 | (nameStr,bd)) | ^^^^^^^^^^^^ Failed, no modules loaded. if i code like this show does not know how to display result: let lstNamesBD = Prelude.map (\(Only name) -> do let nameStr = Text.unpack name bd <- getBD conn nameStr res <- (nameStr,bd) res) names putStr "lstNamesBD =" putStrLn $ show lstNamesBD *Main> :load UpdateSidonie [1 of 1] Compiling Main ( UpdateSidonie.hs, interpreted ) UpdateSidonie.hs:193:16: error: • No instance for (Show (IO (Maybe Float))) arising from a use of ‘show’ • In the second argument of ‘($)’, namely ‘show lstNamesBD’ In a stmt of a 'do' block: putStrLn $ show lstNamesBD In the expression: do conn <- connect defaultConnectInfo {connectHost = "moita", connectUser = "mattei", connectPassword = "sidonie2", connectDatabase = "sidonie"} (rows :: [(Text, Double)]) <- query_ conn "SELECT Nom,distance FROM AngularDistance WHERE distance > 0.000278" (names :: [Only Text]) <- query_ conn "SELECT Nom FROM AngularDistance WHERE distance > 0.000278" let resLstNames = Prelude.map fromOnly names .... | 193 | putStrLn $ show lstNamesBD | ^^^^^^^^^^^^^^^ Failed, no modules loaded. help me please

2 5

Re: [Haskell-cafe] About understanding FunBind in haskell-src-exts.
by Magicloud Magiclouds 29 Dec '18

29 Dec '18

Hi, I can see the case of one FunBind contains multiple Matches, like this one. But I cannot see why the "name" (isJust) is in Match, instead of FunBind. Are there cases other than yours that a few functions having different names should be grouped together? PS: FunBind and Match definitions: FunBind l [Match l] Match l (Name l) [Pat l] (Rhs l) (Maybe (Binds l)) On Sat, Dec 29, 2018 at 6:56 PM Alan & Kim Zimmerman <alan.zimm(a)gmail.com> wrote: > > This is for the case when you have a function like > > isJust Nothing = False > isJust (Maybe _) = True > > This is a single FunBind for isJust, but has two Matches > > Alan > > On Sat, 29 Dec 2018 at 12:25, Magicloud Magiclouds <magicloud.magiclouds(a)gmail.com> wrote: >> >> Hi, >> >> Recently I am playing with haskell-src-exts to help understanding >> Haskell syntax more. Then I got this question. >> >> As top level declarations (the type Decl), TypeSig, PatBind are quite >> straight forward, they mean one item in the source. But `FunBind l >> [Match l] >> `, I could not see it maps to "one item" in the source. >> >> Apparently, the list of Match can hold a few non-related functions >> with different names. Then why a FunBind to hold them together? >> >> -- >> 竹密岂妨流水过 >> 山高哪阻野云飞 >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

1 0