
From:  Juergen Sauermann 
Subject:  Re: [Bugapl] Bug in the parser? 
Date:  Tue, 25 Nov 2014 14:38:11 +0100 
Useragent:  Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 
Hi Elias, this is caused by an ambiguity of / (or ⌿, \. or ⍀ for that matter). These four APL symbols can, unfortunately, be dyadic functions or monadic operators. Your example boils down to this: A←1 2 3 4 5 B←0 1 1 0 1 A / ⍨ B The question is then should / be function  then we would have A (/⍨) B or operator  then we would have A / (⍨ B). Unfortunately there are cases where A is not yet knoen at the time this needs to be decided. I have read the IBM binding rules a number of times but they seem not to help. The problem of these rules is that they give different results in the cases where / is an operator and where / is a function. The binding rules say in which order tokens are bound but they do not decide if a token like / is a function or an operator. The solution in GNU APL is that / is assumed to be an operator unless the token left of it indicates a value (and then / is assumed to be a function. This happens at function definition time (where it is not yet known if A and B in the example above or m in your example) are values or functions). A closing ) left of / implies a value. You have already found the 2 ways to resolve this ambiguity: either put the left argument in parentheses (which marks it as a value in GNU APL) or to put the operator and its function argument in parentheses (which makes it a derived function). /// Jürgen On 11/25/2014 07:16 AM, Elias Mårtenson
wrote:

[Prev in Thread]  Current Thread  [Next in Thread] 