There are different representation of functions: you can represent functions by arrays, maps, and b algorithmically, etc. When you specify your specific implementation e.g. in Haskell, then you fix a certain implementation, which will determine the complexity and ease of use of *updating* the specified data structures.

In the most common case you typically want to have some local functions to store some temporary data and then throw it away after your algorithm finished. This data is typically a function from some domain to a co-domain, but you will always need ad-hoc methods to represent your function as a data-structure, depending on the actual representation of the domain. Defining such temporary mappings can be quite tricky especially in a language like Haskell that does not support physical equality per/default.

OTOH *allowing* physical equality (that you have basically for free e.g. in Scala) opens another Pandora box, with its own set of big problems.

These problems arise even in other non-pure functional languages like ocaml. Pure languages OTOH require additional mind-bending gymnastics to cope with circular data-structures like directed graphs in a computationally efficient manner: you either go the monad way (which is practically giving up, IMO) or start using zippers and all kinds of other “really clever” tricks…

data Foo a = A Int | B String | C a

then A, B and C are regular functions. I don’t know what else you might mean by “artificial lines.” Languages like Scala certainly get this messed up (in more ways than one), but this is not by virtue of it being (or not being or somewhere in between) “functional.”

However, the most fundamental problem with functions in algorithmic context is the question of identity, if we say “f: D-> C” we implicitly assume that “equal” objects have equal function values. However, “identity” is a very elusive beast: it can mean different things based on the assumed equivalence relation and may be even computationally intractable.

If D and C are sets (the domain and codomain) then a function f from D to C, normally written “f : D -> C” is a subset of D x C such that:

1. For each d in D there exists some c in C such that (d,c) is an element of f. I.e. the function is defined for every element of D.

2. For each d in D, c1 and c2 in C, if both (d,c1) and (d,c2) are elements of f then c1 = c2. I.e. the function is uniquely defined for every element of D.

The answer to your second question can be found through experimentation. Functional Java and Scalaz are two such experiments.

I do not apologise for not answering arbitrary (and in this case, overwhelmingly uninteresting) questions and the entitlement is quite repulsive.

Well, I think if someone is not interested in fundamental or even philosophical debates, he’s wrong here. At least this is Tony’s blog, and it is somehow his style.

The way he answered or not-answered here is in my eyes a kind of Zen experience. One must get into it, or it will not be fun but frustration. It is somehow a teaching play.

If you feel as if he did not understand you, ponder why. If you do not understand him, meditate about the statements or responses. It scratches on your current paradigms.
If you’re open to it, it could take you beyond a border. At least that is how I felt about his and others comments on the Scala list some time ago.
So no reason to curse and moan. Play the game.

Tony, you wrote: “Trax2, a functional language in that context is one that does not make things difficult for the user to write functions.”

So I suppose the open questions here are:

- What are functions?
(answer may be necessary for)
- What makes them difficult to write (in language X)?

Well I thought a short answer to his question would have been a more productive use of time than the giant thread that was spawned by insisting on not wanting to answer it

But hey, it’s your time