- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] TDNR without new operators or syntax changes
by Jeremy . 22 May '16

22 May '16

Yes, that it indeed was I meant. AntC seems to be replying to a much more complicated/invasive proposal than what I had intended, apologies if I wasn't clear. (I see in retrospect that I may have misunderstood the original TDNR proposal, understandably leading to confusion.) 1. If the compiler encounters a term f a, and there is more than one definition for f in scope (after following all of the usual rules for qualified imports); 2. And exactly one of these definitions matches the type of a (or the expected type of f if given); 3. Then this is the definition to use. That is all, although point 2 could be extended to consider the return type of f or other arguments as well. Even with the extension on, it would have no effect on programs which compile without it. This has nothing to do with ORF, which relies on magic type classes (although there is some overlap in what it can achieve). The primary use-case I had in mind is disambiguating name clashes between local and/or unqualified imports. Cross-posting to cafe and libraries as this doesn't seem to have attracted a lot of interest in users. Maybe it's just a boring proposal, maybe I didn't post it to the right list.

3 2

Going insane over overlapping instances
by Brian Hurt 22 May '16

22 May '16

This is driving me nuts. So I have a type class HasStructParser I've defined. Details are irrelevant except that if you have HasStructParser defined, then ToJSON is also defined. So I have: instance HasStructParser s => ToJSON s where ... But now, any type that defines ToJSON any other way causes an Overlapping Instances error to happen- the conflict being between the real ToJSON implementation and the one deriving from HasStructParser- this despite the fact that there is no implementation for HasStructParser for the given type. Now, I don't want to allow Overlapping Instances because if there are *real* overlapping instances, I want that to be an error. For instance, if a structure did implement HasStructParser and some other implementation of ToJSON, I want to know. I suppose I could go: newtype JSON a = JSON a instance HasStructParser s => ToJSON (JSON s) where ... But this strikes me as being ugly- now I have to add pointless JSON constructors everywhere I want to convert to (or from) JSON. And this also pollutes my type signatures all over the place- now I can't write a servant endpoint type like: :<|> "foo" :> "bar" :> Get '[JSON] [Foo] I have to write: :<|> "foo" :> "bar" :> Get '[JSON] [JSON Foo] And, of course, if I want to have multiple different types of outputs, now we're off to the races. So my question is, is there a way to do this without throwing the baby out with the bath water (turning on overloaded instances) or being seriously ugly? Or am I just screwed? Brian

2 1

Representation of 3-D objects in non-continuous space
by Michael Litchard 22 May '16

22 May '16

I've been poking at the problem that I've talked about in the following threads. https://groups.google.com/forum/#!searchin/haskell-cafe/michael$20litchard|… https://groups.google.com/forum/#!searchin/haskell-cafe/michael$20litchard|… And my misguided conclusions here https://groups.google.com/forum/#!topic/haskell-cafe/PMtYhVQ5nNQ I'm trying to write a clone in haskell of the space-system implemented in http://swmud.org. The biggest error in my thinking so far is assuming I could do without spatial extent. Nope, these objects in space will have to have spatial extent. So no octree for me. The advice and comments from the first two threads prompted me to investigate R-trees. I could only find specifics about how to describe 2-D. Until I found this paper on layered R-Trees. http://www.isprs.org/proceedings/XXXIII/congress/part4/1216_XXXIII-part4.pdf This looks like what I want. Here's my re-formulation of the criteria: (1) Objects in space will be either ships that can move or stationary things like non-moving game-controlled ships, space-stations , moons and planets. (2) Objects will have spatial extent. Will use bounding volumes to help determine collisions. (3) Space is non-continuous (4) Movement happens by setting a destination vector and a speed. There's no steering exactly, but you can change destination while moving, slow down or stop suddenly. (5) Represent this space with a layered R-tree, This tree will at most have say, 200-300 objects in it, most of which could be moving around in this space. It's the number of objects that have me wondering if layered r-tree might be too heavy-weight. If so, Any links to R-tree variants that include bounding volumes? I could only find ones with bounding boxes.

1 1

ANNOUNCE: testbench-0.1.0.0
by Ivan Lazar Miljenovic 22 May '16

22 May '16

I've just released a new library onto Hackage that aims to help you writing comparison-oriented benchmarks by: a) reducing the duplication found when using criterion directly b) let you test your benchmarked values/functions to ensure that they have the same result/satisfy a given predicate c) provide more comparison-oriented output I've written more about it here: https://ivanmiljenovic.wordpress.com/2016/05/23/test-your-benchmarks/ Or you could go straight to the Hackage page here: http://hackage.haskell.org/package/testbench -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0

Haskell Meetup group in Delhi, India
by Anupam Jain 21 May '16

21 May '16

Hi all, I just started a meetup group for Haskellers in and around Delhi NCR, India. The plan is to organise regular (monthly) meetups, talks, workshops etc for Haskell / FP enthusiasts at all skill levels. Anyone interested is welcome to join at - http://meetu.ps/c/2K4ft/FT8H/f. Also, since we are just getting started, the best way to help right now would be to spread the word! Thanks, Anupam Jain

1 0

ANN: stack-1.1.2
by Emanuel Borsboom 20 May '16

20 May '16

Release notes: - Official FreeBSD binaries are now available <http://docs.haskellstack.org/en/stable/install_and_upgrade/#freebsd> ( #1253 <https://github.com/commercialhaskell/stack/issues/1253>). Major changes: - Extensible custom snapshots implemented. These allow you to define snapshots which extend other snapshots. See #863 <https://github.com/commercialhaskell/stack/issues/863>. Local file custom snapshots can now be safely updated without changing their name. Remote custom snapshots should still be treated as immutable. Behavior changes: - stack path --compiler was added in the last release, to yield a path to the compiler. Unfortunately, --compiler is a global option that is useful to use with stack path. The same functionality is now provided by stack path --compiler-exe. See #2123 <https://github.com/commercialhaskell/stack/issues/2123> - For packages specified in terms of a git or hg repo, the hash used in the location has changed. This means that existing downloads from older stack versions won’t be used. This is a side-effect of the fix to #2133 <https://github.com/commercialhaskell/stack/issues/2133> - stack upgrade no longer pays attention to local stack.yaml files, just the global config and CLI options. #1392 <https://github.com/commercialhaskell/stack/issues/1392> - stack ghci now uses :add instead of :load, making it potentially work better with user scripts. See #1888 <https://github.com/commercialhaskell/stack/issues/1888> Other enhancements: - Grab Cabal files via Git SHA to avoid regressions from Hackage revisions #2070 <https://github.com/commercialhaskell/stack/pull/2070> - Custom snapshots now support ghc-options. - Package git repos are now re-used rather than re-cloned. See #1620 <https://github.com/commercialhaskell/stack/issues/1620> - DESTDIR is filtered from environment when installing GHC. See #1460 <https://github.com/commercialhaskell/stack/issues/1460> - stack haddock now supports --hadock-arguments. See #2144 <https://github.com/commercialhaskell/stack/issues/2144> - Signing: warn if GPG_TTY is not set as per man gpg-agent Bug fixes: - Now ignore project config when doing stack init or stack new. See #2110 <https://github.com/commercialhaskell/stack/issues/2110> - Packages specified by git repo can now have submodules. See #2133 <https://github.com/commercialhaskell/stack/issues/2133> - Fix of hackage index fetch retry. See re-opening of #1418 <https://github.com/commercialhaskell/stack/issues/1418#issuecomment-2176338…> - HPack now picks up changes to filesystem other than package.yaml. See #2051 <https://github.com/commercialhaskell/stack/issues/2051> - “stack solver” no longer suggests —omit-packages. See #2031 <https://github.com/commercialhaskell/stack/issues/2031> - Fixed an issue with building Cabal’s Setup.hs. See #1356 <https://github.com/commercialhaskell/stack/issues/1356> - Package dirtiness now pays attention to deleted files. See #1841 <https://github.com/commercialhaskell/stack/issues/1841> - stack ghci now uses extra-lib-dirs and extra-include-dirs. See #1656 <https://github.com/commercialhaskell/stack/issues/1656> - Relative paths outside of source dir added via qAddDependentFile are now checked for dirtiness. See #1982 <https://github.com/commercialhaskell/stack/issues/1982> - Signing: always use --with-fingerprints ------------------------------ Thanks to all our contributors for this release: - Benno Fünfstück @bennofs <https://github.com/bennofs> - Emanuel Borsboom @borsboom <https://github.com/borsboom> - Levi Notik @levinotik <https://github.com/levinotik> - Michael Sloan @mgsloan <https://github.com/mgsloan> - Michael Snoyman @snoyberg <https://github.com/snoyberg> - Oleg Grenrus @phadej <https://github.com/phadej> - Sebastian Graf @sgraf812 <https://github.com/sgraf812> - Simon Jakobi @sjakobi <https://github.com/sjakobi> - Tim Dysinger @dysinger <https://github.com/dysinger> - Yann Esposito @yogsototh <https://github.com/yogsototh> - Yuji Yamamoto @igrep <https://github.com/igrep> And thanks also to the 150+ contributors to past releases!

1 0

ANNOUNCE: accelerate-typelits
by Martin Heuschober 20 May '16

20 May '16

I want to announce my first haskell project big/clean enough so I consider it possibly useful to others - accelerate-typelits is a library that provides vectors/matrices in a typesafe way - i.e. The dimension of the entities are stored on type level as (Nats). There is basic vector/matrix functionality, documentation and tests for those functions (mostly properties). If I have time I will provide some basic examples and a bit more complicated example within the next week. It is available on hackage https://hackage.haskell.org/package/accelerate-typelits as well as on github https://github.com/epsilonhalbe/accelerate-typelits. I would be happy to get some feedback. - Martin

2 4

Modeling space for a MUD - revisited.
by Michael Litchard 20 May '16

20 May '16

This is a continuation of a conversation started in the following two links. https://groups.google.com/forum/#!searchin/haskell-cafe/michael$20litchard|… https://groups.google.com/forum/#!searchin/haskell-cafe/michael$20litchard|… I am trying to model a 3-D space for a mudlike. Here's the criteria I have so far: (1) Objects in space will be either ships that can move or stationary things like non-moving game-controlled ships, space-stations , moons and planets. (2) Objects will not have spatial extent (3) Space is non-continuous (4) Collision happens only when one object is stationary or each moving objects are moving directly toward each other, on the same line. (5) Movement happens by setting a destination vector and a speed. There's no steering exactly, but you can change destination while moving, slow down or stop suddenly. (6) Octree looks like the data structure I want to use for modeling. I'm looking at http://hackage.haskell.org/package/Octree as best library for my application, if I am right about how to go about updating. I'm not sure I am. I think I can use the octree to track things in space, rather than having a node for each point. At most there will be say, 200 objects in space, therefore at most 200 nodes in the tree. So I am visualizing the following steps: (1) Begin with a [(Vector3 <http://hackage.haskell.org/package/Octree-0.5.4.2/docs/Data-Octree.html#t:V…>, a)]. This includes stationary objects and ships already in space. (2) If a new ship entered this space, add it to end of list. (3) make Octree a from above list (4) ships move by setting destination vector and then speed, calculate next Vector3 they will be at next tick (5) Make a new [(Vector3 <http://hackage.haskell.org/package/Octree-0.5.4.2/docs/Data-Octree.html#t:V…>, a)] (6) Go to (1) The first problem with this is in creating a new Octree from a list, when I would rather just recreate the new tree with a subtree of the nodes that changed. The library I am considering does not offer that operation. Maybe this is not a real problem considering the maximum objects in space will be 200. There may be other problems with my thinking here. I look to haskell-cafe for any insight it may offer.

1 0

Re: [Haskell-cafe] ANNOUNCE: accelerate-typelits
by Johannes Waldmann 20 May '16

20 May '16

> .. a library that provides vectors/matrices in a typesafe way Nice! But what does it have to do with accelarate :-) I mean, we could also use this somewhere in Data.Array? Else, it's re-invented all over the place - and poorly, e.g., https://github.com/jwaldmann/ersatz/blob/master/tests/Z001.hs#L51 - J.W.

1 0

What's your favorite flavor of Iterator type
by Silvio Frischknecht 19 May '16

19 May '16

Hello, We know about Foldable, but sometimes you just want more functionality like: give me the rest of the string! Or a function to build pieces back together. I've been experimenting a bit and come up with 6 flavors of Iterators that do the same thing. Of course they all work for containers like ByteStrings, Text. 1) Haskell98 version (I like) data Iterator98 list ele = Iterator98 { next98 :: Maybe (ele, Iterator98 list ele), ... rest98 :: list, concat98 :: [list] -> list } -- How we can create an Iterator98 listIter98 :: [a] -> Iterator98 [a] a -- How the sum type looks sum98 :: (Num n) => Iterator98 listN n -> n Performance: *3 I'll also usually give the type of the constructor and sum functions. I also benchmarked the sum functions for [] and compared them to the best sum function I could come up with (which is significantly faster than the sum in Prelude!!! because it's strict. Whoever came up with the idea of making it non-strict, must have been drunk at the time :)). I like how handy and simple typed the Haskell98 version is. There are absolutely no superfluous Types or Contexts. However, *3 is quite a heavy penalty and it might even get worse when more functions are added. 2) Haskell98 Explicit (ambivalent) data IteratorExplicit98 iter list ele = IteratorExplicit98 { iterExplicit98 :: iter, nextExplicit98 :: iter -> Maybe (ele, iter) ... restExplicit98 :: iter -> list } listIterExplicit98 :: [a] -> IteratorExplicit98 [a] [a] a sumExplicit98 :: (Num n) => IteratorExplicit98 it list n -> n Performance: *1 It is explicit and it is still quite nice to use. There is however always that extra argument. Note: `iter` and `list` could potentially be different (in all examples). They are in Haskell however usually the same. Performance could be different, if you create and destroy a lot of data of type IteratorExplicit98. However, that won't usually be the case. 3) TypeFamilies (I don't like) class IteratorTF i where type ListTF i type ElemTF i nextTF :: i -> Maybe (ElemTF i, i) ... restTF :: i -> ListTF i instance IteratorTF2Class [ele] ele where ... sumTF :: (Num n, IteratorTF it, ElemTF it ~ n) => it -> n Performance: *1 I used to like type families. But now I'm a bit fed up with ~ contexts. This would be the "Rust" version. Interesting point: List and Elem functions could be separated into two classes. I.e. Note that no list type exists in the type of "sum". 4) TypeFamilies2 (ambivalent) class IteratorTF2Class list ele where data IteratorTF2 list ele nextTF2 :: IteratorTF2 list ele -> Maybe (ele, IteratorTF2 list ele) ... restTF2 :: IteratorTF2 list ele -> list instance IteratorTF2Class [ele] ele where data IteratorTF2 [ele] ele = ListIterTF2 [ele] sumTF2 :: (Num n, IteratorTF2Class list n) => IteratorTF2 list n -> n Performance: *1 Better than the last. However, IteratorTF2Class, IteratorTF2 are two Type-ish things where one would be preferred. This is my preferred method where all functions are carried in the type. 5) MultiParameterTypeClasses and Functional Dependencies (ambivalent) class IteratorMPTC iter list ele | iter -> list, iter -> ele where nextMPTC :: iter -> Maybe (ele, iter) ... restMPTC :: iter -> list instance IteratorMPTC [a] [a] a where sumMPTC :: (Num n, IteratorMPTC it list n) => it -> n Performance: *1 About the same as 3). The user will still be exposed to various individual types ":: it". That is not as bad as it is in "Rust", since (as already stated) in Haskell usually "list == it". This is similar to the parsec approach. class (Monad m) => Stream iter m ele | iter -> ele Parsec has no "rest" function so the "list" type is not needed. But they have an additional monad type. 6) Existential Quantification (my favorite) data IteratorEQ list ele = forall iter . IteratorEQ { iterEQ :: iter, nextEQ :: iter -> Maybe (ele, iter) ... restEQ :: iter -> list } listIterEQ :: [a] -> IteratorEQ [a] a sumEQ :: (Num n) => IteratorEQ list n -> n Performance: *1 Looks as nice as Haskell98 and is as fast as Haskell98Explicit. Btw. This is probably how It would be done in "C" with iter = void*. Additional thoughts: * Do we really need the "list" type. Couldn't we simply return iterators instead of the original "list" type. In 3) and 5), they will *usually* be the same anyway. * In 3) and 5) the typeclasses could be split to separate ele and list. * On the other hand combining Iterators will be very annoying for 3) and 5) data ZipIterator ... instance IteratorMPTC (ZipIterator (?) (elem, elem')) ? (elem, elem') where zip :: (IteratorMPTC iter list elem, IteratorMPTC iter' list' elem') -> ZipIterator ? (elem, elem') Which is your favorite? Why? Did I forget any good ones? Cheers Silvio

2 1