- Haskell-Cafe - Haskell.org

[ANN] cabal-clean (new tool)
by Andreas Abel 19 Aug '22

19 Aug '22

=== Wondering where your disk space goes with too many Haskell projects compiled with too many GHC versions? === https://hackage.haskell.org/package/cabal-clean https://github.com/andreasabel/cabal-clean `cabal-clean` is a small executable that removes outdated cabal build artifacts from `dist-newstyle`. A build tree is considered outdated if there is one with either - a newer version of the package you are building, or - a newer minor version of the GHC compiler. In contrast to `cabal clean`, the tool `cabal-clean` retains the latest build trees for each GHC major version. Thus, it is geared towards multi-GHC development. Example: (self-applied to cabal-clean's build directory) --- 3.7M ghc-8.8.4 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210815 --- 3.7M ghc-9.0.1 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210924 +++ 3.6M ghc-8.10.7/cabal-clean-0.1.20210924 +++ 3.7M ghc-9.0.1 /cabal-clean-0.1.20210924 The directories prefixed with --- will be deleted, the ones with +++ retained. Disclaimers: 1. cabal-clean does not check whether deletion will cause dangling references like broken symlinks etc. (Could happen if you created a symlink to an executable that resides in one of the deleted build directories.) 2. cabal-clean does not read nor utilize information from the .cabal file. 3. Calls `du` ("disk usage"), so, might not work on Windows. Enjoy, Andreas

6 6

Ambiguous type variable with lenses
by Henry Laxen 18 Aug '22

18 Aug '22

-- run this with: ghci -package microlens-platform T7.hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE FlexibleInstances #-} module T7 where import Lens.Micro.Platform type Lenstype f a b = (b -> f b) -> a -> f a data A = A { _a1 :: Int , _a2 :: String} deriving (Show) $(makeLenses ''A) class B a where lensB1 :: (Functor f) => Lenstype f a Int lensB2 :: (Functor f) => Lenstype f a String instance B A where lensB1 = a1 lensB2 = a2 xa = A 1 "one" ya1 = xa ^. a1 ya2 = xa ^. lensB1 test1 = ya1 == ya2 -- True -- But I would like to use a type variable for the String field of A data C b = C { _c1 :: Int , _c2 :: b} deriving (Show) $(makeLenses ''C) -- So next I define: class D a b where -- Need MultiParamTypeClasses here lensD1 :: (Functor f) => Lenstype f a Int -- Need AllowAmbiguousTypes here lensD2 :: (Functor f) => Lenstype f a b instance D (C b) b where -- Need FlexibleInstances here lensD1 = c1 lensD2 = c2 xc1 = C 1 "one" :: C String xc2 = C 1 'o' :: C Char yc1 = xc1 ^. c1 :: Int yc2 = xc2 ^. c1 :: Int test2 = yc1 == yc2 -- True -- All good until here. Now the trouble begins. If you uncomment the next two lines you get: -- zc1 = xc1 ^. lensD1 :: Int -- zc2 = xc2 ^. lensD1 :: Int -- T7.hs:62:14-19: error: -- • Ambiguous type variable ‘b1’ arising from a use of ‘lensD1’ -- prevents the constraint ‘(D (C String) b1)’ from being solved. -- Probable fix: use a type annotation to specify what ‘b1’ should be. -- These potential instance exist: -- instance D (C b) b -- -- Defined at /home/henry/haskell/dev/T7.hs:44:10 -- • In the second argument of ‘(^.)’, namely ‘lensD1’ -- In the expression: xc1 ^. lensD1 :: Int -- In an equation for ‘zc1’: zc1 = xc1 ^. lensD1 :: Int -- | -- 62 | zc1 = xc1 ^. lensD1 :: Int -- | ^^^^^^ -- T7.hs:63:14-19: error: -- • Ambiguous type variable ‘b0’ arising from a use of ‘lensD1’ -- prevents the constraint ‘(D (C Char) b0)’ from being solved. -- Probable fix: use a type annotation to specify what ‘b0’ should be. -- These potential instance exist: -- instance D (C b) b -- -- Defined at /home/henry/haskell/dev/T7.hs:44:10 -- • In the second argument of ‘(^.)’, namely ‘lensD1’ -- In the expression: xc2 ^. lensD1 :: Int -- In an equation for ‘zc2’: zc2 = xc2 ^. lensD1 :: Int -- | -- 63 | zc2 = xc2 ^. lensD1 :: Int -- | ^^^^^^ -- But zc1 and zc2 don't care what is in the second slot. I would -- like to store different types in the second slot of C, but the -- first slot of C will always be an Int. Is there any way to -- manipulate the first slot alone? I got some compiler "suggestions" -- concernting RankNTypes and QuantifiedConstraints but nothing I -- tried ended up working. -- Thanks in advance for your help. -- Henry Laxen

2 2

Web server with dynamic data
by Hans Georg Schaathun 16 Aug '22

16 Aug '22

Hi, I have been fiddling with this idea for some time, and I wonder if this may be the right place to ask a rather probing question!? It has been some years since my last visit to the list. I have been searching for examples using functional reactive programming to make web servers, but this proves surprisingly hard to find. I found the netwire library, but given that the last update was 2011 I am not sure I want to risk that ... So maybe I was asking the wrong question. I have a rather complex system of RDF Graphs (using Swish), with reasoners making derived graphs, and updates being made only on the original graphs. There are multiple constituent graphs to avoid having to recompute everything upon update. Now I was thinking that this looks like a typical case for FRP, with each graph a Behaviour, recomputing derived graph only when the source behaviour changes. I am not sure if I am right. Any opinions? The second part of this is the web server to allow queries (read and update) to the RDF Graphs. The first prototype uses Scotty with STM for storage, but when I add more constituent graphs, I really do not want an update to block access to other constituent graphs, which is what I thought I could avoid in an FRP model. Without much experience writing interactive stuff in Haskell, I cannot figure out how to wire the interaction between Scotty and either netwire or banana which are the two FRP libraries I have tried to comprehend. Are there any examples out there to look at? I am not really committed to any library or paradigm, except for RDF and Swish, so any ideas will be welcome, even pointing me away from everything I thought I needed ... Thanks for reading, :-- George

1 0

IFL22: Early registration deadline August 15th
by Pieter Koopman 15 Aug '22

15 Aug '22

*IFL 2022Frederiksberg Campus of Faculty of Science, UCPH, CopenhagenAugust 31s-September 2nd, 2022* *Early registration deadline: August 15th AoE * *See **https://ifl22.github.io/* <https://ifl22.github.io/>* for more information.* *CALL FOR PARTICIPATION:* The 34th Symposium on Implementation and Application of Functional Languages (IFL 2022) Copenhagen, August 31st-September 2nd, 2022 *Important dates* Submission deadline of draft papers August 8th, 2022 (EXPIRED) Notification of acceptance August 9th, 2022 (EXPIRED) Early registration deadline August 15th, 2022 (AoE) Late registration deadline August 31st, 2022, 12:59 CET (UTC+2) IFL Symposium August 31st - September 2nd, 2022 (We-Fr) *Scope* The goal of IFL is to bring together researchers and developers actively engaged in the implementation and application of functional programming languages and function-oriented programming. IFL 2022 is held in beautiful Copenhagen, Denmark and is a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional programming languages and function-oriented programming. *Invited speakers* IFL 2022 is pleased to announce keynote talks by the following three invited speakers: * Peter Sestoft, Professor, Head of Department, IT University of Copenhagen, Denmark: "Abstract machines and functional language implementation" * Lennart Augustsson, Principal Programmer, Epic Games: "Verse - a new functional-logic language" * Thomas Gazagnaire, Chief Technology Officer and co-founder, Tarides: "Talk title to be announced" *Venue and registration* The symposium will be held physically on the Frederiksberg Campus of the Faculty of Science at the University of Copenhagen. Days 1 and 2 (August 31st and September 1st) will be in meeting room A2-84.01 at Thorvaldsensvej 40. Day 3 (September 2nd) will be in the Celebration Auditorium at Bülowsvej 17. For registration and fees, please consult the symposium web site at https://ifl22.github.io/. Please notice that the early registration date is August 15, 2022 (AoE). *Accepted papers* * Asynchronous Shared Data Sources. Mart Lubbers, Haye Böhm, Pieter Koopman and Rinus Plasmeijer. * Heuristics-based Type Error Diagnosis for Haskell: the case of type families. Niels Kwadijk and Jurriaan Hage. * Verified Technology Mapping in an Agda DSL for Circuit Design. João Paulo Pizani Flor and Wouter Swierstra. * Creating Interactive Visualizations of TopHat Programs. Mark Gerarts, Marc de Hoog, Nico Naus and Tim Steenvoorden. * An SQL Frontend on top of OCaml for Data Analysis. Yan Dong, Yahui Song and Wei-Ngan Chin. * A Structure Editor with Type-Safe Copy/Paste. Hans Hüttel, Christoffer Lind Andersen, Nana Gjerulf Sandberg, Anja Elisasen Lumholtz Nielsen and Peter Mikkelsen. * How to fold and color a map: Comparing Use-Cases of Tree-Fold vs Fold-Left. Jim Newton. * Compiling a functional array language with non-semantic memory information. Philip Munksgaard, Cosmin Oancea and Troels Henriksen. * Systems of partial values and their applications in Haskell. Natasha England-Elbro. * First-Class Data Types in Shallow Embedded Domain-Specific Languages using Metaprogramming. Mart Lubbers, Pieter Koopman and Rinus Plasmeijer. * Set-theoretic Types for Erlang. Albert Schimpf, Stefan Wehr and Annette Bieniusa. * Strongly-Typed Multi-View Stack-Based Computations. Pieter Koopman and Mart Lubbers. * Ztrategic: Strategic Programming with Zippers. José Nuno Macedo, Emanuel Rodrigues, Marcos Viera and João Saraiva. * Higher-ranked region inference for polymorphic, lazy languages. Ivo Gabe de Wolff and Jurriaan Hage. * Jeopardy: An invertible functional programming language. Joachim Kristensen, Robin Kaarsgaard and Michael Kirkedal Thomsen. * The Foil: Capture-Avoiding Substitution With No Sharp Edges. Dougal Maclaurin, Alexey Radul and Adam Paszke. * Verified Causal Broadcast with Liquid Haskell. Patrick Redmond, Gan Shen, Niki Vazou and Lindsey Kuper. * Towards Inversion of Tail-recursive Term Rewriting Systems. Maria Bendix Mikkelsen, Robert Glück and Maja Hanne Kirkeby. * A Confluence and Termination Checker for Haskell Rewrite Rules. Makoto Hamana. * On Generating Out-Of-Core GPU Code for Multi-Dimensional Array Operations. Patrick van Beurden and Sven-Bodo Scholz. * Compiling Haskell for Energy Efficiency: Analysis of Individual Transformations. Bernardo Santos, João Fernandes, Maja Kirkeby and Alberto Pardo. *Post-symposium peer review * Following IFL tradition, IFL 2022 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers have been screened by the program chair to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. Notice that it is a requirement that draft papers that are accepted for presentation be presented physically at the symposium. After the symposium the authors are invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper will be accepted or rejected for the formal proceedings. Papers that are accepted for the formal proceedings are published in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. *Peter Landin Prize* The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. *Sponsors* IFL 2022 is financially supported by - Meta (Silver sponsor), - Well-typed (Bronze sponsor), - Funktionelle Københavnere (Bronze sponsor), and - University of Copenhagen (administrative support, host). *Organisation* General chair Fritz Henglein, University of Copenhagen Program chair Martin Elsman, University of Copenhagen Communications chair Troels Henriksen, University of Copenhagen *Program committee* Laura M. Castro Universidade da Coruña, Spain David Christiansen Haskell Foundation Martin Elsman University of Copenhagen, Denmark (chair) Matthew Fluet Rochester Institute of Technology, USA Clemens Grelck Universiteit van Amsterdam, The Netherlands Zhenjiang Hu Peking University, China Robin Kaarsgaard University of Edinburgh, Scotland Gabriele Keller Utrecht University, The Netherlands Oleg Kiselyov Tohoku University, Japan Neil Mitchell Facebook Stefan Monnier Universite de Montreal, Canada Magnus Myreen Chalmers University, Sweden Cyrus Omar University of Michigan, USA Romain Péchoux University of Lorraine, Inria, France Rinus Plasmeijer Radboud University, The Netherlands Morten Rhiger Roskilde University, Denmark Peter van Roy Catholic University of Louvain, Belgium Olin Shivers Northeastern University, USA Peter Thiemann University of Freiburg, Germany Marcos Viera Universidad de la República, Uruguay Meng Wang University of Bristol, UK [image: beacon]

1 0

Re: [Haskell-cafe] Haskell SQL backends: How is data handed over?
by Olaf Klinke 12 Aug '22

12 Aug '22

Anthony Clayden wrote: > What is your evidence that number/String is a concern here? It's all > happening in-memory. > > Whereas sending whatever to SQL then needs putting it to disk, which is > orders-of-magnitude slower. (Or is this an in-memory database?) > > This thread has already devoted more cycles to speculation than you're > going to reclaim through number formatting, methinks. Very good point. I'm fairly new to SQL, have a solution that works and started to wonder how efficient it is. Since the way data is passed to and from the DB engine affects every database interaction, for every user, I thought it might be worthwile investigating. And as I said earlier, profiling other code has proved that number parsing can make up a significant portion of a data-heavy program's CPU time. Thus it's not speculation entirely. Olaf

1 0

Re: [Haskell-cafe] Haskell SQL backends: How is data handed over?
by Anthony Clayden 12 Aug '22

12 Aug '22

> the backend constructs a complete SQL query statement in form of a string (including the SqlValues), and hands that to the database driver to parse. Is that indeed so? > Hi Olaf, that's the usual format for any HLL to pass statements (queries or updates) to SQL. Most HLLs provide some sort of modulate/demodulate so your program doesn't see the raw numbers-as-strings, but the parsing is going on in the background. Going via CSV isn't really saving anything: the "bulk insert" is again parsing those commas and the bits in between. (A dedicated SQL engine is probably more efficient than Haskell's string handling.) AntC

3 2

Re: [Haskell-cafe] Haskell SQL backends: How is data handed over?
by Anthony Clayden 12 Aug '22

12 Aug '22

> @Olaf You mean that formatting a Scientific number as String is more efficient > than formatting an Integer/Double in its usual representation? > How about parsing? I'm not going to defend the 'efficiency' of Haskell's String formatting/parsing, but ... What is your evidence that number/String is a concern here? It's all happening in-memory. Whereas sending whatever to SQL then needs putting it to disk, which is orders-of-magnitude slower. (Or is this an in-memory database?) This thread has already devoted more cycles to speculation than you're going to reclaim through number formatting, methinks.

1 0

Just released: cabal 3.8.1.0
by Artem Pelenitsyn 11 Aug '22

11 Aug '22

---------- Forwarded message --------- From: Mikolaj Konarski <mikolaj(a)well-typed.com> Date: Thu, Aug 11, 2022 at 7:05 PM Subject: Just released: cabal 3.8.1.0 To: <cabal-devel(a)haskell.org> Here's the happy news. :) Let me copy below the contents of the announcement from https://discourse.haskell.org/t/just-released-cabal-3-8-1-0/4920 but, additionally, on this mailing list I'd like to personally thank Emily and Oleg who, among all the giants on whose shoulders we stand, have most directly affected 3.8.1.0 with their hearts and wisdom. Haskell community owes you big time. --- I’m proud to announce 3.8.1.0 version of Cabal the library and cabal-install the tool. It’s the fruit of concerted effort of innumerous collaborators, from users, through developers, to mentors, caretakers and administrators of our linked community and infrastructure sections. You, people, rock. This version works with the just released GHC 9.4.1 (in fact, for Windows it’s probably necessary) and is already available form GHCup and other channels. More technical details, APIs, changelogs and regressions can be found at Release cabal v3.8.1.0 · haskell/cabal · GitHub. The release is huge, so let me mention only a few random highlights: public/private sublibraries are fully supported and no longer experimental (6. Package Description — Cabal 3.8.1.0 User's Guide) you can now put in your cabal.project something like import: https://www.stackage.org/lts-18.5/cabal.config and it works (7. cabal.project Reference — Cabal 3.8.1.0 User's Guide) new Cabal-syntax and cabal-install-solver packages have been split off there’s no more confusion of compiler options for the local code and for the dependencies (https://github.com/haskell/cabal/pull/7973) one can now define code generators in test stanzas, which is one more principled step away from Custom Setups (https://github.com/haskell/cabal/pull/7688) Cabal badly needs your feedback and your contributions. Please keep them coming. _______________________________________________ cabal-devel mailing list cabal-devel(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

1 0

Re: [Haskell-cafe] Haskell SQL backends: How is data handed over?
by Olaf Klinke 11 Aug '22

11 Aug '22

> My observation about the "scientific" package is also relevant here: > most DBMSes have a different notion of "number" than most programming > languages, so unless there is specifically a binary number field type > it is probably necessary to send it as a string of some variety. The > "scientific" package abstracts over this for Haskell. You mean that formatting a Scientific number as String is more efficient than formatting an Integer/Double in its usual representation? How about parsing? In most parsing libraries I've seen [1,2,3] the following code transforms a string of digits to an integer. import Data.Char (ord) import Data.Foldable (foldl') -- The parser ensures only digit Chars -- are passed to this function. fromDigit :: Num a => Char -> a fromDigit = let z = ord '0' in \digit -> fromIntegral (ord digit - z) appendDigit :: Num a => a -> Char -> a appendDigit x d = 10 * x + fromDigit d digitsToNum :: Num a => [Char] -> a digitsToNum = foldl' appendDigit 0 If in addition to 'show' the function prependDigit (and its foldr cousin for digits behind the floating point) were particularly efficient for Scientific [*], that would indeed make a strong case for using Scientific in parsing and (SQL-)database applications. Olaf [1] https://hackage.haskell.org/package/parsec-3.1.15.1/docs/src/Text.Parsec.To… [2] https://hackage.haskell.org/package/megaparsec-9.2.1/docs/src/Text.Megapars… [3] https://hackage.haskell.org/package/attoparsec-0.14.4/docs/src/Data.Attopar… [*] This seems not to be the case currently: The Num instance is implemented as Scientific c1 e1 * Scientific c2 e2 = Scientific (c1 * c2) (e1 + e2) Would it be a bad idea to add special cases for numbers of the form Scientific 1 e? It penalizes all multiplications with a pattern match.

2 3

Re: [Haskell-cafe] Haskell SQL backends: How is data handed over?
by Olaf Klinke 10 Aug '22

10 Aug '22

Thanks all for the replies. It seems in my specific setup values are indeed passed as strings, see below. Oliver Charles wrote: > I can't speak for SQL in general, but if you're targeting PostgreSQL note that the hasql library uses a binary wire format. Good to know, thanks. It might be that for my specific case the database choice ship has sailed, unfortunately. Anthony Clayden wrote: > Going via CSV isn't really saving anything: the "bulk insert" is again > parsing those commas and the bits in between. (A dedicated SQL engine is > probably more efficient than Haskell's string handling.) That was what I was thinking, too: The bulk insert must also parse the numbers, so it would be kind of a waste to have Haskell parse the numbers, format them as Strings in the CSV just to have the SQL server parse them again. Brandon Allbery wrote: > More specifically, a query or DML statement is a string with ? > placeholders for values, which is "prepare"d to turn it into internal > format and then executed one or more times with values supplied. Sending the SQL statement as string is probably fine. I guess it depends on the specific HDBC backend whether run :: Connection -> String -> [SqlValue] -> IO Integer also sends the SqlValue arguments as String. Specifically, I chose persistent with HDBC-odbc backend because (1) We're talking to a Microsoft SQL server from a Linux client via unixODBC, (2) We chose Microsoft SQL to ensure trouble-free integration into the Microsoft office world, (3) I expect a web application will emerge from this, hence persistent because it integrates well with Yesod. In [HDBC-odbc] it is implemented in sqlBindValue, sqlBindParameter which contains CString -- ^ Parameter value pointer The actual value (if not a string) is converted to ByteString (using the Convertible class) and placed into the CString, it seems. The Convertible SqlValue Bytestring instance uses fromString and Convertible SqlValue String which in turn uses show [HDBC]. So yep, to ODBC the SqlValues are passed as Strings. HDBC-sqlite3 does the same. I opened [1]. Olaf [HDBC-odbc] https://hackage.haskell.org/package/HDBC-odbc-2.5.0.1/docs/src/Database-HDB… [HDBC] https://hackage.haskell.org/package/HDBC-2.4.0.4/docs/src/Database.HDBC.Sql… [1] https://github.com/hdbc/hdbc/issues/56

2 1