- Haskell-Cafe - Haskell.org

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 11 Sep '18

11 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

ANN: proto-lens-0.4.0.0
by Judah Jacobson 10 Sep '18

10 Sep '18

I'm pleased to announce the release of proto-lens-0.4.0.0. The library provides an API for protocol buffers, a language-independent binary file format. Cabal and Stack projects can use proto-lens to automatically generate Haskell source bindings from the original protocol buffer specifications. Some significant changes in this new release include: - Simplifying the overloaded lens instances to improve readability and type error messages (along with the associated release of lens-labels-0.3.0.0) - Switching to a custom class for default messages - Hiding the internals of generated message types - Making the Show instances more readable and concise - Splitting the Cabal support into finer-grained packages, for better integration with Nix and Bazel For general library documentation and tutorials: https://google.github.io/proto-lens/ For assistance in migrating from earlier versions: https://github.com/google/proto-lens/wiki/Migration-Guide For detailed changelogs: https://hackage.haskell.org/package/proto-lens/changelog https://hackage.haskell.org/package/proto-lens-protoc/changelog Best, -Judah

1 0

Mathematics of Program Construction (MPC), Portugal, 2019
by Graham Hutton 10 Sep '18

10 Sep '18

Dear all, The next Mathematics of Program Construction (MPC) conference will be held in the historic city of Porto, Portugal in October 2019, co-located with the Symposium on Formal Methods (FM). Please share, and submit your best papers! Best wishes, Graham Hutton Program Chair, MPC 2019 ====================================================================== 13th International Conference on Mathematics of Program Construction 7-9 October 2019, Porto, Portugal Co-located with Formal Methods 2019 https://tinyurl.com/MPC-Porto ====================================================================== BACKGROUND: The International Conference on Mathematics of Program Construction (MPC) aims to promote the development of mathematical principles and techniques that are demonstrably practical and effective in the process of constructing computer programs. MPC 2019 will be held in Porto, Portugal from 7-9 October 2019, and is co-located with the International Symposium on Formal Methods, FM 2019. Previous conferences were held in Königswinter, Germany (2015); Madrid, Spain (2012); Québec City, Canada (2010); Marseille, France (2008); Kuressaare, Estonia (2006); Stirling, UK (2004); Dagstuhl, Germany (2002); Ponte de Lima, Portugal (2000); Marstrand, Sweden (1998); Kloster Irsee, Germany (1995); Oxford, UK (1992); Twente, The Netherlands (1989). SCOPE: MPC seeks original papers on mathematical methods and tools put to use in program construction. Topics of interest range from algorithmics to support for program construction in programming languages and systems. Typical areas include type systems, program analysis and transformation, programming language semantics, security, and program logics. The notion of a 'program' is interpreted broadly, ranging from algorithms to hardware. Theoretical contributions are welcome, provided that their relevance to program construction is clear. Reports on applications are welcome, provided that their mathematical basis is evident. We also encourage the submission of 'programming pearls' that present elegant and instructive examples of the mathematics of program construction. IMPORTANT DATES: Abstract submission 26th April 2019 Paper submission 3rd May 2019 Author notification 14th June 2019 Camera ready copy 12th July 2019 Conference 7-9 October 2019 SUBMISSION: Submission is in two stages. Abstracts (plain text, maximum 250 words) must be submitted by 26th April 2019. Full papers (pdf, formatted using the llncs.sty style file for LaTex) must be submitted by 3rd May 2019. There is no prescribed page limit, but authors should strive for brevity. Both abstracts and papers will be submitted using EasyChair. Papers must present previously unpublished work, and not be submitted concurrently to any other publication venue. Submissions will be evaluated by the program committee 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. Accepted papers must be presented in person at the conference by one of the authors. The proceedings of MPC 2019 will be published in the Lecture Notes in Computer Science (LNCS) series, as with all previous instances of the conference. Authors of accepted papers will be expected to transfer copyright to Springer for this purpose. After the conference, authors of the best papers from MPC 2019 and MPC 2015 will be invited to submit revised versions to a special issue of Science of Computer Programming (SCP). For any queries about submission please contact the program chair, Graham Hutton <graham.hutton(a)nottingham.ac.uk>. PROGRAM COMMITTEE: Patrick Bahr IT University of Copenhagen, Denmark Richard Bird University of Oxford, UK Corina Cîrstea University of Southampton, UK Brijesh Dongol University of Surrey, UK João F. Ferreira University of Lisbon, Portugal Jennifer Hackett University of Nottingham, UK William Harrison University of Missouri, USA Ralf Hinze University of Kaiserslautern, Germany Zhenjiang Hu National Institute of Informatics, Japan Graham Hutton (chair) University of Nottingham, UK Cezar Ionescu University of Oxford, UK Mauro Jaskelioff National University of Rosario, Argentina Ranjit Jhala University of California, San Diego, USA Ekaterina Komendantskaya Heriot-Watt University, UK Bernhard Möller University of Augsburg, Germany Shin-Cheng Mu Academia Sinica, Taiwan Mary Sheeran Chalmers University of Technology, Sweden Alexandra Silva University College London, UK Georg Struth University of Sheffield, UK VENUE: The conference will be held at the Alfândega Porto Congress Centre, a 150 year old former custom's house located in the historic centre of Porto on the bank of the river Douro. The venue was renovated by a Pritzer prize winning architect and has received many awards. LOCAL ORGANISERS José Nuno Oliveira University of Minho, Portugal For any queries about local issues please contact the local organiser, José Nuno Oliveira <jno(a)di.uminho.pt>. ====================================================================== 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] ANN: leancheck-v0.7.2, enumerative QuickCheck-like testing
by Rodrigo Stevaux 09 Sep '18

09 Sep '18

Hi, nice to see a fellow Brazilian. How does your work differ from QuickCheck?

2 1