improved function partial application design

[nsajko]

This replaces Fix (xref #54653) with fix. The usage is similar: use fix(i)(f, x) instead of Fix{i}(f, x).

Benefits:

• Improved type safety: creating an invalid type such as Fix{:some_symbol} or Fix{-7} is not possible.
• The design should be friendlier to future extensions. E.g., suppose that publicly-facing functionality for fixing a keyword (instead of positional) argument was desired, it could be achieved by adding a new method to fix taking a Symbol, instead of adding new public names.

Lots of changes are shared with PR #56425, if one of them gets merged the other will be greatly simplified.

[adienes]

look, I'm not trying to be the bad guy on all your PRs. but I feel like you are misrepresenting the status quo

Improved type safety: creating an invalid type such as Fix{:some_symbol} or Fix{-7} is not possible.

this is already not possible with Fix. the constructor will throw an error as implemented in this block

        if !(N isa Int)
            throw(ArgumentError(LazyString("expected type parameter in `Fix` to be `Int`, but got `", N, "::", typeof(N), "`")))
        elseif N < 1
            throw(ArgumentError(LazyString("expected `N` in `Fix{N}` to be integer greater than 0, but got ", N)))
        end

[nsajko]

I'm not misrepresenting anything, this is the (embarrassing) behavior on master:

julia> Base.Fix{-1}
Base.Fix{-1}

[adienes]

try constructing it?

[nsajko]

Could you please take your off-topic chatting to Discourse or wherever?

[adienes]

it was a direct and objective refute to one of the primary motivations you provided in the commit message. it feels pretty on topic to me.

that being said, you clearly don't want my input, so I'll stop providing it (as, I suspect, will everyone else)

[KristofferC]

Why does every PR now try to push in this "typed domain numbers" package into Base..?

As has been said regarding

Improved type safety: creating an invalid type such as Fix{:some_symbol} or Fix{-7} is not possible.

julia> Base.Fix{1}(*, "1")
(::Base.Fix1{typeof(*), String}) (generic function with 2 methods)

julia> Base.Fix{-1}(*, "1")
ERROR: ArgumentError: expected `N` in `Fix{N}` to be integer greater than 0, but got -1
Stacktrace:
 [1] (Base.Fix{-1})(f::typeof(*), x::String)
   @ Base ./operators.jl:1181
 [2] top-level scope
   @ REPL[10]:1

julia> Base.Fix{:some_symbol}(*, "1")
ERROR: ArgumentError: expected type parameter in `Fix` to be `Int`, but got `some_symbol::Symbol`
Stacktrace:
 [1] (Base.Fix{:some_symbol})(f::typeof(*), x::String)
   @ Base ./operators.jl:1179
 [2] top-level scope
   @ REPL[11]:1

so it is unclear what is being improved here.

I don't really understand what the other benefit means.

[martinholters]

From what I can tell, this PR comprises three changes that are related, but could be considered independently:

1. Introduce a function fix that creates the required type to wrap the function and fixed argument.
2. Rename that type from Fix to PartiallyAppliedFunction.
3. Change the N type parameter from an integer to a type-domain integer.

I agree that 1. might make future extensions to e.g. fixing keyword arguments more seamless, but could just be introduced when the time is ripe. If we expect the type to change in the future, this function might give the needed indirection to make that less breaking, but that is quite speculative.
I like 2., but it's clearly a matter of taste, and I'm not sure it's worth the trouble renaming now.
I see no benefit in 3.

[nsajko]

The benefit of 3. is type safety, as mentioned in the OP. I'm confused by the apparently wide disregard for correctness.

[DilumAluthge]

If I understand correctly, currently Julia does check for correctness (as shown above), but currently that check is done at runtime, and the idea of this PR (specifically, change 3) is to move that check from runtime to compile-time?

What are the advantages and disadvantages of doing this check at compile-time vs runtime?

[nsajko]

The benefit is type safety for the first type parameter (fixed argument position) of the Fix/PartiallyAppliedFunction type, i.e., an invalid type application would throw. So the existence of an invalid UnionAll value/constructor, such as Fix{-7} with the code currently on the Git master branch, would be impossible. Practically this means bugs getting caught sooner.

The drawback is more code in Base.

IMO the unnecessary lack of type safety in the current version of Fix could be embarrassing if released, leading newcomers to incorrectly conclude that Julia isn't able to provide the type safety there. Given the bad reputation regarding "correctness" that Julia seems to have among users of other programming languages, I'd expect more sensitivity for such issues.

PS: I labeled with do-not-merge because this PR currently fails show-related tests. Not sure if I should bother with looking into it given the strongly negative reactions to the PR.

[nsajko]

Also, to respond to @adienes and @KristofferC directly, clearly error checks in a constructor are irrelevant for type safety, which is why I called the discussion off-topic.

[martinholters]

So the existence of an invalid UnionAll value/constructor, such as Fix{-7} with the code currently on the Git master branch, would be impossible.

Hm, but PartiallyAppliedFunction{PositiveInteger, typeof(<), Int} would be possible AFAICT and is similarly invalid. (Well, instead of specifying an invalid argument number it leaves the argument number unspecified, so it's another kind of invalidity, but still.)

We also have

julia> Array{Float64,-7}
Array{Float64, -7}

and I don't think that has caused much grief, has it? Maybe even worse, we also allow Array{-7, Float64}. Has that caused any real harm?

[KristofferC]

@nsajko, what do you mean when you say "type safety" w.r.t Julia? How will a user be happier?