From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.devel Subject: Re: Inconsistent behaviour of the pattern matcher Date: Sun, 28 Apr 2013 20:18:24 +0200 Message-ID: References: <877gjm24yj.fsf@tines.lan> <8738ua1s2s.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b33cb704367d904db6fcb28 X-Trace: ger.gmane.org 1367173112 18785 80.91.229.3 (28 Apr 2013 18:18:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Apr 2013 18:18:32 +0000 (UTC) Cc: guile-devel , Panicz Maciej Godek To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Apr 28 20:18:36 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UWWBH-0005C7-Vm for guile-devel@m.gmane.org; Sun, 28 Apr 2013 20:18:36 +0200 Original-Received: from localhost ([::1]:34791 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWWBH-00083n-I2 for guile-devel@m.gmane.org; Sun, 28 Apr 2013 14:18:35 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWWBA-00083R-P2 for guile-devel@gnu.org; Sun, 28 Apr 2013 14:18:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWWB8-0006QM-1P for guile-devel@gnu.org; Sun, 28 Apr 2013 14:18:28 -0400 Original-Received: from mail-pa0-f44.google.com ([209.85.220.44]:39343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWWB7-0006Q0-Ox for guile-devel@gnu.org; Sun, 28 Apr 2013 14:18:25 -0400 Original-Received: by mail-pa0-f44.google.com with SMTP id rl6so112248pac.3 for ; Sun, 28 Apr 2013 11:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sp0jXMhlq7OLAuuV7vY9asaSzxj2FqFzQn2KiqcXzUs=; b=ljyZIbavb0/x0eoI8bltNdiPsRALfTdhYFvsxZiKfgsBYZFFuuA7BFVRDBLoXxvjWH WMlUNJ/9NqstV09avU40x5RSY1tpXShBy+9QCIbGtuooOrH6cvsbPXxR8wI1+fJSBUyB 7gAPFAjmNFvJb+cj/uFWaBDAyF2PH5pqbwbLSqY4QFV2lAMCrn1qfO742y5jQgm5Qamt FKWh/79264efCVBG23jwNthcDwrpiadsjhUgSeZGN4Fc9prsCCVtygcRxGMv4NkBouhJ JbjvZgc2zu58cyQ/no4yW4o2sW95yYHZISOepPokz3ZNeiaF+657PrLWy+nGttd01cgE VZ9A== X-Received: by 10.68.244.38 with SMTP id xd6mr63360451pbc.131.1367173104885; Sun, 28 Apr 2013 11:18:24 -0700 (PDT) Original-Received: by 10.70.22.5 with HTTP; Sun, 28 Apr 2013 11:18:24 -0700 (PDT) In-Reply-To: <8738ua1s2s.fsf@tines.lan> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.44 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16305 Archived-At: --047d7b33cb704367d904db6fcb28 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 28, 2013 at 7:30 PM, Mark H Weaver wrote: > Stefan Israelsson Tampe writes: > > > On Sun, Apr 28, 2013 at 2:51 PM, Mark H Weaver wrote: > > > > Panicz Maciej Godek 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 > --047d7b33cb704367d904db6fcb28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Apr 28, 2013 at 7:30 PM, Mark H Weaver &l= t;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:
>
> =A0 =A0 Panicz Maciej Godek <godek.maciek@gmail.com> writes:
>
> =A0 =A0 > (match #u8(1 2 3)
> =A0 =A0 > (#u8(a b c)
> =A0 =A0 > (list a b c)))
>
> =A0 =A0 This can't work because a uniform numeric vector cannot ho= ld
> =A0 =A0 symbols, so
> =A0 =A0 #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<= br> > 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 th= e
*source* code." =A0Remember that in Scheme (and Lisp), code is represe= nted
as data. =A0So what datum do you expect 'read' to return after it c= onsumes
"#u8(a b c)"?

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


We could extend (ice-9 match) to support uniform numeric vectors, but
the pattern syntax would have to be different.

> =A0 =A0 If you want generic accessors, I guess the array accessors are=
> =A0 =A0 what you
> =A0 =A0 want. Patches to extend the pattern matcher to handle arrays a= re
> =A0 =A0 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<= br> > 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 a= rray refs are supported amongst=A0
the schemes. But strings= , bytevectors etc should be somewhat ubiquous. There might=A0
be a way to construct a extensible array syntax and those scheme= s that does not support=A0
arrays could get an error messag= e as a response to an array match. I don't know.=A0
Just that writing in a generalized vector support means th= at we must patch a significant
part of match.upstream.scm a= nd 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 int= o the standard
matcher, for this we would need foof's s= upport I guess.
=A0
> 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 desir= able 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) =A0as a gener= alized vector notation.

=A0 =A0 =A0 =A0Mark

--047d7b33cb704367d904db6fcb28--