Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[piercarl@sabi.demon.co.uk (Piercarlo Grandi)]

>>> "tiggr" =3D=3D Pieter Schoenmakers <tiggr@es.ele.tue.nl> writes:

tiggr> In article <vwjk9obnph4.fsf@cassin.dcs.aber.ac.uk> pcg@aber.ac.uk
tiggr> (Piercarlo Grandi) writes:

piercarl> Consider:
piercarl> class C // bounded stack [ ... ]

piercarl> This defines a class and a type encapsulated within it. Now
piercarl> suppose we just added something like the following two
piercarl> procedures:

piercarl> class C // bounded deque [ ... ]
piercarl> void *get(); void put(void *) { .... }

piercarl> is the second 'C' the same type as the first 'C", only
piercarl> updated? To me they are completely different types, for they
piercarl> have different semantics, as well as different interface.
piercarl> Instances of one 'C' are not instances of the other 'C'.

tiggr> There are (many, very) valid examples of adding methods to a
tiggr> class, which do not change the semantics of the object.

I and tempted to be flippant here, as I am occasionally :-) when reading
this sort of "=A3$%^&* statement, and comment "think harder".

Actually instead I will agree with you, by saying that this statement
may well be regarded as being true if one considers that by adding any
number of procedures computing the identity function to a class, the
algebra it implements does not ``really'' change.

But surely your statement clashes _badly_ with your subsequent example:

tiggr> In the example, only adding a `print' method, with the obvious
tiggr> functionality, would not change the semantics of the existing
tiggr> stack objects.  Nor would it create a new class.  The stack
tiggr> objects would just be able to print themselves.

Here we have the fantastic notion that "just able to print themselves"
("just"!) computes such a ``minuscule'' function that the algebra
implemented by the class has not ``really'' changed. This is profoundly
wrong. Plese spare me illustrating the reasons why...

Let me just state that I can hardly imagine altering a class in such a
way that it does not implement a new algebra, except for the trivial
cases (adding no-op procedures, rewriting a procedure but having it
still compute the same function).

Also, in some important way this is beyond the point: in most languages
out there ``type'' equivalence is not based on equivalence of the
denotations of two types, but on ``name'' identity (not even
``structural'' identity, for even this involves subtle problems).

tiggr> Objective-C (at least the GNU and NeXT implementations) allows
                                              =3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
tiggr> methods to be added to a class in a running program.  NeXT's
tiggr> runtime library allows method replacement.
       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This is not quite the case, to put it mildly, and the underlined bits
indicate why: some ``Objective-C'' *implementations* allow programs to
``reflect'' on their runtime support structures, and even to alter them;
programs can add pointers to method *representations* to data structures
*representing* classes, which is quite (!) a different thing from
allowing the addition of methods to classes. I am not aware of any
``Objective-C'' variants (or any popular, non-research-only) languages
out there that allow programs to do the latter, but perhaps I am just
behind the times (actually on reflection FORTH allows just that, but
arguably by blurring the distinction between the language and its
representation, and arguably CLOS does too, but then I would not call
CLOS a popular language).

One reason is perhaps that research in self-modifying programs is not
popular, for it is not easy. The ability to alter classes, or any other
part of a program, at runtime involves a number of hard conceptual
problems; they can be sidestepped, or at least so it might seem, by
providing (useful) implementation hacks, which are however a way for
language designers to pass the bucket for the solution of those
difficult problems to the programmers that use the hacks.

Note that even bits of research that seriously address representation
and semantics issues, like the relational model(s), only provide hints
towards handling things like schema evolution for databases; and much of
the popular stuff out there that might allow to do that is based on
seat-of-the-pants ``concepts''.

This is sad, but then addressing maintainability concerns seems to win
less sales and publish less papers than delivering ``new and improved''
features. :-)

tiggr> [ ... Cecil and TOM may/may not allow hacking implementations or
tiggr> rather their language-level constructs ... ]

I am not sure either; they are mostly research-in-progress, and I have
not used either.