More consistent definition of functions / methods + some suggestions

[mossaiby]

Hi all,

I have been thinking for a while on ideas similar to what @chandlerc talked about. Even I was thinking on creating a simple language using LLVM for my own needs (number crunching), without all the complexities of C++, but hey, we all know how long it takes...

After watching the intro video, I had some strange feelings about the syntax, and I think many others have that too. I know that you are trying to simplifying things (especially parsing), but I think it has gone a bit too far and became a little too weird for a successor language. Here is my views, with the hope that they help:

1. I think there is some inconsistency in defining the argument and return types for a function / method; the return type uses -> while every other place is : is used (see suggestions below). Good to see that it is like C++ in some sense, but it doesn't match the other parts well.

2. While I completely understand some decisions taken for simplicity of parsing, I think we could do things so that C++ developers feel better; for example, instead of using fn keyword, we could elaborate something like C++ way of defining lambdas for functions:

[] Print(i: i32): void {...}
class test {
...
  [self: Self] Summarize(i: i32): void {...}
...
}

For methods / generics, you can still put deduced parameters there. This way you do not need to mimic Rust, and still I think parsing is easy enough.

If this is accepted, I believe you can even revert to C / C++ way of defining types of parameters, return type and variable declaration, without the vexing parse problem:

[] Print(i32 type, i32 num) -> void {...}
class test {
...
  [Self self] Summarize(i32 i, i32 num) -> void {...}
...
}
i32 test = 5;
[] (i32) -> i32 func; // define a function-type variable; add const / mutable as needed

3. The next thing I want to complain about is var and let keywords. These remind me of JavaScript, except that they have completely different meanings here and there we have const as well. A suggestion might be using one of them (var? at least it is C#-like!) and use the const (for non-mutable) keyword whenever needed. It is much more readable, I think. Even you can use mutable keyword for the purpose.

4. The syntax for generics / concepts is too weird... consider using something other than ! for it. C++ uses ! for 'not' operator, which seems counterintuitive here.

Thanks!

[OlaFosheimGrostad]

Hi, you might want to chime in on issues that cover some of these.

When we are talking usability then I weight rank legibility/readability/scanning over consistency, within reason. So for function signatures I would want this priority:

1. What does it do?
2. What does it create?
3. What constraints are relevant for its usage?

So priority 1 means the name should be to the left. Priority 2 means that the return type should be given weight, which can be done with a unique marker such as ->. Priority 3 means that it should be possible to push deduction parameters down to the next line (issue #1738).

Note that the -> marker is consistent with C++ auto f() -> return_type notation and formal notations.

name:type is consistent with formal notation and many languages, it is also better than type name as the latter does not line up names for long type specs. In general, what you want to see first as a developer should be pushed all the way to the left (or to the top), so that means the name ought to be to the left. The : makes it more visually distinct what is a type and what is a name binding. This is also the order of a function signature, the name is to the left, and the "anonymous" typing part is following to the right.

Carbon has chosen a conservative syntax approach with introducer-keywords in the tradition of ML (or Algol). I personally don't think this redundancy is necessary now that people use IDEs that highlight syntax mistakes. The argument is that it makes tooling easier, but then again, maybe it would be better to provide ready-made parser-libs?

Regarding your point 3: I saw somewhere that @chandlerc is open for doing user testing with other syntax alternatives. If the compiler AST is clean, then it should quite easy to play with multiple syntaxes during initial testing (as long as macro-like rewrites are avoided). Syntax is easy to change, semantics are not so easy to change, so it is more important that the focus is on the latter at this point, IMO.

Regarding your point 4: I have a preference for "and", "or", "not" (C++ also has these) as I think they are less noisy than sigils, so I think Carbon made a good move there.

The biggest syntax issue for me personally is that Carbon has chosen to depart from the all-lowercase naming scheme for language constructs and core standard library constructs (array etc), this leads to a more noisy screen-display and is clashing with various existing C++ code base style practices.

[OlaFosheimGrostad]

as there seems to be a common (mis?)understanding of what we mean by "successor language"

If the messaging doesn't work, change the message (the term "succession" has very strong connotations, so trying to redefine it is an uphill battle).

[mossaiby]

Thanks @KateGregory and @tkoeppe for clarification.

Parts of it will be familiar, and often when there's no real difference among options we choose the one that is more natural to C++ developers.

I strongly agree with this point; if we can use familiar things from C++, why we should use unfamiliar ones? So if I can suggest a new syntax which does NOT necessarily compile on C++, but provides the characteristics foreseen for Carbon (ease of parsing, etc.) AND looks more familiar to C++ developers, the leads will agree with that, right? I really want to do that, as I see merits in Carbon. Can you please guide me what does not fulfill your expectations in my last post? Maybe we can fix that.

[jonmeow]

Hi @YagaoDirac @OlaFosheimGrostad -- while we appreciate the jokes, they're a bit off-topic and are only serving to distract from the conversation. There's a serious discussion going on, so please don't derail it.