- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Making monadic code more concise
by Alberto G. Corona 15 Nov '10

15 Nov '10

I like your autolifting stuff, and the runnable concept. > 2010/11/15 Ling Yang <lyang(a)cs.stanford.edu> > > See my reply to Alex's post for my perspective on how this relates to >> applicative functors, reproduced here: >> >> >> This, to me, is a big hint that applicative functors could be useful. >> > >> >Indeed, the ideas here also apply to applicative functors; it is just the >> lifting primitives that will be different; instead of having liftM<N>, we >> can use <$> and <*> to lift the functions. We could have done this for Num >> and Maybe (suppose Maybe is an instance of Applicative): >> > >> >instance (Num a) => Num (Maybe a) where >> > (+) = \x y -> (+) <$> x <*> y >> > (-) = \x y -> (-) <$> x <*> y >> > (*) = \x y -> (+) <$> x <*> y >> > abs = abs <$> >> > signum = signum <$> >> > fromInteger = pure . fromInteger >> > >> >The larger goal remains the same: autolifting in a principled manner. >> > >> >However, you actually bring up a very good point; what if it is really >> only the applicative functors that this method works on in general, that >> there is no 'use case' for considering this autolifting for monads in >> particular? >> >I think the answer lies in the fact that monads can be 'flattened;' that >> is, realizations of the type m (m a) -> m a are mechanical (in the form of >> 'join') given that >>= is defined. This is important when we have a >> typeclass that also has monadic signatures. To be more concrete, consider >> how this function could be used in a 'monadic DSL': >> > >> >enter x = case x of >> > 0 -> Nothing >> > _ -> Just "hi" >> > >> >The type of 'enter' is one case of the general from 'a -> M b'. If we >> were instancing a typeclass that had an 'a -> M b' function, we'd need a >> function of type 'M a -> M b'. This would be accomplished by >> > >> >enter' = join . liftM enter >> > >> >So the set of lifting primitives must include at least some way to get M >> a -> M b from 'a -> M b'---which requires that M is a monad, not just an >> applicative functor. >> > >> >Thanks for the mention of applicative functors; I should have included >> them in the original post. >> > >> >Lingfeng Yang >> >lyang at cs dot stanford dot edu >> > >> >> I should have included a mention of Applicative in my original post. >> >> > Part of the reason Num was so easy is that all the functions produce >> > values whose type is the class parameter. Your Num instance could >> > almost be completely generic for any ((Applicative f, Num a) => f a), >> > except that Num demands instances of Eq and Show, neither of which can >> > be blindly lifted the way the numeric operations can. >> >> > I imagine it should be fairly obvious why you can't write a >> > non-trivial generic instance (Show a) => Show (M a) that would work >> > for any possible monad M--you'd need a function (show :: M a -> >> > String) which is impossible for abstract types like IO, as well as >> > function types like the State monad. The same applies to (==), of >> > course. Trivial instances are always possible, e.g. show _ = "[not >> > showable]", but then you don't get sensible behavior when a >> > non-trivial instance does exist, such as for Maybe or []. >> >> Good point. This is where we can start defining restrictions for when >> this automatic lifting can or cannot take place. I reference the >> concept of 'runnable monads' here, from >> >> "[Erwig and Ren 2004] Monadification of Functional Programs" >> >> A 'runnable monad' is a monad with an exit function: >> >> class (Monad m) => Runnable m where >> exit : m a -> a >> >> And yes, for monads like IO, no one would really have a need for >> 'exit' outside of the cases where they need unsafePerformIO. However, >> for Maybe and Prob, 'exit' is extremely useful. In fact, in the >> probability monad, if you could not exit the monad, you could not get >> anything done, as the real use is around sampling and computing >> probabilities, which are of non-monadic types. >> >> Provided M is a runnable monad, >> >> class (Show a) => Show (M a) where >> show = show . exit >> >> I'm aware of the limitations of this approach; I just want to come up >> with a set of primitives that characterize the cases where >> autolifting/monadic instancing is useful. >> >> >> On Mon, Nov 15, 2010 at 11:19 AM, C. McCann <cam(a)uptoisomorphism.net> >> wrote: >> > On Mon, Nov 15, 2010 at 12:43 PM, Ling Yang <lyang(a)cs.stanford.edu> >> wrote: >> >> Specifically: There are some DSLs that can be largely expressed as >> monads, >> >> that inherently play nicely with expressions on non-monadic values. >> >> We'd like to use the functions that already work on the non-monadic >> >> values for monadic values without calls to liftM all over the place. >> > >> > It's worth noting that using liftM is possibly the worst possible way >> > to do this, aesthetically speaking. To start with, liftM is just fmap >> > with a gratuitous Monad constraint added on top. Any instance of Monad >> > can (and should) also be an instance of Functor, and if the instances >> > aren't buggy, then liftM f = (>>= return . f) = fmap f. >> > >> > Additionally, in many cases readability is improved by using (<$>), an >> > operator synonym for fmap, found in Control.Applicative, I believe. >> > >> >> The probability monad is a good example. >> >> >> > [snip] >> >> I'm interested in shortening the description of 'test', as it is >> >> really just a 'formal addition' of random variables. One can use liftM >> >> for that: >> >> >> >> test = liftM2 (+) (coin 0.5) (coin 0.5) >> > >> > Also on the subject of Control.Applicative, note that independent >> > probabilities like this don't actually require a monad, merely the >> > ability to lift currying into the underlying functor, which is what >> > Applicative provides. The operator ((<*>) :: f (a -> b) -> f a -> f b) >> > is convenient for writing such expressions, e.g.: >> > >> > test = (+) <$> coin 0.5 <*> coin 0.5 >> > >> > Monads are only required for lifting control flow into the functor, >> > which in this case amounts to conditional probability. You would not, >> > for example, be able to easily use simple lifted functions to write >> > "roll a 6-sided die, flip a coin as many times as the die shows, then >> > count how many flips were heads". >> > >> >> I think a good question as a starting point is whether it's possible >> >> to do this 'monadic instance transformation' for any typeclass, and >> >> whether or not we were lucky to have been able to instance Num so >> >> easily (as Num, Fractional can just be seen as algebras over some base >> >> type plus a coercion function, making them unusually easy to lift if >> >> most typeclasses actually don't fit this description). >> > >> > Part of the reason Num was so easy is that all the functions produce >> > values whose type is the class parameter. Your Num instance could >> > almost be completely generic for any ((Applicative f, Num a) => f a), >> > except that Num demands instances of Eq and Show, neither of which can >> > be blindly lifted the way the numeric operations can. >> > >> > I imagine it should be fairly obvious why you can't write a >> > non-trivial generic instance (Show a) => Show (M a) that would work >> > for any possible monad M--you'd need a function (show :: M a -> >> > String) which is impossible for abstract types like IO, as well as >> > function types like the State monad. The same applies to (==), of >> > course. Trivial instances are always possible, e.g. show _ = "[not >> > showable]", but then you don't get sensible behavior when a >> > non-trivial instance does exist, such as for Maybe or []. >> > >> >> Note that if we consider this in a 'monadification' context, where we >> >> are making some choice for each lifted function, treating it as >> >> entering, exiting, or computing in the monad, instancing the typeclass >> >> leads to very few choices for each: the monadic versions of +, -, * >> >> must be obtained with "liftM2",the monadic versions of negate, abs, >> >> signum must be obtained with "liftM", and the monadic version of >> >> fromInteger must be obtained with "return . " >> > >> > Again, this is pretty much the motivation and purpose of >> > Control.Applicative. Depending on how you want to look at it, the >> > underlying concept is either lifting multi-argument functions into the >> > functor step by step, or lifting tuples into the functor, e.g. (f a, f >> > b) -> f (a, b); the equivalence is recovered using fmap with either >> > (curry id) or (uncurry id). >> > >> > Note that things do get more complicated if you have to deal with the >> > full monadic structure, but since you're lifting functions that have >> > no knowledge of the functor whatsoever they pretty much have to be >> > independent of it. >> > >> >> I suppose I'm basically suggesting that the 'next step' is to somehow >> >> do this calculation of types on real type values, and use an inductive >> >> programming tool like Djinn to realize the type signatures. I think >> >> the general programming technique this is getting at is an orthogonal >> >> version of LISP style where one goes back and forth between types and >> >> functions, rather than data and code. I would also appreciate any >> >> pointers to works in that area. >> > >> > Well, I don't think there's any good way to do this in Haskell >> > directly, in general. There's a GHC extension that can automatically >> > derive Functor for many types, but nothing to automatically derive >> > Applicative as far as I know (other than in trivial cases with newtype >> > deriving)--I suspect due to Applicative instances being far less often >> > uniquely determined than for Functor. And while a fully generic >> > instance can be written and used for any Applicative and Num, the >> > impossibility of sensible instances for Show and Eq, combined with the >> > context-blind nature of Haskell's instance resolution, means that it >> > can't be written directly in full generality. It would, however, be >> > fairly trivial to manufacture instance declarations for specific types >> > using some sort of preprocessor, assuming Show/Eq instances have been >> > written manually or by creating trivial ones. >> > >> > Anyway, you may want to read the paper that introduced Applicative, >> > since that seems to describe the subset of generic lifted functions >> > you're after: http://www.soi.city.ac.uk/~ross/papers/Applicative.html >> > >> > If for some reason you'd rather continue listening to me talk about >> > it, I wrote an extended ode to Applicative on Stack Overflow some time >> > back that was apparently well-received: >> > >> http://stackoverflow.com/questions/3242361/haskell-how-is-pronounced/324285… >> > >> > - C. >> > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >

1 0

Making monadic code more concise
by Ling Yang 15 Nov '10

15 Nov '10

Hi, I'm fairly new to Haskell and recently came across some programming tricks for reducing monadic overhead, and am wondering what higher-level concepts they map to. It would be great to get some pointers to related work. Background: I'm a graduate student whose research interests include methods for implementing domain specific languages. Recently, I have been trying to get more familiar with Haskell and implementing DSLs in it. I'm coming from having a fair bit of experience in Python so I know the basics of functional programming. However, I'm much less familiar with Haskell. In particular I have little to no internal map from existing DSL implementation techniques to the Haskell extensions that would no doubt make DSL implementations easier (and when they are *not* needed). I also don't have a complete picture of the functional programming research that would inform these techniques. I would greatly appreciate it if I could get pointers to the appropriate references so I can really get going on this. Specifically: There are some DSLs that can be largely expressed as monads, that inherently play nicely with expressions on non-monadic values. We'd like to use the functions that already work on the non-monadic values for monadic values without calls to liftM all over the place. The probability monad is a good example. import Control.Monad import Data.List newtype Prob a = Prob { getDist :: [(a, Float)] } deriving (Eq, Show) multiply :: Prob (Prob a) -> Prob a multiply (Prob xs) = Prob $ concat $ map multAll xs where multAll (Prob innerxs, p) = map (\(x, r) -> (x, p * r)) innerxs instance Functor Prob where fmap f (Prob xs) = Prob $ map (\(x, p) -> (f x, p)) xs instance Monad Prob where return x = Prob [(x, 1.0)] x >>= f = multiply (fmap f x) In this monad, >>= hides the multiplying-out of conditional probabilities that happen during the composition of a random variable with a conditional distribution. coin x = Prob [(1, x), (0, 1 - x)] test = do x <- (coin 0.5) y <- (coin 0.5) return $ x + y *Main> test Prob {getDist = [(2,0.25),(1,0.25),(1,0.25),(0,0.25)]} We can use a 'sum out' function to get more useful results: sumOut :: (Ord a) => Prob a -> Prob a sumOut (Prob xs) = Prob $ map (\kvs -> foldr1 sumTwoPoints kvs) eqValues where eqValues = groupBy (\x y -> (fst x == fst y)) $ sortBy compare xs sumTwoPoints (v1, p1) (v2, p2) = (v1, p1 + p2) *Main> sumOut test Prob {getDist = [(0,0.25),(1,0.5),(2,0.25)]} I'm interested in shortening the description of 'test', as it is really just a 'formal addition' of random variables. One can use liftM for that: test = liftM2 (+) (coin 0.5) (coin 0.5) It seems what I'm leading into here is making functions on ordinary values polymorphic over their monadic versions; I think this is the desire for 'autolifting' or 'monadification' that has been mentioned in works such as HaRE http://www.haskell.org/pipermail/haskell/2005-March/015557.html One alternate way of doing this, however, is instancing the typeclasses of the ordinary values with their monadic versions: instance (Num a) => Num (Prob a) where (+) = liftM2 (+) (*) = liftM2 (*) abs = liftM abs signum = liftM signum fromInteger = return . fromInteger instance (Fractional a) => Fractional (Prob a) where fromRational = return . fromRational (/) = liftM2 (/) Note that already, even though each function in the typeclass had to be manually lifted, this eliminates more overhead compared to lifting every function used, because any function with a general enough type bound can work with both monadic and non-monadic values, not just the ones in the typeclass: *Main> sumOut $ (coin 0.5) + (coin 0.5) + (coin 0.5) Prob {getDist = [(0,0.125),(1,0.375),(2,0.375),(3,0.125)]} *Main> let foo x y z = (x + y) * z *Main> sumOut $ foo (coin 0.5) (coin 0.5) (coin 0.5) Prob {getDist = [(0,0.625),(1,0.25),(2,0.125)]} Because of the implementation of fromInteger as return . fromInteger, we also 'luck out' and have the ability to mix ordinary and non-monadic values in the same expression: *Main> 1 + coin 0.5 / 2 Prob {getDist = [(1.5,0.5),(1.0,0.5)]} My question is, what are the higher-level concepts at play here? The motivation is that it should be possible to automatically do this typeclass instancing, letting us get the benefits of concise monadic expressions without manually instancing the typeclasses. Indeed, I didn't have this idea in Haskell; I'm coming from Python where one can realize the automatic instances: if we take the view that classes in Python are combined datatypes and instanced typeclasses, we can use the meta-object protocol to look inside one class's representation and output another class with liftM-ed (or return . -ed) methods and a custom constructor. I realize Template Haskell gives you the ability to reify instance/class declarations, but perhaps there's a less heavyweight way (or there should be). I think a good question as a starting point is whether it's possible to do this 'monadic instance transformation' for any typeclass, and whether or not we were lucky to have been able to instance Num so easily (as Num, Fractional can just be seen as algebras over some base type plus a coercion function, making them unusually easy to lift if most typeclasses actually don't fit this description). In general, what this seems to be is a transformation on functions that also depends explicitly on type signatures. For example in Num: class (Eq a, Show a) => Num a where (+), (-), (*) :: a -> a -> a negate, abs, signum :: a -> a fromInteger :: Integer -> a instance (Num a) => Num (Prob a) where (+) = liftM2 (+) -- Prob a -> Prob a -> Prob a (*) = liftM2 (*) -- Prob a -> Prob a -> Prob a abs = liftM abs -- Prob a -> Prob a signum = liftM signum -- Prob a -> Prob a fromInteger = return . fromInteger -- Integer -> Prob a Note that if we consider this in a 'monadification' context, where we are making some choice for each lifted function, treating it as entering, exiting, or computing in the monad, instancing the typeclass leads to very few choices for each: the monadic versions of +, -, * must be obtained with "liftM2",the monadic versions of negate, abs, signum must be obtained with "liftM", and the monadic version of fromInteger must be obtained with "return . " I think this is what we're doing in general: if we had a typeclass C with a type variable a, with some set of type signatures in which 'a' appears bound, we can do "instance C (M a)" for some monad M if there is some way to realize the resulting set of type signatures where every bound occurence of 'a' is replaced with 'M a'. The following script illustrates precisely what I mean by this: data Typ = Gr String -- Irreducible grounded type, like Int or Bool | Con String Typ -- Type constructor applied to a type of kind *, i.e., IO String, Maybe (Prob Int) | Arr Typ Typ -- Function T1 -> T2 | Tup (Typ, Typ) -- Tuple (T1, T2) deriving Eq instance Show Typ where show (Gr a) = a show (Con m a) = "(" ++ m ++ " " ++ show a ++ ")" show (Arr a b) = "(" ++ show a ++ " -> " ++ show b ++ ")" show (Tup (x, y)) = "(" ++ show x ++ ", " ++ show y ++ ")" --let a = b in expr for our type signature calculus typlet :: Typ -> Typ -> Typ -> Typ typlet a b expr = case a == expr of False -> typletdown a b expr True -> b typletdown a b (Tup (x, y)) = Tup (typlet a b x, typlet a b y) typletdown a b (Arr x y) = Arr (typlet a b x) (typlet a b y) typletdown a b (Con str c) = Con str (typlet a b c) typletdown a b (Gr s) = Gr s monadify a b expr = typlet a (Con b a) expr -- class declaration : the free type variable, with a list of signatures type ClassDecl = (Typ, [Typ]) -- monadify class signatures monadic_sigs :: ClassDecl -> String -> ClassDecl monadic_sigs (btyp, sigs) it = (Con it btyp, map (\sig -> monadify btyp it sig) sigs) -- Num mkNum = (Gr "a", [ (Gr "a") `Arr` ((Gr "a") `Arr` (Gr "a")), -- (+), (-), (*) (Gr "a") `Arr` (Gr "a"), -- abs, signum, negate (Gr "Integer") `Arr` (Gr "a")]) -- fromInteger main = do let testexpr =(Gr "a") `Arr` ((Gr "a") `Arr` (Gr "a")) print "Sample type signature:" print testexpr print "Monadified:" print $ monadify (Gr "a") "Prob" testexpr print $ "Num typeclass signatures:" print $ mkNum print "Signatures of the functions needed for instance (Num a) => Num (Prob a):" print $ monadic_sigs mkNum "Prob" I suppose I'm basically suggesting that the 'next step' is to somehow do this calculation of types on real type values, and use an inductive programming tool like Djinn to realize the type signatures. I think the general programming technique this is getting at is an orthogonal version of LISP style where one goes back and forth between types and functions, rather than data and code. I would also appreciate any pointers to works in that area. Thanks for any leads, Lingfeng Yang lyang at cs dot stanford dot edu

4 4

Concurrent with monads
by Jiansen He 15 Nov '10

15 Nov '10

Hi cafe, I wounder if it is possible to tell a haskell system that two computations with side effects could be executed concurrently. Here is an affected example: Suppose two people want to compare their age, but do not want to leak their personal information. The following program reads one person's age after another then send back compared result. age :: IO () age = do i <- readIntFrom a j <- readIntFrom b writeTo a (i-j) writeTo b (j-i) How can I express the fact that two readings could be carried out in any order? Best Regards Jiansen

2 1

Hood on Hackage is an interesting way to see intermediate data structures.
by caseyh＠istar.ca 15 Nov '10

15 Nov '10

Hood on Hackage is an interesting way to see intermediate data structures. {-# LANGUAGE NoMonomorphismRestriction #-} -- Fold Behaviour Observed module Folding where -- See Hood on Hackage import Observe import Data.List n = 10::Int fr = foldr (observe "Add" (+)) 0 [1..n] fl = foldl (observe "Add" (+)) 0 [1..n] frr = foldr (observe "Add" (+)) 0 (reverse [1..n]) flr = foldl (observe "Add" (+)) 0 (reverse [1..n]) fro = printO fr flo = printO fl frro = printO frr flro = printO flr fl' = foldl' (observe "Add" (+)) 0 [1..n] flr' = foldl' (observe "Add" (+)) 0 (reverse [1..n]) flo' = printO fl' flro' = printO flr'

1 0

Making monadic code more concise
by lyang 15 Nov '10

15 Nov '10

> This, to me, is a big hint that applicative functors could be useful. Indeed, the ideas here also apply to applicative functors; it is just the lifting primitives that will be different; instead of having liftM<N>, we can use <$> and <*> to lift the functions. We could have done this for Num and Maybe (suppose Maybe is an instance of Applicative): instance (Num a) => Num (Maybe a) where (+) = \x y -> (+) <$> x <*> y (-) = \x y -> (-) <$> x <*> y (*) = \x y -> (+) <$> x <*> y abs = abs <$> signum = signum <$> fromInteger = pure . fromInteger The larger goal remains the same: autolifting in a principled manner. However, you actually bring up a very good point; what if it is really only the applicative functors that this method works on in general, that there is no 'use case' for considering this autolifting for monads in particular? I think the answer lies in the fact that monads can be 'flattened;' that is, realizations of the type m (m a) -> m a are mechanical (in the form of 'join') given that >>= is defined. This is important when we have a typeclass that also has monadic signatures. To be more concrete, consider how this function could be used in a 'monadic DSL': enter x = case x of 0 -> Nothing _ -> Just "hi" The type of 'enter' is one case of the general from 'a -> M b'. If we were instancing a typeclass that had an 'a -> M b' function, we'd need a function of type 'M a -> M b'. This would be accomplished by enter' = join . liftM enter So the set of lifting primitives must include at least some way to get M a -> M b from 'a -> M b'---which requires that M is a monad, not just an applicative functor. Thanks for the mention of applicative functors; I should have included them in the original post. Lingfeng Yang lyang at cs dot stanford dot edu

1 0

Announcement: the Haskell.org committee has formed
by Don Stewart 15 Nov '10

15 Nov '10

= The haskell.org committee has formed = http://haskellorg.wordpress.com/2010/11/15/the-haskell-org-committee-has-fo… In recent years, haskell.org has started to receive assets, e.g. Google Summer Of Code funds, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: on the community server, on a server to take over hosting haskell.org itself, and on the haskell.org domain name. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. To resolve who is responsible for haskell.org’s infrastructure development, open nominations were held to form a haskell.org committee, based on representatives from the open source Haskell community. Nominations were received, and we are pleased to announce that the new committee has formed. The current members of the committee are: • Don Stewart [chair] • Edward Z. Yang • Ganesh Sittampalam • Ian Lynagh • Johan Tibell • Malcolm Wallace • Vo Minh Thu Members are expected to serve a 3 year term, and terms are staggered so that 2 or 3 members step down each year. = What we’re working on = Over the past year, two of the core infrastructure nodes: www.haskell.org (which hosts the main wiki), and code.haskell.org (which hosts a lot of project repositories) have become increasingly unreliable. To address this, a new high-spec, dedicated host was purchased, which will be used to replace both services. The commitee is now working directly to solve these issues: • Moving www.haskell.org (and the mailing lists) from Yale to the new dedicated host. • Migrating the code.haskell.org host to a VM on the new machine. More news on this work shortly. = Stay up to date = To help people better keep up to date on the status of the haskell.org infrastructure, stay up to date via: • Online: http://haskellorg.wordpress.com/ • Twitter: http://twitter.com/haskellorg - get status updates about haskell.org services via twitter. • Email: committee(a)haskell.org - To get in touch with the committee, use the committee @ haskell.org address.

1 0

http://www.haskell.org/ is down !
by Pasqualino "Titto" Assini 15 Nov '10

15 Nov '10

Hi, is haskell.org being updated or, as I fear, Haskell's HQ has been overrun by a mob of PHPers ? If so, I am ready to fight ! titto P.S. Just need to find my Excalibur, oh god, the wife just sent it to the Dry Cleaner. -- Pasqualino "Titto" Assini, Ph.D. http://quid2.org/

2 1

Re: [Haskell-cafe] Concurrent with monads
by John Lato 15 Nov '10

15 Nov '10

> > From: Jiansen He <jiansenhe(a)googlemail.com> > > Hi cafe, > > I wounder if it is possible to tell a haskell system that two computations > with side effects could be executed concurrently. > > Here is an affected example: > > Suppose two people want to compare their age, but do not want to leak their > personal information. The following program reads one person's age after > another then send back compared result. > > age :: IO () > age = do > i <- readIntFrom a > j <- readIntFrom b > writeTo a (i-j) > writeTo b (j-i) > > How can I express the fact that two readings could be carried out in any > order? The best approach is probably to fork a thread for each concurrent evaluation. There are a few packages on Hackage that can help with this; I've used threads[1] and spawn[2] successfully. If the "readIntFrom" function is meant to be responding to a client, a threaded model may make sense organizationally, but for this to be a performance benefit there needs to be sufficient work for each thread to carry out. Haskell threads are lighter than Posix threads, but there's still overhead involved. There is an alternative I hesitate to mention because it involves some voodoo, but Roman Leshchinskiy came up with a clever technique that might be appropriate if you want the behavior of "par" but for IO[3]. [1] http://hackage.haskell.org/package/threads [2] http://hackage.haskell.org/package/spawn [3] http://unlines.wordpress.com/2010/04/21/sparking-imperatives/

1 0

Opportunity: Spring semester internship on Haskell project at Intel
by Ryan Newton 15 Nov '10

15 Nov '10

Dear Haskellers, We're looking for outstanding candidates for an internship in Spring 2011. The internship will be in a suburb of Boston (Hudson, MA). Graduate students and talented undergraduates are welcome to apply, but time is a bit short. We are a small research group run directly by the CTO<http://www.intel.com/pressroom/kits/bios/plowney.htm>of Intel's Developer Products Division. Our group works on high-level parallel programming tools<http://software.intel.com/en-us/articles/intel-concurrent-collections-for-c…>(including for Haskell<http://software.intel.com/en-us/blogs/2010/05/27/announcing-intel-concurren…>) and applies binary translation <http://www.pintool.org/> to various problems; also we collaborate closely with Intel's various developer tools teams (Cilk <http://supertech.csail.mit.edu/cilk/>, TBB<http://www.threadingbuildingblocks.org/>, etc). We are looking for someone to work on a new, self-contained Haskell project to create an eDSL that targets the ArBB virtual machine (VM) for vectorization. One possible solution is to adapt existing projects that target CUDA (e.g. accelerate <http://hackage.haskell.org/package/accelerate>and Nikola <%20http://www.eecs.harvard.edu/%7Emainland/projects/nikola/>). Array Building Blocks (ArBB)<http://software.intel.com/en-us/articles/intel-array-building-blocks/>is an interesting and ambitious project that attempts to bring metaprogramming and eDSLs to the masses. It's based on research by Michael Mccool at Waterloo that he used to found a company, RapidMind<http://en.wikipedia.org/wiki/RapidMind>, which was later bought by Intel. The basic idea is that the VM abstracts over the thread and vectorization capabilities of CPUs, GPUs, and other manycore chips<http://www.intel.com/pressroom/archive/releases/20100531comp.htm>. The VM defines a restricted compute language and provides a managed (yes, garbage collected) environment. Using the normal eDSL and metaprogramming tricks the user writes a portable program in a host language streams ASTs to the VM at runtime. These vector programs include the usual aggregate array operations and high level transformations (map, fold, etc), and the VM can perform fusion/deforestation optimizations while JITting vector codes. The VM API for generating programs is a simple C API<http://software.intel.com/sites/products/documentation/arbb/arbb_manual_win…>that can be called from anywhere. The ArBB team is anxious to demonstrate language frontends for other languages, and Haskell is a good candidate. The official requisition will be available at the Intel Jobs site shortly, but in the meantime if you are interested, please forward your CV to me at ryan.r.newton(a)intel.com . Cheers, -Ryan LOCATION: Hudson, MA DURATION: 3-6 Months, flexible START: Some flexibility, ~January, 2011 EXPERIENCE: Expert Haskell/GHC programmer. Interest in research a plus. LOCATION NOTE: With a car it is possible to live in Cambridge or Boston and reverse-commute to our location. (Working offsite two days a week is possible.)

1 1

Re: [Haskell] intent-typing
by Max Rabkin 15 Nov '10

15 Nov '10

I still don't understand what intent typing is, but this particular problem is discussed (with a type-based, statically checked solution) at http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-st… --Max On Mon, Nov 15, 2010 at 17:17, Marcus Sundman <sundman(a)iki.fi> wrote: > Hi, how would one go about implementing (or using if it's supported > out-of-the-box) intent-typing* for haskell? > > *) Intent-typing is compiler/verifier/parser enforced typing similar to > "apps hungarian" notation. E.g., say I have a webapp with fields for a > user's first name and last name, which I at some point show on another > webpage that the user loads, which is a typical XSS vulnerability situation. > So I have 2 functions, getParam(...) and setParam(...), which return the > value of a user-provided parameter and gives a parameter to the template > displayed to the user, respectively. I want to somehow flag the > getParam(...)-function as returning a user-provided string (say, > "unsafe-string"), and the setParam(...)-function as requiring a safely > encoded string (say, "safe-string"), so that if I sometimes forget to run > the user-provided string through some anti-xss-encoding thingy (which would > take an "unsafe-string" and return a "safe-string"), and don't (unit-)test > this particular aspect of said code, then some verifier thingy (preferably a > static verifier) would notice this and show me a warning. > > Cheers, > Marcus > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0