From: Daniel Hartwig <mandyke@gmail.com>
To: Eli Barzilay <eli@barzilay.org>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: [PATCH] add regexp-split
Date: Sat, 31 Dec 2011 12:37:30 +0800 [thread overview]
Message-ID: <CAN3veRcjp1ymF+GnKVP2DdBuxyCBDK8JsEvbMxZ+z6qOfOnq-g@mail.gmail.com> (raw)
In-Reply-To: <20222.32678.878097.893104@winooski.ccs.neu.edu>
On 31 December 2011 11:21, Eli Barzilay <eli@barzilay.org> wrote:
>> A good point. I'm interested to find out the reasoning behind
>> Perl's decision to drop empty strings.. Seems a strange thing to do
>> IMO.
>
> I think that there's a general tendency to make things "nice" and
> dropping these things for cases where what the user wants is
> "obvious". And then when you realize that making the function behave
> differently sometimes is a bad idea, but you can't back off from the
> earlier version without breaking a ton of code. In any case, look
> also at the Emacs solution of an optional argument to drop all empty
> strings, with a weird behavior when no regexp is given...
In Scheme it is easy for the user to remove the empty strings if
desired. In Perl I'd say that this at least involves writing a loop
each time, hence their choice for the default "nice" behaviour.
The ease of using `filter' is a good case for keeping the empty
strings in Scheme version.
I could not find any mention of this optional Emacs arg. you talk
about; have a pointer for me?
next prev parent reply other threads:[~2011-12-31 4:37 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-29 9:32 [PATCH] add regexp-split Nala Ginrut
2011-12-29 9:46 ` Nala Ginrut
2011-12-29 10:20 ` Nala Ginrut
2011-12-29 13:58 ` Nala Ginrut
2011-12-30 5:34 ` Daniel Hartwig
2011-12-30 8:46 ` Nala Ginrut
2011-12-30 9:05 ` Nala Ginrut
[not found] ` <CAN3veRdFQyOthFTSLE7v9x3_A4HTPX99DSmDx26dBkeyy=MTDQ@mail.gmail.com>
2011-12-30 9:42 ` Daniel Hartwig
2011-12-30 11:40 ` Nala Ginrut
2011-12-30 11:47 ` Nala Ginrut
2011-12-30 15:23 ` Daniel Hartwig
2011-12-30 10:14 ` Marijn
2011-12-30 10:56 ` Nala Ginrut
2011-12-30 11:48 ` Marijn
2011-12-30 11:52 ` Nala Ginrut
2011-12-30 13:23 ` Marijn
2011-12-30 14:57 ` Daniel Hartwig
2011-12-31 1:46 ` Daniel Hartwig
2011-12-31 2:32 ` Eli Barzilay
2011-12-31 3:16 ` Daniel Hartwig
2011-12-31 3:21 ` Eli Barzilay
2011-12-31 4:37 ` Daniel Hartwig [this message]
2011-12-31 7:00 ` Eli Barzilay
2011-12-30 13:03 ` Neil Jerram
2011-12-30 15:12 ` Nala Ginrut
2011-12-30 16:26 ` Neil Jerram
2011-12-30 16:46 ` Nala Ginrut
2012-01-07 22:44 ` Andy Wingo
2011-12-30 15:33 ` Daniel Hartwig
2011-12-30 15:58 ` Nala Ginrut
-- strict thread matches above, loose matches on Subject: below --
2013-02-01 9:24 Nala Ginrut
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=CAN3veRcjp1ymF+GnKVP2DdBuxyCBDK8JsEvbMxZ+z6qOfOnq-g@mail.gmail.com \
--to=mandyke@gmail.com \
--cc=eli@barzilay.org \
--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).