- Haskell-Cafe - Haskell.org

problem with servant and type constrains
by PICCA Frederic-Emmanuel 17 Oct '19

17 Oct '19

Hello, I have a type for my APi like this type SubscribeAPI a = "upload" :> ReqBody '[JSON] (JobSpecSub a) :> Post '[JSON] () type HomepageAPI = "homepage" :> QueryParam "id" Int :> Get '[HTML] Homepage type XdsMeAPI a = "xdsme" :> ReqBody '[FormUrlEncoded] XdsMeRequest :> Post '[JSON] (JobSpecSub a) type LogsAPI = "logs" :> ReqBody '[FormUrlEncoded] LogsRequest :> Post '[HTML] Html type ResumXdsAPI = "resumxds" :> ReqBody '[FormUrlEncoded] ResumXdsRequest :> Post '[HTML] Html type SessionIdAPI = "sessionid" :> ReqBody '[FormUrlEncoded] SessionIdRequest :> Post '[HTML] Html type MyApi a = SubscribeAPI a :<|> HomepageAPI :<|> XdsMeAPI a :<|> LogsAPI :<|> ResumXdsAPI :<|> SessionIdAPI myApi :: Job a => Proxy (MyApi a) myApi = Proxy When I try to write the handler for this API, I have this error message for the next code myAPIServer :: Job a => Beamline -> JobQueue a -> Server (MyApi a) myAPIServer beam jobQueue = handleJobSpec :<|> handleHomepage :<|> handleXdsMe :<|> handleLogs :<|> handleResumXds :<|> handleSessionId where handleJobSpec :: Job b => JobSpecSub b -> Handler () handleJobSpec jobSpec = liftIO $ enqueue jobSpec jobQueue • Couldn't match type ‘a’ with ‘b’ ‘a’ is a rigid type variable bound by the type signature for: myAPIServer :: forall a. Job a => Beamline -> JobQueue a -> Server (MyApi a) at src/Web.hs:235:1-66 ‘b’ is a rigid type variable bound by the type signature for: handleJobSpec :: forall b. Job b => JobSpecSub b -> Handler () at src/Web.hs:238:5-56 Expected type: JobQueue b Actual type: JobQueue a • In the second argument of ‘enqueue’, namely ‘jobQueue’ In the second argument of ‘($)’, namely ‘enqueue jobSpec jobQueue’ In the expression: liftIO $ enqueue jobSpec jobQueue • Relevant bindings include jobSpec :: JobSpecSub b (bound at src/Web.hs:239:19) handleJobSpec :: JobSpecSub b -> Handler () (bound at src/Web.hs:239:5) jobQueue :: JobQueue a (bound at src/Web.hs:236:18) myAPIServer :: Beamline -> JobQueue a -> Server (MyApi a) (bound at src/Web.hs:236:1) | 239 | handleJobSpec jobSpec = liftIO $ enqueue jobSpec jobQueue | ^^^^^^^^ I understand that I need to explain haskell that a ~ b. So my question is how can I do this :) thanks for your help Frederic

2 1

Re: [Haskell-cafe] stack: pandoc fails to build as dependency
by Olaf Klinke 17 Oct '19

17 Oct '19

>> [...] Can you get more info about what the linker error is? > Indeed, the linker exiting with status 1 without any stderr > message sounds like your linker is crashing. > take the last `ghc` invocation it makes, run that directly and add `-v` to that to get GHC's verbose output, which will show you the full linker invocation I don't know yet what causes the linker to crash, but I found a work-around: If I download any pandoc version, extract it and run `stack build` inside that directory, it is fine. So I created a symlink to that local pandoc dir inside my package root and made pandoc a part of my own package. Then everything builds all right. Hence there must be something going wrong when stack downloads and builds pandoc somewhere inside .stack-work/. It seems difficult to just run the last sub-command as Niklas suggests, because after the crash all the temporary files of the failed build are gone. But I'll keep investigating, thanks for the suggestions! Olaf

2 1

Windows, doctest and auxiliary FFI wrappers?
by Viktor Dukhovni 16 Oct '19

16 Oct '19

The Network.DNS library contains a bit of helper C-code for determining the default DNS servers on Windows. This code is linked in by Cabal, when building object code for the library on Windows. The library also has 140 "doctest" examples in the haddock comments, which I'd like to test on Windows via AppVeyor. I'm not having much luck making the dependency on the cbits visible to the GHCi invocations executed by "Test.Doctest". Does anyone have some experience getting this sort of thing to work? What I've tried: 1. Add "-liphlpapi" into the "doctest" command argument list, this proved necessary, but not sufficient. 2. Build a separate internal library (supported in Cabal 2.0 and later), which is a dependency of the main library and links in the C glue code, but this proved to be a significant rabbit hole... In fact approach 2 seems like the more promising one, but it runs into a substantial obstacles: a. Building internal libraries requires a "Simple" Cabal build, but the cabal-doctest package which automates compiling doctests, requires a "Custom" build type. :-( b. A Simple build, means abandoning cabal-doctest, and using "doctest" directly, but the new sandbox builds place package artefacts in locations that the command-line invoked by "Test.DocTest.doctest" does not know how to find. It appears that the "Custom" build from cabal-doctest is there for a good reason: it hooks into Cabal's build process, and has access to enough metatata, to generate wrapper code that invokes doctest with an argument list of the form: -XCPP -i -i<DISTDIR>/build/<ARCHDIR>/<GHCVER>/<PKG>-<VER>/build/autogen -i<DISTDIR>/build/<ARCHDIR>/<GHCVER>/<PKG>-<VER>/build -i<SRCDIR> -package-env=- -hide-all-packages -no-user-package-db -package-db=<CABALGLOBALSTORE>/<GHCVER>/package.db -package-db=<DISTDIR>/packagedb/<GHCVER> -package-db=<DISTDIR>/build/<ARCHDIR>/<GHCVER>/<PKG>-<VER>/package.conf.inplace -optP-include -optP<DISTDIR>/build/<ARCHDIR>/<GHCVER>/<PKG>-<VER>/build/autogen/cabal_macros.h ...visible packages... ...modules to doctest... which are needed for the extracted doctest fragments to find their dependencies. Hard-coding such arguments into the "Simple" build seems to work, but is hardly maintainable. I've not yet found an interface in the Cabal library that would divulge these magic strings as a function of the "pkg.cabal" file, something of the shape: cabalMagicGhcArgs :: FilePath -> IO [String] would make it possible to compute the arguments at runtime (rather than build-time) in a Simple build, without having to use a Custom build to machine-generate wrapper code. Other than the above, I'm out of ideas for now, any help much appreciated. -- Viktor.

1 1

Using GHCJS on firebase functions
by Ruben Astudillo 16 Oct '19

16 Oct '19

Dear list Has anyone used GHCJS on Firebase functions? How has it been your experience? Would you recommend it or offer al alternative?. -- -- Ruben -- PGP: 4EE9 28F7 932E F4AD

1 0

Avoiding code-duplication for what is roughly fmap
by Sebastiaan Joosten 15 Oct '19

15 Oct '19

Hi all, I'm writing a lot of code that looks like this: instance WhiteSpaced ClassItem where removeWS (Method a b c) = Method (removeWS a) (removeWS b) (removeWS c) removeWS (Declaration b) = Declaration (removeWS b) Typically, all the way at the end there's an instance that deviates (sometimes the deviating instances are somewhere in the middle). I need to do this for a lot of functions, and a lot of data types, and all I'm doing here is rewriting the data-type declaration in a different syntax (except that you do not know the types of a, b and c from the above). For the sake of maintainability, I want to avoid this code-duplication and focus only on the deviating instances. How to do better? I don't see how to use generics (in the hope of only writing 'instance WhiteSpaced ClassItem where' instead of the three lines above) for this: the types for a, b and c are all different here. Would this be easier with Template Haskell? (in the hope of only writing $(''something ClassItem) instead of the three lines above) My main concern is maintainability, an ideal solution is either a clear one-liner or a library import (in the same way that aeson allows me to use generics or Template Haskell without needing to know much about them). Other solutions are welcome too. Best, Sebastiaan

4 5

Re: [Haskell-cafe] Is join useful for every monad?
by Ruben Astudillo 14 Oct '19

14 Oct '19

On 14-10-19 16:45, Carter Schonwald wrote: > And while join is not at the moment in the Monad typeclass because of > newtype stuff Could you expand a bit on this? I remember this being on a Applicative-Monad proposal but I couldn't understand why it wasn't technically possible. -- -- Ruben -- PGP: 4EE9 28F7 932E F4AD

2 1

[Job] Muse Dev, a Galois spin-out, is hiring
by Thomas DuBuisson 14 Oct '19

14 Oct '19

Muse Dev is a Galois spin-out working to put the rest of Galois out of business by automating their jobs away [1]. By discovering "the right issues at the right time" and presenting to the developer, Muse seeks to bring static code analysis to the world as early in the development cycle as possible. We're currently working with early adopters to flesh-out the interface and add final must-haves. Oh, and we are hiring. If you like all-Haskell backends, have SaaS-related experience, and love build systems then please apply. We're interested in people with experience and enthusiasm in some of: * Haskell development * Static analysis * Build system interpretation * Kubernetes cluster deployment * AWS such as EC2, IAM, EKS * REST APIs * Enterprise system deployment, packaging, and support Location: Galois offices in Portland, Oregon or Arlington, Virginia. Resumes can be sent to careers(a)muse.dev See Also https://muse.dev <https://muse.dev/careers> https://lifeatgalois.com - We have inherited some culture from Galois but are a separate company. [1] Well, anything that can be automated about program analysis. Don't tell Galois. They'll kick us out of this nice, comfy, office.

1 0

Optional "Default" instances of classes in certain subcases (but too broad)
by Juan Casanova 14 Oct '19

14 Oct '19

Hello again, Before my question, I notice I am using this list quite a bit. I hope I am no abusing or misusing it by doing so, though. Sometimes I wonder what's the line between what I should ask here and what I should ask in StackOverflow, if that line even exists. If anyone feels I may be abusing or misusing, please let me know (in public or in private). Very simple question: Would it make sense, or does it already exist, a way to implement *optional* default instances of classes that can be used more directly than currently. I am *not* talking about providing a default implementation of a class when declaring it. I know you can do this. I am talking about when you know you can provide a generic instance of a class for a wide range of situations *which depends on some constraints*. For example: instance Bifunctor f => Functor (f a) where fmap = bimap id Of course, this is a terrible idea, because the constraints are not checked when verifying overlap and the like, and so this is very likely to break your program. What I tend to do nowadays is to add a function: fmapFromBiMap :: Bifunctor f => (b -> c) -> (f a b) -> (f a c) fmapFromBiMap = bimap id and then use it each time (the following is obviously a silly example): instance Functor (Either a) where fmap = fmapFromBiMap The only problem I see with this is that I need to remember (specially with my own type classes): 1. That I provided this "default" implementation. 2. Its name. I know these are fairly small things to complain about, but once again when you do it 100 times it becomes annoying, specially for a person who absolutely does not like doing things that I know would be able to explain how to automate. So, what I would expect is for it to be something like declaring the default instance but only use it for the types that explicitly ask for it. E.g.: optional instance Bifunctor f => Functor (f a) where fmap = bimap id instance Functor (Either a) using optional The main important point here is that I expect this to check the constraints in compile time for the class that I am giving (and if it contains type variables, only use those that are guaranteed to be complied, of course). This means that if I did: instance Functor (f a) using optional I *do not* expect it to be okay with it and automatically add the constraint Bifunctor f => to the instance. I expect it to give me a compile error: "No matching optional instance found". Of course, there could be several optional instances that overlap when using optional. But then, GHC would give me the error indicating what the options are *and I would know that it's because I put optional* and I could just replace it with the specific one to use. Maybe by giving them names? optional instance fmapFromBiMap Bifunctor f => Functor (f a) where fmap = bimap id instance Functor (Either a) using optional -- If this does not work because it overlaps with other optionals, then GHC tells me, indicates the options, and I replace with: instance Functor (Either a) using fmapFromBiMap This avoids the problem of defining the instance in general (that it will overlap with basically anything), should be easy to type check and prevents having to keep an index in your mind about useful functions that you implemented or didn't. I wonder if the "deriving" family of functionalities have anything like this, but my search has not been fruitful. Maybe using Generics? Maybe I just need good autocomplete so that I can find the function easily... it still feels like this would make sense. Juan. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

2 4

Feedback First Application
by Casper Thule Hansen 14 Oct '19

14 Oct '19

Hi. I have created my first application that I expect will go live within the next couple of months and I would like to have some feedback. The application is here: https://github.com/into-cps-association/utilities_backend and will be a project that I keep updating as I learn new stuff. I consider myself somewhat a haskell beginner, and my goal is to learn more about Haskell's features, packages and similar. So I hope that someone can point me to some places in my code that can be written in a better fashion, concepts that can be applied or similar. Of course - please try to keep it within my reach 🙂 The application is not critical in any fashion. It is not necessary with optimal performance, extensive testing and similar. Currently, I am not particularly interested in testing, I will save that for later. I hope someone can give me a few pointers! Cheers, Casper Thule

1 0

Twitter-conduit author not responding
by Corentin Dupont 12 Oct '19

12 Oct '19

Hi community, I have a small problem with the "Twitter-conduit" package: https://github.com/himura/twitter-conduit Their are several opened issues and pull requests, in particular the Twitter API changed so the package is relatively broken. I mailed the author some month ago, without response. What is the recommended course of action? Regards Corentin

2 2