https://github.com/robrix/tilec
Sometimes when I feel sad I implement a dependently typed lambda calculus.
https://github.com/robrix/tilec
compiler dependent-types
Last synced: 11 months ago
JSON representation
Sometimes when I feel sad I implement a dependently typed lambda calculus.
- Host: GitHub
- URL: https://github.com/robrix/tilec
- Owner: robrix
- License: bsd-3-clause
- Created: 2020-02-27T12:51:21.000Z (over 6 years ago)
- Default Branch: master
- Last Pushed: 2020-03-26T23:55:51.000Z (about 6 years ago)
- Last Synced: 2025-05-06T22:02:26.356Z (about 1 year ago)
- Topics: compiler, dependent-types
- Language: Haskell
- Size: 1.51 MB
- Stars: 15
- Watchers: 4
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
- Code of conduct: CODE_OF_CONDUCT.md
Awesome Lists containing this project
README
# `tilec` — the tile programming language (and eventually, its compiler)
tile is a dependently-typed programming language, but this package is mostly an experiment in language and compiler engineering.
I have some aspirations to quantitative type theory, higher-order unification, responsive compilation, levitation, and whole-program optimization, but for now I’m just trying to find my footing; don’t expect to be able to write programs in this any time soon.
# Language notes
There is no syntax or parser right now. tile programs can only be defined as Haskell expressions.
tile is very small: variables, lambda abstractions & applications, one base type (`Type`), and dependent function types. While dependently-typed, tile is not intended to be a consistent logic, in part because I don’t know how to write a termination checker yet. Once I learn about that, I might reconsider, as long as I haven’t painted myself completely into a corner w.r.t. its needs.
tile does not have datatypes. The intention is to levitate definitions using Böhm-Berarducci/Mendler encodings instead. I intend there to eventually be be syntax sugar for defining datatypes & pattern matching using these methods.
Likewise, tile does not have (much of) a metalanguage. The intention is for modules and such to be modelled as (possibly parametric) records (which tile also does not have), themselves encoded as described above.
Various parts of this plan might be poorly-thought-out, intractable, what-have-you; that’s ok! The goal is to see what I learn from the process, not to have all the answers already.
# Development
Make sure you have a recent enough `ghc` and `cabal`; I’m currently developing with `ghc` 8.8 & `cabal` 3.0, and I’m not testing against older versions. On macOS, I recommend `ghcup`.
I do just about everything via `ghci`, which can be conveniently initialized and launched as follows:
```
cabal build # make sure dependencies are known & installed
script/repl # actually launch the repl
```
`ghcide` integration is also provided, and I edit in VS Code configured to use it.
# Architecture
Broadly, `tilec` is designed to use (untyped) tagless final encodings of DSLs wherever feasible. That means typeclasses for bits of syntax, with instances providing algebras, rather than datatypes & pattern matching.