- Haskell-Cafe - Haskell.org

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 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