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) Felix Thibault 27 Oct 2020 00:35 UTC

On Mon, Oct 26, 2020 at 8:05 PM John Cowan <xxxxxx@ccil.org> wrote:
>
> "Beginning with ->" was a mistake.  I conflated two statements:  (a) I want to reserve -> and => (b) R6RS does not have a problem with either of these identifiers, even though identifiers are not allowed to begin with "-".  To which I add (c) that I don't care what we reserve, as long we reserve two things.
>
> On Mon, Oct 26, 2020 at 5:30 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>> How is this supposed to be efficient?
>
>
> It's primarily intended to be complete.  Dynamically typed lists are a universal data structure; that's one of McCarthy's original theorems.  If you know how to match a list and you have views, you can match anything at all.
>
>> This would construct an object just to have it deconstructed.
>
>
> A very good point.  So let's make it (view view-proc pattern ...), where view-proc takes the object to match and returns multiple values that are matched against the patterns.
>

Wait, is this like (match (view-proc obj) pattern ...)) ? Or
(from-view view-proc (match (to-view view-proc obj) (pattern ...))) ?

>>
>> If we want an efficient solution, the mapping from an opaque to a
>> transparent type should happen at expansion time.
>
>
> If view-proc and call-with-values are inlineable, that's about as good as matching against any other pattern.
>
>
>
> John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
> Heckler: "Go on, Al, tell 'em all you know.  It won't take long."
> Al Smith: "I'll tell 'em all we *both* know.  It won't take any longer."
>