Specific List functions can accept 0 elements

[OAGr]

Number.sum, product, sort, cumsum, cumprod, should all accept lists with 0 elements

This closes #2349

[changeset-bot]

🦋 Changeset detected

Latest commit: 85d81c8

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@quri/squiggle-lang	Patch
@quri/squiggle-components	Patch
@quri/prettier-plugin-squiggle	Patch
vscode-squiggle	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
quri-hub	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 25, 2023 7:11pm
quri-ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 25, 2023 7:11pm
squiggle-components	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 25, 2023 7:11pm
squiggle-website	✅ Ready (Inspect)	Visit Preview		Oct 25, 2023 7:11pm

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (20b52b9) 71.65% compared to head (88ae8af) 71.66%.
Report is 2 commits behind head on main.

❗ Current head 88ae8af differs from pull request most recent head 85d81c8. Consider uploading reports for the commit 85d81c8 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2351   +/-   ##
=======================================
  Coverage   71.65%   71.66%           
=======================================
  Files         111      111           
  Lines        5704     5706    +2     
  Branches     1091     1093    +2     
=======================================
+ Hits         4087     4089    +2     
  Misses       1610     1610           
  Partials        7        7           

see 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[berekuk]

For sum and product, there's a slight risk that in the future we'll have to deal with ambiguity because of polymorphism: we could decide to add sum(string[]) or sum(dist[]), and then the result of sum([]) becomes unclear.

This could be bad if the array is generated dynamically, and especially because of interactions with the type inference and compile-time polymorphic dispatch.

Consider this code:

sumArrays(arrs) = arrs -> map({|arr| sum(arr)})

sumArrays([
  ["foo", "bar"],
  []  // imagine that this was obtained by calling another function that does `filter` at runtime
])

Now, if sum is polymorphic, but we also have sum([]) defined to be 0, then the result of sumArrays will be either ["foobar", 0] or ["foobar", ""].

["foobar", ""] result could happen in this case if the interpreter would detect that sumArrays accepts an array of arrays of strings, and so every sum call is over an array of strings.

So it's going to be a minor breaking change, when/if we get there.