[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-apl] Parsing Numbers
From: |
Juergen Sauermann |
Subject: |
Re: [Bug-apl] Parsing Numbers |
Date: |
Sat, 29 Aug 2015 13:59:41 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
Hi Mike,
I fixed the Assertion, see *SVN 666*.
I believe *1E¯¯6* should be tokenized as number *1* followed by
identifier *E¯¯6*.
The reason why *1D¯¯6* is a bad number is because *D* is a complex-marker,
which is followed by a non-number *¯¯6*. The ISO standard only allows
*J* as complex
marker, but IBM APL2 (and GNU APL) has *D* and *R* as well.
/// Jürgen
On 08/25/2015 07:49 PM, Mike Duvos wrote:
Hi,
GNU APL seems to be a bit too forgiving when processing malformed
numbers. It matches what it can, and then continues merrily onwards,
even if it is interpreting as a numeric vector a block of garbage with
no intervening spaces.
¯5¯6¯7
¯5 ¯6 ¯7
1E6E7
VALUE ERROR
1000000 E7
^
1E¯¯6
VALUE ERROR
1 E¯¯6
^
All of those should probably be SYNTAX ERRORs.
And sometimes, it just complains.
1E¯
==============================================================================
Assertion failed: uint32_t(i) < uint32_t(end)
in Function: operator[]
in file: Source.hh:64
Oddly, although it sees a 1 and a variable for 1E¯¯6, it recognizes
1D¯¯6 is a malformed number.
1D¯¯6
Bad number
I would think the desired behavior here would be that upon an initial
¯ or digit, match as many alphanumeric and ¯ characters as you can,
and if that string isn't a legal number, throw SYNTAX ERROR.