[dundee] Tiling Window Managers.... XMonad anyone?

Rick Moynihan rick.moynihan at gmail.com
Thu Jul 9 21:38:00 UTC 2009


2009/7/9 Iain Barnett <iainspeed at gmail.com>:
>
> 2009/7/8 Rick Moynihan <rick.moynihan at gmail.com>
>>
>> In theoretical i.e. mathematical terms I think you're absoloutely
>> right, but in practice evaluation order *is* important and needs to be
>> tightly controlled.  This I think is one reason for your conflation of
>> declarative and functional programming styles.
>
> 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.

I don't think it's splitting hairs at all...  I'd also argue that
declarative languages like XSLT and SQL, which though similar to
functional languages aren't because they don't have a representation
of functions are as a first class data type.

Whilst the features that you list are features commonly found in
functional languages, the core property that is to my knowledge common
to all (accepted) functional languages is that functions can
themselves be treated as values.

> 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 :)

Yes, and there are countless others....  For example what about markup
languages like HTML or CSS, they're clearly declarative and CSS is
certainly domain specific, but what properties (other than being
side-effect free) does it share with functional languages?

> 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.

As I've said before I think they both frequently share a lot of common
ground and I'd concede that functional programs almost always
(depending upon purity etc...) have a declarative interpretation, but
the fact that the reverse isn't always true (for me anyway) means that
it's worth maintaining the distinction....

Interesting conversation!

R.



More information about the dundee mailing list