[Haskell-cafe] Wow Monads!
migmit at gmail.com
Wed Apr 19 05:05:20 UTC 2017
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.
Az iPademről küldve
2017. ápr. 19. dátummal, 6:24 időpontban Richard A. O'Keefe <ok at cs.otago.ac.nz> írta:
>> On 19/04/2017, at 3:13 PM, Atrudyjane via Haskell-Cafe <haskell-cafe at 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 used
> macros 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 and
> LemurCoSprockets and such all over the place and I haven't a clue. Total
> bewilderment. Heck, show me *undocumented* code in a language without
> macros, classes, or higher-order functions (Fortran 95? COBOL 85?) and I'll
> be just as baffled, if it is big enough. (I've been staring at some old
> numeric code recently. One page is quite big enough...)
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe