Email list hosting service & mailing list manager

Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (28 Aug 2020 11:49 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (28 Aug 2020 18:06 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (28 Aug 2020 19:22 UTC)
Re: Extensibility (and the lack thereof) John Cowan (29 Aug 2020 00:46 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (29 Aug 2020 08:14 UTC)
Re: Extensibility (and the lack thereof) Wolfgang Corcoran-Mathe (26 Oct 2020 17:50 UTC)
Re: Extensibility (and the lack thereof) John Cowan (26 Oct 2020 20:04 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (26 Oct 2020 20:33 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (26 Oct 2020 21:17 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (26 Oct 2020 21:30 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (26 Oct 2020 22:42 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (26 Oct 2020 22:49 UTC)
Re: Extensibility (and the lack thereof) John Cowan (27 Oct 2020 00:05 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (27 Oct 2020 00:35 UTC)
Re: Extensibility (and the lack thereof) John Cowan (27 Oct 2020 01:59 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (27 Oct 2020 02:18 UTC)
Re: Extensibility (and the lack thereof) Wolfgang Corcoran-Mathe (27 Oct 2020 19:38 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (27 Oct 2020 19:46 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (28 Oct 2020 06:31 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (28 Oct 2020 21:30 UTC)
Re: Extensibility (and the lack thereof) John Cowan (29 Oct 2020 00:17 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (29 Oct 2020 16:42 UTC)
Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen (27 Oct 2020 17:20 UTC)
Re: Extensibility (and the lack thereof) Felix Thibault (27 Oct 2020 18:42 UTC)

Re: Extensibility (and the lack thereof) Marc Nieper-Wißkirchen 26 Oct 2020 20:32 UTC

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.