[Top][All Lists]

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

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

From: Bill Page
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 22:29:45 -0400

On 10/31/07, Gabriel Dos Reis wrote:
> On Wed, 31 Oct 2007, Bill Page wrote:
> | On 10/31/07, Gabriel Dos Reis wrote:
> | >
> | > On Wed, 31 Oct 2007, Bill Page wrote:
> | > ...
> | > | 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.
> | >
> |
> | Perhaps I am being dense but I do not see what this has to do with the
> | concept of Monad in Haskell.
> They are the same categorial notion.

That is not clear to me.

> What you have in Haskell is a computer scientist application of the
> categorial notion of `monad'.


> Haskell's take derive from Moggi's work on applying monads to defined
> program semantics.  See his seminal work.


> And it is also true that you don't need to understand category
> theory before using `monad's in Haskell.

I don't think that is extraordinary. One doesn't need to know much
about formal semantics of programming languages in general before
starting to program. And more relevant to this thread: I don't think
you need to know anything about category before using Record or Cross
in Axiom/Aldor either, but I would still insist that to describe it
formally as a limit in category theory adds something to the issue of
language and library design.

> Which makes some haskellers say that they did a really bad job
> at picking the name.

Well, the language is called *Haskell* afterall. Do those haskellers
who think monad is a bad name even remember who Haskell Curry was!?
;-)  [Rhetorical, don't answer that ...]

> [...]
> | > I do not however see myself implement the Haskell solution
> | > | for Axiom. I would prefer a more powerful effect system for
> | > | OpenAxiom.
> | >
> |
> | Could you describe what you mean by "effect system"?

Ok, thanks. This quote from the article:

"Similar to types, effects describe how expressions affect the store
in a functional language extended with imperative constructs. Types
and effects can be statically computed by algebraic reconstruction

makes it more clear to me.

> | > | 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.
> | >
> |
> | In that case what is wrong with effects as implemented in SPAD's
> | imperative-style programming right now?
> I did not make a statement to that effect, so I do not exactly what
> you mean. Could you clarify?

Your reference above makes it more clear to me what you might have in
mind. Perhaps you are thinking that it might be possible to give a
formal description of effects related to the imperative constructs in
SPAD as it exists now (or perhaps some subset of the imperative part
of the language). I am sceptical but I really don't know enough to
comment further.

> | I am sorry. I don't mean to sound rude, but I just don't understand
> | where your comments lead. Could you say something more about
> | what you are considering for implemention in OpenAxiom?
> Among other things, a type and effect system so that I can know which
> domain are purely functional -- therefore the caching implementation
> technique is sound for them -- and which have effects, therefore
> should not be cached.

I think that is a very worthwhile goal. Thanks for explaining.

Bill Page.

reply via email to

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