From: johnzabroski on
On Mar 8, 10:53 pm, S Perryman <a...(a)a.net> wrote:
> Stefan Ram wrote:
> > "johnzabro...(a)gmail.com" <johnzabro...(a)gmail.com> writes:
> >>This has to do with the difference between objects and ADTs as data
> >>abstraction techniques.
> >   I would either compare
> >       (OOP-)objects with abstract objects (ADT-objects) or
> >       (OOP-)types   with AD-types
> >   but not
> >       (OOP-)objects with AD-types.
> >   (OOP-)objects have (OOP-)types and
> >   (ADT-)objects have  (AD-)types.
> >   In CLU (Liskov, Zilles; 1974), an object of an ADT is called
> >   an »abstract object«.
>
> My definitions have always been :
>
> 1. ADTs.
> 2. Object-based = ADTs + "self reference"
> 3. OOP (classes) = Object-based + inheritance
>
> The reason I defined the above is because #3 (Simula) came before
> #1, and I want to indicate the fact that the concepts found in ADTs
> are applicable to OOP too, regardless of the emergence in time of
> the concepts.
>
> >>Objects represent *one* interface,
> >   They fun starts when objects have /multiple/ interfaces.
> >   (Depends on how you define and count interfaces, you can
> >   always mentally count a combination of several interfaces to
> >   be a single interface.)
>
> With type substitutability and structural equivalence, a type
> with N properties has 2^N - 1 interfaces.

An object is not a type. In OOP, "interface" keyword really just
means a record of functions.

> I haven't included the 'empty' interface here, although it
> conceptually does exist (and may be of use to something) .

<FuzzyComment>
IIRC, the empty interface is actually a big deal. *IIRC*, Joseph
Goguen was one of the first to realize this, and *IIRC* wrote an essay
I think in the '70s when he was still a young researcher, correcting
his senior colleagues about its importance. But this may have been a
different paper I am thinking of.
</FuzzyComment>
From: johnzabroski on
On Mar 9, 10:52 am, "johnzabro...(a)gmail.com" <johnzabro...(a)gmail.com>
wrote:
> On Mar 8, 4:31 pm, S Perryman <a...(a)a.net> wrote:
>
> > johnzabro...(a)gmail.com wrote:
>
> > > Notice how the
> > > information required to statically check a strong typing system at
> > > compile-time requires more information than at run-time
>
> > A type error that occurs at point P in a program requires the *same*
> > information to deduce the error. The only difference is that for the
> > knowledge base K constituting type information for a program, K is
> > constructed :
>
> > - in its *entirety* for static analysis
> > - *incrementally* for dynamic analysis as the program executes
>
> I think you simply misunderstood my point.
>
> If a type error occurs at run-time, and there is no specified strategy
> for dealing with that type error, then run-time behavior *after* point
> P is undefined.  A type system does not have to be complete, and can
> allow for undefined semantics.  The compiler is allowed to emit
> whatever the hell kind of code it wants when a type error occurs,
> including code that makes demons fly out your nose [1].  A type system
> does not have to be complete, and can allow for undefined semantics.
> However, if we change the language such that we force callers to
> handle the possibility of DoesNotUnderstand, then the receiving object
> can still dynamically interpret the message; the type system just
> doesn't say what the effect of that message will be, because it can't,
> so instead it simply models a monolithic DoesNotUnderstand message.
> Then there will be *no type error*, and the compiler cannot make nasal
> demons.  The key here is how the sender and receiver interact.  An
> example would be Representational State Transfer (REST), where in HTTP
> the response codes for DoesNotUnderstand are less monolithic.  The
> receiving object can still send back a "lying" response code, but that
> is a separate matter -- it changes how you think about what your type
> system is actually proving.
>
> More generally, when specifying a system, specifications can be (1)
> defined (2) implementation defined (3) unspecified (4) undefined
>
> [1]http://catb.org/jargon/html/N/nasal-demons.html

Just to clarify things a bit,

Just because a type check fails, does not mean that the type error is
congruent with program execution flow. A type error may occur due to
"narrowing" gone wrong, and so it might not reveal information the
same way at run-time as it might at compile-time. This is why type
error messages produced by the compiler are not always helpful.
From: S Perryman on
Dmitry A. Kazakov wrote:

> On Mon, 08 Mar 2010 21:31:09 +0000, S Perryman wrote:

>>Apart from something like meta-typing manipulation, there is no concept
>>of "DoesNotUnderstand message" in strongly-typed prog langs.

> Or to put it slightly different, there is no type errors in strongly typed
> languages. So even if DoesNotUnderstand is present, then it does not
> indicate a type error. The type is OK, it does have the method Foo. It is
> just so that Foo is contracted to propagate DoesNotUnderstand.

Exactly.

The concept of not understanding what to do when invoked, is completely
different to not providing something to invoke in the first place.

Nothing more to really say on the topic is there.


Regards,
Steven Perryman
From: raould on
> >>Apart from something like meta-typing manipulation, there is no concept
> >>of "DoesNotUnderstand message" in strongly-typed prog langs.
> Nothing more to really say on the topic is there.

http://list.cs.brown.edu/pipermail/plt-scheme/2009-December/037157.html

;-)
From: johnzabroski on
On Mar 9, 11:56 am, S Perryman <a...(a)a.net> wrote:
> Dmitry A. Kazakov wrote:
> > On Mon, 08 Mar 2010 21:31:09 +0000, S Perryman wrote:
> >>Apart from something like meta-typing manipulation, there is no concept
> >>of "DoesNotUnderstand message" in strongly-typed prog langs.
> > Or to put it slightly different, there is no type errors in strongly typed
> > languages. So even if DoesNotUnderstand is present, then it does not
> > indicate a type error. The type is OK, it does have the method Foo. It is
> > just so that Foo is contracted to propagate DoesNotUnderstand.
>
> Exactly.
>
> The concept of not understanding what to do when invoked, is completely
> different to not providing something to invoke in the first place.
>
> Nothing more to really say on the topic is there.

DoesNotUnderstand in Smalltalk does not actually mean "not
understanding what to do when invoked".

Objects always have a precise specification for what to do when sent a
message. However, other objects don't know what that will be. An
object can know, given a message, what method it will invoke. An
object can also say, your message did not provide a capability-list
ensuring you have authority to tell me to go do something, so screw
you, I won't even bother replying (and potentially leak authority).

This is about separating message interpretation from method
invocation. This concept is not clear in many OO languages.