Received: by 10.43.97.134 with SMTP id ck6mr6622449icc.32.1352151195136;
        Mon, 05 Nov 2012 13:33:15 -0800 (PST)
X-BeenThere: marpa-parser@googlegroups.com
Received: by 10.43.90.135 with SMTP id bi7ls15142008icc.3.gmail; Mon, 05 Nov
 2012 13:33:14 -0800 (PST)
Received: by 10.66.86.194 with SMTP id r2mr3489229paz.42.1352151194793;
        Mon, 05 Nov 2012 13:33:14 -0800 (PST)
Received: by 10.66.86.194 with SMTP id r2mr3489228paz.42.1352151194782;
        Mon, 05 Nov 2012 13:33:14 -0800 (PST)
Return-Path: <r...@savage.net.au>
Received: from mail1.qnetau.com (mail1.qnetau.com. [202.146.209.5])
        by gmr-mx.google.com with ESMTP id yl8si4264255pbc.1.2012.11.05.13.33.14;
        Mon, 05 Nov 2012 13:33:14 -0800 (PST)
Received-SPF: pass (google.com: domain of r...@savage.net.au designates 202.146.209.5 as permitted sender) client-ip=202.146.209.5;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of r...@savage.net.au designates 202.146.209.5 as permitted sender) smtp.mail=...@savage.net.au
Received: (qmail 21687 invoked by uid 399); 5 Nov 2012 21:33:12 -0000
Received: from unknown (HELO ?192.168.1.2?) (r...@savage.net.au@124.149.84.90)
  by mail1.qnetau.com with ESMTPAM; 5 Nov 2012 21:33:12 -0000
X-Originating-IP: 124.149.84.90
X-Sender: r...@savage.net.au
Message-ID: <50982F90.20005@savage.net.au>
Date: Tue, 06 Nov 2012 08:28:48 +1100
From: Ron Savage <r...@savage.net.au>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120922 Icedove/3.0.11
MIME-Version: 1.0
To: marpa-parser@googlegroups.com
Subject: Re: Question to the list: BNF interface notation
References: <509804F2.5080201@jeffreykegler.com>
In-Reply-To: <509804F2.5080201@jeffreykegler.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jeffrey

On 06/11/12 05:26, Jeffrey Kegler wrote:
> I intend in the BNF interface to introduce parentheses, which will
> indicate that the semantics do not see the enclosed symbols. This can be
> seen a generalization of the current keep/discard separators issue in
> sequences. I need this generalization is needed for some other features
> I am working on.
>
> What I intend is that, for example, in the rule
>
> |sum ::= term (op_add) term action => do_addition|

Or?

|sum ::= term [op_add] term action => do_addition|

Yes [] are overloaded, but often indicate optional items...

> the semantics would see the two 'term' values, but would not see the
> op_add. You'd write the semantics like this:
>
> |do_addition {
> my (undef, $a, $b) = @_;
> return $a + $b;
> }|
>
> On the other hand if the rule were written as follows
>
> |sum ::= term op_add term action => do_addition|
>
> the traditional semantics would be written
>
> |do_addition {
> my (undef, $a, undef, $b) = @_;
> return $a + $b;
> }|
>
> Reasons for the discard-if-parenthesized convention: Parenthesis
> traditionally suggest hidden or optional. Also, I may allow parentheses
> for grouping, in which case the semantics of the parenthesized part
> would become quite complex. If an alternative to discarding a complex
> parenthesized group was allowed, it would need special additional
> notation anyway.
>
> Possible reasons to dislike it: In Perl 5 regexes, parentheses by
> default mean capture and, for regexes, capture is roughly analogous to
> semantic visibility. I regret breaking from the Perl convention, but
> parentheses in Perl regexes *are* ugly and semantically overloaded, and
> I think the notation suggested above will be more graceful.
>
> Feedback from this list has changed my mind in the past, and I'd like to
> hear from you.
>
> -- jeffrey
>


-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622