(The (parentheses (update)))

[TodePond]

Today we are pleased to announce DreamBerd 3.

With it, we introduce a brand new feature...

Parentheses

Parentheses in DreamBerd do nothing. They get replaced with whitespace.
The following lines of code all do the same thing.

add(3, 2)!
add 3, 2!
(add (3, 2))!
add)3, 2(!

Lisp lovers will love this feature. Use as many parentheses as you want!

(add (3, (add (5, 6))))!

Lisp haters will also love it.

(add (3, (add (5, 6)!

Bounties £££

There's a growing number of people attempting to build a DreamBerd compiler. We imagine that this update will decrease that number.

If you really want to make a DreamBerd compiler, we highly recommend that you target a smaller subset of the language. Please consider the following features optional:

• Multiplayer const const const server
  Feel free to use a local store instead.
• AI
  If your code has a compile-time error... but could potentially be 'un-errored' by adding more code... it's supposed to email me ([email protected]). But this kind of 'partial' parsing can be tricky. So feel free to ignore this, or only do it in certain cases.
• Implicit strings
  If your code has a compile-time error... but could potentially be 'un-errored' by interpreting a certain part of it as a string... it's supposed to interpret the shortest possible amount of code as such. Again, this kind of 'possibility parsing' can be tricky. So feel free to ignore this, or only do it in a small number of cases.
• Optional parentheses
  As of today, all parentheses are optional. Their use can mostly be replaced by significant whitespace. For function calling, your parser now needs to figure out the signature of every function, so that it can figure out which arguments are being passed to it. This is quite hard! Feel free to require parentheses.
• ECMAScript
  Unless otherwise stated, DreamBerd is the same as ECMAScript. But that can take a lot of work to parse and compile, especially when combined with the other tricky aspects. So I highly recommend just sticking to the functions and features that appear in the DreamBerd documentation.

Even when ignoring these, making a DreamBerd compiler can be hard!
Therefore, the DreamBerd Foundation will pay the following rewards for these accomplishments:

• £99 to a charity* of your choice - if you're the first person to make a DreamBerd compiler (with the above exceptions)
• £99 to a charity* of your choice - if you're the first person to make a DreamBerd compiler (with NO exceptions)

Or do both at once to win £198 outright!

Many thanks,
Lu Wilson, CEO of the DreamBerd Foundation, please pay me money so I can afford these bounties.

*no techbro charities

---

This discussion was created from the release (The (parentheses (update))).

[mybearworld]

Here's my compiler (written in Rust, compiles to Rust):

fn main() {
  println!("fn main() {}");
}

It assumes everything is a zero-quoted-string, unless you specify otherwise¹. Input is taken via a file name as a command line argument.

Footnotes

1. To specify otherwise, simply write a program with no side effects (like const const const, output...) ↩

[TodePond]

Sorry this joke is too advanced for me to understand, consider simplifying

[Zerotask]

This is so revolutionary. I bet it takes at least Java 34 to adapt it.

[GoldenStack]

Given this update, how would the following code run?

const const (2 = "String"!
const const ((2 = "String 2"!

print((2)!

I'm curious to see an explanation of how a parser would determine this. Would the opening parentheses in the variable names be ignored, too?

Also, what about this?

const const (2 = "String"!
print()2)!

Finally, if "[parentheses] get replaced with whitespace" could this code work?

const const ( 2 = "String"! // variable name is "( 2"
print((2)! // Prints "String" ?

(and yes this is making it very difficult to write my parser :(((( )

[TodePond]

All parentheses do nothing. Replace them with whitespace.

const const  2 = "String"!
const const   2 = "String 2"!

print  2 ! // "String 2"

const const  2 = "String"!
print  2 ! // "String"

const const   2 = "String"! // variable name is "2"
print  2 ! // Prints "String"

[mybearworld]

They are replaced with whitespace. Therefore:

const const  2 = "String"!
const const   2 = "String 2"!

print  2 !

This would output "String 2".

const const  2 = "String"!
print  2 !

This would output "String".

const const   2 = "String"! // variable name is "  2"
print  2 ! // Prints "String" ?

This would output "String".

[Racooder]

I think variable names can't start with whitespaces

[mybearworld]

They can't, so the whitespace is just ignored.

const const (2 = "Hello"!
// is equivalent to
const const  2 = "Hello"!
// is equivalent to
const const 2 = "Hello"!

[trueFireblade]

@Racooder I think what you meant to say is "variable names can't start with whitespaces yet"!

I propose the whitespace update:

const const  = "Hello"!
const const x = "1"!
const const  x = "2"!

print  ! // => "Hello"
print x! // => "1"
print  x! // => "2"

[GoldenStack]

Additionally if I use parentheses with an unquoted string:

print(bagel77)!

Wouldn't there be whitespace before and after the parentheses (in the actual value of the unquoted string), assuming that parentheses are actually replaced with whitespace?

[mybearworld]

They are replaced with whitespace. Therefore:

print bagel77!

This prints "bagel77".

[TodePond]

We could consider the steps of two types of parser. One that strips parentheses first, and one that places implicit strings first. Both would lead to the same result.

Parentheses first

print(bagel77)!

print bagel77 !

print "bagel77" !

Implicit string first

print(bagel77)!

print("bagel77")! // shortest possible implicit string to fix error

print "bagel77" !

[arthurmelton]

So are these the same?

print "Hello,(World!"!

print "Hello, World!"!

[mybearworld]

Not necessarily. The compiler could replace print "Hello,(World!"! with either of these:

print "Hello,\tWorld!"!
print "Hello,\nWorld!"!
print "Hello, World!"!
print "Hello,\vWorld!"!
print "Hello,\fWorld!"!
print "Hello,\rWorld!"!

[TodePond]

No that parenthesis is part of the string, not the language's syntax. This is the same as in most languages

[TodePond]

omg @mybearworld always so quick to answer wow

[GoldenStack]

If I have:

a(1, b(2, 3), 4)!

and we remove parentheses:

a 1, b 2, 3 , 4 !

Is the parser expected to know how many arguments are required for b, or is the extra whitespace character before the , 4 indicative of ending the arguments, similar to how operators (like * and +) are specified?

[TodePond]

We would know because of the rest of the code

f b(foo, bar) => bar
f a(foo, bar, baz) => foo

a 1, b 2, 3, 4!

a(1, b(2, 3), 4)!

In your example, the signatures of a and b are not known, so whitespace determines it fully.

Sure! please feel free to use the discussions page of the repo :)

Part of the fun is that most of the discussions happen here on GitHub

[GoldenStack]

How specifically do whitespace rules work for function calls? Is it like, "if there's whitespace before the comma, assume no more arguments will be provided for this specific function"?

[TodePond]

No, don't think of it like a lexer going through character-by-character. Think of it like levels of depth.

function foo(a, b, c) => {
   a 3 ,     b  5 , 2 , c!
}

same as:

function foo(a, b, c) => {
   a(3, b(5,2,c))!
}

[GoldenStack]

But how could the ending be formalised?

a(3, b(5, 2), c)!

becomes

a 3, b 5, 2 , c !

So would we know that c is not an argument to b because there are a total of two whitespace characters between the 2 and c, which is more than the 1 between 5 and 2?

[TodePond]

In this case that's true but that's not always true. More whitespace doesn't necessarily mean the end of the arguments:

a  3,   b 5, 2 ,     c!

And no whitespace before a comma doesn't always imply that it's not the end of the arguments:

a 3,  b 5, 2,  c!

It seems like you're looking for a simple rule based around commas, but the opening and closing of parentheses is really controlled by whitespace size, regardless of commas. The commas simply indicate that two neighbouring values are not a function call.

[DninoAdnane]

I added a testing package for DreamBerd, please have a look at it!

[GoldenStack]

Does this mean we can't have unquoted strings with exclamation marks anymore?
print(Hello, World!)!
becomes
print Hello, World! !
(which can no longer be determined as valid)

[TodePond]

As print is a function that takes one argument, it can be determined as valid.

These lines are both valid:

print(Hello, world!)! // "Hello, world"
print Hello, world!! // "Hello, world"

EDIT: oh I see what you mean. They are valid but they won't print the exclamation mark, you're right

[TodePond]

you could do this:

print Hello, world\!!

[GoldenStack]

Since
print(Hello, World!)!
becomes
print Hello, World! !
Due to the space between the exclamation marks, would the latter statement parse as a call to print with !!, or a call to print with ! and an empty statement with !

[TodePond]

There's no 'argument grouping' needed here so the whitespace makes no difference. Instead, there's an error due to an unrecognised symbol Hello. So it attempts to find an implicit string to fix it:

Implicit string detection always selects the smallest possible string to "un-error" the program.

print "Hello, World"! !

[jzimmerman135]

Not sure I agree with this, whitespace is so outdated. We could just use parentheses instead

[mybearworld]

E.g. you'd like the following?

const)const(name(=)"Luke"!

Not sure how I feel about that

[jzimmerman135]

I(guess)you're(right,)it's(probably)not((my)finest(idea

[Eddio0141]

A few more questions about this

Does function hoisting exist here like JavaScript?
For example the below would be calling a function

// a function call like `var(var(a(=(1))))!`
var var a = 1!

function var arg => {}
function a arg => {}
function = arg => {}

---

What happens if the function var exists, but a isn't defined as anything?
Would it pass the rest of the arguments as if they are a zero quote string like so

function var arg => {}

// could be `var(var("a = 1"))!`
var var a = 1!

---

Also what happens if the function named var does exist, but it has no arguments
Would it allow you to define the variable since it isn't doing var!, or would it call the function and throw away the arguments?

// no arguments
function var => {}
function a => {}
function = => {}

// variable, or a function call like `var(var(a(=(1))))!`
var var a = 1!

[Eddio0141]

Very interesting
So it has to be something like this I'm guessing

add 1, 2!

const const add<-1> = function l, r => { return l + r! }!
// or
const const add<-2> = l, r => l + r!

Also I've rephrased those other questions with this 👀

[TodePond]

Let's start with this one.

add 1, 2!

const const add<-1> = function l, r => { return l + r! }!

Firstly, the second line has some invalid syntax. function is for the start of a line - it can't be assigned to something. So that invalid part will be interpreted as a string.

add 1, 2!

const const add<-1> = "function l, r => { return l + r! }"!

Then, the negative lifetime will cause the line to happen one line earlier.

add 1, 2!
const const add<1> = "function l, r => { return l + r! }"!
 

The first line is a syntax error, as add is undefined there. Therefore, it'll be interpreted as an implicit string.

"add 1, 2"!
const const add<1> = "function l, r => { return l + r! }"!
 

If you have another specific code example you want me to walk through, please comment it below :)

[Eddio0141]

Ahh ok function for the start of the line.
The implicit string comes into literally everything that's invalid I see.

Here I was mainly wondering if there's a code like this

function var => {}
var var a = 1!

What would happen in the second line?
Would it call a function? Or would it call the function var and try to pass the rest of the statement as the arguments to the first var (which gets unused because var has no arguments) ?

[TodePond]

The implicit string comes into literally everything that's invalid I see.

If the code can be made valid by changing something into a string, it changes the smallest possible part of code into a string.

---

Let's look at this example.

function var => {}
var var a = 1!

In the first line, a function called var has been declared that takes zero arguments, and returns type undefined.

On the second line, it recognises the var function at the start of the line. As it takes no arguments, it doesn't need to look for any arguments. However, if it ran the function, it would return type undefined at the start of the line, which would make this line invalid. So, instead, it treats it as a var var declaration instead.

[Eddio0141]

I think I understand
What would happen if lines are revisited though?

For example this

function wrap => {
    var var foo = 1!
}

wrap!
function var arg1 => { }
wrap!

After defining the global function var with an argument, would the second wrap call "re-parse" the var var foo = 1! line to be not a variable declaration but a function call to the global var with the argument "var foo = 1"?