From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: Request for feedback on SRFI-126 Date: Thu, 01 Oct 2015 00:33:26 +0200 Message-ID: <87zj03y1u1.fsf@T420.taylan> References: <87zj08t5w1.fsf@T420.taylan> <8737xvreis.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1443698324 12412 80.91.229.3 (1 Oct 2015 11:18:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 11:18:44 +0000 (UTC) Cc: guile-user@gnu.org, guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Oct 01 13:18:36 2015 Return-path: Envelope-to: guile-user@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 1Zhbsd-0001bn-NK for guile-user@m.gmane.org; Thu, 01 Oct 2015 13:18:31 +0200 Original-Received: from localhost ([::1]:48285 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhbsc-0006hr-HP for guile-user@m.gmane.org; Thu, 01 Oct 2015 07:18:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhPwM-0006iC-Ni for guile-user@gnu.org; Wed, 30 Sep 2015 18:33:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhPwK-0001be-Uo for guile-user@gnu.org; Wed, 30 Sep 2015 18:33:34 -0400 Original-Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:36869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhPwH-0001Xu-9o; Wed, 30 Sep 2015 18:33:29 -0400 Original-Received: by wicfx3 with SMTP id fx3so3620150wic.0; Wed, 30 Sep 2015 15:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=dUfEOY+DhswVGXPxs9M4K7IoV8gco+aVUohyuHxfVy4=; b=t+hurCGLnbYSqJIcL/KvItToQZKJBaQ78LqYeDeDY5DnZgVIolLHzXV+oQ1DR593Na 37AYtGlYMw398pluPmbi6mt0b6uowSlUE8WfvQawrrlgjuuBozL6TguQW74M9fua7Frv mCjv1g4DIXX445u3yIuNZkoghTW3q+HoqM0yKrXOz6jQyKd4amO0FefAqo5cN1AJ5qdB 2MoASe3KKInSg38FDgzc6kpIFmadZqyzwffbDRO1ObZhmvaJDl/hq9d9ALXZFuJt/uso CpEzNjgoHykYN/Gy+JmiYLNDEBsSO+F31TYMUTfLgzef4KKVN7Nau3D9pdqt5YB6jzZ1 IfHA== X-Received: by 10.194.240.132 with SMTP id wa4mr6867610wjc.138.1443652408662; Wed, 30 Sep 2015 15:33:28 -0700 (PDT) Original-Received: from T420.taylan ([2a02:908:c32:4740:221:ccff:fe66:68f0]) by smtp.gmail.com with ESMTPSA id o10sm2957511wia.4.2015.09.30.15.33.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2015 15:33:27 -0700 (PDT) In-Reply-To: <8737xvreis.fsf@netris.org> (Mark H. Weaver's message of "Wed, 30 Sep 2015 13:41:15 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22a X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:12065 gmane.lisp.guile.devel:17882 Archived-At: Mark H Weaver writes: > taylanbayirli@gmail.com (Taylan Ulrich "Bay=C4=B1rl=C4=B1/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?). While that might have been a dumb decision on the side of R7RS, at least converting an R6RS library to an R7RS library is usually trivial; one only needs to change the library boilerplate. (As long as an R6RS + R7RS implementation allows importing (rnrs *) libraries with the R7RS import directive.) But I suppose one desires a library that works with both unchanged, so as to keep working with R6RS-only implementations. If R6RS had 'include', one could have an R6RS and an R7RS library using the same body of code, so that goal would be fulfilled. Sadly R6RS doesn't have 'include'. (And it can't really be implemented with syntax-case as advertised, since there's insufficient control over the filesystem.) I'm not sure how important that is though, since most implementations seem to be taking the R7RS path. From what I know, Guile and Racket are the only remaining popular Scheme implementations that support R6RS libraries but not R7RS. Racketeers apparently discourage using R6RS anyway, preferring the racket language, and if there were demand they could probably implement R7RS quickly. I also see other shortcomings in R6RS in addition to the lack of 'include'. There is no 'cond-expand', which further makes it hard to write portable code. It also came to my attention that Guile's R6RS records API does not recognize SRFI-9 records. (I don't know if that can easily be fixed.) All in all R6RS feels like a "dead end", as William Clinger also suggests(*), whereas R7RS generally integrates very well with the underlying implementation and seems to address the goal of writing portable programs more pragmatically. In my bytestructures library I ultimately dropped R6RS support, because it just wouldn't play along. (*) http://andykeep.com/SchemeWorkshop2015/papers/sfpw1-2015-clinger.pdf For these reasons, I think it would be best if we could support R7RS too, and programmers gradually converted their R6RS libraries and programs to R7RS (which is fairly trivial as long as an R6RS + R7RS implementation allows importing R6RS libraries from R7RS). (By the way, regardless of the issues above, I like many aspects of the R6RS and will do my best to get them into R7RS. I would claim that my negative experiences with R6RS were not influenced by bias; I genuinely tried to make the R6RS wrapper for bytestructures work, and failed.) On another note, there is also the Larceny project of implementing R6RS libraries in R7RS, making some R6RS programs easy to port even to R7RS-only systems that lack native (rnrs *) libraries: https://github.com/larcenists/larceny/tree/master/tools/R6RS > 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. Well, I don't see any coordination between R6RS implementations to define more useful libraries (like sockets, delimited continuations, or an FFI), and don't see any future updates to R6RS itself happening. All in all, I'm not sure if I will ever be able to write something arguably basic like e.g. a small HTTP server in R6RS. I wouldn't call it a "failure" because I see it as a good resource for some purposes, but I could say I see it as a "dead" language. I can't do many useful things with it. > 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 Indeed, I understand your frustration, and wouldn't expect you and Andy to spend any more time and nerves on the R7RS discussion lists. I would still appreciate some quick reviews of SRFIs I will be writing, but I also understand if you see that too as a waste of time so no hard feelings if you say no. > Anyway, having said all this, I very much appreciate your sincere > efforts to help the Scheme and Guile communities, Taylan. Thanks for the kind words. :-) I'm not sure if anything I said affected your opinion, I hope it wasn't just a waste of time. > Regards, > Mark Taylan