- Haskell-Cafe - Haskell.org

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

04 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