[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