- Haskell-Cafe - Haskell.org

how to set extra-lib-dirs for a dependency in a stack project?
by Johannes Waldmann 30 Jan '22

30 Jan '22

Dear Cafe, is it possible to specify include-dirs and extra-lib-dirs for a dependency? I have * top-level project A, depends on: * project B, depends on: * C: external library (written in C) I am building A with stack. I don't want to put fixed locations (include/lib) for C in B.cabal, because it depends on the (top-level) build environment of A (e.g., my machine, or CI). Concrete example: C = kissat SAT solver, B = Haskell API for C. I know that, e.g., https://hackage.haskell.org/package/minisat works around this problem by vendoring (is this the word?) the solver's code (into B). I don't want this. With cabal.project, I could set options for (all?) dependencies? https://cabal.readthedocs.io/en/3.4/cabal-project.html#foreign-function-int… Would stack use this setting (will it read that file at all)? Will I have to copy all extra-deps source repo locations to cabal.project? - J.

2 3

Some Love for wxHaskell
by Tilmann 30 Jan '22

30 Jan '22

Hi cafe, I think wxHaskell needs some love :) Over the years I've written a small client for FICS (Free Internet Chess Server) and wxHaskell has served me really well. Also, wxWidgets seems solid and alive.. but today, wxHaskell is lagging behind updates and seems *sniff* dead. Is someone working on wxHaskell atm? I'd love to connect and help. If not, is there some interest to rejuvenate wxHaskell? Who is also depending on wxHaskell and wants to keep it going? Or, is it time to move on to gtk or reflex? Very much looking forward to your replies! Best, Tilmann

3 4

Coercing existential according to type-level Maybe (re-post from h-beginners)
by Dmitriy Matrosov 29 Jan '22

29 Jan '22

(as suggested, i'm re-asking here) Hi. I've tried to write a function to coerce existential value according to type stored in type-level 'Maybe' (i.e. 'Just or 'Nothing). > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE GADTs #-} > > import Data.Kind > import Data.Proxy > import Unsafe.Coerce > > class FromTypeMaybe k where > type ToType k > fromTypeMaybe :: (a -> ToType k) -> Proxy k -> a -> Maybe (ToType k) > > --instance forall (t :: Type). FromTypeMaybe ('Nothing :: Maybe t) where > instance forall (t :: Type). FromTypeMaybe ('Nothing @t) where > type ToType 'Nothing = t > fromTypeMaybe f _ x = Nothing > > instance forall (t :: Type). FromTypeMaybe ('Just t :: Maybe Type) where > type ToType ('Just t) = t > fromTypeMaybe f _ x = Just (f x) > > data Any where > Any :: a -> Any > > unAny :: Any -> t > unAny (Any x) = unsafeCoerce x This works as far as i can see *Main> fromTypeMaybe unAny (Proxy @('Just Int)) (Any 3) Just 3 *Main> fromTypeMaybe unAny (Proxy @'Nothing) undefined Nothing but i don't understand how 'Nothing instance works: type kind kind? vvv vvvvvv vvv instance forall (t :: Type). FromTypeMaybe ('Nothing :: Maybe t) where type ToType 'Nothing = t ^^^ type (in case alignment breaks: variable 't' in forall is type-variable with kind 'Type', but in "Maybe t" in instance head it's used as kind-variable. And then in associated type-family the same variable 't' is used as type-variable again). If i try to write "'Nothing"'s kind as 'Maybe Type' (in the same manner as 'Just has) instance forall (t :: Type). FromTypeMaybe ('Nothing :: Maybe Type) where i get an error: 1.lhs:21:3: error: • Type variable ‘t’ is mentioned in the RHS, but not bound on the LHS of the family instance • In the type instance declaration for ‘ToType’ In the instance declaration for ‘FromTypeMaybe ('Nothing :: Maybe Type)’ | 21 | > instance forall (t :: Type). FromTypeMaybe ('Nothing :: Maybe Type) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Well, i'm not sure, that understand why 'forall' in instance head may not be used as family's LHS, but.. that's another question. On the other hand, if i try to write 'Just instance using type-variable 't' as kind-variable (in the same manner as 'Nothing has): instance forall (t :: Type). FromTypeMaybe ('Just t :: Maybe t) where i get an error too: 1.lhs:25:47: error: • Expected kind ‘Maybe t’, but ‘'Just t’ has kind ‘Maybe *’ • In the first argument of ‘FromTypeMaybe’, namely ‘('Just t :: Maybe t)’ In the instance declaration for ‘FromTypeMaybe ('Just t :: Maybe t)’ | 25 | > instance forall (t :: Type). FromTypeMaybe ('Just t :: Maybe t) where Well, that's also probably expected, because though i've declared type-variable 't' with kind 'Type' in forall, due to 'DataKinds' extension type 't' is also promoted to kind 't' and, thus, by using ('Just t :: Maybe t) i say, that ('Just t) should have kind 'Maybe t', not 'Maybe Type', which it really has. But if that's so, how working 'Nothing instance instance forall (t :: Type). FromTypeMaybe ('Nothing :: Maybe t) where may work at all? It has the same problem as 'Just instance above: type-variable 't' is promoted to kind 't' and 'Nothing will have kind 'Maybe t' instead of 'Maybe Type' ?

3 10

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 29 Jan '22

29 Jan '22

Dear Haskell community, the GHC Steering committee is seeking nominations for at least two new members. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. In particular, please have a look at the bylaws at https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until February 11th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

[ANN]: traverse-code
by David Feuer 28 Jan '22

28 Jan '22

I've put up a tiny little package[1], traverse-code, offering a generic way to "traverse" in Template Haskell's `Code m`. class TraverseCode t where traverseCode :: Quote m => (a -> Code m b) -> t a -> Code m (t b) I wrote this primarily as a way to "lift" operations on polymorphic data structures into Template Haskell. For example, for Data.Sequence, you can write triple :: a -> a -> a -> Seq a triple a b c = $$(sequenceCode $ fromList [ [||a||], [||b||], [||c||] ]) The `triple` function will not form its arguments into a list and then convert it to a sequence; rather, it will build the result sequence directly, using the underlying constructors. A generic default definition is available for all instances of Generics.Linear.Generic1. See linear-generics[2] for information about how to derive those. There's nothing particularly linear about traverse-code, but linear-generics has a more general Generic1 than GHC.Generics offers. [1] https://hackage.haskell.org/package/traverse-code [2] https://hackage.haskell.org/package/linear-generics

2 1

Munich Virtual Haskell Meeting, 2022-01-31 @ 19:30
by Leah Neukirchen 28 Jan '22

28 Jan '22

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, January 31 on Jitsi at 19:30 CEST. **Due to the pandemic, this meeting will take place online!** For details see here: https://muenchen.haskell.bayern/dates.html A Jitsi link to join the room is provided on the page. Everybody is welcome, especially the Haskellers from Bavaria that do not usually come to our Munich meetings due to travel distance! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Question about ambiguity and defaulting in recursive bindings
by Benjamin Redelings 26 Jan '22

26 Jan '22

Hi, I am trying to understand how GHC treats the following declaration. f c i = if i == 10 then c else g c 'b' g 'a' w = f 'b' 10 g z w = z l = (f 'a' (1::Int), f 'a' (1.0::Double)) It seems to me like, after defaulting, f should have the following type: Char -> Int -> Char However, looking at -ddump-tc, GHC is deriving the polymorphic type forall a. (Eq a, Num a) => Char -> a -> Char That's much nicer, because its more flexible. But I'm confused, because it looks like GHC is defaulting 'g', but not 'f', even though they are in the same recursive group. This seems to contradict "Typing Haskell in Haskell", which is what I am looking at right now. If that is correct, can anybody point me to a paper or documentation about how this works? More detail: 1. If I understand correctly, the definitions of `f` and `g` are mutually recursive, and should be typed together, and the declaration group is not restricted. 2. It seems like, before generalization, we have f :: Char -> a -> Char g :: Char -> Char -> Char Predicates include (Eq a, Num a) 3. Looking at the paper "Typing Haskell in Haskell" (THIH), it looks like the predicates (Num a, Eq a) should cause an ambiguity in the definition of g: * a is present in the definition of f, but not the definition of g * so the type (Eq a, Num a) => Char -> Char -> Char is ambiguous. * more generally, it seems like THIH treats any predicates with a type variable that is part of some, but not all, types in the declaration group to be ambiguous. Does this sound right? 4. Then, again following THIH, this ambiguous predicate should be defaulted to Int. I THINK this should lead to f :: Char -> Int -> Char g :: Char -> Char -> Char 5. However, I'm still not sure I'm understanding this right, because a few things still don't make sense: * First, THIH seems to eliminate the defaulted predicates without substituting a -> Int. But the type for f DOES mention `a`, so how can we avoid substituting? * Second, GHC accepts the code with no warnings or errors. There is some kind of defaulting going on, because GHC rejects the code if I add "default ()". Is there some way for GHC to default only g, but not f? I wonder if this involves a difference between Haskell '98 and Haskell 2010? I also wonder how much I should rely on THIH? Maybe the language has moved on since then? -BenRI

2 2

Recursive constraints with type families
by Dmitriy Matrosov 26 Jan '22

26 Jan '22

Hi. I've stumbled upon a simple problem with recursive type family: > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE TypeApplications #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE StandaloneKindSignatures #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE UndecidableInstances #-} > > import GHC.TypeLits > import Data.Proxy > import Data.Kind > > type C :: Nat -> Constraint > type family C x where > C 0 = KnownNat 0 > --C x = (KnownNat x, C (x - 1)) > C x = (KnownNat x, C 0) > --C x = KnownNat x > > --type C2 x = (KnownNat x, C2 1) > > showNat :: forall (n :: Nat). C n => Proxy n -> String > showNat _ = show $ natVal (Proxy @n) and the error is Prelude> :r [1 of 1] Compiling Main ( constraint-type-family.lhs, interpreted ) constraint-type-family.lhs:31:22: error: • Could not deduce (KnownNat n) arising from a use of ‘natVal’ from the context: C n bound by the type signature for: showNat :: forall (n :: Nat). C n => Proxy n -> String at constraint-type-family.lhs:30:3-56 Possible fix: add (KnownNat n) to the context of the type signature for: showNat :: forall (n :: Nat). C n => Proxy n -> String • In the second argument of ‘($)’, namely ‘natVal (Proxy @n)’ In the expression: show $ natVal (Proxy @n) In an equation for ‘showNat’: showNat _ = show $ natVal (Proxy @n) | 31 | > showNat _ = show $ natVal (Proxy @n) | ^^^^^^^^^^^^^^^^^ If i write just C x = KnownNat x everything works fine. I guess, the reason is UndecidableInstances, but why and then, how can i build constraints recursively and make it work? Thanks. PS. Initially, this 'showNat' was something like countDown :: forall (n :: Nat). C n => Proxy n -> String countDown _ = let x = natVal (Proxy @n) in if x > 0 then show x ++ countDown (Proxy @(n - 1)) else "end" but it does not work.

4 6

Missing feature of Coercible, or necessary caution?
by Tom Ellis 25 Jan '22

25 Jan '22

Consider the following program. {-# LANGUAGE TypeApplications #-} import Data.IntMap (IntMap, mapKeysMonotonic, Key) import Data.Coerce (coerce) newtype MyMap = MyMap (IntMap Bool) doesn'tWork :: (Key -> Key) -> MyMap -> MyMap doesn'tWork = coerce mapKeysMonotonic works :: (Key -> Key) -> MyMap -> MyMap works = coerce (mapKeysMonotonic @Bool) mapKeysmonotonic has type (Key -> Key) -> IntMap a -> IntMap a and we attempt to coerce it to type (Key -> Key) -> MyMap -> MyMap since MyMap is a newtype around IntMap Bool this ends up generating the constraint Coercible a Bool and there is no way to specify that constraint given that a doesn't otherwise appear in the top-level type. Hence doesn'tWork will not type check. If I force the type of a to be Bool using a TypeApplication then it does type check (works). But is this a missing feature of GHC's Coercible system? Since a is not otherwise constrained is it not valid for GHC to choose it to be Bool ? Coercible instances contain now observable content so no observable behaviour could depend on the particular choice of Coercible a Bool instance, and choosing a ~ Bool is the natural one. Is there some violation of type safety or otherwise broken behaviour that could arise from choosing arbitrary Coercible instances on type variables that are not otherwise constrained? Tom

2 2

Guards on variable bindings
by Tom Ellis 24 Jan '22

24 Jan '22

According to GHC there are multiple declarations of bar, but not of foo. I don't understand. Why is it not valid to have multiple clauses for a variable binding? Tom bar | False = () bar = () foo _ | False = () foo _ = ()

2 4