|
From: | Stefan Israelsson Tampe |
Subject: | Re: Inconsistent behaviour of the pattern matcher |
Date: | Sun, 28 Apr 2013 20:18:24 +0200 |
Stefan Israelsson Tampe <address@hidden> writes:
> On Sun, Apr 28, 2013 at 2:51 PM, Mark H Weaver <address@hidden> wrote:
>
> Panicz Maciej Godek <address@hidden> writes:
>
> > (match #u8(1 2 3)Read what I wrote again: "#u8(a b c) cannot be represented in the
> > (#u8(a b c)
> > (list a b c)))
>
> This can't work because a uniform numeric vector cannot hold
> symbols, so
> #u8(a b c) cannot be represented in the source code.
>
> please note a b c binds to values and is not symbols as in the pmatch
> matcher or match quasiquoute
> patterns. So with the right binder this could work.
*source* code." Remember that in Scheme (and Lisp), code is represented
as data. So what datum do you expect 'read' to return after it consumes
"#u8(a b c)"?
We could extend (ice-9 match) to support uniform numeric vectors, but
the pattern syntax would have to be different.
Given that Guile's arrays are specific to Guile and not portable, I
> If you want generic accessors, I guess the array accessors are
> what you
> want. Patches to extend the pattern matcher to handle arrays are
> welcome :)
>
> Actually for ice-9 match we would like the upstream version to
> implement these concepts
> Try ask foof on irc #scheme if he accept a patch to implement this in
> a portable way or ask
> him if he thinks he could spend time on it!
doubt that foof would be interested in supporting them upstream.
> Only if we could accept a slow implementation of the matcher we canBeyond the efficiency considerations, I'm not sure it's desirable for
> implement a general vector
> matcher by patching vector-ref etc.
the pattern #(a b c) to match #u8(1 2 3).
Mark
[Prev in Thread] | Current Thread | [Next in Thread] |