Re: Inconsistent behaviour of the pattern matcher

[Stefan Israelsson Tampe <stefan.itampe@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2885 bytes --]

On Sun, Apr 28, 2013 at 7:30 PM, Mark H Weaver <mhw@netris.org> wrote:

> Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:
>
> > On Sun, Apr 28, 2013 at 2:51 PM, Mark H Weaver <mhw@netris.org> wrote:
> >
> >     Panicz Maciej Godek <godek.maciek@gmail.com> writes:
> >
> >     > (match #u8(1 2 3)
> >     > (#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.
>
> Read what I wrote again: "#u8(a b c) cannot be represented in the
> *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)"?
>

Aha, the #u8 reader is hardwired to produce a u8 datum. I thought it
produced something like
(u8-vector 'a 'b 'c) and that u8-vector would do the datum generation in
the source code and
the compiler could streamline things to various vector datum. Gotcha!


> We could extend (ice-9 match) to support uniform numeric vectors, but
> the pattern syntax would have to be different.
>
> >     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!
>
> Given that Guile's arrays are specific to Guile and not portable, I
> doubt that foof would be interested in supporting them upstream.


Yeah I'm not an expert enough to know how array refs are supported amongst
the schemes. But strings, bytevectors etc should be somewhat ubiquous.
There might
be a way to construct a extensible array syntax and those schemes that does
not support
arrays could get an error message as a response to an array match. I don't
know.

Just that writing in a generalized vector support means that we must patch
a significant
part of match.upstream.scm and this is a bit unclean. I would like some way
to add
in match.scm some definitions of extensions and be able to hook that up
into the standard
matcher, for this we would need foof's support I guess.


> > Only if we could accept a slow implementation of the matcher we can
> > implement a general vector
> > matcher by patching vector-ref etc.
>
> Beyond the efficiency considerations, I'm not sure it's desirable for
> the pattern #(a b c) to match #u8(1 2 3).


No you are right that its not nice to interpret #(a b c)  as a generalized
vector notation.

>
>        Mark
>

[-- Attachment #2: Type: text/html, Size: 4664 bytes --]