September 2018 - Haskell-Cafe

CoqPL 2019: Call for Presentations
by Robbert Krebbers 17 Sep '18

17 Sep '18

=================================================================== CoqPL 2019 5th International Workshop on Coq for Programming Languages -- January 19, 2019, co-located with POPL Cascais/Lisbon, Portugal CALL FOR PRESENTATIONS https://popl19.sigplan.org/track/CoqPL-2019 =================================================================== Workshop Overview ----------------- The series of CoqPL workshops provide an opportunity for programming languages researchers to meet and interact with one another and members from the core Coq development team. At the meeting, we will discuss upcoming new features, see talks and demonstrations of exciting current projects, solicit feedback for potential future changes, and generally work to strengthen the vibrant community around our favorite proof assistant. Topics in scope include: - General purpose libraries and tactic language extensions - Domain-specific libraries for programming language formalization and verification - IDEs, profilers, tracers, debuggers, and testing tools - Reports on ongoing proof efforts conducted via (or in the context of) the Coq proof assistant - Experience reports from Coq usage in educational or industrial contexts Workshop Format --------------- The workshop format will be driven by you, members of the community. We will solicit abstracts for talks and proposals for demonstrations and flesh out format details based on responses. We expect the final program to include experiment reports, panel discussions, and invited talks (details TBA). Talks will be selected according to relevance to the workshop, based on the submission of an extended abstract. To foster open discussion of cutting edge research which can later be published in full conference proceedings, we will not publish papers from the workshop. However, presentations will be recorded and the videos made publicly available. Submission details ------------------ Submission page: https://coqpl19.hotcrp.com/ Submission: Monday, October 15, 2018. Notification: Thursday, November 8, 2018. Workshop: Saturday, January 19, 2019 (tentative, date to be confirmed soon). Submissions for talks and demonstrations should be described in an extended abstract, between 1 and 2 pages in length (excluding the bibliography). We suggest formatting the text using the two-column ACM SIGPLAN latex style (9pt font). Templates are available from the ACM SIGPLAN page: http://www.sigplan.org/Resources/Author. Program Committee ----------------- Chairs: - Robbert Krebbers Delft University of Technology, the Netherlands - Ilya Sergey University College London, UK Program Committee: - Olivier Danvy Yale-NUS College, Singapore - Ronghui Gu Columbia University, USA - William Mansky Princeton University, USA - Talia Ringer University of Washington, USA - Gordon Stewart Ohio University, USA - Enrico Tassi Inria, France - Anton Trunov IMDEA Software Institute, Spain - Edwin Westbrook Galois, Inc., USA - Steve Zdancewic University of Pennsylvania, USA

1 0

Parsing LocalTime from Unix seconds
by Marc Busqué 14 Sep '18

14 Sep '18

In GHCi ``` :m +Data.Time parseTimeM True defaultTimeLocale "%s" "1535684406" :: Maybe UTCTime -- => Just 2018-08-31 03:00:06 UTC parseTimeM True defaultTimeLocale "%s" "1535684406" :: Maybe LocalTime -- => Just 1970-01-01 00:00:00 ``` Why? ¯\(°_o)/¯ Marc Busqué http://waiting-for-dev.github.io/about/

2 2

Request for example of putting LaTeX in Haskell code comments for Haddock processing.
by David Banas 13 Sep '18

13 Sep '18

Hi all, Can anyone provide a know working example (GHC 8.4.3) of embedding LaTeX in Haskell source code comments intended for Haddock processing? Both in-line and block, if you’ve got them, would be great. Thanks! -db

5 5

Re: [Haskell-cafe] ANN: leancheck-v0.7.4 with providers for Tasty, Hspec and test-framework
by waldmann 12 Sep '18

12 Sep '18

Hi. I do prefer the enumerative approach for test case generation over the randomized one (quickcheck) because I have use cases (testing student code) where I want to avoid IO, and I just want a pure list of (small) counterexamples. Among the enumerative testing libraries, the "competition" is between leancheck and smallcheck. For, me the important differences are Enumeration of algebraic data types (ADTs), via built-in serial combinators, e.g., cons0 Leaf \/ cons2 Branch * leancheck enumerate by size (number of nodes in tree) * smallcheck enumerates by depth (longest path in tree) I (much!) prefer "by size" because this delays combinatorial explosion somewhat. Automated Listable/Serial instances for ADTs * leancheck uses template-haskell * smallcheck uses DeriveGeneric Here I would actually prefer DeriveGeneric. But this certainly could be added to leancheck? Oh, and leancheck does not use fancy typeclassery (smallcheck needs Multiparamtypeclasses and Monads just to declare a Serial instance) and it is also easier to get at the list of counterexamples. - J.W.

2 1

Is it possible to change the environment (reader) in applicative style?
by Olaf Klinke 12 Sep '18

12 Sep '18

Neither >>= nor 'return' nor 'join' for the reader monad change the environment, hence the name "reader". Thus I'd chime in and claim it is not possible using the Applicative or Monad combinators alone. After all, the reader monad is ignorant of what type it is reading. In other words, if the type class combinators alone could do this, then you'd have a function that worked for _every_ type Env. But updating a list of (variable,value) pairs is a rather specific task. Fixing the syntax for this post: type Reader a = Env -> a Since your 'let' function modifies the environment, it yields a function of type Env -> Env = Reader Env Say that your 'let' has the type let :: Def -> Reader Env for a suitable type Def, e.g. Def = (String,Int). Suppose you have implemented 'let'. We know the Applicative and Monad type class functions won't help here. But observe that (.) can be specialized to (.) :: Reader a -> Reader Env -> Reader a whence you can write eval term . let newBinding where term :: Term eval :: Term -> Reader Int let :: Def -> Reader Env newBinding :: Def Cheers, Olaf

1 0

Is it possible to change the environment (reader) in applicative style?
by Rodrigo Stevaux 12 Sep '18

12 Sep '18

It is easy to read an environment in applicative style, ie: type Env = [(String, Int)] data Term = Add Term Term | Number Int | Var String deriving Show eval :: Term -> Env -> Int eval (Add a b) = (+) <$> eval a <*> eval b eval (Var name) = fetch name eval (Number i) = pure i fetch :: String -> Env -> Int fetch name = fromJust . lookup name But can the eval function change the Env being passed, as to implement a "let" operation, without using monads? I tried I lot but ultimately I resorted to (>>=) in the function monad: bind f k = \r -> k (f r) r I do not think so, because in applicative style each operand can have an effect (reading the environment) but can not affect other operands (including the next ones), i.e., there is no notion of sequencing in applicatives Is this reasoning right?

4 4

Adding a custom lib to stack project
by Yotam Ohad 11 Sep '18

11 Sep '18

Hi, I made a lib from a cpp project with one function: BOOL Foo(LPCSTR bar) In the stack project I added the .lib file's folder to the extra-lib-dirs/extra-include-dirs and then, in main: {-# LANGUAGE ForeignFunctionInterface #-} module Main where import System.Win32.Types import Foreign.C.String main :: IO () main = do withCString "bar" c_Foo putStrLn "success" foreign import ccall "bindings.lib Foo" c_Foo :: LPCSTR -> IO BOOL When building I get the following error Building all executables for `tape' once. After a successful build of all of them, only specified executables will be rebuilt. tape-0.1.0.0: build (lib + exe) Preprocessing library for tape-0.1.0.0.. Building library for tape-0.1.0.0.. ignoring (possibly broken) abi-depends field for packages Preprocessing executable 'tape-exe' for tape-0.1.0.0.. Building executable 'tape-exe' for tape-0.1.0.0.. Linking .stack-work\dist\7d103d30\build\tape-exe\tape-exe.exe ... .stack-work\dist\7d103d30\build\tape-exe\tape-exe-tmp\Main.o:fake:(.text+0x102): undefined reference to `CreateDebuggedProcess' collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) -- While building custom Setup.hs for package tape-0.1.0.0 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.2.0.1_ghc-8.4.3.exe --builddir=.stack-work\dist\7d103d30 build lib:tape exe:tape-exe --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure What am I doing wrong? Yotam

3 5

Call for Papers: Postproceedings for ThEdu'18 by EPTCS
by Achim D. Brucker 11 Sep '18

11 Sep '18

(Apologies for duplicates) Open Call for Papers ************************************************************************** Postproceedings for ThEdu'18 by EPTCS Theorem proving components for Educational software http://www.uc.pt/en/congressos/thedu/thedu18 ************************************************************************** Workshop ThEdu at FLoC Federated Logic Conference 2018 http://www.floc2018.org/ ************************************************************************** THedu'18 Postproceedings: ThEdu's programme comprised seven contributions, presented also in the webpages. Now postproceedings are planned to collect the contributions upgraded to full papers. The contributions' topics are diverse according to ThEdu's scope, and this is a call open for everyone, also those who did not participate in the workshop. All papers will undergo review according to EPTCS standards. THedu'18 Scope: Computer Theorem Proving is becoming a paradigm as well as a technological base for a new generation of educational software in science, technology, engineering and mathematics. The workshop brings together experts in automated deduction with experts in education in order to further clarify the shape of the new software generation and to discuss existing systems. Topics of interest include: * methods of automated deduction applied to checking students' input; * methods of automated deduction applied to prove post-conditions for particular problem solutions; * combinations of deduction and computation enabling systems to propose next steps; * automated provers specific for dynamic geometry systems; * proof and proving in mathematics education. Important Dates * 2nd call for papers: 10 Sep 2018 * Submission (full papers): 18 Nov 2018 * Notification of acceptance: 17 Dec 2018 * Revised papers due: 21 Jan 2019 Submission We welcome submission of papers presenting original unpublished work which is not been submitted for publication elsewhere. The authors should comply with the "instructions for authors", LaTeX style files and accept the "Non-exclusive license to distribute" of EPTCS: Instructions for authors (http://info.eptcs.org/) LaTeX style file and formatting instructions (http://style.eptcs.org/) Copyright (http://copyright.eptcs.org/) Papers should be submitted via easychair, https://easychair.org/conferences/?conf=thedu18. In case the contributions finally do not reach the standards of EPTCS in number, there will be an alternative to publish as a techreport at CISUC https://www.cisuc.uc.pt/publications. Program Committee Francisco Botana, University of Vigo at Pontevedra, Spain Roman Hašek, University of South Bohemia, Czech Republic Filip Maric, University of Belgrade, Serbia Walther Neuper, Graz University of Technology, Austria (co-chair) Pavel Pech, University of South Bohemia, Czech Republic Pedro Quaresma, University of Coimbra, Portugal (co-chair) Vanda Santos, CISUC, Portugal Wolfgang Schreiner, Johannes Kepler University, Austria -- Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

modules as implicit data structures
by Petr Pudlák 11 Sep '18

11 Sep '18

Hi Cafe, Let's say we have a module like module Foo where foo, bar :: String -> Something ... and use it elsewhere as import qualified Foo as F ... F.foo ... This is almost just if we had a data type defined as data FooModule = FooModule { foo :: String -> Something, bar :: String -> Something } together with a singleton `f : :FooModule` and referenced it as f.foo, f.bar etc. Has some language explored this idea of making modules explicit as language-level objects? It seems that there could be some interesting possibilities, such as: - Abstract modules (just a definition of the data type). Then - Being able to replace a module with a different one (like a fake one for testing). - Polymorphic modules that could be instantiated for specific types. Thanks, Petr

5 5

Difference between `type` and `newtype` in type checking
by Rodrigo Stevaux 10 Sep '18

10 Sep '18

Hi, I was studying this post ( http://www.haskellforall.com/2012/12/the-continuation-monad.html) on CPS and I tried the following code: module Main where newtype Cont r a = Cont { runCont :: (a -> r) -> r } onInput :: Cont (IO ()) String onInput f = do s <- getLine f s onInput f main :: IO () main = onInput print I fails to compile: "Couldn't match expected type ‘Cont (IO ()) String’ with actual type ‘(String -> IO a0) -> IO b0’ • The equation(s) for ‘onInput’ have one argument, but its type ‘Cont (IO ()) String’ has none" But I thought Cont a b would be expanded to (b -> a) -> a so that Cont (IO ()) String became (String -> IO ()) -> IO (), and if I give that type using `type` instead of `newtype`, it does type-check: type Cont r a = (a -> r) -> r What am I missing here about Haskell? thanks folks!

2 1