Shorthand for match assignment functions

[MatthiasJ1]

A common paradigm in functional programming is a function whose implementation is determined by matching the input. This is supported in coconut by either addpattern functions or traditional match statements.

addpattern can be unnecessarily verbose, especially if you like descriptive function names. This also makes refactoring more annoying as now you have to rename the function multiple times.

match def neg_one_if_zero(x if x == 0)=-1
addpattern def neg_one_if_zero(x)=x

Traditional match statements do not work for assignment functions (#832):

def f(x)=
    match x:
        case 0: -1
        case _: x
                ^ │Coconut exiting with error: CoconutParseError

Even if this worked, it would be overly verbose compared to the rest of Coconut which has very streamlined, terse syntax.

I propose a syntax similar to Haskell or StandardML

def f(x)
    | 0 =
        # some code
        -1
    | _ = x

[evhub]

To keep things consistent for refactoring purposes, you can actually just use addpattern even for the initial declaration. From the docs:

Additionally, addpattern def will act just like a normal match def if the function has not previously been defined, allowing for addpattern def to be used for each case rather than requiring match def for the first case and addpattern def for future cases.

Regardless, I could potentially be sold on #190, but I'm not excited about adding syntax like what you're describing; it's redundant with what already exists and doesn't seem very Pythonic to me.

[MatthiasJ1]

doesn't seem very Pythonic to me

The whole point of this library, as seems to me, is to add a bunch of great, non-pythonic features to python from languages such as the ones you specify in the docs:

other languages that inspired Coconut include Haskell, CoffeeScript, F#, and Julia.

All of which (Coffeescript with extensions) have a syntax very similar to the one I propose here.

it's redundant with what already exists

If this is considered redundant then how would it differ from say replacing the lambda syntax with () => <expr>. By that logic you could argue most of Coconut is redundant...? It adds syntactic sugar allowing more expressive functional programming, while also aligning the coding style with other functional programming languages. This is the same principle as your lambda syntax.

It's your language and I totally respect your freedom to veto features purely based on your opinion, but you did offer some rebuttals here which I argue contradict the rest of the direction of this project.

[evhub]

Hmmm... I'll keep the issue open in case anyone comes up with a syntax here that I like but currently I just don't really see the benefit of

def f(x)
    | 0 =
        # some code
        -1
    | _ = x

over

addpattern def f(0) =
    # some code
    -1
addpattern def f(x) = x

and in fact I think I mildly prefer the latter syntax; having the pattern explicitly in the function signature seems more clean to me.

[MatthiasJ1]

Here is an example using the current syntax:

data Expr(value)
data Body(exprs)
data Constant(value)
data BinOp(a, op, b)
data Add()
data Sub()
AST = Expr | Body | Constant | BinOp | Add | Sub

addpattern def dump_ast(Expr(value)) = dump_ast(value)
addpattern def dump_ast(Body(exprs)) = exprs |> map$dump_ast |> "\n".join
addpattern def dump_ast(Constant(value)) = str(value)
addpattern def dump_ast(BinOp(a, op, b)) = (a,op,b) |> map$dump_ast |> " ".join
addpattern def dump_ast(Add()) = "+"
addpattern def dump_ast(Sub()) = "-"

ast = Body([
    Expr(BinOp(Constant(2), Sub(), Constant(1))),
    Expr(BinOp(Constant(2), Add(), Constant(3))),
])

print(dump_ast(ast))

In the above example, there are a few issues:

1. 45% of the code representing dump_ast is addpattern def dump_ast repeated. That is a high ratio of boilerplate to logic.
2. AFAIK there is no good way to type annotate the dump_ast argument as AST
3. If you were to annotate the return type as str, do you add the -> str annotation to the first definition? The last? All of them? If you annotate only one of them you now need to mentally keep track of that if you ever refactor. If you have a lot of addpatterns, you may also not see the one that has the type annotation.

The suggested syntax would resolve all of these issues:

def dump_ast(node: AST) -> str
    | Expr(value) = dump_ast(value)
    | Body(exprs) = exprs |> map$dump_ast |> "\n".join
    | Constant(value) = str(value)
    | BinOp(a, op, b) = (a,op,b) |> map$dump_ast |> " ".join
    | Add() = "+"
    | Sub() = "-"

[evhub]

The repetition point is well-taken. I'll put this on the next milestone to consider what the best thing might be to do here.

[evhub]

Here's a first-pass proposal

case def func: <typedef>
    match (<pattern>):
        <body>

which would make your function

case def dump_ast: AST -> str
    match(Expr(value)) = dump_ast(value)
    match(Body(exprs)) = exprs |> map$dump_ast |> "\n".join
    match(Constant(value)) = str(value)
    match(BinOp(a, op, b)) = (a,op,b) |> map$dump_ast |> " ".join
    match(Add()) = "+"
    match(Sub()) = "-"

or another example

case def factorial[Num <: int | float]: (Num, Num) -> Num
    """Factorial function"""
    match(0, acc=1):
        return acc
    match(int(n), acc=1) if n > 0:
        return factorial(n - 1, acc * n)

[evhub]

Okay, the above syntax is working now as of coconut-develop>=3.1.0-post_dev4 (pip uninstall coconut && pip install -U coconut-develop>=3.1.0-post_dev4), though it still needs documentation and a bit more testing before I call it done.