From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Panicz Maciej Godek Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: Request for feedback on SRFI-126 Date: Sun, 27 Sep 2015 21:00:46 +0200 Message-ID: References: <87zj08t5w1.fsf@T420.taylan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c34adec916720520bf325a X-Trace: ger.gmane.org 1443380464 7519 80.91.229.3 (27 Sep 2015 19:01:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2015 19:01:04 +0000 (UTC) Cc: "guile-user@gnu.org" , guile-devel To: =?UTF-8?B?VGF5bGFuIFVscmljaCBCYXnEsXJsxLEvS2FtbWVy?= Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Sep 27 21:01:03 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 1ZgHC1-00034D-Mu for guile-user@m.gmane.org; Sun, 27 Sep 2015 21:01:01 +0200 Original-Received: from localhost ([::1]:58431 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgHC1-0001gD-3v for guile-user@m.gmane.org; Sun, 27 Sep 2015 15:01:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgHBp-0001fu-F5 for guile-user@gnu.org; Sun, 27 Sep 2015 15:00:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgHBn-0006mw-JK for guile-user@gnu.org; Sun, 27 Sep 2015 15:00:49 -0400 Original-Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]:34422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgHBn-0006l7-9r; Sun, 27 Sep 2015 15:00:47 -0400 Original-Received: by wicfx3 with SMTP id fx3so78296416wic.1; Sun, 27 Sep 2015 12:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bmXZFs6VwvC85h+lpMSJl++E46EWJFr+Z/pz9x0/Ic8=; b=T5fl2B0hdUGkpj/6qymNhWUIQ9zTq1C/P7PqhVxZFJTJJZPriHXD7zMn+hryEo8r8Y K7I8Vm0B2Cqa21nEDHpwlDRJyzJs9G/WoCaqsTZJV5Cal3/Yy/3w8RrDpur0MX3FgbIn wAjRi0LUqD2aHedqVa0KEmvLqGBX21+kMMGHCLtoeM1fMyAZcyWnbsDlZiFwxPoVB2OZ Md2ONEL71bfKr6ctgWI/xRacdbZTGOHaX0wPUPjIswR8c6ZbZUc4aWY1oCSKG/xSguZ2 yOtnS2pc7+TNIF1MnsZfyod6zmUn76b37afG1wV1Vw+BBm26MQU8h19SbzuCVL2NsqRr uyFA== X-Received: by 10.180.184.134 with SMTP id eu6mr15191242wic.77.1443380446433; Sun, 27 Sep 2015 12:00:46 -0700 (PDT) Original-Received: by 10.194.34.35 with HTTP; Sun, 27 Sep 2015 12:00:46 -0700 (PDT) In-Reply-To: <87zj08t5w1.fsf@T420.taylan> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::231 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:12042 gmane.lisp.guile.devel:17863 Archived-At: --001a11c34adec916720520bf325a Content-Type: text/plain; charset=UTF-8 Hi, while I have nothing to say regarding the details of your SRFI, I find some of your motivations questionable, and therefore I decided to write this reply. Forgive the somewhat "negative" tone of this e-mail, despite my intentions being positive. > 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. > It is unclear to me what do you mean by "better direction", and in particular, how do you judge which direction is better or worse 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 > > You wrote there, among others, that "with a little more work, standard Scheme might actually become a language essentially as usable as Python and the like". If you're looking for a language that is "as usable as Python", then I'd recommend trying out Python, which is very good at what it does. Maybe I'm reading your point wrong, but I don't think that competing with Python or chasing Python or trying to mimic Python would be anything but a waste of time > 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. I don't think that the flow of users between the implementations is the major concern of the Scheme community, and I also haven't got a clue how one can tell what the phrase "better Scheme standards" means. "Better" by which standards? Actually, I think that if you really wanted to unite communities around various Scheme implementations, you'd need to do that through dialogue rather than standardizations -- because apparently the diversity between various implementations exists for a reason, as probably those communities worship different values > The envisioned direction for R7RS-large? I'll try writing specs which > could have been part of the clean R7RS-small, or could be part of an > R8RS that would be more in the vein of R6RS (without some key bad > parts), that is: not being overly minimalist, not catering to obscure > implementations that are barely maintained and used, being more daring > in requesting modern and advanced features from implementations that > want to be compliant. > To me, minimalism is at the very heart of Scheme, and any departure from it will sooner or later turn out to be harmful. I think that putting hash tables into the language is a particularly good example of something that goes against the spirit of Scheme. What I believe would go along the spirit of Scheme is that in certain circumstances, an assoc list could be optimized to a hash table, because a hash table is essentially an optimized implementation of key-value lookup Not like R7RS-large's apparent current direction[4][5][6][7][8], i.e.: > specifying a ton of questionable libraries that seem to fill imaginary > gaps, invite design bugs through the inclusion of spurious utility > forms, and overall seem more suitable to live as third-party libraries, > because they can be implemented as such without needing support for > additional fundamental features from Scheme implementations. All the > while said fundamental features are neglected from standardization > because X and Y minimalist implementation of Scheme won't be able to > support them. > Which "said fundamental features" do you mean? Does that make sense? Feel free to add to this high-level description > of the desired direction, even if it seems vague. I'm trying to sum up > the sentiment of others, so don't see the above as my personal opinion. > I think it would be much more worthwhile to create stunning applications (especially the ones that would make use of the Scheme's particular traits), rather than constantly improving the language which is already good enough. The issue of library interoperability between implementations should be solved only if it really turns out to be an actual problem. Best regards, M. --001a11c34adec916720520bf325a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
while I have nothing to say regarding the details = of your SRFI, I find some of your motivations questionable, and therefore I= decided to write this reply. Forgive the somewhat "negative" ton= e of this e-mail, despite my intentions being positive.


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 an= d
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.<= br>

It is unclear to me what do you mean by= "better direction", and in particular, how do you judge which di= rection is better or worse

The benefit for Guile?=C2=A0 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


You wrote there, among others, th= at "with a little more work, standard Scheme might actually become a l= anguage essentially as usable as Python and the like".

If you're looking for a language that is "as usabl= e as Python", then I'd recommend trying out Python, which is very = good at what it does.

Maybe I'm reading your p= oint wrong, but I don't think that competing with Python or chasing Pyt= hon or trying to mimic Python would be anything but a waste of time
=C2=A0
Perhaps a better summary: better Scheme standards -> more libraries that=
work on any implementation -> more total Scheme users & more free-fl= ow
of users between implementations -> more potential for growth of the
Guile community.

I don't think that the= flow of users between the implementations is the major concern of the Sche= me community, and I also haven't got a clue how one can tell what the p= hrase "better Scheme standards" means. "Better" by whic= h standards?

Actually, I think that if you really = wanted to unite communities around various Scheme implementations, you'= d need to do that through dialogue rather than standardizations -- because = apparently the diversity between various implementations exists for a reaso= n, as probably those communities worship different values
=C2=A0<= /div>
The envisioned direction for R7RS-large?=C2=A0 I'll try writing specs w= hich
could have been part of the clean R7RS-small, or could be part of an
R8RS that would be more in the vein of R6RS (without some key bad
parts), that is: not being overly minimalist, not catering to obscure
implementations that are barely maintained and used, being more daring
in requesting modern and advanced features from implementations that
want to be compliant.

To me, minimalism= is at the very heart of Scheme, and any departure from it will sooner or l= ater turn out to be harmful. I think that putting hash tables into the lang= uage is a particularly good example of something that goes against the spir= it of Scheme.

What I believe would go along the sp= irit of Scheme is that in certain circumstances, an assoc list could be opt= imized to a hash table, because a hash table is essentially an optimized im= plementation of key-value lookup

Not like R7RS-large's apparent current direction[4][5][6][7][8], i.e.:<= br> specifying a ton of questionable libraries that seem to fill imaginary
gaps, invite design bugs through the inclusion of spurious utility
forms, and overall seem more suitable to live as third-party libraries,
because they can be implemented as such without needing support for
additional fundamental features from Scheme implementations.=C2=A0 All the<= br> while said fundamental features are neglected from standardization
because X and Y minimalist implementation of Scheme won't be able to support them.

Which "said fundamen= tal features" do you mean?

Does that make sense?=C2=A0 Feel free to add to this high-level description=
of the desired direction, even if it seems vague.=C2=A0 I'm trying to s= um up
the sentiment of others, so don't see the above as my personal opinion.=

=C2=A0I think it would be much more wo= rthwhile to create stunning applications (especially the ones that would ma= ke use of the Scheme's particular traits), rather than constantly impro= ving the language which is already good enough.

Th= e issue of library interoperability between implementations should be solve= d only if it really turns out to be an actual problem.

=
Best regards,
M.

--001a11c34adec916720520bf325a--