Loading ...
Sorry, an error occurred while loading the content.

Re: [eiffel-nice-library] Intermezzo: Comparison features in ANY

Expand Messages
  • Arno Wagner
    ... You where perfectly right. Otherwise I would still be ignorant about the significance of postcondition order. Since I am the person that found ETL boring
    Message 1 of 14 , Nov 8, 2002
    • 0 Attachment
      On Fri, Nov 08, 2002 at 03:17:30PM +0100, Eric Bezault wrote:
      > Arno Wagner wrote:
      > >
      > > My true proposal is further down in the text.
      >
      > Yes, I understood that, I just wanted to correct this imprecision
      > in your reasoning, but your proposal is still valid.

      You where perfectly right. Otherwise I would still be ignorant
      about the significance of postcondition order.

      Since I am the person that found ETL "boring and hard to read"
      (some discussion here last year), I need this kind of help ;-)

      Arno

      --
      Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
      GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
      ----
      For every complex problem there is an answer that is clear, simple,
      and wrong. -- H L Mencken
    • Eric Bezault
      ... Since 1990 (i.e. before it got first published) I probably read it 4 or 5 times cover to cover. I personally find it well written and easy to read ;-) --
      Message 2 of 14 , Nov 8, 2002
      • 0 Attachment
        Arno Wagner wrote:
        >
        > Since I am the person that found ETL "boring and hard to read"
        > (some discussion here last year), I need this kind of help ;-)

        Since 1990 (i.e. before it got first published) I probably read it
        4 or 5 times cover to cover. I personally find it well written and
        easy to read ;-)

        --
        Eric Bezault
        mailto:ericb@...
        http://www.gobosoft.com



        __________________________________________________
        Modem offert : 150,92 euros rembours�s sur le Pack eXtense de Wanadoo !
        Haut d�bit � partir de 30 euros/mois : http://www.ifrance.com/_reloc/w
      • Arno Wagner
        ... I seem to recall that we had exactly the same argument before ;-) Arno -- Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@tik.ee.ethz.ch
        Message 3 of 14 , Nov 8, 2002
        • 0 Attachment
          On Fri, Nov 08, 2002 at 05:14:31PM +0100, Eric Bezault wrote:
          > Arno Wagner wrote:
          > >
          > > Since I am the person that found ETL "boring and hard to read"
          > > (some discussion here last year), I need this kind of help ;-)
          >
          > Since 1990 (i.e. before it got first published) I probably read it
          > 4 or 5 times cover to cover. I personally find it well written and
          > easy to read ;-)

          I seem to recall that we had exactly the same argument before ;-)

          Arno

          --
          Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
          GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
          ----
          For every complex problem there is an answer that is clear, simple,
          and wrong. -- H L Mencken
        • Roger Browne
          ... If you re comfortable using CVS, Joseph Kiniry can advise you how to update the website. Otherwise, you can send Joseph copies of major new standards to
          Message 4 of 14 , Nov 8, 2002
          • 0 Attachment
            Arno wrote:

            > ...
            > http://www.eiffel-nice.org/standards/wip/any/any2003proposal.html
            >
            > (Roger: Can I get access to these pages, so I can update and
            > add what is being voted on here?)

            If you're comfortable using CVS, Joseph Kiniry can advise you how to update
            the website.

            Otherwise, you can send Joseph copies of major new standards to put on the
            website, and ask him to include a link to a URL that you control, where you
            can maintain ongoing day-to-day stuff.

            Regards,
            Roger
          • Arno Wagner
            CVS is fine. I will contact Joseph. Thank you! Arno ... -- Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@tik.ee.ethz.ch GnuPG: ID: 1E25338F
            Message 5 of 14 , Nov 8, 2002
            • 0 Attachment
              CVS is fine. I will contact Joseph. Thank you!

              Arno

              On Fri, Nov 08, 2002 at 09:25:30PM +0000, Roger Browne wrote:
              > Arno wrote:
              >
              > > ...
              > > http://www.eiffel-nice.org/standards/wip/any/any2003proposal.html
              > >
              > > (Roger: Can I get access to these pages, so I can update and
              > > add what is being voted on here?)
              >
              > If you're comfortable using CVS, Joseph Kiniry can advise you how to update
              > the website.
              >
              > Otherwise, you can send Joseph copies of major new standards to put on the
              > website, and ask him to include a link to a URL that you control, where you
              > can maintain ongoing day-to-day stuff.
              >
              > Regards,
              > Roger
              >
              >
              > ---------------------------
              >
              > http://www.eiffel-nice.org/
              >
              > --------------------------
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
              >

              --
              Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
              GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
              ----
              For every complex problem there is an answer that is clear, simple,
              and wrong. -- H L Mencken
            • Peter Horan
              ... So, the proposal is to weaken preconditions and strengthen postconditions. This will be fine for any current clients. For suppliers, the vendors, work may
              Message 6 of 14 , Nov 8, 2002
              • 0 Attachment
                Arno Wagner wrote:

                > All in all more general arguments are allowed, but add no
                > cases where the result is "true". All the additionally
                > allowed arguments caused run-time or compile-time type
                > errors before. My intuition is that this makes the impact
                > on existing software unproblematic.

                So, the proposal is to weaken preconditions and strengthen postconditions. This
                will be fine for any current clients.

                For suppliers, the vendors, work may be required to comply with the proposal.
                (In principle, they could already have an unpublished implementation which
                complies with the proposal).
                --
                Peter Horan School of Information Technology
                peter@... Deakin University
                +61-3-5227 1234 (Voice) Geelong, Victoria 3217, AUSTRALIA
                +61-3-5227 2028 (FAX) http://www.cm.deakin.edu.au/~peter

                -- The Eiffel guarantee: From specification to implementation
                -- (http://www.cetus-links.org/oo_eiffel.html)
              • Cyril ADRIAN
                Hello Arno, all, ... Arno With the somewhat delayed poll result we can move on to the Arno next step. Great! :o) Arno There is indication that the
                Message 7 of 14 , Nov 8, 2002
                • 0 Attachment
                  Hello Arno, all,

                  >>>>> "Arno" == Arno Wagner <arno.wagner@...> writes:

                  Arno> With the somewhat delayed poll result we can move on to the
                  Arno> next step.

                  Great! :o)

                  Arno> There is indication that the comparison features in ANY could
                  Arno> benefit from more general argument types. The main advantage
                  Arno> would be that equality testing could be done on every pair of
                  Arno> objects, consistent with the (my?) intuitive semantics of
                  Arno> equality, namely that it is a total operation.

                  I am not sure I agree, because how can you compare a car with a carrot? I
                  would like is_equal to accept an ANY argument for another reason.

                  Arno> Furthermore not so intuitive run-time type errors would be replaced
                  Arno> by clear postcondition violations.

                  Yes, but I disagree with something more fundamental: that equality should be
                  limited to objects having the same run type. Note that it's not contradictory
                  with the previous statement: you cannot compare a car with a carrot, but I
                  feel happy to compare it to another one, even if the first is a VW and the
                  other a Chrysler . . .

                  Why so? Let's take an example from "real life": the number library of
                  SmartEiffel. In that library a new operator, viz. same_as, had to be provided
                  to be able to compare two numbers: is_equal returns false (or crashes with the
                  current implementation) when trying to compare "2/2" (a fractional number) and
                  "1" (an integer number)!

                  What I propose is:

                  - Keep standard_is_equal as it is, or with the modifications you
                  propose. After all, field-by-field comparisons are still useful.

                  - Do *not* force is_equal to be true only when an argument of the same type is
                  provided.

                  - Note that it means that, standard_is_equal and is_equal do not have exactly
                  the same contract anymore.


                  This way, library designers can covariantly redefine is_equal to their
                  liking. Note, the apparent catcall in the symmetry should then be dealt with
                  by the compiler.

                  At last, I think deep_equal has a well-defined semantics, and cannot be
                  redefined (furthermore, I never use it 'cos I think a correctly redefined
                  is_equal is far more subtle and meaningful than a savage deep_equal). Your
                  proposal suits me for that one.


                  To sum up, my proposal is:

                  - same as you for standard_is_equal and deep_equal (i.e., the frozen features)

                  - make is_equal more flexible:

                    is_equal (other: ANY): BOOLEAN
                        -- Is `other' attached to an object considered equal
                        -- to current object?
                        require
                           other_not_void: other /= Void
                        ensure
                           consistent: standard_is_equal (other) implies Result
                           symmetric: Result implies other.is_equal (Current)

                  - adapt as obvious for equal and standard_equal.


                  Arno> After we have dealt with this issue we will reconsider COMPARABLE in
                  Arno> light of the changes made to ANY.

                  Yes. I have the same kind of ideas for that class ;o)



                  OK, that's another point of view. Now we can discuss :o)

                  Regards,

                  Cyril
                  --
                  http://smerge.sf.net http://advogato.org/person/cadrian/

                  The README file said
                  "Requires Windows 95, NT 4.0, or better."
                  So... I installed it on Linux!
                • Franck Arnaud
                  First, I d like to say I m a bit reluctant about your proposal, because as I said before it s something more language related IMHO (so beyond our remit).
                  Message 8 of 14 , Nov 11, 2002
                  • 0 Attachment
                    First, I'd like to say I'm a bit reluctant about your proposal,
                    because as I said before it's something more language related
                    IMHO (so beyond our remit). Secondly every vendor currently
                    does the same thing, or at least with the same signature, so
                    even if it's currently a bit dodgy we don't gain anything from
                    the change on the interoperability front (which is part of
                    our positive remit). That said, it's no reason not to
                    discuss it, we can gain some insight into the problem if
                    nothing else.

                    > If the argument type is generalized to ANY, it becomes
                    > simpler again:
                    >
                    > frozen standard_is_equal (other: ANY): BOOLEAN

                    I have to say I can agree with this one, given that it's
                    not redefined, all potential problems are the compiler
                    implementer's and should be no worse after this signature
                    change than they were before. On the client side, all
                    potential catcalls go away.

                    > Now for "is_equal":
                    >
                    > is_equal (other: ANY): BOOLEAN
                    > -- Is `other' attached to an object of same type as
                    > -- `Current' and considered equal to `Current'?
                    > require
                    > other_not_void: other /= Void
                    > ensure
                    > consistent: standard_is_equal (other) implies Result
                    > same_type: Result implies same_type (other)
                    > symmetric: Result implies other.is_equal (Current)
                    >
                    > No problem with the more general argument. A wrong
                    > implementation can fail on "same_type" or "symmetric", but
                    > not with a run-time type error.

                    I'm not sure what you mean by 'wrong' implementation, but
                    given that the check is in the _post_condition, you may
                    still create a type error in the routine's body. E.g.:

                    class A feature
                    foo: INTEGER
                    is_equal (other: A): BOOLEAN is do Result := foo = other.foo end
                    end

                    a,other: ANY
                    !A! a
                    !! other

                    a.is_equal(other)
                    -- crash/error on covariant catcall
                    -- (in the body before postcondition)

                    The only way I can think of you could remove catcalls without a
                    precondition check going in all client uses, is to split the
                    client and descendant interfaces:

                    feature -- Client's

                    frozen is_equal (other: ANY): BOOLEAN is
                    do
                    Result := same_type (other)
                    and then is_equal_impl (other)
                    end

                    feature {NONE} -- or my old PUBLIC_NONE

                    is_equal_impl (other: ?): BOOLEAN is
                    -- that one you can be covariantly redefined
                    require
                    same_type: same_type (other)
                    do
                    Result := standard_is_equal (other) -- default
                    end

                    Of course this is not a serious proposal as this breaks
                    all existing code. An alternative would be to rename
                    is_equal_impl -> is_equal
                    is_equal -> safe_is_equal

                    but then you give a choice to the clients, thus confusion
                    (as if there were not already enough equality routines to
                    choose from) and all existing client code uses the 'wrong'
                    unsafe one.


                    Besides (and independently) if the signature is really
                    weakened, why keep the same_type postcondition at all?
                    Without it, it could be possible for POLAR_POINT
                    and CARTESIAN_POINT to be equal with the the
                    definition in the parent:

                    deferred class POINT feature
                    x: INTEGER is deferred end
                    y: INTEGER is deferred end
                    is_equal (other: POINT): BOOLEAN is
                    do Result := x = other.x and y = other.y end
                    end

                    Descendants as expected, they don't need to (must not)
                    redefine is_equal. Typing wise, it's as safe as any
                    covariant redefinition, and safe as long as only
                    descendants of POINT are compared (but they now
                    can be freely mixed, unlike the 'like Current' case).


                    A good point for your proposal, is that the postcondition
                    will statically type check correctly only for 'binary'
                    cases of covariant redefinition.

                    That is you cannot have:

                    class X
                    inherit ANY redefine is_equal end
                    feature
                    is_equal (other: DESCENDANT_OF_X): BOOLEAN ...

                    because then the postcondition:
                    other{:DESCENDANT_OF_X}.is_equal (Current{:X})

                    does not _statically_ type check with is_equal
                    expecting _at_least_ a DESCENDANT_OF_X (as defined in X).
                    This is a good thing. In effect we have some (the
                    good bit) of the "like Current" type constraint
                    expressed statically, through postconditions. Maybe
                    I'm starting to like this proposal :-).

                    Still, you can have:

                    class X
                    inherit ANY redefine is_equal end
                    feature
                    is_equal (other: ANCESTOR_OF_X): BOOLEAN ...

                    which is not binary but type checks:
                    other{:ANCESTOR_OF_X}.is_equal (Current{:X})

                    I don't know if that's a problem or not.

                    > "standard_equal" and "equal" do not change, except that
                    > the arguments would both be changed to type "ANY".

                    Nice bit about this is that it would remove that one use
                    in the standard library of the dodgy pattern:

                    f(a: ANY; b: like a)

                    where you don't really know what 'like a' means (static?
                    dynamic?).

                    Still got a problem with clone though. Talking about
                    clone we need to discuss later adding
                    "twin: like Current" to ANY now that all vendors have
                    implemented it.

                    > "deep_equal" seems to be problematic in general, but

                    Agreed.

                    > I think we could just adjust the signature accordingly
                    > without getting into trouble.

                    Indeed, you'd need a rather strong argument for the deep_
                    routine to have a different signature than their
                    non-deep_ counterpart.

                    > Furthermore a Result of "false" for all calls with different
                    > argument types is ensured, again instead of type errors.

                    The same_type postcondition does not resolve the typing
                    problem as I illustrated above. We just lose some of the
                    catcalls because we lose like Current's implicit
                    redefinition, so

                    That is given
                    a,b: ANY
                    -- to catch all possible catcalls
                    -- for all other static types, the problem is a
                    -- subset of the problem for ANY.

                    a.is_equal (b)

                    Results in a catcall/runtime type error when a is of a runtime
                    type whose latest redefined is_equal is in a class that is an
                    ancestor of b's runtime type (assuming binary redefinitions
                    only).

                    In other words, as this may not be very clear ;-), to type
                    check you would:

                    is_type_safe: BOOLEAN is
                    do
                    type_of_a := a.runtime_type
                    from until
                    type_of_a.defines (is_equal)
                    loop
                    type_of_a := type_of_a.parent -- assumes single inheritance!
                    end
                    check defines: type_of_a.defines (is_equal) end
                    Result := b.runtime_type.conforms_to (type_of_a)
                    end

                    invariant
                    not is_type_safe implies runtime_error

                    With like current, the error is when a and b are of different
                    dynamic types, which is more frequent.

                    --
                    franck@...
                  Your message has been successfully submitted and would be delivered to recipients shortly.