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
>>
>>
>
