Delimiter-first code

This article points wider use of delimiter-first style in code.

Imagine turning three friends [tic, tac, toe] into three friends ・tic ・tac ・toe. A new top-level syntax is suggested to highlight the benefits of this approach. It’s simple, maintains visual structure more effectively, and could help address common formatting issues in code.

Comma-first formatting

A well-known proposal is to write commas first in languages like javascript, JSON or SQL, which don’t have trailing commas (JS has these days, but not the other two):

While this isn’t the main focus here, it’s interesting to explore why this style didn’t catch on widely.

Critics generally raise two points:

But these arguments don’t quite hold up. Tools can adapt to any notation, so Argument 1 isn’t relevant. And while Argument 2 points to the comfort of familiarity, code culture has already evolved far from typical writing norms. We count from zero, use underscores in names, bend traditional rules for quotes, and use indentation rather than paragraphs to structure text. As tools prove alternative methods work well, they tend to gain traction.

And ultimately, Argument 2 has a deeper flaw:

So when it came to enumerating in a visually distinctive way, ‘usual writing’ uses delimiter-first.

Example

You need eggs, cheese, bread. # ok

You need ,eggs ,cheese ,bread. # sucks

You need a) eggs b) cheese c) bread. # ok

You need 1. eggs 2. cheese 3. bread. # ok

You need ・eggs ・cheese ・bread. # ok

Criticism of delimiter-first style stems from habit and tool compatibility, yet examples in SQL and JavaScript highlight its benefits, and the Haskell community largely supports leading commas, demonstrating its practical value.

Is delimiter a right word?

Delimiter (just as separator) separates items. E.g. in [ 1, 2, 3 ] we have a sequence of tokens:

Collections in HTML

E.g. html allows using start-of-item (<li>) and skipping end-of-item (</li>)

Collections in YAML

Yaml, which focuses on a hierarchy of collections, also uses a delimiter-first approach.

There are 3 delimiters: \n-, \n__- and \n____- (underscore = whitespace). All three delimiters are distinct, and the whole structure now reads as

In YAML and similar markup languages, delimiter-first is standard, as collections end at a higher-level delimiter without requiring end tokens or parsing internal structures—expecting only that contents within a level lack tokens from the current or higher levels, a convention less common in programming languages.

Line should start from \n, not end with it

The blank line between chapters highlights the start of Chapter 2, not the end of the previous text. Similarly, in HTML, extra margins belong to headers, and in lines, we focus on the start of a new line, not the end of the previous one—hence newline instead of endline. This is reflected in a code snippet comparing standard print behavior with one that adds a newline before output.

Results:

Unix’s newline in the end of line

Unix does not use \n as a delimiter of lines. Instead, it is more of line-terminator, because file with text should end with \n. Not doing so would break simplicity of unix tools and simplicity of definitions.

The issue is with the first file, but the second prints incorrectly, a problem solved by newline-first. Starting a file with \n keeps Unix utilities simple and makes it easier to visualize in an editor. While I don't want to switch all files to newline-first, it might have been better if that had been the standard. I suspect newline-last comes from Unix mainframes, but it feels outdated now, as tools like Jupyter and IDEs distinguish new lines from sending messages, something terminals still struggle with.

Using indentation to structure code

Code indentation is available in all major languages, but python (and scala 3, F#, nim, haskell, …) relies on indentation to define logical structure. It can be re-interpret the python code the way it was done with yaml.

The structure was reinterpreted with <lvl1>=\n, <lvl2>=\n____, <lvl3>=\n________.

Some problems with multiline strings

There are places where python allows code to ‘escape’ indentation: continuation of previous line (explicit with \ or implicit with different brackets) and multiline strings.

Continuations are ‘solvable’ with code formatting tools, but not multiline literals:

Output (###### just shows where the line ends):

Delimiter-first pseudo-python

To demonstrate how these ideas come together, I’ll imagine a new pseudo-python language with the same features as Python but focus solely on syntax changes, using a deliberately complex example that includes various arguments, lists, empty lists, strings, multiline strings, method chaining, and logical arithmetic, to show that even a wild mix can be represented clearly without causing a mess.

Structure overall did not change much. Note differences in line breaks \ and multiline strings.

An important distinction: leading commas get the same role as hyphens in yaml: they define structure, their position is not arbitrary.

In new code there is no need in closing brackets (see that yourself by staring at the code more!). So let’s remove closing elements:

Conclusion

Delimiter-first code improves clarity and consistency by emphasizing the beginning of items instead of the end, which makes it easier to understand and work with across different programming scenarios. This method fits well with common practices in markup languages and Unix utilities, showing its potential to make code more readable and better structured.