Add stanfunctions extension to Stan

[spinkney]

Stan now allows the ending .stanfunctions

PR in Stan that allows this: https://github.com/stan-dev/stanc3/pull/1022

Repo using them example: https://github.com/spinkney/helpful_stan_functions/blob/main/functions/distribution/unit_johnson_su.stanfunctions

Checklist:

• [x] I am fixing a misclassified language
  • [x] I have included a new sample for the misclassified language:

[Nixinova]

You filled out the wrong part of the checklist - you are adding a new extension which means you should have filled in the "I am adding a new language" checklist instead of the "fixing a misclassified language" one.

The key part of that part of the checklist is:

The extension of the new language is used in hundreds of repositories on GitHub.com.

This extension only has 35 files associated with it (most of which are yours), which is not nearly enough to quality for addition to Linguist.

[spinkney]

It's being released in a few weeks and is a sub extension of the language. My repo is an example of the new usage and I'm a Stan dev, so it's not surprising that it is only mine at the moment. I'm preemptively adding.

As for the checklist, I don't see how it's useful to check "adding a new language". I'm not adding a new language, but an addition to a current language. The code inside is exactly the same as in .stan, so there is no change to highlighting logic or anything else that needs to be done to correctly highlight the code.

I can understand when an entirely new language is being added that this requirement of hundreds of repos being met. Surely, this is overkill in this case.

[Nixinova]

Each new file extension has to meet the requirements for adding a new language. Otherwise Linguist would be chock full of languages with filenames that only apply to a few files.

[WardBrian]

I understand the objections to allowing any language to add arbitrary extensions, but I fear it has created a bit of a chicken and egg problem. I can name several projects which have files that should be .stanfunctions files (e.g., they are not valid stan programs), but use the .stan extension because of syntax highlighting. The latest example I know of is all of the files in https://github.com/onnela-lab/gptools/tree/main/stan/gptools/stan/gptools

Assuming this continues, it seems like because there is already some option which provides highlighting, there will likely never be enough examples under the new name to meet this policy. However, if the new extension was also supported, I think you would see the number rapidly rise due to the correct re-naming of existing files.

In light of this, is there any way this request can be re-considered?

[lildude]

Assuming this continues, it seems like because there is already some option which provides highlighting, there will likely never be enough examples under the new name to meet this policy. However, if the new extension was also supported, I think you would see the number rapidly rise due to the correct re-naming of existing files.

In light of this, is there any way this request can be re-considered?

No as this isn't really Linguist's battle to fight.

If users aren't using the .stanfunctions extension, then it's really up to the language community to promote, encourage or enforce the usage, or reconsider the extension. This applies to all languages Linguist supports.

I'm sceptical the lack of usage (now 41 files spread across only 6 users) is due to the lack of syntax highlighting on GitHub and rather suggests there's no real reason for users to use the extension, or they don't know to use it, so they're not using it. Those that are using it, can easily get syntax highlighting using an override.

A slight relaxation of these requirements might be considered if we're seeing significant and rapid growth in the usage of an extension and we're close to a new release, but that isn't the case here with only 6 new .stanfunctions indexed in a year.

[WardBrian]

Fair enough, thank you for the response!

I am one of those users and honestly the use of linguist overrides for this had not occurred to me. That is definitely a more than workable solution