- Haskell-Cafe - Haskell.org

Call for Haskell.org Committee Nominations
by Jasper Van der Jeugt 09 Dec '19

09 Dec '19

Dear Haskellers, It is time to put out a call for new nominations (typically but not necessarily self-nominations) to the Haskell.org committee. We have three members of our committee due for retirement -- Jasper Van der Jeugt, Niki Vazou, and Mitsutoshi Aoe. To nominate yourself, please send an email to committee at haskell.org by the 7th of January, 2020. The retiring members are eligible to re-nominate themselves. Please feel free to include any information about yourself that you think will help us to make a decision. The Haskell.org committee serves as a board of directors for Haskell.org, a 501(c)3 nonprofit which oversees technical and financial resources related to Haskell community infrastructure. Being a member of the committee does not necessarily require a significant amount of time, but committee members should aim to be responsive during discussions when the committee is called upon to make a decision. Strong leadership, communication, and judgement are very important characteristics for committee members. The role is about setting policy, providing direction/guidance for Haskell.org infrastructure, planning for the long term, and being fiscally responsible with the Haskell.org funds (and donations). As overseers for policy regarding the open source side of Haskell, committee members must also be able to set aside personal or business related bias and make decisions with the good of the open source Haskell community in mind. We seek a broad representation from different segments of the Haskell world -- including but not limited to those focused on education, those focused on industrial applications, those with background in organizing users-groups, and those focused directly on our technical infrastructure. More details about the committee's roles and responsibilities are on https://wiki.haskell.org/Haskell.org_committee If you have any questions about the process, please feel free to e-mail us at committee at haskell.org, or contact one of us individually. Warm regards, Jasper Van der Jeugt

1 0

ZuriHac 2020 (12-14 June) registration is now open
by Jasper Van der Jeugt 06 Dec '19

06 Dec '19

Hi Haskell friends! We are happy to announce that ZuriHac 2020 will take place from Friday the 12th to Sunday the 14th of June, hosted again at the HSR (https://www.hsr.ch/) on the shores of beautiful Lake Zurich. You can find all the information on: https://zurihac.com The Zurich Haskell Hackathon is a free, international, grassroots, and collaborative coding festival. Our goal is to nourish the Haskell community, learn exciting new things, and to have fun working on projects together. This year, we are already excited to announce talks by: - Alexis King - Rob Rix More speakers will be announced later. In addition to talks, we will offer beginner, intermediate, and advanced tracks, similar to last year. The details of this will also be communicated in the coming months. The event is open to any experience level, from beginners to gurus. If you are completely new to Haskell, rest assured that there will be tutorials for you to take, and a bunch of friendly advanced Haskellers to answer your questions and help you along. We will have space for 500 attendees, making this the largest Haskell gathering that we know of! Registration is free and open as of right now: https://zurihac.com/#registration We would also like to thank the Hochschule für Technik Rapperswil for their amazing support and for hosting us again this year. Without them, an event of this scale and quality would be extremely difficult to pull off. We can't wait to see you in June, The Zurich Friends of Haskell (https://zfoh.ch/)

1 0

[RFC] Constraint based arrow notation (GHC proposal)
by Alexis King 06 Dec '19

06 Dec '19

Hello all, I have recently written a GHC proposal to change the typechecking rules for arrow notation (aka `proc`) to better support custom control operators. Specifically, it reverses a change made in GHC 7.8 due to technical limitations that requires control operators to have significantly uglier types. Although arrows have fallen out of favor with the Haskell community in recent years, presumably there are still at least a few users. If you use `proc` notation, and especially if you use its support for custom control operators (i.e. (| banana brackets |)), your feedback would be highly valued. To read or comment on the proposal, follow this link: https://github.com/ghc-proposals/ghc-proposals/pull/303 Thanks, Alexis

1 0

ANN: hledger 1.16
by Simon Michael 04 Dec '19

04 Dec '19

I'm pleased to announce hledger 1.16.1 ! hledger 1.16 was released on schedule on 2019-12-01, but only to hackage and github, since I was travelling and behind a rain-disrupted microwave link. Today brings the release notes & docs updates on hledger.org, and a 1.16.1 point release with some packaging updates. Thanks to release contributors Dmitry Astapov, Mykola Orliuk, Brian Wignall, Alejandro García Montoro, Timofey ZAKREVSKIY, Amitai Burstein, and Michael Kainer. hledger is a robust, cross-platform, multicurrency, plain text accounting tool, with command-line, terminal and web UIs. It is one of the leading implementations of plain text accounting, and is a modern and largely compatible reimplementation of Ledger. Use it for tracking money, time, stocks, cryptocurrencies or any other commodity, Learn more at http://hledger.org and http://plaintextaccounting.org . WHAT'S NEW: GHC 8.8 support, much more powerful CSV conversion rules, percentage balance reports, misc improvements. https://hledger.org/release-notes#hledger-1-16 . GETTING STARTED: Many install methods are described at http://hledger.org/download . Some of these might take a few days to become up to date; look for the green badges. You can build the latest by doing: stack update; stack install --resolver=lts hledger-lib-1.16.1 hledger-1.16.1 hledger-ui-1.16.1 hledger-web-1.16.1 --silent or: cabal v2-update; cabal v2-install hledger-1.16.1 hledger-web-1.16.1 hledger-ui-1.16.1 To start recording transactions: "hledger add". To list more commands: "hledger". See http://hledger.org for docs and support, or join #hledger on Freenode (http://irc.hledger.org) or join via Matrix (http://riot.hledger.org) New and old users, contributors, sponsors, and all feedback are most welcome! Best, -Simon

1 0

Open Position: Lecturer in Cybersecurity - University of Exeter
by Achim D. Brucker 03 Dec '19

03 Dec '19

Dear all, As part of the expansion of the Department of Computer Science [1] at the University of Exeter, we are recruiting for a Lecturer in Cybersecurity. The lecturer will be part of the newly formed Security and Trust of Advanced Systems Group [2]. This is a *unique* opportunity to join a new group and to influence its future research and teaching. We are looking for a candidate with an outstanding research record in any area of cybersecurity such as (but not limited to): language-based security, access control, usable security, software security, formal methods for security, security analytics, security protocols, human aspects of security, security economics, security by design, applied cryptography, security testing. We are particularly keen on research areas that either extend the current strength in software security and formal methods in security or that complement these existing focus area. Please apply by 12th of December 2019! See the full announcement and application details at https://jobs.exeter.ac.uk/hrpr_webrecruitment/wrd/run/ETREC107GF.open?VACAN… Feel free to contact me for informal inquires about the post. Best, Achim [1] https://www.exeter.ac.uk/computer-science/ [2] https://emps.exeter.ac.uk/computer-science/research/cyber-security/ -- Prof. Achim Brucker | Chair in Cybersecurity & Head of Group | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

ANN: reflex-libtelnet-0.1.0.0
by Jack Kelly 03 Dec '19

03 Dec '19

I have just pushed an initial release of reflex-libtelnet[1] to Hackage. reflex-libtelnet wraps libtelnet[2] in a Reflex interface, so that you can describe data flows through a telnet state tracker using Reflex Events. Even if you're not using Telnet in 2019, you might find it interesting as a study in binding Reflex to a callback-oriented library. A telnet echo server is provided as an example[3]. Bug reports[4] and questions/patches[5] are welcome on Sourcehut. Best, -- Jack [1]: https://hackage.haskell.org/package/reflex-libtelnet-0.1.0.0 [2]: https://hackage.haskell.org/package/libtelnet [3]: https://git.sr.ht/~jack/reflex-libtelnet/tree/master/reflex-libtelnet-examp… [4]: https://todo.sr.ht/~jack/reflex-libtelnet [5]: https://lists.sr.ht/~jack/reflex-libtelnet-discuss

1 0

Re: [Haskell-cafe] Is UndecidableInstances unavoidable in heterogenous Show derivation?
by Anthony Clayden 01 Dec '19

01 Dec '19

> ... was mildly surprised by the need for -XUndecidableInstances > when deriving the 'Show' instance for the heterogenous N-ary product 'NP': Hi Viktor, yes 'Undecidable' sounds scary, but it isn't. There's been much debate: should we find a less scary name? Presumably your program compiles and runs OK with that switched on(?) Providing your program compiles, it is type-safe. The risk with -XUndecidableInstances is that you might throw the compiler into a loop, in which case you'll get a stack depth check, with an unhelpful error message. See the Users Guide on UndecidableInstances, also this is a faq on StackOverflow. > deriving instance All (Compose Show f) xs => Show (NP f xs) Yes the constraint on that instance violates the Paterson Conditions (see Users Guide), the constraint is no smaller than the instance head. The P Conditions aim to make each step of instance resolution smaller, by strictly decreasing "constructors and variables (taken together ...". But that constraint has a count of 4, same as the head. > I guess I should also ask whether there's a way to define something equivalent > to 'Compose' without 'UndecidableSuperClasses', and perhaps the two are not unrelated. Not exactly related, but again superclass instance resolution wants to make the problem smaller at each step. The definition for class Compose has a constraint no smaller than the class head (3 variables). > [ Perhaps I should be more blasé about enabling these extensions, but I prefer > to leave sanity checks enabled when possible. ] Yes that's a sensible policy. The trouble with -XUndecidableInstances is that it's a module-wide setting, so lifts the check for all instances of all classes. There are/were several proposals to make this a per-instance or per-class pragma. But they got no support in the proposals process. AntC

2 1

Is UndecidableInstances unavoidable in heterogenous Show derivation?
by Viktor Dukhovni 01 Dec '19

01 Dec '19

I was reading: Summer School on Generic and Effectful Programming Applying Type-Level and Generic Programming in Haskell Andres Löh, Well-Typed LLP https://www.cs.ox.ac.uk/projects/utgp/school/andres.pdf and trying out the various code fragments, and was mildly surprised by the need for -XUndecidableInstances when deriving the 'Show' instance for the heterogenous N-ary product 'NP': deriving instance All (Compose Show f) xs => Show (NP f xs) Without "UndecidableInstances" I get: • Variable ‘k’ occurs more often in the constraint ‘All (Compose Show f) xs’ than in the instance head ‘Show (NP f xs)’ (Use UndecidableInstances to permit this) • In the stand-alone deriving instance for ‘All (Compose Show f) xs => Show (NP f xs)’ This is not related to automatic deriving, as a hand-crafted instance triggers the same error: instance All (Compose Show f) xs => Show (NP f xs) where show Nil = "Nil" show (x :* xs) = show x ++ " :* " ++ show xs Is there some other way of putting together the building blocks that avoids the need for 'UndecidableInstances', or is that somehow intrinsic to the type of NP construction? I guess I should also ask whether there's a way to define something equivalent to 'Compose' without 'UndecidableSuperClasses', and perhaps the two are not unrelated. [ Perhaps I should be more blasé about enabling these extensions, but I prefer to leave sanity checks enabled when possible. ] -- Viktor. {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE UndecidableSuperClasses #-} import GHC.Exts (Constraint) -- | Map a constraint over a list of types. type family All (c :: k -> Constraint) (xs :: [k]) :: Constraint where All _ '[] = () All c (x ': xs) = (c x, All c xs) -- | With @g@ a type constructor and @f@ a constraint, define @Compose f g@ as -- a contraint on @x@ to mean that @g x@ satisfies @f@. -- -- Requires: -- -- 'ConstraintKinds' -- 'FlexibleInstances' -- 'MultiParamTypeClasses' -- 'TypeOperators' -- 'UndecidableSuperClasses' -- class (f (g x)) => (Compose f g) x instance (f (g x)) => (Compose f g) x -- | Type-level 'const'. newtype K a b = K { unK :: a } deriving instance Show a => Show (K a b) -- | N-ary product over an index list of types @xs@ via an interpretation -- function @f@, constructed as a list of elements @f x@. -- data NP (f :: k -> *) (xs :: [k]) where Nil :: NP f '[] (:*) :: f x -> NP f xs -> NP f (x ': xs) infixr 5 :* -- | If we can 'show' each @f x@, then we can 'show' @NP f xs@. -- -- Requires: 'UndecidableInstances' -- deriving instance All (Compose Show f) xs => Show (NP f xs)

1 0

ANN brittany-0.12.0.0
by Evan Borden 28 Nov '19

28 Nov '19

Hello, I am happy to announce the release of brittany version 0.12.0.0. This version includes a number of fantastic improvements from many excellent contributors. Additionally brittany will soon be added back to stackage. In the meantime it can be built with the stack.yaml in its source or with cabal v2-build. https://hackage.haskell.org/package/brittany-0.12.0.0 Contributors ============ * Benjamin Kovach @5outh * Doug Beardsley @mightybyte * Evan Borden @eborden * Lennart Spitzner @lspitzner * Matt Noonan @moatt-noonan * Phil Hazelden @ChickenProp * Rupert Horlick @ruhatch * Sergey Vinokurov @sergv New Collaborators ================= You may be wondering why I am sending this message instead of Lennart. Taylor Fausak and I are taking on some of the maintenance for brittany. We will hopefully lift some of the burden from Lennart so he can remain the guiding light and driving force behind the project. Changes ========== This release includes many bug fixes, additional support for a number of syntactic constructs and a few layouting modifications. For full details check the change log on github: https://github.com/lspitzner/brittany/blob/master/ChangeLog.md Again thank you to brittany's fantastic contributors for helping making this release happen. -- Evan

2 1

[Announcement] Copilot 3.1, hard realtime C generator and runtime verification framework
by Ivan Perez 28 Nov '19

28 Nov '19

Dear all, We are very pleased to announce the release of Copilot 3.1, a stream-based DSL for writing and monitoring embedded C programs, with an emphasis on correctness and hard realtime requirements. Copilot is typically used as a high-level runtime verification framework, and supports temporal logic (LTL, PTLTL and MTL), clocks and voting algorithms. Among others, Copilot has been used at the Safety Critical Avionics Systems Branch of NASA Langley Research Center for monitoring test flights of drones. This new release contains a number of bug fixes and simplifications: * The installation instructions have been updated to work with new versions of cabal and GHC. * Random stream generators were not being used and have been removed. * External functions are no longer supported by the language (to prevent side-effects in streams). * Minor bug related to labels, nested locals, and pretty printing Copilot core, have been fixed. * Code internals have been simplified for a more future proof codebase. Copilot 3.1 is available on hackage [1]. For more information, including documentation, examples and links to the source code, please visit the webpage [2]. Current emphasis is on providing better documentation, facilitating the use with other systems, and generally improving the codebase. Users are encouraged to participate by opening issues and asking questions via our github repo [3]. Kind regards, The Copilot developers: - Frank Dedden (maintainer) - Alwyn Goodloe (maintainer) - Ivan Perez (maintainer) [1] http://hackage.haskell.org/package/copilot [2] https://copilot-language.github.io [3] https://github.com/Copilot-Language/copilot

1 0