Very often when functional programming we specify the types first. Then once that’s done, we implement the term. Writing some tricky code? First, write out the type! By announcing (some) aspect of our intent to the compiler, we get an “accountability partner” that will verify we’ve remained true to our declared intent. That’s one part of it. But as Conor McBride likes to emphasize, types aren’t just about policing errors or checking:
Twitter has a problem with abuse. Everyone knows this. I’ll explain the core issue, and then explain one way to fix it.
I finally wrapped up most of the housecleaning I wanted to do before releasing the code. It’s now public on GitHub and there’s also a dedicated project site and blog at unisonweb.org and Twitter account. Going forward, I’ll be posting about Unison from unisonweb.org, and any contributors to the project will also be able to use that space for Unison-related posts.
As I mentioned in update 6, I’ve been spending the last few weeks doing some much-needed refactoring. Here’s an update on the progress:
No new screencasts to show this week. I’m in the middle of doing some much-needed refactoring. What happened? As of the last update, I had a decent expression editor. The missing final piece was adding a declaration layer to the editor, allowing a Unison panel to be edited much like a module in a regular programming language.