Three Dollar Quill

In this post:

• Update on Gitless.
• Thinking about syntax files.
• Thinking about Structured Data.
• Thinking about the romance stuff, as well.

This week was a little intense, so I didn't have anything lined up for this post. I do have a grab-bag of not-big-enough-for-a-post things.

Continuing on with trying to use Gitless, it seems entirely adequate for my usage so far. I'm still hitting rough patches using it, but they're not caused by Gitless, and it has no way to notice the ways I'm messing up. (Various permutations of "changing a file over there, and doing repo operations over here". I'm a little disorganized, and a CLI can't just magically fix that.) Meanwhile, one of our development machines (which I'm not shoving random bits of software on, because that would be rude) got into detached HEAD state, which isn't supposed to be possible with pure Gitless.

I'm trying to wrap my head around designing rules for syntax files. I've got this idea at an intellectual level that the syntax files don't need to perfectly capture the tree structure of the underlying code. They need to parse out some of the information inherent in syntactically correct code, and it's nice if they can detect some forms of syntactically incorrect code.

The issue is being able to make judgment calls on what to model and what not to. It's necessary to parse strings correctly, because they can contain patterns of text indistinguishable from source code except by context.

I think I want to think about this in terms of constraints. Function calls, indexing, and collection literals introduce a constraint through matching brackets. Attribute access constrains the right-hand side to be a user-defineable identifier.

I think I'll try using that principle to get back on the syntax file.

And speaking of Python stuff, I still haven't been touching Structured Data. I need to take a few hours some time to go over what I want to do, because it's a little confused. I believe I've mentioned before, the idea of writing optimization code to improve the performance characteristics of match-based functions? I've only thought about that enough to ponder a few issues I hadn't entirely noticed in the first place:

• How to represent a "forward declaration" of a match-based function, so that it's possible to reason about recursive functions in some way.
• Where to put the ADT representations of match structures. This is kind of an aesthetics thing; if you look at the history of the repository, it's probably fairly obvious that I'm often reorganizing code on a whim. I'm trying to keep from having a single monolithic file, but there are various dependencies. I was able to make some progress with the idea of "minimal modules" that don't import anything, or only import modules that don't import anything, but if I put ADT definitions next to their corresponding match classes (which seems a natural place to put them), then suddenly that introduces dependencies imported from the public interface.

It's probably appropriate that "Project: Feature Envy of Rust" is giving me more feature envy of Rust.

Regardless, this reveals some shortcomings in my organizational scheme. I've noticed I've had issues with this before, and tried to find advice, but I feel like I didn't find anything really concrete. Either I'm using the wrong search terms, or nobody thinking about this the way I am has any answers.

I jotted down some romance-related ideas, but my presumptuous opinion as an arrogant STEM dude is that it doesn't make any sense to try to put anything together until I've read some professionally-published stuff and know what I like. Some things that I'm going to have to meditate on are, if I end up writing and publishing something, what name would it be under? would I talk about it in any detail here? exactly who's supposed to be seeing this blog, anyway?

Nothing really specific; I haven't been focusing enough for that, I guess. I think the weather's making me a bit loopy; it's just so humid and unpleasant. Here's to next week.