unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer")
Cc: guile-user@gnu.org, guile-devel@gnu.org
Subject: Re: Request for feedback on SRFI-126
Date: Wed, 30 Sep 2015 13:41:15 -0400	[thread overview]
Message-ID: <8737xvreis.fsf@netris.org> (raw)
In-Reply-To: <87zj08t5w1.fsf@T420.taylan> ("Taylan Ulrich \=\?utf-8\?Q\?\=5C\=22Bay\=C4\=B1rl\=C4\=B1\=2FKammer\=5C\=22\=22's\?\= message of "Sun, 27 Sep 2015 14:15:42 +0200")

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> I've made pretty fine experiences with R7RS-small so far[0][1][2][3],
> and after seeing people's disdain towards R7RS-large's direction and
> agreeing with them (although I wouldn't trust my own judgment alone),
> I've decided to try pushing R7RS-large in a somewhat better direction.
>
> The benefit for Guile?  I shortly summed up my thoughts on that in the
> FOSDEM thread on the Guix ML; here the mail from the archives:
> http://lists.gnu.org/archive/html/guix-devel/2015-09/msg00759.html
>
> Perhaps a better summary: better Scheme standards -> more libraries that
> work on any implementation -> more total Scheme users & more free-flow
> of users between implementations -> more potential for growth of the
> Guile community.  Not to mention simply more libraries Guile users can
> use, from the pool of standard-Scheme libraries, without needing a Guile
> porter and maintainer for every possible Scheme library.

I agree that standardization would be helpful, but we already have a
fine standard in R6RS.  It's not perfect, but IMO it's a more promising
platform than R7RS, which is so gratuitously incompatible with R6RS that
it's not possible to write even the simplest library or program that
works with both (wtf?).

One might well argue that having two competing and incompatible
standards is *worse* for standardization than having just one, hence my
reluctance to support R7RS.

In response to the argument that R6RS is a failure because so many
Scheme implementations rejected it: R6RS already has more high-quality
implementations than C++, Python, or Ruby.  Having 10+ implementations
of the same language doesn't seem to be a requirement for a language to
be successful.

In response to the argument that we should engage more in the R7RS-large
process to help move it in a better direction: I wasted a ridiculous
amount of time trying to get some R6RS numerics fixes into R7RS-small,
and was stonewalled the whole way.  I have neither the time nor the
interest in repeating that experience.

More to the point, I have no confidence that the decision making
processes in R7RS-large will result in a well-designed standard.
I agree with Andy Wingo's comments here:

  http://article.gmane.org/gmane.lisp.scheme.reports/4005
  http://article.gmane.org/gmane.lisp.scheme.reports/4019

Anyway, having said all this, I very much appreciate your sincere
efforts to help the Scheme and Guile communities, Taylan.

    Regards,
      Mark



  parent reply	other threads:[~2015-09-30 17:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-27 12:15 Request for feedback on SRFI-126 Taylan Ulrich Bayırlı/Kammer
2015-09-27 19:00 ` Panicz Maciej Godek
2015-09-27 20:11   ` Taylan Ulrich Bayırlı/Kammer
2015-09-27 23:20     ` Panicz Maciej Godek
2015-09-27 23:56       ` Marko Rauhamaa
2015-09-28  8:13       ` Taylan Ulrich Bayırlı/Kammer
2015-09-28 10:37         ` Marko Rauhamaa
2015-09-28 12:39           ` Taylan Ulrich Bayırlı/Kammer
2015-09-28 20:02         ` Panicz Maciej Godek
2015-09-29 20:05           ` Arne Babenhauserheide
2015-09-29 23:02             ` Panicz Maciej Godek
2015-09-29 23:44               ` Arne Babenhauserheide
2015-09-30  6:39                 ` Panicz Maciej Godek
2015-09-30 22:16                   ` Arne Babenhauserheide
2015-09-30 23:39                     ` Panicz Maciej Godek
2015-09-30  7:58             ` Taylan Ulrich Bayırlı/Kammer
2015-09-30 22:20               ` Arne Babenhauserheide
2015-10-01  7:33                 ` Taylan Ulrich Bayırlı/Kammer
2015-09-29 20:18   ` Arne Babenhauserheide
2015-10-01  5:11     ` Marko Rauhamaa
2015-09-28 15:46 ` Christopher Allan Webber
2015-09-28 17:34   ` Taylan Ulrich Bayırlı/Kammer
2015-09-30 17:41 ` Mark H Weaver [this message]
2015-09-30 22:33   ` Taylan Ulrich Bayırlı/Kammer

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=8737xvreis.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guile-devel@gnu.org \
    --cc=guile-user@gnu.org \
    --cc=taylanbayirli@gmail.com \
    /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).