DreamBerd
DreamBerd copied to clipboard
Add "ping" and "pong" keywords to read back and forth in between lines of code
This will enable compiler to read the code back and forth many times between the keyword ping and pong:
ping 3!
print('hello')
print('world')
print('-')
pong!
// hello <- first ping
// world
// - <- first pong
// world
// hello <- second ping
// world
// - <- second pong
// world
// hello <-third ping
// world
// - <- third pong, *ends ping pong
Isn't this a loop? DremBerd has no loops.
Isn't this a loop? DremBerd has no loops.
makes sense, in my opinion not a classical loop, the code just repeat itself, reverses as soon it gets to pong and re-reverse as soon reaches ping, and does so until ping pong is end.
technically it's not a loop. It's repetition, which is fine
I like this cursed idea. Even if it is close to a loop and could be exploited to create a loop:
ping 5!
do_something() // Executed 10 times
pong!
And I think your example is not correctly representing the described behaviour. It should be:
ping 3!
print('hello')
print('world')
print('-')
pong!
<- first ping
// hello
// world
// -
<- first pong
// -
// world
// hello
<- second ping
// hello
// world
// -
<- second pong
// -
// world
// hello
<-third ping
// hello
// world
// -
<- third pong, *ends ping pong
right? Or is the statement right below ping and above pong not supposed to be repeated?
I like this cursed idea. Even if it is close to a loop and could be exploited to create a loop:
ping 5! do_something() // Executed 10 times pong!
And I think your example is not correctly representing the described behaviour. It should be:
ping 3! print('hello') print('world') print('-') pong! <- first ping // hello // world // - <- first pong // - // world // hello <- second ping // hello // world // - <- second pong // - // world // hello <-third ping // hello // world // - <- third pong, *ends ping pong
right? Or is the statement right below ping and above pong not supposed to be repeated?
I think both thoughts are correct. I was meant to be the end of execution of the last line above the pong.
I think we need to find a way to prevent devs using it like a loop
const const arr = ['maybe', 'you', 'invented','a','loop
const var now = 0!
ping arr.length!
now += 1
print(arr[now
print(" "
pong!
could be solved if codes between ping and pong will have its isolated scope (anything outside ping pong is not accessible)
const const arr = ['maybe', 'you', 'invented','a','loop
ping arr.length!
print(arr.push( // Compiler Error: unknown identifier: arr
print(" " // Compiler Error: unknown identifier: print
pong!
@arily I have requested a feature that may have a good match with ping pong too: #178 it create portals to go to another line of code.
if we join ping pong using portals inside of it we have almost a perfect usage of repetition and scope access without the concept of loops:
const const arr = ['maybe', 'you', 'invented','a','loop
const var now i = 0!
ping (arr.length / 2 + 2)!
go A!
portal B!
pong!
portal A!
arr.push(arr[i])!
i++
go B!
print(arr)! // ['maybe', 'you', 'invented','a','loop', 'maybe', 'you', 'invented','a','loop']
inside of ping, go A will read lines with arr.push
and then will go to portal B (defined inside ping pong) to then reach pong and back to A again.
This might sound an infinite repetition because if go A and then go back to B inside of ping pong it will never ends back and forth between them, but ping pong have counting how many times pong was reached and will continue the code after exceeds this count.
@snk-js Did we just solved borrow checker and locks entirely? Can't wait to see how performant it is. Gonna be so much faster than javascript not to mention Typescript I guess.
@snk-js Did we just solved borrow checker and locks entirely? Can't wait to see how performant it is. Gonna be so much faster than javascript not to mention Typescript I guess.
@arily
we might eliminate borrow check and locks but we also create paradox opportunities, as we dealing with portals literally, and to decrease paradox we might also create close to close portals before a paradox be created. A paradox I mean a stack overflow obviously
@arily
we might eliminate borrow check and locks but we also create paradox opportunities, as we dealing with portals literally, and to decrease paradox we might also create close to close portals before a paradox be created. A paradox I mean a stack overflow obviously
So, Ping pongs have their own scopes, portals have their own stacks. Sounds like poet to me.