From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) by sourceware.org (Postfix) with ESMTPS id 863843846403 for ; Tue, 11 May 2021 21:41:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 863843846403 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bothner.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=per@bothner.com Received: from [10.9.9.74] (helo=submission03.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1lga83-0006Jg-2T; Tue, 11 May 2021 23:41:23 +0200 Received: by submission03.runbox with esmtpsa [Authenticated alias (524175)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1lga81-0005ne-MN; Tue, 11 May 2021 23:41:21 +0200 Subject: Re: Extensible Macros and define-library To: "J. Vincent Toups" , kawa@sourceware.org References: From: Per Bothner Message-ID: Date: Tue, 11 May 2021 14:41:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: kawa@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Kawa mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 21:41:30 -0000 Sorry for the late response - I missed your message. On 4/17/21 3:32 AM, J. Vincent Toups via Kawa wrote: > I'm seeking ideas on how to implement an extensible pattern matcher. If you want to define your own pattern-matching library, you can of course do what. Likewise, if you're trying to implement a library following some other existing API. However, if you want pattern-matching to be part of Kawa itself and available as part of the Kawa "standard library" then note that Kawa has its own pattern "language" and "vision". If you're not already familar with it, check out http://www.gnu.org/software/kawa/Variables-and-Patterns.html Understand that the (let ...) family and lambda formal parameters have been extended to take patterns: http://www.gnu.org/software/kawa/Extended-formals.html Note the (! patterm value) syntax is an extension of plain define. Note how if-expressions and cond have been extended to be pattern-aware, using the (? pattern value) form: www.gnu.org/software/kawa/Conditionals.html . Now the Kawa pattern "syntax" is rather limited. My goal was to integrate patterns into the language, so I stuck to pattern forms that wouldn't constrain extending the pattern language. Unfortunately, syntax-rules is based on pattern-match using an elegant but limited syntax - which is incompatible with most other designs: In syntax-rules the pattern (list x y z) matches a *four*-element list, binding the name 'list to the first element of the list. I.e. the first element of a list in a syntax-rules pattern is not a pattern operator, but instead matches just like the remaining elements. Now if we *do* want to allow "pattern operators", breaking with syntax-rules compatibility (and I think we do) then it would be desirable to allow for some kind of extensibility, as you're talking about. If you want to extend or hook into the Kawa pattern framework, the place where lists are handled is starting near line 143 in kawa/lang/BindDecls.java. Specifically, search for the error message "unrecognized pattern operator " and erplace that to search for a defined pattern operator. Unfortunately, the code is rather convoluted. The hard part is defining a Scheme API that can hook into the BindDecls class. Specifically, what kind of transformer is it: What are the inputs (patterns, presumably) and what are the outputs (declarations/bindings, initialized from the match form) in a clean way that can be mapped to Kawa internals. How to deal with namespaces and hygiene can probably best be done with compound names: www.gnu.org/software/kawa/Symbols-and-namespaces.html For example when the compiler sees a pattern (OP arg1 arg2 args3) it could look for a transfomer with the name $PATTERN-BIND$:OP - i.e. the symbol 'OP in the '$PATTERN-BIND$ namespace. -- --Per Bothner per@bothner.com http://per.bothner.com/