Re: [Scheme-reports] [r6rs-discuss] Scheme pattern matching: the case for (case) Peter Kourzanov (21 Dec 2010 20:12 UTC)
(missing)
(missing)
(missing)
(missing)
(missing)
(missing)
(missing)
(missing)
(missing)
(missing)
(missing)
Re: [Scheme-reports] [r6rs-discuss] Bigloo Peter Kourzanov (22 Dec 2010 20:35 UTC)
Re: [Scheme-reports] [r6rs-discuss] Bigloo Thomas Bushnell, BSG (22 Dec 2010 21:01 UTC)
Re: [Scheme-reports] [r6rs-discuss] returning back to pattern matching Thomas Bushnell, BSG (22 Dec 2010 21:55 UTC)
Re: [Scheme-reports] [r6rs-discuss] returning back to pattern matching Thomas Bushnell, BSG (23 Dec 2010 19:47 UTC)
Re: [Scheme-reports] [r6rs-discuss] returning back to pattern matching Thomas Bushnell, BSG (24 Dec 2010 00:53 UTC)
Re: [Scheme-reports] [r6rs-discuss] redefining eqv? Peter Kourzanov (22 Dec 2010 20:32 UTC)
Re: [Scheme-reports] [r6rs-discuss] redefining eqv? Thomas Bushnell, BSG (22 Dec 2010 21:02 UTC)
Re: [Scheme-reports] [r6rs-discuss] redefining eqv? Eli Barzilay (22 Dec 2010 23:37 UTC)

Re: [Scheme-reports] [r6rs-discuss] Scheme pattern matching: the case for (case) Peter Kourzanov 21 Dec 2010 20:12 UTC

On Tue, 2010-12-21 at 12:16 -0500, Jim Wise wrote:
> a.) existing match libraries do not have an analogue of case

I have seen no single library that didn't provide a construct
similar to (case) - its only called typically (match) and typically
allowing only one top-level alternative (all do support more verbose
or-patterns). There is one matcher that evan calls it explicitly
(match-case). They all expect a list of clauses where the (car) is the
pattern, the (car (reverse)) is the body and possibly a guard in
between.

Extending this to cover (case), i.e., a list of possible patterns
rather than a single pattern is a very Schemey thing to do, in
my opinion.

>
> b.) RNRS case's syntax does not lend itself to extending to the pattern
>     matching case in an upwardly compatible manner.  In particular, case
>     compares values with eqv? and performs no binding, while lambda and
>     the let forms are all binding forms (and compare with equal? in the
>     pattern-matching versions).

eqv? is immaterial here:

(let ([eqv? equal?]) (case "asd" (("asd") #t)))

About binding I think you're right, however the (else => exp) form is
sort-of breaking this already. How serious is this limitation that all
binding must be done by lambda, let, let*, letrec, do, case-lambda,
let-values and define (and labels, and innumerable other extensions)?

>
>     This means that making case destructure its arguments would change
>     the meaning of existing valid code, at least for non-list,
>     non-vector patterns:
>
>                (case 'a
>                  ((a) (list a))
>                  (else #f))
>
>                ==> (3)

Not necessarily so. One can consider a (case) pattern to be implicitly
quasiquoted (just like traditional case is implicitly quoted). So, if
one needs "extended" (case) capabilities, one would write:

(case 'b
  ((,a) (list a)))

Otherwise the following would retain its meaning:

(case 'a
  ((a) (list a)))

>
> Neither of these is necessarily compelling, but I think both argue that
> adding pattern matching support to case is more intrusive than adding it
> only to the environment-constructing forms.  On the other hand, the
> (match ...) form of (rnrs match) can be used in a manner similar to
> (case ...), but with no compatibility concerns for existing code.
>
> Thoughts?

>From my perspective, (case) is a degenerate case of (match) and should
be merged - we don't need two switch constructs in a simple and small
language.

Regards,
Pjotr

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