[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: functional languages ill-suited for large programs?

On 31. Okt 2003, at 21:21, Jan-Willem Maessen wrote:

> Vadim Nasardinov <el-vadimo@comcast.net> writes:
>> That's what Peter Van Roy is claiming, if I read him right.  In
>> http://lambda.weblogs.com/2003/10/22#a9361, he writes
>>     In our experience, true state (destructively assignable entities)
>>     is essential for reasons of program modularity (which for this
>>     discussion I take as meaning: the ability to change one part of a
>>     program in a significant way without changing the rest of the
>>     program). Threaded state, e.g., monads as used by Haskell or DCGs
>>     as used by Prolog, cannot substitute for it.
> This is actually a fair critique of Haskell.  You have a choice: write
> programs in the beautiful, purely-functional part of the language (in
> which case you have to use unstable but widely-known hacks to hide
> certain sorts of side effects), or write programs in the much clunkier
> monadic sublanguage, where you need to name all your subexpressions,
> the order of evaluation is fixed, and you can use as many side effects
> as you like.
> It's a problem.  Another problem is that you end up writing at least
> two versions of higher-order library functions---the monadic version
> and the non-monadic version.  There are Haskellers who are deeply
> uncomfortable with this and are trying to come up with clever ways to
> fix it [I've tinkered a bit here with moderately encouraging results].
> I can't think of a non-Haskell-like functional language where this
> criticism applies (I can't comment on Prolog et al).  Most
> "functional" languages I know about incorporate unrestricted side
> effects of some sort.

I have heard claims that Clean handles these things more nicely. The 
concept of "uniqueness typing" sounds relatively useful, but how does 
this work out in practice? Can anyone comment on this?

See http://www.cs.kun.nl/~clean/