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: port-with-print-state doesn't create a port? Or, when is a port not a port? :-) Date: Mon, 26 May 2014 10:47:33 -0400 Message-ID: <87mwe438ca.fsf@yeeloong.lan> References: <87fvk3mcpo.fsf@gnu.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 1401115827 20566 80.91.229.3 (26 May 2014 14:50:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 May 2014 14:50:27 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon May 26 16:50:20 2014 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 1WowEF-00072n-QT for guile-devel@m.gmane.org; Mon, 26 May 2014 16:50:19 +0200 Original-Received: from localhost ([::1]:57108 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WowEF-0002lg-Fh for guile-devel@m.gmane.org; Mon, 26 May 2014 10:50:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WowE6-0002kM-Eq for guile-devel@gnu.org; Mon, 26 May 2014 10:50:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WowE0-0004WU-Iy for guile-devel@gnu.org; Mon, 26 May 2014 10:50:10 -0400 Original-Received: from world.peace.net ([96.39.62.75]:59181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WowE0-0004Lq-F3; Mon, 26 May 2014 10:50:04 -0400 Original-Received: from ip72-221-68-65.ri.ri.cox.net ([72.221.68.65] helo=yeeloong.lan) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WowDi-0005re-9h; Mon, 26 May 2014 10:49:46 -0400 In-Reply-To: <87fvk3mcpo.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Wed, 21 May 2014 16:24:35 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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:17160 Archived-At: ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Doug Evans skribis: > >> The problem can be succinctly represented by the following: >> >> scheme@(guile-user)> (port? (port-with-print-state (current-output-port)= )) >> $3 =3D #f > > I think the short answer is that it=E2=80=99s a very old API that=E2=80= =99s essentially > unused internally. [...] [...] > I think the problem it was trying to solve has been solved differently > (by explicitly passing the print state in the print.c code, for > instance), and can easily be solved differently. In order to implement SRFI-38 properly and efficiently, I think we need to somehow pass the print state to user-defined structure printers. Among other things, the print state includes a map from the set of objects that are currently being printed (i.e. the ancestors of the current object) to the associated datum label. Aside from proper SRFI-38 support, the print state is also used to specify parameters such as maximum-depth for printing abbreviated structures, used for example by the backtrace printer. As distasteful as this 'port-with-print-state' concept may be, I'm not aware of a better solution. Fluids aren't quite right, because a structure printer might cause I/O to happen on another port. Another alternative would be to explicitly pass the print state to structure printers, and then provide versions of 'write' and 'display' that accept a separate print state argument, but we'd still need to handle all the existing struct printers that don't know about this. Yet another option would be to move the print state into the port itself. It might be worth considering, although it seems a bit unclean. Thoughts? Mark