[Alan] Add some more Alan programs

[andreasstamos]

I added some more programs for Alan (mergesort, mergesort with recursive merge, binary modular exponentiation, knapsack). I also transcribed the Alan code to Python by making as little changes as possible so as to be able to then test its correctness. One can run the FILE_test.py and it will print OK if the tests pass (or an AssertionError if the tests fail). When we complete the Alan compiler, we will be able to test the Alan executables by just changing the CMD variable from the Python file to the Alan executable file.

What's more, I created the necessary file alan.vim to make VIM be able to do syntax highlighting when editing Alan code. Although it is yet not perfect and could take some improvements. One can install it by copying alan.vim to ~/.vim/syntax/ and then writing 'au BufRead,BufNewFile *.alan set filetype=alan' in ~/.vimrc.

[kostis]

Thanks for your PR!

Please change all the shebangs from #!/usr/bin/python3 to #!/usr/bin/env python3 which is more portable, and then I'll merge this.

PS. It would have been better to do separate PRs for the programs and for Vim syntax highlighting (because conceptually they are independent additions to the repo), but it is OK, I guess.

[kostis]

I've given this PR a bit more thought and I think it will be a mistake to merge it as is.

Even though this creates a bit more work for both you and me, what I suggest happens is the following:

1. You create a new PR with the VIM changes and we merge it directly.
2. You leave in this PR only the .alan programs (which should be placed at the programs dir, thus following the structure of other programs dirs for all the remaining languages - see also the top-level README).
3. The Python programs are not Alan-related in any way. They are just programs to try to compare results with these example programs, right? For this we need some other, more general, infrastructure. (And we can discuss this separately, in a possible third PR, if you still feel it's worth it.)

Thanks again for your contribution!

[andreasstamos]

Ok. I believe I did 1,2.

Now regarding 3, my thoughts were first of all, that the Alan codes had to be tested now that we still don't have the compiler (the worst thing we would want was incorrect tests), and, second of all, that whenever we complete the compiler, we would need some kind of way to automatically test that the programs do what they are supposed to do and not just that they compile successfully. (I could have written text files with input/output test cases, but random testing seemed more interesting.) What ideas are there for more generic infrastructure for testing?

[kostis]

Yes, of course we need to test programs, but this infrastructure is generic, not Alan-specific. For example, similar programs could exist for Grace (the language of the 2023 instance of the course) or previous ones. So, the Python programs could, in principle at least, be used to test the corresponding Grace mergesort program.

What ideas are there for more generic infrastructure for testing?

Let's take this discussion somewhere else (e.g. in Issues or once you open the Python test PR). For some months now, there is another PR (#12) that I wanted to generalize to multiple languages before it gets merged into the main repo.

I will merge (and close) this PR now -- let's continue this elsewhere.

Thanks again!