Implement unusual syntax rules in grammar

[kjstol]

On Sun, Aug 9, 2009 at 10:49 AM, Moritz Lenz<moritz at faui2k3.org> wrote:
> Hi,
>
> Igor V. Burago wrote:
>> Dear members of the list,
>>
>> I'm implementing language for science computations similar to Matlab.  I found Parrot to be the best
>> solution for that.  Syntax of Matlab (which I'm trying to be compatible to) isn't quite logical and
>> consistent, so I've faced some problems expressing it grammar in Perl 6 rules.
>
> I don't know how octave implements its parser, but it might be worth
> looking at it for prior art.
>
>>  1. The language's control structures ('if', 'while', etc.) always ends with keyword 'end'.  It's
>>     prohibited to use this reserved word for other purposes... except indexing!
> ...
>>     In other cases, such as usual expressions, I could deny using of 'end' identifier later in NQP.
>>     I don't think this is a sane solution of my problem (I also understand that this using of
>>     keyword is not quite sane too).  Is there a better way?  Please let me know.
>
> I don't understand why you can't do it always that way
>
> rule if_statement {
>   :dba('if statement')
>  'if' <condition> ~ 'end'
>         <block>
> }
> ...
>
> token identifier {
>     <[a..z A..Z]> \w* {*}
> }
> ...
>
> method identifier($/) {
>    if !$IN_ARRAY_INDEX && $/ eq 'end' {
>        die('Illegal usage of "end" outside array index');
>    }
>    ...
> }
>
> and have the action method for the array index parsing set $IN_ARRAY_INDEX
>
>>  2. Due to Matlab compatibility the language also has inconsistent use of whitespace.  In most cases
>>     whitespace is not important and can be easily ignored by <ws> rule.  But there is an exception
>>     --- array constructor where it's used as delimiter between elements.
>>
>>     For example,
>>         [ 1 2 3 ]               three elements
>>         [ 1 -2 3 ]              still three elements
>>         [ 1-2 3 ]               two elements
>>         [ 1- 2 ]                one element
>>         [ 1 - 2 ]               again, one element
>>
>>     How whitespace matching behavior can be changed (for example, switched from one meaning to
>>     another inside and outside of expressions in array constructor) to parse such a weird
>>     constructions?
>
> I don't know; maybe you can try to use only explicit whitespace matching
> inside array constructors? Or use a different grammar with a different
> we token for that?

just an idea, not sure if it would work: what if the rule for array
constructors is defined as a token (not a rule), then you will need to
match "whitespace" explicitly, with some kind of custom whitespace
definition...

token array_constructor {
 '[' <.custom_ws>
# whatever an array constr looks like
 ']'
}

token custom_ws {
 # fill in details here
}

cheers,
kjs