Re: [Bug-apl] bad character in execute+

[Hans-Peter Sorge]

Hello Jürgen,

compile fails with

Executable.cc: In member function 'void Executable::setup_lambdas()':
Executable.cc:529:46: error: no matching function for call to
'Executable::setup_one_lambda(ShapeItem&, int&)'
          b = setup_one_lambda(b, ++lambda_num) - 1;   // -1 due to ++b
in loop(b) above
                                              ^
In file included from Executable.cc:22:
Executable.hh:164:14: note: candidate: 'ShapeItem
Executable::setup_one_lambda(ShapeItem, ShapeItem, int)'
    ShapeItem setup_one_lambda(ShapeItem b, ShapeItem end, int lambda_num);
              ^~~~~~~~~~~~~~~~
Executable.hh:164:14: note:   candidate expects 3 arguments, 2 provided
Executable.cc: At global scope:
Executable.cc:543:1: error: no declaration matches 'ShapeItem
Executable::setup_one_lambda(ShapeItem, int)'
 Executable::setup_one_lambda(ShapeItem b, int lambda_num)
 ^~~~~~~~~~
In file included from Executable.cc:22:
Executable.hh:164:14: note: candidate is: 'ShapeItem
Executable::setup_one_lambda(ShapeItem, ShapeItem, int)'
    ShapeItem setup_one_lambda(ShapeItem b, ShapeItem end, int lambda_num);
              ^~~~~~~~~~~~~~~~
Executable.hh:38:7: note: 'class Executable' defined here
 class Executable
       ^~~~~~~~~~

Thanks,

Hans-Peter

Am 01.10.18 um 17:17 schrieb Juergen Sauermann:
> Hi Kacper,
>
> thanks, fixed in *SVN 1082*.
>
> /// Jürgen
>
>
>
> On 10/01/2018 01:11 AM, Kacper Gutowski wrote:
>> On Sun, Sep 30, 2018 at 03:42:53PM -0600, Nathan Rogers wrote:
>>> When using the diamond operator, the repl returns "bad character in
>>> execute+"
>>>
>>> simple example: \
>>> {1:2◊3}
>>>  Bad char in execute+
>> Lambda syntax in GNU APL isn't compatible with Dyalog's, and you can't
>> use diamond within it.  But the diamond here is a red herring.
>> It's the colon that causes the error before getting to the diamond:
>>
>>       :
>> Bad char in execute+
>>       {1⋄2}
>> Unbalanced curly bracket+
>>
>> It more-or-less works as expected.  The former is because : is not a
>> valid token outside of defined functions where it is used for labels.
>> The later is because it's interpreted as two separate statements split
>> by diamond.
>>
>> I think the )MORE messages for parse errors could be improved, though.
>> Now it just repeats "Bad char in execute".  It would be more informative
>> to say which character is the offending one.
>>
>> -k
>>
>>
>