- Cabal/stack plugin: Live at spinda/liquidhaskell-cabal with a demo at spinda/liquidhaskell-cabal-demo.
- Publish to Hackage: All ready on my end, but I’m currently blocked awaiting a new release of LiquidHaskell to Hackage containing the tweaks I had to make to the source to get this to work.
- Improve LH’s CLI output: Right now LiquidHaskell’s output is pretty noisy, and that doesn’t fit in well with the rest of the Cabal output. I’ll work on improving this when I get a chance.
- Improve multi-target support: The Cabal plugin uses LiquidHaskell’s existing support for checking the correctness of multiple modules, passing it all the source files in the project at once. At the moment the implementation of this is rather naive, rerunning the entire pipeline for each module and doing more recompiles than it needs to for each module. As part of the ApiAnnotations work (see below) I’m going to change this so we check all target modules in a single pass instead.
- Ambiguity error in Bare: Really simple, there’s a spot where we’re resolving names and if there’s more than one possible match we pick the first one. Instead we should be throwing an error about ambiguity. See issue #525.
- ApiAnnotations: Have LiquidHaskell extract comments via GHC’s ApiAnnotations interface instead of parsing them out ourselves; see issue #617. At the moment LH does a recursive parsing thing to identify all the modules and source files it needs to process, parses in all the specifications, and then loads the modules into GHC. I’ll need to change this so that the parsing happens after each module is loaded into GHC in order to use the ApiAnnotations interface. While I’m making this change I can improve our support for multiple target modules. This will also lay some groundwork for the .lqhi changes (see below).
- Package DB version check: Issue #612 seems to have caused by a case where the version of GHC LiquidHaskell was compiled with was trying to load in an interface built by an older version of GHC. To guard against this I’ll add a check to make sure that the GHC version in the environment’s package database matches what we expect.
- .lqhi intermediate files: In processing imported modules, LiquidHaskell needs access to information that is only available when GHC has just finished compiling that module. As a result, for each target module, it currently recompiles all the recursive dependencies of that modules every run to get at that information. In my GSoC ‘15 work I implemented a feature where this information is saved to intermediate .lqhi files after each modules is processed and quickly loaded back in when needed in a future run. This is currently stuck on my outdate fork, however, so I’ll need to port it over to the current version of the codebase.
- Get it working with files first: The first iteration will create the .lqhi files and load them back in when they’re needed. This will require that LH’s specification-extraction pipeline process each module independently instead of smooshing them together and extracting everything all at once. The ApiAnnotations work will accomplish part of this.
- Move to GHC Annotations: Once the GHC plugin is in (see below), transition this to store the intermediate information in GHC Annotations, inside the Haskell .hi files, instead.
- GHC plugin: Another thing I did in my GSoC fork was make LiquidHaskell work as a GHC plugin instead of a standalone executable. I’d like to get that finally ported over and merged into
master, as an alternative entry point instead of replacing the CLI interface altogether. I already have a work-in-progress copy of this that’s functioning in some cases, but it still has a ways to go (and needs the .lqhi stuff to be implemented) before it’ll be ready for real use.
- Merge common code: My current version has its own modified copies of code used in the CLI interface. I need to unify these again and have them using a common interface/code.
- Fix name resolution: There’s a bug where names in imported modules need to be fully qualified. I’ve solved this same bug before; I just need to track it down and do it again.
- Unify with CLI: At some point I’d really like to turn the standalone CLI interface into a wrapper around the GHC plugin. Essentially it would run GHC on the target modules with the LH plugin enabled. Then the separate .lqhi files could disappear entirely in favor of information storage in annotations in the .hi files.
- Testing: I need to get the GHC plugin integrated with our test suite, which is currently built around the CLI interface. The “Unify with CLI” step would remove the need for any extra work here.
- Find and fix
<interactive>error: There’s a pesky (GHC?) bug where, in certain cases, triggering an error on our end will cause GHC to try to read a non-existant file called
<interactive>as it tries to generate the error message. I’ve tracked this down to an exception throw in a particular of code in GHC, but I’ll need to do a lot of walking up the stack from that exception to see what’s catching it and ultimately producing the error.
- Fix test setup, drop
idirsCLI flag: LiquidHaskell currently has a command line option to specify include directories for GHC to look in when compiling the module source. This shouldn’t really be separate from the
--ghc-optionflag we already support to pass options to GHC, but it’s necessary right now given the way the test suite is set up. Once the Cabal/stack/GHC plugin support is landed, I’d like to (at some point) rework the test suite to use one of those instead of the manual test runner, then drop support for this flag once nothing else needs it.
- New parsing: A longer-term project is to replace the current parser, which has its fair share of weirdness and error cases, with a new version based on the one I implemented in my GSoC ‘15 work and using
parsec. This is a slog to get through and very prone to inducing burn-out, so I’m prioritizing other things above it for now. But it’ll also be a big help, so I want to get it done eventually.
After doing Google Summer of Code last year, this is my first year of applying for internships. So I’m nervous-yet-excited, and am really hoping that resumes actually get looked at as I don’t have any “employers” to put down so far.
Places I’ve applied to:
- Mozilla in Mountain View – open source, makers of Firefox and Rust! This is kind of my dream job.
- Adobe in San Jose – they’re really easy to get to from home, which is great since I don’t have my driver’s license yet.
- Yahoo in Sunnyvale – also very reachable.
- Facebook in Mountain View – one at WhatsApp, where they use Erlang! And two elsewhere in the company.
Lesson learned: if you have a Facebook account, make sure you log in before applying,
and use Chrome – the “Skills” field is currently broken on Firefox(this seems to be fixed now). Also, some fields have character caps that aren't apparent unless you proceed to the next page and then go back.
Places I’ve looked at:
- Jane Street – it’d be fun to work in a functional language like OCaml, but they only have positions in NYC, London, and Hong Kong.
- Galois – another FP (Haskell) shop that’s too far away (Portland).
- Google – they’re all closed up for the summer internships. I’ll have to apply earlier next year.
- Nest – lots of positions open, but the closest office is in Palo Alto, which lacks good public transportation to and from San Jose.
- Twitter – again, the nearest office is in-state but not close enough (San Francisco).
As it turns out, location is a major limiting factor for me. I definitely need to start driving soon.
- LiquidHaskell – I’m continuing to contribute to the LiquidHaskell project at UCSD, working to improve the overall usability of the system for real-world projects. Currently this means adapting the new parser I wrote a while back to the current state of the codebase, which has undergone some significant refactoring recently. I’m also implementing an “unparser” to go along with it – a pretty-printer exclusively for turning the AST back into formatted (and colorized!) code, whose output should be parseable back to an AST that is semantically equivalent to the input. Progress is here.
- Unreal Engine – I’m learning/experimenting with Unreal Engine 4. I have two loosely-defined ideas of things I want to make, but I’m mostly exploring what the tools can do right now. This also has me dabbling in 3D modeling, 2D design, and animation. I’m posting little screenshots and video snippets to my Twitter account, which is actually being used for stuff now.
- School – A lot of school! Classes, homework, studying. I miss winter break.
- Internships – I applied to my first internship yesterday, at Mozilla! I'm hunting for more places to apply to right now.
- New site – Not exactly something I'm “working on” right now, but I have a new design up for my personal page. I really like this one; it was a fun challenge to get the scattered links to position themselves nicely across different screen resolutions.