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)
|
Am Mo., 26. Okt. 2020 um 22:17 Uhr schrieb Felix Thibault <xxxxxx@gmail.com>: > > On Mon, Oct 26, 2020 at 4:04 PM John Cowan <xxxxxx@ccil.org> wrote: > > > > > > > > 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. > > > > Is reserving them a matter of adding them to the SRFI as reserved and > putting them in the macros as not-implemented-error? As long as you want your implementation to be implementable just with syntax-rules, you cannot special-case all identifiers beginning with "->" or "=>". So, it would just be a matter of the documentation.