What benefits does copper bring over other langs?
Also loose is a bad move. Loose semantics proved a mistake (PL1), loose syntax brings nothing to the party. Semicolons were used in pascal because wirth understood parsing, and they are there to help the parser resync after a syntax error is detected.
From experience if you make semicolons optional as in sql, it helps not at all, AND they are (said by microsoft to) become mandatory in future releases of TSQL, AND I and at least some other users of SQL want them mandatory.
I also don't understand why a non-typical syntax is used. Not at all saying it's wrong but it seems to differ from other syntactic conventions only to be different rather than better (I may be wrong!). Why "gte(a: 100)"? Syntax matters to a degree, why diverge?
https://copperlang.wordpress.com/2016/11/18/printsyntax/
Edit: The design of the parse tree is such that there is no need for things like statement termination, parameter separation, among other things. By its simplicity, the code focuses on what really matters. Complex syntax is mentally taxing and distracts the programmer from focusing his energy on problem solving.
With respect I don't see it that way (nor know of any studies to back that up qualitatively). While complex syntaxes do exist and they are horrible (I pray you never have to use XSLT) dropping semicolons and commas do not make a syntax noticeably simpler. But they may lay unexpected traps.
See how your users find it though.
Not sure what about it are you criticizing?
Local variable access using :?
No commas between parameters?
Operators using function call syntax?
> Local variable access using :? / No commas between parameters? / Operators using function call syntax?
Well, yes, yes and yes.
gte(a=100)not 100% sure but it kind of looks like copper's Whole Deal™ are "object-functions" (closures?) and you use colons to get an object function's return value. something like this
adder = [a b]{ ret(this.a + this.b) }
x = adder(3 5)
print(x.a x.b x:) # 3 5 8
In Copper, variables only store functions. This separates routine from data so you never end up with null pointer errors like in languages that have Any Types or pointers. Functions can return data, so you end up having function calls everywhere. a=5 is basically a={ret(5)}
In your above example the correct first line would be: adder = [a b] { ret(+(a: b:)) }
Parameters to a function are those that are not assigned data, whereas members are: add = [Param, Member=10) { ret(+(Param: this.Member:)) }
Now you can probably see what's wrong with your third line.
For example, taking this line from the first example:
this.peek = +(this.a: this.b:)
this.peek = +(this.a: this.b:
I know that Forth is "loose syntax" in that Forth code is just a sequence of white-space separated words, so your comment and mine are both syntactically valid Forth, but without meaningful semantics. But Forth does not use parenthesized function calls the way Copper does.
Reading through them, it seems like an interesting language concept/experiment.
So, it can be used and incorporated freely, but it also says "YOU ARE NOT GRANTED LEGAL AUTHORITY OVER THE USAGE, PROTECTION, AND DISTRIBUTION OF THIS SOFTWARE." so you don't have legal authority over its usage. IANAL, but that seems to limit one's own authority over one's own work based on this software. It's very confusing.