[Scheme-reports] Fwd: Delivery Status Notification (Failure) Peter Bex (18 Dec 2014 12:23 UTC)

[Scheme-reports] Fwd: Delivery Status Notification (Failure) Peter Bex 18 Dec 2014 08:58 UTC

By the way, every time I "reply all" to your posts, John, I get this
highly annoying message quoted below.  Can anyone configure this to
behave more sanely without requiring everyone to sign up to every
single list that might be quoted?

----- Forwarded message from Mail Delivery Subsystem <mailer-daemon@google.com> -----

From: Mail Delivery Subsystem <mailer-daemon@google.com>
Subject: Delivery Status Notification (Failure)
To: Peter.Bex@xs4all.nl
Date: Thu, 18 Dec 2014 08:51:46 +0000
Message-ID: <f46d044289f6c2fe97050a79b3b8@google.com>

Hello peter.bex@xs4all.nl,

We're writing to let you know that the group you tried to contact (scheme-reports-wg2) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post:

 * You might have spelled or formatted the group name incorrectly.
 * The owner of the group may have removed this group.
 * You may need to join the group before receiving permission to post.
 * This group may not be open to posting.

If you have questions related to this or any other Google Group, visit the Help Center at http://groups.google.com/support/.

Thanks,

Google Groups

----- Original message -----

X-Received: by 10.180.82.34 with SMTP id f2mr227051wiy.1.1418892706703;
        Thu, 18 Dec 2014 00:51:46 -0800 (PST)
Return-Path: <Peter.Bex@xs4all.nl>
Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net. [194.109.24.29])
        by gmr-mx.google.com with ESMTPS id d18si1111237wiv.0.2014.12.18.00.51.46
        for <scheme-reports-wg2@googlegroups.com>
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Thu, 18 Dec 2014 00:51:46 -0800 (PST)
Received-SPF: none (google.com: Peter.Bex@xs4all.nl does not designate permitted sender hosts) client-ip=194.109.24.29;
Authentication-Results: gmr-mx.google.com;
       spf=none (google.com: Peter.Bex@xs4all.nl does not designate permitted sender hosts) smtp.mail=Peter.Bex@xs4all.nl
Received: from frohike.xs4all.nl ([80.101.127.174])
	by smtp-cloud2.xs4all.net with ESMTP
	id Uwrj1p0043ltdwY01wrkco; Thu, 18 Dec 2014 09:51:46 +0100
Date: Thu, 18 Dec 2014 09:50:10 +0100
From: Peter Bex <Peter.Bex@xs4all.nl>
To: John Cowan <cowan@mercury.ccil.org>
Cc: scheme-reports@scheme-reports.org, scheme-reports-wg2@googlegroups.com
Subject: Re: [Scheme-reports] Requesting early review of a character sequence library
Message-ID: <20141218085010.GK27666@frohike.xs4all.nl>
Mail-Followup-To: John Cowan <cowan@mercury.ccil.org>,
	scheme-reports@scheme-reports.org,
	scheme-reports-wg2@googlegroups.com
References: <20141218014902.GA31385@mercury.ccil.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20141218014902.GA31385@mercury.ccil.org>
User-Agent: Mutt/1.4.2.3i

On Wed, Dec 17, 2014 at 08:49:02PM -0500, John Cowan wrote:
> I'd appreciate getting feedback on the pre-SRFI version of a library I
> have designed for immutable shared character sequences called "spans".

This is great!  A more efficient redesign of SRFI-13 was long overdue.
Here's my initial reply after a quick scan of the library.

> It's available at <http://trac.sacrideo.us/wg/wiki/StringSlicesCowan>
> (the term "string slice" is no longer used).  Here are the current issues:

I'm a little worried about the duplication of -span and -string operations.
This seems confusing and causes the API surface to be pretty large.
I'd prefer to let all the "span" operations accept either a span or a
string, but that would probably slow things down considerably, again,
which defeats the point of this redesign.

> 1) Is "character span" a satisfactory name?

Seems fine to me.

> 2) Allow negative indices in make-span and subspan? Convenient, but
> irregular.

Ugly and unSchemely.

> 3) Titlecase doesn't really fit; keep it?

Too complicated and special-purpose and like you said, it doesn't fit;
drop it.

> 4) Keep string trees?

I'm not sure the name is good, but the operation is potentially useful.
On the other hand, it doesn't fit so well with the design of the library;
conceptually, operating on string internals is a very different operation
than writing various objects (among which strings) to a port.  It's a little
ill-defined too, especially the "otherwise, write-string-tree does nothing"
part.  What about user-defined records?  What about records with an associated
record printer?  And so on.  It's probably best to drop it.

> 5) Keep compatibility routines, possibly in a different package?

Which compatibility routines are those?  The remaining SRFI-13 ones?
That doesn't make much sense to me, unless you propose re-adding all the
variable argument versions as well.  That's pretty ugly and defeats the
point of this library, IMHO.

----- Message truncated -----

----- End forwarded message -----

--
http://www.more-magic.net

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports