[CHANGE] Spec Proposal 2026

[Sir-NoChill]

Gazprea '26 Specification Proposal

This is my working upstream PR of a specification for the 2026 gazprea implementation. Currently I would say that the documentation is ready for revision, and would like to point the reviewers to a few specific choices I made that may be contraversial:

Collapsing Aggregate and Composite types

• arrays and vectors are now part of a unified n-d array specification

Rationale: vectors as dynamic arrays felt uncomfortable in the syntax of gazprea, but we can provide the same power by using dynamic arrays. The idea is that, to the programmer, static and dynamic arrays behave the same and can all be concatenated to. So long as the range is known at compile time, we treat the array like a static array, only once we encounter a non-static array length (whether by concatenation or by initialization from a non-constexpr) will the implementation treat the array as a dynamic array. We can test student implementations of static vs dynamic arrays with creative testing (I have some proposals I will outline privately).

• structs are fused back into tuples

Rationale: Since structs essentially took over the tagged tuple in the last version of the spec it created a problem in the specification of our type system. I wanted to resolve this, and you will see in the typing section that I have outlined a formal type lattice for the language. Now tuples use tags as part of their type identity, and this allows us to implement a 'weak normative type' using a tuple.

The future of the gazprea type system could be extended. We could allow for normative type declarations with the addition of the type keyword. This also frees up the future development of impls on custom types.

Future Consideration

Both of these options are for future consideration, but this is what my end goal (whether as part of the language spec for students or as extensions for if they complete the full specification) would look like:

type Point = tuple(integer x, integer y) impl {  // custom normative type
 function distance(self, other) returns real { ... }
}

typealias PointAlias = tuple(integer x, integer y); // cannot share names between alias and type decl
typealias Pnt = tuple(integer x, integer y); 

PointAlias pt0 = (3, 4)
Pnt pt1 = (3, 4);
Point pt2 = (3, 4);
pt1 == pt2 -> std_output; // returns false because the pt2 is a normative type
pt0 == pt1 -> std_output; // returns true since they are elementwise tag, value and type equivalent

We can discuss this at a later date, but this serves as a motivating example for my changes to tuples.

• Tuples and Arrays may hold any type

Rationale: It just didn't make sense to restrict it any more with mlir. If students use memref they may need to define a light type wrapper around their structs to make arrays work and vv, but in mlir defining your own type is simple and you don't need to define the rest of the language in your own dialect, you can mix and match. Otherwise students have success with tuple destructuring in the front-end.

• Jagged Arrays do Not Exist

Rationale: Due to the restrictions I imposed on lvalues/rvalues in slices, jagged arrays could only be defined at compile time. Further, jagged arrays have little use that tuples of dynamic arrays will not cover, especially tuples of dynamic n-d arrays.

Slices are R-Values and Copy-On-Write objects

Rationale: Slices, as we discussed a few times last semester, are most easily represented as a view into an array. Unfortunately, doing this for real causes many problems in the type system for a constrained language like gazprea. Broadening the type system to account for references causes us to need more value categories, like modern C++ has now, and I am not confident in students being able to execute that value category complexity in a way that makes them better programmers. By contrast, we can still teach a very useful optimization if we tell the students that slices are not eagerly copied from their sources. This way, if a slice is assigned to some lvalue, then we can keep it around as a reference until it is modified.

This aligns with @rcunrau's goal of having reference passing through function arguments, and, now that we can define n-d dynamic arrays, should provide students the opportunity to write some more tricky, low-level code if they want.

Type Lattice Definition

• Solid lines represent implicit relationships that do not require an explicit cast

Other Notes

• I have included a definition for constexprs
• The most substantial modifications are in types, arrays and tuples, so if you look at anything, look at that
• Also note that I did get significant input from various LLMs, but I believe I have vetted their outputs meticulously, so any failings that demonstrate true LLM halucinations should be directly attributed to my lack of attention to detail. I apologise if these exist and will update accordingly. You can follow my final edit in 6495ac8
• Related:
  • fixes Specify that globals may only be scalar types #88 , fixes [NEXT] Constexprs #79 - constexprs
  • fixes [NEXT] Aliasing Errors #87 - clearer definition of aliasing errors in arrays
  • fixes n-dimension array #86 , fixes [NEXT] N-d arrays #82 - defines n-d arrays
  • fixes [NEXT] Functions vs Methods in Builtins #80 - obliterates signature ambiguity in builtins
  • fixes [NEXT] Nested Composite Types #71 - nested composites are allowed

[JustinMeimar]

Right of the bat I like unifying structs and tuples, as well as vectors and arrays, into single types with more expressive semantics. Will take a thorough look over the weekend.

[r-dean]

I think it would make more sense to make jagged array literals (or any operations that yeild jagged r-values) illegal.

[Sir-NoChill]

I was thinking that they would be useful as a data container, so you could have a tuple tuple (integer[*], integer[*], integer[*]) a = ([1, 2, 3], [3, 4], [5, 6, 7, 8]) especially for things like lookup tables. Thoughts? Currently I was thinking that true jagged arrays are illegal.

[r-dean]

Totally agree that this approach makes sense.

The interpretation I'm advocating is that integer[*][*] be treated as a type-erased wrapper for any integer[n][m] type.

tuple(integer[*], integer[*][*]) container = ([], [[]]) // legal (underlying object type is tuple(integer[0], integer[0][0]))
container = ([1], [[2,3,4]]);   // legal (underlying object type is tuple(integer[1], integer[1][3]))
container = ([], [1]);          // illegal (wrong dimensionality)
container = ([], [[1],[]]);     // illegal (ragged array literal)

The best analog I can think of is std::function in C++:

struct Adder {
    int operator()(int x, int y) const {
        return x + y;
    }
};

struct Multiplier {
    int operator()(int x, int y) const {
        return x * y;
    }
};

int main() {
    Adder a{};
    Multiplier m{};
    std::function<int(int, int)> f = a;    // Underlying type is Adder
    f = m;                                 // Now underlying type is Multiplier
}

[Sir-NoChill]

I think we are aligned here, is there a way I could specify this better? Currently I just have it removed.

[Sir-NoChill]

Also, sorry @rcunrau did not see your comment on the other PR:

That's a lot of proposals! I cannot/will not try to figure out your intent via context diffs. If you want to make proposals with illustrations of what's wrong and what you're fixing we can discuss it, but I don't think I'll have to time to discuss it before May. I also remember that we held back on a number of things like arrays of structs, nested tuples, etc. because we were concerned that they were too much work. I also remember we discussed the direction forward as towards more compiler stuff (e.g. SSA inference or dead code) and less language stuff (e.g. user defined classes/objects). Does your feedback say the students wanted more language stuff? (I heard the opposite)

Originally posted by @rcunrau in #89 (comment)

So I looked through my previous proposal and agree. This one, in contrast, slims things down a fair bit and should clarify a few of the larger issues that students faced last term. WRT specific comments:

• I think nested arrays and structs might actually make things easier especially since I now have a very clear idea of how to use memref properly to make these types of structures easily.
• We did discuss towards more compiler stuff. I am modeling the type system here after a weaker version of the kotlin type system. It should allow for students to get a taste of type inference without needing to fully implement a borrow checker (which I read about and now understand why they need constraint programming for it to work, the system we want is kotlin-esque).
• I also have a set of proposals for 'language extensions' that I will open in another PR, but probably much later.

I should note that the only reason I started this so early is so that I can bring the solution compiler up to speed.

[max-leontiev]

What is the rationale behind having mixed tuples? They don't seem very useful to me.

If the purpose of mixed tuples is to add a bit of complexity to the implementation, in my opinion this complexity is not particularly "interesting".

To be clear, the mechanics of mixed tuples are well-described here; I'm just wondering why they're allowed.

[Sir-NoChill]

I'm thinking that they can almost be like private fields/structural fields. I admit that it is a little bit of a contrived example, but if you have two types typedef tuple (integer a, float) A; and typedef tuple(integer a, integer) B and they represent some related quantities but one requires the float and the other doesn't (like an iterator) then you can upcase B -> A implicitly.

I can see how this is perhaps not interesting, but I think it is consistent with the definition of a tuple in the language if we fold tagged fields into tuples.

Would you say that only having either entirely tagged or entirely untagged (anonymous) tuples makes better sense? My counter argument was that to have, forcibly, either one or the other feels arbitrary.

[max-leontiev]

I think that having either entirely tagged or entirely untagged tuples makes more sense, partially because it better matches the languages I know (which may or may not be a compelling reason for you):

• Rust - tuple and tuple struct (untagged) vs. normal struct (tagged):

  /*
  Allowed
  */
  // Instances accessed with .0, .1
  struct TupleStruct(i32, i32);
  // Also accessed with .0, .1
  let tup: (i32, i32) = (1, 2);
  // Instances accessed with .a, .b
  //
  // Indexed access with .0 and .1 isn't allowed in Rust.
  // My understanding is that this is because the Rust compiler
  // has the freedom to reorder the fields
  // and it would be a bit odd to allow .0 to actually access
  // field 1 after reordering. This isn't really a problem
  // for Gazprea because there is no reason to reorder fields,
  // so it's fine to allow indexed access for tagged tuples.
  struct NormalStruct { 
    a: i32,
    b: i32
  }
  
  /*
  Not allowed
  */
  struct MixedStruct {
    a: i32,
    i32
  }

• C#, C++ - tuple (untagged) vs. struct (tagged)
• Python - tuple (untagged) vs. collections.namedtuple (tagged, also allows access by index)

[max-leontiev]

It would be great if constexpr function calls (not procedure calls) were allowed, although I admit this might be better as an optional extension.

A function call is constexpr if all arguments are constexpr. For example:

function my_number() returns integer { return 2; }
function times_two(integer val) returns integer { return val * 2; }
procedure two_times(integer val) returns integer { return val * 2; }

//
// Constexpr
//
const m = my_number(); // function call where all arguments are constexpr
const n = times_two(m); // function call where all arguments are constexpr

//
// Not constexpr
//
var integer x;
x <- std_input;
const p = times_two(x); // function call but (at least) one of the arguments is not constexpr
const q = two_times(m); // procedure call is not constexpr even if arguments are constexpr

As with the existing proposal, adventurous teams might try to actually evaluate all constexprs at compile-time (by implementing a partial Gazprea interpreter to execute constexpr functions at compile-time), while I assume most teams will only perform constexpr validation at compile-time and defer the computation to runtime. Admittedly, having constexpr functions makes things a lot harder for the adventurous teams since the constexpr evaluator will have to deal with every control-flow construct that exists in the language.

[Sir-NoChill]

Yeah, this would have to be an extension. We would run into a problem where you end up implementing a full gazprea interpreter and compiler to deal with these constructs. I agree, it would be fun, but I'll add it to the set of extensions I have for the moment.

My current list (I might just open another PR with these and mention this comment so that folks can add more):

• type as a keyword (see the PR desc) and type methods
• extern and multi-file gazprea programs (so invoking the linker and associated machinery)
• More aggressive type inference (read, global type inference with a type constraint system)
• Exposing memory primitives to gazprea users
• Implementing move/reference semantics and implementing a borrow checker to deal with them

[max-leontiev]

Sounds good! I would argue that it isn't quite a full Gazprea interpreter because it doesn't have to deal with procedures at all (since those can't be constexpr), so no I/O or handling of aliasing. But yeah, still better as an optional extension.

[JustinMeimar]

Ranges are currently inclusive on both ends. Is the motivation for making the upper bound exclusive to give parity with slices? If so that's well justified IMO. Just note that dozens of examples likely still use the doubly inclusive construction, so will need to be patched.

[Sir-NoChill]

oops, tbh I just forgot they were inclusive on both ends.

I'm open to discussion on this, I think that for a programmer who would use gazprea (ex. business people, non-systems programmers) that the most expected behaviour might be inclusive on both ends, but you make a good point that this makes everything consistent in slices.

[JustinMeimar]

IIRC, we have allowed function calls in the both 1) the size expression of an array type, and 2) the initialization elements of an array value.

// valid as of current Gazprea
// global scope
integer function foo() returns integer = 3; 
// local scope
integer[foo()] a = [1, 2, foo()];

I do agree that it the BAD_TABLE example shouldn't be constexpr, but I believe the second justification may contradict the current version of Gapzrea, unless this is an intended restriction.

[Sir-NoChill]

I was on the fence about that too. I am willing to make that change to allow function calls in both, I think procedure calls could get a bit gnarly if we allow something like:

procedure foo(integer) returns integer { inner = a - 1; a = a + 1; return inner; }

// local scope
var a = 4;
integer[foo()] = [1, 2, a];

I think the correct behaviour in this case would be that a = 5 in the final array because we need to evaluate foo() for the size before the instantiation of the array.

Or should we still disallow procedures in instantiations?

[Sir-NoChill]

I see the line you were referencing here, I fixed that since you're right, function calls should be allowed in declarations.

[JustinMeimar]

Overall, I find this to be a productive direction for the language to take. There will be some collateral in the form of examples to redo but I assume that will be a future issue before next fall. Nice work!

[max-leontiev]

When I was thinking about tagged/untagged tuples, I looked at the Rust book page on Defining and Instantiating Structs. This made me think that Gazprea could also adopt "partial update syntax" by extending the spread operator .... What I mean is:

typealias tuple(integer, integer) pair;
typealias tuple(integer, integer, integer) triple;
typealias tuple(integer, integer, integer, integer) quad;
typealias tuple(integer a, integer b) tagged_pair;
typealias tuple(integer a, integer b, integer c) tagged_triple;
typealias tuple(integer a, integer b, integer c, integer d) tagged_quad;

// For untagged tuples
pair x = (1, 2);
triple y1 = (...x, 3);  // y1 = (1, 2, 3)
triple y2 = (1, ...x);  // y2 = (1, 1, 2)
pair y3 = ...x;         // error: ...tuple is illegal outside of tuple literal
pair y4 = (...x);       // legal, y4 = (1, 2)
quad y5 = (...x, ...x); // legal, y5 = (1, 2, 1, 2)
pair y6 = (...(1, 2));  // legal, y6 = (1, 2)
tuple(real, real) y7 = (...x); // legal thanks to tuple->tuple promotion

// For tagged tuples
tagged_pair t = (a: 1, b: 2);
tagged_triple u1 = (c: 3, ...t);   // u1 = (a: 1, b: 2, c: 3)
tagged_triple u2 = (...t, c: 3);   // u2 = (a: 1, b: 2, c: 3)
tagged_triple u3 = (a: 1, ...t);   // error: duplicate field name a, also c isn't defined
tagged_pair u4 = ...t;             // error: ...tuple is illegal outside of tuple literal
tagged_pair u5 = (...t);           // legal, u5 = (a: 1, b: 2)
tagged_pair u6 = (...(a: 1, b: 2)) // legal, u6 = (a: 1, b: 2)

// Mixing tagged/untagged using ... is illegal like you'd expect
pair v = (...t);        // error: type mismatch, untagged tuple initialized with tagged tuple
tagged_pair w = (...x); // error: type mismatch, tagged tuple initialized with untagged tuple

We don't have to call it partial update syntax, that's just the name for it in the Rust book.

I don't think this introduces any ambiguities and I could imagine plenty of situations where this syntax could come in handy.

Note that I didn't put any thought into how this would be handled for mixed tuples, because I think being able to use this proposed syntax in an easy-to-understand way is another reason to abandon mixed tuples.

[Sir-NoChill]

This is neat, and I like it. I think it's a natural extension