Use the bf.style standard for code formatting

[aartaka]

Hello @baris-inandi,

I've seen your repository on r/brainfuck and decided to reach out. I was especially interested in the formatter part of the toolkit. What are the formatting rules you're using? I see there is nested indentation for loops and spacing around I/O characters, but can you specify the exact behavior?

I also suggest that you rely on battle tested and de-facto standard bf.style formatting and its bundled format.bf script as a benchmark. This way, we will have more consistent indentation styling and code reusability in the Brainfuck community 🤗

Best of luck,
Artyom Bologov,
Community Manager,
Brainfuck Enterprise Solutions
One step ahead of the future

[Rudxain]

Brainfuck Enterprise Solutions

I thought this was an April Fools joke, but it's serious business! I approve this 👍

[baris-inandi]

Hi,

The current version does not adhere to any standard, the styling is based entirely on what I think was "easy to read" bf code. I'll definitely look into bf.style and see how I can implement it in bfgo.

[baris-inandi]

Quick update: I implemented memory-dumping to use bf.style. It currently only works in interpreter mode. This feature will have to be implemented for the three compile targets (Binary, JVM, JS) separately. I don't think I will be implementing that soon.

Before we continue with this, I have one concern @aartaka:

It may be too many levels of abstraction. Since bf.style is written in bf itself, we will have to interpret it using bfgo's interpreter (which is, admittedly, not that fast). I am inclined to assume the current Go implementation will be significantly faster.

However, we can simply make bf.style a new subcommand (maybe --bfstyle?) without removing the current Go implementation if the performance does end up being a major concern for bigger files (especially since there are a lot of big bf programs).

[baris-inandi]

That being said, I want to be able to actually execute bf.style, which I could not yet. I implemented -mem which dumps data into the bf memory in order to use bf.style. I found this on @aartaka's repo:

 Memory layout is:
 [^bracket count] [case flag] [char] [char copy]

However, I don't quite understand what any of this means. Can you please explain how I should format the memory to get the desired output? I tried replacing the BF tape with the code I wanted to format. It did not work.

BTW, I am planning to remove -mem as it complicates things with the minifier (#2) and since it does not support any compile targets at all (it is interpreter-only).

[aartaka]

Quick update: I implemented memory-dumping to use bf.style. It currently only works in interpreter mode. This feature will have to be implemented for the three compile targets (Binary, JVM, JS) separately. I don't think I will be implementing that soon.

No hurry, it's a hobby open source project, I get it!

It may be too many levels of abstraction. Since bf.style is written in bf itself, we will have to interpret it using bfgo's interpreter (which is, admittedly, not that fast). I am inclined to assume the current Go implementation will be significantly faster.

While bf.style is indeed a BF file itself, it's not meant for execution. And it will do nothing given to being a single comment loop. So you don't have to evaluate it, you can simply implement the rules it specifies in your tool. The rules are exhaustively documented, so it should be easy enough to translate them to code (at least bundled format.bf did.)

However, we can simply make bf.style a new subcommand (maybe --bfstyle?) without removing the current Go implementation if the performance does end up being a major concern for bigger files (especially since there are a lot of big bf programs).

That's an option too, but see above: you don't have to evaluate Brainfuck code for formatting if you implement the rules in Go.

[aartaka]

 Memory layout is:
 [^bracket count] [case flag] [char] [char copy]

However, I don't quite understand what any of this means. Can you please explain how I should format the memory to get the desired output? I tried replacing the BF tape with the code I wanted to format. It did not work.

format.bf (which I'm assuming you're trying to run) reads standard input and formats it. So putting things in memory does not work—you have to provide the code as input when evaluating format.bf. That's what the file comment loop says too.

The initial memory should be all blank, and the memory layout above is the one used by format.bf internally for its bookkeeping. In particular,

• bracket count tracks the loop depth (which, as bf.style specifies, determines the indentation level).
• case flag is used in a switch/case statement to compare the character just read to some constants and decide how to change program state. For instance, newlines mean printing the indentation, brackets mean increasing/decreasing bracket count.
• char is the place where characters are read and processed.
• char copy is a temporary memory cell to store the copy of the char when doing destructive actions on it.
• The cells beyond the ones above are irrelevant and can be filled with anything, as long as these four start out zeroed.

BTW, I am planning to remove -mem as it complicates things with the minifier (#2) and since it does not support any compile targets at all (it is interpreter-only).

Not forcing you to either decision, I'm alright with any. As long as it conforms to the standard, of course 😌

[aartaka]

The important section you should look at when implementing your own formatter is 1.2.1 LOOP INDENTATION. That's basically all you need to make a proper auto-formatter. The rest of bf.style is aimed at human programmers in the hope of promoting a readable and maintainable code.