Non-linear and ellipsis patterns Marc Nieper-Wißkirchen (05 Sep 2020 15:36 UTC)
Re: Non-linear and ellipsis patterns Alex Shinn (06 Sep 2020 14:07 UTC)
Re: Non-linear and ellipsis patterns Marc Nieper-Wißkirchen (06 Sep 2020 14:30 UTC)
Re: Non-linear and ellipsis patterns John Cowan (06 Sep 2020 14:46 UTC)
Re: Non-linear and ellipsis patterns Alex Shinn (07 Sep 2020 09:14 UTC)
Re: Non-linear and ellipsis patterns Marc Nieper-Wißkirchen (07 Sep 2020 09:36 UTC)
Re: Non-linear and ellipsis patterns Alex Shinn (07 Sep 2020 13:25 UTC)
Re: Non-linear and ellipsis patterns Felix Thibault (08 Sep 2020 03:06 UTC)
Re: Non-linear and ellipsis patterns Marc Nieper-Wißkirchen (08 Sep 2020 16:34 UTC)
Re: Non-linear and ellipsis patterns Felix Thibault (13 Sep 2020 12:11 UTC)
Re: Non-linear and ellipsis patterns Marc Nieper-Wißkirchen (13 Sep 2020 12:50 UTC)
Re: Non-linear and ellipsis patterns Felix Thibault (13 Sep 2020 13:10 UTC)
Re: Non-linear and ellipsis patterns Marc Nieper-Wißkirchen (13 Sep 2020 13:26 UTC)
Re: Non-linear and ellipsis patterns John Cowan (13 Sep 2020 16:19 UTC)
Re: Non-linear and ellipsis patterns Marc Nieper-Wißkirchen (13 Sep 2020 16:27 UTC)
Re: Non-linear and ellipsis patterns Felix Thibault (13 Sep 2020 22:42 UTC)
Re: Non-linear and ellipsis patterns Marc Nieper-Wißkirchen (08 Sep 2020 16:21 UTC)

Re: Non-linear and ellipsis patterns Marc Nieper-Wißkirchen 08 Sep 2020 16:20 UTC

Am Mo., 7. Sept. 2020 um 15:25 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:

>> What I mean is that if it is an optional feature, it still leaves some
>> room for experimentation. It doesn't feel like there has been enough
>> experimentation/discussion going on so that duplicate pattern
>> variables suggest themselves for mandatory standardization. Are there
>> any real-life use cases where they are really needed?
>
>
> If I recall correctly, I added it only because someone said it couldn't be done with syntax-rules :)

:) The feature doesn't cost much in complexity and would have been an
error in the original matcher, which speaks for the feature.

The tie-in with a particular equivalence predicate, however, hints at
that we could prematurely standardize something that, viewed from the
future, could possibly have been solved better.

>> > With that restriction, no double ellipsis', and clarifying that side-effects
>> > in ? preds and = accessors are errors, the matching is deterministic.

What do you mean by side effects exactly?

We shouldn't forbid exceptions and possible uses of call/cc in pred or
= patterns, e.g. for short-circuiting.

Wouldn't be enough to write that the order and the number of times in
which the user-provided procedures are called is undetermined?

>> > I don't think there is any need to specify order (except for `or' clauses,
>> > where order also matters for Wright's original match).
>>
>> When the lexical environment where `pred` is evaluated depends on
>> which matchings have already taken place, an order has to specified.
>
>
> The scope rules have to be specified, though this still doesn't imply
> a matching order.  A simple way to side-step this whole issue is to
> make it an error for a predicate expr to refer to a pattern variable.

While that is certainly a simple way, it is a step back from the old
Wright matcher, where the predicates could access the whole lexical
environment of the match expression. Implementing the latter in your
matcher seems easy because you already have a macro that extracts and
renames all variables (which is used for ellipsis patterns, for
example).

> In practice, no one will want or need this anyway - 99% of predicates
> will be `number?' or `string?', etc.

Sure. My point is more that macros suitable for standardization should
have semantics that is, if at all possible, as clear as those of the
standard derived forms in the R[567]RS.

>> But I still think that this change from Wright's matcher is a mistake.
>> Not only but also for performance reasons: an implementation should be
>> possible that binds all pattern variables in one single `let` around
>> the body.

> We shouldn't be in the business of specifying things based on the
> assumption that "let is slow."

I once wrote a transpiler from Scheme to Javascript (using CPS to be
able to provide call/cc) and was amazed at how slow environment access
in nested closures in Javascript (V8 and SpiderMonkey) was. I haven't
made any experiments with common Scheme implementations, though. But
even with fast flat closures, a lot of copying may have to go on. The
problem is that the match macro has to bind all variables in most
cases a predicate shows up (if it wants to mimic your match's current
semantics) because it is generally impossible to scan the predicate
expression for possible pattern variable uses.

Marc