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.
