- Libraries - Haskell.org

Re: [Haskell-cafe] Class-like features for explicit arguments
by Roman Cheplyaka 25 Apr '15

25 Apr '15

On 25/04/15 15:51, Ertugrul Söylemez wrote: >> hrm, wouldn't your proposed extension be largely accomplished by using >> Record pun and Record WildCards? > > A part of it would, but it wouldn't preserve operators. For example > instead of `x r.<> y` you would have to write `(<>) r x y`. Not at all. {-# LANGUAGE RecordWildCards #-} import Prelude hiding (sum) data Monoid a = Monoid { empty :: a, (<>) :: a -> a -> a } sum :: Num a => Monoid a sum = Monoid 0 (+) three :: Integer three = let Monoid{..} = sum in 1 <> 2 > Other class features are not accessible, > most notably type-level features like associated types. Associated types become additional type variables of the record type. A class class C a where type T a is essentially equivalent to class C a t | a -> t But the functional dependency is not enforceable on the value level (isn't the whole point of this discussion not to restrict what "instances" can be defined), so you end up with class C a t, a simple MPTC. > Also defaults are not available. Now this is a good point. > The idea is that a record would be completely equivalent to a class with > the only difference being that you define values instead of instances, > that there are no constraints on which values can exist and that those > values must be passed explicitly to functions as regular arguments. Except we already have regular records (aka data types) which satisfy 90% of the requirements, and adding another language construct to satisfy those remaining 10% feels wrong to me. I'd rather improve the existing construct. Roman

1 0

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

24 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