I think the problem with macros in general is that their semantics is defined purely in terms of code they generate. Not in terms of what that code actually does. As for me, I want to think about the things I need to achieve, not about the code to write.
2017. ápr. 19. dátummal, 6:24 időpontban Richard A. O'Keefe <
ok@cs.otago.ac.nz> írta:
On 19/04/2017, at 3:13 PM, Atrudyjane via Haskell-Cafe <haskell-cafe@haskell.org> wrote:
I used to, mainly C/C++. There is no "I" in team... Our personalities must be similar : )
It's hidden, but there is definitely "a me" in "team".And then it's time for "T". (Obscure Lisp reference.)Someone wrote:
I think Lisp-style macros are too powerful.
It's true that higher-order functions can do a lot of the things people usedmacros to do, and better.However, having said "Lisp-style macros", Lisp is a tree with many branches.How about Scheme-style macros?Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does.
This is also true in Haskell. Show me a piece of code golf with Arrows andLemurCoSprockets and such all over the place and I haven't a clue. Totalbewilderment. Heck, show me *undocumented* code in a language withoutmacros, classes, or higher-order functions (Fortran 95? COBOL 85?) and I'llbe just as baffled, if it is big enough. (I've been staring at some oldnumeric code recently. One page is quite big enough...)_______________________________________________Haskell-Cafe mailing listTo (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafeOnly members subscribed via the mailman list are allowed to post.
