- Haskell-Cafe - Haskell.org

Monads vs. qualified types
by William Lee Irwin III 15 Dec '04

15 Dec '04

To my chagrin, I discovered that the following code was not accepted while attempting to monadify a small interpreter for a language used for calculations in permutation representations of groups. One of the critical notions here is of closure under composition, e.g. a transcript of a command to generate a set via distinguished elements is: 20> <(1 2),(1 2 3)> {(), (1 2), (1 2 3), (1 3), (1 3 2), (2 3)} and augmenting the semantics with group-theoretic joins and intersections and the like look verbose and redundant, with monadic properties to exploit for brevity readily apparent. \begin{code} data Eq t => Set t = Set [t] deriving (Ord, Read, Show) instance Eq t => Eq (Set t) where (Set xs) == (Set ys) = all (`elem` ys) xs && all (`elem` xs) ys instance Functor Set where fmap f (Set xs) = Set . nub $ map f xs instance Monad Set where return = Set . (:[]) (Set xs) >>= f = Set $ foldr union [] [ys | Set ys <- map f xs] \end{code} This, of course, presents me immediately with some nightmare where transitive closure semantics and the like are unimplementable as direct data structure properties within any monad, as constraints on the argument types of the monadic constructor are (for the moment) verboten. Is anyone looking into dealing with this so that I can do this? If not, where (which files) do I hack it into ghc? Are there already patches? -- wli

1 0

The difference between ($) and application
by Derek Elkins 15 Dec '04

15 Dec '04

> On Mon, Dec 13, 2004 at 07:49:00PM -0800, oleg at pobox.com wrote: > > The operator ($) is often considered an application operator of a > > lower precedence. Modulo precedence, there seem to be no difference > > between ($) and `the white space', and so one can quickly get used > > to treat these operators as being semantically the same. However, > > they are not the same in all circumstances. I'd like to observe an > > important case where replacing the application with ($) in a > > fully-parenthesized expression can lead to a type error. > > I think this post should go under the heading "($) considered > harmful". I've been bitten by this, and I never use ($) anymore in > place of parentheses because it's too tempting to think of it as > syntax. (Of course, it's still useful, by itself or in a slice, as a > higher-order operator.) > > Andrew I find this position ridiculous. I don't recall anyone ever posting a message about this (though I'd be far from surprised if someone did). It seems that the people who decide they need higher-rank types are capable of handling type errors involving them, and they certainly don't confuse ($) for syntax. Unless there's a realistic scenario where one suddenly decides one needs some higher-rank types and has to remove a bunch of uses of ($) but otherwise make no changes, I don't see any reason not to use ($) when you can (if you like) and not when you can't. If you ever make a mistake one way the type checker will tell you.

3 2

Re: [Haskell-cafe] local loops
by Jon Cast 15 Dec '04

15 Dec '04

Per Larsson <per(a)L4i.se> wrote: > I often use local loops in monadic code, e.g. > > main = do > ... > let loop = do > ... > if cond then loop else return () > loop > > It seems that I can encode this idiom slightly more concise with the 'fix' > operator (from Control.Monad.Fix), i.e. > > main = do > ... > fix (\loop -> do > ... > if ...) > > But is it really semantically equivalent? Is it as efficient? > > Per It is semantically equivalent. I don't know if it is as efficient; looking at the source code, I would expect GHC to inline fix anywhere it occurs, which yields your original version. Jonathan Cast

1 0

The difference between ($) and application
by Derek Elkins 15 Dec '04

15 Dec '04

> Derek Elkins wrote: > >Andrew Pimlott wrote: > >>I think this post should go under the heading "($) considered > >>harmful". I've been bitten by this, and I never use ($) anymore in > >>place of parentheses because it's too tempting to think of it as > >>syntax. > > > >I find this position ridiculous. [...] If you ever make a mistake > >one way the type checker will tell you. > > For what it's worth, this is not true in the presence of implicit > parameters: > > f :: ((?p :: Int) => Int) -> Int > f g = let ?p = 1 in g > > x,y :: Int > x = let ?p = 2 in (f ?p) ==> 1 > y = let ?p = 2 in (f $ ?p) ==> 2 > > I wouldn't mind ($) being magical, along the lines of the magical > runST in a rank-1 type system. It would be nice to be able to use it > in patterns too. > > -- Ben Moral of the story, and if I'm not mistaken, in your opinion, is not to use implicit parameters (as currently formulated). I.e. the consensus seems to be that this is implicit parameters' fault not ($)'s. Personally, I would mind ($) being magical. One of the nice things about Haskell is there is practically no magic. The last thing I want is Haskerl (http://www.dcs.gla.ac.uk/~partain/haskerl.html) runST simply had a rank-2 type that is not expressible in Haskell 98, it seems getting ($) to "work" would be qualitatively different.

1 0

Sound library?
by Jason Bailey 15 Dec '04

15 Dec '04

Would anyone know of packages out there for Haskell that support mp3's or ogg files? thanks Jason

6 9

special term describing f :: (Monad m) => (a -> m b)?
by Derek Elkins 15 Dec '04

15 Dec '04

> What is a function of the followning type called: > > f :: (Monad m) => (a -> m b) > > Is there a special term describing such a function (a function into a > monad)? > > For f in > a >>= f > is en example. > > Need it for an article/report. > > Regards/Henning Well, formally, it's called a Kleisli arrow (or morphism). A less formal term commonly used for values of type a -> m b and m b, is 'computation' or'action' (though 'action' is usually used for the specific case of IO). In "Notions of Computation and Monads" Moggi calls them 'commands'.

1 0

Named function fields vs. type classes
by Derek Elkins 15 Dec '04

15 Dec '04

> > On the other hand, it's difficult or impossible to make a list of a > > bunch of different types of things that have nothing in common save > > being members of the class. > > I've recently been playing with making, for each class C, a > "interface" datatype IC (appropriately universally and existentially > qualified so as to include a dictionary for class C), and then making > this IC an instance of class C. Then I can wrap any instance of C up > in an IC, and make a list of those. > > The casts get a bit annoying, though; the compiler can't figure out > that this IC is in some sense the maximum type in class C, and so > can't resolve things like > > f :: MyClass a => [a] -> b > f = ... > > upcast :: MyClass a => a -> IMyClass -- usually defined as an > instance of class Cast upcast x = IMyClass x > > f [upcast a, upcast b] -- yields type error > > Instead, you have to redefine f as follows: > > f' :: [IMyClass] -> b > > which is a bit annoying. > > HTH. > > --KW 8-) Not surprisingly, the wiki (http://www.haskell.org/hawiki/ExistentialTypes) has some discussion about this as well, though not too much to add to what has been said.

1 0

The difference between ($) and application
by oleg＠pobox.com 15 Dec '04

15 Dec '04

The operator ($) is often considered an application operator of a lower precedence. Modulo precedence, there seem to be no difference between ($) and `the white space', and so one can quickly get used to treat these operators as being semantically the same. However, they are not the same in all circumstances. I'd like to observe an important case where replacing the application with ($) in a fully-parenthesized expression can lead to a type error. > {-# OPTIONS -fglasgow-exts #-} > > module Foo where > > data WR = WR (Int -> Int) > data W = W (forall a. a->a) > > t1 = WR id > t2 = W id We can also write > t1' = WR $ id However, if we try > t2' = W $ id we get an error: /tmp/t1.hs:13: Inferred type is less polymorphic than expected Quantified type variable `a' escapes Expected type: (a -> a) -> b Inferred type: (forall a1. a1 -> a1) -> W In the first argument of `($)', namely `W' In the definition of `t2'': t2' = W $ id Incidentally, Hugs -98 gives a quite bizarre error message ERROR "/tmp/t1.hs":13 - Use of W requires at least 1 argument It didn't complain about "WR $ id"... The reasons for that behavior are obvious: the compiler cannot generalize to higher-ranked types when instantiating the type of ($). It makes a difference that the application is a built-in construction, whereas ($) is just a regular function.

6 6

special term describing f :: (Monad m) => (a -> m b) ?
by Henning Sato von Rosen 15 Dec '04

15 Dec '04

What is a function of the followning type called: f :: (Monad m) => (a -> m b) Is there a special term describing such a function (a function into a monad)? For f in a >>= f is en example. Need it for an article/report. Regards/Henning

3 3

local loops
by Per Larsson 15 Dec '04

15 Dec '04

I often use local loops in monadic code, e.g. main = do ... let loop = do ... if cond then loop else return () loop It seems that I can encode this idiom slightly more concise with the 'fix' operator (from Control.Monad.Fix), i.e. main = do ... fix (\loop -> do ... if ...) But is it really semantically equivalent? Is it as efficient? Per

1 0