There are currently three repositories on GitHub associated with Brain-Flak (that I know of) distributed across the same number of users. From an organization perspective I was thinking it might be a good idea to create a Brain-Flak organization and migrate all these repositories to that organization.

https://tio.run/##SypKzMzTTctJzP7/Pzq22qa61q661iY61q72/39DSwVD4/@6KQA
See output

It seems that error messages are inconsistent in how they number characters.

For instance:

(

produces:

Error at character 0: Unclosed '(' character.

while

)

produces:

Error at character 1: Unmatched )

It seems that there is an issue with zero indexing in the error messages.

Currently ASCII input in Rain-Flak is done via the -a command line argument. (example) However other interpreters such as BrainHack and BrainFlog don't have a -a flag. These interpreters use a different mixed IO method that removes the need for flags. (example) Arguments in quotes are parsed as strings and all other arguments are parsed as numbers. This method has 2 big benefits

• It is more intuitive. To pass a string write it as a string. No need to remember which flag to use.

• Allows for mixing of strings and integers as input, e.g. you can input 3 and "String" without forcing the 3 into string mode.

Since this has worked out well in the other interpreters perhaps we ought to include its functionality in Rain-Flak as well.

If we do add it I suggest we begin phasing out the use of -a. We ought to keep it for backwards-compatibility reasons but we might want to mark it as deprecated in future versions recommending for the new method.

What are peoples thoughts on this? Is there any reason not to add this? To what extent should we depricate -a and -c?

I recently spent some time poking around to see if I could force a invalid character error. I found one, and then I golfed it. Here it is:

Brain-Flak, 2 bytes

@

Try it online!

This produces the error:

Error at character 1: Invalid character '@'.

It seems that @ followed by a whitespace causes this error. It must be due to some sort of parsing issue. Invalid character errors are never supposed to happen, so I'll get on fixing this.

Thanks to StackExchange user DLosc for pointing this one out.

If the program ends in a @ the interpreter will throw a invalid character error.

When an ASCII flag is active and the output is out of the ASCII range (e.g. negative) a nasty ruby error is thrown. Ideally this will change but the question is how. We could create a custom Brain-Flak error or we could implement a wraparound (i.e. mod 256 the output before conversion).

For example, this program is clearly invalid:

((((

But no error is thrown.

Debug flags simply don't work when they are followed by whitespace.

It just occurred to me that we have no documentation on debug flags whatsoever. Where should we add them? We could add to the wiki but that might be a bit hard to find. We could add them to the README but the README already has quite a lot going on.

A @ in the code that is not a part of a debug flag will cause an invalid character error.

For instance:

@

Will cause the error:

Error at character 1: Invalid character '@'.

The program ((){{}}) correctly returns 2 when the input is 1 but 0 0 when the input is 0. I expect it to be 1 0 since {{}} should evaluate to 0. I get the correct output if the () comes after the {{}}.

Commented code will run if it is on the last line of a program.

As of commit 731da21 unclosed brackets no longer generate an error. The program runs in entirety as if the unclosed brackets were not there.

If a loop executes zero times then the interpreter finds the corresponding closing brace and moves the read head to the position of ([location of close brace] - [location of open brace]) (roughly).

It seems that when running in miniflak mode, comments are read and parsed.

For example

([]()()()()())#({}())

Outputs 6 while

([]()()()()())

Outputs 5.

But wait it gets stranger, this only seems to happen when there are banned operations present, for example

(()()()()())#({}())

and

(()()()()())

both output 5.

I noticed some strangeness with cycle counting and the @cy flag. Currently skipped loops count as a cycle. For example the debug output of:

{()}

Try it online!

is:

Cycles:
1
Program:
{()}
    ^
Chararacter 5
Stack:  
^

This in my opinion doesn't make a ton of sense, every loop costs 2 cycles normally (plus the cycle count of the inside) so it would make sense for zero loops to be zero cycles.

However since this behavior is not documented anywhere I am refraining from labeling this a bug without the approval of at least one other user.

If anyone has any ideas of how they might want the cycle counting to be different or has a defense of the current system comments are welcome.

This seems to be a permutation of this #32 and #28.

When a program starts with whitespace followed by a debug flag we receive a Invalid character error.

Exemplum gratis:

 @dv

produces the error:

Error at character 1: Invalid character ' '.

This brain-flak code hits an infinite loop:

({}<>)<>({}[]){({}[])<>(({}))<>}<>{({}<>{})<>}<>

when the input is 3. Strangely enough, if I give the second input as 0, it does not hang. I did not expect this behavior since an empty stack should pop a 0, so they should behave identically.

Now that we have ASCII support for Brain-Flak it would be a good idea (as @Wheatwizard suggested to me) to add support for ASCII debugging by retooling existing debug flags when possible and adding new debug flags when necessary.

The debug flags that would need to be modified or have ASCII equivalents created are:

• #dv
• #dc
• #dl
• #dr
• #df

For naming any new debug flags that need to be created I suggest simply replace the 'd' with an 'a' in the corresponding decimal debug flag.

I've been toying with the idea of writing an interpreter for Brain-Flak in C. I feel it would be nice to create a thorough language specification to aid the in the creation of interpreters (a javascript interpreter would be quite nice).

In the most recent version there is a bad function call on line 21 of the interpreter. read_until_stack_end is called without being defined.

Programs with debug flags at the end of a program (with no braces after) cause the error:

Error at character <last brace +1>: Invalid character '
.'

It does not mater what debug flag it is, if the file ends in a newline or even if it is a valid debug flag, it always prints a newline and a period as the "Invalid character". If we put other non brain-flak characters such in between the end of the program and the start of the debug flag it marks the first one as the invalid character. However this is because those characters get scrubbed from the program.

Interestingly enough the error occurs regardless of the command line flags used. It occurs in both debug and non-debug mode.

The program still runs and all the flags are executed but it errors at conclusion.

While this bug is being fixed, adding a (<()>){} to the end of your Brain-Flak prevents the error without changing the program's function.

Example:

Code

(())#dc

Output

With debug

$ ruby brain_flak.rb -d code.txt

Debug mode... ENGAGED!
#dc (left) [1]
Error at character 5: Invalid character '
.'

Without Debug

$ ruby brain_flak.rb code.txt

Error at character 5: Invalid character '
.'

Your interpreter has no way to input UTF-8 and output decimal. The print_stack command will print in UTF-8 only if the -u flag is set, and the -A flag is not. The interpreter take UTF-8 input only if both -u and -a are set.

I suggest making a -U flag for UTF-8 output, and limiting the -u to input.

Lots of programming languages have cool logos.

Like this:

or this:

Maybe we should make one for Brain-Flak. There is not much of a point to having a logo but I thought it might be fun to come up with one.

For whatever purpose, either hunting down errors in your brain-flak code or for trying to pin down a bug in the interpreter a debugger would be very useful. This has been touched upon elsewhere so I figured it would be a good idea to have a place to discuss the idea.

From @DJMcMayhem on the subject of the debugger

I don't know what that will look like, but it will probably be a CLI flag (probably -d) and some commands to display

• The active stack
• A specific stack
• The result of a function call

and a way to pause for user input, as well as maybe some others.

Currently flags are parsed when not in debug mode. This is not much of a problem because this is mostly silent however when a flag has a number followed by a non-number character the parser fails. This causes valid programs to crash on parse. This should not happen.

This issue can be resolved by stripping flags in normal mode instead of parsing them.

Here is a program that reproduces the problem.

@1a

Try it online!

Based on the release of the ASCII mode I thought it might be a good idea to use Github's "releases" feature to differentiate between stable and non-stable versions. As well as having proper version numbers (e.g. 1.0.9).

When using the -A flag in brainflak classic you just have decimal output :( please fix because my answer is removed until then

Ok this has been bugging me for a while but because @CatsAreFluffy recently brought it up, I thought it might be a good time to bring this up.

Mismatched brackets do not necessarily cause Brain-Flak to error. Here are three examples of mismatched brackets that do not cause an error, each for a different reason:

(()()) #I'm a mismatched bracket :)
(<><>){I'm a mismatched bracket :)}
(()){()}I'm a mismatched bracket :)

1, 2, 3

The first one is obviously not a problem; its just a comment doing its job, however the next two are iffy. They are in portions of non-executed code, the first because it is skipped by a loop and the second because a infinite loop prevents the code from being run.

The reason this behavior exists is that balance checking is done during run time rather than compile time. Currently a bracket can only be mismatched if it is run. The solution to this "problem" would be to check for mismatched brackets before we begin running the program.

Is this a Problem?

In short, I'm not sure there is a pretty good case both ways. I'll start with the case that these are bad, and I'll start this case with a quote from DJMcMayhem:

The whole point of the language is the matching bracket restriction.

Brain-flak is the language of balanced brackets, thats what its about. We should stick to our values and enforce this restriction no matter what.

The next reason why it might be a good is error messages. Currently our mismatched bracket error messages are rather useless. Take this for example:

Where's the Mismatched bracket? ( <--- Is it that one?
>){}(<>[()]{})({({}()<(())>)})(({({}[])({}{})}<({})<(()({}))<>>(())>)<[]>
                              ^ No its that one

When run this will output the rather unhelpful:

Error at character 33: Unmatched '(' character.

Make no mistake the 33rd character is a perfectly closed (, however Brain-Flak really just means that the 33rd bracket is mismatched (I don't know why I wrote the error messages to say Unmatched that's not a word). If Bracket matching was checked at compile time, this would be incredibly easy to check. It is possible to check with the current system, but it would be rather difficult and inconvenient, and likely would cause some slow down in the system. These messages really have to be fixed, and if the new system makes this easier thats a pro right?

Ok, tell me has this ever happened to you?

You just finished writing a massive Brain-Flak program, maybe your latest Mini-flak quine that takes hours to run, so you start it running so you can test it. You get up, get a drink, come back and the program is running, so you open the review queue, you review a couple of low quality posts and the program is still running, so you get another drink, you come back and its still running, so you figure it would be a good time for a nap. When you wake up from your nap the program has finally finished running. Like a kid on christmas morning you rush over to see if it worked.

Error at character 1516: Unmatched '<' character.

If enforced that all programs must be fully matched we could avoid this situation altogether. A compile time check would tell you in an instant whether or not you are going to encounter a bracket mismatch. Currently checking if a program is syntactically valid is equivalent to solving the halting problem and cannot be done at compile time. The only way to have a check at compile time is to make our check into something that can be computed. Whether or not brackets are matched is computable.

Ok, here's why we might want to keep it the way it is.

It will take longer to run every program with a compile time check. Our interpreter is already pretty bloated and slow, we should avoid any more overhead on programs. Our current system is pretty smart for checking the bracket matches as it runs the program. The current system might cause issues in a couple of places, but we would need to have this overhead every time we run a Brain-Flak program.

You can check yourself. If you have a giant program or want to make sure that your program wont error before you start it off, you can just check if its balanced using a pretty simple script. If you want you could even alias it to do so every time you run a Brain-Flak using a little bit of bash magic. This way people running small programs don't have to bother with the overhead each time.

It would not be backwards compatible. The behavior has been like this since the beginning of Brain-Flak, changing it would break at least one program I've written. I'm usually against legacy decisions like this one, but I've put this in here because I know that it might make a difference to some people, and they are entitled to that opinion.

We are writing an esolang, its just a quirk of the language. "practical" and "good practice" are not in our vocabulary. It just adds a little bit of spice to Brain-Flak that can be used to interesting effect, particularly in polyglot challenges.

What we should not do

Ok, I've been pretty flimsy on everything about this so far, but here I am going to take a stand. We should not add a new flag. I feel like every time we discuss a new change this is brought up by someone (sometimes me). We have a lot of flags right now, and we don't need another flag for something that might not even be noticeable. We should make a hard decision and stick with it.

We should also not do nothing. The two major problems mentioned in the first section should at least be attempted to be fixed. Our error messages are really bad right now. If we are not going to check balance before we run a program we should at least give people the option to do something when their program crashes several hours in. This may be allowing users to see the data, or even modify their code after the error to fix the problem and then resume execution.

If you try to run a input a negative number into a brain-flak program. e.g.:

$brainflak test.txt -7

You get the following

invalid option: -7

Welcome to Brain-Flak!

Usage:
    brain_flak source_file
    brain_flak source_file args

    -d, --debug                      Enables parsing of debug commands
    -f, --file=FILE                  Reads input for the brain-flak program from FILE, rather than from the command line.
    -a, --ascii                      Take input and output in ASCII code points, rather than in decimal

It obviously thinks -7 is a flag but I don't know how to fix it.

Would you please add some comments to your code? I am trying to port this to C++, but I do not know Ruby.
Thanks.

I intend on expanding on the existing debug flags. There are three flags I intend on adding.

• Full stack print. I would like a flag that prints both stacks at once.
• Print cycles. Prints the number of steps taken so far.
• Inject code. This will be the most complicated of the three. It will stop the program, accept user input and then execute the user input as code before resuming.

Add a command line flags -v or --version to have the program print the version and then exit and a command line flags -h or --help to have the program print help info on command line flags.

Lately we have had some changes in the way that input and output is ordered. We do not have a specification for the way that input and output is handled and I think we should.

As of 2c9a960 I have generalized the interpreter so that it would be easy to add additional similar languages so that they could be run with all the fancy features of the Ruby interpreter.

So the question is, do we want to support additional existing languages? If so which ones do we want to support.

Here is a complete^{[citation needed]} list of Brain-Flak derivatives we might support:

• Brain-Flak Classic
• Miniflak
• Brainflueue
• Fλak
• Flakcats

When the left stack is empty and a #df debug flag is called the following runtime error occurs:

/Users/eamon/projects/Brain-Flak/Interpreter.rb:94:in `block (2 levels) in do_debug_flag': undefined method `+' for nil:NilClass (NoMethodError)
    from /Users/eamon/projects/Brain-Flak/Interpreter.rb:93:in `each'
    from /Users/eamon/projects/Brain-Flak/Interpreter.rb:93:in `block in do_debug_flag'
    from /Users/eamon/projects/Brain-Flak/Interpreter.rb:81:in `each'
    from /Users/eamon/projects/Brain-Flak/Interpreter.rb:81:in `do_debug_flag'
    from /Users/eamon/projects/Brain-Flak/Interpreter.rb:116:in `step'
    from brain_flak.rb:60:in `<main>'

This is caused by an attempt to find the largest number in an empty list.

Since TIO is not a traditional console Keyboard interrupts result in the following error when run on TIO:

Keyboard Interrupt
/opt/Brain-Flak/Interpreter.rb:258:in `inspect': undefined method `winsize' for nil:NilClass 
(NoMethodError)
	from /opt/Brain-Flak/brain_flak.rb:159:in `rescue in <main>'
	from /opt/Brain-Flak/brain_flak.rb:132:in `<main>'

Try it online!

Whereas on a console this will result in:

Keyboard Interrupt
(()){()}
       ^

We should design a replacement for the console Keyboard interrupt for consoleless environments.

Currently the only way to give ASCII input to a program is to have the program read it from a given file. It would be nice to be able to give such input straight from the command line.

If you try to run code with only debug flags and no braces (e.g. #dl) you get the following runtime error:

/Users/eamon/projects/Brain-Flak/stack.rb:51:in `include?': no implicit conversion of nil into String (TypeError)
    from /Users/eamon/projects/Brain-Flak/stack.rb:51:in `is_opening_bracket?'
    from /Users/eamon/projects/Brain-Flak/Interpreter.rb:135:in `step'
    from brain_flak.rb:60:in `<main>'

This error occurs when the interpreter attempts to determine if the program starts with an opening bracket but discovers there is no program. It passes a nil object to the method is_opening_bracket, which then tries to convert that to a string. This error occurs on both the debug-flag-dev and master branches. This error only occurs with debug mode on.

The multiplication with any number no longer works with the latest version of Brain-Flak. It hangs when given two negative numbers. This example needs to be replaced with a version that works for negative numbers. There is also a small chance that this is caused by a new bug introduced in one of the recent updates, in which case that bug needs to be fixed.