Email list hosting service & mailing list manager

New draft (#9) and last call of SRFI 224: Integer Mappings Arthur A. Gleckler (11 Jun 2021 01:16 UTC)
Re: New draft (#9) and last call of SRFI 224: Integer Mappings Wolfgang Corcoran-Mathe (11 Jun 2021 02:00 UTC)
Re: New draft (#9) and last call of SRFI 224: Integer Mappings Marc Nieper-Wißkirchen (11 Jun 2021 05:35 UTC)
Re: New draft (#9) and last call of SRFI 224: Integer Mappings Wolfgang Corcoran-Mathe (11 Jun 2021 14:41 UTC)
Re: New draft (#9) and last call of SRFI 224: Integer Mappings Marc Nieper-Wißkirchen (11 Jun 2021 15:18 UTC)
Re: New draft (#9) and last call of SRFI 224: Integer Mappings Marc Nieper-Wißkirchen (13 Jun 2021 08:39 UTC)

Re: New draft (#9) and last call of SRFI 224: Integer Mappings Wolfgang Corcoran-Mathe 11 Jun 2021 14:41 UTC

On 2021-06-11 07:35 +0200, Marc Nieper-Wißkirchen wrote:
> In fact, IMO, fxmapping-lookup is a good example where Maybes are
> worse than the traditional fxmapping-ref. Not only is the former less
> Scheme-y (but this is somewhat subjective), it is also an example of
> needless allocation of objects on the heap.

I agree that fxmapping-lookup is a bit marginal, and I mainly
included it for completeness.

In other places, Maybe is integral.  I did in fact create an
experimental branch[1] in which the Maybe procedures are refactored
as CPS forms.  We have CPS variants like

    (imapping-alter imap k failure success)

which is pretty much identical to `mapping-search'.  These forms are
more complicated than their Maybe-passing counterparts, and harder to
compose.  They also entail the uncheckable expectation that the user
will tail-call a continuation, leading to possible bugs that don't
arise with Maybe-passing.  There's nothing to prevent something like:

    (imapping-alter (imapping 0 'a 1 'b)
                    1
                    (lambda (_ ignore) (ignore))
                    (lambda (v update remove)
                      (update (update v))))

All in all, I think there are good reasons to avoid CPS *as a design
approach*, once we reach the point of calling continuations on
continuations.

> IMO, idiomatic code should only
> create Maybes when they have to be stored. In the given example
> implementation of fxmapping-ref, however, they are created just to be
> destructed again. IMO, that's a bad use and not a very good example.

Would you be willing to give an example that you like better?

Many of the examples in the SRFI are, of course, very silly.  I've
opted for simplicity and terseness over usefulness.  At least there
aren't any embedded insults ("Another miserable Perl drone"...).

> fxmapping-ref should be the primitive procedure, and one could give an
> implementation of fxmapping-lookup in terms of fxmapping-ref.

Since fxmapping-ref is likely to be used heavily, I've made this
change in the sample implementation.  Thanks.

[1] https://github.com/Zipheir/imappings-pre-srfi/tree/cps

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"Conventional programming is precise only about 'how',
not about 'what'." --Conal Elliott