- Haskell-Cafe - Haskell.org

why different type variables enforce different types?
by Rui Azevedo 02 Aug '18

02 Aug '18

after using haskell for a while i was surprised by this little thing f::a->b f a=a and this is not making sense to me till now, so please can someone enlighten me, why does haskell assume that b can not be the same type of a? after all having two distinct math variables does not mean they can not have the same value. I know i could use f::a->a, but its not the same thing, on this last case I'm requesting them to be the same type, but on the first I'm not forbidding it, is there a math reason behind it? would type inference be rendered impossible if considering the case of them being equal? thanks Rui Azevedo (neu-rah)

3 2

JOB | Permanent Java Developer (Montreal, Canada)
by James Tobin 01 Aug '18

01 Aug '18

Hello, I'm working with an employer that is looking to hire (for their Montreal office) a permanent Java developer that has extensive hands-on Java coding experience. Consequently I had hoped that some members of this mailing list may like to discuss with me further; off-list. I can be reached using "JamesBTobin (at) Gmail (dot) Com". Kind regards, James

4 3

JOB | Permanent Java Development Manager (Montreal, Canada)
by James Tobin 01 Aug '18

01 Aug '18

Hello, I'm working with an employer that is looking to hire (for their Montreal office) a permanent development manager that has extensive hands-on Java coding experience. Consequently I had hoped that some members of this mailing list may like to discuss with me further; off-list. I can be reached using "JamesBTobin (at) Gmail (dot) Com". Kind regards, James

1 0

Missing common function for Maybe types
by Marc Busqué 31 Jul '18

31 Jul '18

Hi! I have two functions: ``` foo :: a -> Maybe b bar :: a -> Maybe c ``` >From which I want to build a higher order function: ``` foobar :: a -> (a -> Maybe b) -> (a -> Maybe c) -> Either b c ``` The implementation I need is: ``` foobar x f g = case (f x) of Nothing -> g x Just y -> Just y ``` I'm a bit surprised that looking at hoogle I don't find a built-in solution for this quite common need for `Maybe` types (or perhaps for any monad). Am I looking in the wrong way? Does it exist a similar abstraction but with a different shape? Thanks in advance, Marc Busqué http://waiting-for-dev.github.io/about/

7 16

Testing a collision detection system
by mpevnev＠gmail.com 30 Jul '18

30 Jul '18

As a part of a project, I write a collision detection system. It is in dire need of testing, but designing and writing tests for all possible pairs of types of colliding geometry would be a pretty big effort - not only I would have to calculate the fact of collision manually for 20-something pairs of types of colliding geometry, I would also have to do so multiple times for each pair, since each pair requires several test cases. So the idea is to use an existing collision detection library to generate (a lot of) test cases from random data. I've found two such libraries for Haskell - HODE and Bullet. The problem is, Bullet bindings aren't documented at all, and HODE (which isn't really documented either, but at least lists available functions) is extremely ugly with IO all over the place, and manual tracking of objects' lifetimes (at least that's what I infer from `create :: World -> IO Body` and `destroyBody :: Body -> IO ()`, because again - no documentation). So my question is: does anyone know a library I could use? I'll pretty much settle for whatever. -- Michail.

5 4

using Haskell more like scripting language
by Dennis Raddle 29 Jul '18

29 Jul '18

I'm actually working in Purescript, but the issue is pretty much the same as one would encounter in Haskell. My application (animation of math-related ideas) is changing constantly. It's research, and I don't know where I'll be with it next week, or even tomorrow. For instance, the kinds of "objects" I'm animating (numbers, equations) and the way they move and interact with each other is a research project, and I'm constantly ripping out parts of my application and scavenging them for variations on a theme. My objects need state. At this point I'm thinking of just putting the state into a map with strings as keys and some kind of sum type to represent each data item I might need. So if I want to represent that an object has a particular color and position and velocity, itemState = M.fromList [("color" , DataColor blue ) ,("position", DataPoint 500.0 100.0) ,("velocity", DataVector 50.0 45.0 ) ] Which starts to look more like a dynamically-typed scripting language. But it's not hard to work with. I can uses lenses/prisms to inspect and update state, and it's okay if my program crashes on encountering malformed state. What this lets me do is create new objects that mix and match parts of old objects, and copy and paste a lot of the code. Is there a better way to do this? Is there a compromise I can make that will allow the compiler to help me out more with finding errors at compile time? D

4 4

stack test hangs when using 1.7.1 but completes with 1.4.0
by Olaf Klinke 29 Jul '18

29 Jul '18

Dear cafe, I recently upgraded (with some trouble) to stack-1.7.1 from 1.4.0. I have an older project using lts-9.2 that builds just fine when using the new stack, but it hangs on `stack test`. The difference is shown below. I suspect it is something that needs to be upgraded alongside stack. Maybe Cabal? Upgrading stack was troublesome because of different index formats, which is why using the other stack causes the rebuilds of my extra-deps, I suppose. When using stack --verbosity debug I see messages of the form Error while decoding $HOME/.stack/indices/Hackage/01-index.cache ... (this might not be an error, when switching between stack versions) Any help welcome. Olaf $> /usr/bin/stack-1.7.1 test Populated index cache. $MYPACKAGE: unregistering (missing dependencies: glpk-hs) gasp-1.0.1.0: unregistering (old configure information not found) glpk-hs-0.5: unregistering (missing dependencies: gasp) gasp-1.0.1.0: configure gasp-1.0.1.0: build gasp-1.0.1.0: copy/register glpk-hs-0.5: configure glpk-hs-0.5: build glpk-hs-0.5: copy/register $MYPACKAGE: configure (lib + exe + test) Configuring $MYPACKAGE... $MYPACKAGE: build (lib + exe + test) Preprocessing library $MYPACKAGE... <<< some more output ... >>> Registering $MYPACKAGE... $MYPACKAGE: test (suite: $PACKAGENAME-test) <<< with --verbosity debug >>> [debug] Run process within $PACKAGEDIR/: $PACKAGEDIR/.stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/$PACKAGENAME-testStub/$PACKAGENAME-testStub @(src/Stack/Build/Execute.hs:1711:27) Progress 1/2: $MYPACKAGE <<< Hangs from here on, does not consume CPU cycles >>> $> /usr/bin/stack-1.4.0 test Populated index cache. $MYPACKAGE: unregistering (missing dependencies: glpk-hs) gasp-1.0.1.0: unregistering (old configure information not found) glpk-hs-0.5: unregistering (missing dependencies: gasp) gasp-1.0.1.0: configure gasp-1.0.1.0: build gasp-1.0.1.0: copy/register glpk-hs-0.5: configure glpk-hs-0.5: build glpk-hs-0.5: copy/register $MYPACKAGE: configure (lib + exe + test) Configuring $MYPACKAGE... $MYPACKAGE: build (lib + exe + test) Preprocessing library $MYPACKAGE... <<< some more output >>> Progress: 3/4+++ OK, passed 100 tests. <<< some more output >>> Completed 4 action(s).

2 1

Monad Reader pubs?
by Donald Sitompul 28 Jul '18

28 Jul '18

I’m looking for past publications of the Monad Reader, where are they now? Donald Sitompul

2 1

Re: [Haskell-cafe] Why does this result in a runtime loop instead of a type error or typechecker loop?
by Anthony Clayden 26 Jul '18

26 Jul '18

On Thurs, Jul 26, 2018 at 05:39:00, Emil Axelsson wrote: >> Den 2018-07-26 kl. 01:02, skrev Anthony Clayden: >> >>> * On Tue, Jul 24, 2018 at 5:52 AM,Ryan Reich wrote: *>*>> This seems like the canonical illustration of the dangers of * >>>* UndecidableInstances.* >> >>* No I don't buy that explanation. The worst UndecidableInstances can do * >>* is send the type checker into a loop.* > I used to have a counter-example to that claim: https://mail.haskell.org/pipermail/haskell-cafe/2010-January/072357.html > That example was causing looping dictionaries at run time on GHC 6.10. > But now, on GHC 8.2, the program terminates. 6.10 was rather a long time ago. The whole type inference/improvement engine has had several overhauls since 2010. To be clear: you can write looping programs without type classes at all -- such as mutually recursive functions. You can write looping programs with type classes -- by turning those functions into methods in classes. You can write looping programs with type classes that need `UndecidableInstances` -- by making those classes mutual superclasses or mutual constraints on instances. That doesn't mean the `UndecidableInstances` are to 'blame' for the looping. I would blame the functions/method calls for not reducing the problem. > But one wonders if there are other ways to create looping dictionaries? With `UndecidableInstances`, yes there's plenty. And I expect that'll make the typechecker loop at compile time. The O.P. here is not getting typechecker looping, so I think the explanation is to do with method calls -- for which we need to see what's going on in the imports. AntC

1 0

Integrate GHC-API with Cabal
by Félix Baylac 26 Jul '18

26 Jul '18

Dear cafe, I am currently working on a project [1] which aims to index the code published on Stackage in order to provide a "code example" database. Basically, for each library, I want to generate a real-world example corpus for each exported symbol. Before generating this database, I need to retrieve the exported symbol of a package. So far, I have been gathering the dependencies and integrating them in the GHC pkg database using an external stack call, I then parse the cabal file and load the exposed modules using the GHC API and gather the exported symbols*. It works pretty reliably on the simple packages, however, I end up with some missing dynamic flags for some more advanced packages (missing c includes, c libraries, ASM flags, etc.). I then started to parse and load these missing attributes to GHC until I stepped back for a moment and realized I was re-implementing cabal build. I then looked for a way to "hook" my GHC API code in cabal build. This would allow cabal to both handle the dependencies gathering as well as setting up the correct GHC dyn-flags. The only resource I found was [2]. It's really clever, however, looks a bit hacky to me. Is there a better way to perform this kind of "hook"? [1] https://git.alternativebit.fr/NinjaTrappeur/Exhs [2] http://blog.ezyang.com/2017/02/how-to-integrate-ghc-api-programs-with-cabal/ * I am aware of the hoogle index generated by haddock. However, this index is missing when the haddock documentation of a package cannot be generated.

4 4