From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115969 invoked by alias); 6 Sep 2018 17:10:41 -0000 Mailing-List: contact kawa-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: kawa-owner@sourceware.org Received: (qmail 115957 invoked by uid 89); 6 Sep 2018 17:10:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Per, comfortable, complications, XML X-HELO: aibo.runbox.com Received: from aibo.runbox.com (HELO aibo.runbox.com) (91.220.196.211) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Sep 2018 17:10:38 +0000 Received: from [10.9.9.211] (helo=mailfront11.runbox.com) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1fxxnf-0005ls-OU for kawa@sourceware.org; Thu, 06 Sep 2018 19:10:35 +0200 Received: by mailfront11.runbox.com with esmtpsa (uid:757155 ) (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) id 1fxxnQ-0006RV-WD for kawa@sourceware.org; Thu, 06 Sep 2018 19:10:21 +0200 Subject: =?UTF-8?B?UmU6IOKAmG1hdGNo4oCZIGFuZCDigJgh4oCZIGZlYXR1cmVz?= To: kawa@sourceware.org References: <87ftym4ns7.fsf@gnu.org> From: Per Bothner Message-ID: Date: Thu, 06 Sep 2018 17:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87ftym4ns7.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-q3/txt/msg00004.txt.bz2 On 09/06/2018 09:02 AM, Mathieu Lirzin wrote: > Hello, > > I am getting interested in using Kawa lately. I am happy to discover > that it implements pattern matching using the ‘match’ and ‘!’ macros. > However I am a bit puzzled by the fact those features are added in the > main module while the documentation on patterns [1] describe those > features as work in progress. > > In order to lower the retro-compatibility expectations for those > experimentations, What do you think of moving the ‘match’ and ‘!’ > definitions in a dedicated library for example (kawa match) ? Moving these core features to library may be a bit of work, and I don't think it would be desirable - as a core feature. I'm reasonably comfortable with the syntax and design, and am not planning on changing it. Of course there are almost certainly bugs as well as under-optimized code. The main feature where design and implementation are missing is dealing with structural patterns. Given a constructor function T, where T may be a type/class name (see https://www.gnu.org/software/kawa/Allocating-objects.html), what should be the pattern syntax for "destructuring"? The syntax (T pat1 pat2 ... patN) could be used to match a value created by (T e1 e2 ... eN) by matching e1 against pat1 etc. There is a symmetry blemish in that T in (T pat1 pat2 ... patN) is "evaluated" while the "arguments" are patterns, but it still seems a reasonable syntax. Still, there are a number of complications in doing this. Patterns with keyword arguments are slightly easier. To match an obj against: (T x: pat1 ... z: pat1) could be implemented by matching obj:x against pat1 etc. In adddition we should require (equal? obj (T obj:x ... obj:z)). Then we could go further: Regular (tree) expressions. Strings. XML/HTML nodes. So that's what I mean when I say this feature is a work-in-progress. -- --Per Bothner per@bothner.com http://per.bothner.com/