- Haskell-Cafe - Haskell.org

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