From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: thoughts on ports Date: Wed, 11 Apr 2012 14:36:06 -0400 Message-ID: <87hawq86ax.fsf@netris.org> References: <87zkam7z5n.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1334169567 19880 80.91.229.3 (11 Apr 2012 18:39:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 11 Apr 2012 18:39:27 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Apr 11 20:39:26 2012 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 1SI2Ry-00066o-Do for guile-devel@m.gmane.org; Wed, 11 Apr 2012 20:39:26 +0200 Original-Received: from localhost ([::1]:49436 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SI2Rx-0002rU-OP for guile-devel@m.gmane.org; Wed, 11 Apr 2012 14:39:25 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37448) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SI2Rv-0002rP-DV for guile-devel@gnu.org; Wed, 11 Apr 2012 14:39:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SI2Rt-0001kY-Ly for guile-devel@gnu.org; Wed, 11 Apr 2012 14:39:22 -0400 Original-Received: from world.peace.net ([96.39.62.75]:50683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SI2Rt-0001kS-Hg for guile-devel@gnu.org; Wed, 11 Apr 2012 14:39:21 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1SI2Rl-0002Ey-8b; Wed, 11 Apr 2012 14:39:13 -0400 In-Reply-To: <87zkam7z5n.fsf@pobox.com> (Andy Wingo's message of "Sun, 08 Apr 2012 13:21:24 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 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:14253 Archived-At: Hi Andy, Andy Wingo writes: > I have been thinking about ports recently. I know other folks have had > some thoughts here too, so it's probably good to have a discussion about > how they should look. I apologize that I've not yet had time to properly look into your eports work, so I'm afraid this email will not address your points adequately, but nonetheless I've been thinking about the ports code sporadically for many months, and here are my preliminary (and perhaps controversial :) thoughts: First of all, I think the ports code should be split into two layers: the lower layer should implement only byte ports (i.e. binary I/O). This layer should have multiple backends to support POSIX-style ports (e.g. file and socket I/O) as well as bytevector ports and user-defined "soft" byte ports. The upper layer should instead offer a character-based interface (probably unicode code-points in practice). It should also support multiple backends, including string ports, user-defined "soft" character ports, and perhaps most importantly a transcoding port that provides a character-based view of any arbitrary byte port, using a particular encoding. IMO, port-encoding should not be a fundamental property of all ports. It should _only_ be a property of transcoding ports. For example, SRFI-6 string ports should not have any encoding, nor should user-defined "soft" character ports. Transcoding ports should also support mixed byte/character-based I/O. If users want to do mixed-I/O on a string port, they can convert it to a bytevector in the desired character encoding and then create a transcoding bytevector port. One more recommendation for efficient implementation: internal routines should always work with _blocks_ of bytes or characters, rather than individual bytes or characters. Our current "soft" ports are hopelessly efficient for this reason, and they cannot be fixed without changing their interface, so they should be deprecated and replaced. Regarding the idea of moving some of this code to Scheme, it sounds like a great idea when we have good native code generation on the important upcoming platforms (x86/arm/mips at the very least), but until then I think our ports code better stay in C, but with hooks to implement ports in Scheme, analogous to our support for extensible numerics. Nonetheless, I like the idea of using bytevectors for buffering in byte ports, and offsets instead of pointers. What do you think? Best, Mark