Implement unusual syntax rules in grammar

[Moritz Lenz]

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?

Cheers,
Moritz