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

Re: Roger away for a week

Expand Messages
  • gmc444@yahoo.com
    ... next ... add two ... I d expect string.is_lower to be a boolean, and string.as_lower to be a conversion that returns a new string, all uppercase characters
    Message 1 of 11 , Mar 1, 2001
    • 0 Attachment
      --- In eiffel-nice-library@y..., arno.wagner@a... wrote:
      > ed, Feb 21, 2001 at 03:53:43PM +0000
      >
      > > I'll be away for a week from tomorrow.
      > >
      > > I'd like to suggest that we discuss the case-conversion features
      next
      > > ('to_lower' and 'to_upper') .
      > >
      > > Here are the ELKS95 versions:
      > >
      > > to_lower
      > > -- Convert to lower case.
      > >
      > > to_upper
      > > -- Convert to upper case.
      > >
      > > If we wish to specify these with assertions, one way could be to
      add two
      > > new queries: 'as_lower' and 'as_upper'.
      >
      > What about 'is_lower' and 'is_upper' in the same spirit as in
      > 'is_integer'? We would get a more consistent interface.
      > IMO 'as_lower'/'as_upper' are not needed at all and have
      > only very limited use.

      I'd expect string.is_lower to be a boolean, and string.as_lower to be
      a conversion that returns a new string, all uppercase characters
      converted to lowercase. What would be the behavior of 'is_lower' on a
      string that had not alpha characters in it?

      Going back to Roger's original post, I don't see an obvious way of
      formulating asserts for the pair of 'as_lower' and 'to_lower' that
      doesn't involve circular references.

      One could implement private queries 'has_lower' and 'has_upper' which
      return true if and only if the string contains character of that
      case. Then for example an 'to_lower' could state:

      to_lower
      require exists: exists
      ensure
      no_uppercase: not has_upper

      (such a feature could also be implemented fairly efficiently; in
      looking at some of the assertions we've beeen cranking out I worry
      that these marvels of predicate calculus are so ponderous that they
      will make meaningful applications totally unusable. And in the end
      most users will have to disable them, defeating their purpose
      entirely.)

      Is there a viable name for a case-insensitive comparison that is
      short and to the point? Perhaps "is_equal_no_case"?


      Greg
    • Simon Parker
      Good morning.I would find functions as_upper and as_lower more useful than procedures to_upper and to_lower .I would prefer the feature names to
      Message 2 of 11 , Mar 2, 2001
      • 0 Attachment
        Good morning.

        I would find functions 'as_upper' and 'as_lower' more useful than
        procedures 'to_upper' and 'to_lower'.

        I would prefer the feature names to include the word 'case' explicitly. For
        example, 'as_uppercase'.
        On the other hand, consistency is important and we don't want to break
        'to_upper' without good reason.

        Greg makes an excellent point about strings without letters. Since
        'is_upper' doesn't exist yet, I favour the more explicit and obvious
        'has_upper'.

        Again, I would prefer a more explicit name such as
        'has_uppercase_character'.

        Finally, two common conventions for naming comparison operations which are
        not case-sensitive are illustrated by:
        is_equal_ignore_case
        and
        is_equal_case_blind

        (from Java and VMS respectively).

        It is important to make it clear that default comparisons are always
        case-sensitive. Some languages and libraries have inconsistent behaviour
        and don't state policy explicitly. It's frustrating and dangerous.


        Regards,
        Simon

        Simon Parker +353 87 249 7859


        On Friday, March 02, 2001 6:25 AM, gmc444@... [SMTP:gmc444@...]
        wrote:
        > --- In eiffel-nice-library@y..., arno.wagner@a... wrote:
        > > ed, Feb 21, 2001 at 03:53:43PM +0000
        > >
        > > > I'll be away for a week from tomorrow.
        > > >
        > > > I'd like to suggest that we discuss the case-conversion features
        > next
        > > > ('to_lower' and 'to_upper') .
        > > >
        > > > Here are the ELKS95 versions:
        > > >
        > > > to_lower
        > > > -- Convert to lower case.
        > > >
        > > > to_upper
        > > > -- Convert to upper case.
        > > >
        > > > If we wish to specify these with assertions, one way could be to
        > add two
        > > > new queries: 'as_lower' and 'as_upper'.
        > >
        > > What about 'is_lower' and 'is_upper' in the same spirit as in
        > > 'is_integer'? We would get a more consistent interface.
        > > IMO 'as_lower'/'as_upper' are not needed at all and have
        > > only very limited use.
        >
        > I'd expect string.is_lower to be a boolean, and string.as_lower to be
        > a conversion that returns a new string, all uppercase characters
        > converted to lowercase. What would be the behavior of 'is_lower' on a
        > string that had not alpha characters in it?
        >
        > Going back to Roger's original post, I don't see an obvious way of
        > formulating asserts for the pair of 'as_lower' and 'to_lower' that
        > doesn't involve circular references.
        >
        > One could implement private queries 'has_lower' and 'has_upper' which
        > return true if and only if the string contains character of that
        > case. Then for example an 'to_lower' could state:
        >
        > to_lower
        > require exists: exists
        > ensure
        > no_uppercase: not has_upper
        >
        > (such a feature could also be implemented fairly efficiently; in
        > looking at some of the assertions we've beeen cranking out I worry
        > that these marvels of predicate calculus are so ponderous that they
        > will make meaningful applications totally unusable. And in the end
        > most users will have to disable them, defeating their purpose
        > entirely.)
        >
        > Is there a viable name for a case-insensitive comparison that is
        > short and to the point? Perhaps "is_equal_no_case"?
        >
        >
        > Greg
        >
        >
        > ---------------------------
        >
        > http://www.eiffel-nice.org/
        >
        > --------------------------
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
      • Arno Wagner
        ... No problem: A string is lower , when it contains no upper case characters. So a string without alpha characters (e.g. the empty string) is a string in
        Message 3 of 11 , Mar 2, 2001
        • 0 Attachment
          On Fri, Mar 02, 2001 at 06:24:34AM -0000, gmc444@... wrote:
          > --- In eiffel-nice-library@y..., arno.wagner@a... wrote:
          > > ed, Feb 21, 2001 at 03:53:43PM +0000
          > >
          > > > I'll be away for a week from tomorrow.
          > > >
          > > > I'd like to suggest that we discuss the case-conversion features
          > next
          > > > ('to_lower' and 'to_upper') .
          > > >
          > > > Here are the ELKS95 versions:
          > > >
          > > > to_lower
          > > > -- Convert to lower case.
          > > >
          > > > to_upper
          > > > -- Convert to upper case.
          > > >
          > > > If we wish to specify these with assertions, one way could be to
          > add two
          > > > new queries: 'as_lower' and 'as_upper'.
          > >
          > > What about 'is_lower' and 'is_upper' in the same spirit as in
          > > 'is_integer'? We would get a more consistent interface.
          > > IMO 'as_lower'/'as_upper' are not needed at all and have
          > > only very limited use.
          >
          > I'd expect string.is_lower to be a boolean, and string.as_lower to be
          > a conversion that returns a new string, all uppercase characters
          > converted to lowercase. What would be the behavior of 'is_lower' on a
          > string that had not alpha characters in it?
          >
          No problem: A string 'is lower', when it contains no upper case
          characters. So a string without alpha characters (e.g. the empty string)
          is a string in lower case. In fact
          s.contains_alpha = not s.is_empty and not (s.is_lower and s.is_upper)

          What I don't see the need for is a copying feature. 's.as_lower'
          is just the same as 's.clone.to_lower', which is a quite obvious
          solution IMO. Copying and (case) modification are two basic
          operations, there is no need to combine them into a complex operation,
          because we are doing a basic library here.

          The is_lower and is_upper features provide the
          possibility to check ('s.as_lower.equals(s)' is perhaps a little
          unintuitive) and can serve as postconditions. And they are basic
          operations. After all you might want to know whether calling
          to_lower will actually result in a change or not.

          In short: to_lower/is_lower provide basic functionality, as_lower
          is just a complex combination of the two that does a poor job at
          substituting is_lower.

          Regards,
          Arno

          --
          Arno Wagner Dipl. Inform. ETH Zuerich wagner@...
          GnuPG: ID: F0C049F1 FP: 8C E0 6F A5 CC B1 5A 11 ED C7 AD D2 05 5E BB 6F
          -- -- Signature removed due to protests -- --
        • Alexander Kogtenkov
          ... (Just to be ready for Unicode) Unicode classifies letters into 3 groups: lower case, upper case and title case. So, the solution might be not so obvious.
          Message 4 of 11 , Mar 2, 2001
          • 0 Attachment
            Arno Wagner wrote:

            > A string 'is lower', when it contains no upper case
            > characters.

            (Just to be ready for Unicode) Unicode classifies letters
            into 3 groups: lower case, upper case and title case. So,
            the solution might be not so obvious.

            Regards,
            Alexander Kogtenkov
            Object Tools, Moscow
          • Arno Wagner
            O.K. I cannot let this go without response... ... But why include a feature that is a combination of copying and case conversion, but not the more elementary
            Message 5 of 11 , Mar 2, 2001
            • 0 Attachment
              O.K. I cannot let this go without response...
              On Fri, Mar 02, 2001 at 11:46:50AM -0000, Simon Parker wrote:
              > Good morning.
              >
              > I would find functions 'as_upper' and 'as_lower' more useful than
              > procedures 'to_upper' and 'to_lower'.

              But why include a feature that is a combination of copying and case
              conversion, but not the more elementary case conversion? If we only have
              'as_upper', no in-place conversion will be possible. If the string is long
              this might be not acceptable.

              > I would prefer the feature names to include the word 'case' explicitly. For
              > example, 'as_uppercase'.

              I agree on this. More clear. But not so important. So in the spirit of
              "don't fix it if it is not broken" we probaly should omit the 'case'.

              > On the other hand, consistency is important and we don't want to break
              > 'to_upper' without good reason.
              >
              > Greg makes an excellent point about strings without letters. Since
              > 'is_upper' doesn't exist yet, I favour the more explicit and obvious
              > 'has_upper'.

              Which could easily be misunderstood as "has upper case".
              Or was this your intention: "is_upper = has_upper" ?

              > Again, I would prefer a more explicit name such as
              > 'has_uppercase_character'.

              O.K. I see it was not. I think that while this is clearer it is also
              uneccessarily long. I can already hear Dominique favoring the presence
              of an alias 'has_upper' for 'has_uppercase_character' when I propose this
              for SE. I also see problems with the semantics:
              not has_uppercase_character = is_lower
              IMO the thing you usually are concerned about is whether it is
              lower/upper case and if there are no violating characters,
              it is o.k. (otherwise something has to be done about it). But to do
              that with the negative property is a little unintuitive.

              And it breaks the naming style: we have is_equal, is_boolean, is_integer,
              is_empty. This has the nice consequence that a feature named is_<something>
              is allways a boolean query without argument for a property the object
              might or might not have. I would really be opposed to breaking that
              convention.

              > Finally, two common conventions for naming comparison operations which are
              > not case-sensitive are illustrated by:
              > is_equal_ignore_case
              > and
              > is_equal_case_blind
              >
              > (from Java and VMS respectively).
              >
              > It is important to make it clear that default comparisons are always
              > case-sensitive. Some languages and libraries have inconsistent behaviour

              Not needed. Default comparison is allways either same_object_location (=)
              or same_object_contents (is_equal) in Eiffel. But I agree that having
              'is_equal_ignore_case' (my preference, 'blindness' is a term form
              without CS, while 'ignore' is clearly an accepted computer term)
              would remove any doubt a user could have. These feature would
              be handy to have if we make STRING case aware. And it would
              complete the basic operation tripel that should be there for a property
              that can be made to hold in a canonic way:

              1. check property
              2. convert so that property holds (reduction modulo property)
              3. compare modulo property (equality in the quotient set modulo property)

              > and don't state policy explicitly. It's frustrating and dangerous.
              I hate that too. Best of all is when you get the impression that
              it might change without notice.

              Regards,
              Arno

              --
              Arno Wagner Dipl. Inform. ETH Zuerich wagner@...
              GnuPG: ID: F0C049F1 FP: 8C E0 6F A5 CC B1 5A 11 ED C7 AD D2 05 5E BB 6F
              -- -- Signature removed due to protests -- --
            • Arno Wagner
              ... And why not include footnote_case, remark_case, no_case, subtitle_case, subsubtitle_case, whatever_case,... Arggghh! I really think Unicode was made
              Message 6 of 11 , Mar 2, 2001
              • 0 Attachment
                On Fri, Mar 02, 2001 at 03:31:28PM +0300, Alexander Kogtenkov wrote:
                > Arno Wagner wrote:
                >
                > > A string 'is lower', when it contains no upper case
                > > characters.
                >
                > (Just to be ready for Unicode) Unicode classifies letters
                > into 3 groups: lower case, upper case and title case. So,
                > the solution might be not so obvious.

                And why not include footnote_case, remark_case, no_case,
                subtitle_case, subsubtitle_case, whatever_case,...

                <rant>
                Arggghh! I really think Unicode was made by people that
                don't understand software at all. There are so many features
                that Unicode will probably never work correctly. The whole
                idea is stupid IMO. After all was not one of the most important
                achievements that made a lot of todays science and technology possible
                a poweful and simple notation for numbers and a small set of
                characters in the written language that could actualle be read
                and written by most people?
                I know, I know, shoolars of classic languages are extatic
                about Unicode (I talked to some of them), but for me the whole
                thing is very foolish and will cause a lot of uneccessary problems.
                And I don't think the sudy of classic languages is that important
                that every piece of software has to support right to left writing
                or symbol subscripting or TITLE_CASE or ... ARGGHHH!

                Just to name a few problems: Firewall filtering can be circumvected
                if the firewall has a different understanding as the application
                that should be protected. (This will happen constantly. There is no
                and probably will never be a complete Unicode implementation. But
                there are _many_ different ones. Just think of a Word macro virus
                written in a font where you cannot even recognize the characters,
                but that executes nonetheless. A nightmare!) Buffer overflow cloud
                be caused by strings changing their length in unpredictable ways.
                Whole parts of the internet could stop talk to each other because
                the writing is not readable to the other parts anymore. And
                still Unicode does _not_ have a decent way of describing mathematical
                formulas. Typical: The probably most powerful notational tool
                for all modern science is just omitted. Great. <Grumble>.

                _I_ do _not_ want Unicode support in the EIFFEL basic classes!
                I would support display PostScript or something like it, but
                Unicode is just one big mistake. A typical result from
                "Design by Commitee".
                </rant>

                O.K. I feel better now.
                But still I thik our basis should be ISO-7-Bit (in an 8-bit-clean
                fashion) and not Unicode.

                Regards,
                Arno

                --
                Arno Wagner Dipl. Inform. ETH Zuerich wagner@...
                GnuPG: ID: F0C049F1 FP: 8C E0 6F A5 CC B1 5A 11 ED C7 AD D2 05 5E BB 6F
                -- -- Signature removed due to protests -- --
              • Simon Parker
                Good afternoon.I hear the performance argument, but I wasn t assuming that in-place case conversion is necessarily possible. If it isn t, then perhaps
                Message 7 of 11 , Mar 2, 2001
                • 0 Attachment
                  Good afternoon.

                  I hear the performance argument, but I wasn't assuming that in-place case
                  conversion is necessarily possible. If it isn't, then perhaps
                  'as_lowercase' can be implemented more efficiently than
                  'clone().to_lowercase'. I don't feel very strongly about it, however, and
                  could easily live without the function.

                  'is_lowercase' might be understood to mean 'contains only lowercase
                  letters' rather than 'contains no uppercase letters.
                  'has_lowercase' clearly mean 'contains at least one lowercase letter'.
                  I know it's negative, and perhaps less comfortable, but it is more
                  explicit.
                  Case is a property of a character, not the string which contains it.

                  The crispness of your logic about modulos and properties is attractive,
                  though.

                  Regards,
                  Simon

                  Simon Parker +353 87 249 7859


                  On Friday, March 02, 2001 1:05 PM, Arno Wagner [SMTP:arno.wagner@...]
                  wrote:
                  > O.K. I cannot let this go without response...
                  > On Fri, Mar 02, 2001 at 11:46:50AM -0000, Simon Parker wrote:
                  > > Good morning.
                  > >
                  > > I would find functions 'as_upper' and 'as_lower' more useful than
                  > > procedures 'to_upper' and 'to_lower'.
                  >
                  > But why include a feature that is a combination of copying and case
                  > conversion, but not the more elementary case conversion? If we only have
                  > 'as_upper', no in-place conversion will be possible. If the string is
                  long
                  > this might be not acceptable.
                  >
                  > > I would prefer the feature names to include the word 'case' explicitly.
                  For
                  > > example, 'as_uppercase'.
                  >
                  > I agree on this. More clear. But not so important. So in the spirit of
                  > "don't fix it if it is not broken" we probaly should omit the 'case'.
                  >
                  > > On the other hand, consistency is important and we don't want to break
                  > > 'to_upper' without good reason.
                  > >
                  > > Greg makes an excellent point about strings without letters. Since
                  > > 'is_upper' doesn't exist yet, I favour the more explicit and obvious
                  > > 'has_upper'.
                  >
                  > Which could easily be misunderstood as "has upper case".
                  > Or was this your intention: "is_upper = has_upper" ?
                  >
                  > > Again, I would prefer a more explicit name such as
                  > > 'has_uppercase_character'.
                  >
                  > O.K. I see it was not. I think that while this is clearer it is also
                  > uneccessarily long. I can already hear Dominique favoring the presence
                  > of an alias 'has_upper' for 'has_uppercase_character' when I propose this
                  > for SE. I also see problems with the semantics:
                  > not has_uppercase_character = is_lower
                  > IMO the thing you usually are concerned about is whether it is
                  > lower/upper case and if there are no violating characters,
                  > it is o.k. (otherwise something has to be done about it). But to do
                  > that with the negative property is a little unintuitive.
                  >
                  > And it breaks the naming style: we have is_equal, is_boolean, is_integer,
                  > is_empty. This has the nice consequence that a feature named
                  is_<something>
                  > is allways a boolean query without argument for a property the object
                  > might or might not have. I would really be opposed to breaking that
                  > convention.
                  >
                  > > Finally, two common conventions for naming comparison operations which
                  are
                  > > not case-sensitive are illustrated by:
                  > > is_equal_ignore_case
                  > > and
                  > > is_equal_case_blind
                  > >
                  > > (from Java and VMS respectively).
                  > >
                  > > It is important to make it clear that default comparisons are always
                  > > case-sensitive. Some languages and libraries have inconsistent
                  behaviour
                  >
                  > Not needed. Default comparison is allways either same_object_location (=)
                  > or same_object_contents (is_equal) in Eiffel. But I agree that having
                  > 'is_equal_ignore_case' (my preference, 'blindness' is a term form
                  > without CS, while 'ignore' is clearly an accepted computer term)
                  > would remove any doubt a user could have. These feature would
                  > be handy to have if we make STRING case aware. And it would
                  > complete the basic operation tripel that should be there for a property
                  > that can be made to hold in a canonic way:
                  >
                  > 1. check property
                  > 2. convert so that property holds (reduction modulo property)
                  > 3. compare modulo property (equality in the quotient set modulo
                  property)
                  >
                  > > and don't state policy explicitly. It's frustrating and dangerous.
                  > I hate that too. Best of all is when you get the impression that
                  > it might change without notice.
                  >
                  > Regards,
                  > Arno
                  >
                  > --
                  > Arno Wagner Dipl. Inform. ETH Zuerich wagner@...
                  > GnuPG: ID: F0C049F1 FP: 8C E0 6F A5 CC B1 5A 11 ED C7 AD D2 05 5E BB 6F
                  > -- -- Signature removed due to protests -- --
                  >
                  >
                  > ---------------------------
                  >
                  > http://www.eiffel-nice.org/
                  >
                  > --------------------------
                  >
                  > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                  >
                • gmc444@yahoo.com
                  ... [...] ... string) ... s.is_upper) ... [...] Let me get this straight: is_integer requires the string contain nothing but digits. is_lower requires the
                  Message 8 of 11 , Mar 2, 2001
                  • 0 Attachment
                    --- In eiffel-nice-library@y..., Arno Wagner <arno.wagner@a...> wrote:
                    > On Fri, Mar 02, 2001 at 06:24:34AM -0000, gmc444@y... wrote:
                    [...]
                    > > What would be the behavior of 'is_lower' on a
                    > > string that had not alpha characters in it?
                    > >

                    > No problem: A string 'is lower', when it contains no upper case
                    > characters. So a string without alpha characters (e.g. the empty
                    string)
                    > is a string in lower case. In fact
                    > s.contains_alpha = not s.is_empty and not (s.is_lower and
                    s.is_upper)
                    >
                    [...]

                    Let me get this straight:

                    is_integer requires the string contain nothing but digits.

                    is_lower requires the string contain anything but uppercase alpha
                    characters.

                    Is this correct?

                    Greg
                  • Arno Wagner
                    ... Yes, with one provision: is_integer requires also that it is non-empty (by the grammar that an integer has to respect) and might contain a sign ast the
                    Message 9 of 11 , Mar 2, 2001
                    • 0 Attachment
                      On Fri, Mar 02, 2001 at 05:20:39PM -0000, gmc444@... wrote:
                      > --- In eiffel-nice-library@y..., Arno Wagner <arno.wagner@a...> wrote:
                      > > On Fri, Mar 02, 2001 at 06:24:34AM -0000, gmc444@y... wrote:
                      > [...]
                      > > > What would be the behavior of 'is_lower' on a
                      > > > string that had not alpha characters in it?
                      > > >
                      >
                      > > No problem: A string 'is lower', when it contains no upper case
                      > > characters. So a string without alpha characters (e.g. the empty
                      > string)
                      > > is a string in lower case. In fact
                      > > s.contains_alpha = not s.is_empty and not (s.is_lower and
                      > s.is_upper)
                      > >
                      > [...]
                      >
                      > Let me get this straight:
                      >
                      > is_integer requires the string contain nothing but digits.
                      >
                      > is_lower requires the string contain anything but uppercase alpha
                      > characters.
                      >
                      > Is this correct?
                      >
                      > Greg
                      >
                      Yes, with one provision: is_integer requires also that it is non-empty
                      (by the grammar that an integer has to respect) and might contain
                      a sign ast the beginning. Both requirements can be seen as structural
                      (bending the term a little for the non-emptyness).
                      There is no 'structural' requirement in is_lower.

                      Arno
                      --
                      Arno Wagner Dipl. Inform. ETH Zuerich wagner@...
                      GnuPG: ID: F0C049F1 FP: 8C E0 6F A5 CC B1 5A 11 ED C7 AD D2 05 5E BB 6F
                      -- -- Signature removed due to protests -- --
                    Your message has been successfully submitted and would be delivered to recipients shortly.