[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.

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

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports