- Haskell-Cafe - Haskell.org

optparse-applicative with attoparsec parser
by PICCA Frederic-Emmanuel 04 Feb '22

04 Feb '22

Hello, I Try to write a parser for this command line binoculars-ng --debug process data/test/config_sixs_ruche_flymedv_3.ini 698-734 735-736 But I have this problem Invalid argument `735-736' The parser used for this is this one processOptions :: Parser Options processOptions = Process <$> optional config <*> optional (argument (eitherReader (parseOnly configRangeP . pack)) (metavar "RANGE")) it use the configRangeP attoparser parser whcih knows how to deal with the string "698-734 735-736" configRangeP :: Parser ConfigRange configRangeP = ConfigRange <$> (inputRangeP `sepBy` many (satisfy isSep)) where isSep :: Char -> Bool isSep c = c == ' ' || c == ',' the result should be this one Just (ConfigRange [InputRangeFromTo 698 734,InputRangeFromTo 735 736]) so my question how should I fix my processOptions fucntion in order to deal with this problem. thanks for considering Frederic

2 1

Asking for advice on category for a paper for ICFP
by Anton Kholomiov 02 Feb '22

02 Feb '22

Hi! I'm trying to write a paper for ICFP, This is my first paper of this kind. Can you please help me to choose the right category for it? The paper is about a novel technique of implementation of FRP. I've studied the Haskell FRP zoo and I can confirm that it's novel. In my opinion it's very elegant and simple, but of course I'm biased :) So far so good. Can you please help me to choose the right category for it? Is it a normal research paper or is it a functional pearl? So the FRP is an old technique, but I propose a novel variant of implementation which I hope is easy to study even in normal class rooms and does not contain unsafePerform tricks. Cheers, Anton

5 6

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

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