Here we are going to make Brainfuck better

Here we are going to make Brainfuck better.
The name would be Brainfuck++++ and [somebody draw the logo].
Let's not make it to look like C, Haskell, or Lisp, but let's make it a bit more readable but still Brainfuck.
We propose what would we want to implement.

And yes, Brainfuck++++ compiler should be compatible with Brainfuck code, so []+-.,>< are reserved.
The first thing - operation multiplying, let's write 4+ instead of ++++. Multiplying should work with +, -, .
So, we have Hello world program.
Original Brainfuck:
++++++++
[>++++
[>++>+++>+++>+>+[.>---.+++++++..+++.>>.+.>++.


Brainfuck++++

8+[>4+[>++>3+>3+>+4+>+>->>+[.>3-.7+..3+.>>.+.>++.

Let's have fun!

Lets have MFC support and call it Microsoft Visual Brainfuck

Nah I'm too lazy.

The only thing that would make brainfuck more bearable is functions. That way, you can sorta nest programs on top of each other

There's no good way to do it with current functionality other than to have a program pre compile everything. Functions would allow basic "x*y" operations , and maybe we could even simulate object oriented programming

Since Brainfuck operators are one-character originally, I think it would be better to do the same with operator multiplier - set values from 1 to 9 or 1 to F.

I think it would be better to make some B4 virtual machine.
Let's say, cells before 0 (BF programs start at 0 cell) would be some system parameters.

How about that:
S operator tells B4 to run the program from the cell, which number is stored in the current cell. After jumping to that cell, if runs program by taking values from cells, each command per cell.
The stop value is 0.

Actually I have a better idea. Well two ideas

One involves simulating random access memory. But I think it'll stop being brainfuck after that. In total three operations are needed for functions to work goto, label, and to get the current position of the pointer.

One more, that's a little bit more interesting, in my opinion. It's a bit more recursive. Functions are defined by {/*code*/} and are in numeric order, and $ runs the function underneathe the pointer. The next element after that is how many parameters to enter in, and the next N elements are the parameters. Then another brainfuck interpreter is created with predefined elements that represent the N elements from before

> But I think it'll stop being brainfuck after that
Kinda. I think we should remain inside Turing machine.

>Functions ... are in numeric order
I don't get that.

>$ runs the function underneathe the pointer. The next element after that is how many parameters to enter in, and the next N elements are the parameters. Then another brainfuck interpreter is created with predefined elements that represent the N elements from before

Let's say, we have n, n+1, n+2, n+3, n+4 cells.
Values are m, 3, 12, 34, 56.

Since m is a number of cell, we pass to the
m, m+1 and m+2 cells 12, 34 and 56 values.

Did I understand your idea?

Let's say at the beginning of our program, we have such
{/*program 1*/}
{/*program 2*/}
{/*program 3*/}

If at any point in the rest of the program, we have $ then we launch the function underneath the pointer. For example, if the pointer has 1, we launch function 1
The number after that is the amount of parameters to include in that function. The numbers after that are the parameters

Then, in a new scope, we have a completely new array, initialized only with those parameters at the first, second, and third array. At any point in that function, we can use # to return that single variable underneath the pointer

Alright, could you show me code example with ypur operator?

I'm on my phone, so that's a bit harder. But I'll just copy and paste and hope my code works

{[->+#} //adds two numbers together
+ // selects program one
>++ //sets two parameters
>+ // first parameter
>++ // second parameter

> I guess after that, we can delete the four elements and replace it with 3 or maybe add it as the fifth element?
The simplest way would be just store returning way in the cell where we called the function.
It needs to be thought, how that's implementable in plain brainfuck though.

I guess. But do we delete elements after? It would kinda suck having to clear them out manually

make it use reverse polish notation

We may leave that to function authors.
# may be the pointer to the call cell, so we could flush other cells.
{[->+#>[]>[]>[]++

It doesn't have any binary operators

bump

Bump, very interesting but I am don't have the knowledge to participate

I think you might want to study Turing machines.

I understand Turing machines, I mean I am not familiar with BF. After reading for 10 seconds I feel silly

> + - increment the value in cell by 1
> - - decrement the value in cell by 1
> > - go to the right by one cell
> < - go to the left by one cell
> . - print the value from the cell as ASCII character
> , - get the value into cell
> instructions inside [] are executed until the value of the current cell becomes zero

Now you can read BF.

I think you guys are missing the point of brainfuck. You're trying to make a language more complex and usable even though it's supposed to be simple and near unusable.

Well, that's really easy to fall into reimplementing of existing language.
Do I want to make BF complex? I don't. I'd want just to define a couple of macros, transformable into BF code by hand.
Do I want to make it usable? Yes, I want. I understand that the whole point of BF that every algorithm can be remade on the Turing machine, by nobody would want to. That's fun but what if would be a real deal?
I think: "The core of the BF is Turing machine, so if I want to expand, I should never touch the core." B4 should remain as the implementation of Turing machine, so everything we have to operate are still values in the cells and the pointer.

Whoops, didn't fill the name field.

> I think it would be better to make some B4 virtual machine.
Continuing on that, we can think about . as about the common output operator.
It means if we want to, we must define, if we want output values as characters or as, let's say, pixels on the screen.
Should it be external option or it would be (obviously) better to make it as some internal option? If we want to make it internal, won't this hurt the whole idea of Turing machine?

...Well, fuck.

>make brainfuck more readable
You're missing the point.

I'm interested in being brainfuck a usable language though.

It is usable.

Can I use Node.js with it?

Yes. It can do anything C can, more efficiently.

The point of Brainfuck was to create a turing complete language with as few operations as possible. You can even make it have less instructions, by relying on overflow, and thus remove < and - from the instruction set.

iirc the point was to make a Turing complete language you could write a compiler for that was as simple as possible. The smallest compiler is 160 bites of c code

If I wanted to remove instructions I'd have a "change operation" instruction.

Guys I've made a new language. I call it ILL.
L = perform operation
I = change operation
operations:
0: increment
1: decrement
2: next cell
3: prev cell
4: print cell value as ascii
5: cell = ascii input
6: new loop
7: return to last unbroken loop and change op to 6, or nothing if current value 0
LLLLLLLL //++++++++
IIIIIILIIIILIIIIIILLLL //[>++++
IIIIIILIIIILIIIIIILLIILIIIIIILLLIILIIIIIILLLIILIIIIIILIIILLLLIIIIIILIIIIIIL //[>++>+++>+++>+>+[.>---.+++++++..+++.>>.+.>++.

Also I guess I should mention that case doesn't matter. New line characters are ignored, evidently.

Also since there are only 2 ops, it's reasonable to assume you can just turn it into binary. Taking 0=change and 1=perform, we get the ascii representation (bastardised by Sup Forums's filters)
ΓΏ

some notes:
character count is no more than 7 times larger. This is absolute.
I'd expect about 3x the character count typically.

So... whitespace then?

behaves differently

bump