From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kevin Ryde Newsgroups: gmane.lisp.guile.devel Subject: Re: make-vtable Date: Fri, 16 Feb 2007 11:07:34 +1100 Message-ID: <87zm7fm0c9.fsf@zip.com.au> References: <877iunt6yl.fsf@zip.com.au> <87r6suv5k2.fsf@laas.fr> <877iulwxzd.fsf@zip.com.au> <871wktrwur.fsf@laas.fr> <87tzxopinw.fsf@zip.com.au> <8764a3kdw8.fsf@laas.fr> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1171584521 11889 80.91.229.12 (16 Feb 2007 00:08:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2007 00:08:41 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Feb 16 01:08:35 2007 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HHqeQ-0003zg-IA for guile-devel@m.gmane.org; Fri, 16 Feb 2007 01:08:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HHqeQ-0007u7-3l for guile-devel@m.gmane.org; Thu, 15 Feb 2007 19:08:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HHqeM-0007u1-BL for guile-devel@gnu.org; Thu, 15 Feb 2007 19:08:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HHqeL-0007tp-63 for guile-devel@gnu.org; Thu, 15 Feb 2007 19:08:30 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HHqeL-0007tm-2f for guile-devel@gnu.org; Thu, 15 Feb 2007 19:08:29 -0500 Original-Received: from mailout2-8.pacific.net.au ([61.8.2.231] helo=mailout2.pacific.net.au) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HHqeK-0007ob-6o for guile-devel@gnu.org; Thu, 15 Feb 2007 19:08:28 -0500 Original-Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id B82C912901B for ; Fri, 16 Feb 2007 11:08:18 +1100 (EST) Original-Received: from localhost (ppp2DEB.dyn.pacific.net.au [61.8.45.235]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 0550327426 for ; Fri, 16 Feb 2007 11:08:15 +1100 (EST) Original-Received: from gg by localhost with local (Exim 4.63) (envelope-from ) id 1HHqdT-0001uy-Sx for guile-devel@gnu.org; Fri, 16 Feb 2007 11:07:36 +1100 Mail-Copies-To: never In-Reply-To: <8764a3kdw8.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Thu, 15 Feb 2007 09:45:27 +0100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:6527 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > > When creating stack > objects with (roughly) `(make-struct stack-type)', VTABLE is _not_ > consulted at all. The layout of stack objects is determined only by > that specified in SCM_STACK_TYPE. Yes. > Thus, VTABLE is redundant. Well, except for the creation (and continued existance) of scm_stack_type. > All this would be clearer if we had a `struct-vtable' type such that > `(make-struct struct-vtable)' would yield a new vtable (just like `(make > )' yields a new GOOPS class). Like `', `struct-vtable' > would terminate the "reflective tower" (i.e., its vtable is itself). Yes, as long as you don't want any extra fields in the vtable (which is true for scm_stack_type). I thought of that for my make-vtable func, (define make-vtable (let ((vtable-vtable #f)) (lambda (fields tail-size . print) (or vtable-vtable (set! vtable-vtable (make-vtable-vtable "" 0))) (apply make-struct vtable-vtable tail-size (make-struct-layout fields) print)))) Then wondered if it was worth bothering with. I guess if it's used by stacks.c too then it should share. (The name `struct-vtable' is taken by a func, but some other global name ...) > Actually, such a `struct-vtable' stealthily appears in > `make-vtable-vtable', under the name of REQUIRED_VTABLE_FIELDS: We could > really have a `struct-vtable' whose layout is REQUIRED_VTABLE_FIELDS and > then `make(-vtable)+' could be simply implemented in terms of > `make-struct' (just like `make-class' uses `make'). I think the problem is if you want extra fields in the vtables. Maybe a third level of table descriptor could do that (as opposed to self-vtabling roots). Though for now I'm only really looking at describing it, not changing it. > Perhaps a word saying the struct fields are laid out in a contiguous > memory area, which makes interaction with C much easier (using C arrays > or some such). Yep. I guess documenting SCM_STRUCT_DATA or whatever it is to get at them will be necessary too, if we're really pretending it's useful in C. > While the rest looks good, I remain skeptical about this part. And a > manual that claims to be confusing does not inspire confidence. ;-) It's ok to admit it's potentially confusing, if that's then followed by good explanation :-). _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel