Am Mo., 26. Okt. 2020 um 21:04 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Mon, Oct 26, 2020 at 1:50 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
>
>> I'd second this emphatically.  Few ideas suffer more from a restricted
>> view of Scheme types than pattern-matching.  Any number of extensions
>> seem plausible (what if we want our matcher to match ilists, boxes,
>> mappings, or some other type yet to be invented?), but, as noted
>> above, such extensions may break compatibility.
>
>
> I think the Right Thing here is to resurrect Haskell's idea of views (which are also present in Pure, by the way). Basically a view is a function that transforms an object of some opaque type (defined by a predicate, for Scheme purposes) into an object with a transparent type (most likely a list) that we know how to match on.  Then we just have to teach the matcher about (-> view-proc pattern), which applies view-proc to the object to be matched and matches the result against the pattern.
>
> See <https://gitlab.haskell.org/ghc/ghc/-/wikis/view-patterns> for details, some of which are unobvious (at least to me).  There are a LOT of other ideas at the bottom of that page, with links, but I think this one hits the sweet spot.  Support belongs in another SRFI, but I believe it is a reasonable extension.  I'd like to reserve patterns beginning with -> and => (these are valid in R6RS, so no problem there) in this SRFI, though.

How is this supposed to be efficient? This would construct an object
just to have it deconstructed. GHC may have a compiler that is
intelligent enough to understand and optimize away such a pattern, but
this is probably not true for most Schemes. To be fair, with static
types and no side effects, the job for a Haskell compiler looks much
easier than for a Scheme compiler.

If we want an efficient solution, the mapping from an opaque to a
transparent type should happen at expansion time. (The Nanopass
framework, which is actually from the Scheme world, is a good example
that this is doable. Of course, the domain of the framework is more
specialized.)

PS Reserving pattterns beginning with "->" and "=>" is certainly not a
bad idea, but the wish to do this is the perfect demonstration of why
I wrote the initial post in this thread. We cannot foresee what other
special identifiers we would like to add or would like to have added
in the future.