Packages
Packages copied to clipboard
sublimehq
[Erlang] 'query' keyword is deprecated
The atom query is not a keyword since at least R16B (?) and should be removed.
https://github.com/sublimehq/Packages/blob/f36b8f807d5f30d2b8ef639232a9fc5960f550fa/Erlang/Erlang.sublime-syntax#L764
It was decided to keep the keyword for compatibility reasons with legacy code.
@deathaxe As far as I know not even recent Erlang versions has this as a reserved keyword anymore (can't test right now exactly from wich version).
It is Will who argued for the age of Erlang and possible issues with older sources.
Looks like query keyword was removed in ErlangOTP-17 with commit https://github.com/erlang/otp/commit/0dc3a29744bed0b7f483ad72e19773dc0982ea50 in 2012.
We basically have the same issue with python. It still highlights some obsolete reserved keywords for backward compatibility reasons.
I don't have a strong personal meaning about it.
I can't find any references right now but the query keyword has been deprecated for years before this. It has been removed completely (i.e. is fully allowed and non-reserved) since 17.0.
The point is that we try to make syntax highlighting work even for people who aren't running the latest and greatest of a programming language. Python 2.6 hasn't been supported in years, but there is still plenty of code running that, and will be for many years to come.
So if Sublime insists on supporting this keyword I see only see two reasonable options:
- Mark it as deprecated (arguably the "correct" stance since that is what the last seen state of the keyword was)
- Mark it as a keyword
Neither of which is correct in any modern version of Erlang (with a very generous definition of modern).
Besides, using the atom query is completely valid usage in contemporary Erlang. That was the intention all along when deprecating it in the first place.
I cannot understand the argument of being correct against old versions of a language but not newer versions. Especially officially supported versions.
@wbond But wouldn't you be annoyed if you wrote modern code in the same language as your legacy code from 2007 and it showed up as incorrect even though you knew it wasn't? Isn't it better to do it the other way around for the arguably smaller group of developers who has to read ancient code? And if that's is really important, why not rename the current syntax to "Erlang (Legacy)" and keep the actual Erlang syntax up to date? (Not that I would endorse that in this case)
rename the current syntax to "Erlang (Legacy)" and keep the actual Erlang syntax up to date?
I suggested something in YAML wherein we stamp the old behaviour back in on a syntax variant with extends.
However, in this case it's such a minor thing that I wouldn't do it to be honest. Erlang has very few legacy constructs.