21–30 of 32 posts
Reading through them, it seems like an interesting language concept/experiment.
(Edit: this comes across a bit aggressive, not meant so). 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, i…
An article on the blog explains the parse tree. 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.
Earlier quoted context omitted.
> Why "gte(a: 100)"? Syntax matters to a degree, why diverge? Not sure what about it are you criticizing? Local variable access using :? No commas between parameters? Operators using function call syntax?
Not the parent, but I personally don't like prefix syntax for such common operators. As for the colons combined with the absence of commas, this suggests keyword syntax to me. I.e., as if the gte function took one argument named a. Like this Python call: gte(a=100)
Last note: gte(a=100) would produce an error in Copper because a=100 is an assignment statement that returns "a" (a function), and gte( function ) means nothing.
Edit: I see you're referring to Python, but I figured I'd keep the note of comparison.
Earlier quoted context omitted.
An article on the blog explains the parse tree. 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.
> 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…
[1] When passing either an object or data to a function, the parameter is stored as a function. e.g. if f=[p]{}, then f(a) and f(5) have p=a and p=5 respectively. If a=5, then the results are identical. The trap is that if a={ret({ret(5)})}, which is a wrapping function, and you call "a" before passing it to "f", then you get the nested function {ret(5)} instead of the wrapping function {ret({ret(5)})}. Having worked with Copper in practice, it's not too hard to spot the error, but it is one of those things that will catch beginners off guard.
[2] https://github.com/chronologicaldot/CupricBridge/blob/master...
I wonder what "loose syntax" is supposed to mean here. No semicolons at the ends of lines? OK. Optional commas between function arguments? Hum. But at the same time this seems to require colons after... what exactly? Variable read accesses in argument lists? Unintuitive and not exactly "loose".
Isn't the trailing colon thing also in Ruby? I thought I remembered seeing something like this elsewhere where it also did not make much sense
Earlier quoted context omitted.
> But at the same time this seems to require colons after... what exactly? 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 (i looked at the docs for like 10 minutes, could be wrong)
You are correct. "object-function" is basically like in Javascript: It's an object (having members) and an executable body. The colons are a shorthand for function call. ie myfunc() 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 eve…
x = foo()
bar(x.a, x.b)Earlier quoted context omitted.
> 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…
The dropping of semicolons and commas isn't what makes it simple, I'll agree. I was referring to the simplicity of the parse tree as a whole. It's easier to figure out what a Copper statement does because there are very few types of statements. Yes, there are a couple of traps [1]. Try reading this example [2] and see how you like it. [1] When passing either an object or data to a function, the parameter is stored as…
Earlier quoted context omitted.
You are correct. "object-function" is basically like in Javascript: It's an object (having members) and an executable body. The colons are a shorthand for function call. ie myfunc() 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 eve…
yeah, i think i get it now. but if variables can only store functions, how would you write something like this in Copper? x = foo() bar(x.a, x.b)
bar(x.a: x.b:)
Functions can return data. So say, a=5, then to get the value of 5 out, all you have to do is call the function a.
Edit: I'm assuming foo() here returns an object with members "a" and "b". An example of such a function-object would be:
foo = [] { ret( [a=5, b=10] ) }
Earlier quoted context omitted.
The dropping of semicolons and commas isn't what makes it simple, I'll agree. I was referring to the simplicity of the parse tree as a whole. It's easier to figure out what a Copper statement does because there are very few types of statements. Yes, there are a couple of traps [1]. Try reading this example [2] and see how you like it. [1] When passing either an object or data to a function, the parameter is stored as…
That "trap" looks weird. Does this mean that a's type changes somehow if you call it before passing it to f? That is indeed surprising for a statically typed language. Could you write out the types of the variants (wrapped vs. non-wrapped)?
[code]
class F {
int mydata;
F( int a ) : mydata(a) {}
F* operator( int p ) { a=p; return new Function(0); }
};
myF = new F(10);
doSomething( &myFunc );
doSomething( myFunc() );
[/code]
This is a basic formula for how things appear "under the hood" in the VM. Notice that doSomething() accepts F*, but in the first case, the F instance passed has a different mydata value. In Copper, the above code corresponds to:
[code]
doSomething( myF )
doSomething( myF: ) or doSomething( myF() )
[/code]
Earlier quoted context omitted.
yeah, i think i get it now. but if variables can only store functions, how would you write something like this in Copper? x = foo() bar(x.a, x.b)
x = foo() bar(x.a: x.b:) Functions can return data. So say, a=5, then to get the value of 5 out, all you have to do is call the function a. Edit: I'm assuming foo() here returns an object with members "a" and "b". An example of such a function-object would be: foo = [] { ret( [a=5, b=10] ) }
> "in Copper, variables only store functions"
because here, `x` clearly stores an object... is this about the whole "object-function" thing where Copper doesn't really distinguish the two?
(btw i'm sure this is explained in the docs... but maybe this'll help folks like me who often just read the comments)