Does anyone know which are the Haskell packages which can be used in clash of code?
On CodeWars for example there is a list of packages which have been provided besides base.
Clash or other, the Haskell packages available are the Haskell platform packages for ghc-8.4.3.
Yes, that’s real old.
In details : https://www.haskell.org/platform/contents.html
As we can see, updating to the latest Haskell Platform (8.8) will require a new answer.
2 Likes
A proposal for the CodinGame team and the haskellers around: https://github.com/Chatanga/HaskellCodinGamePlayer
2 Likes
what do the haskellers here think about this?
I would not recommend using Stack in most cases.
Nix + Cabal is better and gives stable/reliable builds, you can install whichever packages you want via Nix + Cabal by getting inspiration from https://www.haskell.org/platform/contents.html
I’d certainly love to have all of stackage at my disposal. We lack libraries all the time, and it’s hard to beat as a large set of libraries that behave well together.
The uncertainty is more around the “will the devs ever get to it”.
It’s hard to propose concrete solutions when we don’t have visibility on the deep requirements. It’s harder to motivate oneself to even suggest anything when all we hear from the devs is that they upgraded every language but Haskell.
2 Likes
If you could get all the packages in stackage in, that would be great haha.
One can dream…
Could you elaborate a bit more? You can replace Nix+Cabal by Stack in your statement and it still holds true, so there is clearly something to add to tip the balance in Cabal’s favor. That’s a genuine question, I do think that using Stack would be simpler here, but I could be wrong.
We need:
- if possible, we would like backward compatibility to avoid to break existing solutions
- the player’s code must be compiled without needing an internet access. For instance, for Rust, we don’t use Cargo (their package manager) but use rustc directly with the libraries that Cargo would download.
- the code must be compiled in a decent amount of time (a few seconds, up to 20s for very complex programs)
- we want something that is very popular among Haskell developers (in term of libs and the impact on the source code). The objective is that a new comer that wants to use Haskell should be able to write code without extra help.
If the solution requires us to execute something to prepare a ready to use environment for any source code, it’s fine.
We don’t have any Haskell skills in the team, so some debates are not clear to us: Nix+Cabal vs Stack, what is possible or not? So we’ll need you to reach a consensus before.
3 Likes
Steps forward! 
Opinions:
The library set would be some subset of stackage to be determined. All of it if feasible (see below).
The former haskell-platform is itself a subset of that, so that part of backward compatibility is covered. As for the rest of it, it’s no different from what the Haskell community has been through these last release cycles: mild, and very well known.
It seems to me all of it would have to be precompiled, we definitely don’t want a complete stack or Nix build at each submit. That’s one part we don’t see too clearly: can we just submit a container file with a complete system? Or define a procedure so that it can be rebuilt periodically? BTW, how often can it be rebuilt? Stackage provides both LTS and nightlies, which can individually be very interesting in their own right.
Building them needs network (towards hackage or stackage or both I’d have to check) to get the packages, but no more AFAIK. Compiling then doesn’t at all.
Our execution environment is a bit old, it was designed before containers became a thing. So we only have a big Debian-based image and we use cgroups + chroot to execute the codes in it. This is what we call “the jail”. In this image you can find all the execution environments for all the languages we support (that’s why you can execute ruby scripts from bash).
Here’s how we currently install Haskell in that image:
wget https://downloads.haskell.org/~platform/8.4.3/haskell-platform-8.4.3-unknown-posix--full-x86_64.tar.gz
tar xvf haskell-platform-8.4.3-unknown-posix--full-x86_64.tar.gz
./install-haskell-platform.sh
ln -s /usr/local/haskell/ghc-8.4.3-x86_64/lib/ghc-8.4.3/ /usr/lib/ghc
Then we simply do: /usr/bin/ghc -w -O1 -B/usr/lib/ghc /tmp/Answer.hs -o /tmp/Answer to compile the file. /tmp/Answer to execute it.
If you can provide the steps to install / compile and run the code, this would help.
1 Like
Perfect!
I’m on it.
Note that the process to build / package / deploy that image is a bit complex and long, that’s why we tend to wait to do several languages at the same time. With the upcoming contest that will start very soon, we won’t update the image during the contest. So take your time, make sure the other Haskell developers are satisfied too.
I’ve forgot to say that if the formatting of the error message changes we might also need to adapt some code to parse the line number and error message.
And we can also improve the default generated code if needed too.
Sure. Speaking of which, how long (s) / large (MiB) am I aiming for?
A more recent GHC, more libraries, I’m not sure how they could not be. 
FWIW, it’s broken now (only one error can be clicked on: the last one). Can’t seriously get any worse.
That would be (well, could be) incredibly great. Anyone who’s seen me on stream knows clearing out the stub is the first thing any Haskeller does on CG.
Whilst I’m certainly willing to help, I feel this is a mostly orthogonal issue.
What’s the specs on this front?
Bonus
What’s the LSP situation?
@JBM I’m also highly interested in getting Haskell upgraded. I can provide some help if you want
1 Like
I hear you. Let’s try and find a channel that fits all.
The image is mounted in RAM so we try to avoid unnecessary stuff. I don’t have a precise number to give you, it must be similar to what we currently have (less would be great, it seems enormous now 
).
That’s going to be hard. We’re missing libraries, and can’t really remove any of those we deem useless if we want backward compatibility.