"Compatibility"
[1/2] from: joel::neely::fedex::com at: 19-Feb-2003 11:02
Hi, all,
By coincidence/providence at about the same time that we were having
the SAME?-ness discussion, a collegue pointed me to
http://members.aol.com/humansandt/papers/subtyping.htm
which applies the terminology of literary criticism to the technical
issue of type-compatability, specifically the "subtype" relationship.
(How's that for an interesting mixture of disciplines? !) She also
pointed me to some thought-provoking discussions on
http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple
including the relationship (or lack thereof) between "subclass" and
subtype
. Note especially the link to the discussion of whether
a Circle is a-kind-of an Ellipse!
The punch line (for those who don't care for the metaphysics of
programming and don't want to read the remainder below ;-) is that
our everyday/common-sense notions are exceptionally poor tools for
reasoning about programs/languages, especially those with non-trivial
capabilities!
While REBOL's object model doesn't partake of the concept of "class",
I suspect that most of us have some sort of common sense notion that
would apply to
circle: make object! [
center: 0x0
radius: 0
area: func [] [pi * radius * radius]
concentric-with?: func [c [object!]] [
equal? center c/center
]
new: func [ctr [pair!] rad [number!]] [
make self [center: ctr radius: rad]
]
]
and would lead us to say that all of
foo: circle/new 0x0 5
yop: circle/new 0x0 3
qaz: circle/new 1x1 3
yield instances of the same concept (CIRCLE). Therefore we expect
each of the expressions:
foo/concentric-with? yop ; == true
foo/concentric-with? qaz ; == false
to be legitimate (error-free) and meaningful. We could have gone
further and first written
geometric-shape: make object! [
center: 0x0
concentric-with?: func [c [object!]] [
equal? center c/center
]
area: new: func [] [make error! "undefined!"]
]
and then written
circle: make geometric-shape [
radius: 0
area: func [] [pi * radius * radius]
new: func [ctr [pair!] rad [number!]] [
make self [center: ctr radius: rad]
]
]
as well as
square: make geometric-shape [
side: 0
area: func [] [side * side]
new: func [ctr [pair!] edge [number!]] [
make self [center: ctr side: edge]
]
]
after which we'd likely expect that all instances of CIRCLE, SQUARE,
and anything else "derived from" GEOMETRIC-SHAPE would be compatible
with the CONCENTRIC-WITH? method.
On the other hand, we'd likely expect that
person: make object! [
first-name: "Tom"
last-name: "Terrific"
job: "superhero"
]
yields something that is *NOT* compatible with the CONCENTRIC-WITH?
method of "any instance of a geometric shape".
>> foo/concentric-with? person
** Script Error: Invalid path value: center
** Where: concentric-with?
** Near: equal? center c/center
Not only is this expectation not something which we cannot express
in REBOL, it is not something that can be asserted confidently in
*ANY* language that supports reflection (according to the first
article cited above) unless we're prepared to bound the set of
purposes/uses we have in mind.
As REBOL is profoundly reflective -- able to "reason" (perform some
computations on) its own activity/state -- and supports most values
as first-class entities, we will always be able to write expressions
that defy our everyday/common-sense concepts of identity, equality,
and similarity.
For example, given all of the above, we can say
>> foo/center: func [] [print "two!"]
and then find
>> yop/concentric-with? foo
two!
** Script Error: equal? is missing its value2 argument
** Where: concentric-with?
** Near: equal? center c/center
or say
foo: circle/new 0x0 5
yop: make circle/new 0x0 3 [
concentric-with?: func [c [object!]] [same? c yop]
]
then finding that
yop/concentric-with? foo ; == false
The point I'm making is *NOT* that we can dynamically change the
definition of "a method of an object" (although that's true as well
in REBOL), but rather than REBOL has access to information about the
internal state of our computation that may not correspond to any
a priori notions about the problem domain of our programs. We could
have placed "identity-sensitive" expressions in the initial
definitions of CIRCLE or GEOMETRIC-SHAPE, for instance.
Our common-sense intuition (based on those a priori notions) may lead
us to conclusions that do not hold for our REBOL values.
Programming (at least with non-trivial languages ;-) isn't trivial,
regardless of our desires!
-jn-
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
Atlanta, Ga. - Scientists at the Centers for Disease Control today
confirmed that hoof-and-mouth disease cannot be spread by Microsoft's
Outlook email application, believed to be the first time the program
has ever failed to propagate a major virus.
[2/2] from: brett:codeconscious at: 20-Feb-2003 10:29
Hi Joel,
Thank you for a very interesting post.
> our everyday/common-sense notions are exceptionally poor tools for
> reasoning about programs/languages, especially those with non-trivial
> capabilities!
> Programming (at least with non-trivial languages ;-) isn't trivial,
> regardless of our desires!
I don't disagree with those two statements, though they were not what
immediately came to my mind after reading the article (the wiki page
exhausted my reading time). Side note: replace the word "Programming" with
Communication
and your second statement is even more applicable. :^)
What caught me eye most in the article (and was not a suprise) was the last
sentence of this quote:
<quote>
In this paper, I use two running examples. The first is the old riddle, "Is
a circle a subtype of an ellipse?" and the second is, "Is a working person a
subtype of a person?" The answer I give is an agressive form of "it
depends":
Those questions cannot be answered as phrased (this should not be a surprise
to the reader). They cannot be answered when given the abstract definition
of all items. In fact, they cannot be answered even when given concrete
implementations in any mathematical or executable language (this should be a
surprise to the reader). They cannot be answered except in the context of an
interpreting environment, where the usage of the items is known.
<end-quote>
This goes to the heart of my interest in REBOL and its goal of being a
messaging language
. The statement has important implications for REBOL and
XML dialects in our increasingly inter-networked world. When passing
messages it is most likely that the "usage of the items" is *not* known
(even if they are supposed to be defined). Actually, even within a fairly
controlled non-networked corporate environment, my experience has taught me
that the interpreting environment changes over time.
I think that REBOL's design (words as symbols) embraces this issue. Not by
treating the issue as a problem, but by accepting it as a fact. Where this
leads, I'm not sure. I would have liked to have seen more practicle examples
of REBOL dialects used for messaging by now. Instead I glance at the XML
based world to see what progress/backsteps are being made.
Thanks again for a thought provoking post.
Regards,
Brett.