Skip to content

fn:identity: make it variadic #1473

Description

@ChristianGruen

Activity

  1. added
    XQFOAn issue related to Functions and Operators
    FeatureA change that introduces a new feature
    on Oct 1, 2024
  2. michaelhkay commented on Oct 1, 2024

    @michaelhkay
    Contributor

    I'm not convinced. What should fn:identity((1,2), (3,4)) return, and why? Whatever it returns, the result doesn't seem to be "identical" to the input.

    fn:void is another matter. Since that ignores all its arguments, it might as well ignore a variable number of them.

  3. ChristianGruen commented on Oct 1, 2024

    @ChristianGruen
    ContributorAuthor

    I'm not convinced. What should fn:identity((1,2), (3,4)) return, and why? Whatever it returns, the result doesn't seem to be "identical" to the input.

    A variadic fn:identity can be seen as a generalized variant of Haskell’s const function, which takes two arguments and returns only the first one. fn:identity would do the same: Only the first argument is evaluted, the remaining ones are ignored.

    #858 (comment) included an example for this. Here is a simplified version: $insert-with is called with an function argument that decides how to update the value of a map entry. If we had identity#2, we could pass it instead of fn($a, $b) { $a }:

    let $insert-with := fn($map, $key, $value, $update-func) {
      let $old-value := $map($key)
      let $new-value := if($old-value) then $update-func($value, $old-value) else $value
      return map:put($map, $key, $new-value)
    }
    let $map := { 'foo': 1 }
    let $summarize := fn($a, $b) { $a + $b }
    let $replace := fn($a, $b) { $a }
    return (
      $insert-with($map, 'foo', 2, $summarize)('foo'),
      $insert-with($map, 'foo', 42, $replace)('foo')
    )
  4. MarkNicholls commented on Oct 2, 2024

    @MarkNicholls

    I'd find this very confusing, identity for me, by definition, is not variadic.

  5. michaelhkay commented on Oct 2, 2024

    @michaelhkay
    Contributor

    In the use case given, doesn't fn:identity#1 serve equally well?

  6. ChristianGruen commented on Oct 2, 2024

    @ChristianGruen
    ContributorAuthor

    In the use case given, doesn't fn:identity#1 serve equally well?

    I would assume that identity#1($value, $old-value) raises an error, but I may be wrong?

  7. michaelhkay commented on Oct 2, 2024

    @michaelhkay
    Contributor

    The function coercion rules say If F has lower arity than T, then F is wrapped in a new function that declares and ignores the additional argument, so supplying identity#1 is equivalent to supplying fn($x, $y){identity#1($x)}.

  8. ChristianGruen commented on Oct 2, 2024

    @ChristianGruen
    ContributorAuthor

    The function coercion rules say If F has lower arity than T, then F is wrapped in a new function that declares and ignores the additional argument, so supplying identity#1 is equivalent to supplying fn($x, $y){identity#1($x)}.

    So I got it right. fn($a, $b) { $a } is probably still easier to read than fn($x, $y){identity#1($x)}. If fn:identity was variadic, though, we could replace fn($a, $b) { $a } with fn:identity#2.

  9. ChristianGruen commented on Oct 8, 2024

    @ChristianGruen
    ContributorAuthor

    While I could see some use for a variadic fn:identity, it will be hard to teach how it works (the mere existence of fn:identity is already a miracle to almost everyone). Maybe it’s better to drop too esoteric endeavors.

  10. ndw commented on Oct 15, 2024

    @ndw
    Contributor

    The CG agreed to close this issue without further action at meeting 094.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    FeatureA change that introduces a new featurePropose Closing with no ActionThe issue should be closed with no further discussion and no action (unless anyone objects)XQFOAn issue related to Functions and Operators

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions