[nercht12]

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 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...

[tom_mellior]

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)?

[nercht12]

a's type didn't change. The trap was that the wrapping function returned its nested function instead of itself. You can do the same thing in other languages, it's just easier to slip into code in Copper. Let me illustrate with pseudo C code:

[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]