Subject: Re: Side-effect freedom (Re: When transformation language) From: Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 19 May 1997 17:04:10 -0400 |
Vivek Agrawala wrote: > Also, could someone point me to a good discussion of the pros & cons of > freedom from side-effects? I am still struggling with problem of > writing > code without maintaining state. Maybe if you describe what you are having a problem with a side-effect ree solution could be suggested. I have only run across a few situations where side-effects would actually make solving a problem much more easy. Side-effect freedom makes things much easier to reason about. I think of all programming languages as living on a spectrum. Assembly language and languages that are higher level abstractions of it (e.g. C, C++) are built on top of the Turing-machine idea of computing: a bunch of squares and your job as a programmer is to fill them and remember what is in each square. Side-effect free languages build upon a mathematical formalism called the Lambda-calculus. They start with the idea that computing something can be done simply by doing a kind of string substitution or macro replacement. This is easier to reason about because the result of evaluating foo( a, b, c, d) is *always* the same if a, b, c, d is the same. foo( "a", "b", "c", "d") == foo( "a", "b", "c", "d" ) is always true in a functional language. But in a regular language you must think: "at what point is foo executing? What is the state of object Q, a global variable?" So lets say that you are debugging a functional language program, all that you have to know are the inputs and the value will be constant. You don't have to remember all of the state that may be hanging around. Just call the function with the values you want to test, check that the return code is right, and you are done. In C++ or something you can't really know if a situation is going to arise where some kind of bogus object-state is going to change the return value of the function call at some point in the future. See also: http://www.cs.nott.ac.uk/Department/Staff/gmh/faq.html http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html I don't want to get into a language war, because there are some things that are much easier to do and think about with traditional languages and some things that are easier to do with functional languages. I think that document processing is in the second category: there is an input, an output and the stylesheet is the mathematical function that maps one to the other. You can certainly think of many applications that do not fit this pattern of input-mapping-output and those are jobs I would usually use something like Perl or C++ for. Paul Prescod DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Side-effect freedom (Re: When trans, Vivek Agrawala | Thread | Re: When transformation language, James Clark |
question on mapping of character en, Kevin Desmarais | Date | Re: Characterstic Specification, Vivek Agrawala |
Month |