April 2015 - Libraries

Re: [Haskell-cafe] Ord for partially ordered sets
by Mike Izbicki 24 Apr '15

24 Apr '15

>> I'm confused. What is supposed to be the result of `g1 <= g2` when `g1` and >> `g2` are not comparable according to the partial order? > >False. The operators aren't a problem for this reason. The real problem is what does `compare` return? On Fri, Apr 24, 2015 at 1:32 PM, Ertugrul Söylemez <ertesx(a)gmx.de> wrote: >> I'm confused. What is supposed to be the result of `g1 <= g2` when `g1` and >> `g2` are not comparable according to the partial order? > > False. > > > Greets, > Ertugrul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

1 0

Re: [Haskell-cafe] Ord for partially ordered sets (fwd)
by Jay Sulzberger 24 Apr '15

24 Apr '15

On Fri, 24 Apr 2015, Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> wrote: > What is the validity of defining an Ord instance for types for which > mathematically the `compare` function is partially ordered? > > Specifically, I have a pull request for fgl [1] to add Ord instances > for the graph types (based upon the Ord instances for Data.Map and > Data.IntMap, which I believe are themselves partially ordered), and > I'm torn as to the soundness of adding these instances. It might be > useful in Haskell code (the example given is to use graphs as keys in > a Map) but mathematically-speaking it is not possible to compare two > arbitrary graphs. > > What are people's thoughts on this? What's more important: potential > usefulness/practicality or mathematical correctness? > > (Of course, the correct answer is to have a function of type a -> a -> > Maybe Ordering :p) > > [1]: https://github.com/haskell/fgl/pull/11 > > -- > Ivan Lazar Miljenovic Of course these type-classes (I hope I am using the word correctly) should be standard: 1. Ord, which is the class of all totally ordered set-like things 2. PoSet, which is the class of all partially ordered set-like things 3. NonStrictPoSet, which is the class of all partially ordered set-like things, but without the requirement that a <= b and b <= a implies a Equal b. 4. Things like above, but with the requirement of a Zero, with the requirement of a One, and the requirement fo both a Zero and a One. oo--JS. > Ivan.Miljenovic(a)gmail.com > http://IvanMiljenovic.wordpress.com > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >

1 0

Export ($!) from Data.Function
by Yuras Shumovich 24 Apr '15

24 Apr '15

Hello, Right now ($!) operator can be imported either from Prelude or GHC.Base. The later is specific to GHC, so it makes sense to avoid it. There are reasons to avoid Prelude too (e.g. because it pollutes name space, changes too often, etc.) We need a home module for all identifies from Prelude, so that one can import them without importing Prelude. Data.Functor seems to be a good candidate for ($!) operator home module. It already exports ($) operator. Thanks, Yuras

4 5

Applicative instance of ExceptT is wrong
by Nikita Volkov 23 Apr '15

23 Apr '15

I've recently discovered a flaw in the Applicative and Alternative instances of EitherT. I've posted the following pull request to fix them: https://github.com/ekmett/either/pull/38 The pull request contains the description of the problem. ExceptT of "transformers" contains exactly the same flaw. However it's not hosted on GitHub, so I don't know a better place to report the issue then here. Best regards, Nikita Volkov

3 2

Proposal: add alterLookupWithKey to Data.Map.Lazy (containers)
by Станислав Черничкин 21 Apr '15

21 Apr '15

Github issue: https://github.com/haskell/containers/issues/151 Summary: add alterLookupWithKey :: Ord k => (k -> Maybe a -> Maybe a) -> k -> Map k a -> (Maybe a, Map k a) function to Data.Map.Lazy. Details: implement alterLookupWithKey function which takes an update function, key and map, allowing to insert, delete or update a value in a Map and return updated map with a new value. Motivations: For insert/update/delete: same as for alter :: Ord k => (Maybe a -> Maybe a) -> k -> Map k a -> Map k a - it allows to perform insert/update/delete within single lookup. For returning updated value: same as for *LookupWithKey functions - in case of update we mind be interested in the updated value. For a "key" parameter: hornestly, don't know. *LookupWithKey functions are having (k -> .. ) -> k -> <a> -> Map k a -> (Maybe a, Map k a) signatures, but I don't see any reason to pass the key to the update function, because we always can capture the key in a closure if we whant to. The only reason is to respect existent conventions. Since we already have insertLookupWithKey and updateLookupWithKey functions it makes sence to implement alterLookupWithKey in the same way. -- Sincerely, Stanislav Chernichkin.

1 0

Data.Tree traversals
by David Feuer 21 Apr '15

21 Apr '15

Data.Tree makes Tree into a Traversable in only one way: depth-first. It seems to me that we should have a newtype to traverse in breadth-first order. David Feuer

2 2

Bed & Breakfast maintainer?
by Mike Meyer 16 Apr '15

16 Apr '15

Anyone out there maintaining (or willing to take over) the bed-and-breakfast package? 0.4.3 (the latest release) doesn't compile with 7.8 because of the changes to Typeable. The git repo has fixes for this in it, along with some other stuff, but that's nearly a year old, and hasn't been released yet. My requests to the author & maintainer (Julian Fleischer < julian.fleischer(a)fu-berlin.de>) have gone unanswered.

4 3

bed & breakfast library update?
by Mike Meyer 15 Apr '15

15 Apr '15

I've asked a couple of times over the last eight moths for an update of this library that would compile on 7.8 to be published, and gotten no response. If you're not able or interested in maintaining this library any longer, please let the community know so that someone else can take over those duties. If you can't or don't respond, I'll have to assume you're no longer able to, and see about getting another maintainer. Thank you, Mike

1 0

Floating and Data.Fixed
by Douglas McClean 14 Apr '15

14 Apr '15

Hello libraries list, (Warning: this whole message may be a waste of time, you may wish to skip it.) I'd like to inquire about the possibility of a Floating instance for Data.Fixed. (Unfortunately, not knowing of the existence of this list or the appropriate procedure, I created a trac ticket to ask about this, because that was the only forum I knew of. It's https://ghc.haskell.org/trac/ghc/ticket/10297. Sorry.) The original idea was along these lines: lift :: (HasResolution a) => (Double -> Double) -> Fixed a -> Fixed a lift f = realToFrac . f . realToFrac instance (HasResolution a) => Floating (Fixed a) where pi = realToFrac pi sin = lift sin -- etc, similar lift2 function for (**), logBase This allows the use of transcendental functions on Fixed values. Conceptually, transcendental functions on fixed point values aren't problematic, and are actually pretty widely used in certain gaming/simulation/signal processing applications. I've since learned that this may not be a good idea. A commenter (Scott Turner) on the haskell-cafe mailing list astutely raised the issue that because Data.Fixed uses the arbitrary-size Integer type, it's impossible to correctly compute these functions for all possible Fixed values without an arbitrary precision implementation, simply converting through Double like this won't always work. Sometimes it can be unclear where to draw the line and "stop worrying" about such issues. However, in this case I think it is a good objection, and that a better solution may be to work on advancing Data.Fixed.Binary or a similar library as a home for this functionality, where the size of the values is statically bounded. This has the advantage of also being outside the scope of the base libraries, and thus easier to modify due to the reduced impact. Unfortunately I learned this was probably unworthy of this list's attention after having already filed the trac ticket. Unless anyone disagrees and thinks this would be worthwhile, I will close that ticket tomorrow with a note saying where I'm redirecting the effort. -Doug McClean

2 1

[Announcement] FLTKHS - Bindings to the FLTK GUI Toolkit
by aditya siram 12 Apr '15

12 Apr '15

I'm pleased to announce the first release of Haskell bindings [1] to the FLTK GUI [2] toolkit. It now works smoothly on Windows (64-bit), Linux and Mac allowing you to create truly cross-platform native GUI applications in pure Haskell and deploy statically linked executables with no dependencies. Most of the FLTK API is covered except for a few minor widgets which I plan to get to in the next release. Motivation behind the package and installation instructions are found in the Haddocks [3]. And to get you started it ships with a number of demos. If you have any issues please report them on the Github [4] page. I'd also love any other feedback so feel free to comment here or email me at the address listed on the Hackage [5] page. Hope you enjoy! [1] https://hackage.haskell.org/package/fltkhs-0.1.0.2 [2] http://fltk.org [3] https://hackage.haskell.org/package/fltkhs-0.1.0.2/docs/Graphics-UI-FLTK-Lo… [4] http://github.com/deech/fltkhs [5] https://hackage.haskell.org/package/fltkhs-0.1.0.2

1 0