[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] [r6rs-discuss] [scheme-reports] Scheme pattern matching & R*RS

I know I'm late on this, but generally I agree with Per's position
here. Pattern-matching is one of the few changes that I think ought to
be part of WG1. I have said nothing about it though because doing the
job correctly involves getting user-defined data types right and
dealing with multiple-return-values. Integrating all of those changes
with a module system is decidedly non-trivial.

And the bottom line is that the syntactic issues for a full pattern
match using SEXPs for semantics in the style of SML or Haskell are
really ugly. I had no idea that there was anyone in the Scheme
community who had either solved the verbosity of a sexp-based match
language, or had the stomach to embrace the usual solutions.

On 14 December 2010 19:04, Per Bothner <per@x> wrote:
> On 12/14/2010 09:39 AM, John Cowan wrote:
>> Per Bothner scripsit:
>>> The (default/preferred) syntax for lambda should do pattern-matching
>>> *without* having to use a verbose name like match-lambda*.

Absolutely agree here. Pattern matching should be integrated with
Scheme all the way through WG1. Otherwise we will have truly forked
the language.

>> I quite agree.  However, I don't think it's too great an imposition
>> to ask people to write (import (scheme patterns)) at the top of their
>> code in order to get pattern-matching lambda, define, let, let*, etc.

Given the wide variety of things that get affected by pattern
matching, while I admit that this is possible, I don't think it is
advisable. Pattern matching is a powerfully expressive mechanism - if
we are going to have it we should properly percolate its power all the
way through the language.

This is not a conservative change.

> It is tolerable, and may be the only solution for R7RS.  However,
> it is inconvenient and problematical (see below).  Perhaps we can
> consider having it part of the standard (rnrs (7)) library?
> And/or positioning it for being the default in R8RS?

Ick. The problem is that we are innovating at the wrong level. This
should be an implementation-first issue - unfortunately no
implementation has really pushed hard on pattern matching yet.

> And of course we have WG1 vs WG2 situation.  So we have to
> delegate patterns to an optional library for R7RS, but it is
> definitely a poor long-term solution.

I would venture to say it is an *unacceptable* solution even in the
short-term. I would love to have a clean pattern-matching Scheme, but
the semantic implications really are quite large, considering that
pattern-matching provides a significant strengthening of the Scheme
type system. Pattern-matching also obsoletes CALL-WITH-VALUES (an
entirely good thing IMO), which R6RS deeply embedded in the semantics
of function call.

Are we really willing to go here? I'd be up for it, but I thought that
the community was shying away from radical changes through
standardization, and that deep innovation in the Scheme community was
supposed to be led by implementations.

GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt

Scheme-reports mailing list