Curry breaks in testing with new .assuming engine: #1

lizmat commented 2026年05月20日 18:08:05 +02:00

The Curry issue is looking like it is an issue with Curry. The equivalent code from the test without the curry trait looks like:

sub a($a,$b,:$c = 1) {
dd $a, $b, $c
}
my &b := &a.assuming(42);
dd &b.signature; # :($b, :$c = 1)
my &c := &b.assuming(666);
dd &c.signature; # :(:$c = 1)
my &d = &c.assuming(:137c);
dd &d.signature; # :(:$c = 137)
However, the equivalent signatures using the curry trait offered by Curry show:

:($b, :$c = 1)
:(:$c = 1)
:()
In other words, Curry removes the optional named argument from the signature, causing the test failure.

The Curry issue is looking like it is an issue with Curry. The equivalent code from the test without the curry trait looks like: sub a($a,$b,:$c = 1) { dd $a, $b, $c } my &b := &a.assuming(42); dd &b.signature; # :($b, :$c = 1) my &c := &b.assuming(666); dd &c.signature; # :(:$c = 1) my &d = &c.assuming(:137c); dd &d.signature; # :(:$c = 137) However, the equivalent signatures using the curry trait offered by Curry show: :($b, :$c = 1) :(:$c = 1) :() In other words, Curry removes the optional named argument from the signature, causing the test failure.

CIAvash commented 2026年06月09日 10:12:31 +02:00

That was by design, Curry applies the named argument and removes it from signature. This was one of the cases mentioned in the assuming design issue.

Named arguments make things complicated since currying and partial application are defined by fixed arguments and function's arity. But I should probably go with assuming's approach, since named arguments can be overridden.

I think mixing currying and partial application was not a good idea and made things confusing, what curry trait is doing is really partial application. I'm thinking of introducing a partial trait. curry should only create new functions which take only 1 argument and partial should apply arguments.

I need to think about it a bit more.

That was by design, Curry applies the named argument and removes it from signature. This was one of the cases mentioned in the [assuming design issue](https://github.com/Raku/problem-solving/issues/301). Named arguments make things complicated since currying and partial application are defined by fixed arguments and function's arity. But I should probably go with `assuming`'s approach, since named arguments can be overridden. I think mixing currying and partial application was not a good idea and made things confusing, what `curry` trait is doing is really partial application. I'm thinking of introducing a `partial` trait. `curry` should only create new functions which take only 1 argument and `partial` should apply arguments. I need to think about it a bit more.

CIAvash commented 2026年06月09日 13:02:54 +02:00

But I should probably go with assuming's approach, since named arguments can be overridden.

Or maybe I shouldn't! Because assuming does partial application differently, it always returns a function, even when there are no more arguments to pass, which makes sense for assuming but partial application calls the function if all fixed arguments are passed.

> But I should probably go with assuming's approach, since named arguments can be overridden. Or maybe I shouldn't! Because `assuming` does partial application differently, it always returns a function, even when there are no more arguments to pass, which makes sense for `assuming` but partial application calls the function if all fixed arguments are passed.

CIAvash commented 2026年06月09日 13:45:42 +02:00

Apparently this is a known conflict.

Raku deals with it by separating function creation(via assuming) and function calling.

Some languages call the function as soon as all positional arguments are passed; they do not wait for arguments that have default values and use those default values.

In OCaml, if there are optional and named arguments, it requires an empty tuple in order for it to execute the function.

The way Curry does it is a mixture of these. I cannot decide which approach I should take right now, call the function as soon as possible or require manual execution?

Apparently this is a known conflict. Raku deals with it by separating function creation(via `assuming`) and function calling. Some languages call the function as soon as all positional arguments are passed; they do not wait for arguments that have default values and use those default values. In OCaml, if there are optional and named arguments, it requires an empty tuple in order for it to execute the function. The way Curry does it is a mixture of these. I cannot decide which approach I should take right now, call the function as soon as possible or require manual execution?

lizmat commented 2026年06月09日 18:14:41 +02:00

I cannot decide which approach I should take right now, call the function as soon as possible or require manual execution?

Well, that's a good question.

It all depends on what you're trying to do. Are you trying to mimic the behaviour .assuming with different syntax? Or are you trying to mimic behaviour of other programming languages, and .assuming is just a tool to achieve that goal?

> I cannot decide which approach I should take right now, call the function as soon as possible or require manual execution? Well, that's a good question. It all depends on what you're trying to do. Are you trying to mimic the behaviour `.assuming` with different syntax? Or are you trying to mimic behaviour of other programming languages, and `.assuming` is just a tool to achieve that goal?

CIAvash commented 2026年06月10日 08:28:48 +02:00

When I created the module, I wanted a partial application similar to what functional programming languages have, but now I think .assuming's way can have its own uses.

Which makes me think why not have both? There can be 2 traits, partial trait does application similar to other programming languages and a primed trait which will be another way of using .assuming. This way one can choose one depending on the situation or by preference.

When I created the module, I wanted a partial application similar to what functional programming languages have, but now I think `.assuming`'s way can have its own uses. Which makes me think why not have both? There can be 2 traits, `partial` trait does application similar to other programming languages and a `primed` trait which will be another way of using `.assuming`. This way one can choose one depending on the situation or by preference.

lizmat commented 2026年06月13日 12:05:20 +02:00

Sure, go for it!

Sure, go for it!