From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Inconsistent behaviour of the pattern matcher Date: Sun, 28 Apr 2013 08:51:48 -0400 Message-ID: <877gjm24yj.fsf@tines.lan> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1367153548 1032 80.91.229.3 (28 Apr 2013 12:52:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Apr 2013 12:52:28 +0000 (UTC) Cc: guile-devel To: Panicz Maciej Godek Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Apr 28 14:52:32 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 1UWR5i-0003Sx-0o for guile-devel@m.gmane.org; Sun, 28 Apr 2013 14:52:30 +0200 Original-Received: from localhost ([::1]:48852 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWR5h-0005pz-JK for guile-devel@m.gmane.org; Sun, 28 Apr 2013 08:52:29 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWR5b-0005pi-TG for guile-devel@gnu.org; Sun, 28 Apr 2013 08:52:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWR5b-0007u9-1c for guile-devel@gnu.org; Sun, 28 Apr 2013 08:52:23 -0400 Original-Received: from world.peace.net ([96.39.62.75]:43501) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWR5a-0007sO-TW for guile-devel@gnu.org; Sun, 28 Apr 2013 08:52:22 -0400 Original-Received: from ip68-9-118-38.ri.ri.cox.net ([68.9.118.38] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UWR5B-00018y-7E; Sun, 28 Apr 2013 08:51:57 -0400 In-Reply-To: (Panicz Maciej Godek's message of "Sun, 28 Apr 2013 10:12:57 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:16300 Archived-At: Panicz Maciej Godek 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