Does it make sense to remove slots ?

[Massimo Dentico]

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.


> 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...

 
> 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.

 
> 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. In any case a comment will be beyond
the scope of our discussion.

 
>>> 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?


> 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.
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).

So, they certainly have "mutable objects" (variables) in their
model; 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)
for good reasons, as I explain in another post in this thread
(pointers not compatible with subtyping).

Anyway, I reject what you imply here: that a programming language
without pointers/references aliasing is not, or is less, imperative.
The number one feature that characterize a programming language
as imperative is the *pervasive* use of the concept of
(updatable) store (variables).


> This makes it unsuitable for Slate.

Well, first: until now Slate has *not* defined a notion of
subtyping (at least to my knowledge).

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!

No more, no less. I was *not* certainly suggesting to get rid of
pointers/references in Slate. But where in Slate the concept of
type is used jointly with the introduction of the concept of subtype,
then, and only then, the problem arose and a correct solution
is needed.


Regards.

--
Massimo Dentico