Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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