Specifying language version

[lassik]

Quoting @Glavin001 from here:

Language version may become a first class feature for Unibeautify. Prettier's Trailing Commas option has an es5 option: https://prettier.io/docs/en/options.html#trailing-commas
Whereas Unibeautify's End With Comma option is boolean (only true or false): https://unibeautify.com/docs/option-end-with-comma.html?language=javascript

I would like to be able to specify the language version (like es5 versus es6 for JavaScript, Python 2 or 3, Elm version, etc) and without an options changing (such as end-with-comma) it will adapt appropriately.

cc @stevenzeck thoughts?

[lassik]

That sounds like an ideal solution to me 😄

So would the Unibeautify config look something like the following?

HTML:
  language_version: html5
JavaScript:
  language_version: es6
Elm:
  language_version: "0.19"

What about language dialects or options?

• C is based on standards (ISO C 90, ISO C 99) with compiler-specific extensions on top of that (e.g. GCC, clang). This isn't normally mentioned anywhere in source files, so we probably need some option for this at some point.
• The Haskell compiler GHC has lots of compiler-specific language extensions. Each source file says at the top which language extensions are enabled for that file, so maybe we don't need to have an option for this.
• Python has from __future__ import ... at the top of the source file, so maybe we don't need to have an option for this.

[Glavin001]

So would the Unibeautify config look something like the following?

Something like that. Maybe using version instead of language_version. 🤔

I also want the language versions to be discrete / enum. So it is not simply numbers for some languages. I'd want Unibeautify to have TypeScript definitions saying JavaScript has supported versions es5, es6, or es2100, etc. Beautifiers can handle the versions on their own and can fall back to a more strict version when not available.

We should think a little more about what these version names should be. html5 or simply 5? ES6 or es6? How to handle complexities like C's ISO C 90 and ISO C 99 -- how many versions will be list?
Should version be required or optional?

[lassik]

Maybe using version instead of language_version. 🤔

Might be better, yes. language_version is quite verbose.

The distinction between language dialects and language versions is giving me trouble. Probably they should be combined into the same option, but what to call it? And then language options on top of that (i.e. particular features that the user can pick and choose from, on top of the base language).

Would dialect be a good enough name to cover both dialect and version? Dialect is a bit more obvious IMHO (since lots of things have versions, but only languages have dialects.)

I also want the language versions to be discrete / enum. So it is not simply numbers for some languages. I'd want Unibeautify to have TypeScript definitions saying JavaScript has supported versions es5, es6, or es2100, etc. Beautifiers can handle the versions on their own and can fall back to a more strict version when not available.

Good idea. Agreed.

html5 or simply 5?

In general, I'd err on the side of extra verbosity. In this case, e.g. XHTML is basically the same language as HTML, but should still be differentiated. So the HTML version would cover both XHTML and classic (SGML-based) HTML.

ES6 or es6?

Do our other enum options prefer upper or lowercase for their values?

How to handle complexities like C's ISO C 90 and ISO C 99 -- how many versions will be list?

We can actually make do with very few versions of C if we handle most differences as language features (instead of them being different versions of the base language).

Should version be required or optional?

Hmm. I guess most people don't actually know what version of a language they are using 😄 So it would be easier if there's a default. Also I think the majority of external formatters don't currently have a language version option. Then again, explicit is often better than implicit.

[lassik]

The other enums seem to be using lowercase-with-underscores so I guess that would be natural for these ones too. We could get on with designing this just by listing every version/dialect of every language we can think of and seeing how that looks.

C:
  version: c90  # For C, I would go with the ISO standards only
  version: c99
  version: c11
C++:
  version: c++98
  version: c++03
  version: c++11
  version: c++14
  version: c++17
Python:
  version: py2  # Or should it be 2.0. That's probably better.
  version: py3
  version: py3.6  # This brought some new syntax for which 'black' has an option.
Haskell:
  version: haskell98
  version: haskell2010
JavaScript:
  version: es5
  version: es6
  version: es7
  version: es8
  version: es9
Scheme:
  version: r5rs
  version: r6rs
  version: r7rs-small
  version: r7rs-large
HTML:
  version: html2.0
  version: html3.2
  version: html4.0
  version: html4.01
  version: html5
  version: html5.1
  version: html5.2
  version: xhtml1.0
  version: xhtml1.1
  version: xhtml1.2
  version: xhtml2.0
  version: xhtml5
  version: xhtml-basic-1.0
  version: xhtml-basic-1.1
  version: xhtml-print
  version: xhtml-mp-1.1
  version: xhtml-mp-1.2

[Glavin001]

@lassik This looks great! 🎉

[lassik]

Go 1.12 release notes:

The compiler now accepts a -lang flag to set the Go language version to use. For example, -lang=go1.8 causes the compiler to emit an error if the program uses type aliases, which were added in Go 1.9.