Investigate formatter adding newline between call to spec and def

[Qqwy]

Currently the formatter seems to insert a newline after a call to spec before the next def. If there is a way to override this, that would be beneficial to the readability of the code.

[Qqwy]

It seems that a newline is only inserted when the spec is long enough to be spread across multiple lines. This is related to what is metioned in this section of the Code.format_string! docs:

Newlines inside blocks are kept as in the input except for:

• expressions that take multiple lines will always have an empty line before and after and 2) empty lines are always squeezed together into a single empty line

[baldwindavid]

That is true, but more often is the case where the function it is specifying is spread across multiple lines, which results in a newline above that function. It totally makes sense that it is doing it. I just wasn't sure if you had some sort of special formatting that made it operate differently.

[baldwindavid]

Hm. I've switched over quite a lot of code to using this now and the newlines and lack of syntax highlighting that I am used to with @contract does make it more difficult to scan. If there were 30 functions in the file, it now looks like 60 because I almost always have multiline functions and spec just blends in with everything else. This whole thing is so well thought out that I hate to even bring up the thought of a replacement for spec, but are you pretty much sold on using spec as opposed to something like @contract or @check? Those would solve the readability issue, but I have no idea of the feasibility. Anyway, just a thought.

[Qqwy]

It is a bit of a matter of pick your poison: Overriding Kernel.@, which is the technique Norm is using, is what is required to be able rewrite the type-AST of a module attribute before it is set. However, overriding Kernel.@ opens up a whole other can of worms with issues like this one.

That said, I'll definitely give this more thought since the lack of proper highlighting and the fact that the formatter treats module-attributes fundamentally different from other expressions definitely are detrimental to the usability of this library.

[baldwindavid]

Eh, definitely a lot of tradeoffs to contend with. I appreciate the work you and the Norm people are doing to push these limits and add useful features.

One last (probably, haha) harp on type-checking @spec and @type. If @spec and @type were type checked, I would assume that they would be sufficient most of the time. Thus, usage of spec would be a special case where the lack of syntax highlighting and extra newlines would probably be fine and expected. I actually really like that the word spec is used because it is obvious that this is both a specification and a signal that the syntax will be very similar to but, an upgrade, to @spec.