From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Suggestion for change in the new array interface Date: Sat, 19 Feb 2005 22:32:59 +0100 Message-ID: <66e540fe050219133267ee9985@mail.gmail.com> Reply-To: djurfeldt@nada.kth.se NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1108849278 8986 80.91.229.2 (19 Feb 2005 21:41:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 19 Feb 2005 21:41:18 +0000 (UTC) Cc: Mikael Djurfeldt Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Feb 19 22:41:17 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D2cLd-0003ow-5I for guile-devel@m.gmane.org; Sat, 19 Feb 2005 22:41:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D2ccF-0006ax-HL for guile-devel@m.gmane.org; Sat, 19 Feb 2005 16:58:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D2cWG-0004Rb-Tw for guile-devel@gnu.org; Sat, 19 Feb 2005 16:52:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D2cW5-0004Js-BZ for guile-devel@gnu.org; Sat, 19 Feb 2005 16:51:58 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D2cW5-0004GV-0f for guile-devel@gnu.org; Sat, 19 Feb 2005 16:51:57 -0500 Original-Received: from [64.233.170.193] (helo=rproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D2cDl-0001Nd-67 for guile-devel@gnu.org; Sat, 19 Feb 2005 16:33:01 -0500 Original-Received: by rproxy.gmail.com with SMTP id y7so95210rne for ; Sat, 19 Feb 2005 13:33:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding; b=levqKuY/lfGPwyvUc6Oee7l1HHTfr1znBCkpcnlhzbT4hXFBPO3rpWD8NZxEtKDBVeFdKh2QQFU8l4KtvZHYe0A8TNJpyb2AtSNFXFpumc6jEIHzETvE/HrX/0jJAgJdnR6LkZJPSz1wtxfWQNZ0ZjqzCAOigZ3HSKXtykmES4I= Original-Received: by 10.38.150.46 with SMTP id x46mr77402rnd; Sat, 19 Feb 2005 13:32:59 -0800 (PST) Original-Received: by 10.38.104.39 with HTTP; Sat, 19 Feb 2005 13:32:59 -0800 (PST) Original-To: Marius Vollmer , guile-devel@gnu.org 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 X-MailScanner-To: guile-devel@m.gmane.org Xref: main.gmane.org gmane.lisp.guile.devel:4788 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:4788 When programming with the new array interface I've noticed an inconvenience that should be easy to fix: When checking the arguments of a procedure there's a few things one normally checks apart from the type. It's common that a procedure takes an array of a specific rank, and it's not unusual that only arrays of a specific dimension qualifies as an argument. Since both rank and dimensionality are extracted from the array handle this handle needs to be allocated *before* argument checking is complete. This means that we have to free the handle on an error exit. So, the code for argument checking only becomes: SCM_ASSERT (scm_is_typed_array (a, ), a, , ); scm_array_get_handle (a, &h); dims = scm_array_handle_dims (&h); if (scm_array_handle_rank (&h) != || dims[0].ubnd - dims[0].lbnd + 1 != || ...) { scm_array_handle_release (&h); scm_wrong_type_arg (, , a); } Since it seems unreasonable to allow future code to modify the dimension of an array, I don't see any reason why we couldn't ask for the rank and dimensions fo an array without allocating the handle. The above code could then instead look like this: SCM_ASSERT (scm_is_typed_array (a, ), a, , ); dims = scm_array_dims (a); SCM_ASSERT ( scm_array_rank (a) != || dims[0].ubnd - dims[0].lbnd + 1 != || ..., a, , ); scm_array_get_handle (a, &h); This all of course depends on the first sentence in the description of how to handle allocation of handles in the reference manual: "You must take care to always unreserve an array after reserving it, also in the presence of non-local exits. To simplify this, reserving and unreserving work like a frame (*note Frames::): a call to `scm_array_get_handle' can be thought of as beginning a frame and `scm_array_handle_release' as ending it. When a non-local exit happens between these two calls, the array is implicitely unreserved." The part after the first sentence indicates that I don't have to call scm_array_handle_release before throwing the error. Is that so? In that case this suggestion of change is unnecessary. Comments? M _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel