Rejected assembler features

These past weeks have been spent fervently working on the backlog of university tests and assignments that have been haunting me, but in the quiet gaps I’ve been able to make steady progress on the new Bedrock specification.

Messing around with the Bedrock assembler

I made a post on Mastodon back in September about maybe making a change to how string parsing works in the Bedrock assembler. The issue I was trying to solve was that it isn’t possible to put a quote character inside a string literal if that character is also the delimiter for that type of string.

A bit of context

The assembler provides two types of string: 'this one', which uses single quotes and assembles to the character values as-is, and "this one", which tacks a null terminator onto the end. If I want to put a single-quote character inside a terminated string, there’s no problem, because the string is delimited with double-quotes. But if I want to put a single-quote inside an unterminated string, there’s a big problem, because the character would prematurely end the string. The only way to get around this is to end the string when you need to use a quote character, then type out the hexadecimal value representing the character, and then start a new string to hold the rest of your text. This works, but it looks quite bad:

'This is how it' 27 's done.'  ( This is how it's done. )

Of course, you can always use a terminated string instead with no issues, and it’s likely that you’d want one in your program anyway. Almost any time that you use a string in a Bedrock program it’ll be a terminated string, because if there’s no terminator there would be no way for the program to figure out where the end of the string is at runtime.

"This is how it's done."

It’s still not a perfect solution because you still can’t use double-quote characters in a terminated string, but hey, it’s the best we’ve got for now.

Maybe add some new syntax?

The fix that I proposed was to change the assembler so that having two consecutive quote characters inside a string would be treated as inserting one quote character into the string there, without ending the string. It doesn’t look too bad, and it’s less complex than using a backslash character to escape the quote (because backslashes would need to be escaped as well).

'It''d look like this.'  ( It'd look like this. )
"Or like ""this"" one."  ( Or like "this" one. )

I was all for this for a couple of weeks, but I’ve slowly changed my mind back to preferring the original unmodified syntax.

The problem is that the proposed string syntax would require assemblers to look ahead when parsing strings, checking the next character to see how the current character should be interpreted. It’s not that much work to do, but it does add a bit of complexity to the specification for not all that much gain. The driving purpose of the Bedrock assembler is to be ergonomic enough to write complex programs without getting all tangled up. It isn’t supposed to be the best assembler, it’s only supposed to be good enough for most things, while still being simple enough to hold in your head and to implement.

It’s a tricky balance, because simplicity can easily be taken to an extreme. The guidelines that I’m using to evaluate any changes is that any extra piece of complexity needs to make it significantly easier to write programs than it would be without it. The biggest pieces of complexity in the language at this point are probably local labels and blocks, which allow much better code organisation and the easy creation of anonymous functions and strings, respectively. For this change, with quotes in strings, I just don’t think that the added complexity is worth it: in however many thousands of lines of code I’ve written for Cobalt, I’ve never found myself needing or wanting this quotes-in-strings feature, it just hasn’t been something that’s ever come up for me.

While writing all this I thought that it might be worth going the other way and simplifying the word-token parsing rules, because word tokens require a one character look-ahead in order to break before reaching a [, ], (, ), {, }, or ; character. I almost committed to stripping this out, because there’s no real reason why allowing these characters to directly follow a word token without an interleaving space would make it easier to write programs. I quickly remembered why I added this in the first place though: if I remove it, it would mean that code that looks like PSH:00(zero byte) would be parsed as PSH:, 00(zero, and byte), where the author clearly intended there to be a comment following the zero byte and just forgot to put a space. Is this important? I dunno, I’ll think on it some more. It sure would be nice to simplify the assembler even more if I could.

Nested strings

There was one more change I considered for the assembler, which was to make it possible to have nested comments. Instead of stopping a comment at the first ) character found, there could be a counter that increments for each ( and decrements for each ), ending the comment once the counter reaches zero. This would make it possible for people to easily comment out blocks of code during development, even if that code contains its own comments.

I think I’ll reject this one too though, for the same reasons as before. The comments at the moment are perfectly functional, and I’ve not really felt the need for the feature, even if it would be simple enough to implement. Add even just a bit of complexity, and the assembler specification gets way more complex.

Thanks

I’ve got to run now, I don’t get a reprieve from being busy just yet. Thanks for your continued support, it’s a great motivator. Have a great week!