__color__ __group__ ticket summary component version milestone type owner status created _changetime _description _reporter
3 Active Tickets 1 Make Data.Map total component1 enhancement somebody new 2009-10-08T22:05:20Z+0100 2009-10-08T22:05:20Z+0100 "`Data.Map k` is a `Functor` but not an `Applicative` or a `Monad` because it lacks `pure`/`return`.
If there were a `pure v`, the resulting map would have to map ''every'' key to `v`, to be consistent with the meaning of maps as functions.
(See ''[http://conal.net/papers/type-class-morphisms Denotational design with type class morphisms]''.)
However, such a map is not partial, and hence not finite.
To fix this algebraic awkardness, I suggest we simplify `Data.Map` to be ''total'' but still based on finitely many values.
The fix is very simple: give every map an explicit default value, by means of `pure`.
The `lookup` operation has a simpler type: `lookup :: Ord k => k -> Map k a -> a` (but let's ''please'' reverse the arguments, so that `lookup` is the semantic function).
Note the absence of `Maybe` in the result.
Both the current and suggested interface are trivially easy to implement in terms of the other.
Represent the partial `Map k v` as the total `Map k (Maybe v)`. (Really `First` in place of `Maybe`, as explained below.)
Represent the total as the partial map and a default value.
This new `Map` type can now be in `Functor`, `Applicative`, `Monad`, and `Monoid`.
Thanks to `Applicative`, it can also inhabit the numeric classes.
The semantics of all of these instances are directly determined by type class morphisms (TCMs), which says that methods on maps must behave consistently with the same methods on the meaning of maps.
In particular, the `Monoid` instance relies on `v` being a `Monoid` (by TCM, since the function/semantics monoid is defined that way).
For instance, `v` can be a `Maybe`, `First`, or `Last`, which all give different and useful ways to combine maps, rather than the one policy for `union` (which corresponds to the `First` monoid).
See Section 3 of ''[http://conal.net/papers/type-class-morphisms Denotational design with type class morphisms]'' for more details and context.
I have ''not'' gone through the whole `Data.Map` API to see the implications this proposal beyond what I've mentioned above." conal
3 Active Tickets 2 seq and pseq unsafety and ambiguities component1 enhancement somebody new 2009-10-21T17:22:28Z+0100 2009-12-04T16:26:19Z+0000 "base's seq and pseq functions break parametricity, which, among other things, is required for some optimizations like deforestation to work. Therefore, I propose that they be considered unsafe functions and that we adopt the unsafe naming conventions for them. Furthermore, since seq doesn't actually guarantee in what order its arguments are evaluated, its name should not resemble ""sequence."" Perhaps it could be renamed to something like unsafeForce. pseq, then, would be renamed to unsafeSeq." jmcarthur
3 Active Tickets 4 Add constraint synonyms and constraint synonym families to GHC component1 enhancement somebody new 2009-12-04T22:59:13Z+0000 2009-12-04T22:59:13Z+0000 "Many of our ideas rely on constraint synonym families. It would be really nice to have this feature available to us.
See the paper: http://tomschrijvers.blogspot.com/2009/11/haskell-type-constraints-unleashed.html
See the prototype preprocessor implementation: http://github.com/dorchard/constraintTermExtensions" jmcarthur
3 Active Tickets 5 GHC extension for higher rank types in constraints component1 enhancement somebody new 2010-03-05T19:28:57Z+0000 2010-03-05T19:31:38Z+0000 "I've been putting a little thought into how to combine an algebra with functors in the same way that Alternative lifts monoids into Applicatives and MonadPlus lifts monoids into Monads (with some extra laws). It occurred to me that the relationship between, say, Monoid, Applicative, and Alternative could be expressed like this:
{{{
constraint Alternative f = (Applicative f, forall a . Monoid (f a))
}}}
The above syntax is a combination of the proposed constraint families extension and this proposal. The ""forall"" portion is the one I'd like to focus on. I haven't put much thought into it yet, but perhaps this could open opportunities for generalization elsewhere." jmcarthur