- Haskell-Cafe - Haskell.org

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