- Haskell-Cafe - Haskell.org

Re: Functional programming in Python
by Marcin 'Qrczak' Kowalczyk 29 May '01

29 May '01

Mon, 28 May 2001 10:23:58 +0100, Malcolm Wallace <Malcolm.Wallace(a)cs.york.ac.uk> pisze: > It seems that right-associativity is so intuitive that even the > person proposing it doesn't get it right. :-) And even those who correct them :-) >> f x (foldr1 f xs) f x foldr1 f xs > > Wouldn't the rhs actually mean f x (foldr1 (f xs)) in current notation? No: f (x (foldr1 (f xs))) Basically Haskell's style uses curried functions, so it's essential to be able to apply a function to multiple parameters without a number of nested parentheses. BTW, before I knew Haskell I exprimented with a syntax in which 'x f' is the application of 'f' to 'x', and 'x f g' means '(x f) g'. Other arguments can also be on the right, but in this case with parentheses, e.g. 'x f (y)' is a function f applied to two arguments. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

2 1

Funny type.
by Jay Cox 29 May '01

29 May '01

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 >show s on >s = Cons 3 [Cons 4 [], Cons 5 [Cons 2 [],Cons 3 []]] (btw yes we are "nesting" an arbitrary lists here! however structurally it really isnt much different from any tree datatype) we get ERROR - *** The type checker has reached the cutoff limit while trying to *** determine whether: *** Show (S [] Integer) *** can be deduced from: *** () *** This may indicate that the problem is undecidable. However, *** you may still try to increase the cutoff limit using the -c *** option and then try again. (The current setting is -c998) funny thing is apparently if you set -c to an odd number (on hugs) it gives *** The type checker has reached the cutoff limit while trying to *** determine whether: *** Show Integer *** can be deduced from: *** () why would it try to deduce Show integer? Anyway, is my instance declaration still a bit mucked up? Also, could there be a way to give a definition of show for S [] a? Heres my sample definition just in case anybody is curious. >myshow Nil = "Nil" >myshow (Cons x y) = "Cons "++ show x ++ > " [" ++ blowup y ++ "]" > where blowup (x:y:ls) = myshow x ++ "," ++ blowup (y:ls) > blowup (x:[]) = myshow x > blowup [] = "" Thanks, Jay Cox yet another non-academic person on this list.

6 5

Re: Type resolution problem
by Marcin 'Qrczak' Kowalczyk 29 May '01

29 May '01

Mon, 28 May 2001 17:53:38 -0700, Juan Carlos Arevalo Baeza <jcab(a)roningames.com> pisze: > Uncommenting the type expression above clears the error. > But, why can't the compiler deduce it by itself? Monomorphism restriction strikes again. See section 4.5.5 in the Haskell 98 Report. A pattern binding without an explicit type signature is considered monomorphic (must resolve to a simgle non-overloaded type) and points of usage or defaulting rules for numeric types determine the type (neither applies here). IMHO monomorphism restriction should be removed (the case for bindings of the form var = expr without type signature). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

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 25 May '01

25 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