General type errors regarding `Arguments and Values`

[jcguu95]

I reviewed the issue draft hash-table-count-type-error and realized it exemplifies a broader problem.

According to the spec, if the types of objects differ from those specified in the Arguments and Values section, the consequences are undefined. However, it would be more practical to signal an error whenever a type violation occurs. Therefore, I propose that we address this general issue instead of focusing solely on hash-table-count.

[Bike]

Coalescing the issues might be a good idea. There are some general considerations... for example I'd want at least to only require an error in safe code to retain some implementation flexibility. And I think it's worth considering exactly what error behavior would be good. Replacing undefined behavior with an error sounds good, but it also constrains implementations to have to signal an error at the time of the function call. That would make nearly every function in the standard non-movable, non-flushable, etc in general by optimizers unless types can be proven. It's at least worth thinking about.

There are some specific issues. In some cases the types given in Arguments and Values sections are not testable upfront, and you can get useful errors that are not type errors. Off the top of my head, mapcar's function argument is said to be "a _designator for a function that must take as many arguments_ as there are lists". There is no standard way to determine how many arguments a function accepts. In practice, currently, this situation will probably result in a program-error when the function is called, instead of a type-error when mapcar is called. Making this a type error is possible, but would take nontrivial work by implementations.

fdefinition is another case where the "types" given are not exactly types, in a potentially non-useful way. It expects "a _function name_. In the non-setf case, the _name must be fbound in the global environment_.", so if the type is taken literally it means that (fdefinition 'undefined-name) should signal a type error rather than an undefined-function as provided for under Exceptional Situations.

Some functions want arguments of types that do not exist in a formal way. Functions that take environments, such as make-load-form-saving-slots, specify as much, but there is no standard environment type. On some implementations environments may not even be a distinct type (I ran into this once on ECL, where it turned out lexical environments were alists).

format has another tricky type - "_format arguments_ for control-string".

There are probably more to worry about elsewhere.

[Bike]

Also, I forgot we have this relevant PR that gives "a list of functions that do not refer to type-error and document no exceptional condition".

[yitzchak]

It is possible to have multiple proposals in one issue. In this case each proposal needs a relevant test cases section, etc. I would think that the proposals should each be specific enough that a short test cases section can be reasonably made and understood. In other words, probably specific to a single dictionary entry or to multiple uses of a term located in multiple places. In terms of "meta" issues, the suggestions submitted so far are certainly valid, but kind of vacuous in details.

Basically, I think a meta-issue that collects multiple TYPE-ERROR issues is still going to have the same number of proposal sections as we would have had if we had separate issues. I think the "meta-issue" idea is good from an organization issue, but it might not be a good idea in that the issue will become rather long.

Maybe in the short term we should have separate issues until we actually have some procedure discussions. We can always take draft issues and merge them into a meta-issue when they enter the "proposed" state.

[robert-strandh]

I think it is better to start with to have separate issues for each operator. The objective here is to get each implementation to accept the a proposal that is such that the implementation is already conforming. It is much easier to do that one operator at a time.

[jcguu95]

Makes sense to me. We can start with doing them separately. Thanks @Bike for pointing out some gotchas.