- Haskell-Cafe - Haskell.org

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

23 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

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

Re: Databases
by Justin: Member Since 1923 15 May '01

15 May '01

> > Is there an efficient way to make simple databases in Haskell? I mean >something like a dictionary, hash table or associative container of some kind. > > I'm aware that Haskell being pure functional means that those things >are not as easily implemented as they can be in other languages, in fact, >I've implemented a simple one myself, using a list of pairs (key,value) >(which means it's slow on lookup) and an optional monad to handle the >updates/lookups. > > I guess what I'm wondering is what has been done in this respect. There >is no such thing in the standard library, as far as I can see, and my >search through the web has turned up nothing. Chris Okasaki has developed a whole mess of purely function data structures. He has a book: http://www.cs.columbia.edu/~cdo/papers.html#cup98 Maybe this is what you're looking for? HTH -Justin

2 1

argument permutation and fundeps
by C T McBride 13 May '01

13 May '01

Hi This is a long message, containing a program which makes heavy use of type classes with functional dependencies, and a query about how the typechecker treats them. It might be a bit of an effort, but I'd be grateful for any comment and advice more experienced Haskellers can spare the time to give me. Er, this ain't no undergrad homework... I'm a dependently typed programmer and a bit of an old Lisphead. What's common to both is that it's fairly easy to write `program reconstruction operations', like the argument permutation function (of which flip is an instance), specified informally thus: Given a permutation p on [1..n] and an n-ary function f, permArg p f x_p(1) .. x_p(n) = f x_1 .. x_n It's easy in Lisp because you can just compute the relevant lambda-expression for permArg p f syntactically, then use it as a program: of course, there's no type system to make sure your p is really a perm and your f has enough arguments. To give permArg a precise type, we have to compute an n-ary permutation of the argument types for an n-ary function space. That is, we need a representation of permutations p from which to compute (1) the type of the permutation function (2) the permutation function itself This isn't that hard with dependent types, because we can use the same kinds of data and program as easily at the level of types as we can at the level of terms. I'm relatively new to Haskell: what attracted me is that recent extensions to the language have introduced a model of computation at the type level via multi-parameter classes with functional dependencies. Although type-level Haskell programming is separate from, different to, and not nearly as powerful as term-level Haskell programming, it's still possible to do some pretty interesting stuff: here's permArg as a Haskell program... Although we can't compute with types over a data encoding of permutations, we can use type classes to make `fake' datatypes one level up. Here's a class representing the natural numbers. Each type in the class has a single element, which we can use to tell the typechecker which instance of the class we mean. > class Nat n > data O = O > instance Nat O > data (Nat n) => S n = S n > instance (Nat n) => Nat (S n) Now, for each n in Nat, we need a class Fin n with exactly n instances. A choice of instance represents the position the first argument of an n-ary function gets shifted to. We can make Fin (S n) by embedding Fin n with one type constructor, FS, and chucking in a new type with another, FO. > class (Nat n) => Fin n x | x -> n > data (Nat n) => FO n = FO n > instance (Nat n) => Fin (S n) (FO n) > data (Nat n,Fin n x) => FS n x = FS n x > instance (Nat n,Fin n x) => Fin (S n) (FS n x) The class Factorial n contains n! types---enough to represent the permutations. It's computed in the traditional way, but this time the product is cartesian... > class (Nat n) => Factorial n p | p -> n > instance Factorial O () > instance (Factorial n p,Fin (S n) x) => Factorial (S n) (x,p) The operation InsertArg n x r s, where x is in Fin (S n), takes an n-ary function type s and inserts an extra argument type r at whichever of the (S n) positions is selected by x. The corresponding function, insertArg permutes a (S n)-ary function in r -> s by flipping until the first argument has been moved to the nominated position. FS codes `flip the argument further in and keep going'; FO codes `stop flipping'. > class (Nat n,Fin (S n) x) => > InsertArg n x r s t | x -> n, x r s -> t, x t -> r s where > insertArg :: x -> (r -> s) -> t > instance (Nat n) => InsertArg n (FO n) r s (r -> s) where > insertArg (FO _) f = f > instance (Nat n,Fin (S n) x,InsertArg n x r s t) => > InsertArg (S n) (FS (S n) x) r (a -> s) (a -> t) where > insertArg (FS _ x) f a = insertArg x (flip f a) PermArg simply works its way down the factorial, performing the InsertArg indicated at each step. permArg is correspondingly built with insertArg. > class (Nat n,Factorial n p) => > PermArg n p s t | p s -> t, p t -> s where > permArg :: p -> s -> t > instance PermArg O () t t where > permArg () t = t > instance (InsertArg n x r t u,PermArg n p s t) => > PermArg (S n) (x,p) (r -> s) u where > permArg (x,p) f = insertArg x (\r -> permArg p (f r)) This code is accepted by the Feb 2000 version of Hugs, of course with -98 selected. Let's look at some examples: the interesting thing is how the typechecker copes. Here's the instance of permArg which corresponds to flip Main> permArg (FS (S O) (FO O),(FO O,())) ERROR: Unresolved overloading *** Type : (InsertArg (S O) (FS (S O) (FO O)) a b c, InsertArg O (FO O) d e b, PermArg O () f e) => (a -> d -> f) -> c *** Expression : permArg (FS (S O) (FO O),(FO O,())) OK, I wasn't expecting that to work, because I didn't tell it the type of the function to permute: however, the machine did figure it out. Look at where it got stuck: I'd have hoped it would compute that e is f, and hence that b is d -> f, then possibly even that c is d -> a -> f. Isn't that what the functional dependencies say? On the other hand, if I tell it the answer, it's fine. Main> :t permArg (FS (S O) (FO O),(FO O,())) :: (a -> b -> c) -> b -> a -> c permArg (FS (S O) (FO O),(FO O,())) :: (a -> b -> c) -> b -> a -> c First, a nice little monomorphic function. > elemChar :: Char -> [Char] -> Bool > elemChar = elem There's no doubt about the type of the input, but this happens: Main> permArg (FS (S O) (FO O),(FO O,())) elemChar ERROR: Unresolved overloading *** Type : (InsertArg (S O) (FS (S O) (FO O)) Char a b, InsertArg O (FO O) [Char] c a, PermArg O () Bool c) => b *** Expression : permArg (FS (S O) (FO O),(FO O,())) elemChar What am I doing wrong? I hope my program says that c is Bool, and so on. Again, tell it the answer and it checks out: Main> :t (permArg (FS (S O) (FO O),(FO O,())) elemChar) :: [Char] -> Char -> Bool permArg (FS (S O) (FO O),(FO O,())) elemChar :: [Char] -> Char -> Bool Adding some arguments gives enough information about `the answer' to get rid of the explicit typing. Main> permArg (FS (S O) (FO O),(FO O,())) elemChar ['a','b','c'] 'b' True :: Bool It's the same story with arity 3... Main> :t permArg (FS (S (S O)) (FO (S O)),(FS (S O) (FO O),(FO O,()))) :: (a -> b -> c -> d) -> (c -> a -> b -> d) permArg (FS (S (S O)) (FO (S O)),(FS (S O) (FO O),(FO O,()))) :: (a -> b -> c -> d) -> c -> a -> b -> d Main> permArg (FS (S (S O)) (FO (S O)),(FS (S O) (FO O),(FO O,()))) foldl ERROR: Unresolved overloading *** Type : (InsertArg (S (S O)) (FS (S (S O)) (FO (S O))) (a -> b -> a) c d, InsertArg (S O) (FS (S O) (FO O)) a e c, InsertArg O (FO O) [b] f e, PermArg O () a f) => d *** Expression : permArg (FS (S (S O)) (FO (S O)),(FS (S O) (FO O),(FO O,()))) foldl Main> :t (permArg (FS (S (S O)) (FO (S O)),(FS (S O) (FO O),(FO O,()))) :: (a -> b -> c -> d) -> (c -> a -> b -> d)) foldl permArg (FS (S (S O)) (FO (S O)),(FS (S O) (FO O),(FO O,()))) foldl :: [a] -> (b -> a -> b) -> b -> b Main> permArg (FS (S (S O)) (FO (S O)),(FS (S O) (FO O),(FO O,()))) foldl [1,2,3] (+) 0 6 :: Integer So, am I failing to explain to Hugs why PermArg and InsertArg are programs, despite the explicit functional dependencies, or is the typechecker just not running them? It seems to be expanding PermArg's step case ok, but not executing the base case, leaving InsertArg blocked. Can anyone shed some light on the operational semantics of programming at the type level? Having, said all that, I'm really impressed that even this much is possible in Haskell. It's so nice to be able to write a type that says exactly what I mean. Cheers Conor

4 4

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

11 May '01

Hi Manuel, It's interesting to me to note the things that were interesting to you. :-) I'm the author of the Xoltar Toolkit (including functional.py) mentioned in those articles, 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. Type inference (to my mind at least) fits the Python mindset very well. I think most Python programmers would be glad to have strong typing, so long as they don't have to press more keys to get it. If you have to declare all your types up front, it just means more time spent changing type declarations as the design evolves, but if the compiler can just ensure your usage is consistent, that's hard to argue with. As for the difficulty with imperative constructs, I agree it's not even an issue for many (Dylan, ML, et. al.) languages, but for Haskell it still is, in my humble opinion. I found the task of writing a simple program that did a few simple imperative things inordinately difficult. I know about the 'do' construct, and I understand the difference between >> and >>=. I've read a book on Haskell, and implemented functional programming support for Python, but trying to use Haskell to write complete programs still ties my brain in knots. I see there are people writing complete, non-trivial programs in Haskell, but I don't see how. To be sure, I owe Haskell more of my time and I owe it to myself to overcome this difficulty, but I don't think it's only my difficulty. In the Haskell book I have, discussion of I/O is delayed until chapter 18, if memory serves. One thing that might really help Haskell become more popular is more documentation which presents I/O in chapter 2 or 3. Clearly the interesting part of a functional language is the beauty of stringing together all these functions into a single, elegant expression, but an introductory text would do well to focus on more immediate problems first. People on this list and others often say that the main body of the program is almost always imperative in style, but there's little demonstration of that fact - most examples are of a purely functional nature. Please understand I mean these comments in the most constructive sense. I have the highest respect for Haskell and the folks who work with it. Bryn > -----Original Message----- > From: Manuel M. T. Chakravarty [SMTP:chak@cse.unsw.edu.au] > Sent: Sunday, May 06, 2001 10:02 PM > To: haskell-cafe(a)haskell.org > Subject: Functional programming in Python > > Two quite interesting articles about FP in Python are over > at IBM developerWorks: > > http://www-106.ibm.com/developerworks/library/l-prog.html > http://www-106.ibm.com/developerworks/library/l-prog2.html > > Two IMHO interesting things to note are the following: > > * In Part 1, at the start, there is a bullet list of what > the author regards as FP "features". I found the > following interesting about this list: > > - There is no mention of the emphasis placed on strong > typing in many modern functional languages. > > - The author makes it sound as if FP can't handle > imperative features, whereas I would say that this is a > problem of the past and wasn't an issue in many FP > languages (Lisp, ML, ...) in the first place. > > The opinion of the author is not really suprising, but I > think, it indicates a problem in how FP presents itself > to the rest of the world. > > * In Part 2, the author writes at the end: > > I have found it much easier to get a grasp of functional > programming in the language Haskell than in Lisp/Scheme > (even though the latter is probably more widely used, if > only in Emacs). Other Python programmers might > similarly have an easier time without quite so many > parentheses and prefix (Polish) operators. > > I think, this is interesting, because both Lisp and Python > are dynammically typed. So, I would have expected the > strong type system to be more of a hurdle than Lisp's > syntax (or lack thereof). > > Cheers, > Manuel > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

5 5

Re: sharing datatypes : best practice ?
by Jan Kort 11 May '01

11 May '01

"Taesch, Luc" wrote: > > do u isolate just the datatype, or a few related with, in a very small file (header like, i would say) > or some basic accessor function with it ? > > isnt it leading to massiv quantities of small files ? Asuming you have some typed AST with many mutually recursive datatypes, I would keep them in one big file. This should be fine if the datatypes are simple (no "deriving" Read and Show etc.). For an AST you don't want accessor functions: the datatypes are the interface. For some datatypes you want to hide the datatype and provide a function based interface, this should be in the same file as the datatype. Usually there is also some kind of asumed hierarchy in datatypes, e.g. Int < List < FiniteMap, to determine where functions operating on multiple datatypes should be placed, but that's the same in OO. Jan

1 0

Re: Macros[by implementor of toy compiler]
by Keith Wansbrough 08 May '01

08 May '01

> 2. Macros make the parsed grammar dynamic. Usually compiler has hard-coded > parser generated by LALR parser generator(like Happy or Yacc) compiled in. > Introducing each macro like you proposed would need(I think) generating > new parser(at least for the fragment of the grammar). Dylan has macros and a syntax more interesting than LISP's, so perhaps it would be worth looking at how they handle it. I forget now, but I don't think it was too difficult. I also considered some of the issues we're discussing in an unpublished paper that appears on my publications page, http://www.cl.cam.ac.uk/~kw217/research/papers.html#Wansbrough99:Macros (Section 8 looks briefly at Dylan-style macro facilities). --KW 8-)

1 0

Macros
by Alan Bawden 08 May '01

08 May '01

Date: Thu, 3 May 2001 18:09:01 -0500 (EST) From: Dan Knapp <dankna(a)brain.mics.net> > > (if (not (< x 3)) > > (assertion-failed '(< x 3))) > > This is a good example, which cannot be implemented in > Haskell. "Exception.assert" is built in to the ghc compiler, rather than > being defined within the language. On the other hand, the built in > function gives you the source file and line number rather than the literal > expression; the macro can't do the former. Yeah, it's a good example, but are there any other uses for such quoting? There are a few. But this isn't the -only- reason to still use macros. We could systematically go through all the macros I've written in the last few years, and for each one we could figure out what language feature would be needed in order to make that macro unnecessary. At the end of the process you would have a larger programming language, but I still wouldn't be convinced that we had covered all the cases. A macro facility is like a pair of vise-grips (if you don't know what those are, see http://www.technogulf.com/ht-vise.htm) You can do a lot of things with a pair of vise-grips, although usually there's a better tool for the job -- if you haven't got (say) a pipe-wrench, then a pair of vise-grips can substitute. Now the more tools you have in your tool box, the less often you will use your vise-grips. But no matter how bloated your tool box becomes, you will still want to include a pair of vise-grips for the unanticipated situation. I have one problem with my own analogy: If you find yourself using your vise-grips everyday for some task, you will probably soon go and purchase a more appropriate tool. But I think that in many circumstances macros do such a good job that I don't see the need to clutter up the language with the special-prupose features needed to replace them. Date: Fri, 04 May 2001 12:57:29 +0200 From: Jerzy Karczmarczuk <karczma(a)info.unicaen.fr> ... I think that they are less than popular nowadays because they are dangerous, badly structured, difficult to write "hygienically".... Indeed, you can screw up pretty badly with a pair of vise-grips! A friend of mine used to say that programmers should have to pass some kind of licensing test before they would be allowed to write Lisp/Scheme macros.

2 2

RE: Macros
by Simon Marlow 07 May '01

07 May '01

> Simon Marlow wrote: > > > > Well, simply extending the Haskell syntax to allow > > > > \ p11 .. p1n -> e1 > > .. > > pm1 .. pmn -> em > > > > (with appropriate layout) should be ok, but I haven't tried > it. Guarded > > right-hand-sides could be allowed too. > > Introducing layout after \ will break a lot of programs. For example, > consider the way >>= is often formatted: > > f >>= \x -> > g >>= \y -> > ... > > I guess that's why Marcin suggested using a new keyword. Ah yes, I forgot that lambda expressions are often used like that (actually, I think that this use of the syntax is horrible, but that's just MHO). Cheers, Simon

1 0

RE: Macros
by Simon Marlow 07 May '01

07 May '01

> Today I ran across exactly your case. In non-pure languages you would > just write 'case foo of'. I would be happy with just 'function': > > get >>= function > ... -> ... > ... -> ... Well, simply extending the Haskell syntax to allow \ p11 .. p1n -> e1 .. pm1 .. pmn -> em (with appropriate layout) should be ok, but I haven't tried it. Guarded right-hand-sides could be allowed too. Cheers, Simon

2 1

Re: Interesting: "Lisp as a competitive advantage"
by Norman Ramsey 07 May '01

07 May '01

> http://www.paulgraham.com/paulgraham/avg.html > > I wonder how Haskell compares in this regard. I loved Graham's characterization of the hierarchy of power in programming languages: - Languages less powerful than the one you understand look impoverished - Languages more powerful than the one you understand look weird When I compare Lisp and Haskell, the big question in my mind is this: is lazy evaluation sufficient to make up for the lack of macros? I would love to hear from a real Lisp macro hacker who has also done lazy functional progrmaming. Norman

9 9

Re: Macros (Was: Interesting: "Lisp as a competitive advantage")
by Keith Wansbrough 07 May '01

07 May '01

Jerzy Karczmarczuk <karczma(a)info.unicaen.fr> writes: > Macros in Scheme are used to unfold n-ary control structures such as COND > into a hierarchy of IFs, etc. Nothing (in principle) to do with laziness > or HO functions. Isn't this exactly the reason that macros are less necessary in lazy languages? In Haskell you can write myIf True x y = x myIf False x y = y and then a function like recip x = myIf (abs x < eps) 0 (1 / x) works as expected. In Scheme, (define myIf (lambda (b x y) (if b x y))) does *not* have the desired behaviour! One can only write myIf using macros, or by explicitly delaying the arguments. --KW 8-)

3 2

Functional programming in Python
by Manuel M. T. Chakravarty 07 May '01

07 May '01

Two quite interesting articles about FP in Python are over at IBM developerWorks: http://www-106.ibm.com/developerworks/library/l-prog.html http://www-106.ibm.com/developerworks/library/l-prog2.html Two IMHO interesting things to note are the following: * In Part 1, at the start, there is a bullet list of what the author regards as FP "features". I found the following interesting about this list: - There is no mention of the emphasis placed on strong typing in many modern functional languages. - The author makes it sound as if FP can't handle imperative features, whereas I would say that this is a problem of the past and wasn't an issue in many FP languages (Lisp, ML, ...) in the first place. The opinion of the author is not really suprising, but I think, it indicates a problem in how FP presents itself to the rest of the world. * In Part 2, the author writes at the end: I have found it much easier to get a grasp of functional programming in the language Haskell than in Lisp/Scheme (even though the latter is probably more widely used, if only in Emacs). Other Python programmers might similarly have an easier time without quite so many parentheses and prefix (Polish) operators. I think, this is interesting, because both Lisp and Python are dynammically typed. So, I would have expected the strong type system to be more of a hurdle than Lisp's syntax (or lack thereof). Cheers, Manuel

1 0

Macros
by Alan Bawden 06 May '01

06 May '01

Date: Fri, 4 May 2001 19:31:21 -0400 (EDT) From: Jan-Willem Maessen <earwig(a)abp.lcs.mit.edu> Alan Bawden <Alan(a)LCS.MIT.EDU> writes: > A macro facility is like a pair of vise-grips (if you don't know what > those are, see http://www.technogulf.com/ht-vise.htm) I found myself laughing heartily at this apt analogy. I have heard vice grips described as "the wrong tool for every job." (My own experience with vice grips backs this up). I considered including that well-known quip in the paragraph where I tried to make it clear that I was -not- saying the same thing about macros. (While looking for a good online picture of vise-grips I came across a number of vise-grip horror stories -- the best was the guy who replaced the steering wheel in his car with a pair of vise-grips! But I digress...) So just to reiterate: the property of vise-grips I find analogous to a macro facility is that the more -other- tools you have available, the less often you need -this- one, nevertheless you still want this tool in your tool-box. That being said, there are a number of things one might want out of a macro facility, and I think they should be carefully distinguished: 1) The ability to name expressions without evaluating them, e.g. to cook up a facsimile of laziness. 2) The ability to parrot source code (and maybe source position) back at the user, e.g. Alan's assert macro, or its C equivalent. 3) The ability to create new binding constructs. 4) The ability to create new declaration constructs. I like this list. I'd love to see nice elegant programming language features for doing all of these things. Not only would I have to write fewer macros, but I'd probably be able to do many amazing -new- things. (Lazyness, for example, doesn't just eliminate the need for a lot of macros, it allows many new things that are beyond the reach of mere macrology!) I suspect, however, that even with everything on this list checked off, I'd still want macros. Because I doubt that this list is exhaustive. The example I pulled out of my hat led you to put item #2 on this list, but I wonder if you would have thought of #2 if you didn't have my example before you? If I had picked another example, I suspect this list would have looked different. - Alan

1 0

Macros
by Jan-Willem Maessen 05 May '01

05 May '01

Alan Bawden <Alan(a)LCS.MIT.EDU> writes: > A macro facility is like a pair of vise-grips (if you don't know what > those are, see http://www.technogulf.com/ht-vise.htm) I found myself laughing heartily at this apt analogy. I have heard vice grips described as "the wrong tool for every job." (My own experience with vice grips backs this up). That being said, there are a number of things one might want out of a macro facility, and I think they should be carefully distinguished: 1) The ability to name expressions without evaluating them, e.g. to cook up a facsimile of laziness. 2) The ability to parrot source code (and maybe source position) back at the user, e.g. Alan's assert macro, or its C equivalent. 3) The ability to create new binding constructs. 4) The ability to create new declaration constructs. (1) is pretty well covered by lazy evaluation. For (2), I wonder if a clever set of compiler-supplied implicit parameters might do the trick---after all, "the position of expression e" and "the source code of expression e" are dynamic notions that could be carefully defined. (3) is trickier. Contrast monadic code before and after "do" notation was introduced. Haskell made it possible---not even very hard---to do monadic binding, but there was a good deal of ugly syntactic noise. The introduction of "do" notation eliminated that noise. My instinct is that this isn't so easy for things that can't be shoehorned into a monad. For example, I use the Utrecht attribute grammar tool, and have trouble imagining how grammars could be coded in pure Haskell while preserving nice naming properties. (4) is harder still. Polytypic classes are a huge step in the right direction. What I most long for, though, is the ability to synthesize new types and new classes---not just simple instance declarations. As you can probably guess, I think (3) and (4) are the most profitable avenues of exploration. And I'm pretty sure I _don't_ want syntax macros for these. I'm still waiting to be convinced what I do want. -Jan-Willem Maessen Eager Haskell project jmaessen(a)mit.edu

1 0

Re: Implict parameters and monomorphism
by Dylan Thurston 04 May '01

04 May '01

On Fri, May 04, 2001 at 07:56:24PM +0000, Marcin 'Qrczak' Kowalczyk wrote: > I would like to make pattern and result type signatures one-way > matching, like in OCaml: a type variable just gives a name to the given > part of the type, without constraining it any way - especially without > "negative constraining", i.e. without yielding an error if it will > be known more than that it's a possibly constrained type variable... I'm not sure I understand here. One thing that occurred to me reading your e-mail was that maybe the implicit universal quantification over type variables is a bad idea, and maybe type variables should, by default, have pattern matching semantics. Whether or not this is a good idea abstractly, the way I imagine it, it would make almost all existing Haskell code invalid, so it can't be what you're proposing. Are you proposing that variables still be implicitly quantified in top-level bindings, but that elsewhere they have pattern-matching semantics? Best, Dylan Thurston

2 1

Re: Haskell-Cafe digest, Vol 1 #122 - 3 msgs
by Alan Bawden 04 May '01

04 May '01

Subject: Re: Interesting: "Lisp as a competitive advantage" Date: Thu, 03 May 2001 10:16:37 -0400 From: Norman Ramsey <nr(a)eecs.harvard.edu> > http://www.paulgraham.com/paulgraham/avg.html > > I wonder how Haskell compares in this regard. I loved Graham's characterization of the hierarchy of power in programming languages: - Languages less powerful than the one you understand look impoverished - Languages more powerful than the one you understand look weird When I compare Lisp and Haskell, the big question in my mind is this: is lazy evaluation sufficient to make up for the lack of macros? I would love to hear from a real Lisp macro hacker who has also done lazy functional progrmaming. Norman --__--__-- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe End of Haskell-Cafe Digest

4 3

Re: Interesting: "Lisp as a competitive advantage"
by andrew＠andrewcooke.free-online.co.uk 03 May '01

03 May '01

Two things in that interested me. First, the comment that "runtime typing" is becoming more popular - did he mean strong rather than weak typing, or dynamic rather than static? Second, more interestingly, I was surprised at his emphasis on macros. Having read his (excellent) On Lisp maybe I shouldn't have been (since that is largely about macros), but anyway, I think it's interesting because it's one of the big differences between Lisp and the statically typed languages (STLs). I have used neither Lisp nor Haskell (or ML) long enough to make a sound judgementon this, so I'd like to hear other views. My first thought is that higher order functions are easier to manage in STLs and might provide some compensation. Also, I'm aware that (limited?) code manipulation is possible in some STLs (there's an ML library whose name I've forgotten). How do these compare? I realise I could get more response by a usenet post to c.l.f and c.l.l, but I'm hoping there might be more light here. Apologies if it's too off-topic. Thanks, Andrew On Tue, May 01, 2001 at 08:58:07PM -0400, Sengan wrote: > http://www.paulgraham.com/paulgraham/avg.html > > I wonder how Haskell compares in this regard. > Any comment from Haskell startups? (eg Galois Connections) > > Sengan > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- http://www.andrewcooke.free-online.co.uk/index.html

2 1

tutorial and other random bits
by Shae Erisson 29 Apr '01

29 Apr '01

Hi, I've started learning Haskell, but I'm coming from a Python/Java/SQL/etc background. I've learned a bit of elisp and scheme in my travels, but Haskell is very very different even from those two. The gentle introduction seems more like a brickbat to me, the best things I've found so far are homework assignments from various CS classes around the world. I've looked for a good irc channel dedicated to haskell, and not found one. I've also searched for a tutorial that works along the same lines as the Python tutorial, and not found one. I have lots of complete beginner questions... Also, it seems the Haskell Wiki has lost many pages again. Would it be possible to use MoinMoin instead of pyWiki? I looked at the "applications written in Haskell" links, but many of the links are dead. I have found some sample code by searching google, but I'd really like to find a library of small pieces of demo code showing the various idioms and useful basics. Does such a thing exist? Thanks, ---- Shae Matijs Erisson - http://www.webwitches.com/~shae/

2 1

Novice question
by Mark Carroll 23 Apr '01

23 Apr '01

Is this a good place for novice questions? I have just started to try to learn Haskell, and am using Hugs to start with. When I write the not-very-useful function, greaterthan 0 _ _ = False greaterthan _ (x:xs) (y:ys) = x > y and test it, Main> greaterthan 2 [3] [4] False Main> greaterthan 3 [4] [3] True Main> greaterthan 0 [4] [3] False Main> greaterthan 0 [] [] ERROR: Unresolved overloading *** Type : Ord a => Bool *** Expression : greaterthan 0 [] [] Main> ...I don't understand what the problem is. I'm guessing that the problem is with the use of > and it not knowing which 'version' of > to use, but it doesn't need to know because we're not matching with that line anyway. I hope that didn't sound quite as confused as I am. (-: Is there anything easy someone can say that will enlighten me as to why things are as they are? (I understand that Ord is a set of types and that you can probably only apply > to things that are in it, and that > is overloaded somehow.) Thanks. -- Mark

3 2

Re: Dimensional analysis with fundeps
by Ashley Yakeley 19 Apr '01

19 Apr '01

At 2001-04-09 10:29, Dylan Thurston wrote: >I hadn't thought about doing rational arithmetic with GCDs. Might be >nice. Herewith my attempt. I can't test it though, it runs afoul of one of the many bugs in Hugs' type-extension handling, and I haven't been able to run GHC on my MacOS X box. -- Ashley Yakeley, Seattle WA

1 0

Re: Dimensional analysis with fundeps (some physics comments)
by Ashley Yakeley 11 Apr '01

11 Apr '01

I'm cross-posting this to the Libraries list... At 2001-04-10 18:02, Fergus Henderson wrote: >Still, the need to insert explicit `toUnits' is >annoying, and it would be nice to have a system where every number was >already a dimensionless unit. That's easy: -- type Unit rep = Dimensioned Zero Zero Zero rep; instance (Real a) => Real (Unit a) where { -- put instances here }; -- Of course you'll have to appropriately declare superclasses of Real, such as Num, Ord, Show, Eq etc. -- Ashley Yakeley, Seattle WA

3 2

Re: Dimensional analysis with fundeps (some physics comments)
by Ashley Yakeley 11 Apr '01

11 Apr '01

At 2001-04-10 18:16, I wrote: >That's easy: > >-- >type Unit rep = Dimensioned Zero Zero Zero rep; > >instance (Real a) => Real (Unit a) where > { > -- put instances here > }; >-- > >Of course you'll have to appropriately declare superclasses of Real, such >as Num, Ord, Show, Eq etc. I've put this together in the enclosed files (same as previously posted to the libraries list), which derive from anatoli's work. -- Ashley Yakeley, Seattle WA

1 0

Re: Dimensional analysis with fundeps (some physics comments)
by Ashley Yakeley 11 Apr '01

11 Apr '01

At 2001-05-01 18:28, Terrence Brannon wrote: >"has Ashley >shown in her example a means of automating a toUnits imperative in >Haskell that must be done explicitly in Mercury?" ...his... -- Ashley Yakeley, Seattle WA

1 0

Re: Dimensional analysis with fundeps (some physics comments)
by Jerzy Karczmarczuk 11 Apr '01

11 Apr '01

[[MOVED FROM haskell TO haskell-cafe]] Nothing to do with Haskell. Pure computer scientists, not interested in physics might not find anything in this posting. Tom Pledger wrote: //about dimensions, units...// > If you clearly make the type system deal with dimensions rather than > units, there's no problem with plugging in multiple unit systems. You > just have to pick a scale for the representation. > > newtype Dimensioned mass length time rep = Dimensioned rep > > type Mass rep = Dimensioned One Zero Zero rep > > kg, lb :: Num a => Mass a > kg = dm 1 > lb = dm 0.4535924 > > Angles are dimensionless. (Think of the Taylor series for trig > functions.) > > radian, degree :: Unit > radian = dm 1 > degree = dm (pi/180) The distinction between dimensions and units may seem for some of you utterly trivial. Mass is a mass, kg -> lb, etc. are just conversion factors. Angles are dimensionless. It was not so trivial for the authors of SI, and for some speculative physicists, who are not all dead yet. The problem is: what is a *fundamental*, *universal* constant? You see, those constants establish our unit systems! Many, really many among my friends don't hesitate to work in a frame where the speed of light is equal to 1. Yes, ONE, dimensionless. Then, passing from length to time is just a unit conversion, and all velocities are dimensionless. (Like, say, steradians in SI?...) Who needs candelas? Who needs Amperes What is the dimension of a mole? (In SI it is an independent unit) Who needs Kelvins? Everybody (within a particular mafia I happen to know) knows very well that the temperature is/should be measured in energy units, i.e., the Boltzmann constant k is equal to 1, dimensionless. Now, even if you won't (probably) find people who would claim that the status of k or c is the same as PI/180, the question "what is a unit" has no unambiguous and non-conventional answer. You may put the universal gravitational constant to 1. Or simply put to 1 the Plankeon mass, and get rid of all the mass "dimensional units". == And if you leave the world of classical physics, and start to analyze the structure of quantum theories you may get some nasty surprises. //Now I have to trivialize a bit// (First, most people who do some calculations in QM put the Planck constant equal to 1, so the energy is inverse time...) Some quantities which should - for geometric reasons - have fixed dimensions, such as the "force" of a field respecting Laplace equation: ~1/r^2 (Newton, Coulomb), get what is called the "anomalous dimension", instead of 2 one has to play with r^(2+x), with x fractional (some people, I suppose that Andrew Kennedy is one of them, don't like such things...). Now, if something which should be - classically - dimensionless, say p^0 acquires this anomaloud dimension p^x, then the only computationally sane way of dealing with it is to introduce a new "universal" (?) dimensional constant q, such that the expression above may be written as (p/q)^x in appropriate units of p and q. Then, no x may do any harm. This phenomenon, the "dimensional transmutation" suggests that it is not clear which is the set of universal dimensional quantities in quantum world. == I like all papers about dimensions, and it is very refreshing to see how people squeeze them into the type systems. (Or play with geometrical "navigation" in a dimensional world: http://mail.collegestudent.com/gda01/GDA01.HTM http://physics.nist.gov/cuu/Units/SIdiagram.html ) I believe, however, that one should not forget that all that is *conventional*. Jerzy Karczmarczuk Caen, France

2 1

What do you think about Mercury?
by Terrence Brannon 10 Apr '01

10 Apr '01

I have decided to escape the world of Perl into something more definitional. I gave up on CAML and Erlang because they contain imperative elements and I am tired of that form of coding. So, I have narrowed it down to Haskell and Mercury. The attractive things about Haskell are: - automatic generation of concurrent programs from normal source... instead of sending msgs to processes like in Erlang. - large user base - possible real job in industry (with Galois Connections). - several books based on it - binaries available (even for my mac os x box already!). So, with that said, http://www.cs.mu.oz.au/research/mercury/information/comparison_with_haskell… lists a number of advantages of Mercury over Haskell. And both Haskell and Mercury did well in the ICFP. Does anyone have anything to say about these criticisms? There were two particular things in the list that caught my attention: 1- Haskell is a pure functional language, but I don't see any support for backtracking or other logic features... but my guess is you have some way of handling this? How? 2- Mercury's mode system provides support for subtypes. For example, you can declare that a function whose argument is a discriminated union type accepts only a subset of the possible constructors for that type, and the mode system will enforce this.

7 8

Re: Question about typing
by Yoann Padioleau 10 Apr '01

10 Apr '01

Matt Harden <matth(a)mindspring.com> writes: > > zip :: ZipFunctor f => f a -> f b -> f (a,b) > zip = zipWith (,) > zip3 :: ZipFunctor f => f a -> f b -> f c -> f (a,b,c) > zip3 = zipWith3 (,,) > > One can easily create ZipFunctor instances for trees and other data > structures. I can provide examples if you like. With multiple > parameter type classes (MPTCs, they are not in Haskell 98) as well as > functional dependencies (also not in h98), one can also create a > "Zippable" class to generalize the zip function over multiple tuple > types and eliminate zip3, zip4, etc. can you explain how you do that ?? (i dont know what is functional dependencies, but i think i understand multiple parameter type classes and i dont see how do make something that avoid to define a zip3 zip4 ....

2 1

Question about typing
by Toby Watson 09 Apr '01

09 Apr '01

Intuitively the following scenarios seem to be related, can anyone point my in the direction of formal work on this, or give me the formal terms I need to search around? 1. Adding two integers together: Int -> Int -> Int 2. Adding two lists of Integers together: [Int] -> [Int] -> [Int] 3. Adding two lazy streams of integers together, possibly in seperate (parallel) processes for example. cheers, Toby

8 9

Visual Haskell
by Jason J. Libsch 06 Apr '01

06 Apr '01

I recently ran across a paper, Visual Haskell- a First Attempt, and was tremendously impressed. Has anybody here played with this language or read the paper? I would be interested to hear other's opinion on such a language. http://ptolemy.eecs.berkeley.edu/~johnr/papers/visual.html /jason

6 6

Re: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
by Dejan Jelovic 04 Apr '01

04 Apr '01

Jerzy Karczmarczuk wrote: > Over and over again the same silly song, by a person who - visibly - > had never anything to do with functional languages, who thinks now > about hiring some C and java programmers living in Belgrade I don't understand how you deduced I "never had anything to do with functional languages"? Any how is it relevant to the subject at hand that I'm hiring Java and C++ (not C) programmers in Belgrade? > but who > writes such silly, incompetent things as: > > > And there is an air of staleness: where new versions of these other > > languages appear frequently, the Haskell community is offering you > > Hugs98. I don't see why what I said is silly or incompetent? The Haskell Compiler and Interpreters page at haskell.org suggests Hugs98 for newcomers. While you and I know that the latest version of Hugs has been released two weeks ago, a curious visitor will wonder why there isn't Hugs 2001. And the Haskell website is updated rarely in contrast with, say, the Python website. > Delovic points out that some languages became "immensely" popular, > as e.g. Ruby, and that Haskell is marginal. Hm. this extremely > orthodox Japanese essence of O-O programming may have some practical > merits, especially those which come from shameless borrowing from > Eiffel, Sather, Clu and Common Lisp, but calling Haskell "marginal" > or "obscure" informs us not what is Haskell, but who is Jelovic. Compared to the usage of C++, Java or Python, the usage of Haskell is _marginal_. Visit the computer section of your local bookstore if you need to be reminded of that. BTW, you seem to be well-informed about who this Jelovic is. Why don't you share that knowledge with us? :) > He accuses the Haskell community of not providing libraries... Two errors here: 1. I didn't accuse anybody of anything. I was just curious about why people aren't using Haskell and started to think about it. There's a saying among Program Managers at Microsoft that "thinking is writing". I subscribe to that. I often write about things I think about in order to explore the issues. If I think other people might be interested in the end result, I post it. 2. I didn't say that the Haskell community has not provided the libraries. I said the Haskell community hasn't provided the libraries together with the compiler in one standard distribution. I think that's needed in order to lower the barrier to entry. > Perhaps there is *one* point worth mentioning: the necessity to > publish papers about Haskell far from such journals as JFP or HOSC, > but to try to reach DrDobbs etc. Funny. You said at the beginning of your message that there is "NOTHING" serious there. :) Dejan http://www.jelovic.com

6 8

Re: "Lambda Dance", Haskell polemic,... (Jerzy Karczmarczuk)
by Dejan Jelovic 03 Apr '01

03 Apr '01

Jerzy Karczmarczuk wrote: > 1. I didn't find ANYTHING about FP on your pages, > only that accusations. I already explained that was not an accusation. How does it follow that since there's nothing else about FP on my website that I "never had anything to do with functional languages"? Do you really think that the 10 pages or so on my website describe the composite of everything I ever did? > 2. I don't remember any of your eventual contribution to discussion > lists, newsgroups, etc. I might be wrong. Please give some references, > publications, functional software, etc. I will apologize then > immediately, with regret, but also with satisfaction that the Truth won. I have never before posted anything on FP to any list or newsgroups. In fact I subscribed to this list only when I saw your message in the list archives. But that's irrelevant. Do you think that everybody that has ever used a functional laguage has contributed to discussion lists and newsgroups? > 3. Personally you don't care about Haskell. Your page *explicitly* > discourages local people from touching functional languages, the > category of people you want to hire is a very strong signal. > A potential employer who does what you did serves the devil, don't > try to suggest that this isn't relevant. Nonsense. I'm hiring C++ and Java programmers because I need help with the C++ and Java projects I do. I don't see how that would discourage anybody from learning about other languages? And why would you assume that I personally don't care about Haskell? You seem to be piling these assumptions about me at random. > 1. Saying that the Haskell community offers Hugs98, and not > mentioning neither GHC, nor NHC is either incompetent or > provocative. Hugs is the distribution that's suggested to newcommers. It didn't seem relevant to talk about other distributions if we are talking about people migrating to Haskell. > 2. A decent programming language *must* be stable. If the main > criterion of the "quality" you attribute to programming languages > is the speed of its modifications, I wonder what don't you accuse > of staleness your favourite languages: Java and C++. Again, wrong assumptions. Neither C++ nor Java are not my favourite language. I don't have a favourite language. The fact that Java has not grown for a number of years is a horror. The language lacks support for types with value semantics, generic types and other useful facilities. Those have all been proposed but Sun has not moved to implement them. C++ is more expressive. The only addition I can think of right now that would be worth the added complexity would be Java-like inner classes and anonymous classes and functions. I was actually contemplating writing about the above things. But it just so happened that I wrote about Haskell first. I don't understand why the order in which I write things is bothering you? Or did you expect to come and find a complete 200-page analysis of all popular programming languages? But again, this is irrelevant. I was not talking about the language. In fact I said that Haskell is superior to Python, Perl and Ruby at the very beginning of my article. But the Haskell website and the _distributions_ seem to be moving at a slower pace. > Hugs 2001???? Are you sure that you really know what does it mean > a STANDARD? Yes. Haskell 98 is a standard. Hugs is a product. It doesn't have to be called Hugs 98. It can be called Hugs 2001, Hugs XP, Hugs ME, Visual Hugs :) or any other attractive name. Anybody programming in Haskell will benefit from other users migrating to it. More users means more vendors and more libraries. Perception is one of the factors that influences the number of users. Commercial world knows this. Microsoft incremented the version of Word from 2.0 to 6.0 in order to avoid having Word perceived as less mature than WordPerfect. The incremented the Visual C++ version from 2.0 to 4.0 in order to match Borland C++. Sun called Java 1.2 "Java 2". Etc. The examples above are extreme and, IMO, slightly dishonest. I just brought them up to illustrate the point vividly. Calling the Hugs February 2001 distribution "Hugs 2001" is not dishonest, it's just good marketing. > 1. Oh yes. Thousands of books about Ruby. Actually one, in Japanese. > Have you looked here: > http://www.haskell.org/bookshelf/ > This is comparable with Python. Of course, Python IS more popular, > but - - I included Ruby in the trio because it fits the scripting language phenomenon. Python is the one to compare against due to similar starting positions. Go to a bookstore. The fact that many books on Haskell have been published doesn't mean that many people are buying them. The bookstores I visit in the States have a number of books on Perl and Python. If they carry books on Haskell at all that's usually one title hidden somewhere on the shelf. Also, it is a known fact that books on specific products ("Teach Yourself Visual C++ in 21 Days") greatly outsell books on programming languages ("The C++ Programming Language"). Guess of which kind are Haskell books? > 2. You neglect, and I suspect that you do it on purpose, that the main > driving force behind the evolution of Haskell is *RESEARCH*. An issue > absent from many "popular" languages which are meant to be > immediately exploitable with very flat learning curve. Flat learning curve is ideal. Since that's not possible, the smallest possible barrier to entry is the next best thing. Why does that bother you? >The documentation on line is sufficiently good that e.g. - > my students won't even think about going and trying to buy a book. No doubt. Ditto for Python and Java. But that's besides the point. If Haskell was more popular the publishing industry would be on the bandwagon. No? Remember, I brought up the number of books sold as a way to gauge the popularity of Haskell in relation to Python. > Still, there are more publications on FP every month that I can > digest. What about Python? Java? Do you have _any_ idea what the average programmer is reading these days? _Nothing_. Not one trade publication, not one book. (See "Rapid Development" for statistics on this.) DDJ is probably one of the most popular trade magazines. Its circulation is 155,000. What percentage of the working programmers is that? How big is the membership in IEEE or ACM? How many practicing programmers read IEEE Software, let alone any of the Journals? All those publications on FP are _not_ reaching the average programmer. > > BTW, you seem to be well-informed about who this Jelovic is. Why don't you > > share that knowledge with us? :) > > Oh, but I did. > You seem to be a self-appointed specialist on functional languages, who > expresses in public some very dubious truths, which I find harmful. I never said I was a specialist. Do only specialists get a voice? > > 1. I didn't accuse anybody of anything. I was just curious about why people > > aren't using Haskell and started to think about it. > > I understood this in such a way. You seem to be the only one. On this list and off. Doesn't this tell you anything? > You are explicitly negative in your *judgement*. I said that the language is good, but that the distributions are not good enough to facilliate widespead use. A number of people on this list agreed. Why is this giving you an ulcer? > There are hundreds of libraries of Java classes and C++ classes > and procedures which are distributed separately. The "standard" > GNU distribution of C++ is quite limited, there is no point in > overloading the standard environment by things whose usage > is limited. The ease of installation is also important. The standard Java library is actually quite comprehensive. I'd go so far to say that it's one of the main reasons why Java has spread so quickly. The standard C++ library is too small. That's a problem with C++. But the language spread before GUIs and before the Web when people required less. If Haskell is to have a chance its distribution(s) must have a comprehensive library. > BTW. the GHC "standard" distribution has an adequate amount of runtime > support for normal tasks. It worked for me without any problem. You underestimate the value of a large community and lots of vendors. In my last project I had to manipulate some graphic files in various formats. For C++ and Java I had turnkey solutions. (Java being better as it has a standard Image class while for C++ no standard exists.) The closest thing I found for Haskell is a GD wrapper with limited functionality. > RRight. I found one point worth mentioning. Wonderful, splendid, and > original. Hereby I declare that you are the winner of this discussion, > and I am the loser. Relax. I was just nitpicking in order to get a rise out of you. So far you have used "silly", "incompetent", "accuse", "Truth", "serve the devil", "moral", "nasty", "dubious" and "harmful". Funny how people are eager to use such qualifications over the Internet but avoid saying them when they have to look the other person in the eyes, don't you think? You also didn't have the common courtesy and courage to CC: me on your initial posting to this list. Dejan http://www.jelovic.com

1 0

RE: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
by Julian Seward (Intl Vendor) 02 Apr '01

02 Apr '01

S. Alexander Jacobsen wrote: | Although I think Haskell is a beautiful language, Jelovic is right on his | core points, Haskell implementations don't meet the needs of | the working programmer. [...] I also largely agree with Jelovic, and I take what he says as constructive criticism. One observation at least as regards Perl and Python is that Haskell has a very much more academically-intense heritage, whereas Perl and (guessing here) Python were motivated more by end-user need. GHC and Hugs suffer from tensions between being research vehicles and being practical implementations suitable for end-users. I'd guess that Perl and Python don't suffer from such tensions, so their implementors can concentrate more directly on providing excellent implementations suitable for widespread use. I say nothing about Ruby because I know nothing about it. A second observation is that Perl and Python are both single -implementation languages, which makes it easier to have a coherent set of libraries. Haskell, by contrast, isn't -- there are at least 4 available implementations (hbc, hugs, nhc, ghc). The core language (Haskell98) is supported by all of these, but there isn't a coherent story on the libraries. We are working on that. This plurality of implementations has worked well for the diverse research interests centered around Haskell. I think there is now a growing feeling that we need to standardise the libraries more and put more emphasis on end-user issues -- the kind of things Jelovic mentions -- if Haskell is to have a long-term future. Here at GHC HQ we are trying hard to make GHC into a suitable vehicle for widespread use. The upcoming GHC version 5 should go some way to addressing issues of installability, library coverage and speed of compilation. As Simon Marlow pointed out, if you feel motivated to help us work on the libraries, that would be excellent. I think it's worth clarifying a couple of potential misunderstandings with the original posting: -- The current version of Hugs is called hugs98 not because the implementation was last revised in 1998 but because it implements the language as standardised in 1998. Hugs is actively maintained. -- Hugs is not the only Haskell implementation. Ours, GHC, strives hard to provide a coherent, complete set of libraries in the standard distribution. NHC is also moving in that direction. We are not yet there, but are, at least, proceeding. J

3 2

Re: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
by Bill Halchin 01 Apr '01

01 Apr '01

Hello, I think Dejan has written in a good spirit and has many cogent points, especially for example with regard to Python. I guess the bottom line is don't be too think-skinned about what seems to me to be constructive criticism. In the FPL community, it is easy to maintain a siege mentality. Before I worked at Microsoft Hotmail. I asked one person (well known) who does research at Microsoft Research on Haskell. I asked him if any projects inside Microsoft were implemented using Haskell and he said no. Of course, this is not his fault. Management has to see that they are not going "out on a limb" to use FPLs. I know that Sun wrote at least one tool in Scheme (albeit it doesn't have ref. transparency). Regards, Bill Halchin >From: "Dejan Jelovic" <djelovic(a)sezampro.yu> >To: <haskell-cafe(a)haskell.org> >CC: <karczma(a)info.unicaen.fr> >Subject: Re: "Lambda Dance", Haskell polemic, etc. on O'Reilly site >Date: Sun, 1 Apr 2001 22:02:29 +0200 > >Jerzy Karczmarczuk wrote: > > > Over and over again the same silly song, by a person who - visibly - > > had never anything to do with functional languages, who thinks now > > about hiring some C and java programmers living in Belgrade > >I don't understand how you deduced I "never had anything to do with >functional languages"? Any how is it relevant to the subject at hand that >I'm hiring Java and C++ (not C) programmers in Belgrade? > > > but who > > writes such silly, incompetent things as: > > > > > And there is an air of staleness: where new versions of these other > > > languages appear frequently, the Haskell community is offering you > > > Hugs98. > >I don't see why what I said is silly or incompetent? The Haskell Compiler >and Interpreters page at haskell.org suggests Hugs98 for newcomers. While >you and I know that the latest version of Hugs has been released two weeks >ago, a curious visitor will wonder why there isn't Hugs 2001. > >And the Haskell website is updated rarely in contrast with, say, the Python >website. > > > Delovic points out that some languages became "immensely" popular, > > as e.g. Ruby, and that Haskell is marginal. Hm. this extremely > > orthodox Japanese essence of O-O programming may have some practical > > merits, especially those which come from shameless borrowing from > > Eiffel, Sather, Clu and Common Lisp, but calling Haskell "marginal" > > or "obscure" informs us not what is Haskell, but who is Jelovic. > >Compared to the usage of C++, Java or Python, the usage of Haskell is >_marginal_. Visit the computer section of your local bookstore if you need >to be reminded of that. > >BTW, you seem to be well-informed about who this Jelovic is. Why don't you >share that knowledge with us? :) > > > He accuses the Haskell community of not providing libraries... > >Two errors here: > >1. I didn't accuse anybody of anything. I was just curious about why people >aren't using Haskell and started to think about it. There's a saying among >Program Managers at Microsoft that "thinking is writing". I subscribe to >that. I often write about things I think about in order to explore the >issues. If I think other people might be interested in the end result, I >post it. > >2. I didn't say that the Haskell community has not provided the libraries. >I >said the Haskell community hasn't provided the libraries together with the >compiler in one standard distribution. I think that's needed in order to >lower the barrier to entry. > > > Perhaps there is *one* point worth mentioning: the necessity to > > publish papers about Haskell far from such journals as JFP or HOSC, > > but to try to reach DrDobbs etc. > >Funny. You said at the beginning of your message that there is "NOTHING" >serious there. :) > >Dejan >http://www.jelovic.com > > > >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

Re: constants and functions without arguments
by Tom Pledger 31 Mar '01

31 Mar '01

Andreas Leitner writes: : | The classic examlple for this is class POINT, which has an interface | like that: | -- | POINT | -- group 1 | x: DOUBLE | y: DOUBLE | -- group 2 | rho: DOUBLE | abs: DOUBLE | -- | Now, you can choose to either implement group 1 as attributes, or | group 2 and calculate the other one. With the uniform access | principle, which says that accessing attributes and functions with no | arguments happen in the same syntactic way, you can change the | implementaion without notice. No user of this class needs to know. | | I am to new to FP to say whether this is equaly important in | FP-languages, since the semantics are different (constants vs. | attributes and immutable values vs. objects), but for now I am just | currious wether it is possible theoretically. That uniformity of access can certainly be achieved in Haskell. Here's the Point example. I've done it with two constructors so as to get fewer floating point imprecisions, but some other possible representations (e.g. one with only the Polar constructor) would look identical outside the module. module Point(Point, cartesian, polar, x, y, r, theta) where -- data type with hidden constructors data Point = Cartesian Double Double -- corresponds to group 1 | Polar Double Double -- corresponds to group 2 -- proxy constructor functions cartesian x y = Cartesian x y polar r theta = Polar r theta -- attribute extraction functions x (Cartesian x y) = x x (Polar r theta) = r * cos theta y (Cartesian x y) = y y (Polar r theta) = r * sin theta r (Cartesian x y) = sqrt (x*x + y*y) r (Polar r theta) = r theta (Cartesian x y) = atan2 y x theta (Polar r theta) = theta

1 0

Instances of Read and Show
by Ingo Sander 30 Mar '01

30 Mar '01

I have a question concerning the Read and Show classes. I have read the Haskell 98 report (section 6.3.3 The Read and Show Classes), but I still do not figure out how to make instances. I have a simple data type: data TVal a = Abst | Prst a I managed to define the function show, so that I can use it with the data type TVal instance (Show a) => Show (TVal a) where show Abst = "_" show (Prst x) = show x Signals> [Prst 1, Abst, Prst 2] [1,_,2] :: [TVal Integer] which is what I want to have. But how do I make a Read instance? I still do not understand the meaning of 'readsPrec' and 'readList' (and not of 'showPrec' and 'showList') either. Can somebody explain to me or give me a good reference so that I can make TVal an instance of the classes Read and Show. Thanks in advance for your help! Ingo Sander

2 1

RE: "Lambda Dance", Haskell polemic, etc. on O'Reilly site
by Simon Marlow 30 Mar '01

30 Mar '01

> There are, perhaps good reasons for all these failures, but please > recognize them for what they are: failures to meet the needs of the > working programmer who just wants to get something done > (whether he/she > lives in YU, FR, JP, or US) > > I would love to be using Haskell for day to day programming work but I > can't at this time. Unless the community recognizes what is > required and > gets it done, I never will. There is one good reason that Haskell fails in these areas, and that's shortage of effort. We in the GHC team are actively trying to encourage our users to contribute: with an open CVS source tree, open development mailing lists, etc. We've had some good results (thanks to our developers!), but we need more. GHC is a large and complex system, and with trying to be all things to all people - a research vehicle / experimentation platform / production compiler, our developer resources are stretched a bit thin. I'm sure this goes for the other Haskell systems too. I see libraries as the biggest missing piece in the Haskell language. Let's face it, Joe Programmer isn't going to pass Haskell by just because it doesn't support a particular flavour of overlapping instance declarations. But he might if it doesn't have a networking library, or unicode support, or an XML parser. Please, join libraries(a)haskell.org. </rant> Cheers, Simon

1 0

"Lambda Dance", Haskell polemic, etc. on O'Reilly site
by Fritz K Ruehr 30 Mar '01

30 Mar '01

Forgive me if the following links were announced here and I just missed them. I found them through the O'Reilley Meerkat "Open Wire Service", in the "Lambda" channel of the "Lang" category (see: <http://www.oreillynet.com/meerkat/index.php?&c=4623&t=ALL> ). The first link is the "Lambda Dance" page, presumably inspired by the infamous "Hamster Dance" (if you don't know the latter, you are better off for it, so don't ask): <http://lambdadance.spacebar.org/> "Beta-reduce the night away", as the site says! The second link is a little polemic entitled "Why People Aren't Using Haskell", which I presume would be of interest to readers of this list (the author is Dejan Jelovic, whom I don't recognize as a regular contributor here): <http://www.jelovic.com/articles/why_people_arent_using_haskell.htm> There are several other interesting looking links on the Meerkat site ("Moving FP from Academia", "Object Functional Patterns", etc.), but I will let you investigate on your own. Enjoy ... -- Fritz Ruehr, still humming to the lambda dance

3 2

Printed Haskell 98 Report
by Mark Carroll 29 Mar '01

29 Mar '01

I don't suppose it's possible to get a reasonable printed copy of the Haskell 98 Report and Haskell 98 Library Report at a sensible price, is it? Just wondering, before I go pricing printing and binding. Thanks. -- Mark

2 1

(no subject)
by Atenea Azcue 28 Mar '01

28 Mar '01

Hello My name is Atenea . I just want to ask you that how can i Creat a program that just say "hello word" and another that can add a "matrix" if you can help me I would really going to apreciate please. Thank you for your listening --------------------------------- Do You Yahoo!? Yahoo! Mail Personal Address - Get email at your own domain with Yahoo! Mail.

2 1