Am So., 7. Juni 2020 um 06:29 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:

> > 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,

At the moment, we don't have such a general pattern matcher and it
will hardly be as efficient as this specialized one. And if we want to
see Maybes used in many algorithms, efficiency matters.

> 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) ...))

That's true that it is just one character longer; but the maybe-case
form expresses a different intent. Moreover, it is less ugly!

In any case, the cost of adding a `maybe-case' macro is zero.

> 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*.

Maybe-let* (which should be the analogue of and-let*) will certainly
be helpful, but I don't see how it can replace my `maybe-case':

Marc