Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Wolfgang Corcoran-Mathe 07 Jun 2020 04:29 UTC
On 2020-06-06 18:58 +0200, Marc Nieper-Wißkirchen wrote: > >> (20) What about a `maybe-case' as well? In `maybe-if', the payload of > >> the Just is thrown away, which is not what we always want. > >> > >> (define-syntax maybe-case > >> (syntax-rules (just nothing) > >> ((maybe-case e ((just . arg*) . body1) ((nothing) . body2)) > >> (maybe-ref e (lambda () . body2) (lambda arg* body1))))) > >> > >> A similar definition can be made for `either-case'. > > > > > > Can you explain the purpose of this? > > If you have code that consumes a Maybe, you can use `maybe-if' to turn > different data paths (encoded by Maybe) into different code paths. But > when you also need to know the payload, you would use `maybe-case': > > (maybe-case maybe > ((just x) > ;; maybe is a just and `x' is bound to the payload, which must be a > single object in this case > ...) > ((nothing) > ;; maybe is a nothing > ...)) My first thought on seeing this form was that it's a special-purpose pattern-matcher. With some standardized general pattern-matching form, it would of course be nice to be able to write something identical, s/maybe-case/match/ (or whatever). But maybe-case by itself doesn't seem to add much; the following is equivalent to the above example, and only one character longer: (maybe-ref maybe ;; maybe is a nothing (lambda () ...) ;; maybe is a just and `x' is bound to the payload, which must ;; be a single object in this case (lambda (x) ...)) The lambdas are a bit ugly, though. I do think there's a need for a syntactically higher-level (i.e. than maybe-ref) form for working with Maybes. Perhaps that's maybe-let*. Regards, -- Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> "Quantum mechanics can be understood as the discovery that information in nature is always finite." --Carlo Rovelli