Inconsistent behaviour of the pattern matcher

Inconsistent behaviour of the pattern matcher

[Panicz Maciej Godek]

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

Hi,
I've traced something that is not entirely a bug, but which was a little
surprise for me. It has to do with the extensions that guile provides to
the Scheme language -- namely, uniform vectors and arrays.

The (ice-9 match) module offers the syntax
(match #(1 2 3)
  (#(a b c)
   (list a b c)))
;===> (1 2 3)

However, none of the following behaves as one could expect:
(match #u8(1 2 3)
  (#u8(a b c)
   (list a b c)))

(match #2((1 2)(3 4))
  (#2((a b)(c d))
   (list a b c d)))

(match #u8(1 2 3); this is perhaps questionable, but
  (#(a b c) ; i add it for a discussion
  (list a b c)))

After looking into the source of the pattern matcher, I've found out that
the problem is probably situated deeper: while it is possible to define
macros with regular vectors, like that:

(define-syntax nv
  (syntax-rules ()
    ((nv #(v ...))
     (list v ...))))

it doesn't work if we replace the #(v ...) with #u8(v ...), for instance.

Best regards,
M.

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

Re: Inconsistent behaviour of the pattern matcher

[Mark H Weaver]

Panicz Maciej Godek <godek.maciek@gmail.com> writes:

> I've traced something that is not entirely a bug, but which was a
> little surprise for me. It has to do with the extensions that guile
> provides to the Scheme language -- namely, uniform vectors and arrays.
>
> The (ice-9 match) module offers the syntax
> (match #(1 2 3)
> (#(a b c)
> (list a b c)))
> ;===> (1 2 3)
>
> However, none of the following behaves as one could expect:
> (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.

> (match #2((1 2)(3 4))
> (#2((a b)(c d))
> (list a b c d)))

This could be made to work, but has not been implemented.

> (match #u8(1 2 3); this is perhaps questionable, but
> (#(a b c) ; i add it for a discussion
> (list a b c))) 

This should not work, IMO, because uniform numeric vectors are a
distinct type from normal vectors, and making the normal vector
accessors work with the other vector-like types would necessarily make
them much slower when we have native code generation.

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 :)

> After looking into the source of the pattern matcher, I've found out
> that the problem is probably situated deeper: while it is possible to
> define macros with regular vectors, like that:
>
> (define-syntax nv
> (syntax-rules ()
> ((nv #(v ...))
> (list v ...))))
>
> it doesn't work if we replace the #(v ...) with #u8(v ...), for
> instance.

Again, a #u8 vector cannot hold symbols, so this cannot work.

     Regards,
       Mark

Re: Inconsistent behaviour of the pattern matcher

[Stefan Israelsson Tampe]

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

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

> Panicz Maciej Godek <godek.maciek@gmail.com> writes:
>
> > I've traced something that is not entirely a bug, but which was a
> > little surprise for me. It has to do with the extensions that guile
> > provides to the Scheme language -- namely, uniform vectors and arrays.
> >
> > The (ice-9 match) module offers the syntax
> > (match #(1 2 3)
> > (#(a b c)
> > (list a b c)))
> > ;===> (1 2 3)
> >
> > However, none of the following behaves as one could expect:
> > (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.


> 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!

Only if we could accept a slow implementation of the matcher we can
implement a general vector
matcher by patching vector-ref etc.

/Stefan

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

Re: Inconsistent behaviour of the pattern matcher

[Mark H Weaver]

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)"?

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.

> 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).

       Mark

Re: Inconsistent behaviour of the pattern matcher

[Stefan Israelsson Tampe]

[-- 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 --]