https://github.com/mheiber/throwaway-scopes

throwaway-scopes
https://github.com/mheiber/throwaway-scopes

Last synced: about 1 month ago
JSON representation

throwaway-scopes

• Host: GitHub
• URL: https://github.com/mheiber/throwaway-scopes
• Owner: mheiber
• Created: 2022-06-29T17:49:24.000Z (over 2 years ago)
• Default Branch: master
• Last Pushed: 2022-08-04T12:04:39.000Z (over 2 years ago)
• Last Synced: 2024-10-16T01:44:13.490Z (3 months ago)
• Language: Rust
• Size: 10.7 KB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# Rough experiment with local type inference in Rust

Ideas explored:

- Rust data structures for local type inference

    - I usually implement program-languagey code with immutable data structures, but that gets weird in Rust.

    - This is an attempt to work with a mutable stack of scopes that is ergonomic, efficient, and safe. I can't yet evaluate whether the attempt is successful.

- I experimented with combining the analysis and checking modes of local type inference (Pierce and Turner, 2000). There is a lot of duplicated logic in the classic Local Type Inference rules, and Rust is verbose enough already. So in this experiment there is just one mode, and the context propagates the expected type, which is an `Option`. I've seen this approach two synthesis/checking before, but I can't remember where.

- *and* I tried type checker error recovery a la Niko Matsakis' [Responsive Compilers](https://www.youtube.com/watch?v=N6b44kMS6OM&t=3121s). This means adding type errors to the context rather than blowing up at a type error, and using a sentinel type for erroneous expressions. 

- And I combined a request for type information (like an IDE might use on hover) with code for type-checking.

# Evaluation

ergonomics:

    - The approach combines a lot of concerns. But the complexity is isolated into a fancy context data structure. So core type checking code doesn't look much different than in a "classic" batch type checker.

    - So far, the approach looks promising to me: the code in the pattern-match inside the main loop, `main::run`, looks pretty vanilla. Emphasis on "so far", since this is a tiny toy.

perf:

- Needs benchmarking. The most ergonomic and safe API I could find for `Ctx` involves a closure for every new scope, but no cloning. Probably OK.

- The string cloning is avoidable (interning) and/or cheapable (SmolStr)

## Try it

`cargo run`

## Status

Quick throway hack. There's only one example and it doesn't exercise all code paths.Some benchmarking would probably be needed if I revisit this, which I probably won't.