elaboration-zoo
metaocaml-bibliography
elaboration-zoo | metaocaml-bibliography | |
---|---|---|
23 | 4 | |
562 | 82 | |
- | - | |
5.3 | 4.9 | |
4 months ago | 8 months ago | |
Haskell | ||
BSD 3-clause "New" or "Revised" License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
elaboration-zoo
- Dependent types do’s and don’ts
-
How to implement dependent type theory I (2012)
I've noticed amongst many peers that when going down the type theory/pl theory journey there is a ton of hidden knowledge and context we all find ourselves collecting.
All of this knowledge and context spread amongst a common set of books, papers, blog posts, and git repos floating around the internet.
At the risk of creating yet another partial silo, I decided earlier this year to create a project similar to the [Elaboration Zoo](https://github.com/AndrasKovacs/elaboration-zoo) but focused on a blessed path to MLTT with a number of the desirable language features via bidirectional typechecking.
https://github.com/solomon-b/lambda-calculus-hs
The project is incomplete and my end goal is a website like the [1 Lab](https://1lab.dev) but focused on Type Theory and PL Theory, but I ran low on steam and could use some collaborators.
-
How to implement dependent types in 80 lines of code
Thanks, yeah, I haven't benchmarked the implementation yet, and I see the repeated substitution happening. Would the NbE approach where we have indices for terms and levels for values fix the issue (I believe you wrote the implementation here)?
I find the NbE approach that combines both indices and levels quite appealing. You remain first-order (easier for debugging and etc.), but no need to define substitution now.
-
Online courses that use, but don't teach, Haskell?
If you're interested in dependent types, you might like András Kovács' elaboration zoo, which uses Haskell as the implementation language.
-
A personal list of Rust grievances
I think it's more a reflection of how Rust evolved, and the techniques and approaches known and understood at the time and the strangeness budget they were (understandably) willing to take on at the time as opposed to something inherent. And also sometimes having separate, complicated features for similar things (as opposed to simple features that compose powerfully) can be useful pedagogically as well.
At any rate, this is something I'm interested in, and so that's why it appears so high up on my list. Often you really do want sub-languages for different purposes, but managing how they interact and work together, what is the same and what is different, and how that impacts usability is interesting (and difficult) part. I feel like it should be possible to do this, but it's going to take some work and there's still lots of unknowns.
In technical terms, I'm interested in dependently typed module systems, multistage programming[1], graded modal type theory[2], elaborator reflection, and two level type theory[3]. These all sound pretty intimidating, but you can actually see glimmers of some of this stuff in how Zig handles type parameters and modules, for example, something that most programmers really like the first time they see it!
I do feel like there is the core of a simple, flexible, powerful systems language out there... but finding it, and making it approachable while maintaining a solid footing in the theory and being sensitive to the practical demands of systems programming is a nontrivial task, and many people will be understandably skeptical that this is even a good direction to pursue. Thankfully the barrier to entry for programming language designers to implementing languages in this style has reduced significantly in just the last number of years[4], so I have hope that we might see some interesting stuff in the coming decade or so. In the meantime we have Rust as well, which is still an excellent language. I'm just one of those people who's never content with the status quo, always wishing we can push the state of the art further. This is why I got excited by Rust in the first place! :)
[1]: https://github.com/metaocaml/metaocaml-bibliography
[2]: https://granule-project.github.io/
[3]: https://github.com/AndrasKovacs/staged
[4]: https://github.com/AndrasKovacs/elaboration-zoo/
-
Reference Implementation for MLF
Another option is this algorithm by Andras Kovacs dubbed "Dynamic order elaboration": https://github.com/AndrasKovacs/elaboration-zoo/tree/master/06-first-class-poly . Basically if you are checking a term against a bare meta variable, then postpone the checking until the meta variable has a solution.
-
purescript-backend-optimizer - A new optimization pipeline and modern-ES backend for PureScript.
Special shout out to /u/AndrasKovacs and elaboration-zoo (as well as their various NbE notes) which served as a primary inspiration for the architecture. Can't thank you enough for those resources!
-
Barebones lambda cube in OCaml
Highly recommend checking the first part of elaboration-zoo to see how all this might be implemented, it clears a lot of things up.
-
Peridot MVP
Pattern unification
metaocaml-bibliography
-
Emulating the state of the stack at compile-time using phantom types with Forth as en embedded DSL
There may be something to investigate with multi-stage programming. I know you can multi-stage programming in a host language to ensure that a correctly typed program is produced in the object language (Forth in your case). I haven't heard of that being extended to more complicated properties like stack sanity, but that may be an idea to investigate.
-
A personal list of Rust grievances
I think it's more a reflection of how Rust evolved, and the techniques and approaches known and understood at the time and the strangeness budget they were (understandably) willing to take on at the time as opposed to something inherent. And also sometimes having separate, complicated features for similar things (as opposed to simple features that compose powerfully) can be useful pedagogically as well.
At any rate, this is something I'm interested in, and so that's why it appears so high up on my list. Often you really do want sub-languages for different purposes, but managing how they interact and work together, what is the same and what is different, and how that impacts usability is interesting (and difficult) part. I feel like it should be possible to do this, but it's going to take some work and there's still lots of unknowns.
In technical terms, I'm interested in dependently typed module systems, multistage programming[1], graded modal type theory[2], elaborator reflection, and two level type theory[3]. These all sound pretty intimidating, but you can actually see glimmers of some of this stuff in how Zig handles type parameters and modules, for example, something that most programmers really like the first time they see it!
I do feel like there is the core of a simple, flexible, powerful systems language out there... but finding it, and making it approachable while maintaining a solid footing in the theory and being sensitive to the practical demands of systems programming is a nontrivial task, and many people will be understandably skeptical that this is even a good direction to pursue. Thankfully the barrier to entry for programming language designers to implementing languages in this style has reduced significantly in just the last number of years[4], so I have hope that we might see some interesting stuff in the coming decade or so. In the meantime we have Rust as well, which is still an excellent language. I'm just one of those people who's never content with the status quo, always wishing we can push the state of the art further. This is why I got excited by Rust in the first place! :)
[1]: https://github.com/metaocaml/metaocaml-bibliography
[2]: https://granule-project.github.io/
[3]: https://github.com/AndrasKovacs/staged
[4]: https://github.com/AndrasKovacs/elaboration-zoo/
-
Literature about mixing compile time and runtime code.
Also interesting to look at is multistage programming.
-
Useful Type-Aware Macros
In addition to the other things posted here, there's also a bunch of interesting work done in MetaML and MetaOCaml. A bunch of this work is documented in the papers listed in the metaocaml-bibliography.
What are some alternatives?
StepULC - Efficient and single-steppable ULC evaluation algorithm
genawaiter - Stackless generators on stable Rust.
pi-forall - A demo implementation of a simple dependently-typed language
tinka
peridot - A fast functional language based on two level type theory
higher-order-unification - A small implementation of higher-order unification
iterator_item - A syntax exploration of eventually stable Rust Iterator items
purescript-backend-optimizer - Optimizing backend toolkit and modern ECMAScript backend for PureScript
lambda-calculus-hs - Single file Lambda Calculus implementations demonstrating various type system features and interpretation techniques
creusot - Creusot helps you prove your code is correct in an automated fashion. [Moved to: https://github.com/creusot-rs/creusot]
rfcs - RFCs for changes to Rust