- Haskell-Cafe - Haskell.org

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 02 Dec '19

02 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 30 Nov '19

30 Nov '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 27 Nov '19

27 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

A Specification for GADTs in Haskell?
by Xuanrui Qi 26 Nov '19

26 Nov '19

Hello all, I recently came a cross a comment by Richard Eisenberg that there's actually no specification for GADTs and creating one would be a major research project (in a GHC proposal somewhere, I recall, but I don't remember exactly where). I was wondering what exactly does Richard's comment mean. What constitutes a specification for GADTs in Haskell? I suppose typing rules and semantics are necessary; what are the major roadblocks hindering the creation of a formal specification for GADTs in Haskell? Thanks! Xuanrui -- Xuanrui Qi Graduate School of Mathematics, Nagoya University https://www.xuanruiqi.com

4 3

[TFP'20] draft paper deadline open (January 10 2020) Trends in Functional Programming 2020, 13-14 February, Krakow, Poland
by Peter Achten 26 Nov '19

26 Nov '19

------------------------------------------------------------------------- Third call for papers 21st Symposium on Trends in Functional Programming tfp2020.org ------------------------------------------------------------------------- Did you miss the deadline to submit a paper to Trends in Functional Programming http://cse.chalmers.se/~rjmh/tfp/? No worries -- it's not too late! Submission is open until January 10th 2020, for a presentation slot at the event and post-symposium reviewing. The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions. * TFP is moving to new winter dates, to provide an FP forum in between the annual ICFP events. * TFP offers a supportive reviewing process designed to help less experienced authors succeed, with two rounds of review, both before and after the symposium itself. Authors have an opportunity to address reviewers' concerns before final decisions on publication in the proceedings. * TFP offers two "best paper" awards, the John McCarthy award for best paper, and the David Turner award for best student paper. * This year we are particularly excited to co-locate with Lambda Days in beautiful Krakow. Lambda Days is a vibrant developer conference with hundreds of attendees and a lively programme of talks on functional programming in practice. TFP will be held in the same venue, and participants will be able to session-hop between the two events. Important Dates --------------- Submission deadline for pre-symposium review: 15th November, 2019 -- passed -- Submission deadline for draft papers: 10th January, 2020 Symposium dates: 13-14th February, 2020 Visit tfp2020.org for more information.

1 0

Munich Haskell Meeting, 2019-11-27 @ 19:30
by Leah Neukirchen 25 Nov '19

25 Nov '19

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, November 27 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-2019/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Planet Haskell
by Joachim Breitner 22 Nov '19

22 Nov '19

Hi, I am reading planet haskell through a feed reader that pulls https://planet.haskell.org/atom.xml and I get new posts. But it seems that that https://planet.haskell.org/ is stuck in January 2019. Or, upon closer inspection, new posts _are_ on planet.haskell.org, but they are not on top. I guess in the times of reddit and slack, few people are following the planet, but maybe still some people do? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 2