From: "Chris K. Jester-Young" <cky944@gmail.com>
To: guile-devel@gnu.org
Subject: Re: regexp-split for Guile
Date: Tue, 18 Sep 2012 15:31:25 -0400 [thread overview]
Message-ID: <20120918193125.GC6315@yarrow> (raw)
In-Reply-To: <50581D8F.2070703@gmail.com>
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.
next prev parent reply other threads:[~2012-09-18 19:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-17 14:01 regexp-split for Guile Chris K. Jester-Young
2012-09-17 19:32 ` Thien-Thi Nguyen
2012-09-17 20:06 ` Chris K. Jester-Young
2012-09-18 7:06 ` Sjoerd van Leent Privé
2012-09-18 19:31 ` Chris K. Jester-Young [this message]
2012-09-18 19:59 ` Chris K. Jester-Young
2012-10-07 2:38 ` Daniel Hartwig
2012-10-12 21:57 ` Mark H Weaver
2012-10-20 4:01 ` Chris K. Jester-Young
2012-10-20 13:27 ` Mark H Weaver
2012-10-20 14:16 ` Mark H Weaver
2012-10-21 8:20 ` Daniel Hartwig
2012-10-21 19:23 ` Chris K. Jester-Young
2012-10-21 16:08 ` Chris K. Jester-Young
2012-09-18 12:59 ` nalaginrut
2012-09-18 19:55 ` Chris K. Jester-Young
2012-09-19 0:30 ` nalaginrut
2012-10-04 21:47 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120918193125.GC6315@yarrow \
--to=cky944@gmail.com \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).