Skip to content

Specifying language #136

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
niemela opened this issue Nov 29, 2023 · 2 comments · Fixed by #160
Closed

Specifying language #136

niemela opened this issue Nov 29, 2023 · 2 comments · Fixed by #160

Comments

@niemela
Copy link
Member

niemela commented Nov 29, 2023

Related to #132.

In the list of programming languages we define "file endings" for all languages. The implication is that this is how we determine what language should be used. For input/output validators we also allow build and run scripts, so oddities can always be handled, but that is not (and should not) be supported for submissions.

There are already collisions in the set of commonly used languages. Specifically Python 2 and Python 3 actually has the same file ending. In the legacy version we require a shebang to distinguish, in 2023-07-draft we currently require .py2 for Python 2. I would argue that both of these are workarounds, and further that the latter is even worse. What is good is that it defaults to Python, and you only have to do strange things if you want to use Python 2 (which you normally shouldn't).

I think that we opted for these workarounds because: 1. they are almost not needed anyway, it's just Python, and 2. the other (obvious) option is to have some kind of metadata file specifying this, and we wanted to avoid that if possible.

Regarding reason 1:

  • There are actual languages that share file endings, where one is not (more or less) a "deprecated" version of the other (i.e. Python 2 vs Python3). One such example is Objective-C, Octave and Matlab. Kattis currently supports both Objective-C and Octave.
  • On Kattis we already have some additional "languages" that share file endings. E.g. "C with GMP", "C++ with GMP", "C with Memory Check", "C++ with Memory Check", "Python 3 with NumPy".

Regarding reason 2:

  • If we store end endpoint information discussed in Specifying entry point #132, we could store this there as well. I.e. if there already is some metadata file then the additional cost for using it for this as well is minimal.
@niemela
Copy link
Member Author

niemela commented Dec 1, 2023

I'm leaning quite strongly towards piggybacking this on the "expectations" framework (see #135), just like with #132.

Specifically, add a language property to the "filename globs" in the YAML file of the expectations framework, and call that file submissions.yaml (due to the now extended use):

# submissions.yaml
accepted/sol2.py
   language: python2

Thoughts?

@Tagl
Copy link
Collaborator

Tagl commented Dec 5, 2023

Seeing as python 2 is EOL for a long time now, perhaps Prolog and Perl are better examples of a conflict. Two very different languages but same extension (.pl) used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants