4 ms·

Am I the only one that really dislikes the Cpp2 syntax? I get it's coming from a Rust influence, but it just feel much harder to parse by humans. The way a fun

by mihaic 4y ago

Am I the only one that really dislikes the Cpp2 syntax? I get it's coming from a Rust influence, but it just feel much harder to parse by humans. The way a function is declares looks just like a variable assignment for instance, but in a compiled language it pushes the wrong paradigm on me, since that's pretty much immutable. I must admit that I'm mostly writing Python and JS these days, but the way the colon is being used feels grossly inconsistent and confusing. Why not say std.vector for instance now instead of std::vector?)

cwzwarich 4y ago
> The way a function is declares looks just like a variable assignment for instance, but in a compiled language it pushes the wrong paradigm on me, since that's pretty much immutable. I think one of the problems with the syntax is that colon (ordinary used for type ascription in ML-family languages) is being used for... something else. For example, in foo: (x: int) -> int = (expression using x) the introduction of the 'x' binding is in the type position of 'foo', whereas in OCaml it would be let foo (x: int): int = ... Here the binding of 'x' is associated to 'foo' rather than first appearing in type position. I think this is more readable, and the component parts are more easily parsed by humans. One could argue that visually, using an arrow as in let foo (x: int) -> int = ... is more readable, but the OCaml syntax captures the fact that the RHS of the binding is defining an 'int' rather than a function value. > I must admit that I'm mostly writing Python and JS these days, but the way the colon is being used feels grossly inconsistent and confusing. Why not say std.vector for instance now instead of std::vector?) One potential sensible distinction would be to use one for statically determined paths and the other for dynamically determined paths (including the separate dynamic phase of compile-time constexpr evaluation).
- still_grokking 4y ago
  > the RHS of the binding is defining an 'int' rather than a function value But what's the difference between an `int` value and a function value? It's only the type! I don't know Cpp2, need to have a closer look, but treating everything as a value makes perfect sense, imho, as everything is just a value in the end. Any definition will become some structure in memory eventually. A "program", and a function is nothing else than a "small program", is data. Only the interpretation of said data makes the difference. Types hint at how some data is meant to be interpreted. You could say they determine the interpreter to use, later on. A syntax that makes those basic ideas very clear seems therefore very convincing to me. It's imho less confusing than something that does treat some "special" types of data, namely function values, very differently even on the syntax level, although the only difference is the type (which is the hint at how this data should be interpreted and nothing more). Even an `int` value can be "executed", so there is no fundamental difference to the idea of a "function". Just interpret the `int` as a pointer to memory. The machine doesn't care as it allows arbitrary interpretations of arbitrary data structures. That's the whole point of a programmable computer in fact. (And also the constant source of the security issues with them).
avgcorrection 4y ago
In fact the type declaration in the function definition for Cpp2 looks better than the one in Rust. The Rust one looks confused.
tialaramex 4y ago
As a Rust programmer it doesn't look like Rust influence to me. Rust would have "introducer keywords" here so that we know what we're doing e.g. fn is a function, let is a variable declaration, const is a constant definition ...

by mihaic 4y ago

cwzwarich 4y ago

> The way a function is declares looks just like a variable assignment for instance, but in a compiled language it pushes the wrong paradigm on me, since that's pretty much immutable. I think one of the problems with the syntax is that colon (ordinary used for type ascription in ML-family languages) is being used for... something else. For example, in foo: (x: int) -> int = (expression using x) the introduction of the 'x' binding is in the type position of 'foo', whereas in OCaml it would be let foo (x: int): int = ... Here the binding of 'x' is associated to 'foo' rather than first appearing in type position. I think this is more readable, and the component parts are more easily parsed by humans. One could argue that visually, using an arrow as in let foo (x: int) -> int = ... is more readable, but the OCaml syntax captures the fact that the RHS of the binding is defining an 'int' rather than a function value. > I must admit that I'm mostly writing Python and JS these days, but the way the colon is being used feels grossly inconsistent and confusing. Why not say std.vector for instance now instead of std::vector?) One potential sensible distinction would be to use one for statically determined paths and the other for dynamically determined paths (including the separate dynamic phase of compile-time constexpr evaluation).

still_grokking 4y ago
> the RHS of the binding is defining an 'int' rather than a function value But what's the difference between an `int` value and a function value? It's only the type! I don't know Cpp2, need to have a closer look, but treating everything as a value makes perfect sense, imho, as everything is just a value in the end. Any definition will become some structure in memory eventually. A "program", and a function is nothing else than a "small program", is data. Only the interpretation of said data makes the difference. Types hint at how some data is meant to be interpreted. You could say they determine the interpreter to use, later on. A syntax that makes those basic ideas very clear seems therefore very convincing to me. It's imho less confusing than something that does treat some "special" types of data, namely function values, very differently even on the syntax level, although the only difference is the type (which is the hint at how this data should be interpreted and nothing more). Even an `int` value can be "executed", so there is no fundamental difference to the idea of a "function". Just interpret the `int` as a pointer to memory. The machine doesn't care as it allows arbitrary interpretations of arbitrary data structures. That's the whole point of a programmable computer in fact. (And also the constant source of the security issues with them).

avgcorrection 4y ago

In fact the type declaration in the function definition for Cpp2 looks better than the one in Rust. The Rust one looks confused.

tialaramex 4y ago

As a Rust programmer it doesn't look like Rust influence to me. Rust would have "introducer keywords" here so that we know what we're doing e.g. fn is a function, let is a variable declaration, const is a constant definition ...