2009/7/9 Rick Moynihan <span dir="ltr"><<a href="mailto:rick.moynihan@gmail.com">rick.moynihan@gmail.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I don't think it's splitting hairs at all... I'd also argue that<br>
declarative languages like XSLT and SQL, which though similar to<br>
functional languages aren't because they don't have a representation<br>
of functions are as a first class data type.<br>
<br>
Whilst the features that you list are features commonly found in<br>
functional languages, the core property that is to my knowledge common<br>
to all (accepted) functional languages is that functions can<br>
themselves be treated as values.</blockquote><div><br>Perl has that feature (almost all the FP features, in fact) but
wouldn't be considered an FP language by most. I think the most important feature is the aim for lack of side effects by keeping most functions pure.<br><br>If a function is pure
then it could be passed around because it has become a declaration, and
therefore just data, but I don't see that it's necessary for the
language, just a likely by-product.<br></div><div><br>C#, for instance, also has delegates (which they keep changing the syntax to, annoyingly for my brain) but it's definitely not FP, more of a convenient extension. Even LINQ, which is definitely functional, is just used as a convenient form of abstracting data - the new embedded SQL statement!<br>
<br>Though they do share the most important feature (by my reckoning), I'm not sure CSS and HTML should count as anything other than a representation of data as they can't be "run". But then, isn't that what a well written functional program (or at least function) is aiming for? Like a dispatch table, for instance.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 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>
<div class="im">
<br>
</div>As I've said before I think they both frequently share a lot of common<br>
ground and I'd concede that functional programs almost always<br>
(depending upon purity etc...) have a declarative interpretation, but<br>
the fact that the reverse isn't always true (for me anyway) means that<br>
it's worth maintaining the distinction....<br>
<br>
Interesting conversation!<br>
<div><div></div><div class="h5"><br>
R.</div></div></blockquote></div><br>In the end, I do think you were right to pull me up on it, but it is interesting to argue the toss. It's made me realise that it is better to aim for a declarative style in all languages than a functional one, as going declarative takes care of everything! :) <br>
<br>Iain<br><br><br>