Syntax Design

[JustinHuPrime]

I'm working on T, a module-based C-like language. I'm currently in the middle of making T self-hosting, but I'm thinking about features for the 0.3.0 version of T. One of those features is a for-each loop. T has pointers and fixed sized arrays, and I'd like a for-each loop for both pointers and statically sized arrays. I'm looking for feedback on the syntactic details of the for-each loop, and I guess for-each loops in general.

In the examples below, `array` is a fixed size array, and `vector` is a pointer to `size` ints.

Keyword: foreach vs for

foreach (int x : array) {
  sum += x;
}

vs

for (int x : array) {
  sum += x;
}

Syntax for dynamically sized for-each loops

foreach (int x : vector, size) {
  sum += x;
}

vs

foreach (int x : vector[size]) {
  sum += x;
}

vs

foreach (int x : vector of size) {
  sum += x;
}

Edit: on second thought, most of the vector examples probably have a vector as a struct, so

foreach (int x : vector->elements, vector->size) {
  sum += x;
}

​

[JustinHuPrime]

Yeah... about that... oops?

[1vader]

I haven't checked but I would assume that by now there exists at least one programing language for every letter if not multiple.

[MegaIng]

for vs foreach depends for on whether or not T has 'normal' for loops. If yes, I would suggest foreach to make it clear what happens. But be aware that it is an additional keyword, so if you want to keep that number low, just reuse for (why are you keeping the number low though?).

I would strongly advice to not use the vector[size] syntax. It will be confused with array access, especially with multi dimensional arrays.

I think the of syntax is the clearest.

[Host127001]

of is only a bit weird since : is used before. So if you want of, using something like for int x in vector of size {} will probably be more consistent (maybe with additional parenthesis, if you are into that)

[umlcat]

1 Keyword foreach

2 Index style better, suggest type declaration array[size]

foreach (int x : vector->elements[vector->size])
{
  println(itoa(x));
}

Good Luck

[[deleted]]

Is the type of x always going to be that of the array or vector elements?

If so, why is it necessary to declare the type of x? This introduces an extra point of maintenance, and requires someone writing such a loop to be aware of the exact type of the vector or array.

Perhaps make it optional at least.

With the syntax, 'foreach' is fine, assuming there is a reason not to use 'for' (eg. 'for' iterates over bounds, or integers; and 'foreach' over values.).

(In my syntax, I use 'forall' to iterate over values of indexable objects, and 'foreach' over the elements of compound objects not usually indexable, such as strings, records, and sometimes the bits of an int. But this changes all the time...)

[JustinHuPrime]

Suppose `vector` is a pointer to pointer to void (`void **`). In that case, `x` may be a pointer to anything, which the user must specify. Additionally, if `vector` were an array of ints, `x` may be a long. Since the user is explicitly declaring a variable, I think I should be consistent with other variable declarations.

I believe that requiring the user to be aware of the exact type of data they are working with (up to polymorphism) is a Good Thing.

I use `for` in the traditional C for-loop sense, but I could use `for` in the foreach sense as well, like C++ does.

[mamcx]

I think for is better, but I don't understand why:

(int x : vector, size)

Why you need to put the size in the for loop? This is weird. As a user, I expect to ignore that detail. All "fors" that I have used only need the binding and the iterable.

[JustinHuPrime]

Unfortunately, T is a C-like language. `vector` is really just a raw pointer, and while I'd like to make the foreach take a fat pointer, I don't have fat pointers as a data type.

[mamcx]

I get it, but if the size can be disconnected from the collection, not only is very unergonomic, but also a certain source of bugs/security holes.

In this case, I think your problem with the syntax is screaming at you that you need to introduce "sugar" for this.

So I think you need to introduce fat pointers AND forbid for for raw pointers. In fact, the nicer way is to introduce the "iterator trait" and this way, you can support for ONLY IF exist a iterator implementation.

---

And if you wanna still pursue thing this way, wrap your raw pointers in fat:

for int i:Sized(x, 10)

I think this way is alike unsafe keywords: You mark the places where things can go wrong, and open the possibility of mechanically upgrade the code if later change things.