Member/instance function implementation

[chronium]

I have a couple ideas, but other are welcome:
Given

rec Person(Name, Age)

We have:

for Person {
  fn is_major self -> bool = .age >= 18 // self is implied here by the use of `.`
}

Analogous for other structures like types and structs.

[SplittyDev]

The use of . for self could be problematic if it's also used for accessing unnamed parameters.

I guess it could be used for both since "." <digit>+ is easy to tell apart from "." <ident> though, so not sure how valid this concern is.

The use of for for implementations could clash with a for keyword.

Are there are plans for a for keyword or would that just be a function like for_each?

[chronium]

What about using def?

rec Person(Name, Age)

def Person {
  fn is_major self -> bool = .age >= 18 // self is implied here by the use of `.`
}

Thinking about it in terms of defining its characteristics.

About the . dot syntax, we could think about it as a shorthand for accessing the first parameter.
Which can be a self, or an unnamed tuple, so on and so fort.

[SplittyDev]

Why decouple the prototype and implementation?

rec Person(name, age) {
  fn is_major self -> bool = .age >= 18
}

val person = Person("John", 32)

👍 for the dot syntax.

[chronium]

Borrowing the idea from Rust, you can have multiple implementations for the same prototype split across multiple files. Alongside that, I have an idea in mind for traits/contracts implementation when time comes for it, and it will go hand in hand with decoupling.

[chronium]

As a side note, Scala's object-class difference is interesting.
For example, in Scala, if you define an object as contrary to a class, you are defining the static implementation for it, useful for singletons.
If you define a class, it's the normal instanced class.
With that, for the same object, you can define both its class and object. One would contain the static implementation, the other the instance implementation.
Maybe an object modifier would be something interesting for that.

rec Person (val name: Name, var age: Age) {
  fn isMajor self -> bool = .age >= 18
}

object rec Person (val name: Name) {
  fn WithAge age: Age -> Self = Person(name, age)
}

// usage

val person: Person = Person ("Jim") WithAge (24)
puts (isMajor person)

Syntax idea came from this. Point-free syntax, where the instance function and the object place are reversed.

---

Given the previous record implementation, another object example could be, for a factory pattern, after we have currying.

object rec Person {
  fn WithName Name -> Self = Person _
  fn WithAge Age -> Self = Person ,_ // free form notation for first parameter applied
}

// usage

val person: Person = Person WithName "Jack" WithAge "32"

[SplittyDev]

Borrowing the idea from Rust, you can have multiple implementations for the same prototype split across multiple files. [...]

So why would you wanna go with def or for instead of Rust's impl?

impl describes very well what it's doing and hasn't been used for wildly different things afaik.

def has baggage from Python and would make it hard for people coming from there to get used to it.
for seems more okay, but I'm pretty sure for is gonna be a keyword for control flow.

Also, couldn't for be used as soon as traits are a thing in Rust's sense of impl Foo for Bar?

I can't say much to the object classes. I don't see how they would be useful, at first glance they just seem to complicate things without providing a real benefit. But to be fair, I'm probably suffering from the Blub paradox here since I have never used a language that has them and can't really imagine a use case in which I would use them over another concept I already know, so for the time being I'd rather not push this particular feature into any specific direction myself.

[chronium]

About using impl, not too bad of an idea. And the difference between class and object can be used for special traits/contracts that are specific for static vs instanced.

[chronium]

On a related note, each could also be used as a keyword for control flow.
As the classic for has the old C idea in mind, and still stuck with the name.

each i in range (0, 10)
each name in iter names // using point-free notation here. equivalent would be names.iter()
each (index, value) in enumerate names

Those would be some examples. I think it better describes the modern iterator-like usage of for loops.

[chronium]

Delaying this to Alpha v0.2