text: VAR E ELLIPSE; VAR C CIRCLE; C := CIRCLE(LENGTH(3.0)); E := C; THE_MINOR_AXIS(E) := LENGTH(4.0));This is all legal TutorialDee code. The first assignment just invokes a Circle selector to assign a particular value. The second assignment is legal because Circles are substitutable for Ellipses: every Circle is an Ellipse. The third assignment is legal because the declared type of E is Ellipse, and THE_MINOR_AXIS is an operator defined on Ellipses. Under normal TutorialDee semantics, this presents no problem. GeneralizationByConstraint? occurs on the third assignment, so E now holds an Ellipse. And only values are stored in variables, so this doesn't affect C at all. But if you allow references or ObjectIdentity, then C would have to change with the mutation of E. But Circles don't have a minor axis! How can you set the minor axis when it doesn't have one? You'd either have to break the constraint that a circle's minor axis equal its major axis, or you'd have to change the major axis too, which isn't what the code asked for. That's why D&D speak of the "FourOutOfFiveRule". You can have 4 of the following 5 language features:
  TYPE point is POSSREP cartesian { x double, y double} POSSREP polar { r double, theta double }Is this enough to properly define the type point? It is, according to Tutorial D syntax. The semantics however, are left as an exercise:
  POINT p= cartesian ( 1, 2); THE_x(p) := 2; THE_theta(p) := PI;How about defining a + operator? OPERATOR '+' ( P1: POINT, P2: POINT ) RETURNS POINT BEGIN /* what goes in here? */ END Similar holes are there with regards to subtyping and many other crucial aspects. Of course a language without formal semantics and without a serious implementation exercise is doomed to have many holes, so the presumption should be that it is incomplete until proven otherwise. A collection of BNF forms together with half a book of "informal discussions and explanations" do not a language make. The fact that some parts of the language are not specified does not automatically invalidate other parts of the language. And the semantics of the language are fairly well defined in the book. Make sure that you're looking at the second edition of TheThirdManifesto, because it was considerably revised and expanded compared to the first. DateAndDarwen explicitly declined to fill in details of defining and manipulating actual representations in Tutorial D's syntax, although in spite of this they give some speculative examples. They do not define the semantics of the constructs in a rigorous way. In fact, you can easily define an addition operator with what is given in the book -- you don't need actual representations to do that. (Although they do not address the definition of infix operators, nor is that in any way necessary.):
  OPERATOR ADD (P1: POINT, P2: POINT) RETURNS POINT BEGIN RETURN cartesian(THE_x(P1) + THE_x(P2), THE_y(P1) + THE_y(P2)); ENDWhat is THE_x and THE_y for a point value constructed as polar(r, theta)? So your specific criticism is invalid (and the language need be no more complete than it is to determine this).The specific criticisms raised on NominativeAndStructuralTyping (where my comments originally appeared) are addressed in the book, contrary to the claims made on that page. Try again. I really don't understand what you consider informal about DateAndDarwen's treatment; it's far more rigorous than the definitions of many other languages that have actually been implemented. (Cf. for instance Ruby or Perl.) Part 3 of the book that is suppose to define the "meat" of the language has the title "informal discussions and explanations", and that's exactly what it is, they are not a systematic attempt in any way shape or form to define the semantics of the language. At the very least Ruby and Perl are defined by their implementation, and have a large body of documentation.
  operator the_theta (p point) returns rational; return ( arctan ( the_y ( p ) / the_x ( p ) ) ); end operator;- SomeGuy? } [Actually, the type implementer has to choose an actual implementation and then to provide operators to convert between the actual representation and the possible representation(s). If there is only one possible representation, the system can provide the operators by using the possible representation as the actual representation, as the operators are trivial in this case. That's the way things work in Duro. -- ReneHartmann?] You either have a type system that works or one that doesn't. And the only way to prove that an actual type system works is to integrate it with a complete language design, and show how it addresses the major problems that any language design has to face. In absence of that, all you have is castles made of sand, and nobody is going to take that kind of thing seriously.