Class hierarchy for categorical morphism

[Tom Bachmann]

Hi,

this is lifted Sergiu's pull request discussion to expose it to a wider
audience. We are discussing the class hierarchy for morphisms (to the
extent that there should be any hierarchy).


In general, a morphism is essentially a directed edge of a graph, the
starting vertex is called domain and the ending vertex codomain.
There are, for practical purposes, three kinds of morphisms:

- "named" morphisms.
These have associated a domain, codomain and "name". Two named morphisms
are equal iff they have the same name, domain and codomain.

- identity morphisms
These have a domain, and codomain equal to domain. There is a unique
identity morphism for every object.

- composed morphisms
Since categories model typical mathematical situations, composition of
morphisms is of course important. But since categories are essentially
abstract, the only thing we know, a priory, about a composed morphism is
what morphisms it was obtained from. As such, composed morphisms have
domain, codomain, and "components" (the list of morphisms that was
composed to obtain the current morphism).

Sergiu started out with one class for all three cases. He then turned
identity morphisms into a subclass (because storing booleans in .args is
tricky). I then suggested a finer splitting still:

> Tom:
>> Actually (sorry for not thinking this through earlier): why do composed
>> morphisms have names at all? I see why it can be useful to name
>> morphisms in a diagram (also composed ones, presumably), but that's not
>> really the point. The kinds of names we attach to both morphisms and
objects
>> are "internal" - they are used *purely* to distinguish them, and are
>> not necessarily related to user-visible names.
>
> Sergiu:
> Yes, agreed.
>
>> I would think that composed morphisms are identified by their components,
>> and as such don't need names. In fact, I think composed and named
>> morphismsshould live in separate classes!
>
> That's an unexpected point of view, for me And you do raise important points.
> I'll try to muse a bit here, and I'll then sleep it over.
>
> Initially, I thought that what you suggested sounded like removing the name from
> `Morphism` and deriving a class `NamedMorphism` from `Morphism`.
> However, in this case `NamedMorphism` inherits the components from
`Morphism`.
> If we do if the other way round (derive `Morphism` from
> `NamedMorphism`), then > `Morphism` will have a name, which defeats the whole point.
This means that
> there should be a third class, `MorphismBase`, which, uhm, has only a
domain and
> a codomain. `CompositeMorphism` derives from `MorphismBase` and can
have components,
> while `NamedMorphism` derives from `MorphismBase` and adds a name.
> Then, hm, we derive `IdentityMorphism` from `MorphismBase`(?), because
> names don't really make much sense for identities, and identities
cannot be composite.
>
> Does this go along the lines you were thinking of?
>

Yes.

> If yes, I can't say I am really enthusiastic, because, to factor out the name of a morphism,
> we add two classes. Also, there is essentially no way of treating a
> collection of morphisms uniformly, since some morphisms don't have names,
> others don't have components; one will always have to check the type.

Not necessarily. You could have properties (implemented in MorphismBase)
.name, .components which return "" and [self] to allow uniform access.
Not sure to what extent this defeats the idea.

> Not that I say it's critical or even necessary; just throwing about ideas.
>

I'm not very sure about it either. That's why I said "what do you think"
:-).

> Generally, I like it when the class model follows the real-world model with
> great granularity; but in this case I'm afraid whether this isn't
> going to be an overkill.
>

Yes, I also tend to worry about overkill, mostly because sometimes I
don't see when I create it ^^. I think what troubles me most about the
current design (and "most" really does not mean very much at all) is
that there is one class doing several things, not all of which make a
lot of sense in all scenarios.

Tom

[Ronan Lamy]

This is basically the obvious way to do it in sympy and matches the way
the core works, so it seems like a good plan.

>
> > If yes, I can't say I am really enthusiastic, because, to factor out the name of a morphism,
> > we add two classes. Also, there is essentially no way of treating a
> > collection of morphisms uniformly, since some morphisms don't have names,
> > others don't have components; one will always have to check the type.
>
> Not necessarily. You could have properties (implemented in MorphismBase)
> .name, .components which return "" and [self] to allow uniform access.
> Not sure to what extent this defeats the idea.

Assuming that every morphism has a name and components doesn't make much
sense from a "real-world" perspective. Code that assumes that probably
has a faulty logic, so it's appropriate to let it raise an exception.

[Sergiu Ivanov]

On Wed, Jun 13, 2012 at 3:47 PM, Ronan Lamy <ronan...@gmail.com> wrote:
> Le mercredi 13 juin 2012 à 12:16 +0100, Tom Bachmann a écrit :
>
> This is basically the obvious way to do it in sympy and matches the way
> the core works, so it seems like a good plan.

Cool, I go for it then.

Thank you everyone for your thoughts and thank you, Tom, for having
moved the discussion here :-)

>>
>> > If yes, I can't say I am really enthusiastic, because, to factor out the name of a morphism,
>>  > we add two classes.  Also, there is essentially no way of treating a
>> > collection  of morphisms uniformly, since some morphisms don't have names,
>>  > others don't have components; one will always have to check the type.
>>
>> Not necessarily. You could have properties (implemented in MorphismBase)
>> .name, .components which return "" and [self] to allow uniform access.
>> Not sure to what extent this defeats the idea.
>
> Assuming that every morphism has a name and components doesn't make much
> sense from a "real-world" perspective. Code that assumes that probably
> has a faulty logic, so it's appropriate to let it raise an exception.

Sounds plausible. Now that several people say it's not an overkill, I
like the idea much better :-)

Sergiu