Code formatting patterns (was: [squeak-dev] The Trunk: Compiler-cmm.275.mcz)

>> This precise proposal is argued against by "Inline Message Pattern"
>> (pg. 172 of the book).  Method body's would be starting in all
>> different vertical places, your eyes have to "find" it.  And by
>> consuming more vertical space it will result in more required
>> scrolling.  Methods are often very short, would we really want to see
>> the message pattern take up more space than the body?
>
> You're putting up a straw man here. Nobody is proposing to always put a keyword on a new line. That would make no sense at all.

Oh, I thought that's what you were proposing as an alternative to
Tim's pragma idea.  I guess I misunderstood.

> However, if you have a pattern with many and long keywords, then putting in explicit line breaks may be preferable to the automatic line wrapping. You would do that to group the keywords semantically.

I think it's better to format the language syntax elements
consistently, perhaps with a couple of exceptions like to:do: for the
sake of vertical space.  I think this gives the reader a
more-immediate awareness of the messages being sent, rather than
"reading prose".  It's a program, not a poem.  :)

On 06-10-2013, at 10:36 AM, Eliot Miranda <[hidden email]> wrote:

>
>
>
> On Sat, Oct 5, 2013 at 2:04 PM, Chris Muller <[hidden email]> wrote:
> >> This precise proposal is argued against by "Inline Message Pattern"
> >> (pg. 172 of the book).  Method body's would be starting in all
> >> different vertical places, your eyes have to "find" it.  And by
> >> consuming more vertical space it will result in more required
> >> scrolling.  Methods are often very short, would we really want to see
> >> the message pattern take up more space than the body?
> >
> > You're putting up a straw man here. Nobody is proposing to always put a keyword on a new line. That would make no sense at all.
>
> Oh, I thought that's what you were proposing as an alternative to
> Tim's pragma idea.  I guess I misunderstood.
>
> Tim's pragma idea was a joke…

Yes, sort of. I bet you could make something of that kind which would provide formatting help. An optional wotsit that the Shout & prettyprinter would take notice of. Not a lot different to ideas about optional type information provision.

The real joke is that even if someone spent the time to implement it, nobody would use it and in a few years time somebody would be stridently demanding that such a system must be developed or Smalltalk would be *destroyed* - *destroyed I tell you!!!!* by Visual javsharp++

On 2013-10-06, at 20:25, Eliot Miranda <[hidden email]> wrote:

> hence we're left with the war between visual thinkers (rectangular blocks) and verbal thinkers (pascal formatting).  just throwing wood on the fire ;-)

I very much like rectangular blocks as the general formatting rule; this is how Smalltalk code looks "naturally" to me. However, you must *not* put a space inside the brackets because then they draw too much attention, standing there on their own:

        [this is
        rectangular]

vs

        [ this is not
        as rectangular ]

There is, however, one case where the rectangular block formatting falls short, IMHO. That is when the block is the receiver of a message. For those, I still try to make them rectangular, but if that fails to look pleasant I occasionally put the closing bracket below the opening one in a line of its own, followed by the message.

Conventional wisdom says in that case one should refactor the method because it got too complex, which I agree to if there is a part that makes sense as its own method. However, I personally don't like one-off private methods just for the sake of simplifying one method. These typically need many arguments, have perhaps multiple return values, so the resulting complexity is not worth doing it.  Or am I missing something?

Not only comments, literal formatting is also important...

If I want to put line breaks and tabs inside a #( ... ), the formatter shall not break it.

If I want to write 2r0110, there must be a reason, and the formatter shall not normalize to 6.

2013/10/8 Chris Muller <[hidden email]>

> On Mon, Oct 7, 2013 at 3:01 AM, Bert Freudenberg <[hidden email]>
> wrote:
>>
>> On 2013-10-06, at 20:25, Eliot Miranda <[hidden email]> wrote:
>>
>> > hence we're left with the war between visual thinkers (rectangular
>> > blocks) and verbal thinkers (pascal formatting).  just throwing wood on the
>> > fire ;-)
>>
>> I very much like rectangular blocks as the general formatting rule; this
>> is how Smalltalk code looks "naturally" to me. However, you must *not* put a
>> space inside the brackets because then they draw too much attention,
>> standing there on their own:
>>
>>         [this is
>>         rectangular]
>
>
> Ian Piumarta and I are anal enough to prefer
>
>         [this is
>          rectangular
>          and nicely indented]
>
> ;-)
>
>>
>> vs
>>
>>         [ this is not
>>         as rectangular ]
>
>
> yuck.  Ugly as sin.  Hate the extra whitespace.  I like asSortedCollection:
> [:a :b| a < b], *not* *horrible* [ :a :b |, or even *worse*, [ : a : b |
> (argh)... ;-)

I guess there's no accounting for taste.  :)

My gripe with [:each | each doSomething] is that word-selection then
includes the colon, which is a pain when you want to Command+h,
Command+g it.  Plus, [: each | each doSomething] is consistent with
method signatures, an anonymous selector.

>> Conventional wisdom says in that case one should refactor the method
>> because it got too complex, which I agree to if there is a part that makes
>> sense as its own method. However, I personally don't like one-off private
>> methods just for the sake of simplifying one method. These typically need
>> many arguments, have perhaps multiple return values, so the resulting
>> complexity is not worth doing it.  Or am I missing something?
>
> Nope.  +1.
>
> If it weren't for comments (and comments are /really/ important) we'd have
> implemented a parameterised formatted by now that auto-formatted code to the
> preferences of the reader and this would all be moot.  But without a good AI
> I don't see how to spot and preserve while reformatting multi-line comments,
> comments with diagrams in them, etc, etc, etc.

Right the formatter butchers comments is all the more reason I lean
toward composing methods to expose more meaning.  Auto-formatting is
too valuable to give up.

Am 08.10.2013 um 22:49 schrieb tim Rowledge <[hidden email]>:

> On 08-10-2013, at 12:58 PM, Eliot Miranda <[hidden email]> wrote:
>>
>> If it weren't for comments (and comments are /really/ important) we'd have implemented a parameterised formatted by now that auto-formatted code to the preferences of the reader and this would all be moot.  But without a good AI I don't see how to spot and preserve while reformatting multi-line comments, comments with diagrams in them, etc, etc, etc.
>> --
>
> One possible thing we could do with comments is make them act like comments to annotated Word/Pages documents. Select the section of code, hit MagicKey-comment, enter comment in balloon. Comments get to live in their own private formatting space, unaffected by whatever happens to the code layout. Possibly, they could be handled so that the code differ doesn't have to get confused by them, potentially simplifying that important job.
>

CodeTalk. https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/codetalk
Yours truly had been involved with this in his bachelor's project[1]
which then was done in cooperation with Andreas and Qwaq.

There is a Paper[2] with screenshots also, an Marcel[3] wrote his Bachelor's Thesis
about this[4].

You get pop-out chats on your code that get sync-ed via a monticello
extension.

> once you have them separated, you can display them according to whatever algorithm you like. Inline them, have them float at the side, have them only pop-up when pointer is in the relevant region, list them at the end like footnotes, whatever. Or even invert the view - have the comments appear as the main text with the code off to the side.
>
> tim

Best
        -Tobias


[1] Our Univerisities way to get your fingers dirty in order to be able to
    write your thesis.
[2] http://www.taeumel.eu/pdf/codetalk-ieee.pdf
[3] The guy who also did the Morpic designer: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/designer
[4] http://www.taeumel.eu/pdf/bachelors-thesis.pdf

On 08-10-2013, at 2:14 PM, Eliot Miranda <[hidden email]> wrote:
>
> So what does a file-out look like?  What's the textual/interchange format e.g. in a Monticello package?

Not having looked at Tobias' stuff yet, I'm going to guess that one could use the same style-embedding that we already have, with some (probably) simple extensions. Or change to using xml? Is that too scary?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim

Strange OpCodes: LC: Lobotomize CPU

Am 08.10.2013 um 23:14 schrieb Eliot Miranda <[hidden email]>:

> Hi Tobias, Tim,
>
>
> On Tue, Oct 8, 2013 at 1:58 PM, Tobias Pape <[hidden email]> wrote:
>
>> Am 08.10.2013 um 22:49 schrieb tim Rowledge <[hidden email]>:
>>
>>> On 08-10-2013, at 12:58 PM, Eliot Miranda <[hidden email]>
>> wrote:
>>>>
>>>> If it weren't for comments (and comments are /really/ important) we'd
>> have implemented a parameterised formatted by now that auto-formatted code
>> to the preferences of the reader and this would all be moot.  But without a
>> good AI I don't see how to spot and preserve while reformatting multi-line
>> comments, comments with diagrams in them, etc, etc, etc.
>>>> --
>>>
>>> One possible thing we could do with comments is make them act like
>> comments to annotated Word/Pages documents. Select the section of code, hit
>> MagicKey-comment, enter comment in balloon. Comments get to live in their
>> own private formatting space, unaffected by whatever happens to the code
>> layout. Possibly, they could be handled so that the code differ doesn't
>> have to get confused by them, potentially simplifying that important job.
>>>
>>
>> CodeTalk.
>> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/codetalk
>> Yours truly had been involved with this in his bachelor's project[1]
>> which then was done in cooperation with Andreas and Qwaq.
>>
>> There is a Paper[2] with screenshots also, an Marcel[3] wrote his
>> Bachelor's Thesis
>> about this[4].
>>
>> You get pop-out chats on your code that get sync-ed via a monticello
>> extension.
>>
>
> So what does a file-out look like?  What's the textual/interchange format
> e.g. in a Monticello package?

There is no textual form in the monticello file.
The presence of chatting information is stored as extended
text attibutes (like links or colors) and the chats itself
are serialized binary as a new zip part (like snapshot.bin)
(see §3.6 of http://www.taeumel.eu/pdf/bachelors-thesis.pdf)

Best
        -Tobias

>
>
>>> once you have them separated, you can display them according to whatever
>> algorithm you like. Inline them, have them float at the side, have them
>> only pop-up when pointer is in the relevant region, list them at the end
>> like footnotes, whatever. Or even invert the view - have the comments
>> appear as the main text with the code off to the side.
>>>
>>> tim
>>
>> Best
>>        -Tobias
>>
>>
>> [1] Our Univerisities way to get your fingers dirty in order to be able to
>>    write your thesis.
>> [2] http://www.taeumel.eu/pdf/codetalk-ieee.pdf
>> [3] The guy who also did the Morpic designer:
>> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/designer
>> [4] http://www.taeumel.eu/pdf/bachelors-thesis.pdf