Proposed syntax changes for 0.11

Roto
1

So far, 0.11 is shaping up to be a release without significant syntax changes. However, there are some things that I’d really like to change. This includes reverting some previous changes. That’s why I’d like to gauge what people think, so we don’t create unnecessary churn for unpopular changes. I’d also like to talk a bit about the considerations here.

The Changes

Comments with //

I keep mistyping comments myself because curly-braced languages usually have comments with //. So I’d like to revert back to using that. I know I changed this just a few releases ago, but # just doesn’t feel right in the end.

In the future, we can expand this more easily to doc-comments (///) and block comments (/* … */).

From variant to enum

The first reaction of everybody I have talked to about variant types was “why did you call it that?” And you know what, that’s fair. The enum is fairly standardized across languages and is immediately recognizable for Rustaceans.

Negation with !

This is a similar change to the comment change: curly-braced C-style languages usually have ! for negation instead of not. This also makes it more consistent because we have symbols for other boolean operations as well, such as && (instead of and) and || (instead of or).

Match with =>

Rust’s match syntax uses =>, which I found a bit weird, so when I implemented match in Roto, I changed it to ->, but that seems to diverge unnecessarily from Rust.

The Bigger Picture

All of these changes bring Roto closer to Rust. That’s both good and bad. Let’s start with the good: Roto will be easier to pick up for Rustaceans.

However, Roto should also have its own identity. The more Roto looks like Rust, the more people expect Roto to work like Rust and that might lead to issues where they diverge. A second problem is that Rust is not necessarily a language that Roto users might be familiar with.

I find it tricky to find a balance here. The current syntax was an attempt at merging the syntax of several languages into something that I thought fit Roto, but small divergences from Rust only seem to confuse.

Feel free to chime in with any opinions! Do you agree with the changes? How do you want to see Roto evolve? Are there other syntax changes that you’d really like to see?

1 Like
2

I think it’s important to know what Roto wants to be.

There’s no direct harm in sticking with a Rust-like syntax, especially as a companion language to Rust. But when syntax features look similar but behave differently, this may confuse users.

enum is better than variant, because I would consider an “enum" to consist of multiple “variants”.

The way I see it, ! is a unary operator, and not is a keyword of sorts. If it acts like an operator it should probably look like an operator. Especially considering the other boolean operators are already symbols.

I like # for comments, but there’s no obvious multiline comment syntax for it. /// does work for doc comments, but does Roto need a dedicated syntax for documentation?

Maybe you should take a step back and look at the bigger picture. Where do you expect/want Roto to be used? And how?

In the olden days a lot of software (especially GNUs) used parser generators absolutely everywhere, often for custom a configuration syntax. Think nftables, collectd, nginx etc.

I think this is one area where Roto could shine, and this is most in line with the Rotonda use as well. The nginx configuration syntax already supports control flows, operators, variable substitution etc. You could see how implementing such a configuration in an actual language could be useful.

A second use-case is how embedded languages like Lua are often used. For instance a lot of game engines use Lua for scripting purposes.

These use-cases are fairly different from each other. In the first you’ll likely want to configure Roto as some sort of DSL. You would use it to declare a static configuration, but there’s little imperative scripting or logic. In the second you’ll use it more like a general language, with a custom runtime.

I also want to note that Lua is quite popular and beloved, even though it’s a minimal language with some weird design choices. I believe its simplicity is key to its popularity.

If it were up to me I’d maybe reach for a RubySpec like syntax with static types. Ruby supports a lot of different syntax styles. This makes it really good for making DSLs. As an example I use it to configure a bar for my wm. I’ve even seen it used to make music.

Anyway, I think I might have gone a bit off-topic here. But I generally think it’s a good idea to consider all the possible use-cases for Roto, and what syntax would best fit those use-cases.

3

In particular it may be useful to think about whether Roto will have a mutable state (as discussed in #245).

In which case, maybe a distinction between “pure functions” and “procedures” could be considered.

A procedure would be a list of statements. These statements may include modifying global state or performing IO.

A function would be an expression. It has access only to the arguments it has been passed. It does not call procedures.

Nim is a language that implements this distinction (as well as any FP).

If Roto were to be used similar to Lua, a mutable state on the Roto side is a must. But for use-cases like that of Rotonda this would cause problems with parallelization.

By making the distinction you are guaranteed that functions are safe to use in parallel. You could even perform memoization of their results.

These kinds of major design choices (top-level code, mutable state, classes, anonymous top-level functions) will inevitably shape the syntax.

4

Thanks for the replies! I’m glad you mostly agree.

For the bigger picture, I think Roto should fit the use cases of Lua. There might be some ways to do configuration with it like people sometimes do in the JS ecosystem, where there is a function that returns a configuration, but that’s about as far as we should go in that direction I think.

Pure functions would be interesting, especially for optimization. But I think we need mutable state in the end. We could indeed go the Nim route there.

1 Like