John Cowan <xxxxxx@ccil.org> writes:

| On Sat, Nov 19, 2016 at 8:16 PM, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
|
|  This is just a reminder that it has been sixty days since
|  the first draft of SRFI 144, Flonums, was posted.
|
| There's an issue about the sample implementation that I
| don't know how to resolve. The flonum procedures that are
| semantically the same as generic procedures, like flsin,
| can be portably implemented just using sin. But the ones
| that come from the <math.h> library can't be, or at least
| not without ignoring the accuracy constraints.  Every
| implementer has access to the C library, but that doesn't
| mean every Scheme implementation provides access to it for
| their users, and if they do, it will be in a very
| implementation-specific way, as there is no standard FFI.
|
| What's the Right Thing to do here?  Provide portable but
| inexact implementations, or just say that the
| implementation is inherently specific to a given Scheme?

I've included an excerpt from the SRFI process document that
deals with this issue below.

Since a fully portable implementation is impossible, I would
shoot for a Scheme implementation-specific implementation of
the SRFI in which the means by which it uses <math.h> is
fully specified.  Since you also have an implementation that
is completely portable but inaccurate, you could include
that, too, documenting its deficiencies.

| I'm especially interested in Art's comments, but anyone
| else's too.

Here's what the SRFI process document
(<http://srfi.schemers.org/srfi-process.html>) says:

  7. It must contain a reference implementation.  This
  requirement may be met (in order from the most to the
  least preferred) by:

    1. A portable Scheme implementation (possibly using
    earlier SRFIs).  This is the most desirable option,
    because then implementors can provide a (possibly slow)
    implementation with no effort.

    2. A mostly-portable solution that uses some kind of
    hooks provided in some Scheme interpreter/compiler.  In
    this case, a detailed specification of the hooks must be
    included so that the SRFI is self-contained.

    3. An implementation-specific solution.  Ideally, tricky
    issues that had to be dealt with in the implementation
    will be identified.

    4. A separately available implementation, where a
    reference implementation is large or requires extensive
    modifications (rather than just additions) to an
    existing implementation.  This implementation will
    eventually be archived along with the SRFI and the
    discussion related to it.

    5. An outline of how it might be implemented.  This
    should be considered a last resort, and in this case the
    rationale for the feature must be stronger.

  The reference implementation should normally conform to
  the specification in point 5.  If there is any variance
  (such as the implementation being overly restrictive), the
  specification will be considered correct, the variance
  should be explained, and a timetable provided for the
  reference implementation to meet the specification.