Allow empty lists as arguments to binary methods

[d-torrance]

Currently, binary methods (like gcd) accept inputs using sequences or lists:

i1 : gcd(6, 9, 15)

o1 = 3

i2 : gcd {6, 9, 15}

o2 = 3

However, if a 0-argument method is installed, only sequences work:

i3 : gcd()

o3 = 0

i4 : gcd {}
stdio:4:1:(3): error: expected 0 arguments but got 1

This is because it passes along the argument of {} (a single argument -- a list) to a function expecting 0 arguments. By swapping this argument out with (), it works:

i1 : gcd {}

o1 = 0

We also add a couple related changes:

• A 0-argument method for lcm:

  i2 : lcm {}
  
  o2 = 1

• Previously, "no method" errors when the input is empty seem to imply that we were calling the corresponding method for Sequence objects:

  i1 : intersect()
  stdio:1:1:(3): error: no method found for applying intersect to:
     argument   :  () (of class Sequence)

  But intersect(Sequence) does exist! And it's not what we were calling. So now, we get:

  i1 : intersect()
  stdio:1:1:(3): error: no method found for applying intersect to:
     argument   :  ()

[d-torrance]

I also added a 0-argument method for union (returning the empty set).

There are two other binary methods in Core that don't currently have 0-argument support: intersect and tensor. Both of these would only make sense with a ring. We could assume ZZ, I suppose? That would match things like ideal {} and matrix {}.

[mikestillman]

I would prefer not to have the ring default to ZZ for tensor and intersect. We have that in other cases (e.g. ideal()), and it causes hard to find bugs...

Better might be to have versions of these take a ring argument too...?

[d-torrance]

@DanGrayson -- I'm not sure if this still needs an "under discussion" tag. @mikestillman answered my question of whether intersect() and tensor() should assume we're working over ZZ with "no", so I wasn't planning on adding any additional 0-argument binary methods in this PR.

[mahrud]

Better might be to have versions of these take a ring argument too...?

At least with intersect and tensor, I'm not sure if this makes a lot of sense. But maybe I'm not seeing it now and once I actually need to use something like matrix(R, {...}) I'll come to appreciate it?

I would prefer not to have the ring default to ZZ for tensor and intersect. We have that in other cases (e.g. ideal()), and it causes hard to find bugs...

I think returning a ZZ-module makes mathematical sense, since ZZ is the initial object in the category of rings. A Macaulay2 error I've run into frequently is this:

i2 : ideal 0_R == ideal {}
stdio:2:11:(3): error: expected ideals for the same ring

And I'd really like this to "just work", especially because:

i5 : ideal {} == 0 and ideal 0_R == 0

o5 = true

Do you remember what errors/bugs you've seen?