- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] static analysis of a C-like language
by Olaf Klinke 04 Dec '18

04 Dec '18

> Hello Olaf, > > to me that sounds as if you want to do an abstract interpretation with a > forward collecting semantics that employs non-relational abstract > domains for the primitive data types and summarizes the dimensions of > arrays. ... > I would start by writing a simple interpreter for the language to be > analyzed. That way you fix messy details before they bite you, e.g. the > order in which submodules are loaded and initialized. I was hoping not having to write an interpreter (because the language author wrote a translation to C++ already), but if that is the way to go, I'll do it. As I understand it, the Haskell semantics should contain just enough substance so that the errors I am after will cause hiccups in the Haskell compiler? That is indeed a compelling approach. What this does not address is the question about error reporting: How could a translation to Haskell preserve information about scope, source position and masking? Can I leverage the ghc API for that? Regards, Olaf

3 2

10 PhD studentships in Nottingham
by Graham Hutton 04 Dec '18

04 Dec '18

Dear all, The School of Computer Science at the University of Nottingham is seeking applications for 10 fully-funded PhD studentships: https://tinyurl.com/10-phds-2019 Applicants in the area of the Functional Programming Laboratory (https://tinyurl.com/fp-notts) are strongly encouraged! If you are interested in applying, please contact a potential supervisor at least two weeks prior to the 18th January deadline: Thorsten Altenkirch - constructive logic, proof assistants, homotopy type theory, category theory, lambda calculus. Venanzio Capretta - type theory, mathematical logic, corecursive structures, proof assistants, category theory, epistemic logic. Graham Hutton - functional programming, program calculation and transformation, correctness and efficiency, category theory. Henrik Nilsson - functional reactive programming, modelling and simulation, domain-specific languages, probabilistic languages. Best wishes, Graham +-----------------------------------------------------------+ 10 Fully-Funded PhD Studentships School of Computer Science University of Nottingham, UK https://tinyurl.com/10-phds-2019 Applications are invited for up to ten fully-funded PhD studentships in the School of Computer Science at the University of Nottingham, starting on 1 October 2019. The topics for the studentships are open, but should relate to one of the School’s research groups: Agents Lab; Automated Scheduling and Planning; Computer Vision Lab; Data Driven Algorithms, Systems and Design; Functional Programming Lab; Intelligent Modelling and Analysis; Uncertainty in Data and Decision Making; Mixed Reality Lab. The studentships are for a minimum of three years and include a stipend of £14,777 per year and tuition fees. They are open to students of any nationality. Applicants are normally expected to have a first-class MSc or BSc in Computer Science or a related discipline, and must obtain the support of a supervisor in the School prior to submitting their application. Initial contact with supervisors should be made at least two weeks prior to the closing date for applications. Informal enquiries may be addressed to SS-PGR-JC(a)nottingham.ac.uk. To apply, please submit the following items by email to: Christine.Fletcher(a)nottingham.ac.uk: (1) a brief covering letter that describes your reasons for wishing to pursue a PhD, your proposed research area and topic, and the name of the potential supervisor whose support you have already secured; (2) a copy of your CV, including your actual or expected degree classes, and results of all University examinations; (3) an extended example of your technical writing, such as a project report or dissertation; (4) contact details for two academic referees. Closing date for applications: Friday 18 January 2019 +-----------------------------------------------------------+ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

ANN: hledger-1.12
by Simon Michael 03 Dec '18

03 Dec '18

hledger is a robust, cross-platform plain text accounting tool, for tracking money, time, stocks, cryptocurrencies or any other commodity, using double-entry accounting, private or shared plain text files, revision control, and command-line, curses or web UIs. Find out more at http://hledger.org and http://plaintextaccounting.org. I'm pleased to announce the release of hledger 1.12! Thank you release contributors Alex Chen, Jesse Rosenthal, Samuel May, Mykola Orliuk, Peter Simons, Moritz Kiefer, Dmitry Astapov, Felix Yan, Aiken Cairncross, and Nikhil Jha. After two years of regular quarter-end releases, I am speeding up hledger's release cadence: we now aim to release every 1-3 months, as needed or wanted, with our normal release window being the first few days of each month. Release notes (http://hledger.org/release-notes) ------------------------------------------------- hledger 1.12 * install script: ensure a new-enough version of stack; more informative output * build with GHC 8.6/base-4.12 (Peter Simons) * add required upper bound for statistics (Samuel May) * --anon anonymises more thoroughly (including linked original postings) (Moritz Kiefer) * unbalanced transaction errors now include location info (Mykola Orliuk) * accounts command: --drop also affects the default flat output, without needing an explicit --flat flag * accounts command: the --codes flag has been dropped * accounts command: filtering by non-account-name queries now works * add command: fix transaction rendering regression during data entry and in journal file * balance command: fix wrongful eliding of zero-balance parent accounts in tree mode (Dmitry Astapov) * journal format, bs/bse/cf/is commands: account directives can declare account types (#877) Previously you had to use one of the standard english account names (assets, liabilities..) for top-level accounts, if you wanted them to appear in the right place in the balancesheet, balancesheetequity, cashflow or incomestatement reports. Now you can use your preferred account names, and use account directives to declare which accounting class (Asset, Liability, Equity, Revenue or eXpense) an account (and its subaccounts) belongs to, by writing one of the letters A, L, E, R, X after the account name, after two or more spaces. This syntax may change (see issue). Experimental. Currently we allow unlimited account type declarations anywhere in the account tree. So you could declare a liability account somewhere under assets, and maybe a revenue account under that, and another asset account even further down. In such cases you start to see oddities like accounts appearing in multiple places in a tree-mode report. I have left it this way for now in case it helps with, eg, modelling contra accounts, or combining multiple files each with their own account type declarations. (In that scenario, if we only allowed type declarations on top-level accounts, or only allowed a single account of each type, complications seem likely.) * journal format: periodic transaction rules now require a double space separator. In periodic transaction rules which specify a transaction description or same-line transaction comment, this must be separated from the period expression by two or more spaces, to prevent ambiguous parsing. Eg this will parse correctly as "monthly" thanks to the double space: ~ monthly In 2020 we'll end this monthly transaction. * journal format: exact/complete balance assertions (Samuel May). A stronger kind of balance assertion, written with a double equals sign, asserts an account's complete account balance, not just the balance in one commodity. (But only if it is a single-commodity balance, for now.) Eg: 1/1 (a) A 1 (a) B 1 (a) 0 = A 1 ; commodity A balance assertion, succeeds (a) 0 == A 1 ; complete balance assertion, fails * journal format: account directives now allow whitespace or a comment after the account name * journal format: using ~ for home directory in include directives now works (#896) (Mykola Orliuk) * journal format: prevent misleading parse error messages with cyclic include directives (#853) (Alex Chen) * journal format: transaction modifier multipliers handle total-priced amounts correctly (#928). Multipliers (*N) in transaction modifier rules did not multiply total-priced amounts properly. Now the total prices are also multiplied, keeping the transaction balanced. * journal format: do amount inference/balance assignments/assertions before transaction modifiers (#893, #908) (Jesse Rosenthal) Previously, transaction modifier (auto postings) rules were applied before missing amounts were inferred. This meant amount multipliers could generate too many missing-amount postings, making the transaction unbalanceable (#893). Now, missing amount inference (and balance assignments, and balance assertions, which are interdependent) are done earlier, before transaction modifier rules are applied (#900, #903). Also, we now disallow the combination of balance assignments and transaction modifier rules which both affect the same account, which could otherwise cause confusing balance assertion failures (#912). (Because assignments now generate amounts to satisfy balance assertions before transaction modifier rules are applied (#908).) * journal format: periodic transaction rules are now aware of Y default year directives. (#892) Ie when a default year Y is in effect, they resolve partial or relative dates using Y/1/1 as the reference date, rather than today's date. hledger-ui 1.12 * fix "Any" build error with GHC < 8.4 * error screen: always show error position properly (#904) (Mykola Orliuk) * accounts screen: show correct balances when there's only periodic transactions * drop the --status-toggles flag * periodic transactions and transaction modifiers are always enabled. Rule-based transactions and postings are always generated (--forecast and --auto are always on). Experimental. * escape key resets to flat mode. Flat mode is the default at startup. Probably it should reset to tree mode if --tree was used at startup. * tree mode tweaks: add --tree/-T/-F flags, make flat mode the default, toggle tree mode with T, ensure a visible effect on register screen * hide future txns by default, add --future flag, toggle with F. You may have transactions dated later than today, perhaps piped from print --forecast or recorded in the journal, which you don't want to see except when forecasting. By default, we now hide future transactions, showing "today's balance". This can be toggled with the F key, which is easier than setting a date query. --present and --future flags have been added to set the initial mode. (Experimental. Interactions with date queries have not been explored.) * quick help tweaks; try to show most useful info first * reorganise help dialog, fit content into 80x25 again * styling tweaks; cyan/blue -> white/yellow * less noisy styling in horizontal borders (#838) * register screen: positive amounts: green -> black The green/red scheme helped distinguish the changes column from the black/red balance column, but the default green is hard to read on the pale background in some terminals. Also the changes column is non-bold now. Getting started: ---------------- All install methods are described at http://hledger.org/download . You can download windows binaries, or use a package manager, though in some cases these will install an older hledger version. You can build the latest hledger packages with stack: $ stack install --resolver=lts-12 megaparsec-7.0.4 cassava-megaparsec-2.0.0 config-ini-0.2.3.0 hledger-lib-1.12 hledger-1.12 [hledger-ui-1.12] [hledger-web-1.12] [hledger-api-1.12] or with cabal: $ cabal update && cabal install hledger-1.12 [hledger-ui-1.12] [hledger-web-1.12] [hledger-api-1.12] or with the hledger installer, on systems with bash installed (handy if you don't have a working stack or cabal): $ curl -s https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… > hledger-install.sh $ less hledger-install.sh # satisfy yourself that the script is safe $ bash hledger-install.sh Some commands to try: $ hledger add # record some transactions, with guidance $ hledger print # show recorded transactions $ hledger balance # show totals by account $ hledger -h # show quick help $ hledger # list available commands $ hledger help # list built-in manuals To get oriented, see the tutorials and manuals at http://hledger.org ; say hello and ask questions in the #hledger IRC channel on Freenode, accessible at http://irc.hledger.org . New users and contributors are always welcome! Best, -Simon

1 0

Open PhD and intern positions at IMDEA
by Niki Vazou 03 Dec '18

03 Dec '18

Hi Haskellers, I recently joined IMDEA and looking for talented Ph.D. students and interns to work with. Projects My current open projects focus on how to establish Liquid Haskell <https://ucsd-progsys.github.io/liquidhaskell-blog/> as a practical and useful theorem prover. Ideas I would like to explore include: - *Integration with Compiler & Compiler Optimizations:* The major goal of verification is to prove that your code satisfies certain correctness properties. But, once your correctness properties are proved, the compiler could use them to optimize the running times. For example properties like associativity, map fusion, and class laws could, and should, be used for provably correct compiler optimizations. The goal of this project is how the Haskell compiler can automatically take full advantage of Liquid Haskell generated proofs. - *Error Reporting:* Error messages are terrible! This is the case in most systems that include type inference, see ghc, and Liquid Haskell is not an exception. Recently <https://nikivazou.github.io/static/oopsla18main-p124-p.pdf>, the idea of using gradual types for error explanation was explored. The goal of this project is to further explore the interaction between gradual types and error reporting, or use further concepts, such as testing to aid error explanation. - *Interactive Proving Environment:* For theorem proving to be usable, proof generation should be interactively directed by the prover. Towards this goal, this project aims to investigate how existing techniques such as tactics and interactive environments from interactive theorem provers like Coq and Isabelle/HOL can be adapted to aid proof generation in Liquid Haskell. At the same time, proof generation can be aided by Haskell’s code generation infrastructures such as the automatic code derivation mechanisms. My passion is functional programing and practical program verification, so I am happy to discuss new research ideas in any of these directions. Requirements If you want to apply for a Ph.D. position you are required to have an undergraduate degree in Computer Science or a closely related area and have strong interest in functional programming. About IMDEA The IMDEA Software Institute <https://software.imdea.org/index.html> is ranked <http://csrankings.org/#/index?plan&europe> among the best european institutes in the areas of Programming Languages and Computer Security. Located in the Montegancedo Science and Technology Park <https://software.imdea.org/contact_and_directions/building.html> it perfectly combines the sunny and vibrant city of Madrid with cutting edge research and competitive salaries. How to apply? To apply send me an email at niki.vazou(a)imdea.org with your CV and submit an online application at IMDEA’s open positions <http://software.imdea.org/open_positions.html>. Best, Niki Vazou

1 0

Can't get Type 3" to work
by Amy de Buitléir 03 Dec '18

03 Dec '18

I'm reading "Thinking with Types" by Sandy Maguire, and there's a bit of code on p. 27 that I don't understand and can't get to work. The "Type 3" seems to have the effect of multiplying by 3. > :set -XDataKinds > :set -XTypeOperators > :kind! (1 + 17) Type 3 (1 + 17) Type 3 :: Nat = 54 But it doesn't work for me. When I try this, I get... $ ghci --version The Glorious Glasgow Haskell Compilation System, version 8.2.2 $ ghci λ> :set -XDataKinds λ> :set -XTypeOperators λ> :kind! (1 + 17) Type 3 <interactive>:1:2: error: Not in scope: type constructor or class '+' <interactive>:1:10: error: Not in scope: type constructor or class 'Type'

3 4

semantics of concurrent program depends on -O level, -f[no-]omit-yields
by Johannes Waldmann 30 Nov '18

30 Nov '18

Dear Cafe, I am surprised by the behaviour of the program below (the interesting property is whether it will output "foo"). Behaviours (plural) actually: it seems to depend on optimisation level, on omit-yields, and on very small changes in the source code: It does print (mostly), when compiled with -O0. It does not, when compiled with -O2. With -O2 -fno-omit-yields, it will print. With -O0 -fno-omit-yields, and when I remove the two newTVar in the beginning, it will mostly not print. How come? These differences already occur with the last two lines replaced by "forever $ return ()", so the STM stuff may be inessential here. But that's the context where I came across the problem. - J.W. import Control.Concurrent.STM import Control.Concurrent ( forkIO ) import Control.Monad ( forever ) import System.IO main = do atomically $ newTVar "bar" atomically $ newTVar False forkIO $ putStrLn "foo" x <- atomically $ newTVar False forever $ atomically $ writeTVar x True

5 16

Haskell-related summer internship in Germany
by Sandra Dylus 30 Nov '18

30 Nov '18

Our department (PL and compiler construction) again offers a summer internship in 2019 sponsored by DAAD Rise Germany [1]. Undergraduate students enrolled at North American, British and Irish universities are eligible to make an application. We'd be very happy to host a motivated student, who is keen to improve our compiler for the functional logic programming language Curry in terms of performance. For more information you may have a look at our project poster [2]. If you have any questions, feel free to mail any of the contact persons. Please also spread the news to your students and classmates. Cheers, Finn and Sandra [1]: https://www.daad.de/rise/en/rise-germany/ <https://www.daad.de/rise/en/rise-germany/> [2]: https://www-ps.informatik.uni-kiel.de/~sad/DAADRise.pdf <https://www-ps.informatik.uni-kiel.de/~sad/DAADRise.pdf>

1 0

Re: [Haskell-cafe] WebAssembly illustrated
by Takenobu Tani 30 Nov '18

30 Nov '18

Hi Sven, Thank you for teaching me. > Also, are you slides free to use? Could you please share the source? Of course you can use it freely :) I also commit the source. (But it is PowerPoint.) Cheers, Takenobu On Fri, Nov 30, 2018 at 9:10 PM Sven Sauleau <sven(a)sauleau.com> wrote: > Hi, > > Interesting document, thanks for sharing! > > I opened a clarification issue: [1]. > > Also, are you slides free to use? Could you please share the source? > [1]: https://github.com/takenobu-hs/WebAssembly-illustrated/issues/1 > > Thanks! > Sven > > On 30/11/2018 12:45, Takenobu Tani wrote: > > Hi cafe, > > I share this even in this place. > > WebAssembly illustrated > https://takenobu-hs.github.io/downloads/WebAssembly_illustrated.pdf > > > P.S. > Haskell has backends such as asterius [1] and dhc [2]. > > [1]: https://github.com/tweag/asterius > [2]: https://github.com/dfinity/dhc > > Cheers, > Takenobu > > > > _______________________________________________ > 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. > > >

1 0

WebAssembly illustrated
by Takenobu Tani 30 Nov '18

30 Nov '18

Hi cafe, I share this even in this place. WebAssembly illustrated https://takenobu-hs.github.io/downloads/WebAssembly_illustrated.pdf P.S. Haskell has backends such as asterius [1] and dhc [2]. [1]: https://github.com/tweag/asterius [2]: https://github.com/dfinity/dhc Cheers, Takenobu

1 0

GHC 8.6.2 zombie processes?
by Viktor Dukhovni 30 Nov '18

30 Nov '18

It seems that GHC 8.6.2 does not reap defunct child processes in a timely manner when compiling many modules (e.g. "base" when stack is building a new sandbox). This is especially visible when using LLVM 6.0 whose optimizer is particularly CPU-intensive (read mind-numbingly slow) on my X86_84 FreeBSD system: The process: $ ps -wwwwwww -o pid,etime,args -p 98525 PID ELAPSED COMMAND 98525 55:47 /home/viktor/.local/lib/ghc-8.6.2.20181122/bin/ghc -B/home/viktor/.local/lib/ghc-8.6.2.20181122 --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir .stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/build -odir .stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/build -hidir .stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/build -stubdir .stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/build -i -i.stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/build -i. -i.stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/build/autogen -i.stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/build/global-autogen -I.stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/build/autogen -I.stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/build/global-autogen -I.stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/build -I/usr/local/Cellar/postgresql/10.0/include -I/usr/local/include -I/usr/local/opt/icu4c/include -optP-include -optP.stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/build/autogen/cabal_macros.h -this-unit-id Cabal-2.4.1.0-IaB5GUEm19R82R9cEdbB1D -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db /usr/home/viktor/.stack/snapshots/x86_64-freebsd/nightly-2018-11-28/8.6.2.20181122/pkgdb -package-db .stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/package.conf.inplace -package-id array-0.5.3.0 -package-id base-4.12.0.0 -package-id binary-0.8.6.0 -package-id bytestring-0.10.8.2 -package-id containers-0.6.0.1 -package-id deepseq-1.4.4.0 -package-id directory-1.3.3.0 -package-id filepath-1.4.2.1 -package-id mtl-2.2.2 -package-id parsec-3.1.13.0 -package-id pretty-1.1.3.6 -package-id process-1.6.3.0 -package-id text-1.2.3.1 -package-id time-1.8.0.2 -package-id transformers-0.5.5.0 -package-id unix-2.7.2.2 -XHaskell2010 Distribution.Backpack Distribution.Backpack.Configure Distribution.Backpack.ComponentsGraph Distribution.Backpack.ConfiguredComponent Distribution.Backpack.DescribeUnitId Distribution.Backpack.FullUnitId Distribution.Backpack.LinkedComponent Distribution.Backpack.ModSubst Distribution.Backpack.ModuleShape generated multiple hundreds of "zombies": $ ps $(pgrep -P 98525) | egrep -c defunct 460 I guess the build taking an hour is far more an issue than a few hundred zombies, but this message is about the zombies. Is this a feature or a bug? -- Viktor.

1 0

Is there some way to hack the type system without recompiling GHC?
by ducis 29 Nov '18

29 Nov '18

We know that the type system is now a second language where you spec formal requirements and let the compiler solve it, kinda like logic programming. But sometimes I knew something is correct or at least willing to take the risk of runtime errors, but the typechecker is not (yet) able to figure it out. In this case is it possible to somehow insert (regular haskell) code into the typechecker and force the compiler to think some values are of some types, rather than waiting for or inventing some formally correct solution, which may be fundamentally very difficult?

4 3

Tidal (musical pattern library) refactor - feedback appreciated
by Alex McLean 28 Nov '18

28 Nov '18

https://slab.org/tidal-1-0-0-refactor/ -- blog: http://slab.org/

1 1

XText vs DSL in Haskell in mission critical software
by Puck 28 Nov '18

28 Nov '18

Hello all, how can I convince my bosses to use existing functional languages for specifying the future embedded softwares from the company instead of using Xtext or other things that firm under the name "model driven development". The softwares are mission critical. A local cooperation is already building an research institute with the goal of "model driven development". Why they do not use plain Haskell, LiquidHaskell and Coq? Neither can I imagine, that Haskell or Coq is so hard to learn, neither can I imagine that they want the developers to dive through handwritten Java extensions for their tool, that can only be analyzed with Java-tools and cannot be proven. Is XText, for example, really so good? Is a Haskell-DSL as a counterpart, not very much fewer dependent on other things, and very much easier to maintain? Thanks for suggestions and arguments Puck

2 1

Re: [Haskell-cafe] XText vs DSL in Haskell in mission critical software
by Johannes Waldmann 27 Nov '18

27 Nov '18

> how can I convince my bosses to use existing functional languages You don't. Instead you have a coffee and read about bosses and software at dilbert.com and hackernews. While the browser refreshes the page, you write a compiler from xtext (or whatever the current buzzword is) to Haskell and back. - J.W.

1 0

haddock (on hackage/stackage) missing references to external libraries
by Johannes Waldmann 27 Nov '18

27 Nov '18

Dear Cafe, it seems that haddock (as used on hackage) does not link to identifiers from other packages (neither in HTML nor in hyperlinked source). This hurts, especially if a project has several packages that are meant to be used together, but are split for others reasons (modularity, maintenance). Example: This index has an entry for "bpf", with a non-linked module name Csound.Base: https://hackage.haskell.org/package/csound-expression-5.3.2/docs/doc-index-… The reason is (I think) that "bpf" is defined elsewhere, but re-exported, and "elsewhere" is in a different package. It is very hard to find the name of this package! (in this case, csound-expression-opcodes) Of course, in no way is this a complaint about Anton's csound-* project. I use it in teaching, and I wonder how could we make documentation more accessible - without extra manual work. Now, :doc of ghc-8.6 works, and :info helps somewhat: :info bpf ... -- Defined in ‘Csound.Typed.Opcode.SignalGenerators’ but it still does not show the name of the package. But at least we know the name of the module to look for. - J.W.

2 2

how to cabal-install so that :doc works?
by Johannes Waldmann 27 Nov '18

27 Nov '18

Dear Cafe - what do I have to put in my global .cabal/config in order to make ghci's new :doc command https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#g… work after "cabal install <foo>"? I thought "documentation: True" should do it but I am invariably getting this: GHCi, version 8.6.2: http://www.haskell.org/ghc/ :? for help Prelude> import Ersatz Prelude Ersatz> :doc solveWith ghc: Can't find any documentation for Ersatz.Solver. This is probably because the module was compiled without '-haddock', but it's also possible that the module contains no documentation. I do have the .cabal/share/doc/x86_64-linux-ghc-8.6.2/ersatz-0.4.4/html directory. The :doc command seems to work for the libraries that come with ghc (documentation in /opt/ghc/ghc-8.6.2/share/doc/ghc-8.6.2/html/ ) - J.W.

3 3

Munich Haskell Meeting, 2018-11-28 @ 19:30
by Leah Neukirchen 27 Nov '18

27 Nov '18

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, November 28 at Cafe Puck at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-nov-2018/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> http://leah.zone

1 0

[Job] Cross Compass is currently hiring Haskell developers
by Ramin Honary 27 Nov '18

27 Nov '18

[Cross Compass](https://www.xcompass.com/en/) is a data science and machine learning consultancy located in Tokyo, Japan. Most of the work is focused on solving problems for clients by making creative use of their data. We currently have a small team of Haskellers working on a deep learning framework implemented in Haskell. We plan to use this framework multiple ways. For example, we have created a web platform for the manufacturing industry to make it easy to generate anomaly detection models for use in a factory. We are hiring Haskell programmers to help create this framework. We are mainly looking for people skilled in either web programming or machine learning. ### The ideal candidate would be similar to the following: - Passionate about functional programming, type-driven development, and modern artificial intelligence, especially deep learning. - Have experience with machine learning/deep learning, either professionally or academically. Be experienced with popular frameworks like Tensorflow, PyTorch, etc. - Have extensive Haskell experience. Be completely comfortable using (or learning) libraries like `lens`, `servant`, `singletons`, etc. Author of popular Haskell libraries. Worked on multiple large applications. - Have experience developing web apps using any of JavaScript, TypeScript, PureScript, Elm, GHCJS, and have created web apps using frameworks like Vue, Angular, React, Halogen, Reflex, or Miso. Ideally with a backend REST API implemented in Haskell. - Able to work full-time (40 hours a week) or **part-time** (20+ hours a week). - Willing to do freelance with us for a few weeks to make sure we are a good match for each other before becoming an permanent employee. - Able to work either on-site or **remote** - In the case of remote, you live in near Japan's timezone (UTC+9) and can fly to the office in Tokyo multiple times per year. (This requirement could be waived for strong candidates.) - Experience as a team-lead, chopping up and assigning tasks to less experienced Haskellers, reviewing PRs, etc. ## Flexible with job requirements We realize there are probably very few people that actually meet all these points. We are flexible, so please feel free to get in touch even if you don't think you meet our ideal requirements. It is possible for us to hire remotely, although we prefer people that are near Japan's timezone (UTC+9) and can fly to the office in Tokyo multiple times per year. We can also sponsor visas for people that want to move to Japan. As stated above, we are also open to applicants who want to do non-full-time work (20+ hours per week). Here are two examples of people we would love to talk to even though they don't meet all of the points above: ### Example 1: - Going to graduate school in Tokyo for machine learning. Very familiar with deep learning. - Beginning Haskeller. Have read through all of Haskell Programming From First Principles (and perhaps [Thinking with Types](https://leanpub.com/thinking-with-types)?) but has no experience working with large applications. - Able to come in to the office 20 to 25 hours a week. ### Example 2: - Living in Australia - Intimately familiar with Haskell, author of multiple popular libraries. - Very competent with web programming. - No experience with machine learning. - Multiple years of experience working remotely. - Able to work full-time. ## Some of the benefits of working at Cross Compass: - Work with passionate Haskellers. You may have seen us either here on [/r/haskell](https://www.reddit.com/r/haskell), or at conferences: - [Hideaki Kawai](https://github.com/kayhide) - [Viktor Kronvall](https://github.com/considerate) - [Ramin Honary](https://github.com/RaminHAL9001) - [Dennis Gosnell](https://functor.tokyo/) - We also work with [Tweag I/O](https://www.tweag.io). Their Haskellers are really top class. - Attend conferences like ICFP, Lambda Jam, etc. We each try to attend a couple conferences a year. - Training. We are planning to have the entire team take the [Guide to Haskell Performance and Optimization](https://www.well-typed.com/services_training_performance_and_… course from Well-Typed at some point. The lower end of the pay scale is 8 Million Yen (800万円) per year for full-time. I'm not sure what the higher end is. If this sounds interesting, please feel free to email us atrecruit-haskell(a)cross-compass.com, possibly with your resume and why you think we'd be good for each other. If you want to know more, we would love to take you out to lunch if you're located in Tokyo, or chat with you on Skype if not.

1 0

Taking over a package bindings-librrd
by Alexandr Fedorov 26 Nov '18

26 Nov '18

Hello, this package looks abandoned and does not compile on the latest librrd library. Let me clarify this: if MasatakeDaimon can hear this letter, please add me to bindings-librrd maintainers list, i'd be more than happy to help and a taking over is not necessary, but if somehow he still doesn't show up, hackage administrator please consider either adding me as a maintainer, or let me take over this package.

1 0

Help with DataKinds example
by Marc Busqué 24 Nov '18

24 Nov '18

I'm reading Sandy Maguire book Thinking with Types, and I'm stuck understanding an example about `DataKinds` language extension. In the book, it is said that it can be used to prevent at the type level that non admin users perform some action for which admin privileges are required. So, in the example, having `DataKinds` enabled, we define: ``` data UserType = User | Admin ``` Then, we change User type: ``` data User = User { userAdminToken :: Maybe (Proxy 'Admin) } ``` And then it is said that we can enforce that sensitive operations are performed by a user with the admin token: ``` doSensitiveThings :: Proxy 'Admin -> IO () ``` No other language extensions have been explained before in the book, and I simply don't understand how it is works... First, I guess that when writing `data User = ...` we are overriding `'User` promoted data constructor. Isn't it? Also, I don't understand how I could define a type `Proxy 'Admin`. If I'm not wrong, `Proxy` should have the kind `UserType -> *`, but I don't know how to do that. Besides that, I would like some guidance in the general idea of the example, because I'm quite puzzled :) Thanks in advance! Marc Busqué http://waiting-for-dev.github.io/about/

3 3

static analysis of a C-like language
by Olaf Klinke 22 Nov '18

22 Nov '18

Dear Cafe, I want to build a linter for a C-like language. My company uses a UI system that comes with a C-like language that is used to provide functionality to the UI elements. The language is interpreted at runtime. The user, however, has no access to the built-in parser and checking functions. Only a basic syntax check comes with their editor. Therefore many stupid mistakes only show at runtime and can not be tested for statically. The language is in many respects even simpler than C. No structs, no enumerations, only a handful of basic data types and arrays thereof, plus pointers and the usual control flow structures. On the other hand, there are some features that make static analysis near impossible, e.g. the possibility of dynamic registration of variables. Higher-order types are emulated by passing the name of other functions as strings. There is explicit referencing of other sources (#include statements) as well as implicit referencing within UI elements and within the project hierarchy. We want to catch basic programming mistakes - misspelled variables, missing return statements, usage of variables before assignment, wrong number of function arguments/types. A project's code is scattered across multiple files and layers - a function declaration can mask a declaration from the layer below. Therefore, a per-file-linter will not suffice. As a side-effect this may also yield a documentation generator (boy do I miss haddock while working with that), which is also missing in the system. I have never done something like this and will seek help from local CS departments (If you are a CS student in Paderborn or Bielefeld, Germany, get in touch!). My company would be willing to sponsor a Bachelor or Master's thesis project. Ultimately this will be comercialized as an add-on, so anyone who helps will also profit from the result financially. The user community is not large, but includes big names such as Siemens, London Heathrow, the Metros in NYC and Bilbao, and CERN. What kind of expertise shall I look for? Compiler theorists? What information shall I request from the language author? I feel that Haskell might be a good language to represent the AST in. But I am overwhelmed by the numerous AST libraries on hackage. How similar is my problem to what is covered by, say, haskell-src-exts, hlint, alex or syntactic? Can I re-use code from these projects? What solutions are out there for dependency resolution between source files? I suppose for informative error messages I need to decorate each semantic bit with information about - source file and location - what is in scope at that position, plus the source of the symbols in scope What data structures can be used to build and represent this information? Any pointers welcome. Olaf

3 3

Re: [Haskell-cafe] Feedback on plan for checking code requirements in a GHC plugin
by Johannes Waldmann 21 Nov '18

21 Nov '18

> Has anyone done anything like this before? Sort-of. Not with a GHC plugin, but haskell-src-exts to get the AST, and then match with a blueprint for the code (students have to replace "undefined" by some expression). See "How I Teach Functional Programming" (WFLP 2017) https://www.imn.htwk-leipzig.de/~waldmann/talk/ - J.W.

1 0

Re: [Haskell-cafe] Specialize a function on types of arguments?
by Anthony Clayden 20 Nov '18

20 Nov '18

On Mon, 19 Nov 2018 at 21:03, Olaf Klinke wrote: >>* The top-level story is that I am trying to create a monad that somehow* *>*>* records the "intermediate steps" of computation.* >> > If it is only for knowing where things went wrong, ... Thanks Olaf, no I think Ducis wants to stack the whole history of the computation. > If ... Then you need to stack a state transformer on top, Yes a monad transformer might be it. Thank you for the example. As per my previous message, I'm not convinced it needs monads at all. Here's a dumb approach as a straw man, showing that type-changing steps are nothing special (or perhaps I mean type-preserving steps are nothing special ;-). Ducis could explain why this won't do nil = () cons x l = (x, l) start :: a -> (a,()) start x = cons x nil -- i.e. singleton x infixl 0 $>> ($>>) :: (b, _a) -> (b -> c) -> (c, (b, _a)) xs@(x, z) $>> f = cons (f x) xs eg = start 1 $>> (+ 1) $>> (+ 3) $>> double $>> show ===> ("10",(10,(5,(2,(1,()))))) I chose ($>>) to be similar to ($>) from the Control.FPipe package "trivial F#-style pipes for function composition and application". You could use Datakind `'[]` instead of the 'poor man's heterogeneous list' I've used, but that seems over-engineering. AntC

1 0

Re: [Haskell-cafe] Specialize a function on types of arguments?
by Olaf Klinke 19 Nov '18

19 Nov '18

> > The top-level story is that I am trying to create a monad that somehow > records the "intermediate steps" of computation. > If it is only for knowing where things went wrong, isn't that what the Either monad is for? The semantics of (Either YourErrorType) is that it returns `Right result' when all steps went through, and `Left errmsg' from the first place where something went wrong. You'd have to define YourErrorType to incorporate the relevant error information. If you also want something like a call stack, i.e. a message like "computation failed in step 3 with message: foo" Then you need to stack a state transformer on top, e.g. StateT CallStack (Either YourErrorType) which decodes to CallStack -> Either YourErrorType (resultType,CallStack) An example using mtl transformers: import Control.Monad.State.Strict import Control.Monad.Except type CallStack = (Int,[String]) type YourErrorType = String type M a = StateT CallStack (Except YourError) a fancyFunc :: Show a => (a -> b) -> (a -> M b) fancyFunc f a = do (n,stack) <- get put (n+1,show a : stack) return b fancyMaybe :: Show a => (a -> Maybe b) -> (a -> M b) fancyMaybe f a = do (n,stack) <- get case (f a) of Nothing -> throwError $ "Failed at step "++(show n)++" on input "++(show a) Just b -> do put (n+1,show a : stack) return b runChainOfComputations = runStateT (1,[]) I once wrote a type 'ProvenienceT' which is a bit fancier than the above. It is a monadic EDSL and constructs a graph where nodes are (Markup of) intermediate steps of a computation and where edges are (user-supplied descriptions of) functions. It is inspired by the Javelin software of the 80s which pre-dates Excel spreadsheets. The result can be rendered as html. Can provide code if anyone is interested. Cheers, Olaf

1 0

Re: [Haskell-cafe] Specialize a function on types of arguments?
by ducis 19 Nov '18

19 Nov '18

Hi, Anthony, The top-level story is that I am trying to create a monad that somehow records the "intermediate steps" of computation. e.g. something like Prelude> return 1 ([],1) Prelude> return 1 >>= return.(+1) ([1],2) Prelude> return 1 >>= return.(+1)>>=return.(+3) ([2,1],5) (the list has the intermediate steps placed right-to-left so that new steps are appended to the left of the older steps) Of course all "intermediate steps of computation" actually form a graph, but we are frequently focused on, say, the transformation of a parse tree, where we want to take a series of snapshots of one "thing". Since a "lifted function" (e.g. return.(+1)) has in general the type a->m b, there are two ways to deal with input and output being not necessarily equal. The first approach I tried is to only record latest steps starting with the last change of type > newtype WithHistory b = WH ([b], b) and just discard the older steps when the input and output are of different types. > newtype WithHistory b = WH ([b], b) deriving (Show,Eq) > instance Monad WithHistory where > return b = WH ([], b) > (>>=) :: forall a b. WithHistory a -> (a -> WithHistory b) -> WithHistory b > WH (h,a) >>= fm = WH (h1++coerceHistory (a:h),b) > where > WH (h1, b) = fm a > class CoerceHistory a b where > coerceHistory :: [a] -> [b] > instance CoerceHistory a a where > coerceHistory = id > instance CoerceHistory a b where > coerceHistory _ = [] I have got the coerceHistory function to (appear to) work in GHCi *Main> coerceHistory [2::Int] :: [Int] [2] *Main> coerceHistory "c" :: [Int] [] But the Monad instanciation does not really work. GHC(7.6.3) hints for -XIncoherentInstances, which when enabled seems to force the (>>=) to always use the instance of coerceHistory returning [] The second approach is to use [Dynamic] for steps, i.e., > newtype WithHistory b = WH ([Dynamic], b) > instance Monad WithHistory where > return b = WH ([], b) > WH (h,a) >>= fm = WH (h1++forceDynList a++h, b) > where WH (h1, b) = fm a and presumably > class ForceDynList a where forceDynList :: a -> [Dynamic] > instance (Typeable a) => ForceDynList a where forceDynList x = [toDyn x] > instance ForceDynList a where forceDynList x = [] which is far from correct with error "Duplicate instance declarations" Thanks! Ducis -- ----------------------------- At 2018-11-18 20:00:01, 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. Timing out a pure evaluation of an expression I did not write > myself (Ryan Reich) > 2. Re: Timing out a pure evaluation of an expression I did not > write myself (Daniel Díaz Casanueva) > 3. Re: Timing out a pure evaluation of an expression I did not > write myself (Daniel Díaz Casanueva) > 4. Re: Timing out a pure evaluation of an expression I did not > write myself (Ryan Reich) > 5. Specialize a function on types of arguments? (ducis) > 6. Re: Specialize a function on types of arguments? (Anthony Clayden) > 7. Re: Timing out a pure evaluation of an expression I did not > write myself (arjenvanweelden(a)gmail.com) > 8. external git dependency source in .cabal (Fabien R) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Sat, 17 Nov 2018 15:21:53 -0800 >From: Ryan Reich <ryan.reich(a)gmail.com> >To: haskell-cafe <haskell-cafe(a)haskell.org> >Subject: [Haskell-cafe] Timing out a pure evaluation of an expression > I did not write myself >Message-ID: > <CAO8Ocku+=6GkyW-z8bShr7OSJppT_yPmrkcknF=UXYDn7+KBQg(a)mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >I want to time out a pure computation. My experience, and that described >in various previous questions here and elsewhere (the best of which is >https://mail.haskell.org/pipermail/haskell-cafe/2011-February/088820.html) >is that this doesn't always work: for instance, > >>>> timeout 1 $ evaluate $ let x = 0 : x in last x > >does not time out because, apparently, the fact that the expression >evaluates in constant space (i.e. never allocates) means that it never >yields to the timeout monitor thread that would kill it. > >The solution that is described in the other iterations is to embed >checkpoints in the expression that do allocate, giving the RTS a chance to >switch contexts. However, in my application, the expression is /arbitrary/ >and I do not have the freedom to inject alterations into it. (Don't argue >this point, please. The expression is arbitrary.) > >How can I time out a tight loop like the above? Clearly, it can be done, >because I can, say, alt-tab over to another terminal and kill the process, >which exploits the operating system's more aggressively pre-emptive >scheduling. Is there a solution using bound threads, say 'forkOS' instead >of 'forkIO' in the implementation of 'timeout'? Unix signals? Some >FFI-based workaround? Etc. Keep in mind that notwithstanding that >comment, I don't actually want to kill the whole process, but just the one >evaluation. > >Thanks in advance, >Ryan Reich >

2 1

external git dependency source in .cabal
by Fabien R 19 Nov '18

19 Nov '18

Hello, I'm trying to reference an external source of a package within a sandbox, using cabal 2.0.0.1: source-repository head type: git location: <git URL of pack1> executable myExe build-depends: base==4.10.1.0, pack1 -any But "cabal -v install --only-dependencies" fails: cabal: Encountered missing dependencies: pack1 -any Any hint ? -- Fabien

4 5

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 183, Issue 14
by ducis 19 Nov '18

19 Nov '18

Hi, Anthony, The top-level story is that I am trying to create a monad that somehow records the "intermediate steps" of computation. e.g. something like Prelude> return 1 ([],1) Prelude> return 1 >>= return.(+1) ([1],2) Prelude> return 1 >>= return.(+1)>>=return.(+3) ([2,1],5) (the list has the intermediate steps placed right-to-left so that new steps are appended to the left of the older steps) Of course all "intermediate steps of computation" actually form a graph, but we are frequently focused on, say, the transformation of a parse tree, where we want to take a series of snapshots of one "thing". Since a "lifted function" (e.g. return.(+1)) has in general the type a->m b, there are two ways to deal with input and output being not necessarily equal. The first approach I tried is to only record latest steps starting with the last change of type > newtype WithHistory b = WH ([b], b) and just discard the older steps when the input and output are of different types. > newtype WithHistory b = WH ([b], b) deriving (Show,Eq) > instance Monad WithHistory where > return b = WH ([], b) > (>>=) :: forall a b. WithHistory a -> (a -> WithHistory b) -> WithHistory b > WH (h,a) >>= fm = WH (h1++coerceHistory (a:h),b) > where > WH (h1, b) = fm a > class CoerceHistory a b where > coerceHistory :: [a] -> [b] > instance CoerceHistory a a where > coerceHistory = id > instance CoerceHistory a b where > coerceHistory _ = [] I have got the coerceHistory function to (appear to) work in GHCi *Main> coerceHistory [2::Int] :: [Int] [2] *Main> coerceHistory "c" :: [Int] [] But the Monad instanciation does not really work. GHC(7.6.3) hints for -XIncoherentInstances, which when enabled seems to force the (>>=) to always use the instance of coerceHistory returning [] The second approach is to use [Dynamic] for steps, i.e., > newtype WithHistory b = WH ([Dynamic], b) > instance Monad WithHistory where > return b = WH ([], b) > WH (h,a) >>= fm = WH (h1++forceDynList a++h, b) > where WH (h1, b) = fm a and presumably > class ForceDynList a where forceDynList :: a -> [Dynamic] > instance (Typeable a) => ForceDynList a where forceDynList x = [toDyn x] > instance ForceDynList a where forceDynList x = [] which is far from correct with error "Duplicate instance declarations" Thanks! Ducis -- ----------------------------- At 2018-11-18 20:00:01, 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. Timing out a pure evaluation of an expression I did not write > myself (Ryan Reich) > 2. Re: Timing out a pure evaluation of an expression I did not > write myself (Daniel Díaz Casanueva) > 3. Re: Timing out a pure evaluation of an expression I did not > write myself (Daniel Díaz Casanueva) > 4. Re: Timing out a pure evaluation of an expression I did not > write myself (Ryan Reich) > 5. Specialize a function on types of arguments? (ducis) > 6. Re: Specialize a function on types of arguments? (Anthony Clayden) > 7. Re: Timing out a pure evaluation of an expression I did not > write myself (arjenvanweelden(a)gmail.com) > 8. external git dependency source in .cabal (Fabien R) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Sat, 17 Nov 2018 15:21:53 -0800 >From: Ryan Reich <ryan.reich(a)gmail.com> >To: haskell-cafe <haskell-cafe(a)haskell.org> >Subject: [Haskell-cafe] Timing out a pure evaluation of an expression > I did not write myself >Message-ID: > <CAO8Ocku+=6GkyW-z8bShr7OSJppT_yPmrkcknF=UXYDn7+KBQg(a)mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >I want to time out a pure computation. My experience, and that described >in various previous questions here and elsewhere (the best of which is >https://mail.haskell.org/pipermail/haskell-cafe/2011-February/088820.html) >is that this doesn't always work: for instance, > >>>> timeout 1 $ evaluate $ let x = 0 : x in last x > >does not time out because, apparently, the fact that the expression >evaluates in constant space (i.e. never allocates) means that it never >yields to the timeout monitor thread that would kill it. > >The solution that is described in the other iterations is to embed >checkpoints in the expression that do allocate, giving the RTS a chance to >switch contexts. However, in my application, the expression is /arbitrary/ >and I do not have the freedom to inject alterations into it. (Don't argue >this point, please. The expression is arbitrary.) > >How can I time out a tight loop like the above? Clearly, it can be done, >because I can, say, alt-tab over to another terminal and kill the process, >which exploits the operating system's more aggressively pre-emptive >scheduling. Is there a solution using bound threads, say 'forkOS' instead >of 'forkIO' in the implementation of 'timeout'? Unix signals? Some >FFI-based workaround? Etc. Keep in mind that notwithstanding that >comment, I don't actually want to kill the whole process, but just the one >evaluation. > >Thanks in advance, >Ryan Reich >

2 2

education@haskell.org mailing list
by Chris Smith 19 Nov '18

19 Nov '18

Hello Haskellers, I'd like to invite you to join education(a)haskell.org This mailing list is a place to discuss the use of Haskell and similar languages (such as Elm, PureScript, ML, etc.) in education, particularly for broader audiences such as teaching children in schools, the broader public, etc. If this is of interest to you, I would like to invite you to join us. Please use this mailing list to talk about things you're doing in education, ask for advice or ideas or help with getting started, announce new projects, conferences, or research results, and/or seek collaborations with others. You can subscribe at https://mail.haskell.org/cgi-bin/mailman/listinfo/education If you're not yet involved in using Haskell in education, but are interested in the idea, please also join, and reach out for information. I started doing this about 7 years ago, and I've now taught something I love at a dozen different schools to hundreds of children, and it's been the most rewarding experience of my life. If you've got the interest and a bit of free time, I'd love to help you get started doing the same! Thanks, Chris Smith

1 0

ANN: LeanCheck v0.8.0 -- enumerative property testing
by Rudy Matela 18 Nov '18

18 Nov '18

Hello Haskell Café, A new version of LeanCheck is out (v0.8.0). LeanCheck is a property testing library (like QuickCheck) that tests values enumeratively. _Whats new?_ Among several changes, the most notable and significant are: * improvements in [LeanCheck's Haddock documentation]; * removal of a few experimental function enumeration modules; * and improved reporting of functional counter-examples (see below). [LeanCheck's changelog] provides more details. Take for example the following higher-order property that takes a functional argument and states an equivalence between `foldl` and `foldr`: prop_foldlr' :: (Int->Int->Int) -> Int -> [Int] -> Bool prop_foldlr' f z xs = foldl (flip f) z (reverse xs) == foldr f z xs You can check that it is correct by: > import Test.LeanCheck > import Test.LeanCheck.Function > check prop_foldlr' +++ OK, passed 200 tests. Now here is an incorrect version of the above property: prop_foldlr :: (A -> A -> A) -> A -> [A] -> Bool prop_foldlr f z xs = foldr f z xs == foldl f z xs You can check that it is incorrect by: > check prop_foldlr *** Failed! Falsifiable (after 75 tests): \x _ -> case x of 0 -> 1 _ -> 0 0 [0,0] LeanCheck reports the smallest counterexample it finds. The functional argument is now reported very concisely: a function that returns 1 whenever the first argument is 0 and returns 0 otherwise. Here's one last incorrect example property with two functional arguments: prop_mapFilter :: (Int->Int) -> (Int->Bool) -> [Int] -> Bool prop_mapFilter f p xs = filter p (map f xs) == map f (filter p xs) > check prop_mapFilter *** Failed! Falsifiable (after 36 tests): \_ -> 0 \x -> case x of 0 -> True _ -> False [1] The functions `map` and `filter` do not commute, the three values above are a counterexample. You can find LeanCheck on [Hackage] or [GitHub]. As usual, you can install it with: $ cabal install leancheck [Hackage]: https://hackage.haskell.org/package/leancheck [GitHub]: https://github.com/rudymatela/leancheck [LeanCheck's changelog]: https://hackage.haskell.org/package/leancheck/changelog [LeanCheck's Haddock documentation]: https://hackage.haskell.org/package/leancheck/docs/Test-LeanCheck.html

1 0

Re: [Haskell-cafe] Specialize a function on types of arguments?
by Anthony Clayden 18 Nov '18

18 Nov '18

Hi Ducis, > Is it possible to make combine the following "f" and "g" into one function? "combine" is vague. You perhaps mean: look at the types of the arguments, and choose one function or the other? > Looks like it would require some typeclasses, I'll answer the question as put (yes it needs typeclasses), but I can't help feel there's a backstory, and you might well be doing something that could be done better, if I knew what you're trying to achieve. Let's take the second one first > "eq1" and "eq2" into one function? > eq1 :: (Eq a)=>a->a->Bool > eq1 = (==) > eq2 :: (Eq a,Eq b)=>a->b->Bool > eq2 _ _ = False class Eqbytype a b where eqt :: a -> b -> Bool instance {-# OVERLAPPING #-} (Eq a) => Eqbytype a a where eqt = (==) instance {-# OVERLAPPABLE #-} Eqbytype a b where eqt _ _ = False Look at the Users Guide for what the OVERLAPPING/OVERLAPPABLE pragmas are doing. Note for the first instance I repeated type var `a` in the head, meaning: pick this instance if the two arguments to the method are of the same type. Note for the second instance, I didn't bother with the `Eq` constraint, since we can't compare values of distinct types. > f:: a -> b -> b > f x y = y > g:: a -> a -> a > g x y = x So you want same argument types to drive which argument to pick? Or you want the return type to drive which argument? That's possible: look at the definition of class `Read` in the Prelude. Again we can pick instances depending on a repeated type. But your requirements are not clear. > but at least in the first case [which I've put second], "a" and "b" should be any types. No they can't: as you state it, you require either all three the same, or the second to be the same as the return type. Come back and ask a more focussed question once you've worked through the above. (And explain why you're asking.) The above code is untested, BTW. AntC

1 0

Specialize a function on types of arguments?
by ducis 18 Nov '18

18 Nov '18

Hi, everyone, Is it possible to make combine the following "f" and "g" into one function? f:: a -> b -> b f x y = y g:: a -> a -> a g x y = x Or similarly, "eq1" and "eq2" into one function? eq1 :: (Eq a)=>a->a->Bool eq1 = (==) eq2 :: (Eq a,Eq b)=>a->b->Bool eq2 _ _ = False Looks like it would require some typeclasses, but at least in the first case, "a" and "b" should be any types. Best!

1 0

wxneeded on OpenBSD
by Alexander Ben Nasrallah 16 Nov '18

16 Nov '18

Hello Haskell-Cafe, I hope this is the right place for my question. Is there any progress or news on getting rid of the wxneeded flag on OpenBSD? https://phabricator.haskell.org/D2454 mentions a new ticket but I can't find any. Thanks Alex

2 2

Request for Haskell account
by Aleksandar Lukac 13 Nov '18

13 Nov '18

Hello, I would like to have Haskell account. I would like to start to solve 99 problems and to submit it. My name is Aleksandar Lukac, and i would like to have similar user name Aeksandar, Lukac or aleksandar.lukac or something likewise for example Aleksandar111 Thank you in advance *Aleksandar Lukač* | *Koordinator volontera**- Half Marathon ”MTEL City Race Banja Luka 2015” * *p**:* +387 66 40 77 22 *e*: lukaclukacbanjalukamaraton(a)gmail.com <banjalukamaraton(a)gmail.com> | *w:* banjalukamarathon.com

2 2

find functions that produce / consume a type?
by Johannes Waldmann 11 Nov '18

11 Nov '18

Dear Cafe, can we automate something like the following for any type T that appears in signatures (shown by haddock), add (separate) lists of "functions that produce T", "functions that consume T". Hoogle can type-search approximately, but * it would always (want to) match the full type AST (matching with a subtree incurs a penalty?), * and not distinguish between producer and consumer? E.g., https://ndmitchell.com/downloads/slides-hoogle_finding_functions_from_types… Slide #29 "Per Argument Searching" uses "search arguments", "search results" - only to merge the results immediately. Can we keep them separate? - J.W.

3 2

Fwd: [Haskell] [ANNOUNCE] GHC 8.6.2 is now available
by Dan Burton 10 Nov '18

10 Nov '18

(fwd to the real haskell cafe list) -- Dan Burton ---------- Forwarded message --------- From: Dan Burton <danburton.email(a)gmail.com> Date: Sat, Nov 10, 2018 at 11:30 AM Subject: Re: [Haskell] [ANNOUNCE] GHC 8.6.2 is now available To: Ben Gamari <ben(a)well-typed.com> Cc: Haskell-cafe <haskell-cafe(a)googlegroups.com> I have two trivialities to bring up: 1. Could you update https://downloads.haskell.org/~ghc/latest/ to point to 8.6.2? (It's currently showing 8.6.1.) 2. The SHA1SUMS and SHA256SUMS for 8.6.2 list a file "./ghc-8.6.2-x86_64-darwin.tar.xz", but that is a broken link; the corresponding file is found at "./ghc-8.6.2-x86_64*-apple*-darwin.tar.xz". Can these be harmonized? Thanks! -- Dan Burton On Mon, Nov 5, 2018 at 11:29 AM Ben Gamari <ben(a)well-typed.com> wrote: > Hello everyone, > > The GHC team is very happy to announce the availability of GHC 8.6.2, a > bugfix release to GHC 8.6.1. The source distribution, binary > distributions, and documentation for this release are available at > > https://downloads.haskell.org/~ghc/8.6.2 > > The 8.6 release fixes several regressions present in 8.6.1 including: > > * A long-standing (but previously hard to manifest) bug resulting in > undefined behavior for some applications of dataToTag# has been fixed > (#15696) > > * An incorrect linker path to libgmp in the Mac OS binary distributions > (#15404) > > * A regression rendering Windows installations to read-only directories > unusable (#15667) > > * A regression resulting in panics while compiling some record updates > of GADTs constructors (#15499) > > * A regression resulting in incorrect type errors when splicing types > into constraint contexts has been fixed (#15815) > > * Around a dozen other issues. > > See Trac [1] for a full list of issues resolved in this release. > > Note that this release ships with one significant but long-standing bug > (#14251): Calls to functions taking both Float# and Double# may result > in incorrect code generation when compiled using the LLVM code generator. > This is not a new issue, it has existed as long as the LLVM code > generator has existed; however, changes in code generation in 8.6 made > it more likely that user code using only lifted types will trigger it. > > Happy compiling! > > Cheers, > > - Ben > > > > [1] > https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.2&col=id… > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell >

1 0

First Call for Papers: PACMPL issue ICFP 2019
by Sam Tobin-Hochstadt 09 Nov '18

09 Nov '18

PACMPL Volume 3, Issue ICFP 2019 Call for Papers accepted papers to be invited for presentation at The 24th ACM SIGPLAN International Conference on Functional Programming Berlin, Germany http://icfp19.sigplan.org/ ### Important dates Submissions due: 1 March 2019 (Friday) Anywhere on Earth https://icfp19.hotcrp.com Author response: 16 April (Tuesday) - 18 Apri (Friday) 14:00 UTC Notification: 3 May (Friday) Final copy due: 22 June (Saturday) Conference: 18 August (Sunday) - 23 August (Friday) ### About PACMPL Proceedings of the ACM on Programming Languages (PACMPL <https://pacmpl.acm.org/>) is a Gold Open Access journal publishing research on all aspects of programming languages, from design to implementation and from mathematical formalisms to empirical studies. Each issue of the journal is devoted to a particular subject area within programming languages and will be announced through publicized Calls for Papers, like this one. ### Scope [PACMPL](https://pacmpl.acm.org/) issue ICFP 2019 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * *Language Design*: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; type systems; interoperability; domain-specific languages; and relations to imperative, object-oriented, or logic programming. * *Implementation*: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources. * *Software-Development Techniques*: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling. * *Foundations*: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types. * *Analysis and Transformation*: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation. * *Applications*: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia and 3D graphics programming; scripting; system administration; security. * *Education*: teaching introductory programming; parallel programming; mathematical proof; algebra. Submissions will be evaluated according to their relevance, correctness, significance, originality, and clarity. Each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. PACMPL issue ICFP 2019 also welcomes submissions in two separate categories — Functional Pearls and Experience Reports — that must be marked as such at the time of submission and that need not report original research results. Detailed guidelines on both categories are given at the end of this call. Please contact the principal editor if you have questions or are concerned about the appropriateness of a topic. ### Preparation of submissions **Deadline**: The deadline for submissions is **Friday, March 1, 2019**, Anywhere on Earth (<https://en.wikipedia.org/wiki/Anywhere_on_Earth>). This deadline will be strictly enforced. **Formatting**: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from <https://www.acm.org/publications/authors/submissions>. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from <http://sigplan.org/Resources/Author/#acmart-format>. There is a limit of **25 pages for a full paper or Functional Pearl** and **12 pages for an Experience Report**; in either case, the bibliography will not be counted against these limits. Submissions that exceed the page limits or, for other reasons, do not meet the requirements for formatting, will be summarily rejected. Supplementary material can and should be **separately** submitted (see below). See also PACMPL's Information and Guidelines for Authors at <https://pacmpl.acm.org/authors.cfm>. **Submission**: Submissions will be accepted at <https://icfp19.hotcrp.com/> Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. **Author Response Period**: Authors will have a 72-hour period, starting at 14:00 UTC on **Tuesday, April 16, 2019**, to read reviews and respond to them. **Supplementary Material**: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should **not** be submitted as part of the main document; instead, it should be uploaded as a **separate** PDF document or tarball. Supplementary material should be uploaded **at submission time**, not by providing a URL in the paper that points to an external repository. Authors are free to upload both anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). **Authorship Policies**: All submissions are expected to comply with the ACM Policies for Authorship that are detailed at <https://www.acm.org/publications/authors/information-for-authors>. **Republication Policies**: Each submission must adhere to SIGPLAN's republication policy, as explained on the web at <http://www.sigplan.org/Resources/Policies/Republication>. **Resubmitted Papers**: Authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the principal editor will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. ### Review Process This section outlines the two-stage process with lightweight double-blind reviewing that will be used to select papers for PACMPL issue ICFP 2019. We anticipate that there will be a need to clarify and expand on this process, and we will maintain a list of frequently asked questions and answers on the conference website to address common concerns. **PACMPL issue ICFP 2019 will employ a two-stage review process.** The first stage in the review process will assess submitted papers using the criteria stated above and will allow for feedback and input on initial reviews through the author response period mentioned previously. At the review meeting, a set of papers will be conditionally accepted and all other papers will be rejected. Authors will be notified of these decisions on **May 3, 2019**. Authors of conditionally accepted papers will be provided with committee reviews (just as in previous conferences) along with a set of mandatory revisions. After four weeks (May 31, 2019), the authors will provide a second submission. The second and final reviewing phase assesses whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. The intent and expectation is that the mandatory revisions can be addressed within four weeks and hence that conditionally accepted papers will in general be accepted in the second phase. The second submission should clearly identify how the mandatory revisions were addressed. To that end, the second submission must be accompanied by a cover letter mapping each mandatory revision request to specific parts of the paper. The cover letter will facilitate a quick second review, allowing for confirmation of final acceptance within two weeks. Conversely, the absence of a cover letter will be grounds for the paper’s rejection. **PACMPL issue ICFP 2019 will employ a lightweight double-blind reviewing process.** To facilitate this, submitted papers must adhere to two rules: 1. **author names and institutions must be omitted**, and 2. **references to authors' own related work should be in the third person** (e.g., not "We build on our previous work ..." but rather "We build on the work of ..."). The purpose of this process is to help the reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. ### Information for Authors of Accepted Papers * As a condition of acceptance, final versions of all papers must adhere to the new ACM Small format. The page limit for the final versions of papers will be increased by two pages to help authors respond to reviewer comments and mandatory revisions: **27 pages plus bibliography for a regular paper or Functional Pearl, 14 pages plus bibliography for an Experience Report**. * Authors of accepted submissions will be required to agree to one of the three ACM licensing options: open access on payment of a fee (**recommended**, and SIGPLAN can cover the cost as described next); copyright transfer to ACM; or retaining copyright but granting ACM exclusive publication rights. Further information about ACM author rights is available from <http://authors.acm.org>. * PACMPL is a Gold Open Access journal. It will be archived in ACM’s Digital Library, but no membership or fee is required for access. Gold Open Access has been made possible by generous funding through ACM SIGPLAN, which will cover all open access costs in the event authors cannot. Authors who can cover the costs may do so by paying an Article Processing Charge (APC). PACMPL, SIGPLAN, and ACM Headquarters are committed to exploring routes to making Gold Open Access publication both affordable and sustainable. * ACM offers authors a range of copyright options, one of which is Creative Commons CC-BY publication; this is the option recommended by the PACMPL editorial board. A reasoned argument in favour of this option can be found in the article [Why CC-BY?](https://oaspa.org/why-cc-by/) published by OASPA, the Open Access Scholarly Publishers Association. * We intend that the papers will be freely available for download from the ACM Digital Library in perpetuity via the OpenTOC mechanism. * ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking to the definitive version of an ACM article should reduce user confusion over article versioning. After an article has been published and assigned to the appropriate ACM Author Profile pages, authors should visit <http://www.acm.org/publications/acm-author-izer-service> to learn how to create links for free downloads from the ACM DL. * At least one author of each accepted submissions will be expected to attend and present their paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. Presentations will be videotaped and released online if the presenter consents. * The official publication date is the date the papers are made available in the ACM Digital Library. This date may be up to *two weeks prior* to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. ### Artifact Evaluation Authors of papers that are conditionally accepted in the first phase of the review process will be encouraged (but not required) to submit supporting materials for Artifact Evaluation. These items will then be reviewed by an Artifact Evaluation Committee, separate from the paper Review Committee, whose task is to assess how the artifacts support the work described in the associated paper. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Authors of accepted papers will be encouraged to make the supporting materials publicly available upon publication of the papers, for example, by including them as "source materials" in the ACM Digital Library. An additional seal will mark papers whose artifacts are made available, as outlined in the ACM guidelines for artifact badging. Participation in Artifact Evaluation is voluntary and will not influence the final decision regarding paper acceptance. ### Special categories of papers In addition to research papers, PACMPL issue ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to half the length of a full paper. Authors submitting such papers should consider the following guidelines. #### Functional Pearls A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: * a new and thought-provoking way of looking at an old idea * an instructive example of program calculation or proof * a nifty presentation of an old or new data structure * an interesting application of functional programming techniques * a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. A pearl is likely to be rejected if its readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission that is intended to be treated as a pearl must be marked as such on the submission web page, and should contain the words "Functional Pearl" somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. <a name="experience-reports"></a> #### Experience Reports The purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works — or to describe what obstacles prevent it from working. Possible topics for an Experience Report include, but are not limited to: * insights gained from real-world projects using functional programming * comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum * project-management, business, or legal issues encountered when using functional programming in a real-world project * curricular issues encountered when using functional programming in education * real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report is distinguished from a normal PACMPL issue ICFP paper by its title, by its length, and by the criteria used to evaluate it. * Both in the papers and in any citations, the title of each accepted Experience Report must end with the words "(Experience Report)" in parentheses. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. * Experience Report submissions can be at most 12 pages long, excluding bibliography. * Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks. * Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The review committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point: it should make a claim about how well functional programming worked on a particular project and why, and produce evidence to substantiate this claim. If functional programming worked in this case in the same ways it has worked for others, the paper need only summarize the results — the main part of the paper should discuss how well it worked and in what context. Most readers will not want to know all the details of the project and its implementation, but the paper should characterize the project and its context well enough so that readers can judge to what degree this experience is relevant to their own projects. The paper should take care to highlight any unusual aspects of the project. Specifics about the project are more valuable than generalities about functional programming; for example, it is more valuable to say that the team delivered its software a month ahead of schedule than it is to say that functional programming made the team more productive. If the paper not only describes experience but also presents new technical results, or if the experience refutes cherished beliefs of the functional-programming community, it may be better to submit it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. The principal editor will be happy to advise on any concerns about which category to submit to. ### ICFP Organizers General Chair: Derek Dreyer (MPI-SWS, Germany) Artifact Evaluation Co-Chairs: Simon Marlow (Facebook, UK) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organiser: Ilya Sergey (Yale-NUS College, Singapore) Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: William J. Bowman (University of British Columbia, Canada) Workshops Co-Chair: Christophe Scholliers (Universiteit Gent, Belgium) Jennifer Hackett (University of Nottingham, UK) Conference Manager: Annabel Satin (P.C.K.) ### PACMPL Volume 3, Issue ICFP 2019 Principal Editor: François Pottier (Inria, France) Review Committee: Lennart Beringer (Princeton University, United States) Joachim Breitner (DFINITY Foundation, Germany) Laura M. Castro (University of A Coruña, Spain) Ezgi Çiçek (Facebook London, United Kingdom) Pierre-Evariste Dagand (LIP6/CNRS, France) Christos Dimoulas (Northwestern University, United States) Jacques-Henri Jourdan (CNRS, LRI, Université Paris-Sud, France) Andrew Kennedy (Facebook London, United Kingdom) Daan Leijen (Microsoft Research, United States) Kazutaka Matsuda (Tohoku University, Japan) Bruno C. d. S. Oliveira (University of Hong Kong, China) Klaus Ostermann (University of Tübingen, Germany) Jennifer Paykin (Galois, United States) Frank Pfenning (Carnegie Mellon University, USA) Mike Rainey (Indiana University, USA) Chung-chieh Shan (Indiana University, USA) Sam Staton (University of Oxford, UK) Pierre-Yves Strub (Ecole Polytechnique, France) German Vidal (Universitat Politecnica de Valencia, Spain) External Review Committee: Michael D. Adams (University of Utah, USA) Robert Atkey (University of Strathclyde, IK) Sheng Chen (University of Louisiana at Lafayette, USA) James Cheney (University of Edinburgh, UK) Adam Chlipala (Massachusetts Institute of Technology, USA) Evelyne Contejean (LRI, Université Paris-Sud, France) Germán Andrés Delbianco (IRIF, Université Paris Diderot, France) Dominique Devriese (Vrije Universiteit Brussel, Belgium) Richard A. Eisenberg (Bryn Mawr College, USA) Conal Elliott (Target, USA) Sebastian Erdweg (Delft University of Technology, Netherlands) Michael Greenberg (Pomona College, USA) Adrien Guatto (IRIF, Université Paris Diderot, France) Jennifer Hackett (University of Nottingham, UK) Troels Henriksen (University of Copenhagen, Denmark) Chung-Kil Hur (Seoul National University, Republic of Korea) Roberto Ierusalimschy (PUC-Rio, Brazil) Ranjit Jhala (University of California, San Diego, USA) Ralf Jung (MPI-SWS, Germany) Ohad Kammar (University of Oxford, UK) Oleg Kiselyov (Tohoku University, Japan) Hsiang-Shang ‘Josh’ Ko (National Institute of Informatics, Japan) Ondřej Lhoták (University of Waterloo, Canada) Dan Licata (Wesleyan University, USA) Geoffrey Mainland (Drexel University, USA) Simon Marlow (Facebook, UK) Akimasa Morihata (University of Tokyo, Japan) Shin-Cheng Mu (Academia Sinica, Taiwan) Guillaume Munch-Maccagnoni (Inria, France) Kim Nguyễn (University of Paris-Sud, France) Ulf Norell (Gothenburg University, Sweden) Atsushi Ohori (Tohoku University, Japan) Rex Page (University of Oklahoma, USA) Zoe Paraskevopoulou (Princeton University, USA) Nadia Polikarpova (University of California, San Diego, USA) Jonathan Protzenko (Microsoft Research, USA) Tiark Rompf (Purdue University, USA) Andreas Rossberg (Dfinity, Germany) KC Sivaramakrishnan (University of Cambridge, UI) Nicholas Smallbone (Chalmers University of Technology, Sweden) Matthieu Sozeau (Inria, France) Sandro Stucki (Chalmers | University of Gothenburg, Sweden) Don Syme (Microsoft, UK) Zachary Tatlock (University of Washington, USA) Sam Tobin-Hochstadt (Indiana University, USA) Takeshi Tsukada (University of Tokyo, Japan) Tarmo Uustalu (Reykjavik University, Iceland) Benoit Valiron (LRI, CentraleSupelec, Univ. Paris Saclay, France) Daniel Winograd-Cort (University of Pennsylvania, USA) Nicolas Wu (University of Bristol, UK)

1 0

Feedback on Haskell theme redesign
by Alec Theriault 09 Nov '18

09 Nov '18

Hi all, There’s been an ongoing effort to redesign Haddock’s theme to match the new purple Hackage theme. Nuno Alexandre, the original author of these changes, has [blogged][0] and [posted to reddit][1] about this before (and gotten positive feedback), but it’s only now that we are actually on the verge of merging these changes. I’ve generated sample docs for the Haskell Hierarchical Libraries (that includes a bunch of packages including `base`, `containers`, `template-haskell`, and `parsec`). You can compare the new theme to the old one via the “style” dropdown in the top right corner: https://harpocrates.github.io/ghc-head-libraries If you have time to spare, it would be very helpful to gather feedback to further optimize/tune the existing work prior to merging. The Haddock pull request on GitHub is the best place to collect that feedback: https://github.com/haskell/haddock/pull/949. Whenever relevant, please accompany issues and suggestions with screenshots! Thanks in advance, Alec Theriault [0]: https://nunoalexandre.com/2018/02/04/redesigning-haskell-docs [1]: https://www.reddit.com/r/haskell/comments/7vatew/redesigning_haddock_docs_a…

2 1

Why doesn't this consume all the computer's memory?
by Tyson Whitehead 08 Nov '18

08 Nov '18

I would expect the following to consume all the computer's memory and die due to a buildup of lazy pattern matches for the `y` value. ``` import Data.Either main = print x >> print y where (length -> x, length -> y) = paritionEithers $ repeat (Left ()) ``` That is, `partitionEithers` is ``` partitionEithers :: [Either a b] -> ([a],[b]) partitionEithers = foldr go ([],[]) where go (Left x) ~(xs,ys) = (x:xs,ys) go (Right y) ~(xs,ys) = (xs,y:ys) ``` and, in the -ddump-simpl we see the `go Left` branch returns a thunk on both the right and left sides that hold onto the evaluation of (x:xs,ys) as we would expect ``` Left x_aqy -> (GHC.Types.: @ a_a1q8 x_aqy (case ds1_d1rO of { (xs_aqz, ys_aqA) -> xs_aqz }), case ds1_d1rO of { (xs_aqz, ys_aqA) -> ys_aqA }); ``` Our code keeps generating more and more of these thunks as the left-hand side chases down the infinite list of `Left ()` values, and the machine cannot let go of them because, as far as it knows, we are going to reach the end sometime and then need the right-hand side. Thus I expect it would consume all the memory and crash. But it doesn't. It just sits there forever consuming 100% CPU at a constant memory limit. This means my mental model is defective and I'm unable to properly reason about the space usage of my programs. Could someone please enlighten me as to were I'm missing? Is there some sort of optimization going on here? When can it be depend on? Thanks very much! -Tyson I would expect

4 9

Help understanding this type
by Guru Devanla 08 Nov '18

08 Nov '18

Hello Haskell-Cafe, I have been recently studying the XMonad code and some related types available in the X11 bindings library. I came across this type: newtype XEvent = XEvent XEventPtr type XEventPtr = Ptr <http://hackage.haskell.org/package/base-4.10.1.0/docs/Foreign-Ptr.html#t:Ptr> XEvent <http://hackage.haskell.org/package/X11-1.9/docs/Graphics-X11-Xlib-Event.htm…> Available here: http://hackage.haskell.org/package/X11-1.9/docs/Graphics-X11-Xlib-Event.htm… It seems that this type is circular here. how does one use this type? Is it possible to create a value out of this type? What is the use of this type? Please could someone help me wrap my head around this? Thanks

6 7

Looking for feedback on my beginner's Haskell resource
by André Popovitch 06 Nov '18

06 Nov '18

If you follow /r/haskell you may have seen it posted there as well, but I've written a short guide called Wise Man's Haskell <https://andre.tips/wmh/> which I hope people will find useful. However, I'm not extremely knowledgeable about Haskell and I wouldn't say I'm the best teacher, so if anyone is willing to skim it or provide feedback that would be much appreciated!

6 11

Network deprecation
by Evan Laforge 06 Nov '18

06 Nov '18

I'm starting to get deprecation warnings about Network in the network package. I know this has been in the works for a long time, but now that I search I can't find any info about the rationale and suggested replacement (the deprecation message suggests Network.Socket, but this is a completely different lower level api). Does anyone out there have links to discussions, articles, or whatnot? Thanks in advance!

3 4

reading file content with conduit
by Fabien R 05 Nov '18

05 Nov '18

Hello, I have a strange behaviour with my code when reading data from a file saved by sinkFile. I only see the first record of the file, although the file seems to contain several records. Any hints ? -- built in a sandbox with GHC 8.2.2, base 4.10.1.0, binary 0.8.5.1, bytestring 0.8.10.2, conduit 1.3.1 {-# LANGUAGE DeriveGeneric #-} import qualified Data.ByteString as DB import qualified Data.ByteString.Lazy as DBL import qualified Data.Binary as DBI import GHC.Generics (Generic) import Conduit import Data.Int (Int64) data MySubRec = MySubRec { sr1 :: Float, sr2 :: Float } deriving (Generic, Show) data MyRec = MyRec { r1 :: Int64, r2 :: String, r3 :: [MySubRec], r4 :: [MySubRec] } deriving (Generic, Show) instance DBI.Binary MySubRec instance DBI.Binary MyRec es = MySubRec { sr1 =1.0, sr2 =1000.5 } myList = repeat es e1 = MyRec{ r1=1, r2="e1", r3=take 2 myList, r4=take 1 myList} e2 = MyRec{ r1=2, r2="e2", r3=take 2 myList, r4=take 1 myList} myData = concat $ repeat [e1,e2] dataToBs :: Monad m => ConduitT MyRec DB.ByteString m () dataToBs = do d <- await case d of Just bs -> do yield $ DBL.toStrict $ DBI.encode bs dataToBs _ -> return () bsToData :: Monad m => ConduitT DB.ByteString MyRec m () bsToData = do d <- await case d of Just bs -> do yield $ DBI.decode $ DBL.fromStrict bs bsToData _ -> return () main = do runConduitRes $ yieldMany (take 10 myData) .| dataToBs .| sinkFile "/tmp/res.bin" runConduitRes $ sourceFile "/tmp/res.bin" .| bsToData .| mapM_C (liftIO . putStrLn . show)

2 3

Journal of Functional Programming - Call for PhD Abstracts
by Graham Hutton 05 Nov '18

05 Nov '18

Dear all, If you or one of your students recently completed a PhD in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, open access, deadline 30th November 2018. Please share! Best wishes, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 30th November 2018 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton <graham.hutton(a)nottingham.ac.uk> by 30th November 2018. o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 350 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting; if your original abstract exceeds the word limit, please submit an abridged version within the limit) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

Re: [Haskell-cafe] Looking for feedback on my beginner's Haskell resource
by Olaf Klinke 03 Nov '18

03 Nov '18

This guide would be a perfect fit for literate Haskell [1]. It is a file format where you mix markup (e.g. LaTeX) and Haskell, so the file can be interpreted either way. In a nutshell, your html content becomes Haskell comments or the Haskell becomes <code> blocks in html. In that way, your readers could just load your document into ghci and play with it. Not sure whether html is supported out of the box, though. You might need to pass the .lhs file through pandoc [2] or another tool. Can anyone clarify/help on this? Cheers, Olaf [1] https://wiki.haskell.org/Literate_programming [2] https://groups.google.com/forum/#!topic/hakyll/lFfHAk2nxbs

1 0

Get number of fields for non-record ADTs using Data type class?
by Markus Läll 03 Nov '18

03 Nov '18

Dear list, Is it possible te get the number of fields for data constructors for a plain ADT, i.e something with no record fields? E.g for data T = A Int Double | B String (Maybe String) it would give 2 for both `A` and `B`. For a record it's possible using the `constrFields` function from Data.Data. I was trying to follow this tutorial by Christopher Done https://chrisdone.com/posts/data-typeable, and I feel that it must be possible somehow to get these numbers with the gmap*/gfold* functions, but the use of them is over my head at the moment. Best, -- Markus Läll

3 5

Re: [Haskell-cafe] 2018 State of Haskell Survey
by Doug McIlroy 03 Nov '18

03 Nov '18

The survey didn't work for me in either Internet Explorer or Microsoft Edge: In IE an attempt to scroll a pull-down "Add an option" menu would dismiss the menu. In ME the same menus needed a scroll bar, but the bar was missing. Doug McIlroy

1 0

2018 State of Haskell Survey
by Jasper Van der Jeugt 02 Nov '18

02 Nov '18

Hi all, (apologies if you receive multiple copies of this email) We are running a 2018 State of Haskell Survey here: https://airtable.com/shr8G4RBPD9T6tnDf If you have some time to spare, please submit a response. This goes a long way in helping the community. The survey closes on the 15th of November. This survey is co-sponsored by Haskell.org and Haskell Weekly, but I'd like to give credit where credit is due, so I'll add that Taylor Fausak did almost all of the hard work -- thanks a lot! Kind regards Jasper Van der Jeugt on behalf of the Haskell.org committee

2 1

Intention to Take Over adblock2privoxy Hackage Package
by Steven Smith 30 Oct '18

30 Oct '18

Dear Haskell Cafe, I’m writing to publicly state my intention to take over the adblock2privoxy Hackage package: http://hackage.haskell.org/package/adblock2privoxy <http://hackage.haskell.org/package/adblock2privoxy> using the forked github repo at: https://github.com/essandess/adblock2privoxy <https://github.com/essandess/adblock2privoxy> I have been unable to contact the package’s creator/maintainer at the email provided, and the original repo <https://projects.zubr.me/wiki/adblock2privoxy> has not been updated for several years. I forked this project about a year and a half ago, and since then have addressed <https://github.com/essandess/adblock2privoxy/commits/master> many issues and incorporated feedback and fixed from the github community, including compilation with the most recent GHC compiler. I am following up on a suggestion made here to publish the latest version in Hackage, following the procedure to take over a package: https://github.com/essandess/adblock2privoxy/pull/29#issue-215776931 <https://github.com/essandess/adblock2privoxy/pull/29#issue-215776931> https://wiki.haskell.org/Taking_over_a_package <https://wiki.haskell.org/Taking_over_a_package> My Hackage username is essandess. Sincerely, Steve

1 0

Call For Workshop Proposals
by Sam Tobin-Hochstadt 30 Oct '18

30 Oct '18

CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS ICFP 2019 24th ACM SIGPLAN International Conference on Functional Programming August 18 - 23, 2019 Berlin, Germany https://icfp19.sigplan.org/ The 24th ACM SIGPLAN International Conference on Functional Programming will be held in Berlin, Germany on August 18-23, 2019. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as symposiums) to be affiliated with ICFP 2019 and sponsored by SIGPLAN. These events should be less formal and more focused than ICFP itself, include sessions that enable interaction among the attendees, and foster the exchange of new ideas. The preference is for one-day events, but other schedules can also be considered. The workshops are scheduled to occur on August 18th (the day before ICFP) and 22-23th of August (the two days after ICFP). ---------------------------------------------------------------------- Submission details Deadline for submission: November 25, 2018 Notification of acceptance: December 23, 2018 Prospective organizers of workshops or other co-located events are invited to submit a completed workshop proposal form in plain text format to the ICFP 2019 workshop co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019(a)googlegroups.com by November 25, 2018. (For proposals of co-located events other than workshops, please fill in the workshop proposal form and just leave blank any sections that do not apply.) Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by December 23, 2018, and if successful, depending on the event, they will be asked to produce a final report after the event has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2019-files/icfp19-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://www.sigplan.org/Resources/Proposals/Sponsored/ ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2019 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Jennifer Hackett (University of Nottingham) Workshop Co-Chair: Christophe Scholliers (University of Ghent) General Chair: Derek Dreyer (MPI-SWS) Program Chair: François Potier (Inria) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019(a)googlegroups.com

1 0

ANN: Major releases of 'fltkhs-themes' and 'fltkhs' for nice looking, portable native GUIs
by aditya siram 28 Oct '18

28 Oct '18

I'm happy to announce two major releases: fltkhs-themes [1] : a drop-in replacement to FLTKHS [2] with a vastly better looking UX [3] . The small but growing showcase app should hopefully give a better feel for it. And to help you get started with your own project there is a starter app [7] and a lot more documentation [8]. fltkhs[2]: the underlying GUI binding to FLTK which after nearly 6 months of continuous work has been overhauled with a ton of bug fixes and shoring up of the API (fixing leaks, making types more precise via newtypes etc.) and new features have been added including new widgets and out-of-the-box HiDPI and SVG support (which fltkhs-themes relies on heavily for nicer widgets). All the starter kits and demo packages have been updated to this version. If you need help migrating an existing app to the new API feel free to send email to the address on Hackage page or hit me up on Twitter. There a lot more documentation on installation and getting started in the Hackage docs [4]. As always if you have any problems please open an issue on fltkhs [5], fltkhs-themes or any of my other repos. Hopefully these releases help you make Haskell native GUI apps that are fast, portable, easy to install/deploy, and nice looking! [1] http://hackage.haskell.org/package/fltkhs-themes [2] http://hackage.haskell.org/package/fltkhs [3] https://github.com/deech/fltkhs-themes-demo#screenshots [4] http://hackage.haskell.org/package/fltkhs/docs/Graphics-UI-FLTK-LowLevel-FL… [5] https://github.com/deech/fltkhs/issues [6] https://github.com/deech/fltkhs-themes/issues [7] https://github.com/deech/fltkhs-light-theme-skeleton [8] http://hackage.haskell.org/package/fltkhs-themes/docs/Graphics-UI-FLTK-Them…

1 0