Allow accessing struct fields through the struct name rather than the instance name

[kontheocharis]

Consider the following example:

Add := struct <T> (
    add: (T, T) -> T
)

Colour := struct(r: u8, g: u8, b: u8)

colour_add := Add<Colour>(
    add = (a, b) => Colour(a.r + b.r, a.g + b.g, a.b + b.b)
)

main := () => {
    c1 := Colour(0, 0, 0)
    c2 := Colour(0, 1, 0)
    c3 := colour_add.add(c1, c2)
}

The ideal situation is that instead of colour_add.add(c1, c2) we can write c1 + c2 or something like Add::add(c1, c2). Since there is only a single instance of Add<Colour>, it would be unambiguous to resolve Add::add(c1, c2) to colour_add.add(c1, c2). For this reason, the following feature could be added:

Each struct field like add can be accessed from the main struct Add by using the :: operator: Add::add. Then, this becomes the following function:

Add::add := <T> => <instance: Add<T>> => (a: T, b: T) -> T => instance.add(a, b)

Conceptually, Add::add means to access the field add of some instance of Add that should be somehow inferred. This inference can occur if there exists some, for example, instance colour_add: Add<Colour> defined earlier (as above).

More generally, for a struct

S := struct <T1..TN> (field1: F1...fieldN: FN)

we have functions

S::fieldI : <T1...TN> -> <instance: S<T1...TN>> -> FI
          = <T1...TN> => <instance: S<T1...TN>> => instance.fieldI

for all I = 1..N

To be more explicit, this is functionality which recovers the benefits of a trait system.

[feds01]

whilst I agree that this feature is useful and something we want to have, how does it fit with traits/impl blocks? Is the intent to move away from the Rusty way of doing traits and things like this?

[feds01]

Furthermore, what occurs when there are conflicts, how do you distinguish which method you mean or does it disallow this to happen in principle. Also, in the case of the original type having the same function defined on it, what happens? For example:

Add := struct <T> (
    add: (T, T) -> T
)

Colour := struct(
    r: u8, g: u8, b: u8,
     
    add: (Self, Self) -> Self;
);

// Does this then become disallowed?
colour_add := Add<Colour>(
    add = (a, b) => Colour(a.r + b.r, a.g + b.g, a.b + b.b)
);

main := () => {
    a := Colour::red();
    b := Colour::black();

   // ~ERROR: ambiguous function reference, `Colour` already has member `add` defined
   mix := a + b
}

And again, what happens if you have another Adder defined which has conflicting function names/definitions?

[kontheocharis]

first, there is no such thing as a Self symbol in a struct.

The intention is not to move away from traits and impls, it is more to unify this with structs and instances; they really are the same thing.

And again, what happens if you have another Adder defined which has conflicting function names/definitions?

The + operator would only be tied to the Add struct, not to any function called add (In the same way that in Rust the + operator invokes the Add trait).

In terms of conflicts, the easiest solution is that if at some call site there are multiple candidates to infer for instance, an error is shown which says

colour_add_1 := Add<Colour>(
    add = (a, b) => Colour(a.r + b.r, a.g + b.g, a.b + b.b)
)
colour_add_2 := Add<Colour>(
    add = (a, b) => Colour(a.r + 2 * b.r, a.g + 2 * b.g, a.b + 2 * b.b)
)

main := () => {
    c1 := Colour(0, 0, 0)
    c2 := Colour(0, 1, 0)
    c3 := c1 + c2 
    // ^^^ Error: Ambiguous call to `Add::add`: two instances exist,
    // one defined at (..) and another at (..). 
    // Disambiguate by explicitly using the name of the instance `colour_add_1.add` or `colour_add_2.add`.
}

[kontheocharis]

Additionally, "inherent" impl blocks could be represented in the following way, using the syntax from #9 :

Colour := (
    this struct(r: u8, g: u8, b: u8),
    
    invert := (a: Colour) => {
        Colour(r = 0xff - a.r, g = 0xff - a.g, b = 0xff - a.b)
    }
)

main := () => {
    print(Colour.invert(Colour(0, 1, 0)))
}

[kontheocharis]

I think there are definitely lots of intricacies to figure out, like for example supporting method call syntax like .invert() above. However, my idea is that at the core, whatever trait mechanics Hash supports should be part of the way that structs and instances of structs work. This is motivated further by the fact that Types can appear as members of structs. This ability is not shared by Rust, and it is powerful because it essentially models associated types:

Iterator := struct <T> (
    Item: Type,
    next: (&mut T) -> Option<Item>
)

Due to this feature parity between structs in Hash and traits in Rust, alongside some resolution mechanics like above, it would be really strange to invent a whole another construct to represent traits that would effectively be a duplication of structs.

[feds01]

first, there is no such thing as a Self symbol in a struct.

Yeah it was meant as an example, I guess its a separate issue!

[feds01]

Additionally, "inherent" impl blocks could be represented in the following way, using the syntax from #9 :

Colour := (
    this struct(r: u8, g: u8, b: u8),
    
    invert := (a: Colour) => {
        Colour(r = 0xff - a.r, g = 0xff - a.g, b = 0xff - a.b)
    }
)

main := () => {
    print(Colour.invert(Colour(0, 1, 0)))
}

I think this is an interesting way to express the same intent as an implementation block, and you are right to say that there are still things to work out. It would be nice to see:

• How things like self can be referred to (in the example above for invert)
• method call syntax for these functions

[feds01]

I think this feature (after some refinement) could be a great addition. It can allow for basic trait-like functionality in the language without having traits specifically.

[kontheocharis]

How things like self can be referred to (in the example above for invert)

The parameter (a: Colour) acts as self. Perhaps there can be a way of desugaring self to the actual type.