Email list hosting service & mailing list manager

Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen (10 Jul 2020 17:51 UTC)

Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 10 Jul 2020 17:50 UTC

Am Fr., 10. Juli 2020 um 19:30 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2020-07-10 16:39 +0200, Marc Nieper-Wißkirchen wrote:
> > A better implementation would be (maybe-if m j n) => (if (maybe? m)
> > (if (just? m) j n) (error "...")).
> >
> > Note that this better implementation even conforms to the current
> > wording in SRFI 189.
>
> Not meaning to extend an already dense thread, I'm still going to
> jump in here.  I don't think that an implementation of maybe-if (or
> the other other SRFI 189 macros) using assume conforms to the current
> spec.  Namely, it isn't stated anywhere in SRFI 145 that an object
> raised by assume satisfies error-object?.  (On the strength of this, I
> did some work yesterday to make the macro implementations into more
> unassuming code, using error throughout.)  Is this interpretation
> correct, or would assume be acceptable here?

This is exactly my point. An implementation using "assume" (which
delegates the general "error situation and reporting" to a single
authority) is not yet conforming to the current SRFI 189 spec.

Of course, my point is not that "assume" has to be to be used or has
to be usable but that forcing the implementation to *signal an error*
instead of *reporting an error in an implementation-defined way* is a
fundamental deviation from the basic principles of R7RS, which,
moreover, still fails to guarantee to resume a buggy program and is
detrimental to optimizations through type inference.