From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Chris K. Jester-Young" Newsgroups: gmane.lisp.guile.devel Subject: Re: regexp-split for Guile Date: Tue, 18 Sep 2012 15:31:25 -0400 Message-ID: <20120918193125.GC6315@yarrow> References: <20120917140133.GA6315@yarrow> <87lig830ox.fsf@zigzag.favinet> <20120917200603.GB6315@yarrow> <50581D8F.2070703@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1347996695 29501 80.91.229.3 (18 Sep 2012 19:31:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Sep 2012 19:31:35 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Sep 18 21:31:39 2012 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 1TE3WF-0007Mm-LN for guile-devel@m.gmane.org; Tue, 18 Sep 2012 21:31:39 +0200 Original-Received: from localhost ([::1]:42445 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TE3WB-0006A1-Bh for guile-devel@m.gmane.org; Tue, 18 Sep 2012 15:31:35 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TE3W8-00069i-AA for guile-devel@gnu.org; Tue, 18 Sep 2012 15:31:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TE3W7-0001OA-40 for guile-devel@gnu.org; Tue, 18 Sep 2012 15:31:32 -0400 Original-Received: from mail-vc0-f169.google.com ([209.85.220.169]:46383) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TE3W6-0001MV-VA for guile-devel@gnu.org; Tue, 18 Sep 2012 15:31:31 -0400 Original-Received: by vcbfl17 with SMTP id fl17so308470vcb.0 for ; Tue, 18 Sep 2012 12:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=T5a3ZqKHcSmcxxBDddEdh3tJhrB9bq1+YXGMN/akEUg=; b=Nwk/t11g1tcjlXYXt5LSFXA/ruCXxBJiRPEJzf82XdPxLKqeNjIxTAp84NpTFW0m8W vwcRLsCcSCV1c7ndkT6CMjeFCbqhNxq6fRNhP51qcKUDh+xk7cq8qYeJT2hup3lAf2dm zaZdeoham/Swemy4EigLnwK+RHfjjXUPlxPoky5mHSpR/7J7UZPcr+IACaXM9EcS3FMH 5965ancQZKORo2QXf4W+MbaIIOZus1Q4HOfhcDFFaEOSO+4SCFLPgo1APc1kgCn2gaxc I44bHo/nxsDsZwgwFGdcTJTdq95Qr0QbjnKGwzLpRxqPQhaEFYkNKRXHYfdzDKiNvI2H AJmw== Original-Received: by 10.220.226.4 with SMTP id iu4mr524913vcb.64.1347996690082; Tue, 18 Sep 2012 12:31:30 -0700 (PDT) Original-Received: from yarrow (cpe-069-134-140-185.nc.res.rr.com. [69.134.140.185]) by mx.google.com with ESMTPS id k2sm215505vdf.15.2012.09.18.12.31.27 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 12:31:28 -0700 (PDT) Mail-Followup-To: guile-devel@gnu.org Content-Disposition: inline In-Reply-To: <50581D8F.2070703@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.220.169 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:14895 Archived-At: On Tue, Sep 18, 2012 at 09:06:55AM +0200, Sjoerd van Leent Privé wrote: > It might just be me, but would it not be more sensible for scheme to > just perform the opposite. Return the same amount of fields at most, > but starting from the end, thus: > > (regexp-split ":" "foo:bar:baz:qux:" -3) > => ("foo:bar" "baz" "qux" "") Unfortunately, this is not ideal to implement: 1. Regexes are inherently forward-searching only. This means that matches are always built up from left-to-right. 2. Thus, there is no sensible way to implement right-fold-matches, which is what would be required for what you're proposing. What would instead have to happen is that you have to do list-matches with no limit, then ignore the front matches. This complicates the code significantly. 3. It's not compatible with Perl's split limits. The appeal of the Perl semantics is that it's already implemented exactly the same way in Ruby and Java, so the learning curve is lower. > The problem described in your second case could be solved by using a > symbol, such as #:all, or something similar. I'm not a fan of this. :-( Because then you'd have to add another keyword, like #:trim, to trim off the blanks (which is what happens with a limit of 0), and then the interface suddenly got a lot more verbose. Wanting all the fields, or trimming blank ones, are the commonest use cases, and people who want to use it should not be punished with having to use a verbose syntax for it. Thanks for your feedback! Unfortunately, it sounds like implementing it would complicate things too much, in my opinion. :-( YMMV. Cheers, Chris.