I’ve been talking about my secret project for a while now. It’s certainly a secret no longer. It’s time you got a proper update.
Here’s a screenshot I made a few months ago, for the homepage:
This is what I know:
Eventually I’d like to have most of a Scratch editor, with support for importing & renaming of costumes and sounds. I still need to implement variables and lists. For now, there’s just a (fancy) code editor.
Syntax highlighting works: blocks are highlighted using the category colours from Scratch. This actually requires a full-blown parser; unlike most languages just highlight based on only the kinds of expression (such as numbers and strings), tosh highlights based on the commands. And commands have a reasonably complicated grammar, so writing that has been interesting.
Auto-complete is mostly working, with bugs; it needs rewriting a third time. And designing usable completion is harder than you’d expect.
I came up with a way of doing completion directly based on the language’s grammar. Assuming the principle is actually sound (I haven’t proved it correct) it might in fact be a novel technique.
tosh will support any Scratch project: you’ll be able to create a project entirely in tosh, or import an existing one, or export and edit in Scratch and then re-import, and finally export your creation to an
.sb2file and upload it to scratch.mit.edu.
Allowing both import and export causes some interesting design issues, particularly variable names. I’ll write more about that later.
tosh will use Scratch 2.0 files only. No 1.4 support.
The language will be exactly Scratch: “write blocks as you’d read them”.
I experimented with various extensions, such as using
=for assignment, but I decided against them. I’m clear about sticking to this principle.
tosh embeds phosphorus to play Scratch projects.
A week ago I finally implemented compiling. Presssing ⌘⏎ compiles the code and runs it in phosphorus.
I put off implementing compiling for a long time, focusing instead on the code editor and parser. Those are the largest parts of the project and hardest to get right.
But I’m glad I did it, because now tosh is much more fun to work on. (Though now I get distracted making silly turtle art projects!)
There’s a lesson here about the virtues of tackling the hard part first vs. making a complete prototype. (One of the two is like the “tracer bullet” technique from The Pragmatic Programmer.) Either can be good, but what you really need is a fun prototype.