- Haskell-Cafe - Haskell.org

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

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

15 May '01

> -----Original Message----- > From: Manuel M. T. Chakravarty [SMTP:chak@cse.unsw.edu.au] > Sent: Monday, May 14, 2001 10:46 PM > To: brk(a)jenkon.com > Cc: haskell-cafe(a)haskell.org > Subject: RE: Functional programming in Python > > brk(a)jenkon.com wrote, > > > > From: Manuel M. T. Chakravarty [SMTP:chak@cse.unsw.edu.au] > > Evidently this is wrong, but my intuition is that <- simply binds a > > name to a value, and that: > > No, that is not the case. It does more, it executes an I/O action. > [Bryn Keller] [snip] > The short answer is that Version 2 (the arrow) executes any > side effects encoded in `somefunc', whereas Version 1 (the > let binding) doesn't do that. Expressions given as an > argument to a function behave as if they were let bound, ie, > they don't execute any side effects. This explains why the > identity that you stated above does not hold. > > So, at the core is that Haskell insists on distinguishing > expressions that can have side effects from those that > cannot. This distinction makes the language a little bit > more complicated (eg, by enforcing us to distinguish between > `=' and `<-'), but it also has the benefit that both a > programmer and the compiler can immediately tell which > expressions do have side effects and which don't. For > example, this often makes it a lot easier to alter code > written by somebody else. It also makes it easier to > formally reason about code and it gives the compiler scope > for rather radical optimisations. > [Bryn Keller] Exactly the clarification I needed, thank you! [Bryn Keller] [snip] > > p.s. What data have your students' reactions given you about what is > > and is not difficult for beginners to grasp? > > They found it to be a difficult topic, but they found > "Unix/Shell scripts" even harder (and we did only simple > shell scripts). I actually made another interesting > observation (and keep in mind that for many that was their > first contact with programming). I had prepared for the > distinction between side effecting and non-side-effecting > expressions to be a hurdle in understanding I/O. What I > hand't taken into account was that the fact that they had > only worked in an interactive interpreter environment (as > opposed to, possibly compiled, standalone code) would pose > them a problem. The interactive interpreter had allowed > them to type in input and get results printed all way long, > so they didn't see why it should be necessary to complicate > a program with print statements. [Bryn Keller] Interesting! Thanks for your help, and for sharing your students' observations. I always knew shell scripting was harder than it ought to be. ;-) Bryn

1 0

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

15 May '01

> -----Original Message----- > From: Manuel M. T. Chakravarty [SMTP:chak@cse.unsw.edu.au] > Sent: Wednesday, May 09, 2001 12:57 AM > To: brk(a)jenkon.com > Cc: haskell-cafe(a)haskell.org > Subject: RE: Functional programming in Python > [Bryn Keller] [snip] > > > and I have to agree with Dr. Mertz - I find > > Haskell much more palatable than Lisp or Scheme. Many (most?) Python > > programmers also have experience in more typeful languages (typically at > > least C, since that's how one writes Python extension modules) so > perhaps > > that's not as surprising as it might seem. > > Ok, but there are worlds between C's type system and > Haskell's.[1] > [Bryn Keller] Absolutely! C's type system is not nearly so powerful or unobtrusive as Haskell's. > > Type inference (to my mind at least) fits the Python mindset very > > well. > > So, how about the following conjecture? Types essentially > only articulate properties about a program that a good > programmer would be aware of anyway and would strive to > reinforce in a well-structured program. Such a programmer > might not have many problems with a strongly typed language. [Bryn Keller] I would agree with this. > Now, to me, Python has this image of a well designed > scripting language attracting the kind of programmer who > strives for elegance and well-structured programs. Maybe > that is a reason. [Bryn Keller] This, too. :-) [Bryn Keller] [snip] > Absolutely. In fact, you have just pointed out one of the > gripes that I have with most Haskell texts and courses. The > shunning of I/O in textbooks is promoting the image of > Haskell as a purely academic exercise. Something which is > not necessary at all, I am teaching an introductory course > with Haskell myself and did I/O in Week 5 out of 14 (these > are students without any previous programming experience). > Moreover, IIRC Paul Hudak's book <http://haskell.org/soe/> > also introduces I/O early. > > In other words, I believe that this a problem with the > presentation of Haskell and not with Haskell itself. > > Cheers, > Manuel > > [1] You might wonder why I am pushing this point. It is > just because the type system seems to be a hurdle for > some people who try Haskell. I am curious to understand > why it is a problem for some and not for others. [Bryn Keller] Since my first mesage and your and Simon Peyton-Jones' response, I've taken a little more time to work with Haskell, re-read Tackling the Awkward squad, and browsed the source for Simon Marlow's web server, and it's starting to feel more comfortable now. In the paper and in the server souce, there is certainly a fair amount of IO work happening, and it all looks fairly natural and intuitive. Mostly I find when I try to write code following those examples (or so I think!), it turns out to be not so easy, and the real difficulty is that I can't even put my finger on why it's troublesome. I try many variations on a theme - some work, some fail, and often I can't see why. I should have kept all the versions of my program that failed for reasons I didn't understand, but unfortunately I didn't... 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 That was one difficulty. Another was trying to figure out what the $ sign was for. Finally I realized it was an alternative to parentheses, necessary due to the extremely high precedence of function application in Haskell. That high precedence is also disorienting, by the way. What's the rationale behind it? Struggling along, but starting to enjoy the aesthetics of Haskell, Bryn p.s. What data have your students' reactions given you about what is and is not difficult for beginners to grasp?

2 1