debug feature identifier and coercion Antero Mejr (23 Aug 2024 19:31 UTC)
Re: debug feature identifier and coercion Artyom Bologov (24 Aug 2024 03:36 UTC)
Re: debug feature identifier and coercion Antero Mejr (24 Aug 2024 04:41 UTC)
Re: debug feature identifier and coercion Artyom Bologov (24 Aug 2024 06:01 UTC)
Re: debug feature identifier and coercion Arthur A. Gleckler (26 Aug 2024 05:24 UTC)

Re: debug feature identifier and coercion Antero Mejr 24 Aug 2024 04:41 UTC

Artyom Bologov <xxxxxx@aartaka.me> writes:

>> Also the SRFI should more clearly specify when coercion is done IMO.
>> Currently it says the `values-checked` form "might" coerce, but I think
>> the default should be no coercion (and specify this for all forms), and
>> that `*-coerce` variants be supplied, which must coerce when possible.
>
> This one I'm not sure about. Several reasons for the current spec:
>
> - Existing implementation practice. Kawa has an `as` form that coerces
>   the passed values to the necessary type when possible. Kawa
>   implementation of SRFI-253 uses `as` in `values-checked`, as the
>   closest implementation-specific approximation of `values-checked`.

Is it correct to assume that only `values-checked` does coercion? Can
any of the other forms in the SRFI coerce values?

> - Latent typing. Scheme is not strictly typed, so equating predicate
>   with type is not always right. `integer?` in particular might be true
>   on floats. And (generic) math operations convert between types
>   frivolously. So coercion is consistent with the rest of Scheme.
>
> - Semantics. My intention for `values-checked` was that it should
>   guarantee that the value returned from it satisfies the
>   predicate. Which is compatible with coercion. The language in the
>   document doesn't reflects that, though. I've sent an edit:
>   https://github.com/scheme-requests-for-implementation/srfi-253/pull/10

OK. Can the wording be updated to something like:

"Implementations may choose to coerce the values when the types are
compatible (e.g. integer -> inexact)."

That way the implementer can decide whether to be permissive or strict.
Also the SRFI text says "(e.g. int -> float)", but float is not
specified in R7RS so I assume it means inexact, which is usually
represented by a float.

My concern is that coercion could cause subtle changes in behavior or
breakage, in rare cases. A contrived example:

```
(define (add-one x)
  (values-checked (inexact?) (+ x 1)))

(display (inexact? (add-one 3))) ; different output in debug mode
```