Re: [Bug-apl] Parsing Numbers

[Juergen Sauermann]

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.