-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Labels
nextFuture updates to the spec not implementable for the current yearFuture updates to the spec not implementable for the current year
Description
One construct I would like to support in gazprea is the creation of functions on user defined types like
struct hooman (integer age, string name);
impl hooman {
function getAge() returns integer {
return this.age;
}
procedure happyBirthday() {
this.age = this.age + 1;
}
}
procedure main() returns integer {
hooman me = (23, "Mr Can of Beans");
me.happyBirthday();
me.getAge() -> std_output;
return 0;
}
Which should print 24.
Pedagogical worth
To be fair, this might just be me wanting gazprea == rust but I do think this adds a lot of flexibility to the language and readability to the programs students define. The front end transformation would be relatively simple, just needing to fold the impl members into functions/procedures with the first argument as this and then evaluate normally.
The thing this opens us up for in the future is to tackle some form of polymorphism, but once again with a four month course that might be going too far. I list my pros and cons below:
Pros
- Provides the students first taste of folding at a function level in the AST.
- Note that most students already implicitly fold tuples into individual variables when they need to work with them in the backend. I think that it would be good to expose the concept of 'folding' more formally to the students in the course.
- No real back-end considerations required if the front end is effective
- Students are already exposed to this notation in the vectors
- If we set it up correctly and begin to allow memory transformations (eg.
malloc) then we no longer need vectors as a base type and can start collecting a 'standard library' with these constructs defined in gazprea instead of relying on student implementations.
Cons
- The language does get more complex
- Competitive testing might be hammered with impls, and if a group does not get there then they could be disproportionately impacted
- This might point us towards a rust-like type of polymorphism, which I'm not sure is the direction we want to go.
Metadata
Metadata
Assignees
Labels
nextFuture updates to the spec not implementable for the current yearFuture updates to the spec not implementable for the current year