__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