Skip to content

[NEXT] Fully supported, user-defined types with custom operations? #63

@Sir-NoChill

Description

@Sir-NoChill

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

No one assigned

    Labels

    nextFuture updates to the spec not implementable for the current year

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions