<br><br><div class="gmail_quote">2009/7/8 Rick Moynihan <span dir="ltr"><<a href="mailto:rick.moynihan@gmail.com">rick.moynihan@gmail.com</a>></span><br><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="h5">In theoretical i.e. mathematical terms I think you're absoloutely<br></div>
right, but in practice evaluation order *is* important and needs to be<br>
tightly controlled. This I think is one reason for your conflation of<br>
declarative and functional programming styles.</blockquote><div><br>Well, thinking about it and looking into it I can see that it is a conflation, since if it's FP it's declarative, but declarative doesn't always mean FP. Though really, in practice, that is splitting hairs. If it's domain specific and declarative, it will usually hold many aspects of FP, to the point where you could argue that they just aren't feature-full FP (but so few languages hold all the features anyway). SQL is a perfect example of this. What actually makes SQL _not_ an FP language? It has the notion of pure/impure functions (and occasionally requires purity), recursion, and pattern matching. The standard may suggest immutable variables, I'm not sure, but the extensions most have implemented are a mixture.<br>
<br>The only big hole I can see in my conflation is logical style programming like Prolog, but I never use it, see it, or worry about it :) <br><br>2 sides of the same coin, that's the way I see it. But I doubt my perspective has anything to do with laziness, I see that as a feature not something I usually care about. Unless you're talking about my academic background. That would certainly lead to hazy definitions.<br>
<br>Iain<br><br></div></div>