Skip to content

2015 009 Policy for exceptions and partial applications

John Reppy edited this page Aug 22, 2015 · 1 revision

Proposal 2015-009

Policy for exceptions and partial applications

Author: John Reppy
Last revised: August 22, 2015
Status: proposed
Discussion: issue #11 (also issue #10)


Synopsis

Some curried functions in the Basis Library will raise an exception when their first argument is invalid. The Basis Library specification is not consistent in specifying if the exception should be raised at the time of the partial application to the invalid argument or at the time of the application to the last argument. In the case of Real.fmt), the specification states that the exception should be raised on the partial application to the invalid argument. In the case of Time.fmt, the behavior in unspecified.

The purpose of this proposal is to define a uniform behavior for this situation, both for the existing Basis Library and for future proposals. Specifically,

if a curried function raises an exception because of an invalid input, then it should raise that exception as soon as it is partially applied to the invalid input.

Adopting this policy means that the following change should be made to the description of Time.fmt: Replace the sentence

Having n < 0 causes the Size exception to be raised.

with

Having n < 0 causes the Size exception to be raised when fmt n is evaluated.

Impact

Some versions of SML raise the exception at the point where the last argument is supplied (e.g., SML/NJ prior to 110.79). These implementations will have to be modified to implement the correct behavior. It is possible, but not likely, that there might be code that depends on the behavior of these implementations, but such code would not work on other implementations, so it ought to be fixed anyway.

There is also a potential implementation cost for adopting this behavior, since it prevents the application of the uncurrying transformation to an application of one of these functions to all of its arguments.

Rationale

Providing a uniform policy for curried functions will provide predictable behavior of these functions and provide a guide for the semantics of future proposals involving curried functions.


History

  • [2015-08-22] Proposed

Clone this wiki locally