Syntax Design - Expressing Intent and Pronounceability principles

[ghsi011]

I watched the intro, I really liked the back-to "first principles" approach of the language and the Interop method of succeeding C++
I would like to suggest 2 core principles that I think will really help with syntax design.

The first is the Expression of intent
I think we all agree that code should express intent (at least anyone who watched herb's talks).
Taking this to the language design level will not only help make code more readable, but will also make learning and teaching the language much easier too!
Carbon does it right in some places but it gets it wrong in others, I will give some basic examples:

For instance, a good example in current carbon design is inheritance using the abstract, impl and virtual keywords.
This design is very explicit and easier to understand
making the difference between virtual and pure virtual functions trivially teachable as opposed to C++

virtual void foo();
virtual void bar() = 0;  // Using assignment to mark a function as pure virtual is not consistent and another thing you need to teach

another good example is interface which is clearer than concept and also utilizes the same syntax as when declaring a class making it easier to teach.

A bad example in current design would be the let and var keywords
Imagine asking a developer new to the language the following question:

"In the example below what do you think is the difference between variable a and b?
In Carbon:

let a: i32;
var b: i32;

In C++

const int32_t a;
int32_t b;

The answer is of course that a is constant\immutable and b is mutable.
But in which language would the learner have an easier time learning?

The use of the keyword const expresses intent and thus makes the code more readable and easier to teach while let does not offer that.
another advantage of the C++ style of declaration is that changing the constness of a variable is easier:
You either delete the const or you add it. no delete one word then write the other. this also makes spotting and comprehending changes much easier when reviewing diffs.

My suggested syntax would be to just remove the keyword let and combine const with var this should also not hurt parsing and can be done in two flavors:
Either joining the constness with the type:

var a: const i32;
var b: i32;

Or joining it with var (which would be a drop and replace with let)

const var a: i32;
var b: i32;

perhaps only one should be possible or maybe both (imagine declaring Vector(const i32) vs Vector(i32))

Another principle that should be considered is Pronounceability - ensuring the code is as pronounceable as possible(without making it too cumbersome)
This means that it is easy to read out loud or voice in your head, Making it easier to talk about with other teammates, and generally more human-friendly.

This also ties in with readability and works very well with the previous principle.
Making code easier to read and understand.
Try to read out loud each of the following examples:

Good:

const var my_number: int32 = 50; // pronounceable 

Bad:

const var m_n: i32 = 50; // not so pronounceable

Good:

function Partition[T as Comparable and Movable](slice: Slice(T))
     -> int64 {...}

Bad:

fn Partition[T:! Comparable & Movable](s: Slice(T))
     -> i64 {...}

perhaps is or requires would be better than as but either way this is much easier to read, understand and teach.

I hope you take my suggestions into consideration and create a language that is both explicit and easy to read and reason about! :)

[OlaFosheimGrostad]

I guess my personal preference would be to get rid of both let and var and just use

a:const<i32> = 3;
b:i32 = f();
b := 45;  // typed as const<i64>

One advantage of having let and var might be that you can change to meaning of :T from "is followed by type T" to "is constrained by expression T". That way you could cast values as 3:i8 or 42:f32. As other have pointed out, one ought to allow:

let a = 3;
var b = f();

But the syntax is easy to change later, so it is more important to get the semantics right for v0.1?

[jens-auer]

I think let feels very natural for people with a background in mathematics and computer science. There is also a lot of prior art for this in programming languages such as Scheme or Pascal. Looking from a perspective as a C++ programmer it certainly feels strange, but I appreciate using well-defined concepts.

[L4stR1t3s]

I think the biggest issue I have with var/let is that it removes the mutability syntax from the type and adds it to the name instead.

In C++ the mutability syntax is always tied to the type:

const int i = 0;
// or
int const i = 0;
// but not
// int i const = 0;

In Carbon it is connected to the name:

var i: i32 = 0;
let i: i32 = 0;

It just feels wrong to me to, because the mutability is directly related to the type of a variable and not the name. Especially for templates this can be important:

template <class T>
class Object;

template <class T>
class Object<const T> {
public:
	const T& Get() const { return x; }
protected:
	T x { 42 };
};

template <class T>
class Object : public Object<const T> {
public:
	T& Get() { return Object<const T>::x; }
};

// Now you can declare an Object for both const and non-const types and it will have the appropriate Get() member functions:
Object<int> obj;
Object<const int> cobj;

I know code generation hasn't really been looked into for Carbon, but I think the var/let syntax is not really compatible with code generation. If you are writing template code that can deal with both, what do you do then if you need to define a variable that could be mutable or immutable depending on the template parameters? An additional keyword? A lot more verbose code that checks mutability everywhere at compile-time?

I also don't really understand why a distinction needs to be made between const and non-const variables that requires specific syntax to declare them. Will Carbon treat these differently somehow? C++ doesn't, even if something is declared const, you can still change its value:

const int i = 0;
const_cast<int &>(i) = 1;

I also think that a future addition of constexpr in Carbon should be taken into account in this discussion, but like code generation not a lot has been done yet in Carbon around compile-time evaluation.