November 2006
Monthly Archive
Thu 9 Nov 2006
Posted by Edward Kmett under
Haskell ,
Monads [7] Comments
If we take a look at the Haskell (.) operator:
(.) :: (a -> b) -> (e -> a) -> e -> b
and take a moment to reflect on the type of fmap
fmap :: Functor f => (a -> b) -> f a -> f b
and the unnamed Reader monad from Control.Monad.Reader
instance Functor ((->) r)
we see that fmap applied to the Reader functor rederives (.).
(more...)
Thu 9 Nov 2006
Posted by Edward Kmett under
Logic No Comments
A number of us from the freenode #haskell channel have gone and formed/revived ##logic to avoid overwhelming the main Haskell channel with traffic. Originally, I just wanted to revive the #logic channel that was already there, but upon talking to the freenode staff, it appears that they have channel naming guidelines that preclude topical discussion channels getting single # names without some sort of clear trademark. They were however nice enough to forward the previous #logic channel to the new location.
In any event, if you are interested in logic at pretty much any level, feel free to stop by the channel.
Wed 1 Nov 2006
Posted by Edward Kmett under
Type Theory No Comments
Was reading Castagna, Ghelli, and Longo's 1995 paper on "A Calculus for Overloaded Functions with Subtyping" today and in it they have to jump through some hoops to index their '&' types to keep them well behaved under β-reduction.
It seems to me, at least from my back-of-the-envelope scribblings, that if you CPS transform the calculus before, that the main technical innovation (overloaded functions using the tighter run-time type information) remains intact, but the need for this technical trick goes away. In this case you know what the reduction will evaluate out to regardless of call-by-value or call-by-need (just bottom), and if the specification changes during evaluation it is still sound, so no need for an index.
The above then would requires explicit continuations and might interfere with rederiving tupling from the overloading mechanism alone, but seems to eliminate some of the barriers they mention to the higher order case. However, I'm not convinced it is a net win regardless, because it would require a notion of typecase.