On Sun, Aug 9, 2009 at 10:49 AM, Moritz Lenz<[email protected]> 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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
