Proposal: OOP-like function call

[iMashtak]

Seems like i really like that project and able to generate something (i hope) useful.

I tried to follow intuition of "if i type dot, then i should see all available methods for this variable". I found that it is possible to create something like that in existing syntax but it looks too verbose.

Example with Rust highlight for easier understanding:

// Main type, for which i want so-called "methods". For now it just holds internal structure
type Seq<a> = recursive either {
    .end!,
    .item(a) self,
}

// Extension that provides neccessary methods, `concat` for example
// Type is definition
type SeqMethods<a> = [Seq<a>] choice {
    .concat(Seq<a>) => Seq<a>,
}

// Def is implementation
dec SeqMethods : [type a] SeqMethods<a>
def SeqMethods = [type a] [this] case {
    .concat(seq) => do {
        let builder = StaticSeq(type a).builder
        this.begin.case {
            .end! => {},
            .item(x) xs => {
                builder.add(x)
                xs.loop
            }
        }
        seq.begin.case {
            .end! => {},
            .item(x) xs => {
                builder.add(x)
                xs.loop
            }
        }
    } in builder.build
}

// Supportive type for Seq
type SeqBuilder<a> = iterative choice {
    .add(a) => self,
    .build => Seq<a>
}

// So-called "static methods" for Seq
type StaticSeq<a> = choice {
    .new => Seq<a>,
    .builder => SeqBuilder<a>
}

// Impl of static methods
dec StaticSeq : [type a] StaticSeq<a>
def StaticSeq = [type a] case {
    .new => .end!,
    .builder => 
        let append: [Seq<a>] Seq<a> = [xs] xs
        in begin case {
            .add(x) =>
                let append: [Seq<a>] Seq<a> = [xs] append(.item(x) xs)
                in loop,
            .build => append(.end!),
        }
}

// Main function for tests
def Main: ! = do {
    // Using StaticSeq wrapper
    let seq = StaticSeq(type String).builder.add("x").add("y").build
    let seq2 = StaticSeq(type String).builder.add("a").add("b").build

    // Using SeqMethods wrapper
    let seq3 = SeqMethods(type String)(seq).concat(seq2)

    let console = Console.Open
    seq4.begin.case {
        .end! => {},
        .item(x) xs => {
            console.print(x)
            xs.loop
        }
    }
    console.close
} in !

So, i would want to have an ability to declare "extension methods" and "static methods" for given type with some sort of syntax. Maybe static/dynamic impls. For now i imagine the following syntax:

// Types
type Seq<a> = recursive either {
    .end!,
    .item(a) self,
}

type SeqBuilder<a> = iterative choice {
    .add(a) => self,
    .build => Seq<a>
}

// Shorthand of SeqMethods from previous example
impl Seq<a> as Dyn = [this] {
    .concat(seq: Seq<a>): Seq<a> => do {
        let builder = StaticSeq(type a).builder
        this.begin.case {
            .end! => {},
            .item(x) xs => {
                builder.add(x)
                xs.loop
            }
        }
        seq.begin.case {
            .end! => {},
            .item(x) xs => {
                builder.add(x)
                xs.loop
            }
        }
    } in builder.build
}

// Shorthand of StaticSeq from previous example
impl Seq<a> as Static = {
    .new => .end!,
    .builder => 
        let append: [Seq<a>] Seq<a> = [xs] xs
        in begin case {
            .add(x) =>
                let append: [Seq<a>] Seq<a> = [xs] append(.item(x) xs)
                in loop,
            .build => append(.end!),
        }
}

def Main: ! = do {
    // Somehow add Static in execution context
    let seq = Seq(type String).builder.add("x").add("y").build
    let seq2 = Seq(type String).builder.add("x").add("y").build

    // Somehow add Dyn in execution context
    let seq3 = seq.concat(seq2)
} in !

If Par had macro system, it would be solved solely by that. But it also may be a part of language.

Dont think my new syntax is 100% good, i feel it lacks something. Anyway, it will make code easier to write.

[faiface]

Hey, thanks for the suggestion! Once again consider joining the Discord, as it currently is the most active place for discussing these ideas, and more people can chime in.

Regarding this proposal, I think we have two features in the plans that remedy the same problems.

The first is a "pipe operator". In F# or Elm or other functional languages, there is this operator x |> f where the function f is applied to x.

In Par, a similar operator would be used, but probably we'd use an arrow. So

value -> Function

would be the same as

Function(value)

Precedence would work like this

value
  -> Function1(arg1, arg2)
  -> Function2(arg3)

would be the same as this

Function2(Function1(value, arg1, arg2), arg3)

Now, that's for expression syntax, but this becomes especially interesting, if we naturally extend it to process syntax.

In process syntax, this

variable->Function

Would be the same as

let variable = Function(variable)

So you see it acts very much like an extension method! Both in expression syntax and process syntax.

The second feature helping here would be some kind of inference of generic types. Currently, you have to always explicitly write Function(type T)... and while it's nice that it's explicit, it can get very verbose.

My current idea for remedying this would be to extend [...]... and (...)... and with inferred generic types that have to be inferred from the type in the parentheses/brackets.

For example:

dec List.Length : <a>[List<box a>] Nat

instead of

dec List.Length : [type a] [List<box a>] Nat

Here you can see that a can be inferred with a full knowledge of the type in square brackets.

This is my current thinking there. Neither of these is implemented so far, but I hope it won't take too long.

To me it sounds like these two together solve the problem you're trying to solve as well. What do you think?

[iMashtak]

Thanks for reply!
Sorry - for now i cant access Discord cause it is blocked in Russia by government :( Maybe i will somehow solve this problem, maybe not, but it is what it is.

As for Par, -> feels like C++ style, but seems reasonable for me. Much more than |>. If precedence will work like you say, it would be very nice. But i dont know about LSP performace of "context suggestions" - when you will write ->, LSP will need to scan all declarations in current scope and typecheck its first argument. Feels really heavy.

For second thing you said i dont understand what is changed between that

dec List.Length : <a> [List<box a>] Nat

and that

dec List.Length : [type a] [List<box a>] Nat

You can still have second syntax but type argument can be implicitly inferred.