Copper: A statically-typed, loose syntax programming language • Hacker News Board

Re: Copper: A statically-typed, loose syntax programming language

#11

Post by kroltan » Sat, Oct 03, 2020, 11:47 AM UTC

throwaway_pdp09 wrote: post #10

(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…

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

Re: Copper: A statically-typed, loose syntax programming language

#12

Post by skohan » Sat, Oct 03, 2020, 12:09 PM UTC

tom_mellior wrote: post #3

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

Re: Copper: A statically-typed, loose syntax programming language

#13

Post by skohan » Sat, Oct 03, 2020, 12:11 PM UTC

throwaway_pdp09 wrote: post #10

(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…

I agree about looseness in general, but I disagree about semicolons. After having gotten used to programming without them, they always feel like a tedious burden which adds no value when I'm working with a language where they're required again.

Re: Copper: A statically-typed, loose syntax programming language

#14

Post by tom_mellior » Sat, Oct 03, 2020, 12:33 PM UTC

kroltan wrote: post #11

throwaway_pdp09 wrote: post #10

(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…

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

Re: Copper: A statically-typed, loose syntax programming language

#15

Post by [deleted] » Sat, Oct 03, 2020, 1:11 PM UTC

tom_mellior wrote: post #14

kroltan wrote: post #11

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)

[deleted]

Re: Copper: A statically-typed, loose syntax programming language

#16

Post by throwaway_pdp09 » Sat, Oct 03, 2020, 1:12 PM UTC

kroltan wrote: post #11

throwaway_pdp09 wrote: post #10

(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…

> 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 criticising, asking.

> Local variable access using :? / No commas between parameters? / Operators using function call syntax?

Well, yes, yes and yes.

Re: Copper: A statically-typed, loose syntax programming language

#17

Post by uryga » Sat, Oct 03, 2020, 1:47 PM UTC

tom_mellior wrote: post #3

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

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

Re: Copper: A statically-typed, loose syntax programming language

#18

Post by nercht12 » Sat, Oct 03, 2020, 2:40 PM UTC

throwaway_pdp09 wrote: post #10

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

Re: Copper: A statically-typed, loose syntax programming language

#19

Post by nercht12 » Sat, Oct 03, 2020, 2:52 PM UTC

uryga wrote: post #17

tom_mellior wrote: post #3

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

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

Re: Copper: A statically-typed, loose syntax programming language

#20

Post by kroltan » Sat, Oct 03, 2020, 4:08 PM UTC

throwaway_pdp09 wrote: post #16

kroltan wrote: post #11

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 criticising, asking. > Local variable access using :? / No commas between parameters? / Operators using function call syntax? Well, yes, yes and yes.

Didn't mean to imply, my bad.

Commas and function-call operators is actually pretty common in Lisp-likes, though they usually still use the symbol instead of some shorthand or initialism, and the opening parens comes before the function name:

    (= (> 4 1) true)

I'm not a fan of Copper's local variable syntax though, as the uncle comment by tom_mellior articulated, looks too much like association.