@toh995 I don't think .core is a Koka extension. .kkc is probably what you are thinking of.

.kk is source
.kkc is core (a subset of source), highlights pretty well with the textmate grammar, but might also have some features less supported - it is a generated intermediate file representation, probably not ever checked into git.
.kki is interface files, always generated as an interface for distributing binary libraries, and linking to them. Also just a subset of the source syntax, and highlights mostly fine with the textmate grammar.

Hi @TimWhiting. Thanks for the advice.

I was going off of this part of the textmate grammar: https://github.com/koka-lang/koka/blob/e55036d/support/vscode/koka.language-koka/syntaxes/koka.json#L3

I had thought that there was a one-to-one mapping between file extensions vs. file types. But looks like that is not actually the case?

Which file extensions would you recommend adding linguist support for, amongst the three? Obviously we'd like .kk support, but what about the others?

EDIT: Maybe we can add .kk only for now, since I only provided code samples for .kk.

I've made a change in the original textmate grammar in the Koka repo to reflect the actual file type.

I'd say add all of the extensions unless there is any concern from the linguist side. They all should be highlighted using this grammar if they show up in a repository or on github issues. We probably should add examples of those files though.

I'd say add all of the extensions unless there is any concern from the linguist side.

All extensions need to meet our usage requirements. Any that don't will hold back the PR from being merged. Once merged and deployed, users can use an override to set the language for the less poor extensions.

Thanks @lildude for weighing in RE: file extensions!

Looks like .kki and .kkc clearly do not meet the usage requirements. I'll remove those file extensions from this PR.

@lildude I've addressed your comments! I'd appreciate another round of review.

Also - another question - how is the grammar git submodule kept up-to-date? i.e. suppose the upstream grammar repo gets updated (e.g. in our case, koka-community/koka-textmate-grammar). How does linguist pick up on these upstream changes? Do we need to manually update linguist for every upstream change?

@toh995 It looks like most languages only have one sample per extension, it looks like multiple samples are not necessary unless there are other languages with the same extension to disambiguate which actual language it better matches. Since no other language uses .kk I think we only need one sample.

Thanks @lildude for the review!

For the code samples, is it okay if it doesn't contain all possible language features? I guess that's why I added so many samples, I wanted to ensure we get reasonable coverage of all language features 😅

@toh995 I don't think we need all features, just enough to distinguish from another language using the .kk extension.

From looking at the other languages in the samples folder it seems like there is a wide variety of lengths and numbers of samples, and many have only one or two samples per extension type. For example, Kotlin, Dart, ReScript and Scala have very few samples (1-2). There are others that have a lot (Swift). I feel like the ones that have a lot are going overboard. What other programming language is going to use the .swift extension? Also the samples don't necessarily need to be a full module with tests and main functions. Maybe some different examples of omitting {} and ; versus using {} and ; could be useful. I don't think it has to be comprehensive. If another language decides to use .kk, then they will have to add enough samples to distinguish from Koka's syntax, which is unlikely to be hard - since Koka has some unique features and keywords.

@lildude I believe this is ready for re-review