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.devel,gmane.lisp.guile.user Subject: Request for feedback on SRFI-126 Date: Sun, 27 Sep 2015 14:15:42 +0200 Message-ID: <87zj08t5w1.fsf@T420.taylan> 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 1443356074 5468 80.91.229.3 (27 Sep 2015 12:14:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2015 12:14:34 +0000 (UTC) To: guile-user@gnu.org, guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Sep 27 14:14:22 2015 Return-path: Envelope-to: guile-devel@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 1ZgAqJ-0001Ay-AV for guile-devel@m.gmane.org; Sun, 27 Sep 2015 14:14:11 +0200 Original-Received: from localhost ([::1]:57303 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgAqH-0000r4-PM for guile-devel@m.gmane.org; Sun, 27 Sep 2015 08:14:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgAqD-0000ql-Pa for guile-devel@gnu.org; Sun, 27 Sep 2015 08:14:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgAqC-0003vl-Ix for guile-devel@gnu.org; Sun, 27 Sep 2015 08:14:05 -0400 Original-Received: from mail-wi0-x22c.google.com ([2a00:1450:400c:c05::22c]:35831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgAqC-0003vb-A5; Sun, 27 Sep 2015 08:14:04 -0400 Original-Received: by wicge5 with SMTP id ge5so71591086wic.0; Sun, 27 Sep 2015 05:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:mime-version :content-type:content-transfer-encoding; bh=uvPY9Vi0C6t6r0eiInuBCj9q4+C6nE7IZ+V6YDWuVuI=; b=k0o5PmFiyX1LfhE7iewaErNOywRksCIDLtnaNTE8TR/SFDO7nKJSsa9hki/FgfRste NX+YXSe/NnnfHo4sNlAe6oSDzblBclWboqWCCAkAgQGl8EqwQ44h+DpeMMQtiQBXZ+Hd nJ6xQsFDIMNP6rYRFbZZSEtds08EHRimSJ0le8E3fh1FLqEDZcw9FGckjLt0nyDXh43q MeYNAkcp+LNT/7kINLc2npFdOKhnfr7CAc+uESxdqsXenGBseX7oxNixrOM20ZXPdPq4 i7eTqbosZKZ8VkjcDDEgbNIYhKeUxUXFWmfjPXWWTKcXIvvM28Eo/sMaH5M2wxP9eU/h jHSQ== X-Received: by 10.194.236.74 with SMTP id us10mr15733563wjc.39.1443356043163; Sun, 27 Sep 2015 05:14:03 -0700 (PDT) Original-Received: from T420.taylan ([2a02:908:c32:4740:221:ccff:fe66:68f0]) by smtp.gmail.com with ESMTPSA id ry1sm12857582wjb.24.2015.09.27.05.14.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Sep 2015 05:14:01 -0700 (PDT) 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::22c X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17862 gmane.lisp.guile.user:12041 Archived-At: Hello Guile folks, 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. 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. 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. 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'm doing my best to bring together good ideas from mature Scheme implementations like Racket, MIT/GNU Scheme, Gauche, and it goes without saying Guile. I shamelessly bother people like Taylor Campbell and Mark for their input, feeling they have a good sense for API design, get input from Shiro Kawai (Gauche author) and others on the SRFI MLs (John Cowan also has pretty good ideas sometimes), bother 'samth' and 'stamourv' on #racket, Jorgen Sch=C3=A4fer ('forcer') on #emacs, and so on, overall trying to work as an aggregator of good ideas. I hope that clarifies why/how someone inexperienced like me could be working on SRFIs/R7RS-large. *** Now on to SRFI-126. http://srfi.schemers.org/srfi-126/ First, why? Short history: there is SRFI-69, and it sadly has a design bug that makes it unsuitable for Schemes with a moving garbage collector (the "by pointer identity" hash function is exposed). Then there is the R6RS hashtables API, which is a good base and indeed SRFI-126 builds on that, fully backwards compatibly. Indeed I would have said "just standardize R6RS hashtables for R7RS" if it weren't for SRFI-125 popping up and gaining traction. It was a third incompatible API, not compatible with either SRFI-69 nor R6RS. Terrible! I needed to steal the attention from SRFI-125, so to say, with something that offers similarly neat features missing in SRFI-69 and R6RS, but without being terribly incompatible with them. Since then SRFI-125 received big changes and became SRFI-69 compatible itself, somehow managing to amend SRFI-69's design bug. If it also drops the SRFI-114 dependency and gets a little more polish, we might actually merge SRFI-125 and SRFI-126, but that hasn't happened yet. So I would now love to get feedback on the SRFI from the whole Guile community. Do you think it's RnRS worthy, specifically could it have been section "6.10 Hashtables" in R7RS-small? Would you enjoy being able to use the library in your Guile programs? I would especially love hearing the thoughts of the other main Guile developers, since I only queried Mark so far. Of course, I know you're all very busy, and I think I understand the frustrations over the RnRS, so no problem if you have no time or just don't feel like it. *** After that? I will probably work on a delimited continuations SRFI, heavily inspired by Guile's call-with-prompt, since I find it *immensely* more easy to grok than shift/reset and prompt/control because those mingle together the "stack slice" and the "handler" code whereas call-with-prompt clearly separates them. I will probably push for syntax-case re-standardization because it's very powerful and IMO most correctly captures/reifies the notion of Scheme "identifiers" as separate entities from contextless symbols. I will probably push for SRFI-99 standardization because it's backwards compatible with our beloved SRFI-9 and removes other flaws of R6RS records, while adding the important fundamental feature of subtyping. Like R6RS it also allows non-hygienic creation of getter/setter procedures, which seem often desired. (I wish it also supported R6RS's "protocol" feature... While seeming obscure, it has no clean implementation without being supported as a fundamental feature.) Let's see where this goes... I hope I didn't waste your time and am only wasting my own at worst! Taylan [0] https://github.com/taylanub/scheme-srfis [1] https://github.com/taylanub/scheme-bytestructures [2] https://github.com/larcenists/larceny/tree/master/tools/R6RS [3] https://github.com/TaylanUB/srfi-123 (code in srfi/ dir) [4] http://srfi.schemers.org/srfi-114/ "Comparators" [5] http://srfi.schemers.org/srfi-113/ Sets and bags using "comparators" [6] http://srfi.schemers.org/srfi-116/ Separate "immutable pair" type [7] http://srfi.schemers.org/srfi-117/ Queues based on lists [8] http://srfi.schemers.org/srfi-125/ Hash-tables using "comparators"