May 2001 - Haskell-Cafe

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

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

RE: Functional programming in Python
by brk＠jenkon.com 22 May '01

22 May '01

> -----Original Message----- > From: Manuel M. T. Chakravarty [SMTP:chak@cse.unsw.edu.au] > Sent: Tuesday, May 22, 2001 6:55 AM > To: pk(a)cs.tut.fi > Cc: haskell-cafe(a)haskell.org > Subject: Re: Functional programming in Python > > Pertti Kellomäki <pk(a)cs.tut.fi> wrote, > > > > From: Ketil Malde <ketil(a)ii.uib.no> > > > "Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> writes: > > > > You want to be able to write > > > > > > > f 1 2 + g 3 4 > > > > > > > instead of > > > > > > > (f 1 2) + (g 3 4) > > > > > > I do? Personally, I find it a bit confusing, and I still often get it > > > wrong on the first attempt. > > > > Same here. A while back someone said something along the lines that > people > > come to Haskell because of the syntax. For me it is the other way > around. > > My background is in Scheme/Lisp, and I still find it irritating that I > cannot > > just say indent-sexp and the like in Emacs. It is the other properties > of the > > language that keep me using it. I also get irritated when I get > > precedence wrong, so in fact I tend to write (f 1 2) + (g 2 3), which to > > my eye conveys the intended structure much better and compiles at first > try. > > In languages that don't use curring, you would write > > f (1, 2) + g (2, 3) > > which also gives application precedence over infix > operators. So, I think, we can safely say that application > being stronger than infix operators is the standard > situation. [Bryn Keller] There's another piece to this question that we're overlooking, I think. It's not just a difference (or lack thereof) in precedence, it's the fact that parentheses indicate application in Python and many other languages, and a function name without parentheses after it is a reference to the function, not an application of it. This has nothing to do with currying that I can see - you can have curried functions in Python, and they still look the same. The main advantage I see for the Haskell style is (sometimes) fewer keypresses for parentheses, but I still find it surprising at times. 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) ) ) I'm not sure why folks thought this was an improvement. I suppose it bears more resemblance to lambda calculus? > Nevertheless, the currying notation is a matter of habit. > It took me a while to get used to it, too (as did layout). > But now, I wouldn't want to miss them anymore. And as far > as layout is concerned, I think, the Python people have made > the same experience. For humans, it is quite natural to use > visual cues (like layout) to indicate semantics. [Bryn Keller] Absolutely. Once you get used to layout (Haskell style or Python style), everything else looks like it was designed specifically to irritate you. On the other hand, it's nice to have a brace-delimited style since that makes autogenerating code a lot easier. Bryn > Cheers, > Manuel > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

Re: Functional programming in Python
by Pertti Kellomäki 22 May '01

22 May '01

> From: Ketil Malde <ketil(a)ii.uib.no> > "Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> writes: > > You want to be able to write > > > f 1 2 + g 3 4 > > > instead of > > > (f 1 2) + (g 3 4) > > I do? Personally, I find it a bit confusing, and I still often get it > wrong on the first attempt. Same here. A while back someone said something along the lines that people come to Haskell because of the syntax. For me it is the other way around. My background is in Scheme/Lisp, and I still find it irritating that I cannot just say indent-sexp and the like in Emacs. It is the other properties of the language that keep me using it. I also get irritated when I get precedence wrong, so in fact I tend to write (f 1 2) + (g 2 3), which to my eye conveys the intended structure much better and compiles at first try. -- pertti

5 6

Re: PP with HaXml 1.02
by Malcolm Wallace 21 May '01

21 May '01

> Im proceeding with basic exploratory tests with HaXml (1.02, winhugs feb 2001) > > the pretty print return the closing < on the next line, like > > <Person-XML > ><Name > ><string .... > > where i expect > > <Person-XML> > <Name> > <string> > > what am i doing wrong ? You are not doing anything wrong. This is the intended behaviour. It is very important that HaXml does not add whitespace that could be interpreted as #PCDATA within an element, given that in many cases we do not know whether the DTD might permit free text in this position. Whitespace inside the tag is always ignored, so it is a safe way to display indentation without changing the meaning of the document. Regards, Malcolm

1 0