- Haskell-Cafe - Haskell.org

Escape Time Library or Free Software Program?
by Christopher Howard 30 Oct '16

30 Oct '16

Hi list. Is there a library that separates out escape time image generation, so that you could plug in whatever formula you wanted for Xnew and Ynew? (Instead of just a few predefined complex number formulas like julia?) I've come across a ton of libraries and programs that generate mandelbrots, but I wanted to try autogenerating images based on random polynomials, like Pickover describes in one of his papers. But I know escape time image generation must be far too well developed by now to be building this from scratch. -- https://qlfiles.net My PGP public key ID is 0x340EA95A (pgp.mit.edu)

1 0

Why doesn't GHC derive these types
by Clinton Mead 29 Oct '16

29 Oct '16

Consider the following program: {-# LANGUAGE TypeFamilyDependencies #-} data D x type family F t = s | s -> t type instance F (D t) = D (F t) f :: F s -> () f _ = () g :: D (F t) -> () g x = f x main = return () The problem seems to be the call from "g" to "f". We're calling "f" with an argument of type "D (F t)". "f" then has to determine what "s" is in it's signature. We know: 1. "F s ~ D (F t)" (from function call) 2. "D (F t) ~ F (D t)" (from the right hand side of the injective type definition) Therefore we should be able to derive: 3. "F s ~ F (D t)" (type equality is transitive) 4. "s ~ D t" (as F is injective) I suspect the part we're missing in GHC is step 4. I recall reading this somewhere but I can't find where now. However, the paper about injective types says that this style of inference, namely "F a ~ F b => a ~ b" should occur. I quote ( https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/injecti… section 5.1 p125): So, faced with the constraint F α ∼ F β, the inference engine does not in > general unify α := β; so the constraint F α ∼ F β is not solved, and hence > f (g 3) will be rejected. But if we knew that F was injective, we can unify > α := β without guessing. > Improvement (a term due to Mark Jones (Jones 1995, 2000)) is a process > that adds extra "derived" equality constraints that may make some extra > unifications apparent, thus allowing inference to proceed further without > having to make guesses. In the case of an injective F, improvement adds α ∼ > β, which the constraint solver can solve by unification. In general, > improvement of wanted constraint is extremely simple: > Definition 11 (Wanted improvement). Given the wanted constraint F σ ∼ F τ > , add the derived wanted constraint σn ∼ τn for each n-injective argument > of F. > Why is this OK? Because if it is possible to prove the original constraint > F σ ∼ F τ , then (by Definition 1) we will also have a proof of σn ∼ τn. So > adding σn ∼ τn as a new wanted constraint does not constrain the solution > space. Why is it beneficial? Because, as we have seen, it may expose > additional guess-free unification opportunities that that solver can > exploit. Am I correct in my assessment of what is happening here with GHC? Is there anyway to get it to compile this program, perhaps with an extension?

2 3

What instances can be derived by GHC ?
by Jacques Carette 29 Oct '16

29 Oct '16

I am trying to find a list of classes which can be derived 'out of the box' with GHC 8.0, i.e. without installing extra packages like derive [1]. There is quite a lot of information on how 'deriving' (inline and standalone) works [2] on the GHC wiki, but sadly no list. Yes, it does say that any class could be made derivable, but that's not useful, as it doesn't which ones have been. The page describing DerivingStrategies does have a list of 'stock classes' - is this indeed the full list? From the 8.0.1 documentation on Deriving [4], one can extract a list too. For reference, as far as I can tell, the answer to my question *appears to be* (using extensions as necessary): - Bounded, Enum, Eq, Ix, Ord, Read, Show, Functor, Foldable, Traversable, Generic, Generic1, Data, Lift. I do understand that GeneralizedNewtypeDeriving muddies the water. Let's ignore 'newtype' for this purpose, and only concentrate on 'data'. If my guess is correct, would it make sense to put this information somewhere easy to find, instead of having be buried, so that it needs to be 'dug out' ? Jacques [1] http://hackage.haskell.org/package/derive [2] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving [3] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies [4] http://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts.…

2 1

Haddock, wrapping contexts?
by Tom Ellis 28 Oct '16

28 Oct '16

Some of my type signatures have long contexts and Haddock doesn't wrap them, pushing the more interesting information off the right hand side, e.g.: https://hackage.haskell.org/package/opaleye-0.5.1.1/docs/Opaleye-Join.html Is there any way I can convince Haddock to wrap these contexts? Ideally I want to see something like leftJoin :: (Default Unpackspec columnsA columnsA, Default Unpackspec columnsB columnsB, Default NullMaker columnsB nullableColumnsB) => Query columnsA -> Query columnsB -> ((columnsA, columnsB) -> Column PGBool) -> Query (columnsA, nullableColumnsB) Thanks, Tom

4 7

get Chalmers' Haskell Interpreter and Compiler source code
by Csaba Hruska 28 Oct '16

28 Oct '16

Hi, I was curious and wanted to check the HBC source code but I only found a broken link (https://www.haskell.org/hbc/hbc-2004-06-29.src.tar.gz) on Haskell Wiki <https://wiki.haskell.org/Implementations#HBI_and_HBC.2C_Chalmers.27_Haskell…> . Is it possible to fix the link? Or if somebody has the source code can you please share it? Thanks, Csaba

1 2

CoALP-Ty'16: Call for Participation
by František Farka 27 Oct '16

27 Oct '16

Call for Participation Workshop on Coalgebra, Horn Clause Logic Programming and Types 28-29 November 2016, Edinburgh, UK https://ff32.host.cs.st-andrews.ac.uk/coalpty16/ Abstract submission: 15 October, 2016 Registration deadline: 5 November, 2016 ==================================================== Objectives and scope ------------------- The workshop marks the end of the EPSRC Grant Coalgebraic Logic Programming for Type Inference, by K. Komendantskaya and J. Power and will consist of two parts: Part 1 - Semantics: Lawvere theories and Coalgebra in Logic and Functional Programming Part 2 - Programming languages: Horn Clause Logic for Type Inference in Functional Languages and Beyond We invite all colleagues working in related areas to present and share their results. We envisage a friendly meeting with many stimulating discussions, and therefore welcome presentations of already published research as well as novel results. Authors of original contributions will be invited to submit their papers to EPTCS post-proceedings. We especially encourage early career researchers to present and participate. Venue ----- The workshop will be held at the International Centre for Mathematical Sciences, in Edinburgh city centre, just 2 minutes walk from the Informatics Forum. Registration ------------ To register please fill in https://goo.gl/forms/KAm83p1bcNAxw0ss2 Although the registration is free it is compulsory. Please register by the 5th of November 2016. Programme --------- Monday 28 November 9:10 - 9:20 Registration 9:30 - 9:40 Welcome to CoALP-Ty'16 - Ekaterina Komendantskaya 9:40 - 11:10 Invited talk I - John Power: Logic Programming: Laxness and Saturation 11:10 - 11:30 Coffee break 11:30 - 12:00 Contributed talk - Henning Basold and Ekaterina Komendantskaya: Models of Inductive-Coinductive Logic Programs 12:00 - 13:00 Invited talk II - Steven Ramsay and Luke Ong: Refinement Types and Higher-Order Constrained Horn Clauses 13:00 - 14:00 Lunch 14:00 - 15:00 Invited talk III - Tarmo Uustalu: Comodels and Interaction 15:00 - 15:30 Coffee break 15:30 - 17:00 Contributed talks - František Farka: Proofs by Resolution and Existential Variables - Bashar Igried and Anton Setzer: Defining Trace Semantics for CSP-Agda - Clemens Kupke: Coalgebra and Ontological Rules 18:00 - 20:00 Workshop dinner - Lebanese restaurant Beirut, 24 Nicolson Square Tuesday 29 November 9:30 - 10:30 Invited talk IV - Claudio Russo: Classes for the Masses 10:30 - 11:00 Contributed talk - J. Garrett Morris: Semantical Analysis of Type Classes 11:00 - 11:30 Coffee break 11:30 - 12:30 Invited talk V - Davide Ancona: Abstract Compilation for Type Analysis of Object-Oriented Languages 12:30 - 13:30 Lunch 13:30 - 14:30 Invited talk VI - Ki Yung Ahn: Relational Specification of Type Systems Using Logic Programming 14:30 - 15:15 Discussion Panel - Horn Clause Logic: its Proof Theory, Type Theory and Category Theory — do we have the full picture yet? 15:15 - 15:45 Coffee break 15:45 - 16:45 Contributed talks - Martin Schmidt: Coalgebraic Logic Programming: Implementation and Optimization - Luca Franceschini, Davide Ancona and Ekaterina Komendantskaya: Structural Resolution for Abstract Compilation of Object-Oriented Languages Important dates --------------- Workshop registration: 5 November, 2016 Workshop: 28–29 November, 2016 Programme committee ------------------- Ki Yung Ahn, Nanyang Technological University, Singapore Davide Ancona, University of Genoa, Italy Filippo Bonchi, CNRS, ENS de Lyon, France Iavor Diatchki, Galois, Inc, USA Peng Fu, Heriot-Watt University, Edinburgh, UK Neil Ghani, University of Strathclyde, UK Patricia Johann, Appalachian State University, USA Ekaterina Komendantskaya, Heriot-Watt University, Edinburgh, UK Clemens Kupke, University of Strathclyde, UK J. Garrett Morris, University of Edinburgh, UK Fredrik Nordvall Forsberg, University of Strathclyde, UK John Power, University of Bath, UK Claudio Russo, Microsoft Research Cambridge, UK Martin Schmidt, DHBW Stuttgart and Osnabrück University , Germany Stephan Schulz, DHBW Stuttgart, Germany Aaron Stump, The University of Iowa, USA Niki Vazou, University of California, San Diego, USA Joe Wells, Heriot-Watt University, Edinburgh, UK Fabio Zanasi, Radboud University of Nijmegen, The Netherlands Workshop chairs -------- Ekaterina Komendantskaya, Heriot-Watt University, UK John Power, University of Bath, UK Publicity chair --------------- František Farka, University of Dundee, UK and University of St Andrews, UK -- František Farka

1 0

Fwd: How to best display type variables with the same name
by Christopher Done 27 Oct '16

27 Oct '16

Hi all, I posted the below to ghc-devs, but they suggested perhaps Haskell-Cafe might be interested in the problem. For convenience, here's the ghc-devs archive of that discussion: https://mail.haskell.org/pipermail/ghc-devs/2016-October/013085.html ---------- Forwarded message ---------- From: Christopher Done <chrisdone(a)gmail.com> Date: 19 October 2016 at 12:45 Subject: How to best display type variables with the same name To: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> We've encountered a problem in Intero which is that when inspecting types of expressions and patterns, sometimes it happens that the type, when pretty printing, yields variables of the same name but which have different provenance. Here's a summary of the issue: https://github.com/commercialhaskell/intero/issues/280#issuecomment-2547849… And a strawman proposal of how it could be solved: https://github.com/commercialhaskell/intero/issues/280#issuecomment-2547879… What do you think? Also, if I were to implement the strawman proposal, is it possible to recover from a `tyvar :: Type` its original quantification/its "forall"? I've had a look through the API briefly and it looks like a _maybe_. Ciao!

1 0

Proof of concept of explanations for instance resolution
by Michael Sloan 27 Oct '16

27 Oct '16

When typeclass machinery gets complicated, it can be hard to figure interpret the meaning behind GHC's messages. In particular "Could not deduce ..." messages often reference constraints that are deep in a tree of resolving typeclasses. I think it would be great if GHC provided additional information for this circumstance. In a way what we need is a "stack trace" of what GHC was thinking about when yielding these type errors. A couple years ago, I wrote an extremely hacky approach to yielding this information through TH. It is quite imperfect, and only works with GHC 7.8. I've realized that it's highly unlikely that this project will reach the level of polish for it to be very usable in practice: https://github.com/mgsloan/explain-instance However, rather than allow that work to be wasted, I'd like to bring people's attention to the problem in general, and how we might solve it in GHC. Along with providing more information in type errors, this could also look like having a ":explain" command in ghci. Lets take Text.Printf as an example. The expression (printf "%d %d" (1 :: Int) (2 :: A) :: String) has quite a bit of machinery behind it: printf :: (PrintfType r) => String -> r class PrintfType t instance (IsChar c) => PrintfType [c] instance (a ~ ()) => PrintfType (IO a) instance (PrintfArg a, PrintfType r) => PrintfType (a -> r) class PrintfArg a where instance PrintfArg Int where With explain-instance, all we have to do is create a module with the following in it: import ExplainInstance import Text.Printf $(explainInstance [t| PrintfType (Int -> Int -> String) |]) Then, upon running the generated main function, we get the following explanation: instance (PrintfArg a, PrintfType r) => PrintfType (a -> r) with a ~ Int r ~ (Int -> [Char]) instance PrintfArg Int instance (PrintfArg a, PrintfType r) => PrintfType (a -> r) with a ~ Int r ~ [Char] instance PrintfArg Int instance IsChar c => PrintfType ([c]) with c ~ Char instance IsChar Char This is the recursive tree of instance instantiation! It shows the instance head, the particular types that it has been instantiated at in a made up "with" clause. Most importantly, it shows how the instance's constraints are also satisfied, giving a tree for an explanation. The implementation of this is irrelevant, but for the curious: it involves recursively reifying all of the typeclasses, and then generating a whole new set of typeclasses. These modified versions have the same heads (renamed) as the original typeclasses, but just have one method, which yields a description of the the types it has been instantiated with, via Typeable. Well that's quite convenient! I think it can really aid in understanding typeclass machinery to be able to get this variety of trace through what GHC is thinking when satisfying a constraint. However, this is just half the problem - what about type errors? I played around with a solution to this via UndecidableInstances, where it would create a base-case instance that represents the error case. Lets say I wanted to use (printf :: String -> A -> Int -> Maybe String) where A is a type that is not an instance of PrintfArg. Another issue with this is that the result type (Maybe String) is not allowed by PrintfType. The output of $(explainInstanceError [t| PrintfType (A -> Int -> Maybe String) |]) is instance (PrintfArg a, PrintfType r) => PrintfType (a -> r) with a ~ A r ~ (Int -> Maybe [Char]) ERROR instance PrintfArg a with a ~ A instance (PrintfArg a, PrintfType r) => PrintfType (a -> r) with a ~ Int r ~ Maybe [Char] instance PrintfArg Int ERROR instance PrintfType t with t ~ Maybe [Char] This explains exactly where the problem is coming from in the typeclass machinery. If you're just looking at the type of printf, and see a `PrintfType` constraint, it can be a total mystery as to why GHC is complaining about some class we may or may not know about: No instance for (PrintfArg A) arising from a use of ‘printf’ Thanks for reading! I hope we can address this UI concern in the future. I hope I've contributed something by demonstrating the possibility! -Michael

2 1

Suggestion for error message improvement
by Zachary Kessin 26 Oct '16

26 Oct '16

When I compiled some code this morning I got an error that said that I should edit my cabal file, but I notice that one thing is missing, the path to the cabal file. Having that in the error message would make fixing it a bit easier and faster in that emacs could take me right to the correct cabal file and that I would know for sure which one it was using. I tried filing this as a bug on the stack github repo but they said it is a ghc issue. [1 of 1] Compiling Main ( tests/test.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/test/test-tmp/Main.o ) /home/zkessin/Documents/*****/tests/test.hs:17:1: error: Failed to load interface for ‘Control.Lens’ It is a member of the hidden package ‘lens-4.14’. Perhaps you need to add ‘lens’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for. Progress: 1/2 -- While building package ***********-0.1.0.0 using: /home/zkessin/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:********** test:test --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 -- Zach Kessin SquareTarget <http://squaretarget.rocks?utm_source=email-sig> Twitter: @zkessin <https://twitter.com/zkessin> Skype: zachkessin

2 1

[ANN] unicode-transforms-0.2.0 pure Haskell unicode normalization
by Harendra Kumar 25 Oct '16

25 Oct '16

Hi, I released unicode-transforms sometime back as bindings to a C library (utf8proc). Since then I have rewritten it completely in Haskell. Haskell data structures are automatically generated from unicode database, so it can be kept up-to-date with the standard unlike the C implementation which was stuck at unicode 5. The implementation comes with a test suite providing 100% code coverage. After a number of algorithmic and implementation efficiency optimizations, I was able to get several times better decompose performance compared to the C implementation. I have not yet got a chance to fully optimize the compose operations but they are still as fast as utf8proc. I would like to thank Antonio Nikishaev for the unicode character database parsing code which I borrowed from the prose library. https://github.com/harendra-kumar/unicode-transforms https://hackage.haskell.org/package/unicode-transforms -harendra

2 2