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