- Haskell-Cafe - Haskell.org

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

Re: Functional programming in Python
by Ketil Malde 20 May '01

20 May '01

"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. The good thing is that the rule is simple to remember. :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

Is there version of Report merged with errata?
by korek＠icm.edu.pl 19 May '01

19 May '01

It seems that errata for Haskell Report is independent document on the www.haskell.org. My limited human perception forces me to ignore these corrections completely. Has anybody got an updated(merged) version? Greetings :-) (and thanks in advance) Michal Gajda korek(a)icm.edu.pl

2 1

Re: BAL paper available >> graphic libraries
by Jerzy Karczmarczuk 17 May '01

17 May '01

[[Perhaps, if this thread continues, it is time to move to a nice -café at the corner.]] Timothy Docker: > Has anyone considered writing a haskell wrapper for SDL - Simple > Directmedia Layer at http://www.libsdl.org ? > > This is a cross platform library intended for writing games, and aims > for a high performance, low level API. It would be interesting to see > how clean a functional API could be built around such an imperative > framework. Ammmmm...... I didn't want to touch this issue, but, well, indeed, I had a look on Sam Lantinga's SDL package some time ago (I believe, a new version exists now). I know that Johnny Andersen (somewhere near DIKU, plenty of craziness on his ÁNOQ pages...) produced a Standard ML bindings for that. But reading this stuff I was simply scared to death! Using simultaneously 6 compilers, passing through "C" code, etc. - my impression was: OK, it should work. If somebody wants to write a game, a concrete simulation in ML, it might help him. But, on the other hand if you want to have a decent programming platform, enabling you to write - even (or: especially) for pedagogical purposes some graphic tools of universal character, say, * a model ray tracer with the "native" scene description language (i.e. the same language for the core implementation, and for the scene/object description, and for its scripting (animation)), * a generic texture generator and image processing toolbox with all such stuff as relational algebra of images, math. morphology, etc., * a radiosity machine * ... dozen of other projects ... then without a common memory management, without rebuilding the - say - Haskell runtime *with* SDL or other low-level graphics utilities, it might be difficult to use. The approach taken by Clean'ers, to have an "almost intrinsic" graphic object-oriented IO layer, and building their Game Library upon it, seems more reasonable, and at any rate it has more sex-appeal for those who are truly interested in practical functional programming as such, and not just in stacking some external goodies which integrate badly with the language. Bother, I realized that my main contributions to this list are just complaining. Somebody could teleport me to a desert island, with some computers, but without hoards of students just for 6 months? Jerzy Karczmarczuk Caen, France

2 1

Things and limitations...
by Juan Carlos Arevalo Baeza 17 May '01

17 May '01

Hi. First of all, I'm new to Haskell, so greetings to all listeners. And I come from the oh-so-ever-present world of C/C++ and such. Thinking in Haskell is quite different, so if you see me thinking in the wrong way, please, do point it out. That said, I want to make it clear that I'm seriously trying to understand the inner workings of a language like Haskell (I've already implemented a little toy lazy evaluator, which was great in understanding how this can all work). Only recently have I come to really understand (I hope) what a monad is (and it was extremely elusive for a while). It was a real struggle for a while :-) At 01:36 PM 5/14/2001 -0700, Bryn Keller wrote: >The only concrete example >of something that confuses me I can recall is the fact that this compiles: > > main = do allLines <- readLines; putStr $ unlines allLines > where readLines = do > eof <- isEOF > if eof then return [] else > do > line <- getLine > allLines <- readLines > return (line : allLines) > > but this doesn't: > > main = do putStr $ unlines readLines > where readLines = do > eof <- isEOF > if eof then return [] else > do > line <- getLine > allLines <- readLines > return (line : allLines) > > Evidently this is wrong, but my intuition is that <- simply binds a >name to a value, and that: > > foo <- somefunc > bar foo > > should be identical to: > > bar somefunc Yes. I'd even shorten that to: --- Valid readLines = do eof <- isEOF if eof then ... --- as opposed to: --- invalid readLines = do if isEOF then ... --- The reason behind this is, evidently, due to the fact that the do-notation is just a little bit of syntactic sugar for monads. It can't "look into" the parameter to "if" to do the monad transfer. In fact, even if it could look into the if, it wouldn't work without heavy processing. It would need to do it EXACTLY in that manner (providing a hidden binding before expression that uses the bound value). And you'd still have lots of problems dealing with order of execution. Just think of this example: --- myfunction = do if readChar > readChar then ... --- our hypothetical smarter-do-notation would need to generate one of the following: --- myfunction = do char1 <- readChar char2 <- readChar if char1 < char2 then ... --- or: --- myfunction = do char2 <- readChar char1 <- readChar if char1 < char2 then ... --- but which is the correct? In this case, you might want to define rules saying that the first is 'obviously' the correct one. But with more complex operations and expressions it might not be possible. Or you might want to leave it ambiguous. But that is quite against the spirit of Haskell, I believe. In any case, forcing the programmer to be more explicit in these matters is, I believe, a good thing. Same as not allowing circular references between modules, for example. Anyway... I have been toying a bit with Haskell lately, and I have several questions: First, about classes of heavily parametric types. Can't be done, I believe. At least, I haven't been able to. What I was trying to do (as an exercise to myself) was reconverting Graham Hutton and Erik Meijer's monadic parser library into a class. Basically, I was trying to convert the static: --- newtype Parser a = P (String -> [(a,String)]) item :: Parser Char force :: Parser a -> Parser a first :: Parser a -> Parser a papply :: Parser a -> String -> [(a,String)] --- --- class (MonadPlus (p s v)) => Parser p where item :: p s v v force :: p s v a -> p s v a first :: p s v a -> p s v a papply :: p s v a -> s -> [(a,s)] --- I have at home the actual code I tried to make work, so I can't just copy/paste it, but it looked something like this. Anyway, this class would allow me to define parsers that parse any kind of thing ('s', which was 'String' in the original lib), from which you can extract any kind of element ('v', which was 'Char') and parse it into arbitrary types (the original parameter 'a'). For example, with this you could parse, say, a recursive algebraic data structure into something else. Nhc98 wouldn't take it. I assume this is NOT proper Haskell. The questions are: Is this doable? If so, how? Is this not recommendable? If not, why? I had an idea about how to make this much more palatable. It would be something like: --- class (MonadPlus p) => Parser p where type Source type Value item :: p Value force :: p a -> p a first :: p a -> p a papply :: p a -> Source -> [(a,Source)] --- So individual instances of Parser would define the actual type aliases Source and Value. Again, though, this is NOT valid Haskell. Questions: Am I being unreasonable here? Why? Ok, last, I wanted to alias a constructor. So: --- module MyModule(Type, TypeCons) where newtype Type = TypeCons Integer instance SomeClass Type where .... --- --- module Main where import MyModule newtype NewType = NewTypeCons Type --- So, now, if I want to construct a NewType, I need to do something like: --- kk = NewTypeCons (TypeCons 5) --- And if I want to pattern-match a NewType value, I have to use both constructors again. It's quite a pain. I've tried to make a constructor that can do it in one shot, but I've been unable. Tried things like: --- AnotherCons i = NewTypeCons (TypeCons i) --- but nothing works. Again, the same questions: Is it doable? Am I being unreasonable here? 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

4 6

algebra proposals
by S.D.Mechveliani 16 May '01

16 May '01

It appears, there was a discussion on the library proposals, by D.Thurston, maybe, others. And people asked for my comments. My comments are as follows. ----------------------------------------------------------------- (1) It is misleading to call this part of the standard library `numeric': `numeric classes', `numeric Prelude', `Num', and so on. Matrices and polynomials match many of the corresponding instances but hardly can be named `numeric' objects. This is why BAL introduces the term Basic Algebra (items). (2) The order of considering problems matters. First we have to decide how to program algebra and then - whether (and how) to change the standard. The idea of the first stage forms the skeleton for the second. (3) As I see, we cannot decide how to program algebra in Haskell. Hence, it is better not to touch the standard - in order to save effort and e-mail noise. ----------------------------------------------------------------- Comments to (2) --------------- Anyone pretending to improve the standard has either to write any sensible algebraic Haskell application or to study attentively (with computing various examples) any existing one. A `sensible application' should show how to operate in parametric domains, not only in domains like (Integer, Bool). Example: polynomials in [x1..xn] with coefficients over a field (like rational numbers) quotiented by several equations. For example, the data r = Residue (x+y) (Ideal [x^2+3, y^3-2]) represents the mathematical expression squareRoot(-3) + cubicRoot(2) The basis bas = [x^2+3, y^3-2] for I = Ideal [x^2+3, y^3-2] can be computed as the first class data. And for many instances <Inst> (<Inst> may be Fractional, Field, ...) the domain (type?) of r matches or does not match <Inst> depending on the value of bas. Even if the application builds the domains only statically, when the compiler knows statically all the intended values of bas, Haskell would still meet difficulties. On dependent types ------------------ Maybe, Haskell has to move to dependent types. I am not sure, but probably, unsolvability does not matter. If the compiler fails to prove the correctness condition (on p) for a type T(p) within the given threshold d, the compiler reports "cannot prove ...". The user has to add annotations that help to prove this. Or to say "solve at run-time". Or to say "I postulate this condition on p, put the correctness on me". With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru *** I am not in haskell-cafe list ***

1 0