Does it make sense to remove slots ?

[David Hopwood]

Massimo Dentico wrote:
> David Hopwood wrote:
>> Massimo Dentico wrote:
>>> David Hopwood wrote:
>>>
>>>> Exactly: you don't need a Circle type at all, so there is no problem
>>>> to solve. This applies to a large proportion of cases of supposed
>>>> problems involving Liskov substitutability.
>>>
>>> Unacceptable: the example of ellipses and circles is perfectly
>>> valid as representative of situations in the real world.
>>
>> LSP only allows Circle to be considered a subtype of Ellipse if its
>> behaviour is identical to a constrained Ellipse, i.e. with equal major
>> and minor axes.
> 
> Please, read the rest of the thread: I reject LSP as a sensible
> definition of the *subtyping* relation (if A is a subtype of B, then
> A is s subset of B). LSP defines the *behavioral equivalence* relation,
> which is a different concept.

Good, we agree on that much.

>> So why not just use an Ellipse with equal major and minor axes,
>> and reduce the complexity of the system by eliminating a class?
> 
> Simply no: I have 2 different types, one a subset of the other,
> and I need to constraint a variable to hold only values of this
> subset...

Either the Ellipse class is mutable or it is not.

If the Ellipse class is mutable, then using a conventional type
system you cannot constrain a variable to hold only circular Ellipse
instances and also consider Circle to be a subtype of Ellipse, because
that would violate the contracts of the mutation methods of Ellipse.
It is possible to define type systems that support "reference immutability":
<http://people.csail.mit.edu/people/mernst/pubs/ref-immutability-oopsla2004-abstract.html>
which solves the problem by allowing a mutable Ellipse to be created
and then referred to by a reference through which it cannot be modified.
However, that approach is very different from the Darwen and Date type
system, which doesn't allow you to model mutable Ellipse objects at all;
only mutable databases with state that includes immutable Ellipse objects.

If the Ellipse class is immutable, there is no problem to solve.

>> Essentially the only cases in which it is useful to define a subtype
>> relation between two concrete classes are cases in which LSP, strictly
>> interpreted, does *not* hold.
> 
> ... and I do *not* want someone to force me to establish another
> kind of relation (which I want the system to enforce) just to satisfy
> a "principle".
> 
> You can repeat ad nauseam that a subtype relation, as defined
> above, is not useful in "real" programs, but I know that this simply
> is not the case: declaring such relation is useful in "toy" examples
> (well, not so much toy, see the end of this post), as that of Circles
> and Ellipses, as in "real" business or scientific programs.

I didn't say that a subtype relation is not useful in real programs;
I argued that the Darwen and Date type system is not a suitable solution
to any real problem that arises with subtyping in an imperative (or
hybrid functional) language.

>> My apologies, it should have been
>> <http://c2.com/cgi/wiki?DateAndDarwensTypeSystem>.
> 
> I don't want to comment such page: there are debatable statements
> and other simply wrong.

Of course there are; it's a Wiki.

>>>> Essentially, Darwen and Date "solve" the subtyping problem by
>>>> prohibiting objects from having identity or modelling mutable
>>>> state. This is only practical if you have a language that fully
>>>> supports a pure object-functional programming style; otherwise
>>>> the cure is worse than the disease.
>>>
>>> .. this is an unsubstantieted claim. Please, explain: their
>>> model is NOT purely functional by any means, they have
>>> updatable variables, as in all *imperative* programming
>>> languages.
>>
>> Purely functional languages also support updatable variables (e.g.
>> MVar in Haskell). The differences from imperative languages are in
>> how they support this.
> 
> Yes, purely functional languages deal with states, usually via
> monads (IO monad in case of MVar). As in imperative languages
> one can write a pure function. So what? Do you equate monads
> with updatable variables? Are variables and monads used in the
> same way? Where is the distinction between purely functional
> and imperative languages then?

The main distinction is referential transparency. Darwen and Date's
model is referentially transparent, and therefore can only be used
effectively in a language designed to support pure functional
programming. There's nothing wrong with that, but Slate is not
such a language.

>> Date & Darwen's system is much closer to pure functional
>> languages in this respect, it particular, it does not
>> support multiple references aliasing a mutable object.
> 
> What you call "mutable object" is a "variable" in their model.

Not really. In their model variables can only occur at the "top level"
of a database, i.e. there are no first-class references to mutable
objects in the same sense as normally supported in (imperative or
hybrid functional) OO languages.

> What you *probably* call "object instance" (or "slot values") is
> a "value" in their model. (Well, in the object world the
> confusion reigns: some call "object instance" a value and other
> a variable; of course, a "mutable value" just don't make
> sense).

Some people are confused, others are not. Any confusion that there
is has little to do with "the object world"; after all, exactly the
same issues arise in languages that don't support typical OO features.

Mutable objects can be modelled formally as communicating processes.
Darwin and Date's system doesn't allow references to such
objects/processes to be treated as first-class values, unlike most
OO languages (and also unlike process calculi). Their model has only
one process: the database as a whole. This is somewhat like the
"world" in a pure functional language like Clean that models state
using linear/uniqueness types.

My main objection to 'The Third Manifesto', and Darwen and Date's
other writings on the same subject, is that they try to imply that
there is some fundamental difficulty or lack of conceptual coherence
in imperative OO models that take any other approach to theirs.
Rather, there are simply different design alternatives for how to
model state. All of the approaches used in practice are compatible
with useful subtyping relations.

> So, they certainly have "mutable objects" (variables) in their
> model;

They have mutable top-level variables (relvars). They do not have
first-class references to mutable objects. I made that distinction
quite clear in my previous post.

> the unique way I see in which you can think that they
> have *not* "mutable objects" is if you make confusion between
> "mutable objects" and "object instances" beacuse you call both
> when not appropriate "objects" (see my other post on the subject
> of the term "object" in Slate).
> 
> It does not support "multiple references aliasing a mutable
> object" (well, variables aliasing, via references, a variable)

Same thing.

> for good reasons, as I explain in another post in this thread
> (pointers not compatible with subtyping).

Pointers/references are perfectly compatible with subtyping, as
demonstrated by the many languages with sound type systems that
have both. Standard ML is a good example.

> Anyway, I reject what you imply here: that a programming language
> without pointers/references aliasing is not, or is less, imperative.

Well, strictly speaking a language could be imperative without
supporting reference aliasing. All imperative object-oriented
languages support reference aliasing, however, because they would
lose a significant degree of expressiveness otherwise.

> The number one feature that characterize a programming language
> as imperative is the *pervasive* use of the concept of
> (updatable) store (variables).

Yes. But the important distinction here is between languages that
fully support *pure* functional programming and those that do not.
Since Darwen and Date's model is a (somewhat disguised) pure
functional model, it needs such a language in order to be
practical.

Note that the top-level relvars do not make the model any less
pure-functional. They are analogous to MVars in Haskell or
variables directly accessible from the world in Clean.

>> This [the fact that Darwen and Date's system does not
>> support multiple references aliasing a mutable object] makes
 >> it unsuitable for Slate.
> 
> Well, first: until now Slate has *not* defined a notion of
> subtyping (at least to my knowledge).

Right, Slate is mainly dynamically typed, so the issue is not as
important.

> In fact the problem arose when Pupeno was trying to define,
> in the graphical library, a subtype relation between Circles
> and Ellipses and so he aked the list.
> 
> What I was trying to say in that context is: don't demand that
> the underlying semantics of derivation between prototypes
> in Slate is good to model subtyping (in the sense of "subsetting",
> so to speak, not behavioral equivalence). It is not!

I agree with this.

> No more, no less. I was *not* certainly suggesting to get rid of
> pointers/references in Slate.

Hmm. You suggested using (or at least looking at) Darwen and Date's
"inheritance model". That model does depend on getting rid of
pointers/references (in the form they take in Slate).

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>