Comments for page "Intergalactic Telefunctors and Quantum Entanglement"

Re:

Mon, 02 Mar 2009 06:18:59 +0000

Well, I wouldn't want to try to speak for augustss, but I don't see anything specifically imperative about his put/get example: I, at least, interpreted him to mean something that could be axiomatized algebraically, including including something along the lines of "a = get(put(a))" Well, writing it down I see that perhaps what you're getting at has to do with the lack of a key, although you didn't use quite the same type of operations he (augustss) indicated.

Regarding selecting things from a set, I understand what you're getting at … but if I know something in advance I suspect might be in a set, I can certainly see if it's in there, and if it is, I can then form the new set, as a predicate, which returns false for the thing in question and defers to the original predicate on everything else. This is only possible if I know what to look for in advance, but in a typed context it might be possible in principle (if not efficient) to enumerate the possibilities.

and again

Tue, 17 Feb 2009 00:46:57 +0000

I posted this in reply to the other post, but again, here is one formalization of the notion of a container, and if you don't like it, you need to confront it rather than dismiss it.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.285

Re:

Mon, 16 Feb 2009 23:36:41 +0000

If that works for you, I would not argue against it. But I would object if you were to instruct newcomers by saying "this is what it really is". What you've described are not set operations, they're more like imperative operations on a set-like data structure. There's really only one operation involved in "containers", and that is membership. It's not even an operation, it's a predicate. You cannot "add" or "stick" a new element into a set; you can only form the union of two sets. Nor can you remove an element of a set; you can only ask if the element is a member of the set. "put C A" really means: form the set {C} and then take the union of {C} and A; "get c A" doesn't really mean much of anything; I suspect you mean something more like "member? c A". Sets are unordered; there is absolutely no way to select a specific element of a set; the best you can do is ask of that element is in the set or not.

Whether or not Maybe is a usefully thought of as a container really depends on who is doing the thinking. For many people that's fine and dandy, no problem. For others, not. Either way, technically, it is not a container. The predication "a isMemberOf (Maybe a)" is false, period.

Re: Mind the types

Mon, 16 Feb 2009 18:45:49 +0000

Thanks, but I was not asking for you to define it. My request still stands for Gregg.

Re: Mind the types

Mon, 16 Feb 2009 13:43:13 +0000

A (covariant) functor is some morphism map with type (α→β) → (ϕ(α)→ϕ(β)) that obeys these two laws:

map idα = idϕ
map g ◦ map f = map (g ◦ f)

(initially, it really helps if you think that a functor lifts an item function to the container level)

For example the (,) bifunctor takes two identity morphisms idα and idβ and it gives you (fst,snd) as the identity for pairs.

The classical way would be to say (a,b) is some constructor invocation that returns a new object that accepts two destructors fst and snd.

The difference is the former ressembles a specification while the latter ressembles an implementation.
If you are a functional programmer chasing abstraction, then you are encouraged to go the categorical way. Also, lazyness implies that potentially any data is actually a function, that greatly favors the categorical point of view.

Re: Mind the types

Sun, 15 Feb 2009 23:00:03 +0000

Define functor (as in the categorical concept) formally.

Re:

Sun, 15 Feb 2009 22:34:16 +0000

So to me a container, C, is something that (very informally) has these operations

 put :: A -> C get :: C -> A

You can stick something into the container, and then you can get it out. Depending on the container it might be able to hold more than one item, etc.
So that means that 'Maybe Int' is a container for Int. The Maybe type constructor is strictly speaking not a container, since it's not even kind correct to say so. But it's convenient to talk about Maybe as a container anyway, since there's no real risk of confusion.

Re: Mind the types

Sun, 15 Feb 2009 18:48:30 +0000

I agree about alien scary words. I'm not sure I would use the intergalactic telefunctor as an explanatory device, although once you grok functors it's kind of amusing.

I'm also realizing, the more I get into it, just how conditioned my thinking was by set theory. I had learned Z pretty well, so I was thinking about everything in terms of straightforward ZF denotations. I'm beginning to think the learner should be warned at the beginning that notions of set theory will have to be not so much unlearned as relearned from a CT perspective.

Thanks,

gregg

Re:

Sun, 15 Feb 2009 18:34:31 +0000

I'm not sure what you're looking for; at any rate I don't have anything fancy in mind, just anything that contains. A set being the canonical example. Does that answer your question?

Mind the types

Sun, 15 Feb 2009 17:51:54 +0000

What i tell to beginners is "observe the types", "mind the types", "type is behavior", "the arrow is right associative", "the application is left-associative".

The more they are confortable with types, functionnal types, product types & sum types, the less the urge to perpetuate the object intuition.

We want them to abandon the objet-oriented thinking, but in my opinion it's not so much desirable to resort to alien scary words to exorcize the object conditioning.
Typically arrow and application should be powerful enough to instil the mind change.

Then let it mature long enough and some will eventually demand more.

- damien

(no title)

Sun, 15 Feb 2009 17:51:48 +0000

And, btw, this gave me no insight to what you think a container is.

(no title)

Sun, 15 Feb 2009 17:49:55 +0000

I don't think category theory is the key to understanding Haskell. A little bit of domain theory helps though.

Postscript

Sun, 15 Feb 2009 16:37:33 +0000

Just realized that "quantum" is an excellent replacement for "value". So e.g. '3' denotes not a number but a quantum that we happen to name '3', or, the value of '3' is that quantum.