www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Full closures for D

reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Nathan Reed Wrote:

 Bruce Adams wrote:
 Since they're on the language comparison feature chat it implies (to me at
least) that there is some perceived benefit to the concept.
 Any poor strictly functional guys care to explain what it is?
 

Here's a good introduction to monads in the context of Haskell: http://research.microsoft.com/%7Esimonpj/Papers/marktoberdorf/mark.pdf Basically, a monad is a type whose values represent actions. An action is something that, when done, has an effect on some global state and then possibly returns a value. There are operators that allow actions to be composed in various ways. So, in a pure functional programming language, you never actually *do* anything imperatively - you just construct a huge action, which contains everything your program should do, by gluing together lots of itty-bitty actions (and pure functions). The construction of this action is done purely-fuctionally. Then the runtime executes the action, but this occurs outside of the language proper, so it doesn't hurt your beautiful clean pure-functionality. Thanks, Nathan Reed

But could there be any benefit to a 'non functional' language like D. I just read a paper demonstrating how continuations can be viewed as a special case/use of monads for example. Or perhaps in lazy evaluation of complex expressions?
Nov 06 2007
parent Mikola Lysenko <mclysenk mtu.edu> writes:
Bruce Adams Wrote:

 Nathan Reed Wrote:
 
 Bruce Adams wrote:
 Since they're on the language comparison feature chat it implies (to me at
least) that there is some perceived benefit to the concept.
 Any poor strictly functional guys care to explain what it is?
 


But could there be any benefit to a 'non functional' language like D.

I'm inclined to agree with Bruce. My opinion is that for C-style languages, monads are just a bunch of category-theoretic red tape. The primary function of monadic types is to induce ordering and side-effects within the evaluation of functional programs. D already has a well defined order for executing statements, so adding support for monads seems redundant in a most painful way. Monadic type modifiers are also inscrutably arcane. Nothing is going to scare off newbies more easily than several pages of incomprehensible mathematical text describing how to print a line of text to the console (see: Haskell). -Mik
Nov 06 2007