Re: fmatch

[ludo@gnu.org (Ludovic Courtès)]

Hi!

stefan <stefan.tampe@spray.se> writes:

> I think that the match-define logic is something that is missing in the 
> Shinn version although I don't know how much this construct is used.

Yes, I left a comment about it in ice-9/match.scm.

> Basically $ is using the order of the records like ($ person? Rec1 Rec2 , ... 
> Recn)
> and is nice to do quick hacks and get dense informative matchers. On the 
> other hand if the record specification changes, like the order of the 
> records or meanings etc havoc can enter. So destructuring on order would 
> probably, in the end, yield a buggy code base. And I suspect that this issue 
> makes the $ construct less liked and probably will not be accepted upstreams.
>
> On the other hand we have the record-case construct that is somewhat dense in 
> information but is not hygienic. That would leave us with constructs like
>
> (and (= person-height pat1)
>      (= person-weight pat2)
>      ...)
>
> We can streamline it a little but the end win is marginal compared to the 
> size of usual accessor names.

It looks like we are somewhere between a rock and a hard place.  :-)

> I would have liked something like
> ($ person (height pat1) (weight pat2))

Perhaps:

  ($ person? (person-height h) (person-weight w))

But then again, if we look at, say, language/tree-il/analyze.scm as an
example, it seems clear that such a syntax would be too heavyweight.

In Coq, OCaml, Scala, etc., one matches on the type constructor:

  match stefan with
    | Person h w => ...
  end

This *is* also positional matching, except that it relates to the
position of the arguments to the constructor, not to the position of
slots within the structure.  In the end, it’s not too different, though.

So, I’m still in favor of adding Wright’s ‘$’ positional pattern
matching, along with ‘=’ to match with named accessors.

Thanks,
Ludo’.