- Haskell-Cafe - Haskell.org

Multithreaded stateful software
by Mark Carroll 29 May '01

29 May '01

Often I've found that quite how wonderful a programming language is isn't clear until you've used it for a non-trivial project. So, I'm still battling on with Haskell. One of the projects I have coming up is a multi-threaded server that manages many clients in performing a distributed computation using a number of computers. So, we care about state, and control flow has some concurrent threads and is partially event-driven. Some possibilities come to my mind: (a) This really isn't what Haskell was designed for, and if I try to write this in Haskell I'll never want to touch it again. (b) This project is quite feasible in Haskell but when it's done I'll feel I should have just used Java or something. (c) Haskell's monads, concurrency stuff and TCP/IP libraries are really quite powerful and useful, and I'll be happy I picked Haskell for the task. Does anyone have any thoughts? (-: I have a couple of symbolic computation tasks too that use complex data structures, which I'm sure that Haskell would be great for, but I want it to be more generally useful than that because, although it's nice to always use the best tool for the job, it's also nice not to be using too many languages in-house. -- Mark

3 2

RE: Multithreaded stateful software
by Simon Peyton-Jones 28 May '01

28 May '01

| (c) Haskell's monads, concurrency stuff and TCP/IP libraries | are really quite powerful and useful, and I'll be happy I | picked Haskell for the task. Definitely (c). See Simon Marlow's paper about his experience of writing a web server (highly concurrent), and my tutorial "Tackling the awkward squad". Both at http://research.microsoft.com/~simonpj/papers/marktoberdorf.htm Haskell is a great language for writing concurrent applications. Simon

2 1

RE: Functional programming in Python
by Peter Douglass 28 May '01

28 May '01

Peter Hancock wrote: > > foo( bar( baz( x ) ) ) > > it's: > > (foo ( bar (baz x) ) ) > > Clearly the outer parentheses are unnecessary in the last expression. > One undeniable advantage of (f a) is it saves parentheses. Yes and no. In ( ( ( foo bar) baz) x ) the parens can be omitted to leave foo bar baz x but in ( foo ( bar (baz x) ) ) You would want the following I think. foo . bar . baz x which does have the parens omitted, but requires the composition operator. --PeterD

5 6

RE: Funny type.
by Simon Peyton-Jones 28 May '01

28 May '01

You need a language extension. Check out Section 7 of "Derivable type classes" http://research.microsoft.com/~simonpj/Papers/derive.htm Alas, I have not implemented the idea yet. (Partly because no one ever reports it as a problem; you are the first!) Simon | One day I was playing around with types and I came across this type: | | >data S m a = Nil | Cons a (m (S m a)) | | The idea being one could use generic functions with whatever | monad m (of course m doesn't need to be a monad but my | original idea was to be able to make mutable lists with some | sort of monad m.) | | Anyway in attempting to define a generic show instance for | the above datatype I finally came upon: | | >instance (Show a, Show (m (S m a))) => Show (S m a) where | > show Nil = "Nil" | > show (Cons x y) = "Cons " ++ show x ++ " " ++ show y | | which boggles my mind. But hugs +98 and ghci | -fallow-undecidable-instances both allow it to compile but when i try

1 0

Re: Functional programming in Python
by Juan Carlos Arevalo Baeza 26 May '01

26 May '01

At 05:25 PM 5/25/2001 -0400, S. Alexander Jacobson wrote: >Admittedly, this is different from how haskell type checks now. I guess >the question is whether it is impossible to type check or whether it just >requires modification to the type checking algorithm. Does anyone know? I don't think so... The only ambiguity that I can think of is with passing functions as arguments to other functions, and you showed that it can be resolved by currying: map f x would have to be force-curried using parenthesis: (map f) x because otherwise, it would mean: map (f x) which is both: very wrongly typed and NOT the intention. I like your parsing scheme. I still DO like more explicit languages better, though (i.e. map(f, x) style, like C & Co.). Currying is cool, but it can be kept at a conceptual level, not affecting syntax. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html

1 0

Re: Functional programming in Python
by Peter Hancock 24 May '01

24 May '01

Hi, you said > Unfortunately in many cases you need to apply nearly as many > parens for a Haskell expression as you would for a Python one, but > they're in different places. It's not: > > foo( bar( baz( x ) ) ) > it's: > (foo ( bar (baz x) ) ) Clearly the outer parentheses are unnecessary in the last expression. One undeniable advantage of (f a) is it saves parentheses. My feeling is that the f(a) (mathematical) notation works well when type set or handwritten, but the (f a) (combinatory logic) notation looks better with non-proportional fonts. In a way the f(a) notation "represents things better": the f is at a higher parenthesis level than the a. Peter Hancock

1 0

Re: Functional programming in Python
by Peter Hancock 24 May '01

24 May '01

Hi, you said > Unfortunately in many cases you need to apply nearly as many > parens for a Haskell expression as you would for a Python one, but > they're in different places. It's not: > > foo( bar( baz( x ) ) ) > it's: > (foo ( bar (baz x) ) ) Clearly the outer parentheses are unnecessary in the last expression. One undeniable advantage of (f a) is it saves parentheses. My feeling is that the f(a) (mathematical) notation works well when type set or handwritten, but the (f a) (combinatory logic) notation looks better with non-proportional fonts. In a way the f(a) notation "represents things better": the f is at a higher parenthesis level than the a. Peter Hancock

1 0

Re: Templates in FPL?
by D. Tweed 23 May '01

23 May '01

On 22 May 2001, Carl R. Witty wrote: > "D. Tweed" <tweed(a)cs.bris.ac.uk> writes: > > > In my experience the C++ idiom `you only pay for what you use' (==> > > templates are essentially type-checked macros) and the fact most compilers > > are evolved from C compilers makes working with templates a real pain in > > practice. > > I'm not sure what you mean by type-checked here. Templates are not > type-checked at definition time, but are type-checked when they are > used; the same is true of ordinary macros. I was thinking in terms of (to take a really simple example) template<class T> void initialiseArray(T** arr,const T& elt,int bnd) { for(int i=0;i<bnd;++i){ arr[i]=elt.realValue(); // <----------------- } } If I try and use intialiseArray(<obj of type foo>,<obj of type bar>), with the template function I get the error when passing in the parameters; with a macro the type error would appear at the indicated line, and indeed if by pure chance bar just happened to have a member function called realValue then I wouldn't get one at all. In my view it's reasonable to say that template functions are type-checked in essentially the same way as general functions, giving type errors in terms of the source code that you're using, whereas there's no way to ignore the fact macros dump a lot of code at the calling point in your program (mapping certain identifiers to local identifiers) and then type-checking in the context of the calling point. The above code is a really contrived example, but I do genuinely find it useful that template type-error messages are essentially normal function type-error messages. [As an aside to Marcin, one of my vague plans (once I've been viva'd, etc) is to have a go at writing some Haskell code that attempts to try and simplify g++ template type errors, e.g., taking in a nasty screen long error message and saying `This looks like a list<a> ---- list<a>* mistake' Like everything I plan to do it may not materialise though.] ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers email: tweed(a)cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.

2 2

RE: Recursive types?
by Tom Pledger 22 May '01

22 May '01

(Bailing out to haskell-cafe because this stuff is probably old hat) David Bakin writes: | Thank you. | | Now, on seeing your Tree example I tried to use it by defining | height using structural recursion. But I couldn't find a valid | syntax to pattern match - or otherwise define the function - on the | type CT. Is there one? No. You can generalise over some structures ctHeight :: (CT c k e -> Tree c k e) -> CT c k e -> Int ctHeight extract ct = case extract ct of Empty -> 0 Node l _ r -> let hl = ctHeight extract l hr = ctHeight extract r in 1 + max hl hr plainHeight = ctHeight (\(Plain t) -> t) labelledHeight = ctHeight snd where the role of `extract' is a simplification of that of `phi' in section 5.1 of the paper you mentioned (MPJ's Functional Programming with Overloading and Higher-Order Polymorphism). I'm rapidly getting out of my depth in bananas and lenses, so won't try to be more specific about the similarity. Anyway, the type of ctHeight is not appropriate for all possible structures. For example, to follow an STRef you must visit an ST: import ST stHeight :: CT STRef s e -> ST s Int stHeight ct = do t <- readSTRef ct case t of Empty -> return 0 Node l _ r -> do hl <- stHeight l hr <- stHeight r return (1 + max hl hr) - Tom : | -----Original Message----- | From: Tom Pledger [mailto:Tom.Pledger@peace.com] : | One advantage of such higher-order types is reusability. For example, | this | | type CT c k e | = c k (Tree c k e) -- Contained Tree, container, key, element | data Tree c k e | = Empty | | Node (CT c k e) e (CT c k e) | | can be used with no frills | | newtype Plain k t = Plain t | ... :: Tree Plain () e | | or with every subtree labelled | | ... :: Tree (,) String e | | or with every subtree inside the ST monad | | import ST | ... :: Tree STRef s e

1 0

RE: HUGS error: Unresolved overloading
by Mark P Jones 22 May '01

22 May '01

Hi David, | Can anyone shed some light on the following error? Thanks in advance. | | isSorted :: Ord a => [a] -> Bool | isSorted [] = True | isSorted [x] = True | isSorted (x1:x2:xs) | | x1 <= x2 = isSorted (x2:xs) | | otherwise = False I'm branching away from your question, but hope that you might find some additional comments useful ... the last equation in your definition can actually be expressed more succinctly as: isSorted (x1:x2:xs) = (x1 <= x2) && isSorted (x2:xs) This means exactly the same thing, but, in my opinion at least, is much clearer. In fact there's a really nice way to redo the whole definition in one line using standard prelude functions and no explicit recursion: isSorted xs = and (zipWith (<=) xs (tail xs)) In other words: "When is a list xs sorted? If each element in xs is less than or equal to its successor in the list (i.e., the corresponding element in tail xs)." I know this definition may look obscure and overly terse if you're new to either (a) the prelude functions used here or (b) the whole style of programming. But once you get used to it, the shorter definition will actually seem much clearer than the original, focusing on the important parts and avoiding unnecessary clutter. I don't see many emails on this list about "programming style", so this is something of an experiment. If folks on the list find it interesting and useful, perhaps we'll see more. But if everybody else thinks this kind of thing is a waste of space, then I guess this may be the last such posting! All the best, Mark

4 3