From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: records as s-expressions Date: 17 Oct 2003 07:43:06 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <87llrxcan4.fsf@zagadka.ping.de> <87fzhs6ect.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1066373133 21106 80.91.224.253 (17 Oct 2003 06:45:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 17 Oct 2003 06:45:33 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Oct 17 08:45:30 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AAOMc-0007BZ-00 for ; Fri, 17 Oct 2003 08:45:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AAOMH-0001dC-O2 for guile-devel@m.gmane.org; Fri, 17 Oct 2003 02:45:09 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AAOLh-0001UA-ID for guile-devel@gnu.org; Fri, 17 Oct 2003 02:44:33 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AAOL9-0001Lb-VT for guile-devel@gnu.org; Fri, 17 Oct 2003 02:44:32 -0400 Original-Received: from [80.84.72.21] (helo=s1.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AAOL9-0001LM-GU for guile-devel@gnu.org; Fri, 17 Oct 2003 02:43:59 -0400 Original-Received: from laruns.ossau.uklinux.net (bts-0196.dialup.zetnet.co.uk [194.247.48.196]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id h9H6hEC24893; Fri, 17 Oct 2003 07:43:43 +0100 Original-Received: from laruns.ossau.uklinux.net.ossau.uklinux.net (localhost [127.0.0.1]) by laruns.ossau.uklinux.net (Postfix on SuSE Linux 7.2 (i386)) with ESMTP id 08EC7DC4D3; Fri, 17 Oct 2003 07:43:06 +0100 (BST) Original-To: Rob Browning In-Reply-To: <87fzhs6ect.fsf@raven.i.defaultvalue.org> Original-Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 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 Xref: main.gmane.org gmane.lisp.guile.devel:2890 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2890 >>>>> "Rob" == Rob Browning writes: Rob> Thamer Al-Harbash writes: >> Would it be reasonable to just use (read-hash-extend) to hook >> into the existing reader, and as well as modify existing >> boot-9.scm code cause records to (display) as #S(...)? >> >> If I went with the SRFI-10 solution I'd be implementing this as a >> (record-serialize) (record-unserialize) which seem a bit less >> Schemeish to me. Rob> I think I might rather go with the SRFI since that means any Rob> records written have a much greater possibility of being able Rob> to be parsed by other schemes, [...] I agree with Rob. Remember that the only cleverness required here is to construct the reread record properly at _read_ time; if it was OK for construction to be delayed until evaluation, then records could be printed simply as whatever Scheme functional expression is needed to create a record (e.g. `(record-constructor )). So the problem is construction at read time, and this is exactly what SRFI-10 is designed to do. As regards convenience of usage, I think the details of the mechanism can all be hidden from the user inside `write', either using GOOPS, or by hacking the C code for write. I don't see a need for explicit record-serialize/record-unserialize calls. Best regards, Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel