New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Arthur A. Gleckler 02 Jul 2020 05:56 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Shiro Kawai 02 Jul 2020 12:50 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types John Cowan 02 Jul 2020 13:19 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 07 Jul 2020 14:23 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types John Cowan 07 Jul 2020 20:32 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 08 Jul 2020 14:27 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 08 Jul 2020 19:47 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 08 Jul 2020 20:21 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types John Cowan 09 Jul 2020 04:32 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 09 Jul 2020 09:30 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types John Cowan 10 Jul 2020 14:05 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 14:39 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 10 Jul 2020 17:30 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
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 11 Jul 2020 15:22 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 11 Jul 2020 15:30 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 11 Jul 2020 16:17 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Alex Shinn 11 Jul 2020 22:20 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 11 Jul 2020 22:29 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 12 Jul 2020 03:35 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 11 Jul 2020 16:33 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types John Cowan 11 Jul 2020 18:44 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 11 Jul 2020 19:26 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Arthur A. Gleckler 11 Jul 2020 19:59 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 11 Jul 2020 20:06 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Arthur A. Gleckler 11 Jul 2020 20:08 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Marc Nieper-Wißkirchen 14 Jul 2020 09:13 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types John Cowan 14 Jul 2020 21:15 UTC
Re: New draft (#8) of and new "last call" for SRFI 189: Maybe and Either: optional container types Alex Shinn 15 Jul 2020 00:07 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.