eb20ea9b07
We used to represent types with a different constructor for each different sort of type, e.g. there was a constructor `TyFunF` which took two types as arguments, etc. This refactoring creates a new type `TyCon` which has things like `TCFun` and `TCBase` and represents various types as an application of a `TyCon` to some arguments. For example function type `t1 -> t2` would be represented no longer as `TyFunF t1 t2` but instead as `TyConApp TCFun [t1, t2]`. This is slightly more roundabout, and it does make parsing slightly trickier, but it greatly simplifies and shortens code for e.g. unification, extracting free variables, etc. (because what used to be many essentially identical cases now turn into a single case). It also paves the way for #1865, so we have a way to represent new type constructors defined by the user. E.g. if the user defined `tydef Maybe a = Unit + a` then we would represent the type `Maybe Int` as something like `TyConApp (TCUser "Maybe") [TyBase BInt]`. This also means that types like `Int Unit` are no longer a parse error, so we need kind checking to rule out applications of type constructors to the wrong number of arguments; this PR adds such kind checking as well. Having some sort of kind checking is unavoidable when allowing the user to define their own new type constructors (with an arbitrary number of arguments). |
||
|---|---|---|
| .github | ||
| .vscode | ||
| app | ||
| data | ||
| docs | ||
| editors | ||
| example | ||
| images | ||
| scripts | ||
| src | ||
| test | ||
| tournament | ||
| web | ||
| .gitignore | ||
| .hlint.yaml | ||
| .mergify.yml | ||
| .restyled.yaml | ||
| .stan.toml | ||
| cabal.haskell-ci | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| COMMUNITY.md | ||
| CONTRIBUTING.md | ||
| cspell.json | ||
| DESIGN.md | ||
| feedback.yaml | ||
| fourmolu.yaml | ||
| hie.cabal.yaml | ||
| hie.stack.yaml | ||
| LICENSE | ||
| NOTICE | ||
| pull_request_template.md | ||
| README.md | ||
| scenarios | ||
| stack.yaml | ||
| swarm.cabal | ||
Swarm
Swarm is a 2D programming and resource gathering game. Program your robots to explore the world and collect resources, which in turn allows you to build upgraded robots that can run more interesting and complex programs. More info can be found on the Swarm website.
Contributing
See CONTRIBUTING.md for information about various ways you can contribute to Swarm development!
Building
If you just want to play the game, head over to the Swarm website for installation instructions. If you want to build Swarm from source (e.g. in order to contribute, or to test out the latest bleeding-edge unreleased features), read on.
-
Clone the Swarm repository, e.g.
git clone https://github.com/swarm-game/swarm.git -
If you don't already have the
cabaltool:-
Get the
ghcuptool, a handy one-stop utility for managing all the different pieces of a Haskell toolchain. -
Use
ghcupto install a supported version of GHC:ghcup install ghc 9.6.4 -
Use
ghcupto installcabal:ghcup install cabal
-
-
Now use
cabalto build and run Swarm:cd /path/to/the/swarm/repo cabal run -O0 swarm:exe:swarm(Note that we recommend turning off optimizations with
-O0since they don't seem to make much difference to the speed of the resulting executable, but they make a big difference in compilation time.) -
Go get a snack while
cabaldownloads and builds all of Swarm's dependencies. -
You might also want to check out the
scriptsdirectory, which contains an assortment of useful scripts for developers.