- Libraries - Haskell.org

Re: [Haskell-cafe] Class-like features for explicit arguments (was: Ord for partially ordered sets)
by Carter Schonwald 25 Apr '15

25 Apr '15

hrm, wouldn't your proposed extension be largely accomplished by using Record pun and Record WildCards? eg {-# LANGUAGE RecordWildCards #-} {-# LANGUAGE RecordPuns #-} module Foo where data Relation a = Rel{related :: a -> a ->Bool,unrelated :: a -> a -> Bool} foo :: Relation A -> A -> A -> Bool foo Rel{..} x y = related x y ------ or am i over looking something? I do realize this may not quite be what youre suggesting, and if so, could you help me understand better? :) On Fri, Apr 24, 2015 at 4:26 PM, Ertugrul Söylemez <ertesx(a)gmx.de> wrote: > > 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. > > Those are preorders. An antisymmetric preorder is a non-strict poset. > > Also it's difficult to capture all of those various order types in > Haskell's class system. A type can have many orders and many underlying > equivalence relations in the case of partial and total orders, and there > are different ways to combine them. For example equality is a partial > order, modular equivalence is a preorder, etc. Those denote bags and > groups more than sequences or trees. > > Perhaps it's time to add a type class-like system to Haskell, but for > explicitly passed arguments: > > record Relation a where > related :: a -> a -> Bool > > unrelated :: a -> a -> Bool > unrelated x y = not (related x y) > > func1 :: Relation A -> A -> A -> A > func1 _ x y = ... related x y ... > > func2 :: Relation A -> Relation A -> A -> A -> A > func2 r1 r2 x y = ... r1.related x y ... r2.unrelated x y ... > > In a lot of cases this is much more appropriate than a type class, and > it would turn many things that are currently types into regular > functions, thus making them a lot more composable: > > down :: Ord a -> Ord a > down o = > Ord { compare x y = o.compare y x } > -- The remaining Ord functions are defaulted. > > Perhaps all we need is to generalise default definitions to data types > and add module-like dot syntax for records (mainly to preserve infix > operators). Formally speaking there is also little that prevents us > From having associated types in those records that can be used on the > type level. > > For actual record types (i.e. single-constructor types) we could even > have specialisation and get a nice performance boost that way, if we ask > for it: > > {-# SPECIALISE down someOrder :: Ord SomeType #-} > > This would be extremely useful. > > > > 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. > > Zero and one as in minBound and maxBound or rather as in Monoid and a > hypothetical Semiring? In the latter case I believe they don't really > belong into an additional class, unless you have some ordering-related > laws for the zeroes and ones. If not, you can always simply use an > Ord+Semiring constraint. > > There may be some motivation to make Bounded a subclass of Ord though. > > > 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
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 15 Apr '15

15 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