Eniko Foxmaking good progress on my parser, and now i'm thinking of committing some crimes >:3
that being having both `and` and `&&`, and `or` and `||`, where the latter coerces to bool and the former does not and acts like lua >_>
in less trolling news i'm really liking the way if/while/etc blocks work in this syntax. either you do this
if x { ... }
or you do
if x: print "single line";
so the colon delineates the end of the condition but is optional if you have a {} block instead of a single line. and yes, this is also valid:
if x: { ... }
not sure what i wanna do with for loops 🙃 C style for (;;) or Lua style for x = 1, 10
maybe i will just only have while loops for now so i have time to think about it. for loops are just while loops but fancy anyway
Trying to think of what's left for my parser before I can start writing and compiling actual programs. Right now all it knows is integers. I guess if I expose some stuff to interact with memory handles and the VM's system calls I could make real programs?
It'd be nicer to have like, actual pointers and strings and arrays though, but that's a lot more work. So maybe I should just do the quick and dirty way for now?
Jari Komppa 🇫🇮@eniko Everything depends on what your end goal is. Once you have decided what that is, the answer to your question becomes "do I really, really, REALLY need this to do X?"
@sol_hsa end goal or what I want right now, cause those are not the same >_>
@eniko well, "no, but wouldn't it be *fun*" is a completely valid answer to the question too...
Efi (nap pet) 🦊💤@eniko im not sure what you've done, but a program made only of integers sounds like a brainfuck kind of language
j_bertolotti@eniko You've got a Turing machine, so you should be able to run any program 😜
Smol Catto@eniko do you allow nested expressions? I did and only got as far as the shunting yard algorithm to try and sort them out. Haven't worked on my own in a while, interested to see how you're handling it
@an_smol_catto yeah, i'm using a pratt parser as per Crafting Interpreters: https://craftinginterpreters.com/compiling-expressions.html
@eniko this looks really useful thanks!
@eniko for loops are while loops that you gotta tell when to stop
Ozzelot 
David Stark@eniko Implement don't-unless loops as the main looping structure.
squibs@eniko Made me realize I almost basically only use while loops for my main game loop functions and then almost never outside of that context.
Mattias_G@eniko or basic style for x = 1 to 10 :)
@Mattias_G yeah i considered that one too, though that's kind of the same as lua style
Joshua Barretto@eniko Do you have a more general iterator abstraction?
@jsbarretto no, that requires type complexity that things are not set up for right now
@eniko fair enough! Remember that you can choose a syntax that's amenable to iterators later.
For example, Rust's `for x in 0..N` syntax works with any iterator instead of a range, but there's no reason why you couldn't hard-code the range pattern for now and solve the general behaviour later :)
Kojack 🦎@eniko A slightly different form is Reverse Polish Lisp: 1 10 for x next :)
(Whenever I've written my own languages I make them Forth or RPL style, since it's so much easier to write the interpreter)
@eniko But more seriously, C style is more flexible, but also more complicated. Lua has a nice clear syntax if all the programmer is doing is a simple counting loop without extra logic.
As long as there's something like a while loop, the C form of for loops isn't really needed.
As long as there's something like a while loop, the C form of for loops isn't really needed.
Isaac 'Atridas' Serrano Guasch@eniko Lua are really "for each" loops, so you gotta have iterators more or less native to your language. I'd say go for it if you can.
Alex Celeste, Princess Consort of Burnout@eniko yall got lambdas?
```for_each (sequence, ^ (item) {
work (item);
});
for_each_n (sequence, ^ (item, i) {
work (item);
array[i];
});```
etc
then later you could do what Ruby/early Rust did and allow the recursion-operators to curry and implicitly use trailing-call syntax:
for_each (sequence) ^(item) {
work (item);
};
(i am hung up on this :P)
@erisceleste nope, too fancy for me
@eniko i poisoned my brain with Lisp at an early age and am now unable to think of the C-style control structures as anything other than higher-order functions that curry with a lazy condition-expression and are then invoked with a block-lambda
pzmyers 🕷@erisceleste @eniko I managed to avoid the Lisp indoctrination, but instead got sucked int Forth at an early age. Now everything is about popping stuff on and off stacks.
SorceryForEva 🏳️🌈 🏳️⚧️parents, talk to your children about programming languages before it's too late 😂
Rob\Viewdata UK@eniko
If you're already treating a {..} block also as an expression, as per your "if" post, you could go the route TCL went, ie
for start test next body
E.g.
for {set i 0} {$i < 10} {incr i} {
puts "I inside first loop: $i"
}
From https://www.tcl-lang.org/man/tcl8.5/tutorial/Tcl10.html
@robert oh I don't have anything as advanced as block expressions
sarah tonin 
@eniko yea that's reasonable. If a : then only one statement, if { then a whole block
i like this
josh g.@eniko criiiiiiimes
Kim Spence-Jones 🇬🇧😷@eniko
Having bitwise boolean operations are cool.
Having bitwise boolean operations are cool.
Tom Coxon@eniko straight to jail
aeva@eniko if you roll a crit this is going to be really funny in 10 years
@aeva "why the fuck does this ubiquitous language have two logical and operators??"
Because I thought it would be funny
Fortunately it's almost guaranteed I'm not gonna roll a 100 on a d100
Olivier
Martin Marconcini@eniko if you're going to go the evil route, why not use ®® and ©© as operators?
MikiP0@eniko still better than doing &, && and &&& so go ahead, it's atleast your language
~ a C# dev that might just be used to not caring anymore
Aurani Casts Fireball@eniko you've gone mad with power!
But also, Coldfusion - my first language - used keywords. It was jarring going between it and JavaScript.
ManchmalScott@eniko Elixir sorta does this!
and and or strictly work with boolean arguments (i.e. it is a type error to call them with non-booleans), whereas && and || work with truthy and falsey values.
@manchmalscott huh, that's interesting! Wonder why they made that decision
@eniko
I came across this in some old C code the other day... No wonder I was confused..
I came across this in some old C code the other day... No wonder I was confused..
tekhedd