Re: Discriminants of tagged types

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 31 Paź, 19:36, Shark8 <onewingedsh...@gmail.com> wrote:

> I got one for you; I was using tagged types to implement the typing-
> system for a PostScript interpreter.

Yes, this is a good example.
But then - do we consider assignment to be part of the "copyability"
property?
That is, it might be meaningful for your objects to be cloned
(duplicated), but is it also meaningful for them to be assigned to one
another?
Is the assignment meaningful only within the same type, or across the
hierarchy as well?

The reason for the above question is that even though at the language
level copy initialization and assignment are somewhat mixed together
by the type being either limited or not, they are in fact distinct
concepts and not that much similar.

In the tutorial analogy of famous shapes, it might be perfectly
reasonable to duplicate an arbitrary Shape'Class (whatever it is), but
it will be completely unreasonable to assign Square to some existing
Circle. This problem alone would be sufficient for me to make
everything limited.
Similarly with the interpreter objects, states in FSMs, and so on.

Thus, for the purpose of modeling clarity I prefer to distinguish
between:
- copyability, which means support for copy-initialization *and*
assignment
- cloneability, which is always deep

So - even though my tagged types are typically limited, in some
particular cases they can be also cloneable. It does not apply to
files, sockets, database connections and similar things that are
associated with some resources that exist outside of the physical
representation of the object, but it might apply to self-contained
data entities like interpreter instructions, document elements, states
in FSMs, etc.

I hope that the above clarification makes my rule of thumb more
understandable and not really conflicting with your examples.

--
Maciej Sobczak * http://www.inspirel.com