Re: New draft (#5) of SRFI 189: Maybe and Either: optional container types Marc Nieper-WiÃkirchen 07 Jun 2020 10:28 UTC
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