alt-stdlib:
http://trac.haskell.org/alt-stdlib/report/3
Trac Report - en-usalt-stdlibhttp://trac.haskell.org/alt-stdlib/chrome/common/trac_banner.png
http://trac.haskell.org/alt-stdlib/report/3
Trac v0.11.1#4: Add constraint synonyms and constraint synonym families to GHCFri, 04 Dec 2009 22:59:13 GMTFri, 04 Dec 2009 22:59:13 GMT<p>
Many of our ideas rely on constraint synonym families. It would be really nice to have this feature available to us.
</p>
<p>
See the paper: <a class="ext-link" href="http://tomschrijvers.blogspot.com/2009/11/haskell-type-constraints-unleashed.html"><span class="icon">http://tomschrijvers.blogspot.com/2009/11/haskell-type-constraints-unleashed.html</span></a>
</p>
<p>
See the prototype preprocessor implementation: <a class="ext-link" href="http://github.com/dorchard/constraintTermExtensions"><span class="icon">http://github.com/dorchard/constraintTermExtensions</span></a>
</p>
http://trac.haskell.org/alt-stdlib/ticket/4
http://trac.haskell.org/alt-stdlib/ticket/4Report#5: GHC extension for higher rank types in constraintsFri, 05 Mar 2010 19:28:57 GMTFri, 05 Mar 2010 19:31:38 GMT<p>
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 <a class="missing wiki" href="http://trac.haskell.org/alt-stdlib/wiki/MonadPlus" rel="nofollow">MonadPlus?</a> 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:
</p>
<pre class="wiki">constraint Alternative f = (Applicative f, forall a . Monoid (f a))
</pre><p>
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.
</p>
http://trac.haskell.org/alt-stdlib/ticket/5
http://trac.haskell.org/alt-stdlib/ticket/5Report#1: Make Data.Map totalThu, 08 Oct 2009 21:05:20 GMTThu, 08 Oct 2009 21:05:20 GMT<p>
<tt>Data.Map k</tt> is a <tt>Functor</tt> but not an <tt>Applicative</tt> or a <tt>Monad</tt> because it lacks <tt>pure</tt>/<tt>return</tt>.
If there were a <tt>pure v</tt>, the resulting map would have to map <i>every</i> key to <tt>v</tt>, to be consistent with the meaning of maps as functions.
(See <i><a class="ext-link" href="http://conal.net/papers/type-class-morphisms"><span class="icon">Denotational design with type class morphisms</span></a></i>.)
However, such a map is not partial, and hence not finite.
</p>
<p>
To fix this algebraic awkardness, I suggest we simplify <tt>Data.Map</tt> to be <i>total</i> but still based on finitely many values.
The fix is very simple: give every map an explicit default value, by means of <tt>pure</tt>.
The <tt>lookup</tt> operation has a simpler type: <tt>lookup :: Ord k => k -> Map k a -> a</tt> (but let's <i>please</i> reverse the arguments, so that <tt>lookup</tt> is the semantic function).
Note the absence of <tt>Maybe</tt> in the result.
</p>
<p>
Both the current and suggested interface are trivially easy to implement in terms of the other.
Represent the partial <tt>Map k v</tt> as the total <tt>Map k (Maybe v)</tt>. (Really <tt>First</tt> in place of <tt>Maybe</tt>, as explained below.)
Represent the total as the partial map and a default value.
</p>
<p>
This new <tt>Map</tt> type can now be in <tt>Functor</tt>, <tt>Applicative</tt>, <tt>Monad</tt>, and <tt>Monoid</tt>.
Thanks to <tt>Applicative</tt>, 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 <tt>Monoid</tt> instance relies on <tt>v</tt> being a <tt>Monoid</tt> (by TCM, since the function/semantics monoid is defined that way).
For instance, <tt>v</tt> can be a <tt>Maybe</tt>, <tt>First</tt>, or <tt>Last</tt>, which all give different and useful ways to combine maps, rather than the one policy for <tt>union</tt> (which corresponds to the <tt>First</tt> monoid).
</p>
<p>
See Section 3 of <i><a class="ext-link" href="http://conal.net/papers/type-class-morphisms"><span class="icon">Denotational design with type class morphisms</span></a></i> for more details and context.
</p>
<p>
I have <i>not</i> gone through the whole <tt>Data.Map</tt> API to see the implications this proposal beyond what I've mentioned above.
</p>
http://trac.haskell.org/alt-stdlib/ticket/1
http://trac.haskell.org/alt-stdlib/ticket/1Report#2: seq and pseq unsafety and ambiguitiesWed, 21 Oct 2009 16:22:28 GMTFri, 04 Dec 2009 16:26:19 GMT<p>
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.
</p>
http://trac.haskell.org/alt-stdlib/ticket/2
http://trac.haskell.org/alt-stdlib/ticket/2Report