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

Quirks in 'pretty' output

Expand Messages
  • Thomas Aglassinger
    Here are some minor quirks in the output pretty -0.78 writes. For every case, I included the expected and the actual output. Lines of interest are marked with
    Message 1 of 14 , Sep 1 12:09 AM
    • 0 Attachment
      Here are some minor quirks in the output pretty -0.78
      writes. For every case, I included the expected and the
      actual output. Lines of interest are marked with (*),
      columns with (^).

      Thomas.

      -----------------------------------------------------------
      Missing indention in loop variant

      from
      i := 1;
      variant
      count - i
      until
      count < i
      loop
      ...
      end;

      becomes

      from
      i := 1;
      variant
      * count - i
      until
      count < i
      loop
      ...
      end;

      -----------------------------------------------------------
      Inspect looks weird

      inspect
      i
      when 1 then
      do_something
      else
      do_something_else;
      end;

      becomes

      inspect
      i
      when 1 then
      * do_something
      * else do_something_else;
      end;

      -----------------------------------------------------------
      Deferred features look weird

      sepp is
      deferred
      end -- sepp

      becomes

      sepp is
      *
      * deferred
      end -- sepp

      -----------------------------------------------------------
      True and False are lower case

      sepp: BOOLEAN is False

      hugo: BOOLEAN is True

      becomes

      sepp: BOOLEAN is false
      ^
      hugo: BOOLEAN is true
      ^
      The lower case seems to be used in ETL2, but OOSC2 uses
      initial upper case for reasons of consistency with constants
      [OOSC2, p.881]

      -----------------------------------------------------------
      Header comment is indented only one level [OOSC2, p. 886]

      hugo is
      -- Some routine
      do
      ...

      becomes

      hugo is
      * -- Some routine
      do
      ...
      -----------------------------------------------------------
      Feature clause header comments cause a line break if
      exported to something but {ANY} [OOSC2, p.889]

      feature {NONE} -- Implementation

      becomes

      * feature {NONE}
      * -- Implementation

      -----------------------------------------------------------
      {ANY} is always added to feature clause

      feature
      sepp is ...

      becomes

      * feature {ANY}
      sepp is ...

      Although it is not really wrong, I think {ANY} should only
      be written when in -parano mode. In almost all the Eiffel
      sources I've seen recently, there is no {ANY} in such a
      case.

      -----------------------------------------------------------
      Missing blank after comma and before opening parenthesis in
      feature calls [OOSC2, p.895]

      sepp.insert ('x', 1)

      becomes

      sepp.insert('x',1);
      ^ ^
      -----------------------------------------------------------
    • Roger Browne
      ... Some of your examples point to bugs or misfeatures in pretty , but some are simply stylistic issues. Not all of us consider OOSC to be the ultimate word
      Message 2 of 14 , Sep 1 4:41 AM
      • 0 Attachment
        Thomas Aglassinger wrote:

        > Here are some minor quirks in the output pretty -0.78
        > writes.

        Some of your examples point to bugs or misfeatures in 'pretty', but some
        are simply stylistic issues.
        Not all of us consider OOSC to be the ultimate word in Eiffel
        formatting!

        Here are the cases where I prefer the current SmallEiffel behaviour:

        > -----------------------------------------------------------
        > True and False are lower case
        > ...
        > The lower case seems to be used in ETL2, but OOSC2 uses
        > initial upper case for reasons of consistency with constants
        > [OOSC2, p.881]

        I prefer lower-case. In client code, 'true' and 'false' are called just
        like any other query feature, and I don't see why they should be
        lexically distinguished.

        It's not possible to enforce a consistent convention for initial
        upper-case on constants anyway! You can redefine a deferred feature as a
        constant - what value is added by using initial upper-case when calling
        the constant monomorphically and using the all-lower-case name of the
        deferred feature when calling it polymorphically?

        > -----------------------------------------------------------
        > Header comment is indented only one level

        Why should it be indented more? As far as I'm concerned, an
        indentation-level is a consistent way to show that some construct is
        "directly contained within" the outer construct. To me, two levels of
        indirection implies two levels of containment.

        > -----------------------------------------------------------
        > {ANY} is always added to feature clause
        > ...
        > Although it is not really wrong, I think {ANY} should only
        > be written when in -parano mode. In almost all the Eiffel
        > sources I've seen recently, there is no {ANY} in such a
        > case.

        I for one always write an explicit {ANY}, so that I know that I've
        specifically considered the export status of that feature clause. Only
        in quick-and-dirty hacks do I leave out the {ANY}. Then, I know that I
        must come back to it later.

        Ideally, a pretty-printer would retain {ANY} if it was present in the
        original source text.

        > -----------------------------------------------------------
        > Missing blank ... before opening parenthesis in
        > feature calls

        I prefer for leave out the blank before the opening parenthesis.

        Normally, Eiffel formatting should be inspired by rules of punctuation.
        However, parentheses do not represent a parenthetical comment as they do
        in English. Instead, they represent an argument list which is very
        tightly associated with the preceding text - and therefore I prefer to
        put them as close as possible to it.

        No formatting system is going to please everyone. The SmallEiffel team
        should only feel the need to please themselves. Whatever they can live
        with, I can too. If they were to put in options to allow for every
        possible style, they'd never have any time for more important work.

        Regards,
        Roger
        --
        Roger Browne - roger@... - Everything Eiffel
        6 Bambers Walk Wesham PR4 3DG UK - +44 1772 687525
      • Rudi Chiarito
        ... Judging by OOSC2, p. 886 I think you meant the following: hugo is -- Some routine do ... i.e. the comment is indented twice from the feature name, while
        Message 3 of 14 , Sep 1 7:48 AM
        • 0 Attachment
          Thomas Aglassinger wrote:
          >Header comment is indented only one level [OOSC2, p. 886]

          > hugo is
          > -- Some routine
          > do
          > ...

          Judging by OOSC2, p. 886 I think you meant the following:

          hugo is
          -- Some routine
          do
          ...

          i.e. the comment is indented twice from the feature name, while
          keywords are indented only once. FWIW, my eyes find that more readable
          than pretty's current behaviour (one level for comments and keywords).

          BTW, should blank lines between indexing clauses be preserved? I like to
          group them logically, as e.g. the RCS clauses below:

          indexing

          description: "MUIWindow objects";

          id: "$Id: mui_window.e,v 3.1 1999/05/08 21:14:01 yax Exp yax $";
          date: "$Date: 1999/05/08 21:14:01 $";

          The current implementation of pretty outputs the three clauses in a row.

          --
          "That's it. Sorry. Freudian slit - slut! - slot!"
          Rudi Chiarito - Magrathea & SushiWare Development - Jay Miner Society Member
          EMail: chiarito@... - WWW: http://www.cli.di.unipi.it/~chiarito/
          MISTAKES/MISSPELLINGS ARE FICTIONAL: A SIMILARITY TO REAL ONES IS INCIDENTAL
        • Berend de Boer
          Hai Roger, ... Some comment on this: people reading European languages read words, not letters. Words are separated by spaces. So I think there is a small
          Message 4 of 14 , Sep 1 11:03 AM
          • 0 Attachment
            Hai Roger,

            > However, parentheses do not represent a parenthetical comment
            > as they do
            > in English. Instead, they represent an argument list which is very
            > tightly associated with the preceding text - and therefore I prefer to
            > put them as close as possible to it.

            Some comment on this: people reading European languages read words, not
            letters. Words are separated by spaces. So I think there is a small
            advantage of having a space between a word (the method name) and its
            parameters so there's a little less brain activity in separated things which
            the brain probably reads as one thing (word + parameters if there are no
            spaces).

            I'm not sure if it's measurable, but I think a space is a bit more
            defendable than no space.

            Groetjes,

            Berend. (-:
          • Dustin Sallings
            On Wed, 1 Sep 1999, Berend de Boer wrote: # Some comment on this: people reading European languages read words, not # letters. Words are separated by spaces.
            Message 5 of 14 , Sep 1 1:48 PM
            • 0 Attachment
              On Wed, 1 Sep 1999, Berend de Boer wrote:

              # Some comment on this: people reading European languages read words, not
              # letters. Words are separated by spaces. So I think there is a small
              # advantage of having a space between a word (the method name) and its
              # parameters so there's a little less brain activity in separated things
              # which the brain probably reads as one thing (word + parameters if there
              # are no spaces).
              #
              # I'm not sure if it's measurable, but I think a space is a bit more
              # defendable than no space.

              Is Eiffel a European language? I personally prefer no space, but
              that's another one of those preference things. Maybe we should have a
              ~/.pretty.pro like indent has?

              --
              SA, beyond.com My girlfriend asked me which one I like better.
              pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@...>
              | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
              L_______________________ I hope the answer won't upset her. ____________
            • sedwards@es.com
              Having worked on thousands of lines of C and C++ code, mostly written by other people, I find it far easier to read if functions have no space between the name
              Message 6 of 14 , Sep 1 3:35 PM
              • 0 Attachment
                Having worked on thousands of lines of C and C++ code, mostly written by
                other people, I find it far easier to read if functions have no space
                between the name and the parenthesis and control statements such as 'if',
                'while', etc. do have a space. In my mind this kind of distinguishes the
                two different things

                And let's all be thankful there aren't any curly braces in Eiffel, so we
                don't have any holy wars over where they should be placed ;)

                -Scott


                -----Original Message-----
                From: Berend de Boer [mailto:berend@...]
                Sent: Wednesday, September 01, 1999 12:03 PM
                To: roger@...; 'SmallEiffel Mailing List'
                Subject: RE: Quirks in 'pretty' output

                Hai Roger,

                > However, parentheses do not represent a parenthetical
                comment
                > as they do
                > in English. Instead, they represent an argument list which
                is very
                > tightly associated with the preceding text - and therefore
                I prefer to
                > put them as close as possible to it.

                Some comment on this: people reading European languages read
                words, not
                letters. Words are separated by spaces. So I think there is
                a small
                advantage of having a space between a word (the method name)
                and its
                parameters so there's a little less brain activity in
                separated things which
                the brain probably reads as one thing (word + parameters if
                there are no
                spaces).

                I'm not sure if it's measurable, but I think a space is a
                bit more
                defendable than no space.

                Groetjes,

                Berend. (-:
              • Richard A. O'Keefe
                Concerning the spacing of f(x, y) : - Appeals to natural-language punctuation and layout conventions DO work for the comma here, because the comma IS
                Message 7 of 14 , Sep 1 4:38 PM
                • 0 Attachment
                  Concerning the spacing of "f(x, y)":

                  - Appeals to natural-language punctuation and layout conventions
                  DO work for the comma here,
                  because the comma IS functioning the way it does in natural language.

                  - Appeals to natural-language punctuation and layout conventions
                  DON'T work for the left parenthesis here,
                  because it ISN'T functioning like any of the uses of "(" in
                  (European) natural languages.

                  - It is a good thing to avoid "faux amis". In an English text,
                  "f (x)" is commonly used to mean that f and x refer to the same
                  thing (apposition). Another use is for parenthetical remarks,
                  hence the use of curly braces in Pascal.

                  - The English writing system also uses the em-dash for parenthetical
                  remarks, and the absolute rule is that the em-dash must not have
                  space on either side--yes I know the ill-educated often get that
                  wrong--but what is Eiffel practice? Eiffel practice is to put
                  spaces between "--" and any token that precedes it on the same line.
                  If natural-language tradition and good practice may be flouted when
                  the use of a symbol in Eiffel IS analogous to its natural-language
                  use, appeals to natural-language convention are idle in other cases.

                  - The use of parentheses in Eiffel, like other Fortran descendants,
                  is derived from MATHEMATICAL practice. To see what that might be,
                  I grabbed a mathematical book off my shelves. It happened to be

                  Metric Affine Geometry
                  Ernst Snapper and Robert J. Troyer
                  ISBN 0-486-66108-3

                  I opened it haphazardly, and found

                  Theorem 234.1 (refinement of the Witt theorem).
                  An isometry s: U -> W between the subspaces U and W of V
                  can be extended to both a rotation and a reflection of V
                  if and only if dim U + dim(rad U) < n.
                  ----------------------------------^
                  on page 234. The rule used here and elsewhere in the book for
                  function application appears to be "functions are immediately
                  adjacent to their arguments, or separated by one space iff that is
                  necessary to break up what would otherwise be a single token" with
                  the understanding that each Greek letter is a complete token by
                  itself and doesn't combine with anything else.

                  Let's face it, in mathematics "sin (x+y)" would be glaringly
                  unusual, "sin(x+y)" is the normal way to write it.

                  - Let us also face the fact that while layout practices can and
                  should be justified, it is still difficult to judge what weights
                  should be given to different considerations, and people can
                  rationally disagree about the outcome, while agreeing on most of
                  the principles. Any pretty-printing tool that is to be useful
                  outside the circle that originated it HAS to offer options to
                  allow for those rational disagreements. Let us also face the fact
                  that you can't satisfy everyone. With all the options GNU 'indent'
                  has, it can't satisfy everyone, so we can't expect 'pretty' to.
                • Patrick Doyle
                  ... I like the style that Jim McKim uses with the ARRAY spec: some_function( one_argument, another_argument( x ) ) It separates the function name from the
                  Message 8 of 14 , Sep 1 4:39 PM
                  • 0 Attachment
                    On Wed, 1 Sep 1999, Berend de Boer wrote:

                    > Some comment on this: people reading European languages read words, not
                    > letters. Words are separated by spaces. So I think there is a small
                    > advantage of having a space between a word (the method name) and its
                    > parameters so there's a little less brain activity in separated things which
                    > the brain probably reads as one thing (word + parameters if there are no
                    > spaces).
                    >
                    > I'm not sure if it's measurable, but I think a space is a bit more
                    > defendable than no space.

                    I like the style that Jim McKim uses with the ARRAY spec:

                    some_function( one_argument, another_argument( x ) )

                    It separates the function name from the arguments with a space, as you
                    like, but also makes it clear that the arguments are associated closely
                    with the function. It also makes the arguments themselves easier to read.

                    --
                    Patrick Doyle
                    doylep@...
                  • Richard A. O'Keefe
                    Patrick Doyle wrote: I like the style that Jim McKim uses with the ARRAY spec: some_function( one_argument, another_argument( x ) ) It separates the function
                    Message 9 of 14 , Sep 1 6:19 PM
                    • 0 Attachment
                      Patrick Doyle wrote:

                      I like the style that Jim McKim uses with the ARRAY spec:

                      some_function( one_argument, another_argument( x ) )

                      It separates the function name from the arguments with a space,
                      as you like, but also makes it clear that the arguments are
                      associated closely with the function. It also makes the
                      arguments themselves easier to read.

                      I don't agree with everything the "Ada 95 Quality and Style Guidelines"
                      book says, but there is a lot of excellent advice in there, and there's
                      a good bit of explanation. They advise divorcing function and array
                      names from arguments and subscripts, which I strongly dislike. For
                      what it's worth, you will find in section 2 the advice:

                      Therefore, use the same spacing as in text (no spaces before
                      commas and semicolons, no spaces inside parentheses, etc.).

                      It would be an excellent thing if there were an Eiffel Quality and
                      Style Guidelines book. OOSC2 is about so many other things that
                      this aspect is somewhat diluted therein.
                    • Berend de Boer
                      Hai Richard, ... I give up. You win :-) Thanks for this excellent discussion! Groetjes, Berend. (-:
                      Message 10 of 14 , Sep 1 11:46 PM
                      • 0 Attachment
                        Hai Richard,

                        > Concerning the spacing of "f(x, y)":

                        I wrote:

                        >> I'm not sure if it's measurable, but I think a space is a bit more
                        >> defendable than no space.

                        I give up. You win :-)

                        Thanks for this excellent discussion!

                        Groetjes,

                        Berend. (-:
                      • Berend de Boer
                        ... BM released that part of OOSC2 as a separate pdf, which you can download from ISE. He asked for some one to generate a 1 page summary. Groetjes, Berend.
                        Message 11 of 14 , Sep 2 12:02 AM
                        • 0 Attachment
                          > It would be an excellent thing if there were an Eiffel Quality and
                          > Style Guidelines book. OOSC2 is about so many other things that
                          > this aspect is somewhat diluted therein.

                          BM released that part of OOSC2 as a separate pdf, which you can download
                          from ISE. He asked for some one to generate a 1 page summary.

                          Groetjes,

                          Berend. (-:
                        • Kevin Wells
                          ... Style guidlines always involve personal preferences and so there is no right answer. However if everyone uses there own style this helps no-one. I think
                          Message 12 of 14 , Sep 2 1:22 PM
                          • 0 Attachment
                            Dustin Sallings wrote:

                            > Is Eiffel a European language? I personally prefer no space, but
                            > that's another one of those preference things. Maybe we should have a
                            > ~/.pretty.pro like indent has?

                            Style guidlines always involve personal preferences and so there is no
                            "right" answer. However if everyone uses there own style this helps no-one.

                            I think the only solution is for the Eiffel community to follow consistent
                            style guidelines so that members of the community can easily read one
                            anothers code. I am pleased to see that style guidelines are included in E:TL

                            Second Printing. They are an important detail missing from other language
                            specifications.

                            In my opinion the ideal solution would be an editor that displays code using
                            a
                            particular users preferences, but always saves them on disk using the
                            standard
                            style guidelines. This would insure that code distributed between users is
                            formatted in the standard way but still allows users to use their own style
                            preferences. However, I am not sure such an editor exists.

                            There was an editor for Mac Pascal on the Mac about ten years ago that did
                            real-time pretty printing of source code, highlighting of syntax errors, etc.

                            Very nice when you have to mark student assignments to have all their code
                            consistently formatted. I have never seen anything like it since. Know of a
                            syntax aware (i.e. more than just recongnising keywords and some tokens)
                            editor for Eiffel?

                            Kevin Wells
                          • Tim Rowe
                            ... A good prettyprinter could do much of that. Use a make utility to make the prettyprinter format it the standard way whenever code is checked in to
                            Message 13 of 14 , Sep 13 5:30 PM
                            • 0 Attachment
                              > -----Original Message-----
                              > From: Kevin Wells [mailto:kevin@...]
                              > Sent: 02 September 1999 21:23
                              > To: 'SmallEiffel Mailing List'
                              > Subject: Re: Quirks in 'pretty' output

                              > In my opinion the ideal solution would be an editor that displays
                              > code using
                              > a
                              > particular users preferences, but always saves them on disk using the
                              > standard
                              > style guidelines.

                              A good prettyprinter could do much of that. Use a make utility to make the
                              prettyprinter format it the standard way whenever code is checked in to
                              configuration management, and to format it the users way when checking it
                              out. Each user would have the tools set up their own way & would see it
                              their way. Of course, expecting the prettyprinter to change VariableName to
                              variable_name and vice-versa might be taking things a bit too far...
                            • Tim Rowe
                              ... ... Of course, an n-dash /with/ spaces is often used as an alternative to an m-dash /without/. As a TeX user, -- reads to me as an n-dash, so I
                              Message 14 of 14 , Sep 13 5:30 PM
                              • 0 Attachment
                                > -----Original Message-----
                                > From: Richard A. O'Keefe [mailto:ok@...]
                                > Sent: 02 September 1999 00:38
                                > To: SmallEiffel@...; berend@...; roger@...
                                > Subject: RE: Quirks in 'pretty' output
                                >
                                >
                                > Concerning the spacing of "f(x, y)":

                                <snip>
                                >
                                > - The English writing system also uses the em-dash for parenthetical
                                > remarks, and the absolute rule is that the em-dash must not have
                                > space on either side--yes I know the ill-educated often get that
                                > wrong--but what is Eiffel practice? Eiffel practice is to put
                                > spaces between "--" and any token that precedes it on the same line.
                                > If natural-language tradition and good practice may be flouted when
                                > the use of a symbol in Eiffel IS analogous to its natural-language
                                > use, appeals to natural-language convention are idle in other cases.

                                Of course, an n-dash /with/ spaces is often used as an alternative to an
                                m-dash /without/. As a TeX user, "--" reads to me as an n-dash, so I expect
                                a space!
                              Your message has been successfully submitted and would be delivered to recipients shortly.