From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Panicz Maciej Godek Newsgroups: gmane.lisp.guile.user Subject: Re: Reader syntax for accessing arrays Date: Fri, 26 Aug 2011 23:02:31 +0200 Message-ID: References: <87bovf5bg0.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: dough.gmane.org 1314392565 10330 80.91.229.12 (26 Aug 2011 21:02:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 26 Aug 2011 21:02:45 +0000 (UTC) Cc: =?ISO-8859-1?Q?Ludovic_Court=E8s?= , guile-user@gnu.org To: Johan Hidding Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Aug 26 23:02:40 2011 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qx3Xz-00088A-Bi for guile-user@m.gmane.org; Fri, 26 Aug 2011 23:02:39 +0200 Original-Received: from localhost ([::1]:48288 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qx3Xy-0000vs-Lw for guile-user@m.gmane.org; Fri, 26 Aug 2011 17:02:38 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38770) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qx3Xu-0000vi-TY for guile-user@gnu.org; Fri, 26 Aug 2011 17:02:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qx3Xt-0007KB-Uc for guile-user@gnu.org; Fri, 26 Aug 2011 17:02:34 -0400 Original-Received: from mail-vx0-f169.google.com ([209.85.220.169]:63507) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qx3Xt-0007Jx-K9; Fri, 26 Aug 2011 17:02:33 -0400 Original-Received: by vxj3 with SMTP id 3so3539566vxj.0 for ; Fri, 26 Aug 2011 14:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WG+9uC39dhRUca30q5EGA5b5V4sq59pdiEO/5LIQCCU=; b=srbeTkBdn6QhhVHXEyG3xDDzvpDvMJ6edURtqVarZ0gL2K8R7h1lCgAGUXlIQzUyJw bKJtFNnPxyTZaA6lyDI15f5F26PhI4PAgeyO1e2oQi9hu9O6au74CvNAu0W6Y5hqpiQw 20HKKyl8KBCbu8I697B6bbs+O7qvWJRLbq8Gg= Original-Received: by 10.220.75.149 with SMTP id y21mr443476vcj.259.1314392552131; Fri, 26 Aug 2011 14:02:32 -0700 (PDT) Original-Received: by 10.220.187.6 with HTTP; Fri, 26 Aug 2011 14:02:31 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.220.169 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:8739 Archived-At: Howdie, I would agree that specifying a rigid behavior for [] and {} brackets is pretty far away from the minimalistic spirit of scheme. However, section 7.1.1 of R5RS specification states, that characters [, ], {, } and | are "reserved for further extension of the language". (R6RS, on the other hand, makes a step backward, and indeed specifies a trivial rigid behavior for []). I eventually went without making a closure, and defined the following syntax: (define-syntax [ (syntax-rules (]) (([ v i ]) (vector-ref v i)))) It has three disadvantages. Firstly, it still needs the additional surrounding parentheses, secondly it requires spaces between the adjacent symbols, and thirdly it is not R5RS compliant, due to the reason stated above (and hence it doesn't work with various scheme implementations). I remember that I once used the infix module written by Daniel Skarda, but it used the quite non-portable read-hash-extend and I guess it is no longer shipped with guile. I believe that there must be a way to utilize the square and curly brackets that would suit the scheme philosophy. Perhaps the bigloo's read mechanism is close to that way, as it is conceptually simple, makes scheme more self-documentable and allows it to remain compatible with the behavior of [] in R6RS, while enabling the programmer to specify new behavior for it. Best regards, Maciek