Re: [Scheme-reports] returning back to pattern matching Andre van Tonder (24 Dec 2010 00:18 UTC)
Re: [Scheme-reports] returning back to pattern matching Alex Shinn (24 Dec 2010 00:21 UTC)
Re: [Scheme-reports] returning back to pattern matching Andre van Tonder (24 Dec 2010 00:27 UTC)
[Scheme-reports] Scheme is NOT spam! Vincent Manis (24 Dec 2010 02:41 UTC)
Re: [Scheme-reports] [r6rs-discuss] returning back to pattern matching Vincent Manis (24 Dec 2010 00:18 UTC)
Re: [Scheme-reports] [r6rs-discuss] returning back to pattern matching Thomas Bushnell, BSG (24 Dec 2010 00:26 UTC)

Re: [Scheme-reports] [r6rs-discuss] returning back to pattern matching Vincent Manis 24 Dec 2010 00:17 UTC

On 2010-12-23, at 15:49, Peter Kourzanov wrote:

> On Thu, 2010-12-23 at 14:33 -0800, Vincent Manis wrote:
>> So, please:
>>
>>  1. small, clean, core language, with a modest number of extensions to
>> existing standards (though, I hope, nothing that is an extension to
>> existing practice).
>
> Then we should have stopped at R4RS and declared it the ultimate Scheme,
> which is the point where some important implementations have stopped.
Actually, R5RS is where many important implementations stopped. I primarily use Gambit and Chicken in my work.

>> From my experience the lack of pattern matching, not even dynamic typing
> anymore, that is the feature that makes many people go Haskell or ML.
> That is sad to see, especially in an otherwise powerful language that
> advocates program-as-data philosophy, yet at the same time permeates
> half-baked solutions like (define (x y . z)), case/eqv?, case-lambda and
> let-values... THAT does sound like piling feature upon feature upon
> feature.

Absolutely no disagreement here. Pattern matching is extremely important, and I hope WG2 can come up with a clean set of pattern matching facilities. Having said that, I'm reluctant to change (as opposed to cleaning up specifications for) anything defined in R5RS (or in some cases R6RS). C.A.R. Hoare once said something to the effect that the absolute last place to do any language design is in preparing a standard. This has always struck me as very sensible.

As for things like case-lambda and let-values (defined in SRFIs), and match (defined by various implementations), I don't care too much about the APIs. If these are all unified into some glorious do-what-i-want form, I'm likely to write implementations of the older forms as macros, so as not to break my existing code. If it's possible to harmonize them, great. If not, having explicit matching provided in an official library is far more important than the exact API to be chosen.

-- vincent

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