Thanks, this is a very useful way of putting it. I started out trying to think in purely mathematical terms and not paying any mind to implementation stuff like how things are represented, but obviously at some point one would have to leap the chasm between math and actual languages and compilers. The kind of language you use here is an excellent way to integrate these two worlds.

Thanks,

gregg

Actually I'm not sure it does demolish it. My original motivation was thinking about the ontology of mathematical objects. ZF set theory is just another representation of mathematical objects. The lambda operator captures what I'm getting at better: given a formula like $x+2$, the corresponding lambda expression $\lambda x.x+2$ denotes the function associated with the formula (Church's words, my emphasis). In other words it just gives us a way to refer to the function (mathematical object) without naming it, but it doesn't say anything about what it is, except that it corresponds to the formula. In Z notation, one could use set comprehension notation to refer to the same object, something like $\{ (x,y) | y = x+2 \}$ (read "the set of all pairs $(x,y)$ satisfying the predicate $y = x+2$".) Ok, a set is about as containerish is it gets, but the point is we cannot privilege that representation by saying a function is a set of ordered pairs.

In any case your post(s) are a good reminder that most programmers are going to be coming from a practical, bottom-up perspective - thinking in terms of machine and language-specific concepts - whereas I'm trying to start with the theoretical, purely mathematical stuff and work my way down to the bits. But the kind of programmers who work with LISP dialects and FP languages are probably going to think in terms of a mix of theoretical and implementational (machine, specific language) ideas, so I think the trick (if one were to try to write e.g. a guide to Haskell from the top-down perspective) is to be very clear about the theory/practice distinction and show how they match up.

Thanks,

gregg

I think for most people it would be a stretch to think of a function as containing anything

not those familiar with Scheme… :) They'd think right away in terms of function call frames holding their lexical bindings.

Maybe a container metaphor is not such a bad idea to hold as long as we realize it's just a metaphor ("denotes containment" — what a great way of putting it!). If some value can be retrieved reliably, repeateably, from an "object", it's only natural to think of that value being contained by it.

How the held value is retrived from a curried function fooa = foo a (that is what it is, right) or from list, is two different things; so the mechanics of how a function is lifted over to them are different too - since it all eventually boils down to how and by what means the access is performed. So,

liftL f (a:as) = f a : liftL f as
— access on list is patter-matching

liftS f fooa s = (f a, s') where (a,s') = fooa s
— access on fooa is by ($ s)

But the meaning is the same. Both versions are just reductions of (liftM f = m »= (return.f)).

So here the container metaphor looks helpful in understanding.

In concrete languages, when we use "struct" we know what's going on internally. In Haskell, we don't.

The compiler is free to choose whatever concrete representation it pleases for a given abstract construct, as long as its behaviour is as prescribed.

If you'll allow my trying to rephrase you in more simple terms (so it is easier for me to understand), it's all about a distinction between an abstract mathematical concept and its concrete implementation inside the machine i.e. run-time system. A distinction between the inside pure world of Haskell compiler, and the outside real world of its run-time system implementation.

We are too imperatively inclined and are used to think in terms of concrete representations. To take your example of a pair, it _can_ actually be represented - inside run-time system world - by a C struct with two fields. Or if we use Scheme, by a tagged cons chain. Or by nothing at all - if it is all "compiled out" into its basic components as e.g. C's global variables.

And this is the main point. What it all means, is that the compiler is allowed to "compile it all out" into the thin air. What it means, is that from the mathematical perspective - from inside the pure Haskell world now - every object is an opaque entity which can only be known to us through its prescribed transactions (re: ADT via functional interfaces). IOW an object is defined by what we can do with it, ask of it, ask from it. By transactions we can get involved with it.

And that has got nothing to do with its concrete representations chosen by the implementation. And so a list - from the pure standpoint - is not a list, but an object which can be asked LENGTH? (!!)? and participate in (:). The list image inside the run-time implementation can be anything that will give us same answers to same questions. Or it can be nothing at all, as long as we get the same answers to same questions we pose using its "name" that holds its "value". As long as there's Repeatability and Predictability exhibited by our program/run-time system/implementation.

"List" is a good name, defined as you defined it: it means the constructor lists its arguments, not that the denoted value is some kind of list.

One would not want to belabor this point too much in a manual or guide, but I think it is worth making in order to bring out the character of functors as structure-preserving things that allow us to manipulate the values of one (unknown) domain using the objects and morphisms of another (known) domain.

I'm constantly puzzled by professional mathematicians becoming territorial about nomenclature, usually justified by the need to "avoid misunderstanding". "List" is a very good name, it denotes that the constructor lists its argument. Things of course get harder with nullary functions: They do not have a chance to form a morphism, they only can be subject of one. Is this latter — let's call it "subjective" — view of values what you're driving at?

However i believe adopting such a radical approach would lead to elitism.
May be, if you come from an algebraic culture, then the container fiction hurts your first contact with Haskell.
But let's face it: if you come from an algebraic culture then certainly Haskell is easier to grasp than if you are say, a Cobol programmer.

In my opinion, up to a certain extent, the tolerant way to speak about Haskell is to avoid difficulties for beginners and syntax-oriented people. Beginners tend to think about programming using objects, containers are familiar to them, containers are objects within objects, that's exactly what they expect to be.

Tell them there is no object, tell them everything is defined behavioristically, tell them morphism is the real thing and you have lost them, perhaps forever. Containers may be a fiction yet there are a fiction with a purpose.
I understand how CT can be deeply enlightening yet i simply don't want functionnal programming becoming an ivory tower only inhabited with people ending every word with -morphism.