`min`/`max` should not accept 0 arguments

[samth]

Welcome to Racket v6.8.0.1.
> min
- : (-> Real * Real) ... [Use (:print-type <expr>) to see more.]
#<procedure:min>
> max
- : (-> Real * Real) ...
#<procedure:max>
> (max)
; max: arity mismatch;
;  the expected number of arguments does not match the given number
;   expected: at least 1
;   given: 0
; [,bt for context]

Reported by John Reppy.

[endobson]

http://bugs.racket-lang.org/query/?cmd=view&pr=13635 has previous discussion on this issue.

[k4rtik]

http://bugs.racket-lang.org/query/?cmd=view&pr=13635 has previous discussion on this issue.

Is this discussion archived somewhere publicly?

[maueroats]

Warning: this change is probably controversial / a non-starter since it will result in previously working TR code no longer typechecking. I can't see the discussion either, but I assume the issue is as described below.

Issue: If you make the type of max require at least one element, then the function max cannot be blindly applied to a (Listof Integer) in another function.

This code does not type check if max is required in its type signature to have at least one argument:

(define (one-more-than-max [xs : (Listof Integer)])
    : Integer
    (add1 (apply max xs)))

While not exactly common, the idiom of applying max to a list does happen a reasonable amount in the Racket code base. Examples: a bunch in plot-lib, some in math-lib (array/typed-array-transform, matrix/matrix-operator-norm, statistics/statistics-utils).

I'm not sure this should actually be tagged with "good-first-issue" given that it is a not-backward-compatible change, causing errors in a bunch of previously-working code.

[samth]

The previously-referenced discussion is here: https://github.com/racket/gnats-bugs/blob/master/typed-scheme/13635

[maueroats]

I wrote up the issues that came up implementing this (naively propagating nonemptiness of lists through the type system), and made the changes needed to make the base packages compile in Racket 7.7. See my types for nonempty lists gist for a writeup.

[samth]

Thanks, that's an extensive investigation. I think the conclusion is clear -- we aren't going to change this in TR. I think adding (Nonempty-List T) is a good idea, though.

[jackfirth]

If Nonempty-List is added to TR, could we also add nonempty-list? to racket/list? If nonempty lists are relied on enough to warrant a type, then they also warrant a predicate for use in untyped contracts.

[mfelleisen]

Isn't that cons? (or pair? for old people)?

[rfindler]

Maybe (and/c list? pair?) or (non-empty-listof any/c)?

(Those are both predicates, too)

[jackfirth]

I think having a dedicated nonempty-list? predicate is more usable than (and/c list? pair?) in the same way that (Nonempty-List E) is more usable than (Pairof E (Listof E)).