axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Re: [fricas-devel] Re: [open-axiom-devel] [fricas-deve


From: Gabriel Dos Reis
Subject: [Axiom-developer] Re: [fricas-devel] Re: [open-axiom-devel] [fricas-devel] Re: [fricas-devel] Re: iterators and cartesian product.
Date: Wed, 31 Oct 2007 20:11:18 -0500 (CDT)

On Wed, 31 Oct 2007, Bill Page wrote:

| 
| On 10/31/07, Gabriel Dos Reis wrote:
| >
| > On Wed, 31 Oct 2007, Bill Page wrote:
| >
| > |                     I think the lack of mutability in functional
| > | languages like Haskell is one of the harder things to get used
| > | to but at the same time one of it's greatest strengths.
| >
| > Haskell has imperative skin -- check out `monad'.
| >
| 
| Yes, I think that is a very good point and it does soften my point
| above a little. "lack of mutability" is misleading. Mutable structures
| can be modeled in Haskell as a derived concept.  For example:
| 
| http://en.wikipedia.org/wiki/Monads_in_functional_programming
| 
| (See especially references at the end of the article.)
| 
| Using a purely functional language does not mean that imperative-style
| programming is impossible in that language.

Note however that some functional programming evangelists consider the
'monad' solution to the state problem as a `grotesques hack': If you
use a state in your function, all the callers will be infected.

| It might even be
| interesting to consider implementing something akin to monads in
| Aldor/SPAD,

There already existe a domain called Monad in the Axiom family -- it
is a well mathematically defined notion. 

I do not however see myself implement the Haskell solution for Axiom.
I would prefer a more powerful effect system for OpenAxiom.

| but I think you will agree that fundamentally these
| languages were not designed to be purely functional.

I do not see `purely functional' as as necessity.

-- Gaby




reply via email to

[Prev in Thread] Current Thread [Next in Thread]