January 2022 - Haskell-Cafe

[ANN] cabal-clean (new tool)
by Andreas Abel 20 Aug '22

20 Aug '22

=== Wondering where your disk space goes with too many Haskell projects compiled with too many GHC versions? === https://hackage.haskell.org/package/cabal-clean https://github.com/andreasabel/cabal-clean `cabal-clean` is a small executable that removes outdated cabal build artifacts from `dist-newstyle`. A build tree is considered outdated if there is one with either - a newer version of the package you are building, or - a newer minor version of the GHC compiler. In contrast to `cabal clean`, the tool `cabal-clean` retains the latest build trees for each GHC major version. Thus, it is geared towards multi-GHC development. Example: (self-applied to cabal-clean's build directory) --- 3.7M ghc-8.8.4 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210815 --- 3.7M ghc-9.0.1 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210924 +++ 3.6M ghc-8.10.7/cabal-clean-0.1.20210924 +++ 3.7M ghc-9.0.1 /cabal-clean-0.1.20210924 The directories prefixed with --- will be deleted, the ones with +++ retained. Disclaimers: 1. cabal-clean does not check whether deletion will cause dangling references like broken symlinks etc. (Could happen if you created a symlink to an executable that resides in one of the deleted build directories.) 2. cabal-clean does not read nor utilize information from the .cabal file. 3. Calls `du` ("disk usage"), so, might not work on Windows. Enjoy, Andreas

6 6

Explicit type signatures and wrappers / impedance-matching
by Benjamin Redelings 23 Feb '22

23 Feb '22

Hi, I am trying to understand (and implement) how Haskell handles explicit type signatures. Specifically, I'm trying to understand how explicit type signatures interact with wrappers. 1. Is there any paper or documentation that explains wrappers and/or explicit type signatures in detail? There are some non-obvious details regarding wrappers, such as using eliminating type arguments by supplying the Any type as an argument... 2. Do explicit type signatures impose any unification constraints, or can they be thought of entirely in terms of wrappers? For example, if we have g :: Int -> Int (f,g) = (\x ->x, f) then the signature for g is added to the environment when typing the right-hand-side. One way that this could be handled is: (i) typecheck rhs -> rhs_type (ii) generate type of lhs with fresh variables for every binder -> lhs_type = (a,b) (iii) unify(lhs_type, rhs_type) (iv) do one-way unification: match(inferred-type-of-g, explicit-type-for-g) Is this correct? Step (iv), the way that I have written it, would impose unification constraints. Without considering the type signature, we would have { f_mono :: a -> a, g_mono :: a -> a} If we just use wrappers to impose the explict type, it seems like we would get something like let tup = /\a.let {(f:a,g:a) = (\x:a -> x:a, f::a->a) f = /\a.case tup a of (f,g) -> f g = case tup @Int of (f,g) -> g where f :: forall a.a ->a and g :: Int -> Int. THIH seems to imply that type signatures are merely checked: no unification constraints are imposed (I think). However, ghc reports f :: Int -> Int. I apologize if this is a dumb question. I have found the definition of HsWrapper in ghc/compiler/GHC/Tc/Types/Evidence.hs, but I am still struggling a bit. thanks! -BenRI

2 4

[ANN] opc-xml-da-client, a client for the OPC XML-DA protocol
by Olaf Klinke 01 Feb '22

01 Feb '22

Dear Haskell Café, I am pleased to announce opc-xml-da-client [1,2], an implementation of (the client side of) the OPC XML-DA data access protocol. While the OPC XML-DA protocol is quite dated (2003) and has largely been superseded by other OPC flavours, it is still being used in industrial environments. OPC XML-DA is based on SOAP and the data types in the Haskell package closely reflect the protocol specification as a web services description language document [5]. This package was developed by Mlabs [3] as contract work for my employer. We release it as FOSS, with Mlabs kindly hosting the project under their Github account. To my knowledge, besides PyOPC [4] this is the only freely available OPC XML-DA library and the only Haskell OPC library. We stopped using PyOPC because Python hit performance limits while parsing the XML. Feel free to contact me or Nikita Volkov at Mlabs if you have further questions. Cheers Olaf [1] https://github.com/mlabs-haskell/opc-xml-da-client [2] https://hackage.haskell.org/package/opc-xml-da-client [3] https://mlabs.city [4] https://pypi.org/project/PyOPC/ [5] https://opcfoundation.org/XMLDA/1.0/OpcXmlDa1.00.wsdl

1 0

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

31 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 29 Jan '22

29 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 27 Jan '22

27 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