Current Projects

To help with organization and visibility, this page gives a summary of potential and active projects around Gator. These projects are a bit broader than just 'issues', and might involve other external repositories. If you have questions about what each project means or if there's something I should be adding, let me (Checkmate50) know!

Projects are divided into approximate areas of work. Within each area, I've roughly sorted projects by priority (higher is something I think is more short term urgent or important). I've included a short summary of each and whether or not they are active (have someone currently assigned to work actively on each) -- note that 'inactive' projects are usually those I'm looking to have someone join on! I've also included my guess for the complexity of a project, very roughly based on the Software Foundations problem difficulty ratings:

• * Good starter project; can make useful progress with little background or huge amounts of effort
• ** Reasonable project for a semester or less; you need some background and will take time, but shouldn't be insane.
• *** Tougher project for at least a semester of work; I expect substantial learning and time will be needed to make real progress.
• **** Paper-worthy project; I currently believe that this project has the potential to be a paper by itself, requiring lots of motivation.

Application-y

1. * Shader Implementation (inactive)

Gator can perennially use more shaders being added to its suite of examples. The Gator game project is a long-term repository of such examples, but the example folder can always use expansion. Concretely, I am working to add sufficient examples to support the actual Gator paper.

2. ** Gator Tutorial (inactive)

Gator is hard to learn; users both need to get a sense for graphics programming (which is notoriously difficult) and Gator's geometry type system. We need a central tutorial that explains these ideas in a clear way.

3. ** User Study Website (active)

Related to a tutorial; we would like to be able to experiment with whether or not Gator is actually helpful for expressing graphics programs and preventing common bugs. Designing a website for this seems like the best approach and would be very cool to work on. I'm working somewhat on this, but marking it as inactive since it's not my main focus.

4. *** Game Engine in Gator (inactive)

The Gator-game project needs to be revived a bit -- the initial engine exists, but requires some fixing, and examples need to be pulled together properly. The goal here is to show that Gator can be used for large-scale programs and to help discover real issues with our compiler.

5. *** Scientific Computing with Gator (inactive)

I'm interested in exploring applications of Gator to scientific computing libraries and calculations. The main goal of this project right now would be to find real examples and how they can be encoded with Gator's types.

Compiler-y

1. * Test bench update (inactive)

Our test bench for Gator just...doesn't work right now. It would be cool to have a proper test harness, but even more basic would be to just salvage relevant test cases from the current test folder. These are all written in the old Linguine/Lathe language, so it will require some learning to figure out what they mean and what can be reused / tossed.

2. ** Javascript Compiler (finished!)

We need to update our support for compiling Gator code to JavaScript. This was working in Linguine / Lathe, but simply hasn't been updated to match Gator's updates and style. Marked harder since this requires design considerations with how to write JavaScript reasonably in Gator.

3. * Documentation (inactive)

Gator has exactly no formal documentation, which should be fixed.

4. **** in Expression Optimization (inactive)

We currently make no effort to optimize in expressions, either with redundant code elimination or by lifting operations. There are some simple hacks here, but there seems to be a more interesting problem in how these optimizations can and should be done. Graphics in particular provides an interesting domain problem with pipelines and limited memory.

5. ** Dimension analysis types (active)

Gator conceptually supports types for physical properties, such as meters, seconds, etc... It would be cool to add more explicit support in the form of type operations (* and /) for reasoning about dimension analysis.

6. **** Pipeline Language Design (active)

How can we design a language (maybe Gator?) to reason properly about types and values through a pipeline? There have been a few attempts (e.g. Braid and sorta Spire), but I'm not satisfied with using these for graphics programming for various reasons.

Theory-y

1. **** Path Independence (finished!)

How are we sure that our choice for path with in expressions is correct? Would another produce different results? We need to show that these paths are independent to be sure, which turns out to be a hard problem.

2. **-*** Gator Types in other Languages (inactive)

Can we write Gator-style geometry types nicely in other languages? Targets of interest include Haskell (almost certainly), C++ (template hacking is weird, so yes?), and Java/TypeScript (...maybe? Seems hard).

3. **** Reactive Programming Verification (active)

A project in-development to help reason about whether or not data is updated properly in looping or real-time code. Ask me for details if interested.

4. **** Formalizing Geometry Correctness in Linear Algebra (inactive)

It would be cool to formalize geometry correctness in the context of linear algebra, which is one of the informal promises of Gator. This would probably entail coming up with a formal semantics for geometry as defined by Gator (i.e. coordinate schemes and reference frames as applied to geometry objects), and what it means for an operation to be geometrically undefined. Notable problems here include figuring out how reference frame dimensions interact with transformations and how geometry objects can have an intuitive notion of correctness.